그냥 세션 쓰세요: 'JWT 그만 쓰자'는 주장의 진짜 의미

"JWT 그만 쓰세요"라는 도발

웹 개발 배울 때 거의 통과의례처럼 만나는 게 JWT예요. 로그인 인증 구현한다고 하면 다들 JWT부터 꺼내죠. 그런데 "JWT 좀 그만 쓰자(Stop Using JWTs)"라는 글이 돌면서 다시 논쟁이 붙었어요. 결론부터 말하면 "JWT가 나쁘다"가 아니라 "대부분의 사람들이 JWT를 써야 할 자리가 아닌 곳에 쓰고 있다"는 얘기예요.

JWT가 뭐였더라

먼저 복습부터요. JWT(JSON Web Token)는 사용자 정보를 담아서 서명한 토큰이에요. 이게 뭐냐면, 서버가 "이 사람은 id가 42번이고 권한은 일반회원이야"라는 내용을 적고, 위조 못 하게 서버만 아는 열쇠로 도장(서명)을 찍어서 사용자한테 줘요. 다음부터 사용자가 그 토큰을 들고 오면, 서버는 도장만 확인하면 돼요. 데이터베이스를 안 찾아봐도 토큰 안에 정보가 다 들어있으니까요. 이걸 "상태가 없다(stateless)"고 표현해요. 서버가 누가 로그인 중인지 따로 기억 안 해도 된다는 뜻이죠.

이 stateless가 JWT의 최대 장점으로 홍보돼요. 서버를 여러 대로 늘려도 세션을 공유할 필요가 없으니 확장하기 좋다는 거죠.

진짜 문제는 "로그아웃"이에요

그런데 이 글이 찌르는 핵심 약점이 바로 그 stateless에서 나와요. 토큰 안에 정보가 다 들어있고 서버가 기억을 안 한다는 건, 뒤집어 말하면 한 번 발급한 토큰을 서버가 취소할 방법이 없다는 뜻이거든요.

예를 들어볼게요. 사용자가 "로그아웃" 버튼을 눌렀어요. 혹은 계정이 해킹당해서 강제로 모든 기기에서 로그아웃시켜야 해요. 세션 방식이라면 서버 DB에서 그 세션 한 줄을 지우면 끝이에요. 그런데 JWT는요? 이미 사용자 손에 들어간 토큰은 만료 시간 전까지 계속 유효해요. 서버가 "야 너 이제 로그아웃이야"라고 말할 방법이 없어요.

그래서 결국 어떻게 되냐면, 취소된 토큰 목록(블랙리스트)을 DB에 저장하고 매 요청마다 확인하게 돼요. 그 순간 "DB 안 찾아봐도 된다"던 JWT의 최대 장점이 사라져요. 매번 DB를 찾을 거면, 그냥 처음부터 세션 ID 하나 던져주고 DB에서 찾는 게 더 단순하고 안전하거든요.

그럼 뭘 쓰라는 거냐면

이 글의 대안은 의외로 고전적이에요. "그냥 세션 쓰세요." 임의의 긴 랜덤 문자열(세션 ID)을 쿠키에 담아 주고, 서버는 그 ID로 DB나 Redis에서 사용자 정보를 찾는 방식이요. 토큰 안에 민감한 정보가 안 들어가니 유출 위험도 줄고, 로그아웃은 한 줄 지우면 끝이고, 토큰 크기도 훨씬 작아요. JWT는 base64로 인코딩된 내용이 매 요청마다 따라다녀서 은근히 무겁거든요.

게다가 보안 함정도 많아요. 알고리즘을 none으로 바꿔서 서명 검증을 우회하는 공격, 대칭키와 비대칭키를 헷갈려서 생기는 취약점 등 JWT는 "직접 다루다가 발 헛디디기 쉬운" 스펙이에요.

그래도 JWT가 맞는 자리

물론 JWT가 무조건 나쁜 건 아니에요. 수명이 아주 짧고(몇 분), 여러 독립된 서비스가 한 사용자를 공유해야 하는 상황, 예를 들어 마이크로서비스 사이에서 신원을 잠깐 전달하거나 OAuth 같은 표준 흐름에서는 JWT가 제값을 해요. 핵심은 "기본값으로 JWT를 깔지 말고, 정말 stateless가 필요한 자리에만 쓰라"는 거예요.

한국 개발자에게

신규 프로젝트에서 별생각 없이 JWT로 로그인 세션을 구현하고 있었다면, 한 번쯤 멈춰서 물어보세요. "우리 진짜 stateless가 필요한가? 로그아웃이랑 강제 만료는 어떻게 처리하지?" 대부분의 평범한 웹 서비스는 세션 + 쿠키 조합으로 충분하고, 그게 더 안전하고 단순해요. 멋져 보여서가 아니라 필요해서 고르는 게 좋은 기술 선택이죠.