JWT 토큰 인증이란? 쿠키, 세션과의 차이점 완벽 비교

JWT 토큰 인증이란? 쿠키, 세션과의 차이점 완벽 비교

웹 개발을 공부하다 보면 로그인 기능을 구현하는 단계에서 반드시 마주치는 용어들이 있습니다. 바로 쿠키, 세션, 그리고 오늘 자세히 다뤄볼 JWT입니다.

 

사용자가 아이디와 비밀번호를 입력하고 로그인 버튼을 눌렀을 때, 서버는 과연 이 사용자를 어떻게 기억하고 식별할까요? 과거에는 당연하게 여겨졌던 방식들이 모바일 시대와 클라우드 환경이 도래하면서 한계를 드러내기 시작했습니다. 그 대안으로 떠오른 것이 바로 토큰 기반의 인증 방식입니다.

 

오늘은 개발자라면 꼭 알아야 할 인증의 흐름과, 구형 방식인 세션과 신형 방식인 JWT가 정확히 어떻게 다른지 아주 쉽게 풀어서 설명해 드릴게요. 이 글 하나면 면접 질문부터 실무 적용까지 확실하게 개념을 잡으실 수 있을 거예요.

 

HTTP는 기억상실증에 걸려 있다

본격적인 비교에 앞서, 우리가 왜 이런 복잡한 인증 방식을 써야 하는지 근본적인 이유를 알아야 합니다.

우리가 사용하는 인터넷, 즉 HTTP 프로토콜은 기본적으로 상태를 저장하지 않는 무상태(Stateless) 성질을 가지고 있습니다.

 

쉽게 말해, 서버는 여러분이 방금 페이지를 요청했던 사람인지, 아니면 지구 반대편에서 처음 접속한 사람인지 전혀 기억하지 못합니다.

 

요청이 끝나면 연결을 끊고 모든 기억을 잊어버리기 때문입니다. 마치 금붕어와 대화하는 것과 비슷하다고 볼 수 있습니다.

 

 

그래서 우리는 서버에게 내가 누구인지 지속적으로 증명할 수 있는 수단이 필요합니다.

그것이 바로 인증입니다.

 

이 인증 정보를 어디에 저장하고 어떻게 관리하느냐에 따라 쿠키/세션 방식과 JWT 방식으로 나뉩니다.

 

 

 

 

 

전통적인 강자 세션과 쿠키 (Session & Cookie)

 

오랫동안 웹 생태계를 지배해 온 방식은 세션과 쿠키입니다. 이 방식은 서버가 모든 것을 주도합니다.

사용자가 로그인을 하면 서버는 신분증 역할을 하는 세션 ID를 생성하고, 이를 서버의 메모리나 데이터베이스에 저장합니다.

그리고 사용자에게는 이 세션 ID가 적힌 쿠키라는 쪽지를 전달합니다.

이후 사용자가 다른 페이지로 이동할 때마다 브라우저는 알아서 이 쿠키를 서버에 보여주며 나 로그인 한 사람이야라고 증명합니다.

 

 

이 방식은 아주 안전하고 관리가 쉽다는 장점이 있습니다.

서버가 모든 정보를 쥐고 있으니 특정 사용자를 강제로 로그아웃시키거나 관리하기가 편합니다.

하지만 치명적인 단점이 있습니다.

접속자가 늘어날수록 서버가 기억해야 할 정보가 너무 많아져 메모리가 부족해지거나 성능이 저하될 수 있다는 점입니다. 이를 세션 부하라고 부릅니다.

 

 

 

가볍고 투명한 대안 JWT (JSON Web Token)

서버가 모든 것을 기억해야 하는 부담을 덜기 위해 등장한 것이 바로 토큰 기반 인증, 그중에서도 가장 표준으로 자리 잡은 JWT입니다.

JWT는 정보를 담은 토큰을 암호화하여 사용자에게 전달합니다.

 

세션 방식이 헬스장 입구에서 회원의 얼굴과 장부를 일일이 대조하는 것이라면, JWT는 회원에게 위변조가 불가능한 전자 출입증을 발급해 주는 것과 같습니다.

이제 서버는 별도의 장부를 뒤적일 필요 없이 사용자가 제시한 토큰이 유효한지만 검증하면 됩니다.

 

이 덕분에 서버는 상태를 저장할 필요가 없어지며, 수많은 사용자가 몰려도 서버를 쉽게 확장할 수 있는 무한한 유연성을 갖게 됩니다.

 

 

JWT의 3가지 핵심 구조

 

JWT는 점(.)으로 구분된 세 가지 부분으로 구성되어 있습니다. 각 부분은 저마다 중요한 역할을 수행합니다.

첫 번째는 헤더(Header)입니다.

여기에는 토큰의 타입과 어떤 암호화 알고리즘을 사용했는지에 대한 정보가 담겨 있습니다. 마치 편지 봉투에 적힌 발신인 정보와 같습니다.

 

두 번째는 페이로드(Payload)입니다.

실질적인 정보가 담기는 곳입니다. 사용자 ID나 유효 기간 같은 데이터가 들어갑니다. 단, 이곳은 누구나 해독하여 볼 수 있으므로 비밀번호 같은 민감한 정보는 절대 담아서는 안 됩니다.

 

세 번째는 서명(Signature)입니다. 가장 중요한 보안 장치입니다.

헤더와 페이로드를 합친 뒤 서버만 알고 있는 비밀키로 암호화한 값입니다.

만약 누군가 페이로드의 내용을 몰래 조작한다면 이 서명 값과 일치하지 않게 되어 서버는 즉시 위조된 토큰임을 알아챌 수 있습니다.

 

 

쿠키 세션 vs JWT 한눈에 비교하기

 

두 방식의 차이를 명확히 이해하는 것이 중요합니다. 상황에 따라 적절한 기술을 선택해야 하기 때문입니다.

 

저장 위치에서 가장 큰 차이가 납니다. 세션 방식은 서버의 메모리나 데이터베이스에 정보를 저장하지만, JWT는 클라이언트(브라우저)가 토큰을 보관합니다. 이로 인해 서버의 부하가 확연히 달라집니다.

 

확장성 면에서는 JWT가 압도적으로 유리합니다. 서버가 여러 대로 늘어나도 토큰만 검증하면 되기 때문입니다. 반면 세션 방식은 여러 서버 간에 세션 정보를 공유해야 하는 복잡한 설정이 추가로 필요합니다.

 

보안 측면에서는 세션이 조금 더 유리할 수 있습니다.

 

토큰은 한번 발급되면 유효기간이 끝날 때까지 제어하기 힘들지만, 세션은 서버에서 즉시 삭제하여 접속을 차단할 수 있기 때문입니다. 그래서 JWT를 사용할 때는 유효기간을 짧게 잡고 Refresh Token을 함께 사용하는 전략을 주로 씁니다.

 

 

 

어떤 방식을 선택해야 할까

 

정답은 없습니다.

여러분이 만들고자 하는 서비스의 특성에 맞춰야 합니다.

 

만약 접속자가 많지 않고 관리자 기능처럼 강력한 보안과 통제가 필요한 내부 시스템을 만든다면 전통적인 세션 방식이 더 안전하고 효율적일 수 있습니다. 구현도 상대적으로 간단합니다.

 

하지만 모바일 앱을 함께 운영하거나, 사용자 수가 급격히 늘어날 가능성이 있는 B2C 서비스, 혹은 마이크로 서비스 아키텍처(MSA)를 고려하고 있다면 JWT가 필수적입니다.

서버 간의 의존성을 없애고 가볍고 끊김 없는 인증 환경을 제공하기 때문입니다.

 

 

JWT, 토큰인증, 세션쿠키차이, 웹개발, 로그인구현, 서버인증, 백엔드기초, 프론트엔드인증, 보안기초, API인증