HTTP 세션 유지와 관련된 고민
지난 글에서 HTTP 요청/응답에 대해 알아보았고 HTTP 세션을 설명하며 문득 든 생각들이 있었다.
- 세션이 만료되면 사용자 입장에서는 어떻게 되는 걸까?
- 세션을 너무 오래 유지하면 왜 문제가 될까?
- 서버가 여러 대일 때, 세션을 어떻게 공유해야 할까?
이번 글에서는 이 세 가지 질문을 중심으로
내가 공부하고 이해한 내용을 정리해봤다.
1. 세션이 만료되면 사용자에게 어떤 경험이 될까?
세션은 일반적으로 사용자가 일정 시간 동안 아무 요청도 하지 않으면 자동으로 만료된다.
Spring Boot 기본 세션 유효 시간은 30분이다.
내가 겪은 문제
사용자가 로그인하고 사이트를 켜둔 채 30분 넘게 아무 행동을 하지 않으면,
다시 페이지를 이동할 때 로그인이 풀려버리는 현상이 발생했다.
사용자 입장에서는 갑자기 로그인이 해제된 느낌을 받았고, 심지어 작성 중이던 내용이 사라지기도 했다.
배운 점
- 세션 만료는 보안과 서버 리소스 절약을 위한 필수 기능이다.
- 하지만 사용자 경험 측면에서는 갑작스러운 만료가 당황스러울 수 있다.
- 이를 방지하려면
- 사용자에게 세션 만료까지 남은 시간을 안내하거나,
- 일정 시간마다 백그라운드에서 자동 요청을 보내 세션을 갱신하는 방식(keep-alive)이 필요하다.
2. 세션을 너무 오래 유지하면 무슨 일이 생길까?
한번 로그인하면 무제한으로 세션을 유지하게 만드는 것도 간단하다.
하지만 이건 또 다른 문제를 낳는다.
왜 문제가 되는가?
- 세션 정보는 보통 서버 메모리나 Redis와 같은 저장소에 보관된다.
- 사용자가 많아질수록 유지해야 할 세션 정보도 많아지고, 수십만 명 단위로 올라가면 메모리 사용량이 급격히 증가한다.
해결 방안
- 일반적으로 세션 만료 시간은 30분 ~ 1시간으로 설정
- 민감한 서비스(은행, 병원)는 더 짧게, 커뮤니티/게시판은 더 길게
- 장시간 사용자가 많은 경우 로그인 유지 기능(JWT 토큰 + Refresh Token)으로 대체
3. 분산 서버 환경에서는 세션을 어떻게 공유할까?
처음에는 단일 서버에서만 서비스하니까 세션 관리도 간단하다.
하지만 수평 확장(서버를 여러 대로 늘리는 구조)을 고민하면서 새로운 문제가 생긴다.
문제 상황
- 사용자가 로그인했는데,다음 요청은 다른 서버로 전달되어 세션이 없는 상태로 처리됨
- 사용자 입장에서는 로그인이 풀리는 듯한 현상을 겪음
해결 방법
| 방식 | 설명 | 장단점 |
| Sticky Session | 로드밸런서가 항상 같은 서버로 요청을 보냄 | 설정은 간단하지만 서버 장애 시 취약 |
| 세션 공유 DB | 세션 정보를 DB나 Redis에 저장해서 모든 서버가 공유 | 일반적이고 안정적, Redis 사용 추천 |
| JWT 방식 | 세션 없이 토큰만으로 상태 유지 (Stateless) | 완전한 분산에 적합, 재발급/보안 관리 필요 |
마치며
처음에는 HttpSession 하나로 끝나는 문제라 생각했다.
하지만 실제 운영을 고려하면, 세션 하나에도 사용자 경험, 보안, 리소스 관리. 인프라 구조
이 모든 것이 얽혀 있다는 걸 알게 되었다.
이제는 세션을 설계할 때 "그게 어떻게 동작하는가?”보다는
“이 세션은 어떤 조건에서 만들어지고, 언제 만료되고, 여러 서버에서 어떻게 관리되는가?”
이 질문부터 던지게 될 것 같다.
앞으로 JWT, OAuth2 같은 토큰 기반 인증까지 확장하면서
진짜 서비스에서 상태를 어떻게 유지하고, 보안과 사용자 편의를 함께 지킬 것인가에 대한 고민을 더 해볼 것이다.