본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 열아홉번째 날입니다.
열여덟번째 날에는 왜 JPA를 선택했나 ORM과 SQL Mapper의 차이는 무엇인가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 3. 채팅 서비스 핵심 기능 개발 > Ch 2. 사용자 인증과 등록 추가 그리고 레디스 연동 >
01. 왜 Http Session을 선택했나. Cookie, Http Session, JWT의 차이
입니다.
🔐 왜 HTTP 세션을 선택했나? Cookie, HTTP Session, JWT의 차이
- 채팅 서비스 개발에서는 사용자의 로그인 상태를 유지하고
웹소켓 접속을 제어하기 위한 세션 관리 방식이 중요합니다. - 이번 포스팅에서는 대표적인 세 가지 방식인 Cookie, HTTP 세션, JWT(Json Web Token)의 차이를 살펴보고 왜 우리 프로젝트에서는 HTTP 세션을 선택했는지 설명하도록 하겠습니다.
🍪 Cookie – 클라이언트 중심 저장소
- 가장 기초적인 세션 방식은 Cookie입니다. 클라이언트에 데이터를 저장하며, 요청 시마다 이를 서버에 전송합니다. 웹 브라우저는 물론, 네이티브 앱도 Cookie 사용이 가능합니다.
- 보안: 민감한 데이터 저장은 금물. 사용자가 내용을 볼 수 있고, 조작도 가능.
- 크기 제한: 1개당 4KB 정도. 브라우저마다 총 사용 가능량에도 제한 있음.
- 확장성: 서버가 상태 정보를 직접 저장하지 않아 분산 서버 환경에서 유리.
- 구현 난이도: HTTP 라이브러리 대부분이 기본 지원. 비교적 간단.
- 단, 서버는 능동적인 세션 제어가 어렵고, 보안 측면에서도 취약하므로 주로 세션 ID나 토큰 전달용으로 사용됩니다.
🧾 HTTP 세션 – 서버 중심의 상태 관리
- HTTP 세션은 세션 ID만 클라이언트에 저장하고, 실제 데이터는 모두 서버에 저장합니다. 클라이언트가 요청 시 세션 ID를 보내면, 서버가 해당 정보를 조회해 사용자를 식별합니다.
- 보안: 클라이언트는 데이터를 직접 접근/수정 불가. 보안성 우수.
- 크기 제한: 명시적 제한 없음. 다만 서버 메모리 사용량 증가 가능성 있음.
- 상태 관리: 서버가 세션을 능동적으로 조회, 갱신, 만료 가능.
- 확장성: 서버가 여러 대일 경우 세션 동기화가 필요. 이를 위해 Redis 등 인메모리 저장소 활용.
- 구현 난이도: Spring Boot + Redis 연동으로 쉽게 설정 가능.
- 우리 프로젝트처럼 실시간 연결 상태를 관리해야 하는 경우, HTTP 세션은 유저의 온라인 상태를 서버가 직접 감지하고 제어하기에 매우 유리합니다.
🔐 JWT – 자체 포함된 인증 토큰
- JWT는 사용자 정보와 권한 등을 토큰 자체에 포함하여 클라이언트에 저장하고 요청 시마다 함께 전송합니다.
- 보안: 인코딩은 돼 있지만 암호화는 아님. 서명(JWS)으로 변조만 방지.
- 크기 제한: 명시적 제한은 없으나, 일반적으로 8KB 이하가 권장됨.
- 상태 관리: 클라이언트 중심이라 서버가 능동적 제어 불가. 만료된 토큰도 직접 요청이 오기 전까진 모름.
- 확장성: 서버 간 동기화 불필요. 어떤 서버로 요청해도 무방.
- 구현 난이도: 엑세스 토큰 + 리프레시 토큰 관리 등으로 다소 복잡.
- JWT는 무상태(stateless) 서비스에 적합하지만, 실시간 연결 유지가 중요한 우리 채팅 서비스에는 아쉬운 점이 많았습니다.
✅ 왜 HTTP 세션을 선택했는가?
- JWT는 사용자 정보와 권한 등을 토큰 자체에 포함하여 클라이언트에 저장하고 요청 시마다 함께 전송합니다.
- 유저의 온라인 상태 모니터링이 핵심이기 때문입니다.
JWT처럼 클라이언트가 모든 걸 관리하면 서버는 상태를 모를 수 있습니다.
HTTP 세션을 사용하면 서버가 사용자의 로그인/접속 상태를 직접 확인하고 제어할 수 있습니다. - Spring Boot + Redis 연동으로 구현이 간편하고 유연합니다.
추후 JWT로 교체할 수도 있도록 구조를 단순하게 유지하면서도
실시간 서비스에 필요한 상태 관리 기능을 확보할 수 있습니다. - 개발 중 디버깅 및 테스트가 용이합니다.
세션 데이터를 직접 확인하고 조작할 수 있어,
기능 점검이 빠르고 확실합니다.
- 유저의 온라인 상태 모니터링이 핵심이기 때문입니다.
- 이번 선택은 기술 자체보다 문제 해결 관점에서 결정되었습니다. 보안이나 성능, 확장성은 모두 중요하지만, "우리 서비스에서 진짜 중요한 건 무엇인가?" 를 먼저 정의하는 게 핵심이었습니다.
- JPA를 선택했던 이유처럼, 기술 도구의 장단점을 알고만 있는 것보다, "왜 그걸 선택했는가?"를 설명할 수 있는 능력이 개발자의 실력이고, 기획자나 협업자와의 신뢰로 이어집니다.
- 기술은 계속 바뀌지만 문제를 바라보는 방식과 선택의 기준은 오래 갑니다.
