JWT란 무엇인가? 로그인 상태를 유지하는 토큰의 구조

JWT란 무엇이며 왜 현대 웹 서비스의 핵심인가

우리가 매일 사용하는 웹사이트나 모바일 앱에서 로그인을 한 번 하면, 브라우저를 끄거나 앱을 다시 실행해도 계속 로그인 상태가 유지되는 경험을 해보셨을 겁니다. 매번 아이디와 비밀번호를 입력하지 않아도 되는 이 편리함 뒤에는 ‘JWT(JSON Web Token)’라는 기술이 숨어 있습니다. JWT는 웹 표준으로서 정보를 안전하게 전달하고, 사용자의 인증 상태를 유지하는 데 사용되는 가장 대중적인 방법 중 하나입니다.

과거에는 서버가 세션이라는 데이터를 메모리에 저장하고, 사용자가 요청을 보낼 때마다 이를 확인하는 방식을 주로 사용했습니다. 하지만 사용자가 수백만 명으로 늘어나면 서버의 메모리 부담이 커지고, 여러 대의 서버를 운영할 때 세션 정보를 동기화하는 것이 매우 복잡해집니다. 이러한 문제를 해결하기 위해 등장한 것이 바로 JWT입니다. JWT는 별도의 서버 저장소 없이 토큰 자체에 필요한 정보를 담아 클라이언트(사용자 기기)에 저장하기 때문에 확장성이 매우 뛰어납니다.

JWT의 구조를 이해하면 보안이 보인다

JWT는 점(.)으로 구분된 세 가지 부분으로 구성되어 있습니다. 이 구조를 이해하면 토큰이 어떻게 작동하는지 명확하게 알 수 있습니다.

• 헤더(Header): 토큰의 타입(JWT)과 사용된 암호화 알고리즘(예: HMAC SHA256) 정보를 담고 있습니다.

• 페이로드(Payload): 실제로 전달하고자 하는 데이터가 담겨 있습니다. 사용자 ID, 권한 정보, 토큰의 만료 시간 등이 포함됩니다. 다만, 누구나 내용을 읽을 수 있으므로 비밀번호와 같은 민감한 개인정보는 절대 넣지 않아야 합니다.
• 서명(Signature): 헤더와 페이로드를 서버가 가진 비밀키로 암호화한 값입니다. 이 서명이 있어야 서버는 토큰이 위변조되지 않았음을 증명할 수 있습니다.

이 세 부분을 합치면 xxxxx.yyyyy.zzzzz 형태의 긴 문자열이 됩니다. 서버는 사용자가 보낸 토큰의 서명을 자신의 비밀키로 다시 계산해보고, 기존 서명과 일치하는지 확인하는 것만으로 사용자를 인증합니다.

실생활에서의 활용 예시와 작동 원리

사용자가 로그인을 시도하면 서버는 아이디와 비밀번호를 확인한 후 JWT를 발급합니다. 클라이언트는 이 토큰을 웹 브라우저의 로컬 스토리지나 쿠키에 저장합니다. 이후 사용자가 게시글을 작성하거나 마이페이지를 조회할 때마다, 클라이언트는 HTTP 헤더에 이 토큰을 포함하여 서버에 보냅니다.

서버는 데이터베이스를 조회할 필요 없이 토큰만 해독하여 “아, 이 사람은 ID가 123번인 김철수님이구나”라고 즉시 판단합니다. 이러한 구조 덕분에 서버는 상태를 유지할 필요가 없는 ‘Stateless(무상태)’ 환경을 구축할 수 있고, 이는 곧 서버 운영 비용 절감과 서비스 속도 향상으로 이어집니다.

JWT 사용 시 주의해야 할 보안 팁

JWT는 편리하지만, 잘못 사용하면 큰 보안 구멍이 될 수 있습니다. 다음은 전문가들이 권장하는 실용적인 보안 지침입니다.

• 민감 정보 포함 금지: 페이로드는 Base64 방식으로 인코딩되어 있을 뿐 암호화된 것이 아닙니다. 따라서 누구든 복호화가 가능하므로 주민등록번호, 비밀번호 등은 절대 포함해서는 안 됩니다.

• HTTPS 사용 필수: 토큰이 네트워크를 통해 전송될 때 해커가 가로챌 수 있습니다. 반드시 HTTPS를 사용하여 통신 구간을 암호화해야 합니다.
• 만료 시간 설정: 토큰이 영원히 유효하다면 탈취당했을 때 치명적입니다. Access Token은 짧게(예: 30분), Refresh Token은 길게(예: 2주) 설정하여 주기적으로 토큰을 갱신하는 전략이 필요합니다.
• Refresh Token 활용: Access Token이 만료되었을 때, 사용자를 다시 로그인시키지 않고 서버에 저장된 Refresh Token을 통해 새로운 Access Token을 발급받는 방식을 사용하세요.

흔한 오해와 사실 관계 바로잡기

많은 개발자와 사용자가 JWT에 대해 오해하는 부분들이 있습니다.

오해 1: JWT는 암호화되어 있어 안전하다

사실은 그렇지 않습니다. 서명(Signature)은 데이터의 무결성을 보장하기 위한 것이지, 내용을 숨기기 위한 암호화가 아닙니다. 따라서 중요한 데이터는 반드시 서버 내부에서 처리해야 합니다.

오해 2: 로그아웃을 구현하기 어렵다

JWT는 서버에 상태를 저장하지 않기 때문에, 토큰이 만료되기 전까지는 강제로 무효화하기가 어렵습니다. 이를 해결하기 위해 로그아웃한 토큰을 블랙리스트(Blacklist) 데이터베이스에 저장하여 서버가 요청을 받을 때마다 확인하는 방식을 사용합니다.

오해 3: 쿠키보다 로컬 스토리지에 저장하는 것이 좋다

상황에 따라 다릅니다. 로컬 스토리지는 자바스크립트로 접근이 가능하여 XSS(Cross-Site Scripting) 공격에 취약할 수 있습니다. 반면, HttpOnly 속성이 설정된 쿠키는 자바스크립트로 접근할 수 없어 보안상 더 안전할 수 있습니다. 서비스의 특성에 맞는 저장소를 선택해야 합니다.

자주 묻는 질문과 답변

Q: 토큰이 해킹당하면 어떻게 되나요?

A: 토큰이 탈취되면 해커가 본인인 것처럼 행세할 수 있습니다. 이를 방지하기 위해 토큰의 만료 시간을 짧게 유지하고, 이상 감지 시스템(예: 갑자기 해외 IP에서 접속)을 통해 토큰을 강제 폐기하는 로직을 마련해야 합니다.

Q: 세션과 JWT 중 무엇이 더 좋은가요?

A: 정답은 없습니다. 소규모 서비스이며 서버 관리가 간단한 환경이라면 세션이 더 쉽고 안전할 수 있습니다. 반면, 모바일 앱과 웹을 동시에 지원하거나 마이크로서비스 아키텍처(MSA)를 사용하는 경우 JWT가 훨씬 효율적입니다.

Q: JWT의 크기가 커지면 성능에 영향을 주나요?

A: 페이로드에 너무 많은 정보를 담으면 토큰의 길이가 길어집니다. 모든 요청마다 이 긴 토큰이 전송되므로 대역폭을 낭비할 수 있습니다. 필요한 최소한의 정보(사용자 식별자, 권한)만 담는 것이 좋습니다.

비용 효율적인 활용과 아키텍처 설계

JWT를 적절히 활용하면 서버 인프라 비용을 크게 줄일 수 있습니다. 데이터베이스 조회 횟수가 줄어들기 때문입니다. 특히 클라우드 환경에서 서버를 자동 확장(Auto-scaling)할 때, 세션 동기화를 위한 별도의 Redis 서버 비용을 절약할 수 있다는 점은 큰 장점입니다.

개발 초기에는 단순한 인증 체계로 시작하되, 서비스가 커질수록 토큰의 발급과 갱신 과정을 분리하세요. 인증 서버를 별도로 두어 토큰을 관리하면 서비스 간의 결합도를 낮추고 유지보수가 쉬워집니다. 또한, 토큰 검증 로직을 API 게이트웨이 단계에서 수행하도록 설계하면, 개별 마이크로서비스들의 부하를 획기적으로 줄일 수 있습니다.

결국 JWT는 단순한 기술을 넘어, 현대적인 웹 서비스가 가져야 할 ‘확장성’과 ‘사용자 경험’을 동시에 잡기 위한 필수 도구입니다. 보안 수칙을 준수하고 올바른 아키텍처를 설계한다면, 사용자와 서비스 제공자 모두에게 만족스러운 인증 시스템을 구축할 수 있을 것입니다.