JWT를 쓰지 말라고요? 다시 불붙은 인증 토큰 논쟁의 진실

웹 서비스를 만들어 본 개발자라면 한 번쯤 JWT(JSON Web Token)를 써봤을 겁니다. 로그인 처리의 거의 표준처럼 굳어진 기술인데요. 그런데 최근 개발자 커뮤니티에서 “이제 JWT 그만 쓰자"는 목소리가 다시 커지고 있습니다. 한때 모두가 칭송하던 기술이 왜 갑자기 공공의 적이 됐을까요.

먼저 솔직하게 말씀드리면, 이 주제는 지난 한 달간 새로 터진 대형 논쟁이라기보다 몇 년째 주기적으로 재점화되는 ‘고전 떡밥’에 가깝습니다. 그래서 이번 글은 특정 최신 스레드보다, 이 논쟁이 왜 계속 돌아오는지 구조 자체를 짚어보려 합니다.

JWT가 대체 뭐길래

JWT를 이해하려면 먼저 옛날 방식을 알아야 합니다. 전통적인 방식은 세션 쿠키입니다. 사용자가 로그인하면 서버가 세션 정보를 자기 메모리나 데이터베이스에 저장합니다. 그리고 사용자에게는 작은 쿠키 하나만 줍니다. 일종의 보관증인 셈이죠.

JWT는 발상을 뒤집었습니다. 서버가 아무것도 저장하지 않습니다. 대신 사용자 정보를 토큰 안에 통째로 담아서 사용자에게 줍니다. 서버는 토큰에 찍힌 서명만 확인하면 됩니다. 보관증 대신 위조 방지 도장이 찍힌 신분증을 들고 다니는 방식입니다.

이 차이가 핵심입니다. 세션은 서버가 기억하고, JWT는 서버가 검증만 합니다. 유튜브에서 90만 회 넘게 재생된 인증 강의들이 하나같이 “쿠키, 세션, 토큰의 차이"부터 설명하는 이유가 여기 있습니다. 이 구분을 모르면 논쟁 자체가 이해되지 않거든요.

왜 다들 JWT에 열광했나

JWT의 가장 큰 매력은 확장성입니다. 서버가 세션을 저장하지 않으니, 서버를 여러 대로 늘려도 골치가 없습니다. 사용자가 A 서버에 로그인했다가 B 서버로 요청이 넘어가도 토큰만 들고 있으면 그만입니다.

마이크로서비스 시대와 궁합이 잘 맞았던 것도 한몫했습니다. 서비스가 잘게 쪼개진 환경에서 모든 서비스가 하나의 세션 저장소를 바라보는 건 부담입니다. 반면 JWT는 각 서비스가 독립적으로 토큰을 검증할 수 있습니다. 모바일 앱, 외부 API 연동에서도 다루기 편했고요.

한마디로 JWT는 ‘서버가 기억하지 않아도 되는’ 자유를 줬습니다. 문제는, 그 자유에 생각보다 비싼 청구서가 따라왔다는 겁니다.

그런데 왜 ‘쓰지 마라’는 말이 나오나

비판의 핵심은 딱 하나로 모입니다. 한 번 발급한 토큰을 취소하기 어렵다는 점입니다.

세션 방식은 간단합니다. 사용자를 강제 로그아웃시키고 싶으면 서버에서 세션 기록만 지우면 끝입니다. 그런데 JWT는 서버가 아무것도 저장하지 않죠. 이미 사용자 손에 들어간 토큰은 만료 시각이 될 때까지 계속 유효합니다. 비밀번호를 바꿔도, 계정을 정지시켜도, 그 토큰은 살아 있습니다.

해커가 토큰을 탈취했다고 생각해 보세요. 세션이라면 즉시 무효화할 수 있지만, JWT는 그러기가 까다롭습니다. 결국 블랙리스트라는 별도 저장소를 두고 “이 토큰은 취소됐다"고 일일이 기록해야 합니다. 그런데 이러면 어떻게 될까요. 서버가 아무것도 저장하지 않는다는 JWT의 최대 장점이 무너집니다. 취소 기능을 위해 결국 세션 비슷한 걸 다시 만드는 셈입니다.

두 번째 비판은 토큰 크기입니다. JWT는 정보를 통째로 담다 보니 쿠키보다 훨씬 큽니다. 모든 요청마다 이 덩치 큰 토큰이 따라다니니 트래픽에 부담이 됩니다.

세 번째는 보안 설정의 함정입니다. JWT는 직접 다뤄야 할 부분이 많습니다. 서명 알고리즘 설정을 잘못하면 토큰 위조에 뚫리는 사례가 실제로 여러 번 보고됐습니다. 강력한 도구일수록 잘못 쥐면 다친다는 거죠.

그래서 세션으로 돌아가야 하나

여기서 균형을 잡아야 합니다. “JWT를 쓰지 마라"는 주장이 곧 “세션이 무조건 옳다"는 뜻은 아닙니다.

비판하는 쪽의 진짜 메시지는 이겁니다. 대부분의 평범한 웹 서비스에는 JWT가 과한 선택이라는 겁니다. 서버 한두 대로 돌아가는 서비스라면 세션 쿠키가 더 단순하고, 더 안전하고, 취소도 쉽습니다. 그런데 많은 개발자가 “요즘 다들 쓰니까” 혹은 “확장성이 좋다니까” 하는 이유로 필요도 없는 JWT를 끌어다 쓴다는 지적입니다.

실제 현업의 타협안도 흥미롭습니다. 많은 서비스가 둘을 섞어 씁니다. 짧게 살아 있는 액세스 토큰(JWT)과, 이를 갱신하는 리프레시 토큰을 함께 쓰는 방식인데요. 액세스 토큰의 수명을 몇 분으로 짧게 잡아서, 탈취되더라도 금방 만료되게 만드는 겁니다. 인기 인증 강의들이 하나같이 “액세스 토큰 + 리프레시 토큰 + 쿠키” 조합을 가르치는 이유가 여기 있습니다. 순수 JWT의 약점을 실무가 이미 보완하고 있다는 증거죠.

마무리

결국 이 논쟁의 교훈은 기술 선택에 ‘유행’이 끼어들면 안 된다는 겁니다. JWT는 나쁜 기술이 아닙니다. 다만 모든 상황에 맞는 만능 열쇠도 아닙니다. 중요한 건 내 서비스가 정말 토큰의 무상태성을 필요로 하는가, 아니면 그저 멋져 보여서 고른 건가를 따져보는 일입니다.

여러분의 프로젝트는 어떤가요. 지금 쓰는 인증 방식이 진짜 필요해서 고른 건지, 아니면 남들이 쓰니까 따라간 건지 한번 점검해 보시면 어떨까요.