Sessions vs Tokens — 백엔드 엔지니어를 위한 완전 가이드

Source: Dev.to

위에 제공된 텍스트를 번역하려면 실제 번역할 내용이 필요합니다. 번역하고 싶은 본문을 알려주시면 한국어로 번역해 드리겠습니다.

🔐 인증이란?

세션과 토큰에 대해 살펴보기 전에 중요한 구분을 명확히 합니다:

세션과 토큰은 주로 authentication‑persistence problem을 해결합니다, 왜냐하면 로그인 후…

👉 HTTP는 상태 비저장 – 서버는 요청 사이의 모든 정보를 잊어버립니다.

따라서 사용자를 기억할 메커니즘이 필요합니다.

🧠 핵심 문제

흐름 예시

1. 사용자가 이메일 + 비밀번호로 로그인합니다.
2. 서버가 자격 증명을 확인합니다.
3. 사용자가 또 다른 요청을 합니다.

이제 서버는 알아야 합니다:

👉 이 사용자가 동일한 인증된 사용자입니까?

여기서 세션과 토큰이 등장합니다.

---

✅ 세션이란?

A session은 로그인한 사용자를 추적하는 서버‑사이드 저장 메커니즘입니다.

핵심 아이디어

• 서버가 사용자 데이터를 저장합니다.
• 클라이언트는 세션 ID만 저장합니다.

세션 작동 방식 (단계별)

1. 사용자 로그인 – 백엔드가 자격 증명을 검증합니다.

2. 서버가 세션을 생성 – 예: Redis/DB에 저장:

   {
     "session_id": "abc123",
     "user_id": 42,
     "role": "admin",
     "expires_at": "2026-02-01"
   }

3. 서버가 세션 ID를 쿠키로 전송

   Set-Cookie: session_id=abc123; HttpOnly; Secure

4. 브라우저가 모든 요청에 쿠키를 자동으로 전송:

   Cookie: session_id=abc123

5. 서버가 세션을 조회 – 찾으면 사용자가 인증됩니다.

아키텍처 보기

Client → Cookie → Server → Session Store → User

서버는 사용자를 기억하는 책임을 집니다.

🔥 세션의 장점

❌ 세션의 단점

✅ 토큰이란?

토큰은 서버가 발행하고 클라이언트가 저장하여 각 요청마다 전송하는 자체 포함 인증 정보입니다.

👉 서버에 사용자 데이터를 저장하는 대신, 토큰 자체에 데이터가 담겨 있습니다.

가장 일반적인 형태는 JWT (JSON Web Token) 입니다.

JWT 구조

JWT는 세 부분으로 구성됩니다:

header.payload.signature

예시

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VyX2lkIjo0Miwicm9sZSI6ImFkbWluIn0.
abcXYZsignature

토큰 작동 방식 (단계별)

1. 사용자 로그인 – 서버가 자격 증명을 확인합니다.

2. 서버가 토큰 생성 – 페이로드에 포함될 수 있는 내용:

   {
     "user_id": 42,
     "role": "admin",
     "exp": 1735689600   // Unix 타임스탬프
   }

3. 클라이언트가 토큰 저장 – 보통 Authorization 헤더나 HttpOnly 쿠키에 저장합니다.

4. 클라이언트가 매 요청마다 토큰 전송:

   Authorization: Bearer <token>

5. 서버가 서명 검증 – 유효하면 페이로드를 신뢰합니다 (DB 조회 불필요).

아키텍처 보기

Client → Token → Server (verify only)

서버 측 메모리 필요 없음 → 무상태(stateless).

🔑 토큰의 장점

❌ 토큰의 단점

⚔️ 세션 vs. 토큰 — 직접 비교

🧠 언제 세션을 사용해야 할까요?

다음과 같은 경우에 좋은 선택입니다:

• ✅ MVC 또는 서버‑렌더링 앱
• ✅ 은행 시스템 및 관리자 대시보드
• ✅ 엄격한 보안 제어가 수평 확장보다 우선시되는 시나리오

🚀 언제 토큰을 사용해야 할까요?

Ideal for:

• ✅ REST API
• ✅ 모바일 백엔드
• ✅ 마이크로서비스 & SaaS 플랫폼
• ✅ 확장성이 중요한 모든 상황

⭐ Senior‑Level Insight

세션과 토큰은 각각 역할이 있습니다. “올바른” 선택은 다음에 따라 달라집니다:

1. 애플리케이션 유형 (웹 페이지 vs. API)
2. 확장성 요구사항 (단일 서버 vs. 분산)
3. 보안 및 폐기 필요성 (즉시 로그아웃 vs. 허용 가능한 지연)

대부분의 경우 하이브리드 접근법을 사용합니다: 브라우저 기반 UI에는 세션, API 호출에는 토큰을 사용합니다. 트레이드‑오프를 이해하면 보안과 확장성을 모두 갖춘 백엔드를 설계할 수 있습니다.

Important

많은 엔지니어가 이렇게 생각합니다:

“JWT가 항상 더 좋다.”

이는 잘못된 생각입니다.

Stateless가 자동으로 우수한 것은 아닙니다.

대기업에서도 세션을 많이 사용하는 이유는:

Control > Convenience.

아키텍처는 트렌드가 아니라 트레이드‑오프에 관한 것입니다.

🔥 현대 하이브리드 접근 방식 (매우 인기 있음)

두 세계의 장점

사용

• ✅ 짧은 수명의 Access Token (5 – 15 분)
• ✅ 서버 측에 저장된 Refresh Token

흐름

1. Access token이 빠르게 만료됩니다.
2. Refresh token이 새로운 access token을 요청합니다.
3. Refresh token이 유출된 경우 → 토큰을 폐기합니다.

장점

• ✔ 확장성
• ✔ 제어
• ✔ 보안

⚠️ 일반적인 백엔드 실수

---

🧭 Final Mental Model

• 👉 Sessions = Server remembers you → 세션 = 서버가 당신을 기억합니다
• 👉 Tokens = You prove who you are → 토큰 = 당신이 누구인지 증명합니다

두 가지 모두 도구입니다. 훌륭한 엔지니어는 과대광고가 아니라 시스템 요구사항에 따라 선택합니다.

이 주제를 마스터하면, 단순히 코더가 아니라 시스템 설계자처럼 사고하게 됩니다.

---

Follow me:

• GitHub
• LinkedIn
• Threads
• YouTube Channel