프로젝트의 인증 시스템 설계에서 개발자들은 흔히 Session vs JWT 사이의 선택을 고민하게 된다. 겉보기에 단순한 기술적 차이 같지만, 사실 이 선택은 프로젝트의 아키텍처 방향과 설계자의 철학을 깊숙이 반영한다.
나는 이번 이커머스 프로젝트에서 Session 기반이 아닌 JWT(Json Web Token) 기반 인증 방식을 선택했다. 그 이유는 단순한 기술적 우위 때문이 아니라, 앞으로의 시스템 확장성과 분산 환경에 최적화된 무상태(Stateless) 인증 아키텍처를 지향했기 때문이다.
왜 Stateless가 중요한가?
대부분의 웹 서비스는 처음에는 세션 기반 인증으로 쉽게 시작한다. 하지만 사용자가 많아지고 서버가 여러 대로 늘어나면서 곧 문제가 발생한다. 세션 기반 인증은 서버가 로그인 상태를 기억해야 하기 때문에 서버 간 세션 공유나 Sticky Session 등의 복잡성이 추가되며 확장성의 한계를 경험하게 된다.
JWT는 서버가 "사용자의 상태를 기억하지 않는다"는 점에서 근본적인 차이가 있다. 이는 단순히 기술적 특징이 아니라 시스템 설계의 근본적인 원칙을 바꾸는 요소다.
분산 아키텍처에 최적화된 JWT
이커머스 시스템과 같은 대규모 서비스에서는 항상 Scale-Out, Auto-Scaling, 무중단 배포 등을 고려해야 한다. JWT 기반 인증 방식은 서버가 사용자의 인증 상태를 관리하지 않기 때문에, 수십 대에서 수백 대의 서버로 확장하더라도 추가적인 복잡성이 없다.
즉, 사용자의 모든 요청은 독립적으로 처리되고, 로드 밸런서(LB)나 API Gateway를 통해 여러 서버에 분산되어도 동일한 인증 로직을 수행할 수 있다.
Redis와의 통합을 통한 실시간 통제
JWT 인증 시스템의 대표적인 우려 사항 중 하나는 바로 보안 문제다. JWT는 한번 발급되면 만료 전까지 강제로 중단시키기 어렵다는 특성 때문에 보안 리스크가 있다는 평가를 종종 받는다.
하지만 본 프로젝트에서는 Redis와 연계한 블랙리스트 캐시를 통해 이 문제를 해결했다. 사용자의 권한이 변경되거나, 계정이 탈취되었다고 판단되면 즉시 Redis의 블랙리스트에 토큰을 등록하여 강제로 인증을 무효화할 수 있도록 설계했다.
프론트엔드와의 유기적 통합
JWT는 서버와 클라이언트가 명확하게 분리된 환경에서 매우 효과적이다. 본 프로젝트의 경우 프론트엔드를 Nuxt로 구성하고, HttpOnly 쿠키로 JWT Access Token을 관리했다. 이는 XSS 공격에 대응하면서도 인증 정보를 클라이언트가 직접 관리할 필요가 없게 한다.
동시에 Redis와 연동하여 Refresh Token을 관리하고, 프론트와 백엔드가 상호 작용하여 토큰 갱신을 자동화하는 구조를 구축했다. 결과적으로 사용자는 인증 절차를 거의 인지하지 않고도 원활한 서비스 이용이 가능하게 되었다.
설계자의 철학: Stateless를 통한 아키텍처적 자유
"무상태(Stateless)는 자유다."
이 짧은 문장은 내가 JWT를 선택한 이유의 핵심이다. 상태 관리가 서버로부터 독립되면, 시스템 설계자는 서버 자원을 자유롭게 배치하고, 트래픽을 원하는 대로 분산시키며, 필요에 따라 언제든지 확장할 수 있다.
JWT 기반의 무상태 설계를 통해 얻은 가장 큰 가치는 확장성과 유연성이다. 향후 마이크로서비스 아키텍처나 서버리스 컴퓨팅 환경으로의 전환 또한 쉽다.
결론
JWT 기반 인증을 선택한 것은 단순한 기술적 편의성이 아닌, 앞으로의 서비스가 추구하는 고가용성(High Availability), 확장성(Scalability), 보안(Security) 그리고 무엇보다도 아키텍처적 유연성(Flexibility)을 얻기 위한 전략적인 결정이었다. 앞으로도 시스템의 근본적 설계 철학으로 Stateless를 유지할 계획이며, 그 중심에는 JWT와 Redis가 함께할 것이다.
