[ FINSight ] 단일 서버 환경에서 JWT 대신 Session을 선택한 이유

들어가며

프로젝트를 시작하면서 가장 먼저 마주한 기술적 선택은 "인증 방식을 어떻게 할 것 인가?" 였습니다.

저는 스파르타 내일배움캠프 Spring 7기 수강생입니다. 부트캠프를 진행할 당시에 세션과 JWT를 모두 배워서 프로젝트에 적용시킨 경험이 있었습니다. 하지만 시간이 지날수록 모든 수강생들은 세션 기반 인증인가보다는 모두 JWT 기반 인증인가로 처리하였습니다. 이번 시간에는 저희가 왜 JWT 말고 Session을 사용하였는지 말씀드리겠습니다.

---

1. JWT vs Session

1.1 JWT

핵심 : Stateless (서버가 상태를 저장하지 않음)

 

1.2 Session

핵심: Stateful (서버가 상태를 저장함)

---

2. JWT의 장점과 단점

2.1 장점

2.1.1 수평 확장에 유리

2.1.2 마이크로서비스 아키텍처(MSA)에 적합

2.1.3 모바일 앱과 호환성

쿠키를 사용하기 어려운 모바일 환경에서 JWT를 헤더에 담아 보내면 됩니다.

 

정리: JWT는 서버가 상태를 저장하지 않기 때문에, 로드밸런서를 사용한 스케일 아웃(다중 서버) 또는 MSA 같이 여러 서버의 인증을 사용하는 경우에 사용이 적합합니다.

 

2.2 단점

2.2.1 토큰 탈취 시 서버에서 무효화 불가능

- 해결책으로 Refresh 토큰을 도입하고, Access 토큰의 만료 기간을 짧게 가져가지만, 이는 복잡도를 크게 증가시키고, 결국 Refresh 토큰을 서버에서 관리한다면 Stateful한 특성이 사라집니다.

---

3. Session의 장점과 단점

3.1 장점

3.1.1 즉시 무효화 가능

- 서버가 세션을 관리하는 Stateful한 상태이므로, 언제든지 세션을 무효화할 수 있습니다.(ex. 로그아웃)

3.1.2 보안성

- JWT 토큰 안에는 사용자의 정보가 담겨있지만, Session은 쿠키에 JSESSIONID만 담겨있습니다.

 

3.2 단점

3.2.1 수평 확장 시 세션 공유 필요

- 여러 서버를 운영할 경우(스케일 아웃, MSA), Redis 등 공유 메모리를 통해서 세션을 공유해야 합니다.

---

4. 프로젝트 상황 분석

- 위의 사진은 저희 FINSight 프로젝트의 ver1.0의 시스템 아키텍처입니다.

- 현재 NCP 서버를 1개(단일 서버)에 배포를 진행한 상태입니다.

- 단일 서버에서는 stateless한 특성이 필요없으므로 보안적으로 더 뛰어난 Session을 선택하였습니다.

- 추후에 트래픽이 증가한다면, 로드밸런서를 사용한 다중 서버 또는 마이크로서비스 아키텍처(MSA)로 전향할 때 JWT 토큰을 사용할 예정입니다.

---

마치며

기준	JWT	Session	선택
수평 확장	⭐⭐⭐	⭐	불필요
보안성 (즉시 무효화)	⭐	⭐⭐⭐	중요
구현 복잡도	⭐	⭐⭐⭐	Spring Security 활용
단일 서버 최적화	⭐	⭐⭐⭐	필요

 

이번 프로젝트를 통해 "유행하는 기술"이 아닌 "적합한 기술"을 선택하는 것의 중요성을 깨달았습니다.

 

부트캠프에서 모든 수강생들이 JWT를 사용하는 것을 보며, 처음에는 저도 JWT를 써야 하나 고민했습니다.

하지만 우리 프로젝트의 실제 요구사항과 환경을 분석해보니 단일 서버 환경에서는 Session이 훨씬 더 적합한 선택이었습니다.

 

JWT의 Stateless 특성은 분산 환경에서 빛을 발하지만, 단일 서버에서는 오히려:

- Refresh Token 관리로 인한 복잡도 증가

- 즉시 무효화 불가능으로 인한 보안 취약점

- 불필요한 오버 엔지니어링

 

이라는 문제만 가져왔을 것입니다.

 

"모든 프로젝트에 정답은 없다"는 것을 다시 한번 느꼈습니다. 현재 우리 프로젝트에는 Session이 최선이지만, 추후 트래픽이 증가하여 로드밸런서와 다중 서버 환경으로 전환한다면 그때는 JWT나 Redis 기반 세션 공유를 고려할 것입니다. 기술 선택의 기준은 "이 기술이 얼마나 핫한가?"가 아니라 "우리 프로젝트에 지금 필요한가?"여야 한다는 것을 배운 값진 경험이었습니다.