웹 서비스에서 로그인 기능을 구현할 때 가장 중요한 문제는 "로그인 상태를 어떻게 유지할 것인가?" 이다.
HTTP는 Stateless(무상태) 프로토콜이기 때문에 요청이 끝나면 이전 요청을 기억하지 않는다.
즉, 로그인 요청이 끝난 후 다음 요청이 들어오면 서버는 사용자가 누구인지 알 수 없다.
그래서 로그인 상태를 유지하기 위한 기술로 Session과 JWT를 사용한다.
HTTP는 왜 로그인을 기억하지 못할까?
예를 들어 인스타그램에 로그인했다고 가정해보자.
로그인
↓
홈 화면
↓
좋아요
↓
댓글 작성
만약 로그인 정보를 저장하지 않는다면
사용자는 매 요청마다 로그인해야 한다.
홈 화면 → 아이디, 비밀번호 입력
좋아요 → 아이디, 비밀번호 입력
댓글 → 아이디, 비밀번호 입력
이 문제를 해결하기 위해 Session과 JWT가 등장했다.
Session 방식
개념
Session은 서버가 로그인 정보를 기억하는 방식이다.
로그인에 성공하면 서버는 Session ID를 생성하고, 사용자 정보를 서버 메모리에 저장한다.
브라우저에는 Session ID만 전달한다.
동작 과정
브라우저
│ 로그인
▼
서버
로그인 성공
↓
Session 생성
↓
Session ID 발급
↓
브라우저는 Session ID를 쿠키에 저장
다음 요청에서는
브라우저
Session ID
↓
서버
Session ID 조회
↓
사용자 확인
즉,
브라우저는 Session ID만 가지고 있고
실제 로그인 정보는 서버가 가지고 있다.
장점
- 서버에서 로그인 정보를 관리하므로 비교적 안전하다.
- 로그아웃 처리가 쉽다.
- Session을 삭제하면 즉시 로그아웃된다.
단점
- 사용자 수가 많아질수록 서버 메모리를 많이 사용한다.
- 서버가 여러 대인 경우 Session 공유가 필요하다.
JWT(JSON Web Token) 방식
개념
JWT는 사용자가 로그인 정보를 직접 가지고 다니는 방식이다.
로그인 성공 시 서버는 JWT(Token)를 생성하여 브라우저에 전달한다.
이 Token 안에는
- 사용자 번호
- 권한
- 만료시간
등의 정보가 들어 있다.
다음 요청에서는 이 Token을 서버에 함께 보낸다.
동작 과정
브라우저
로그인
↓
서버
JWT 생성
↓
브라우저
JWT 저장
다음 요청
브라우저
Authorization
Bearer JWT
↓
서버
JWT 검증
↓
사용자 확인
서버는 로그인 정보를 따로 저장하지 않고
JWT만 검증하면 된다.
장점
- 서버 메모리를 거의 사용하지 않는다.
- 서버가 여러 대여도 관리가 쉽다.
- REST API, 모바일 앱, React/Vue 같은 프론트엔드 분리 프로젝트에서 많이 사용된다.
단점
- 로그아웃 처리가 Session보다 어렵다.
- 토큰이 탈취되면 만료될 때까지 사용할 수 있으므로 추가적인 보안 대책이 필요하다.
Session과 JWT 비교
SessionJWT
| 서버가 로그인 정보를 저장 | 클라이언트가 Token을 저장 |
| 브라우저에는 Session ID만 저장 | 브라우저에 JWT 저장 |
| 서버 메모리 사용 | 서버 메모리 거의 사용하지 않음 |
| 로그아웃이 쉬움 | 로그아웃 구현이 상대적으로 복잡함 |
| 전통적인 웹 서비스에서 많이 사용 | REST API, 모바일, React 프로젝트에서 많이 사용 |
'Spring' 카테고리의 다른 글
| Spring 커스텀 예외 만들기와 전역 예외 처리 (0) | 2026.08.04 |
|---|---|
| [Spring] JPA 연관관계 매핑 정리 (0) | 2026.07.06 |
| [Spring] 핵심 개념 정리 (Bean, IoC, DI) (0) | 2026.07.02 |
| [Spring] Request DTO는 스프링이 만들어주는데, Response DTO는 왜 내가 만들어야 할까? (0) | 2026.07.01 |
| [Spring 입문] 스프링 전체 흐름 정리 (0) | 2026.06.29 |