• Cookie/세션 방식

  • 서버가 사용자 로그인 정보를 세션 저장소(메모리, DB, Redis 등) 에 저장하고, 클라이언트는 세션 ID를 쿠키로 보관
  • 요청마다 쿠키의 세션 ID를 보내면 서버가 세션 저장소에서 사용자 정보를 조회
  • 장점: 세션 무효화(로그아웃, 강제 종료)가 쉽고 직관적
  • 단점: 세션 상태를 서버에 유지해야 하므로 서버 확장(scale-out) 시 중앙 세션 저장소 필요

• JWT (JSON Web Token) 방식

  • 인증 정보를 자체적으로 담은 토큰(Payload + Signature)을 클라이언트가 보관
  • 요청 시 토큰을 HTTP 헤더(Authorization: Bearer)로 전송
  • 서버는 서명 검증만 하고 별도 세션 저장소가 필요 없음 → 무상태(stateless)
  • 장점: 서버 확장 시 중앙 세션 관리 불필요, 다른 서비스/도메인과도 쉽게 연동 가능
  • 단점: 토큰이 발급되면 만료(exp) 전까지는 유효 → 강제 폐기 어려움
    (보통 짧은 만료시간 + Refresh Token or Redis 블랙리스트로 보완)

• 네, 사실 단일 서버 환경이라면 쿠키-세션 기반으로도 충분히 구현 가능합니다.
• 제가 JWT를 사용한 이유는 다음과 같습니다:

1. 무상태(stateless)

   • 서버가 사용자 세션을 따로 저장하지 않아도 됩니다.
   • 요청마다 토큰 검증만 수행하면 되므로 서버 부담이 줄어듭니다.

2. 확장성

   • 서버를 여러 대로 늘려도 별도의 세션 공유 저장소(Redis 등)를 두지 않아도 됩니다.
   • 추후 마이크로서비스나 게이트웨이 환경으로 확장할 때 유리합니다.

3. Self-contained 토큰

   • 토큰 안에 사용자 식별자, 권한 등의 정보가 포함될 수 있어, 단순 인가 판단에 추가 DB 조회가 필요하지 않습니다.

• 물론 단점도 인지하고 있습니다.
  • 토큰을 강제로 무효화하기 어렵다는 점, Payload 크기가 커질 수 있다는 점이 있습니다.
  • 따라서 짧은 만료시간 + Refresh Token 전략으로 운영하거나,
    필요하다면 Redis 같은 저장소에 블랙리스트를 둬서 보완할 수 있습니다.

👉 결론적으로, 제 프로젝트(Madness)에서는 세션 방식도 가능했지만,
확장성과 무상태성을 경험해보기 위해 JWT를 선택했습니다.