쉬운 설명
전통적인 세션 방식은 서버가 사용자별 세션 ID를 메모리·DB에 저장해 두고, 매 요청마다 그 ID로 사용자를 찾아옵니다. 서버를 여러 대 운영하거나 서버리스에서는 다소 무겁습니다. JWT는 사용자 정보 자체를 토큰 안에 담고 서버 비밀 키로 서명해 두는 방식입니다.
구조는 세 부분 — 헤더, 페이로드, 서명 — 이 점(.)으로 이어져 있습니다. 페이로드 안에 'userId: 42, role: editor, exp: 만료시각'처럼 정보가 평문으로(Base64 인코딩) 들어가고, 마지막 서명이 그 내용을 누구도 변조하지 못하게 보증합니다. 클라이언트가 토큰을 보관하고, 매 요청에 Authorization 헤더로 함께 보냅니다.
동작 흐름은 다섯 단계입니다. ① 사용자 로그인 → ② 서버가 비밀 키로 서명한 JWT 발급 → ③ 클라이언트가 토큰을 저장(쿠키·localStorage) → ④ 매 요청에 'Authorization: Bearer <token>'으로 함께 보냄 → ⑤ 서버는 서명만 검증하면 즉시 사용자를 인식. DB 조회가 필요 없어 응답이 빠르고, 여러 서버로 확장이 쉽습니다.
자주 혼동되는 두 가지. 첫째, JWT는 암호화가 아니라 서명입니다. 즉 내용은 누구나 볼 수 있고, 변조만 막힙니다. 그래서 페이로드에 민감 정보를 담으면 안 됩니다. 둘째, JWT는 '서버가 즉시 무효화하기 어렵다'는 단점이 있습니다. 발급 후엔 만료까지 유효하기 때문에, 로그아웃 즉시 차단이 중요한 시스템은 짧은 만료(15분~1시간) + 갱신 토큰(refresh token)을 함께 쓰거나, 차단 목록(blocklist)을 별도로 관리합니다.
쓰지 말아야 하는 곳도 있습니다. 보안 요구가 매우 높은 시스템(금융·의료) — 즉시 무효화·세션 추적이 필요하면 전통적인 세션이 더 안전합니다. JWT의 가장 큰 가치는 '서버 간 신원 전달' — API 게이트웨이 뒤의 여러 서비스가 같은 토큰을 검증해 사용자를 인식하는 마이크로서비스 아키텍처에서 진가가 드러납니다.
비유로 보면
JWT는 콘서트의 손목 밴드와 비슷합니다. 입장 시 한 번 발급받으면, 그 뒤로는 어느 구역에 가든 손목 밴드만 보여 주면 직원이 즉시 통과시켜 줍니다. 매번 입장권 발급기에 다시 가지 않아도 됩니다. 단점은 콘서트 도중에 환불·퇴장 처리를 해도 손목 밴드를 풀기 전까지는 그 사람이 계속 입장한 상태로 보인다는 점입니다.
어디에서 만나나
모바일 앱과 서버 통신, 마이크로서비스 사이의 인증 전달, OAuth/OIDC의 ID 토큰, 사이드프로젝트·SaaS의 일반적인 로그인. Auth0·Clerk·Supabase Auth·Firebase Auth 같은 인증 서비스 대부분이 JWT 기반으로 동작합니다.
작은 예시
로그인하면 서버가 'user_id=42, exp=1h 후'가 담긴 JWT를 발급합니다. 브라우저는 그 토큰을 저장해 두고 매 API 호출의 헤더에 'Authorization: Bearer <token>'으로 함께 보냅니다. 서버는 토큰의 서명만 확인하면 즉시 'user 42'로 인식할 수 있고, DB 조회가 필요 없습니다.
자주 하는 오해
한 줄 정리
JWT의 가치는 '서버가 매번 DB를 안 봐도 사용자를 인식한다'에 있습니다. 그 가치는 마이크로서비스·서버리스에서 가장 잘 드러나고, 단순한 단일 서비스에는 과한 선택일 수 있습니다.