세션 vs JWT

 

 

 

세션(Session)과 JWT(JSON Web Token)는 둘 다:

"로그인 상태를 유지하는 방법"

 

이다.

하지만 핵심 구조가 완전히 다르다.

---

가장 핵심 차이 한 줄

방식	로그인 상태 저장 위치
Session	서버
JWT	클라이언트(Token 내부)

---

1. Session 방식 - 전통적인 서버 로그인 방식

흐름

로그인 성공 = 서버가  SESSION_ID 생성:

# SESSION_ID 생성
JSESSIONID=ABCD1234

 

 

서버 메모리/Redis 저장

SESSION_ID: ABCD1234
{ 
	userId=hoon,
    role=ADMIN
}

 

저장 후 브라우저에 세션 ID 전달

브라우저는 쿠키만 보관 (JSESSIONID외의 정보는 브라우저가 모름)

 

Set-Cookie: JSESSIONID=ABCD1234

 

이후 요청마다 브라우저가 자동으로 이 쿠키를 전송하면

서버가 세션ID를 조회해서 매칭되는 userId, role을 찾음:

SESSION_ID 조회

 

후 로그인 사용자 확인.

---

즉 핵심

상태(State)를 서버가 저장

 

한다.

그래서:

Stateful

 

이라고 부름.

---

Session 장점

1. 강제 로그아웃 쉬움

서버에서 세션 삭제하면 끝.

2. 토큰 탈취 대응 쉬움

세션 무효화 가능.

3. 구현 단순

Spring Security 기본 구조.

---

단점

서버 메모리 사용

사용자 많으면 부담.

서버 확장 어려움

서버 여러 대면:

• 세션 공유
• Redis
• Sticky Session
• Session Cluster

필요.

---

2. JWT 방식

JWT는 구조가 다르다.

---

핵심

사용자 정보 자체를
토큰 안에 넣는다

 

---

로그인 성공 시

서버가 JWT 생성.

예:

HEADER.PAYLOAD.SIGNATURE

 

{
  "userId":"hoon",
  "role":"ADMIN",
  "exp":999999999
}

 

서버는 전자서명

서버비밀키(HMAC 또는 RSA/ECDSA)로 서명. 위조 불가

클라이언트(브라우저) 저장

보통:

• 쿠키
• LocalStorage

등에 저장.

이후 요청 시

 

Authorization: Bearer eyJ...

 

전송.

서버는 DB 조회 안 해도 됨, 서명 검증만하고 신뢰

왜냐면:

# JWT 내부 본원하면 토큰 안에 정보 이미 존재
{
  "userId":"hoon",
  "role":"ADMIN",
  "exp":999999999
}

 

하기 때문.

서버는 서명만 검증. 세션 없고, DB조회도 필요없음

위조 안 됐나?

 

확인.

---

즉 핵심

상태를 서버가 저장 안 함

 

그래서:

Stateless

 

방식.

---

JWT 장점

1. 서버 확장 쉬움

서버끼리 세션 공유 불필요.

2. 모바일/API 친화적

SPA, 앱에 적합.

3. MSA 구조에 좋음

마이크로서비스에서 많이 사용.

---

JWT 단점 (엄청 중요)

1. 강제 로그아웃 어려움

JWT는 이미 사용자 손에 있음.

즉:

서버가 즉시 회수 어려움

 

2. 탈취 시 위험

유효기간 동안 사용 가능.

3. Payload 노출 가능

암호화가 아니라 Base64 인코딩.

즉:

내용 읽기는 가능

 

(서명으로 위조만 방지)

그래서 민감정보 넣으면 안 됨

예:

• 비밀번호
• 주민번호

절대 금지.

---

실무에서 많이 쓰는 구조

현재는 보통:

Access Token (짧게) 강제 로그아웃이 어려우니까 애초에 짧게
+
Refresh Token (길게) 별도로 관리

 

구조.

---

Access Token

• 15분~1시간
• API 인증용

---

Refresh Token

• 재발급용
• DB/Redis 저장

---

JWT라고 DB 조회가 완전히 없는 건 아님

실무에선:

• 블랙리스트
• Refresh 관리
• 권한 변경
• 강제로그아웃위해서

때문에 Redis 자주 사용. 

---

그래서 현실은

완전 Stateless는 드물다

 

오히려 세션이 더 좋은 경우

특히:

• 관리자 페이지
• 기업 내부 시스템
• 보안 중요한 서비스

는 세션 엄청 많음.

상황	추천
전통 서버 렌더링	세션
SPA/모바일 API	JWT
대규모 분산	JWT
강한 로그인 통제	세션
간단한 운영	세션
MSA/API Gateway	JWT

 

---

Session vs JWT 비교

항목	Session	JWT
상태 저장	서버	클라이언트
서버 메모리	사용	적음
서버 확장	어려움	쉬움
강제 로그아웃	쉬움	어려움
토큰 크기	작음	큼
모바일/API	상대적으로 불편	적합

---

Spring 실무 느낌

---

Session 기반

JSESSIONID 쿠키

 

---

JWT 기반

 

Authorization: Bearer TOKEN

• Authorization → 인증 헤더 이름
• Bearer → 인증 방식 종류. "소지자", "이 토큰을 가진 사람은 인증된 것으로 간주" 라는 개념 
• eyJhbGciOi... → 실제 토큰

Bearer Token: 토큰 자체가 신분증 역할 하는 방식

HTTP Authorization 헤더 구조

원래 HTTP 스펙 자체가 이렇게 되어 있음 (프로토콜 규약):

 

Authorization: <인증방식> <인증값>

그래서 Bearer는 JWT 전용이 아니다

이게 중요.

JWT가 없어도 Bearer 쓸 수 있음. 물론 실무에서는 JWT와 Bearer 조합을 많이 씀 JWT는 토큰 형식, 포맷이고 Bearer는 인증방식 

실무 서버 코드 예시

Spring Security 필터에서 보통:

 

String auth = request.getHeader("Authorization");

 

꺼낸 뒤:

 

if (auth.startsWith("Bearer ")) {
    token = auth.substring(7);
}

 

이렇게 파싱함.

---

Bearer 방식의 보안 특징

Bearer는:

가진 놈이 인증됨

 

구조라서,

토큰 탈취되면 위험함.

그래서 반드시:

• HTTPS 사용
• 짧은 만료시간
• Refresh Token
• Secure Cookie

등 같이 사용함.

---

요즘 트렌드

환경	주류
전통 MVC	Session
SPA + API	JWT
MSA	JWT/OAuth2
내부 관리툴	Session 많음

---

실무에서 중요한 보안 포인트

JWT 저장 위치 중요

LocalStorage는:

XSS 위험

 

있다.

---

그래서 최근은

HttpOnly Secure Cookie

 

많이 사용.

---

Session도 결국 쿠키 기반

헷갈리는 부분.

Session 자체는 서버 저장이고:

세션ID 전달은 쿠키

 

사용한다.

---

핵심 한 줄

Session은:

로그인 상태를 서버가 저장하는 방식

브라우저:
"나 A1B2C3 입니다"

서버:
"조회해보니 ADMIN 이군"

 

이고,

JWT는:

로그인 정보를 서명된 토큰 안에 담아
클라이언트가 직접 들고 다니는 방식

브라우저:
"내 신분증 안에 ADMIN 써있음"

서버:
"서명 검증 완료. 진짜 맞네"

 

이다.