다중 JWT 도입 배경

• 도입 배경 국내 서비스인 '소모임'의 DAU는 약 12~14만으로 하루 수십만 건의 REST API 요청이 발생합니다. 인증 로직이 무겁거나 비효율적이면 서버 전체에 심각한 부하가 발생할 수 있어 가볍고 빠른 인증 메커니즘이 필요했습니다. 또한 탈취 위험을 최소화하기 위해 짧은 수명으로 발급하되, 토큰이 자주 만료되면 사용자가 반복 로그인해야 하는 불편이 생겨 보안성과 편의성을 동시에 만족시키는 인증 체계가 필요했습니다.
• 선택지
  • 세션 기반 (서버/Redis 저장)
    • Redis로 서버 간 세션 공유가 가능해 수평 확장 대응
    • 요청마다 세션 저장소 조회로 네트워크 I/O 추가
    • 세션 정보가 많아질수록 저장소와 서버 부하 증가
  • 쿠키 기반 인증
    • 브라우저 환경에서 구현이 간단하고 편리
    • CSRF·쿠키 탈취 대응 필요, 모바일·외부 API 연동 제약
  • 단일 JWT
    • 무상태(stateless)라 서버 확장에 유리, 서명 검증만으로 빠른 처리
    • 토큰 유출 시 만료까지 위험 창구 존재, TTL 설정의 보안/편의성 트레이드오프
  • 다중 JWT (Access + Refresh)
    • Access는 짧게, Refresh는 길게 발급하여 조합
    • 짧은 Access TTL로 보안 리스크 감소, 재발급으로 사용자 로그인 빈도 감소
• 최종 결정 세션 기반은 요청마다 네트워크 I/O가 추가되어 제외했습니다. 쿠키 기반은 관리 포인트가 많고 모바일·외부 API에 제약이 있어 제외했습니다. 단일 JWT는 토큰 유출 시 막기 어렵고 TTL 설정의 트레이드오프가 있어 제외했습니다. 따라서 다중 JWT(Access + Refresh)로 결정했습니다.