[디지털 뱃지] 일일 스터디 Day 08

[디지털 뱃지] 일일 스터디 Day 08

General(API Design) & Developer(Authentication) 핵심 돌파

1. 오늘의 핵심 이론 설명

General Engineering - API Design

RESTful API 설계 사상과 HTTP 메서드의 멱등성

클라우드 제어 시스템 및 이종 솔루션 간 유연한 데이터 교환을 구현하기 위해 엔지니어가 반드시 준수해야 하는 자원 지향적 인터페이스 기초 표준입니다.

• REST(Representational State Transfer)의 핵심 사상: 모든 자원(Resource)을 독자적인 URI(Uniform Resource Identifier)로 식별하고, 자원에 대한 행위는 HTTP 표준 메서드로 표현하며, 자원의 상태 표현은 JSON이나 XML 형태의 메시지로 처리하는 아키텍처 스타일입니다.
• 주요 HTTP 메서드 분류:
  - GET: 특정 자원의 조회를 요청하며, 시스템 상태를 변형시키지 않는 안전한(Safe) 메서드입니다.
  - POST: 새 자원을 생성할 때 사용하며, 매 요청마다 새로운 하위 자원이 추가됩니다.
  - PUT: 대상 자원의 전체를 대체(전체 수정)하거나 없다면 새로 생성합니다.
  - PATCH: 자원의 일부 속성만 부분적으로 수정할 때 사용합니다.
  - DELETE: 지정한 자원을 삭제합니다.
• HTTP 메서드의 멱등성(Idempotency): 동일한 요청을 한 번 보내는 것과 여러 번 연속해서 보내는 것이 서버의 자원 상태에 동일한 결과를 가져오는 성질입니다. GET, PUT, DELETE는 멱등성을 가지지만, 새로운 리소스를 계속 생성하는 POST와 부분 수정을 가하는 PATCH(설계에 따라 다름)는 일반적으로 멱등성을 보장하지 않습니다.

Developer Engineering - Authentication

세션(Session) 기반 인증 vs JWT 토큰(Token) 무상태 인증 메커니즘

수평적 확장이 필수적인 대규모 클라우드 웹 애플리케이션 인프라에서 분산 사용자 인증을 안전하게 제어하는 아키텍처적 진화입니다.

• 세션(Session) 기반 인증의 한계: 서버 메모리나 세션 저장소(DB/Redis)에 클라이언트의 로그인 상태를 저장하는 상태 유지(Stateful) 방식입니다. 사용자가 폭증하거나 로드밸런서에 의해 다수의 서버 노드로 트래픽이 분산될 때, 각 서버 간 세션 데이터를 동기화(Session Clustering)해야 하거나 특정 서버에만 사용자를 종속시켜야 하는 오버헤드가 큽니다.
• JWT(JSON Web Token) 기반 무상태(Stateless) 인증: 사용자 인증 정보를 암호화된 토큰(Token) 형태로 클라이언트가 직접 들고 있게 하는 방식입니다. 서버는 세션을 별도로 기억하지 않고(무상태), 토큰의 서명(Signature)만 검증하여 적합성을 확인하므로 백엔드 인프라 노드가 수천 개로 스케일 아웃되어도 동기화 부담이 전혀 없습니다.
• JWT의 구조적 특징: JWT는 점(.)을 기준으로 Header(알고리즘 및 토큰 타입), Payload(사용자 식별 정보 및 권한 등 Claim), Signature(변조 방지 검증 서명)의 3개 레이어로 결합되어 있습니다. Payload는 단순 Base64로 인코딩되어 누구나 열어볼 수 있으므로, 패스워드 같은 민감한 금융/개인 정보는 절대 포함해서는 안 됩니다.

---

2. 디지털 뱃지 레벨 1~2 예상 문제집

Q1. HTTP 구조 사상 중 '멱등성(Idempotency)'에 대한 설명으로 올바르지 않은 것은?

1) 동일한 요청을 한 번 수행한 결과와 백 번 수행한 결과가 서버의 자원 관점에서 동일한 특성을 말한다.
2) GET 메서드는 자원의 상태를 변경하지 않는 안전한 메서드이므로 당연히 멱등성을 만족한다.
3) PUT 메서드는 대상 자원을 지정한 내용으로 매번 완전히 대체하므로 여러 번 수행해도 결과가 동일한 멱등 메서드이다.
4) POST 메서드는 리소스의 생성 역할을 담당하므로, 수차례 연속 호출하더라도 서버에 중복 자원이 생기지 않아 멱등성을 가진다.

정답 및 해설 보기

정답: 4)
해설: POST 메서드는 실행할 때마다 서버 내부에 새로운 하위 리소스 데이터를 생성하므로, 동일한 POST 요청을 10번 보내면 10개의 고유한 리소스가 중복으로 쌓이게 됩니다. 따라서 POST는 대표적인 '비멱등(Non-idempotent)' 메서드입니다.

Q2. JWT(JSON Web Token) 아키텍처에 대한 특징 중 가장 거리가 먼 것은?

1) 클라이언트의 상태를 서버가 기록할 필요가 없는 무상태(Stateless) 분산 인증을 구현하기에 용이하다.
2) 토큰 내의 Payload 데이터는 Base64 인코딩만 되어 있으므로 보안 유지를 위해 노출되어도 괜찮은 정보 위주로 구성해야 한다.
3) 클라이언트가 토큰을 탈취당하더라도, 서버가 세션 저장소처럼 중앙에서 토큰의 즉각적인 무효화를 즉시 보장하므로 완벽하게 안전하다.
4) Header와 Payload의 내용을 비밀키를 이용해 해싱하여 생성한 Signature를 통해 토큰 데이터의 위변조 여부를 완벽히 판별한다.

정답 및 해설 보기

정답: 3)
해설: JWT는 서버가 발급한 뒤에는 상태를 직접 통제하지 않는 분산 인증 방식입니다. 토큰 자체가 유효성을 입증하므로, 한 번 유출된 토큰은 만료 시간 전까지 임의로 서버가 차단(Blacklist 등 별도 저장소를 구축하지 않는 한)하기가 극히 어렵습니다. 이 단점을 보완하기 위해 만료 주기가 짧은 Access Token과 이를 갱신하는 Refresh Token 투-트랙 메커니즘을 주로 연동합니다.

---

💡 신기술 추가 지식 : API 게이트웨이 연계 중앙화 OAuth2 / OIDC 인증 패턴

모던 클라우드 네이티브 MSA 생태계에서는 수십 개의 개별 마이크로서비스 내부 컴포넌트들이 각자 JWT 서명을 해독하고 유효성 검사를 처리하는 로직을 직접 품고 있는 구조를 지양하고 있습니다. 대신 시스템 아키텍처 전면에 위치한 API Gateway나 분산 프록시 레이어(Envoy 등)가 최상단 진입점에서 중앙 통제 장치 역할을 담당합니다. 외부 요청이 유입되면 외부용 인증 규격(OAuth2 / OIDC) 프로토콜을 이용해 Gateway가 토큰 유효성을 일괄 검증한 후, 인증이 완료되면 내부 마이크로서비스 노드망에는 오직 컨텍스트 전송용 경량 토큰이나 HTTP 헤더 형태로 신원 정보를 바인딩하여 안전하고 초고속으로 내부 통신을 연결하는 라우팅 아키텍처가 전방위 표준으로 채택되고 있습니다.