JWT vs 세션 쿠키 인증 방식 비교: 개념, 장단점, 실제 적용 가이드

## JWT vs 세션 쿠키 인증 방식 비교: 개념, 장단점, 실제 적용 가이드

웹 애플리케이션에서 사용자 인증은 필수적인 기능입니다. 사용자 요청을 검증하고 리소스 접근 권한을 관리하기 위해 다양한 인증 메커니즘이 사용됩니다. 대표적으로 JWT(JSON Web Token)와 세션 쿠키 기반 인증 방식이 널리 활용되고 있습니다. 본 문서는 두 방식의 개념, 특징, 장단점을 비교하고 실제 적용 시 고려사항을 제시하여 개발자 및 메이커들이 프로젝트에 적합한 인증 방식을 선택하도록 돕습니다.

### 1. 세션 쿠키 기반 인증 방식

세션 쿠키 인증 방식은 서버 측에서 사용자 세션 정보를 관리하는 전통적인 방식입니다.

*   **개념**: 사용자가 로그인하면, 서버는 사용자 정보를 담은 세션 ID를 생성합니다. 이 세션 ID는 쿠키 형태로 사용자 브라우저에 저장되고, 이후 사용자의 모든 요청에는 이 세션 ID가 포함됩니다. 서버는 수신된 세션 ID를 통해 해당 사용자의 세션 정보를 조회하고 인증을 처리합니다.
*   **작동 방식**: 
    1.  사용자가 로그인 요청을 보냅니다.
    2.  서버는 사용자 정보를 검증하고 고유한 세션 ID를 생성합니다.
    3.  서버는 생성된 세션 ID를 쿠키에 담아 사용자 브라우저로 응답합니다.
    4.  브라우저는 세션 ID 쿠키를 저장하고, 이후 요청 시마다 이 쿠키를 함께 전송합니다.
    5.  서버는 요청에서 받은 세션 ID를 통해 저장된 세션 정보를 확인하여 인증합니다.
*   **장점**: 
    *   서버 측에서 세션 정보를 직접 관리하므로 보안에 상대적으로 유리합니다.
    *   세션 만료 시 클라이언트 측에서 별도 처리가 필요 없습니다.
    *   구현이 비교적 간단합니다.
*   **단점**: 
    *   **확장성 문제**: 서버가 모든 세션 정보를 메모리나 저장소에 보관해야 하므로, 사용자 수가 많아지면 서버 부하가 증가하고 확장이 어렵습니다.
    *   **Stateful 서버**: 서버가 클라이언트의 상태(세션 정보)를 기억해야 하므로 Stateful 서버가 됩니다.
    *   **CSRF 공격 취약**: 쿠키를 이용하므로 CSRF(Cross-Site Request Forgery) 공격에 취약할 수 있습니다.
    *   **서버 장애 시 문제**: 세션 정보가 서버 내부에만 저장되어 있어, 서버 장애 발생 시 모든 사용자의 세션이 유실될 수 있습니다.

### 2. JWT (JSON Web Token) 인증 방식

JWT는 서버와 클라이언트 간에 정보를 안전하게 전달하기 위한 오픈 표준(RFC 7519)입니다. 인증 및 정보 교환에 사용됩니다.

*   **개념**: JWT는 토큰 기반 인증 방식으로, 사용자 정보와 권한 등을 암호화하여 JSON 객체 형태로 전달합니다. 이 토큰은 사용자 브라우저(주로 Local Storage 또는 Session Storage)에 저장되며, 서버는 토큰의 유효성을 검증하여 인증을 처리합니다.
*   **JWT 구조**: JWT는 크게 세 부분으로 구성되며, 각 부분은 Base64Url로 인코딩되어 점(.)으로 구분됩니다.
    *   **Header**: 토큰 타입(JWT)과 서명에 사용된 알고리즘(예: HS256) 정보를 포함합니다.
    *   **Payload**: 사용자 식별 정보(Subject), 발급 시간(Issued At), 만료 시간(Expiration Time) 등 클레임(Claim)을 포함합니다. 민감한 정보는 포함하지 않는 것이 좋습니다.
    *   **Signature**: Header와 Payload, 그리고 서버의 비밀 키(Secret Key)를 사용하여 생성됩니다. 토큰의 위변조 여부를 확인하는 데 사용됩니다.
*   **작동 방식**: 
    1.  사용자가 로그인 요청을 보냅니다.
    2.  서버는 사용자 정보를 검증하고, Header, Payload, Secret Key를 이용하여 JWT를 생성합니다.
    3.  서버는 생성된 JWT를 사용자에게 응답합니다.
    4.  사용자는 JWT를 브라우저(Local Storage 등)에 저장합니다.
    5.  사용자는 이후 요청 시마다 Authorization 헤더 등을 통해 JWT를 서버로 전송합니다.
    6.  서버는 수신된 JWT의 서명을 검증하고, Payload의 유효 기간 등을 확인하여 인증합니다.
*   **장점**: 
    *   **Stateless 서버**: 서버는 클라이언트의 상태를 저장할 필요 없이 토큰 검증만 수행하면 되므로 Stateless 서버 구성이 가능합니다.
    *   **확장성 용이**: 서버 확장 및 관리가 세션 방식보다 용이합니다.
    *   **분산 환경**: 여러 서버 간에 토큰을 공유하여 인증할 수 있어 마이크로서비스 환경에 적합합니다.
    *   **다양한 클라이언트 지원**: 웹뿐만 아니라 모바일 앱 등 다양한 클라이언트에서 쉽게 사용할 수 있습니다.
*   **단점**: 
    *   **보안**: 토큰 자체에 정보를 담고 있어 Payload가 노출될 경우 민감한 정보가 유출될 수 있으므로, 민감 정보는 담지 않거나 추가 암호화가 필요합니다. 또한, 토큰이 탈취될 경우 검증 과정에서 이를 즉시 알기 어렵습니다.
    *   **토큰 크기**: 세션 ID보다 일반적으로 토큰의 크기가 커서 요청 시 전송량이 늘어날 수 있습니다.
    *   **토큰 폐기 어려움**: 한 번 발급된 JWT는 유효 기간 내에는 서버 측에서 직접적으로 만료시키기 어렵습니다. 이를 위해 별도의 블랙리스트 관리 등이 필요할 수 있습니다.
    *   **CORS 문제**: 쿠키 방식과 달리 브라우저의 자동 처리 기능이 없어, 클라이언트 측에서 Authorization 헤더에 토큰을 직접 포함시키는 등의 처리가 필요합니다.

### 3. JWT vs 세션 쿠키: 핵심 차이점 요약

| 특징          | 세션 쿠키 인증                                  | JWT 인증                                        |
| :------------ | :---------------------------------------------- | :---------------------------------------------- |
| **상태 관리** | Stateful (서버가 세션 정보 저장)                | Stateless (서버가 상태 저장 안 함)               |
| **정보 저장** | 서버 (세션 ID, 사용자 정보)                     | 클라이언트 (JWT 토큰)                           |
| **확장성**    | 제한적 (서버 부하 증가)                         | 용이 (Stateless 특성)                           |
| **구현 복잡도** | 상대적으로 낮음                                 | 상대적으로 높음 (토큰 생성, 검증, 관리 필요)    |
| **CSRF 취약** | 있음 (쿠키 이용)                                | 없음 (쿠키 자동 전송되지 않음)                  |
| **토큰 탈취** | 세션 ID 탈취 시 문제 (세션 만료로 대응 가능)    | 토큰 탈취 시 문제 (별도 검증/무효화 로직 필요)  |
| **주요 사용처** | 전통적인 웹 애플리케이션, 단일 서버 환경        | 마이크로서비스, API 인증, 다중 클라이언트 환경  |

### 4. 실제 적용 시 고려사항

*   **보안**: JWT 사용 시 Payload에 민감한 정보를 포함하지 않도록 주의하고, 서명 검증 및 토큰 만료 관리에 신경 써야 합니다. HTTPS를 항상 사용하세요.
*   **확장성**: 서비스 규모가 커지거나 마이크로서비스 아키텍처를 도입할 계획이라면 JWT 방식이 더 유리할 수 있습니다.
*