[Security] API 보안의 핵심: Session vs JWT 완벽 비교 가이드

백엔드 개발자라면 프로젝트 설계 단계에서 반드시 마주하는 난제가 있습니다. 바로 "세션(Session)으로 갈 것인가, JWT(Token)로 갈 것인가?"입니다.

과거에는 세션이 당연한 정석이었지만, 최근에는 너도나도 JWT를 사용하는 추세입니다. 하지만 유행이라고 해서 무조건 JWT가 정답은 아닙니다. 오늘 두 방식의 차이점을 뼈 때리는 팩트와 함께 완벽히 비교해 보겠습니다.

---

1. 한눈에 보는 비교표

구분	세션 (Session)	JWT (JSON Web Token)
저장 위치	서버 메모리 또는 DB	클라이언트 (브라우저, 앱)
상태 유지	Stateful (상태 유지)	Stateless (무상태)
확장성	낮음 (서버 간 공유 설정 필요)	높음 (서버가 늘어나도 무관)
보안 제어	서버가 세션을 강제 만료 가능	유효 기간 전까지 만료 불가
데이터 크기	매우 작음 (ID만 전송)	큼 (사용자 정보 포함)

---

2. 세션(Session)의 한계: 왜 서버 확장의 걸림돌인가?

세션 방식의 가장 큰 문제는 "서버가 기억력이 좋아야 한다"는 점입니다.

1. 메모리 부하: 접속자가 10만 명이라면 서버 메모리에 10만 개의 세션 객체가 상주해야 합니다.
2. Scalability(확장성) 이슈:
   • 서비스가 잘 되어 서버를 1대에서 3대로 늘렸다고 가정합시다.
   • 사용자가 서버 A에서 로그인했는데, 다음 요청이 서버 B로 가면? 서버 B에는 세션 정보가 없어 다시 로그인을 요구하게 됩니다.
   • 이를 해결하기 위해 Sticky Session이나 Redis 같은 외부 저장소를 써야 하는데, 이 자체가 관리 포인트와 비용이 됩니다.

---

3. JWT의 매력: 서버는 아무것도 기억하지 않는다

JWT는 "열쇠에 모든 정보를 담아 손님에게 맡기는 방식"입니다.

• 구조적 장점: 토큰 안에 유저의 권한, 만료 시간 등이 다 들어있어 서버는 받은 토큰의 서명(Signature)이 유효한지만 검증하면 끝납니다. 어떤 서버로 요청이 가든 상관없습니다.
• 비용 절감: 서버는 세션 저장소를 조회할 필요가 없으므로 DB 부하가 줄어들고 로직이 단순해집니다.

---

4. JWT의 아킬레스건: "한번 내뱉은 말은 주워 담을 수 없다"

JWT가 만능 같지만 치명적인 단점이 있습니다.

1. 통제 불가: 토큰이 탈취되어도 서버가 강제로 그 토큰을 무효화할 방법이 없습니다. 유효기간이 1시간이라면 공격자는 1시간 동안 주인 행세를 할 수 있습니다.
2. 데이터 노출: Base64로 인코딩된 것뿐이라 누구나 내용을 볼 수 있습니다. (민감 정보 노출 위험)
3. 무거운 무게: 페이로드가 커질수록 네트워크 트래픽에 영향을 줍니다.

---

5. 실무의 정답: Refresh Token 도입의 필요성

JWT의 보안 취약점을 보완하기 위해 실무에서는 2중 토큰 전략을 사용합니다.

• Access Token: 수명이 매우 짧음 (15분~30분). 실제 인증에 사용.
• Refresh Token: 수명이 김 (1~2주). Access Token이 만료되었을 때 갱신하는 용도.

공격자가 Access Token을 훔쳐가도 곧 만료되므로 피해를 최소화할 수 있고, 만약 심각한 위협이 감지되면 서버 DB에서 Refresh Token을 삭제하여 더 이상 갱신이 안 되게 막는(강제 로그아웃) 하이브리드 전략을 취합니다.

---

6. 결론: 무엇을 선택해야 할까?

✅ 이런 경우 세션(Session)을 추천합니다.

• 사용자 수가 서버 1대로 감당 가능한 수준이거나, Redis 같은 세션 공유 인프라가 갖춰진 경우.
• 보안이 극도로 중요하여, 관리자가 언제든 특정 유저의 접속을 끊어야 하는 경우.
• 중복 로그인을 철저히 막아야 하는 경우.

✅ 이런 경우 JWT를 추천합니다.

• 서버 확장이 빈번하고, MSA(마이크로서비스) 구조를 지향하는 경우.
• 웹뿐만 아니라 모바일 앱(iOS/Android)과의 통합 인증이 필요한 경우.
• 서버의 메모리 자원을 최대한 아끼고 싶은 경우.

---

🏁 마치며

세션과 JWT는 유행의 문제가 아니라 트레이드오프(Trade-off)의 문제입니다. 우리 서비스의 규모가 얼마나 큰지, 보안 정책이 얼마나 까다로운지에 따라 최적의 도구는 달라집니다.

"남들이 다 JWT 쓰니까 우리도 써야지"라는 생각보다, 각 방식의 한계를 정확히 알고 그에 맞는 방어책을 세우는 것이 진짜 실력 있는 백엔드 개발자의 자세입니다.