세션 vs JWT: 세션을 선택하며 얻은 고찰

대부분의 개발자들이 프로젝트를 시작할 때 회원가입과 로그인을 구현하며 인증 방식을 고민하게 됩니다. 이 과정에서 흔히 접하게 되는 두 가지 방식이 바로 세션(Session)과 JWT(Json Web Token)입니다. "세션과 토큰, 무엇을 써야 할까?"라는 질문은 많은 초보 개발자들이 한 번쯤은 해봤을 법한 고민일 것입니다. 이 문서에서는 세션과 JWT의 차이를 비교하고, 제가 세션 방식을 선택한 이유와 그 과정에서 느낀 점을 정리했습니다.

 

세션과 JWT의 차이점

JWT와 세션은 인증 데이터를 처리하고 관리하는 방식에서 차이를 보입니다. 다음은 두 방식의 주요 차이점을 간단하게 비교한 표입니다.

특징	JWT (JSON Web Token)	세션 기반 인증
저장 위치	클라이언트 (주로 브라우저 로컬스토리지 또는 쿠키)	서버 (세션 ID는 클라이언트 쿠키에 저장)
상태 관리	무상태 (Stateless)	상태 기반 (Stateful)
확장성	분산 시스템에서 유리	단일 서버 환경에서 적합
보안	토큰 탈취 시 악용 가능성, 토큰 무효화 어려움	서버에서 세션 관리, 세션 무효화 쉬움
성능	서버 부하 낮음	서버 메모리 사용량 증가 가능
유효기간 관리	토큰 발급 시 설정된 만료 시간에 의존	세션 만료 시간 서버에서 제어 가능

 

JWT의 특징

JWT는 클라이언트 측에서 인증 정보를 보관하며, 무상태 인증 방식을 따릅니다. 서버는 인증 상태를 유지할 필요가 없어 확장성이 뛰어나며, 분산 환경에서 특히 유리합니다. 그러나 클라이언트에 저장된 토큰이 탈취될 경우 이를 무효화하기 어려운 보안 문제가 있습니다.

jwt 인증 흐름

JWT 기반 인증 흐름

1. 로그인 요청: 사용자가 ID와 비밀번호로 서버에 로그인 요청을 보냅니다.
2. 인증 및 토큰 발급: 서버는 사용자 인증을 수행하고, 성공 시 사용자 정보를 포함한 JWT를 생성하여 클라이언트에 전달합니다.
3. JWT 저장: 클라이언트는 JWT를 로컬 스토리지나 쿠키에 저장합니다.
4. 요청 시 토큰 전송: 이후 클라이언트는 요청 헤더(일반적으로 Authorization: Bearer <JWT>)에 JWT를 포함하여 서버로 전송합니다.
5. 토큰 검증: 서버는 전달받은 JWT의 서명을 검증하여 토큰이 변조되지 않았음을 확인합니다.
6. 요청 처리: 토큰 검증에 성공하면, 서버는 요청을 처리하고 응답을 반환합니다.

장점: 서버가 상태를 관리하지 않으므로 확장성이 높고 분산 시스템에 적합합니다. 
단점: 토큰 만료 전까지 서버에서 강제로 토큰을 무효화하기 어려움(예: 로그아웃 처리)

---

세션의 특징

세션은 서버에서 인증 정보를 관리하며 상태 기반 인증 방식을 사용합니다. 높은 보안성을 제공하며, 실시간으로 세션을 무효화할 수 있는 장점이 있습니다. 하지만 다수의 사용자가 접속하면 서버 메모리 사용량이 증가할 수 있으며, 분산 환경에서는 세션 동기화 문제가 발생할 수 있습니다.

세션 인증 흐름

세션 기반 인증 흐름

1. 로그인 요청: 사용자가 ID와 비밀번호로 서버에 로그인 요청을 보냅니다.
2. 인증 및 세션 생성: 서버는 사용자 인증을 수행하고, 성공 시 고유한 세션 ID를 생성합니다.
3. 세션 저장: 생성된 세션 ID는 서버의 세션 저장소(메모리, DB 등)에 사용자의 상태 정보와 함께 저장됩니다.
4. 세션 ID 전달: 클라이언트에게 세션 ID를 쿠키로 전달합니다. 쿠키는 보통 HttpOnly 속성을 사용해 보안을 강화합니다.
5. 요청 시 세션 확인: 이후 클라이언트가 요청을 보낼 때 세션 ID가 쿠키에 포함되어 서버로 전송됩니다. 서버는 이 세션 ID를 기반으로 저장소에서 사용자 정보를 조회해 인증을 확인합니다.
6. 응답 처리: 인증이 유효하면 서버는 요청을 처리하고 응답을 반환합니다.

장점: 보안성이 높고, 세션 만료, 권한 변경 등을 실시간으로 관리 가능합니다.
단점: 서버에서 세션 데이터를 관리하기 때문에 저장소 및 메모리 부담이 증가할 수 있습니다.

---

세션 기반 인증 방식을 선택하게 된 이유

보안 우선순위

우리 프로젝트는 민감한 데이터를 다루기 때문에 보안이 최우선 과제였습니다. 세션 기반 인증은 서버에서 인증 정보를 관리하여 클라이언트에서 발생할 수 있는 보안 취약점을 최소화할 수 있었습니다. JWT와 비교했을 때, 토큰이 탈취된 경우 이를 강제로 무효화할 수 없다는 문제가 있었으나, 세션 기반 인증은 서버에서 이를 즉시 제어할 수 있었습니다. 특히, HTTPS와 쿠키 설정(Secure, HttpOnly) 등을 통해 세션 탈취를 방지하는 추가적인 보안 조치도 가능합니다.

실시간 제어 필요성

사용자가 로그아웃하거나, 권한이 변경되었을 때 인증 상태를 즉각적으로 변경해야 하는 요구사항이 있었습니다. JWT는 무상태 방식으로 한 번 발급된 토큰을 실시간으로 무효화하기 어려운 반면, 세션은 서버에서 세션 데이터를 삭제함으로써 즉시 인증 상태를 제어할 수 있었습니다. 이러한 실시간 제어는 보안성을 더욱 높이는 데 기여했습니다.

단일 서버 환경

프로젝트 초기 단계에서는 단일 서버로 시스템을 운영할 계획이었기 때문에, 세션 기반 인증으로 인한 서버 메모리 사용 부담이 크지 않았습니다. 또한, 분산 환경에서 발생할 수 있는 세션 동기화 문제를 고려하지 않아도 되므로, 세션 기반 인증이 더 적합한 선택이었습니다.

---

세션을 왜 사용하셨는데요?

세션 기반 인증을 선택한 이유는 다음과 같습니다.

 

실시간 인증 관리: 세션 기반 인증은 로그아웃, 세션 만료, 권한 변경과 같은 작업을 서버에서 즉시 처리할 수 있습니다. 이는 사용자의 행동에 따라 빠르게 대응해야 하는 프로젝트 특성과 잘 맞아떨어졌습니다. 이 과정에서 기술의 장단점만이 아니라 환경과 목적을 기준으로 결정을 내려야 합니다.

 

프로젝트 요구사항 부합: 이번 프로젝트에선 특히 보안과 실시간 관리가 중요한 환경이었습니다. JWT도 고려했지만, 인증 방식의 선택은 단순한 기술적 장단점보다 프로젝트의 목적과 특성을 더 우선시해야 한다는 점을 다시금 깨닫게 되었습니다.

 

보안 강화: 세션은 서버에서 데이터를 관리하기 때문에 클라이언트 측에서 인증 정보가 노출될 위험이 적습니다. 프로젝트 초반에는 JWT의 확장성과 독립성이 매력적으로 보였지만, 보안 요구사항을 면밀히 검토하면서 세션의 장점이 더 중요하다는 결론에 도달했습니다.

---

세션을 어떻게 하면 잘 사용할 수 있을까요?

안전한 세션 관리를 위한 팁

1. 보안 강화:
   • HTTPS를 통해 네트워크에서 세션 ID가 탈취되지 않도록 합니다.
   • Secure 및 HttpOnly 옵션을 설정해 클라이언트에서 세션 쿠키를 보호합니다.
2. IP 및 브라우저 정보 확인:
   • 세션에 로그인 시점의 IP와 브라우저 정보를 저장하고, 매 요청 시 이를 검증하여 세션 하이재킹 공격을 방지합니다.
3. 효율적인 세션 관리:
   • 만료된 세션을 주기적으로 삭제하여 서버 자원을 절약합니다.
   • Redis와 같은 분산 캐시를 활용해 세션 동기화를 처리합니다.
4. 로그아웃 처리:
   • 사용자가 로그아웃 시 서버에서 세션 데이터를 즉시 삭제하여 보안을 강화합니다.

---

세션은 언제 사용될까요?

세션은 다음과 같은 상황에서 유용하게 사용됩니다:

1. 전통적인 웹 애플리케이션: 브라우저 기반 애플리케이션에서 세션은 간단하고 효과적인 인증 방식입니다.
2. 보안이 중요한 애플리케이션: 금융, 헬스케어와 같은 민감한 데이터를 다루는 서비스에서는 세션 기반 인증이 더 안전합니다.
3. 단일 서버 환경: 서버가 단일하거나 적은 경우, 세션 기반 인증은 성능과 관리 면에서 적합합니다.
4. 로그아웃 및 세션 관리가 중요한 환경: 사용자가 로그아웃하거나 특정 상황에서 인증을 실시간으로 제어해야 하는 시스템에 적합합니다.

---

세션 관리 시 주의해야 할 보안 이슈

세션 ID 관련 공격

1. 세션 ID 추측:
   • 세션 ID 생성 알고리즘이 약할 경우, 제3자가 이를 추측하여 세션 하이재킹 공격을 시도할 수 있습니다.
2. 세션 ID 훔치기:
   • 네트워크 패킷 스니핑을 통해 세션 ID를 탈취하는 공격입니다. HTTPS로 이를 방지할 수 있습니다.
3. 세션 ID 고정:
   • 공격자가 사용자의 브라우저에 미리 세션 ID를 설정하고, 이를 악용해 세션을 탈취하는 방식입니다.
4. XSS를 통한 세션 유출:
   • 크로스 사이트 스크립팅(XSS) 공격으로 클라이언트의 세션 ID를 탈취할 수 있습니다. 이를 방지하기 위해 HttpOnly 옵션을 설정해야 합니다.

---

기업들이 세션 방식을 선호하는 이유

정보에 대한 주도권 확보

세션 기반 인증은 서버에서 인증 정보를 관리하기 때문에, 세션이 악용되더라도 서버에서 인지하는 즉시 대응이 가능합니다. 반면, JWT는 클라이언트 측에서 관리되므로, 토큰 탈취 시 이를 즉각적으로 무효화하기 어려운 단점이 있습니다. 기업들은 이러한 이유로 성능보다 보안을 우선시하며, 민감한 데이터를 다루는 서비스에서는 안전성을 선택할 수밖에 없습니다.

정보 활용의 용이성

세션은 사용자의 행동 데이터를 수집하고 분석하는 데 유리합니다. 예를 들어, 마지막 로그인 시간, 서비스 이용 시간 등을 저장하여 사용자 경험을 개선할 수 있는 맞춤형 서비스를 제공할 수 있습니다. 이러한 데이터 활용은 비즈니스적으로도 중요한 가치로 이어집니다.

기존 시스템과의 호환성

세션 방식은 오래된 인증 방식으로, 많은 시스템에서 기본적으로 채택되어 왔습니다. 기존 세션 기반 서비스를 JWT로 전환하려면 상당한 시간과 비용이 소요되기 때문에, 전환의 어려움이 기업들이 세션 방식을 계속 사용하는 또 다른 이유가 됩니다.

---

결론

JWT와 세션 기반 인증은 각각의 장단점이 있으며, 프로젝트 특성에 따라 적절한 방식을 선택하는 것이 중요합니다. 이번 프로젝트에서는 다음과 같은 이유로 세션 기반 인증을 선택했습니다.

1. 보안이 중요한 환경에서 세션 기반 인증의 안전성
2. 로그아웃 및 세션 제어가 필요한 요구사항
3. 단일 서버 기반 환경에서의 적합성

느낀 점

번외로, 프로젝트를 진행하며 깊게 고민했던 점과 이를 통해 생긴 나만의 개발 가치관에 대해 이야기해보고자 합니다. 단순히 기능을 구현하는 것을 넘어, 코드의 의미와 역할에 대해 생각하는 시간이 많아졌습니다.

혼자 이해할 수 있는 코드, 확장성과 변화에 닫혀 있는 코드는 결국 누군가에게 부담이 되고, 협업을 어렵게 만든다는 걸 느꼈습니다. 반대로, 함께 작업하는 동료들의 입장을 고려하며 작성한 코드는 더 나은 결과물을 만들어 낸다고 생각합니다.

코드뿐만 아니라 관계도 마찬가지라는 것을 깨달았습니다. 타인을 배려하고, 그 기대에 부응하려는 마음이 성장으로 이어지고, 더 나은 개발자로 만들어 준다는 것을 실감했습니다. 이 깨달음은 혼자만의 것이 아닌, 주변의 동료들과 함께 쌓아 올린 것이라 더 소중하게 느껴집니다. 이런 경험들이 제게 큰 감사함과 성장의 동력을 주었고, 앞으로도 함께 나아가는 개발자가 되고 싶네요 ㅎㅎ

 

Reference

https://overcome-the-limits.tistory.com/518

[Web] 세션을 알아보자

https://f-lab.kr/insight/understanding-session-management-and-jwt

세션 관리와 JWT의 역할 이해하기

https://f-lab.kr/insight/jwt-vs-session-authentication-20240823?gad_source=1&gbraid=0AAAAACGgUFe1l3NHnR4Gov-V8it067y90&gclid=CjwKCAiAgoq7BhBxEiwAVcW0LNS3wohmo-U_AbFmKq1PeN9xBcUye6Bw4M0VzuqdndfOFS77H26b_BoCHggQAvD_BwE

JWT와 세션 기반 인증의 차이점과 선택 기준

https://f-lab.kr/insight/session-based-login-security-20240519

세션 기반 로그인 구현 시 보안 고려사항