549. JWT (JSON Web Token)

핵심 인사이트 (3줄 요약)

본질: JWT는 이름 해석과 네트워크 관리에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.

가치: JWT를 이해하면 가시성과 관리 자동화 사이의 균형을 더 정확히 볼 수 있다.

판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

개념: JWT는 정보 덩어리를 두 주체 간에 안전하게 전송하기 위한 간결하고 독립적인 방법이다. 점(.)을 기준으로 세 부분(Header, Payload, Signature)으로 나뉘며, 서버는 DB를 뒤져보지 않고도 토큰 끝에 달린 '서명'을 수학적 공식으로 풀어내어 이 토큰이 내가 발급한 진짜 토큰인지 단 1밀리초 만에 검증해낸다.
필요성: 기존의 쿠키-세션(Session) 방식에서는 사용자가 로그인하면 서버 메모리에 세션 ID를 저장해두고, 사용자가 올 때마다 메모리를 뒤져야 했다. 만약 회사가 커져 서버가 100대로 늘어나면? 1번 서버에서 로그인한 사용자가 2번 서버로 요청을 보내면 2번 서버는 "너 누구야?"라며 로그인을 다시 요구한다. 이를 막기 위해 세션 클러스터링(Redis 등)을 구축해야 하는데, 이는 거대한 낭비와 병목 지점(SPOF)을 만든다.
등장 배경: ① 레거시 세션/쿠키 인증 방식의 스케일아웃(Scale-out) 한계 폭발 → ② 모바일 앱과 SPA(React/Vue) 환경에서의 쿠키 사용 제약 및 CORS 문제 발생 → ③ 서버 부하를 0으로 만들면서도 모바일/웹 모두에서 호환되는 무상태(Stateless) 토큰 인증 아키텍처(JWT)의 표준화.

┌─────────────────────────────────────────────────────────────┐
│             기존 세션(Session) 방식 vs JWT(Stateless) 방식 비교    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   [과거: 무거운 Stateful 세션 방식]                              │
│   Client ─(로그인)─▶ [서버 A] ──▶ [Session DB (Redis)] 저장     │
│   Client ─(구매)──▶ [서버 B] ──▶ [Session DB] 뒤져봄 (병목 발생)  │
│   => 서버가 늘어날수록 인증 확인 때문에 중앙 DB가 마비되는 재앙!         │
│                                                             │
│   [혁신: 가벼운 Stateless JWT 방식]                             │
│   Client ─(로그인)─▶ [인증 서버] ─▶ 서버가 '디지털 도장(JWT)' 찍어서 발급│
│                                                             │
│   Client ─(구매)──▶ [서버 A] (DB 안 봄. 토큰의 도장만 수학적으로 1초 계산)│
│   Client ─(결제)──▶ [서버 B] (DB 안 봄. 토큰의 도장만 수학적으로 1초 계산)│
│   => 1만 대의 서버가 늘어나도 인증 DB 병목이 0! 무한한 스케일아웃 가능!   │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 그림은 아키텍처 설계에서 왜 개발자들이 열광하며 JWT로 넘어왔는지(Paradigm Shift)를 완벽히 보여준다. 예전엔 놀이공원 입구에서 표를 사면, 놀이기구 직원이 매번 무전기로 본부에 "이 사람 표 산 거 맞아요?"라고 물어봐야(DB 조회) 했다. JWT는 놀이공원 입구에서 특수 형광 도장이 찍힌 팔찌(토큰)를 채워주는 것이다. 이제 놀이기구 직원(서버 A, B)들은 본부에 연락할 필요 없이, 자기가 가진 형광등(Secret Key)으로 팔찌의 도장만 비춰보면 진짜인지 가짜인지 그 자리에서 바로 판별할 수 있다. 분산 컴퓨팅 환경에 빛과 같은 효율을 가져왔다.

📢 섹션 요약 비유: 세션(Session) 방식은 식당 주인이 단골손님의 외상 장부를 머릿속에 다 기억(메모리)해야 하는 것이고, JWT는 주인이 손님에게 위조 불가능한 도장을 찍은 식권(토큰)을 쥐여줘서, 주인이 기억력을 쓸 필요 없이 식권만 보고 밥을 주는 획기적인 무뇌(Stateless) 식당 운영법과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리

구성 요소 (JWT의 3단 샌드위치 구조)

JWT는 매우 콤팩트한 문자열로 xxxxxxx.yyyyyyy.zzzzzzz 처럼 점(.) 세 개로 구분된다. 모든 텍스트는 암호화(Encryption)된 것이 아니라 단순히 텍스트 형태 변환(Base64URL Encoding)만 된 것이므로 누구나 열어볼 수 있다.

요소명 (구간)	영문 명칭	내용 및 목적	예시 (Base64 디코딩 전후)	비유
첫 번째 (Red)	Header (헤더)	어떤 서명 알고리즘(예: HS256, RS256)을 썼는지, 타입이 무엇인지 정의	`{"alg": "HS256", "typ": "JWT"}`	수표의 위조방지 마크 종류 설명
두 번째 (Green)	Payload (페이로드/클레임)	사용자의 이름, 권한, 만료시간 등 전달하려는 핵심 정보(Claims)의 집합	`{"sub": "123", "name": "Hong", "exp": 1712345678}`	수표에 적힌 금액과 받는 사람 이름
세 번째 (Blue)	Signature (디지털 서명)	헤더와 페이로드를 합친 후 서버만이 아는 '비밀키(Secret Key)'로 수학적 해싱 연산을 한 절대 위조 불가능한 도장 값	`HMACSHA256(base64(Header) + "." + base64(Payload), 256비트_비밀키)`	은행장이 꽉 찍은 물리적 인감도장

서명(Signature) 검증의 마법 원리

해커가 Payload 부분의 Base64 문자열을 디코딩하여 "name": "Hong"을 "name": "Admin"으로 위조했다고 가정하자. 이 공격이 통하지 않는 원리가 JWT의 심장이다.

┌───────────────────────────────────────────────────────────────┐
│               JWT 위조 공격 방어와 수학적 서명 검증 원리            │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│   [해커의 토큰 조작]                                            │
│   원본 Payload: {"role": "user"}  ──▶ 조작: {"role": "admin"}   │
│   (해커는 헤더와 페이로드를 Base64로 묶어 서버로 전송!)               │
│                                                               │
│   [서버의 검증 로직 가동]                                         │
│   1. 수신: 서버가 조작된 헤더 + 조작된 페이로드 + 기존 서명을 받음.       │
│                                                               │
│   2. 연산: 서버 금고에 있는 [비밀키(Secret)]를 꺼내어                 │
│            해커가 보낸 (헤더 + 페이로드)를 공식에 넣고 믹서기(해싱) 돌림.│
│                                                               │
│   3. 대조: 서버가 방금 갓 짠 따끈한 새 [도장 값]  VS  해커가 보낸 [도장 값] │
│                                                               │
│   4. 결론: "어? 글자 하나가 바뀌었더니 믹서기 결과가 완전히 다르잖아!"      │
│            "이 토큰은 조작되었다!" ──▶ HTTP 401 Unauthorized 차단! │
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 암호학적 해시 함수(SHA-256 등)는 눈곱만한 글자 하나만 바뀌어도 결과 값이 완전히 달라지는 눈사태 효과(Avalanche Effect)를 갖는다. 서버는 토큰을 받을 때마다 자기가 가진 **유일한 비밀키(Secret Key)**를 이용해 헤더와 페이로드를 다시 해싱해본다. 해커는 헤더와 페이로드는 마음대로 고칠 수 있지만, 서버의 금고 안에 있는 '비밀키'를 모르기 때문에 바뀐 내용에 딱 들어맞는 새로운 '서명(Signature)'을 절대 찍어낼 수가 없다. 결국 서버가 계산한 서명과 토큰에 달린 서명이 불일치하게 되어 100% 위조 적발이 가능해진다.

백엔드 및 보안 아키텍처 설계 시 가장 격렬하게 논쟁하는 두 가지 방식의 트레이드오프다.

비교 기준	쿠키 + 세션 (Stateful)	JWT 토큰 (Stateless)
상태 저장 위치	서버의 메모리 또는 Redis DB	클라이언트(브라우저, 앱)의 로컬 저장소 / 쿠키
서버 확장성 (Scale-out)	불편함 (서버 간 세션 공유(Clustering) 인프라 필수)	최상 (각 서버가 독립적으로 서명만 검증하면 끝)
보안 (탈취 및 강제 로그아웃)	강력함 (서버에서 세션 ID 지워버리면 해커 즉시 쫓겨남)	취약함 (발급된 JWT는 수명이 끝날 때까지 서버가 강제로 죽일 수 없음)
CSRF 및 모바일 호환	CSRF(교차 사이트 요청 위조) 공격에 취약, 네이티브 모바일 앱 구현 귀찮음	헤더(Bearer) 전송 시 CSRF 방어 우수, Android/iOS 네이티브 완벽 호환
트래픽 오버헤드	적음 (세션 ID 문자열만 오감)	다소 큼 (Payload에 넣는 정보가 많을수록 패킷 뚱뚱해짐)

JWT는 완벽하지 않다. 서버가 한 번 토큰을 발급하고 나면, "앗 저 토큰 해커가 훔쳐 갔네!"라고 알아채도 그 토큰을 즉시 정지시킬 버튼(State)이 서버에 존재하지 않는다. (통제권 상실). 이 치명적인 단점을 극복하기 위해 실무에서는 Access Token과 Refresh Token을 쪼개는 아키텍처가 강제된다.

┌───────────────────────────────────────────────────────────────┐
│               JWT의 치명적 단점 극복: Refresh Token 아키텍처        │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│   [Access Token] (수명: 15분)                                   │
│   - 가볍고 서명 검증만으로 통과. DB 안 봄 (Stateless)                 │
│   - 해커가 훔쳐 가도 15분 뒤면 쓰레기가 됨. 피해 최소화.               │
│                                                               │
│   [Refresh Token] (수명: 2주일)                                  │
│   - Access Token이 죽었을 때만, 새것을 받기 위해 제한적으로 서버에 제시. │
│   - 이것만큼은 서버 DB(Stateful)에 저장해서 해킹 발견 시 DB에서 지워버림!│
│                                                               │
│   => 결과: "평소엔 매우 빠른 Stateless API 통신을 유지하면서도,        │
│            해킹 시 최대 15분 이내에 해커를 영구히 쫓아낼 수 있는 하이브리드"│
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 순도 100%의 무상태(Stateless) JWT 아키텍처는 이론상 아름답지만, 보안 사고 대응이 불가능해 실제 엔터프라이즈 환경에서는 쓸 수 없다. 따라서 "통신의 99%를 차지하는 API 호출 구간은 가벼운 Access Token으로 날아다니고(서버 부하 0), 토큰이 만료되어 1% 빈도로 발생하는 갱신 요청 때에만 무거운 Refresh Token을 검사하는(서버 DB 조회)" 형태의 융합(Hybrid) 구조를 채택한다. 만약 사용자가 핸드폰을 분실해서 "기기 강제 로그아웃" 버튼을 누르면, 서버는 DB의 Refresh Token을 지워버린다. 해커는 들고 있던 Access Token으로 길어야 15분 더 놀 수 있지만, 그 뒤 갱신 시점에 매정하게 차단당한다.

상황: 쇼핑몰이 커져서 회원 서버, 주문 서버, 결제 서버, 배송 서버 등 50개의 마이크로서비스(MSA)로 쪼개졌다. 고객이 주문을 할 때 4개의 서버를 차례대로 거치는데, 각 서버가 "이 고객 로그인한 거 맞아?"라며 회원 서버 DB를 찔러보면 회원 서버가 죽어버리는 병목 현상이 발생한다.
해결책 (JWT 분산 검증):
- 고객이 로그인하면 **API 게이트웨이(Gateway)**가 JWT 토큰을 만들어 브라우저에 내려준다.
- 고객은 주문할 때마다 HTTP 헤더에 Authorization: Bearer eyJhbG... 형태로 JWT를 달고 쏜다.
- API 게이트웨이는 토큰 서명이 맞는지 가볍게 1차 검사한 후, 그 토큰을 주문 서버 -> 결제 서버 -> 배송 서버로 통과시킨다.
- 각 뒷단(Back-end) 마이크로서비스들은 중앙 DB를 쳐다볼 필요 없이, 자기가 건네받은 JWT 페이로드를 뜯어서 {"user_id":"123", "role":"VIP"}라는 정보를 믿고 0.1초 만에 즉시 비즈니스 로직(결제, 배송 처리)을 실행한다.
결과: 인증에 의한 DB I/O 부하가 100% 소멸하며, 뒷단 서버들이 무한정 스케일아웃(서버 증설) 가능한 궁극의 유연성을 확보했다.

도입 체크리스트 및 안티패턴

알고리즘 'None' 공격 (치명적): 해커가 토큰 헤더의 "alg": "HS256"을 "alg": "none"으로 변조하여 서버로 보내는 고전적 해킹 기법. 라이브러리를 대충 쓰면 서버가 "어? 서명 알고리즘이 none이네? 그럼 검증 통과시켜줄게!"라며 조작된 페이로드를 허용해버리는 참사가 일어났다. 현재는 대부분 패치되었으나, 서명 검증 시 서버 측에서 '반드시 HS256/RS256만 수용'하도록 명시적 코드 방어를 구축해야 한다.
XSS 탈취 방어 (보관 위치 안티패턴): 발급받은 JWT를 브라우저의 localStorage 나 sessionStorage에 보관하는 행위. 게시판에 악성 스크립트를 숨기는 XSS(Cross-Site Scripting) 공격에 1초 만에 토큰을 통째로 털린다. 이를 막기 위해 토큰은 반드시 **HttpOnly 속성이 부여된 보안 쿠키(Cookie)**에 담아 브라우저가 자바스크립트로 절대 접근할 수 없게 철벽을 쳐야 한다. 페이로드에 민감 정보(주민번호, 비밀번호)를 담는 것도 절대 금기다(Base64는 암호화가 아니므로 누구나 디코딩해 읽을 수 있음).
📢 섹션 요약 비유: JWT는 누구도 글자를 몰래 바꿀 수 없는(위조 방지) 튼튼한 유리 상자입니다. 하지만 유리 상자이므로 밖에서 안의 내용물이 훤히 보입니다(기밀성 없음). 따라서 그 상자 안에 일기장이나 현관 비밀번호 같은 진짜 중요한 프라이버시는 절대 넣어두면 안 됩니다.

Ⅲ. 비교 및 연결

JWT를 볼 때는 앞뒤 개념과의 경계를 함께 봐야 전체 흐름이 선명해진다. OpenID Connect가 기반 조건을 만든다면, JWT는 그 위에서 핵심 메커니즘을 구현하고, X.509 v3 디지털 인증서 표준 규격은 이를 더 확장된 적용 단계로 연결한다. 따라서 단일 정의보다 가시성과 관리 자동화에 어떤 차이를 만드는지 비교하는 것이 중요하다.

관점	선행 개념	현재 개념	확장 개념
초점	OpenID Connect의 기반 정리	JWT의 핵심 동작	X.509 v3 디지털 인증서 표준 규격의 확장 적용
자원 관점	기본 조건 확보	가시성 최적화	규모와 범위 확대
판단 포인트	도입 가능성 확인	현재 메커니즘의 적합성 판단	운영·확장 전략 연결

📢 섹션 요약 비유: JWT는 비슷한 기술들 사이의 차선을 구분하는 분기점과 같다. 어디서 갈라지는지 알아야 헷갈리지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 JWT를 단독 개념으로 외우기보다 어떤 병목을 줄이기 위한 선택인지 먼저 따져야 한다. 특히 OpenID Connect 수준의 기본 대책으로 충분한지, 아니면 JWT가 제공하는 메커니즘이 실제로 필요한지 구분해야 한다. 이후 확장 단계에서는 X.509 v3 디지털 인증서 표준 규격와 같은 후속 기술, 자동화 체계, 표준 호환성까지 함께 검토해야 한다.

실무 체크리스트

현재 문제의 핵심이 가시성 부족인지, 관리 자동화 악화인지 먼저 분리한다.
JWT가 추가하는 복잡도와 운영 이득이 균형을 이루는지 확인한다.
도입 후에는 인접 기술인 X.509 v3 디지털 인증서 표준 규격와의 연계 방식을 함께 검증한다.

안티패턴

JWT의 장점만 보고 트래픽 패턴이나 운영 비용을 무시한 채 과도 도입하는 설계
OpenID Connect와의 경계를 정리하지 않아 중복 투자나 정책 충돌을 만드는 설계
📢 섹션 요약 비유: JWT를 실제로 쓰는 판단은 도구 상자를 고르는 일과 비슷하다. 좋아 보이는 도구보다 지금 문제에 맞는 도구가 중요하다.

Ⅴ. 기대효과 및 결론

구분	세션(Session) 기반 아키텍처	JWT 기반 아키텍처	개선 효과
정량 (인프라 비용)	세션 공유를 위해 Redis 클러스터 유지 비용 수천만 원	서버 메모리/DB 의존 0 (Stateless 연산만 수행)	인증 캐시 메모리 유지 인프라 비용 100% 절감
정량 (성능/지연)	로그인 사용자 10만 명 몰리면 Session DB 조회 병목(수백 ms)	분산 서버 각자가 CPU 연산으로 서명 확인(수십 µs)	인증 로직 지연 속도 10배 이상 단축
정성 (개발 확장성)	웹, 모바일 앱, 외부 파트너사 API마다 인증 로직 별도 구현	모든 이기종 환경이 `Authorization: Bearer` 헤더 표준 하나로 통일	프론트엔드/백엔드/클라우드 통신 범용성 및 유연성 극대화

미래 전망 및 진화 방향

비대칭키(RS256) 기반 글로벌 파트너십 확장: 우리 회사 안에서만 JWT를 쓰면 대칭키(HS256) 하나로 충분하지만, 우리 토큰을 외부 파트너사도 검증하게 하려면 비밀키를 넘겨줄 수 없다. 따라서 발급(서버)은 공개 안 된 '개인키(Private Key)'로 하고, 검증(파트너사)은 누구나 받을 수 있는 '공개키(Public Key)'로 하는 비대칭키 JWT 융합(RS256, ES256 등)이 현대 B2B, 오픈 API 환경의 대세로 군림하고 있다.
JWE (JSON Web Encryption): JWT의 내용물이 평문으로 노출된다는 단점을 보완하기 위해, 아예 페이로드 자체를 강력한 암호 덩어리로 찌그러뜨리는 JWE 규격이 있다. 극도로 민감한 금융/의료 페이로드를 담아야 하는 제로 트러스트 구간에서 부분적으로 채택이 늘고 있다.

참고 표준

RFC 7519: JSON Web Token (JWT) 기본 기술 규격
RFC 7515: JSON Web Signature (JWS) - JWT의 서명 방식을 구체화한 규격
RFC 7516: JSON Web Encryption (JWE) - 암호화 규격

인터넷이라는 방대한 대양을 항해할 때, 모든 배가 지날 때마다 본부에 전화를 걸어 허가를 구한다면 통신망은 마비될 것이다. JWT는 뱃사공에게 위조 불가능한 항해 증명서를 쥐여주고 각자가 알아서 검문을 통과하게 만든 극강의 분산 철학이다. JWT는 단순한 문자열이 아니라 클라우드 스케일아웃(Scale-out) 시대를 지탱하는 가장 거대한 주춧돌이다.

📢 섹션 요약 비유: 식당 직원이 주문받을 때마다 사장님께 전화(DB)해서 "이 사람 VIP 맞아요?"라고 물어보던 시대가 끝나고, 손님 이마에 사장님만 찍을 수 있는 빛나는 투명 도장(JWT)을 쾅 찍어줘서 직원 누구나 도장만 슬쩍 확인하고 VIP 대우를 해주는 눈부시게 빠른 세상이 열린 것입니다.

📌 관련 개념 맵

개념	연결 포인트
OpenID Connect	현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
DNS (Domain Name System)	이름과 주소를 연결해 서비스 접근성을 만든다.
모니터링 (Monitoring)	장애 징후를 조기에 발견하기 위한 기초다.
X.509 v3 디지털 인증서 표준 규격	현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: OpenID Connect]
    │
    ▼
[현재 개념: JWT]
    │
    ├──▶ [확장 A: X.509 v3 디지털 인증서 표준 규격]
    └──▶ [확장 B: 자율 운영 네트워크]

JWT는 OpenID Connect에서 출발해 현재 메커니즘을 정교화하고, 이후 X.509 v3 디지털 인증서 표준 규격와 자율 운영 네트워크 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

👶 어린이를 위한 3줄 비유 설명

예전에는 놀이공원 입구에서 표를 사면, 바이킹이나 범퍼카를 탈 때마다 직원이 매표소에 전화해서 "얘 표 산 거 맞아요?"라고 물어봐야 해서 줄이 엄청나게 밀렸어요.
그래서 나온 아이디어가 JWT예요! 매표소에서 내 팔목에 절대 씻기지 않는 마법의 특수 야광 도장(서명)을 쾅 찍어주는 거죠.
이제 놀이기구 직원들은 전화(서버 확인)할 필요 없이 특수 손전등으로 내 팔목 도장만 비춰보면 진짜인지 알 수 있어서, 수백만 명이 와도 1초 만에 씽씽 놀이기구를 탈 수 있답니다!