본문 바로가기
codeit sprint backend/weekly paper

[13-1] 인증: 세션 기반 vs 토큰 기반

by boolynn 2026. 5. 26.

✔️ 들어가며

HTTP는 무상태 프로토콜로, 서버는 요청을 받을 때마다 어느 사람의 요청인지 알지 못한다. 로그인은 이 문제를 해결하기 위한 일종의 약속인데, 이 약속을 어디에/어떻게 저장하느냐에 따라 세션 방식과 토큰 방식으로 나뉜다.

✔️ 세션 기반 인증

세션 기반 인증은 서버가 직접 상태를 기억하는 방법이다. 사용자가 로그인에 성공하면 서버가 "이 사람은 인증됐다!"는 정보를 자신의 저장소(메모리, DB, Redis)에 저장하고, 그 키만 클라이언트에게 쿠키로 전달한다. 이후 모든 요청에서 브라우저는 쿠키를 자동으로 전송하고, 서버는 저장소를 조회해 인증 여부를 확인한다. 도식화하면 다음과 같다.

1. 로그인: 아이디/비밀번호를 서버로 전송
2. 세션 생성: 서버가 세션 저장소에 사용자 정보/권한 저장
3. 쿠키 발급
4. 요청 -> 브라우저가 쿠키 자동 전송 -> 서버가 저장소를 조회해 검증

 

이러한 세션 기반 인증의 가장 큰 장점은 즉각 무효화이다. 서버가 직접 상태를 관리하기 때문에, 보안 사고가 발생했을 때 서버 저장소에서 해당 세션을 삭제하면 해당 사용자는 즉시 로그아웃된다.

 

하지만 모든 사용자의 로그인 상태를 서버가 관리해야 하므로 확장성에 문제가 있다. 사용자가 늘어날수록 세션 저장소가 커지고, 서버의 부담이 증가한다. 부하 분산을 한다 하더라도, A 서버에서 만든 세션을 B 서버는 알지 못 하기 때문에 세션 동기화를 수동으로 해야 한다는 번거로움이 존재한다. 또한, 보안 측면에서 CSRF에 취약하다. 쿠키는 같은 도메인에 대한 요청이라면 사용자의 의도와 무관하게 자동 전송되기 때문이다. 그 예로 악의적인 사이트가 숨겨진 폼으로 은행 API에 요청을 보내면, 사용자가 의도하지 않았더라도 해당 사용자의 쿠키가 함께 전송된다.

✔️ 토큰 기반 인증

토큰 기반 인증은 인증 정보 자체를 토큰 안에 담아 클라이언트에 전달하는 방식이다. 서버는 저장소를 조회하는 대신 토큰의 서명만 검증해 사용자를 식별하면 된다. 이때 토큰의 구성과 각 요소는 다음과 같다.

# 토큰의 구성
header.payload.signature

# 각 요소
## header: 토큰의 메타 정보 (타입, 서명 알고리즘 정보)
## payload: 사용자 정보와 만료 시간
## signature: 서버 비밀키를 이용한 서명 값 (위조 방지를 위함)

 

토큰 기반 인증의 핵심 이점은 무상태성에 있다. 서버가 상태를 저장하지 않기 때문에 분산 환경에서 그 장점이 두드러지는데, 크게 두 가지, 서버 확장성부하 분산의 측면에서 살펴볼 수 있다. 서버 확장성의 측면에서, 세션 저장 공간이 불필요하므로 사용자 수가 늘어도 세션 저장에 부담이 가지 않으며, 새로운 서버를 추가하더라도 세션 동기화 과정이 필요하지 않다. 부하 분산의 특면에서는 모든 서버가 동일한 방식으로 토큰 검증을 수행할 수 있으며 특정 서버에 사용자를 고정시키는 Sticky Session이 불필요하다.

 

하지만 이러한 토큰 기반 인증 방식에도 취약점이 있다. 토큰이 탈취 되었을 때 만료 전까지 서버에서 거부할 방법이 없기 때문이다. 또한, 로컬 스토리지에 저장했을 때 XSS 공격에 취약하다는 단점이 있다. 이를 위해서 Refresh Token Rotation 전략을 사용한다. 이는 토큰을 access token + refresh token 조합으로 운영함으로써, 토큰을 짧은 주기로 무효화시키는 전략이다. 이를 통해 탈취된 토큰이 사용되면 Rotation 충돌로 감지해 전체 세션을 강제 종료할 수도 있다.

 

✔️ 세션 기반 vs 토큰 기반

두 방식의 장단점을 고려해보았을 때, 각각이 적합한 상황은 다음과 같이 정리할 수 있다.

세션 기반

  • 단일 서버 또는 소규모 웹앱
  • 금융/의료와 같이 보안에 민감해 즉각 무효화가 필수인 환경
  • 브라우저 기반 서비스, 로직 상 쿠키 사용이 자연스러운 경우

토큰 기반

  • SPA/모바일 앱
  • 마이크로서비스
  • 여러 도메인/서비스가 동일한 인증을 공유해야 하는 경우
  • 서드파티 API 연동

✔️ 정리

두 방식 중 어떤 것이 우월하다고 말할 수 없다. 어느 것이 안전한가의 문제가 아니라, 어떤 환경에서 어떤 트레이드오프를 감수할 것인가의 문제라고 볼 수 있다. 세션 기반 인증은 즉각 무효화와 구현 단순성이 강점이고, 토큰 기반 방식은 무상태 확장성과 크로스 서비스 인증(사용자가 한번의 로그인으로 여러 독립적인 애플리케이션을 사용 가능)이 강점이다.

 

어느 방식을 선택하든, 보안 기본기를 지키는 것은 늘 중요하다. HTTPS 전용 운영, 쿠키 속성의 올바른 설정, 토큰 저장 위치에 대한 신중한 선택, 무효화 전략 등을 고민함으로써 인증 보안을 공고히 할 수 있다.