로그인·로그아웃·내 정보 조회 API를 구현하려면, 서버가 먼저 요청을 보낸 사용자가 누구인지 확인하는 방법을 정해야 했습니다.
검토한 방식은 세션(Session)과 토큰(Token)이었습니다.
두 방식 모두 로그인 기능을 구현할 수 있지만, 상태를 저장하는 위치와 로그아웃 처리 방법, 서버 확장 방식에서 차이가 있습니다. 따라서 어떤 방식이 일반적으로 더 좋은지를 판단하기보다, 현재 프로젝트의 요구사항과 규모에 더 잘 맞는 방식이 무엇인지를 기준으로 비교했습니다.
| 비교 항목 | 세션 기반 인증 | 토큰 기반 인증 |
|---|---|---|
| 로그인 상태 저장 위치 | 서버 | 클라이언트 |
| 클라이언트가 보내는 정보 | 세션 ID가 담긴 쿠키 | 사용자 정보와 만료 시간 등이 담긴 토큰 |
| 로그아웃 처리 | 서버에서 세션을 삭제하면 즉시 처리할 수 있습니다. | 이미 발급한 토큰은 만료 전까지 유효하므로 별도의 무효화 방법이 필요할 수 있습니다. |
| 강제 만료 및 로그인 제어 | 서버가 세션을 관리하므로 비교적 간단합니다. | 토큰 차단 목록 등의 추가 저장소가 필요할 수 있습니다. |
| 여러 서버로 확장 | 서버 간에 세션을 공유하기 위한 Redis 등의 저장소가 필요합니다. | 서버가 로그인 상태를 저장하지 않아 수평 확장에 유리합니다. |
| 구현 복잡도 | 서블릿의 HttpSession을 사용할 수 있어 비교적 단순합니다. | 토큰 서명·검증·만료·재발급 정책을 설계해야 합니다. |
| 요청 데이터 크기 | 의미 없는 세션 ID만 전달하므로 작습니다. | 사용자 정보 등의 클레임이 포함되어 세션 ID보다 커질 수 있습니다. |
토큰 방식의 가장 큰 장점은 서버가 로그인 상태를 직접 보관하지 않는다는 점입니다.
따라서 여러 서버가 요청을 나누어 처리하는 환경에서 확장하기 좋다는 장점이 있었습니다.
반면 세션 방식은 서버가 로그인 상태를 직접 관리하므로 로그아웃이나 강제 만료를 간단하게 처리할 수 있습니다. 또한 현재 사용 중인 서블릿 컨테이너인 톰캣이 세션 생성, 만료, 쿠키 발급을 지원하기 때문에 별도의 인증 라이브러리 없이 구현할 수 있습니다.
현재 프로젝트는 단일 서버와 비교적 적은 트래픽을 기준으로 운영하고 있습니다. 여러 서버로 확장하거나 모바일·외부 서비스에 토큰을 제공해야 하는 요구사항은 아직 없습니다.
따라서 지금은 토큰 방식의 주요 장점인 무상태 기반의 수평 확장을 활용하기 어렵다고 생각했습니다.
반면 토큰을 도입하면 서명과 검증, Access Token과 Refresh Token의 만료 및 재발급, 로그아웃한 토큰의 처리 방법 등을 추가로 설계해야 합니다.
5주 동안 진행하는 프로젝트의 범위와 현재 요구사항을 고려하면 이 복잡도에 비해 얻는 이점이 크지 않다고 판단했습니다.
세션 방식은 서버 메모리에 로그인 상태를 저장하므로, 서버가 여러 대로 늘어나면 특정 서버에 저장된 세션을 다른 서버가 알지 못하는 문제가 생길 수 있습니다.
이 경우에는 다음과 같은 대응이 필요합니다.