JWT 인증이란? 실무 정리: 구조·원리·장단점부터 보안까지

최종 수정일: 2026년 08월 07일

JWT(JSON Web Token)는 사용자 정보와 권한을 토큰 안에 담아 서버가 상태를 저장하지 않고(stateless) 인증을 처리하는 RFC 7519 표준 방식으로, 분산·마이크로서비스 환경에서 수평 확장에 강합니다. 다만 페이로드는 암호화가 아니라 디코딩되면 내용이 보이므로 민감 정보를 넣으면 안 되고, 한 번 발급되면 즉시 무효화가 어렵다는 한계가 있습니다. 그래서 짧은 액세스 토큰 + 리프레시 토큰(회전 적용), HTTPS 전송, alg:none 차단 같은 보안 설계가 함께 가야 합니다.
‘사용자 인증’은 제가 여러 웹 서비스를 만들고 개선하는 과정에서 늘 중요하게 봤던 영역입니다. 사용자 데이터를 안전하게 지키면서도 서비스는 편리하게 쓰게 만드는 것, 이게 생각보다 늘 큰 숙제입니다. 특히 2018년에 팀에서 분산 마이크로서비스 아키텍처 도입 프로젝트를 시작했을 때, 기존 세션 기반 인증만으로는 한계를 꽤 뚜렷하게 느꼈습니다.

그 무렵 JWT 인증을 깊게 파고들어 실제 시스템에 적용해 보면서, 이 방식이 얼마나 강력하고 유연한지 체감했습니다. JWT는 단순한 기술 선택을 넘어, 사용자 경험과 시스템 확장성이라는 두 가지를 같이 챙길 수 있는 열쇠에 가깝습니다.

이 글에서는 현장에서 쌓은 경험을 바탕으로, 쉽게 JWT가 무엇인지, 어떻게 작동하는지, 장단점은 무엇인지, 그리고 어떻게 안전하게 활용할 수 있는지 정리해 드리겠습니다. JWT 인증이 왜 현대 웹 환경에서 자주 등장하는지, 그 이유가 좀 더 또렷해질 겁니다.

JWT 인증 이해

JWT 인증이란 무엇인가요?

JWT(JSON Web Token)는 ‘JSON 형태로 된 웹 토큰’을 뜻하며, 인터넷을 통해 사용자 정보를 안전하게 주고받기 위한 표준화된 방법입니다. RFC 7519라는 국제 표준으로 제정되어 전 세계 개발자들이 같은 규칙으로 활용합니다.

JWT의 핵심 특성은 두 가지입니다. 컴팩트하고, 자체 포함(self-contained)되어 있다는 점입니다. 컴팩트하다는 건 토큰 크기가 비교적 작아 네트워크로 빠르게 주고받을 수 있다는 뜻이고, 자체 포함은 토큰 안에 사용자 정보와 권한 같은 필요한 내용이 들어 있다는 의미입니다. 그래서 서버가 사용자 정보를 별도로 저장하지 않아도 되는 구조가 됩니다. 동시 처리량이 늘어나는 이유도 여기서 나옵니다.

그렇다면 JWT는 어떻게 안전함을 확보할까요? 답은 ‘디지털 서명’입니다. 서명 덕분에 토큰 내용이 중간에 바뀌지 않았는지, 즉 무결성을 확인할 수 있습니다. 봉인 스티커를 떠올리면 이해가 빠릅니다. 이 봉인은 비밀키(secret key) 또는 공개키-개인키 쌍으로 만들어집니다.

주로 로그인 같은 인증(Authentication) 과정이나, 서버 간 정보 교환(Information Exchange)에 활용됩니다. 예를 들어 온라인 강의 플랫폼에 로그인하면 서버가 JWT를 발급해 주고, 이후 강의 시청이나 게시판 이용 때마다 매번 로그인하지 않아도 됩니다. 토큰에 사용자 식별 정보와 권한이 들어 있기 때문입니다.

JWT는 URL 안전(URL-safe)하게 인코딩된다는 특징도 있습니다. 그래서 URL, HTTP 요청 헤더, 쿠키 등 다양한 방식으로 전송할 수 있습니다. 모바일 앱이나 SPA(Single Page Application)에서도 자주 쓰이는 이유가 여기 있습니다. 프론트엔드와 백엔드가 서로 다른 도메인에 있을 때 생기는 CORS 문제를 다루는 데도 JWT가 편한 편입니다. 실제로 초기 프로젝트에서 CORS 때문에 일정이 밀리던 상황에서 JWT가 꽤 도움이 됐던 기억이 있습니다.

그리고 JWT는 stateless(무상태) 특성을 가집니다. 서버가 사용자 상태를 저장하지 않아도 됩니다. 토큰 안에 정보가 있으니 서버는 토큰 유효성만 확인하면 됩니다. 분산 환경에서는 이게 강점으로 크게 작동합니다. 트래픽이 몰려 서버를 증설해야 할 때, 새로 붙은 서버도 별도 세션 공유 없이 바로 요청을 처리할 수 있습니다. NIST(미국 국립표준기술연구소)도 JWT를 안전한 인증 방식으로 인정하고 있습니다.

JWT 토큰은 어떤 구조로 되어 있나요?

JWT는 세 부분으로 나뉘며 점(.)으로 구분됩니다. 형태는 Header.Payload.Signature 입니다. 겉으로는 긴 문자열처럼 보이지만, Base64Url 인코딩 결과입니다. 각 부분의 역할을 알면 JWT가 훨씬 선명해집니다.

Header(헤더)는 토큰의 머리말입니다. 토큰 타입(typ)과 서명 알고리즘(alg)이 들어갑니다. 예를 들어 {"alg":"HS256","typ":"JWT"} 같은 JSON이 Base64Url로 인코딩되어 담깁니다. 서버는 이 정보를 보고 어떤 방식으로 검증할지 판단합니다.

Payload(페이로드)는 본문입니다. 여기 들어가는 정보가 클레임(claims)입니다. 클레임은 사용자나 데이터에 대한 속성 정보라고 보면 됩니다. 클레임은 보통 세 가지로 나뉩니다.

1. 등록된 클레임(Registered claims): 표준에서 미리 정한 항목입니다. 예를 들면 iss, exp, sub, aud 등이 있습니다. 특히 exp는 보안과 직결되는 핵심입니다.
2. 공개 클레임(Public claims): 자유롭게 만들 수 있지만, 이름 충돌을 피하려면 등록하거나 URL 형태로 정의하는 방식이 권장됩니다.
3. 비공개 클레임(Private claims): 발급자와 사용자(서버-클라이언트)가 합의해 정하는 항목입니다. 역할(관리자 여부)이나 서비스 접근 권한 같은 정보가 여기에 들어갑니다.

여기서 꼭 짚고 넘어가야 할 경고가 있습니다. OWASP는 다음을 강하게 권고합니다.

OWASP 권고에 따르면, JWT 페이로드는 Base64 인코딩일 뿐 암호화가 아니므로 주민등록번호·비밀번호 같은 민감 정보를 직접 넣어서는 안 됩니다.

JWT의 페이로드는 암호화가 아닙니다. 토큰을 얻으면 누구나 디코딩해서 내용을 볼 수 있다는 뜻입니다. 이 부분은 실무에서 사고로 이어지기 쉬워서 더 조심해야 합니다.

Signature(서명)는 봉인 스티커이자 위조 방지 장치입니다. 인코딩된 헤더와 페이로드에 서버만 아는 비밀키(secret key)를 더해, 헤더에 지정된 알고리즘으로 서명을 만듭니다. 토큰 내용이 조금이라도 바뀌면 서버가 재계산한 서명과 일치하지 않기 때문에 변조를 감지할 수 있습니다. 실제로 비밀키 관리가 느슨하면 테스트 토큰이 새어 나갈 뻔한 상황도 생깁니다. 키 관리는 과할 정도로 보수적으로 가는 게 맞습니다.

Base64Url 인코딩은 일반 Base64와 달리 URL에 문제를 일으키는 문자(+, /, =)를 –, _로 바꾸거나 제거합니다. JWT 크기는 보통 200~500바이트 수준이며, 세션 ID(32~128바이트)보다 큰 편이라는 점도 같이 기억해 두면 좋습니다.

JWT 인증 원리

JWT 토큰 인증 방식

JWT 토큰 인증은 클라이언트와 서버가 토큰을 주고받으며 사용자임을 확인하고 권한을 부여하는 흐름입니다. 크게 세 단계로 나뉩니다.

1. 토큰 발급: 사용자가 아이디, 비밀번호를 제출하면 서버가 확인 후 JWT를 생성해 서명하고 전달합니다. 사용자는 토큰을 안전한 곳에 저장합니다.
2. 토큰 전송: 이후 요청마다 JWT를 HTTP 요청의 Authorization 헤더에 담아 보냅니다. 보통 Bearer 방식입니다.
3. 토큰 검증: 서버는 서명, 만료 시간, 발급자 등 유효성을 확인하고 변조 여부를 검사합니다. 문제가 있으면 요청을 거부합니다.

토큰 발급 단계에서는 서버가 자격 증명을 DB 정보와 비교해 본인 확인을 합니다. 확인이 되면 사용자 ID, 역할, 만료 시간 같은 정보를 담아 JWT를 만들고 비밀키로 서명합니다. 클라이언트는 이를 로컬 스토리지, 세션 스토리지, 쿠키 등에 저장합니다.

토큰 전송 단계에서는 요청마다 Authorization: Bearer <토큰> 형태로 보냅니다. RFC 6750에서 말하듯, Bearer 토큰은 “가진 사람이 쓰는 토큰”입니다. 즉, 탈취되면 그 권한으로 접근이 가능해집니다. 그래서 전송과 저장이 더 중요해집니다.

토큰 검증 단계에서는 서명 확인뿐 아니라 iss, aud, exp 같은 클레임도 같이 봐야 합니다. 서명은 서버가 같은 방식으로 재계산해 일치 여부로 판단합니다. 만료 시간(exp), 발급 시간(iat), 유효 시작(nbf)도 빠지면 안 됩니다.

JWT가 빛나는 이유는 stateless(무상태) 특성입니다. 서버가 매번 DB를 뒤져 사용자 상태를 찾지 않아도 됩니다. 토큰만으로 사용자와 권한을 판단할 수 있으니 수평 확장이 쉬워집니다. 마이크로서비스 환경에서 JWT가 자주 선택되는 이유도 결국 여기로 모입니다.

JWT 토큰 갱신

JWT 토큰 갱신은 도서관의 단기 대출증과 장기 회원카드로 비유하면 이해가 빠릅니다. 실제 접근에 쓰는 액세스 토큰(Access Token)은 짧게, 만료되면 리프레시 토큰(Refresh Token)으로 새 액세스 토큰을 받는 구조입니다. 토큰 탈취 위험을 줄이면서도 사용자는 로그인 상태를 유지할 수 있게 만드는 방식입니다.

액세스 토큰은 보통 15분에서 1시간 정도로 짧게 잡습니다. 짧을수록 탈취 시 피해 시간이 줄어듭니다. 다만 너무 자주 만료되면 사용자 불편이 커지니, 그 균형을 리프레시 토큰이 잡아줍니다. 리프레시 토큰은 만료 시간이 길고, 새 액세스 토큰 발급 용도로만 씁니다. RFC 6749에서도 리프레시 토큰을 “새 액세스 토큰을 얻기 위한 자격 증명”으로 정의합니다.

리프레시 토큰은 보통 HttpOnly 쿠키에 저장해 XSS로부터 보호합니다. 반대로 액세스 토큰은 메모리나 상태 관리 영역에 두고 Authorization 헤더로 보내는 패턴이 흔합니다.

보안을 더 강화하려면 토큰 회전(Refresh Token Rotation)을 적용합니다. 리프레시 토큰이 한 번 쓰이면 즉시 무효화하고, 새 리프레시 토큰을 다시 발급하는 방식입니다. 탈취된 토큰의 재사용을 막는 데 효과적입니다.

JWT는 무상태 특성 때문에 즉시 무효화가 어렵다는 단점이 있습니다. 그래서 토큰 블랙리스트를 운영하는 경우도 있는데, 이건 무상태 장점을 일부 포기하는 선택입니다. 운영 부담도 늘어납니다. 실무에서는 짧은 액세스 토큰과 안전한 리프레시 토큰(회전 적용)을 조합해 블랙리스트 없이 운영하는 방식이 많이 쓰입니다.

JWT 인증 특징

JWT 장점

JWT는 웹과 모바일 앱에서 널리 쓰이는 인증 방식입니다. 특히 분산 시스템에서 장점이 더 잘 드러납니다. 제가 여러 프로젝트에서 가장 크게 체감한 건 stateless(무상태) 특성입니다. 서버가 로그인 상태를 기억하지 않으니 메모리 부담이 줄고, 수평 확장이 쉬워집니다. 2021년에 대규모 온라인 시험 시스템을 만들 때도 트래픽이 튀는 상황에서 이 특성이 꽤 든든하게 작동했습니다.

주요 장점은 아래와 같습니다.

• Stateless(무상태) 특성: 서버 상태 저장 불필요, 수평 확장 쉬움
• 자체 포함(self-contained): DB 조회 없이 권한 판단 가능, 응답 속도 개선 여지 큼
• CORS 문제 대응에 유리: Authorization 헤더 전송 기반, 도메인 제약이 상대적으로 덜함
• 모바일 앱에 유리: 쿠키 의존 낮음, 구현 단순해짐
• 마이크로서비스에 적합: 서비스별 독립 검증 가능, 인증 교환 단순화
• 라이브러리 풍부: 언어/프레임워크 지원 폭 넓음, 표준 기반 상호 운용성 좋음
• SSO 구현 용이: 한 번 로그인으로 여러 서비스 접근 가능

JWT는 자체 포함 방식이라 서버가 매 요청마다 DB를 조회하지 않아도 됩니다. 자체 포함 방식이라 매 요청마다 DB를 조회하지 않아도 되므로, 응답 시간과 서버 부담 측면에서 이점이 있습니다. 다만 이건 “토큰에 무엇을 얼마나 담느냐”에 따라 체감이 달라집니다.

CORS 관점에서도 JWT는 편합니다. 쿠키는 도메인 제약이 강한 편이라 구조가 복잡해질 수 있는데, JWT는 헤더로 보내는 패턴이 많아 상대적으로 유연합니다. 프론트와 백이 다른 도메인에 있거나 서브도메인이 많은 서비스에서 특히 그렇습니다.

모바일 환경에서도 JWT는 자주 선택됩니다. 쿠키 지원이 애매하거나 관리가 복잡한 경우가 많기 때문입니다. 토큰을 안전한 저장소에 두고 헤더로 보내는 방식이 구현 측면에서 깔끔하게 떨어집니다.

마이크로서비스에서는 각 서비스가 토큰을 독립적으로 검증할 수 있다는 점이 큽니다. 중앙 인증 서버 의존도를 낮추고, 서비스별 배포와 확장도 유연해집니다.

다만 “완벽한 인증 기술”이라고 단정하기는 어렵습니다. 장점이 분명한 만큼, 단점과 운영 리스크도 같이 봐야 합니다.

JWT 단점

JWT는 장점이 많지만 단점과 보안 위험도 분명합니다. 운영 환경에서는 이 부분이 더 중요해지는 경우가 많습니다.

첫 번째는 토큰 크기입니다. 세션 ID보다 커지는 경우가 많고, 요청마다 토큰이 같이 전송되니 네트워크 오버헤드가 생깁니다. 특히 모바일처럼 데이터가 제한적인 환경에서는 체감이 커질 수 있습니다.

두 번째는 토큰 불변성(Immutability)입니다. 한 번 발급된 JWT는 서버에서 내용을 바꿀 수 없습니다. 사용자 권한이 바뀌거나 계정이 비활성화돼도, 토큰이 만료되기 전까지는 이전 권한이 남아 있을 수 있습니다.

세 번째는 즉시 무효화가 어렵다는 점입니다. 무상태 구조라 서버가 토큰 상태를 추적하지 않기 때문입니다. 그래서 짧은 만료 시간, 리프레시 토큰, 블랙리스트 같은 보완책이 필요해집니다. 블랙리스트는 운영 부담이 늘고, 무상태 장점을 일부 포기하는 선택이기도 합니다.

네 번째는 페이로드가 암호화가 아니라는 점입니다. Base64 인코딩일 뿐이라 디코딩하면 내용이 보입니다. 민감 정보는 절대 넣으면 안 됩니다.

그리고 JWT 관련 취약점(CVE)도 꾸준히 보고됩니다. 알고리즘 혼동 공격처럼 구현 실수로 터지는 이슈가 대표적입니다.

마지막으로 저장 방식에 따른 보안 위험도 큽니다. 로컬 스토리지 저장은 XSS에 취약해질 수 있고, 쿠키 저장은 설정에 따라 CSRF 이슈가 생길 수 있습니다. HttpOnly, Secure, CSRF 토큰 병행 같은 기본기를 제대로 챙겨야 합니다.

JWT 보안

JWT는 강력한 만큼, 보안은 “한 방”으로 해결되지 않습니다. 생성, 전송, 저장, 검증 전 과정에서 여러 겹으로 막아야 합니다. 실무에서는 이 관점이 중요합니다.

첫째, 강력한 서명 알고리즘을 써야 합니다. NIST 권고처럼 최소 SHA-256 이상을 기준으로 잡는 게 일반적입니다. HS256, RS256 같은 알고리즘을 선택할 때도 서비스 구조에 맞춰야 합니다.

둘째, 알고리즘 혼동 공격 방지가 핵심입니다. 특히 alg: none 허용은 금물입니다.

JWT 구현 시 alg: none 알고리즘을 절대로 허용해서는 안 되며, 이는 서명 없이 토큰을 수락하게 되어 심각한 보안 취약점을 초래한다.

서버는 토큰 헤더의 alg를 그대로 믿지 말고, “우리 서버는 이 알고리즘만 받는다”를 코드로 고정해야 합니다.

셋째, 비밀키(secret key) 관리는 기본 중 기본입니다. 키 길이, 랜덤성, 보관 위치가 모두 중요합니다. 환경 변수나 전용 키 관리 시스템을 쓰는 방식이 현실적입니다.

넷째, HTTPS/TLS 전송은 전제 조건입니다. HTTP로 토큰을 주고받는 순간 중간자 공격에 취약해집니다.

다섯째, 만료 시간(exp) 설계가 필요합니다. 너무 길면 탈취 시 피해가 커지고, 너무 짧으면 사용자 불편이 커집니다. 액세스 토큰은 짧게, 리프레시 토큰은 길게가 기본 패턴입니다.

여섯째, JTI(JWT ID) 같은 식별자 클레임을 활용하면 토큰 추적과 재사용 공격 방지에 도움이 됩니다.

일곱째, 검증 라이브러리는 검증된 것을 쓰는 게 안전합니다. 직접 구현하면 서명 검증, 만료 확인, 발급자 검증 같은 필수 단계를 빠뜨리기 쉽습니다.

마지막으로, 정말 민감한 정보를 토큰에 넣어야 한다면 JWE(JSON Web Encryption, RFC 7516) 같은 방식으로 암호화를 고려할 수 있습니다. 다만 “넣어야만 하는지”부터 다시 점검하는 게 먼저입니다.

JWT와 세션 인증 비교

토큰 기반 인증과 세션 기반 인증은 사용자 확인과 상태 관리를 위한 대표 방식입니다. 어떤 게 더 좋다로 끝나지 않고, 서비스 구조와 요구사항에 따라 선택이 갈립니다. 이 차이를 정확히 잡는 게 설계의 출발점입니다.

가장 큰 차이는 상태 관리 방식입니다. 세션은 서버가 상태를 저장하는 stateful 방식이고, JWT는 서버가 상태를 저장하지 않는 stateless 방식입니다. 동시 접속이 커질수록 서버가 상태를 저장하지 않는 JWT 쪽이 메모리 효율 면에서 유리한 경우가 많습니다.

즉시 무효화는 세션이 유리합니다. 서버에서 세션을 지우면 끝입니다. JWT는 만료 전까지 살아 있으니 보완 설계가 필요합니다.

확장성은 JWT가 유리한 경우가 많습니다. 서버가 상태를 공유하지 않아도 되니 수평 확장이 단순해집니다. 반대로 세션은 sticky session이나 Redis 같은 외부 저장소가 필요해질 수 있습니다.

네트워크 오버헤드는 JWT가 불리할 수 있습니다. 요청마다 토큰이 붙기 때문입니다.

보안은 “어떤 방식이 더 안전하다”보다 “어떻게 저장하고 전송하느냐”가 더 크게 작동합니다. JWT를 쿠키에 저장하면 CSRF 이슈가 생길 수 있고, 로컬 스토리지는 XSS에 취약해질 수 있습니다. 결국 설정과 운영이 승부처입니다.

일반적으로 세션은 전통적인 웹 앱에, JWT는 API 중심 마이크로서비스나 모바일 앱에 더 적합한 것으로 봅니다. 상황에 따라 하이브리드 접근(짧은 JWT + 서버 측 검증 리프레시 토큰)도 충분히 현실적인 선택입니다.

—

FAQ

Q1: JWT 인증에서 ‘stateless’는 정확히 무엇이며, 어떤 장점이 있나요?
A1: stateless는 서버가 클라이언트의 세션 상태를 저장하거나 관리하지 않는다는 의미입니다. 토큰 자체에 사용자 정보와 권한이 포함되므로 서버는 토큰 검증만으로 요청을 처리할 수 있습니다. 그 결과 서버 메모리 부담이 줄고 수평 확장이 쉬워집니다. DB 조회가 줄어 응답 속도 측면에서도 이점이 생길 수 있습니다.

Q2: JWT 토큰의 Header, Payload, Signature는 각각 어떤 역할을 하나요?
A2: JWT는 점(.)으로 구분된 세 부분으로 구성됩니다.

1. Header: 토큰 유형(typ)과 서명 알고리즘(alg) 정보를 담습니다. 서버는 이를 바탕으로 검증 방식을 결정합니다.
2. Payload: 클레임(claims)이라 불리는 사용자 정보와 권한 데이터를 담습니다. iss, exp, sub, aud 같은 표준 클레임과 사용자 정의 클레임이 들어갈 수 있습니다.
3. Signature: 헤더와 페이로드, 비밀키를 특정 알고리즘으로 처리해 만든 서명입니다. 전송 중 변조 여부를 확인하는 무결성 검증 역할을 합니다.

Q3: JWT 페이로드에 민감 정보를 넣으면 안 되는 이유는 무엇이며, 꼭 넣어야 한다면 어떻게 해야 하나요?
A3: 페이로드는 Base64Url 인코딩일 뿐 암호화가 아닙니다. 토큰을 얻으면 누구나 디코딩해 내용을 볼 수 있습니다. 그래서 주민등록번호, 카드 정보 같은 민감 정보는 넣으면 안 됩니다. 정말 불가피하다면 JWE(JSON Web Encryption) 같은 표준으로 페이로드를 암호화하는 방식을 고려할 수 있습니다.

Q4: 토큰 갱신은 왜 필요하며, 액세스 토큰과 리프레시 토큰은 각각 어떤 역할인가요?
A4: 액세스 토큰을 짧게 가져가면 탈취 위험은 줄지만 사용자 불편이 커집니다. 이 불편을 줄이기 위해 리프레시 토큰으로 새 액세스 토큰을 발급받는 갱신 구조를 씁니다.

• 액세스 토큰: 실제 리소스 접근용, 만료 시간 짧게 설정된다
• 리프레시 토큰: 액세스 토큰 재발급용, 만료 시간 길게 설정된다. 보통 HttpOnly 쿠키에 저장해 XSS 위험을 낮춘다

Q5: JWT 인증과 세션 기반 인증의 가장 큰 차이점은 무엇이며, 각각 어떤 상황에 더 적합한가요?
A5: 가장 큰 차이는 상태 관리 방식입니다.

• 세션 기반 인증: 서버가 상태를 저장하는 방식이다. 즉시 무효화가 쉽다. 전통적인 웹 애플리케이션에 적합하다
• JWT 인증: 서버가 상태를 저장하지 않는 방식이다. 확장성이 좋다. API 중심 서비스, 마이크로서비스, 모바일/SPA에 적합한 경우가 많다. 즉시 무효화는 설계로 보완해야 한다

요구사항과 보안 수준에 따라 선택해야 하며, 하이브리드 방식도 충분히 실전적인 대안입니다.