면접에서 웹 페이지를 구현할 때 인증 시스템을 어떻게 설계할 건가요?
라고 물어본다면 뭐라고 대답을 할 것인지 고민해 본다.
나는 세션은 다뤄본적이 없어서 JWT를 사용한다고 말할 것이다.
물론 이렇게 대답하면 무조건 면접에서 떨어진다.
이 질문은 초보자와 숙련된 개발자 모두에게 일반적으로 묻는 질문이다.
특히 이력서에 JWT를 언급한 경우 더욱 그렇다.
그러면 어떤 대답이 정답일까?
기업들은 어떤 답변을 기대하고 있을까?
이 질문에 대한 완벽한 답변을 해주는 좋은 글을 발견해서 기록해본다.
세션과 JWT의 진정한 트레이드오프는 무엇이며, 어떤 상황에서 어떤 선택을 해야 하는지 알려주는 글이다.
세션 기반 인증
세션 기반 인증은 서버 측에 세션 정보를 저장하고 사용자에게 세션 ID를 제공하여 요청을 인증하는 방식으로 작동한다.
이를 항공권에 비유해 본다. 사용자는 항공권 ID를 보유하고 항공사는 모든 관련 세부 정보를 데이터베이스에 보관한다.
세션 기반 인증 작동 방식
1. 사용자가 로그인하면 프런트엔드가 백엔드 서버로 자격 증명을 전송한다.
2. 백엔드는 비밀 키를 사용하여 세션을 생성하고 세션 데이터를 데이터베이스 또는 세션 저장소에 저장한다.
3. 서버는 고유한 세션 ID가 포함된 쿠키를 사용자의 브라우저로 전송한다.
4. 이후 요청의 경우 브라우저는 헤더에 세션 ID를 포함합니다.
5. 서버는 세션 ID를 검증하고 액세스 권한을 부여합니다.
실제로 세션기반 인증이 작동하는 방식은 다음과 같습니다.
세션 기반 인증의 장점
프로젝트에서 세션 기반 인증을 사용하는 주요 이점은 다음과 같다.
- 무효화가 간단함: 사용자가 로그아웃하면 서버에서 그 사람의 세션 정보를 지우기만 하면 끝.
- 중앙에서 관리 가능: 모든 세션 정보를 서버 한곳에서 관리하기 때문에, 누가 로그인 중인지, 어떤 세션이 유효한지 한눈에 확인하고 관리하기 쉬움.
세션 기반 인증의 단점
- 확장성 문제: 사용자 수가 늘어나면 세션 저장소에 병목 현상이 발생할 수 있습니다.
- 세션 상태를 유지하기 위한 서버에 대한 종속성.
쉽게 말하면,
- 확장성 문제: 사용자가 많아지면 세션을 저장하는 서버가 버거워질 수 있음.
- 서버 종속성: 세션 정보를 서버가 관리해야 하니까 서버가 꺼지거나 문제가 생기면 인증도 엉망이 됨.
JWT 기반 인증
JWT(JSON 웹 토큰) 인증은 다르게 작동한다. 여기서 세션 정보는 토큰에 직접 내장되고, 토큰은 서명되어 사용자와 공유된다.
이는 모든 여행 세부 정보가 안전하게 인코딩되어 있는 항공권과 같다.
JWT기반 인증 작동 방식
1. 사용자가 로그인하면 백엔드가 자격 증명을 검증한다.
2. 서버는 개인 키를 사용하여 서명된 JWT를 발행한다. 세션 저장소는 필요하지 않다.
3. JWT는 사용자의 브라우저로 전송된다.(일반적으로 쿠키를 통해 전송된다.)
4. 이후의 각 요청에 대해 브라우저는 헤더와 함께 JWT를 전송한다.
5. 서버는 JWT를 검증하고 토큰에서 사용자 정보를 추출한다.
실제로 JWT 기반 인증이 작동하는 방식은 다음과 같습니다.
JWT의 장점
애플리케이션에서 인증을 위해 JSON 웹 토큰을 사용하는 주요 이점은 다음과 같습니다.
- 무상태: 서버에 세션 저장 공간이 필요 없어서 확장하기 쉽고, 여러 서버에서도 문제 없음.
- 이식성: 토큰만 있으면 다른 서비스나 도메인에서도 바로 사용 가능. 서버끼리 정보를 공유할 필요 없음.
JWT 단점
- 무효화 어려움: 토큰이 만료되기 전에 사용을 막으려면 복잡한 방법이 필요함.
- 오래된 데이터: 토큰에 담긴 정보는 발행 시점 그대로라, 바뀐 정보를 반영하지 못함.
- 큰 크기: 토큰에 정보가 많아서 크기가 커질 수 있고, 전송 비용이 늘어남.
세션 vs. JWT: 어느 것이 더 낫나?
둘 중 어느 것이 더 낫다고 딱 잘라 말하기는 어렵다. 왜냐하면 "상황에 따라 다르기" 때문이다. 각 방식은 사용하는 애플리케이션의 요구 사항과 보안 필요성에 따라 장단점이 뚜렷하다.
세션을 사용하는 경우
세션은 서버가 사용자 상태를 직접 관리하는 방식으로, 다음과 같은 상황에서 유리하다:
- 세션 무효화와 실시간 사용자 상태 관리가 중요할 때
사용자가 로그아웃하면 서버에서 세션 정보를 바로 삭제할 수 있어 실시간으로 제어가 가능하다. 특히 보안에 민감한 애플리케이션(예: 은행, 전자상거래)에서는 필요 시 바로 계정을 잠그거나 세션을 종료할 수 있다는 점이 큰 장점이다. - 로그인한 사용자를 간편하게 관리하고 싶을 때
모든 세션 정보가 서버에 저장되므로, 로그인한 사용자들을 중앙에서 쉽게 추적하고 관리할 수 있다. 예를 들어, 관리자가 현재 접속한 사용자 목록을 확인하거나 특정 사용자만 로그아웃시키는 등의 작업이 간단하다.
JWT를 언제 사용해야 하나요?
JWT는 무상태 인증 방식으로, 토큰을 통해 인증 정보를 주고받는다. 이런 방식은 다음과 같은 상황에서 강점을 발휘한다:
- 확장성과 이동성이 중요한 경우
서버가 세션을 관리하지 않으므로, 여러 서버에 걸쳐 분산된 시스템에서도 문제가 없다. 토큰은 사용자와 함께 이동하기 때문에, 마이크로서비스 환경이나 여러 도메인(예: 웹앱과 모바일 앱)을 사용하는 애플리케이션에 적합하다. - 서버의 인증 종속성을 줄이고 싶을 때
JWT는 토큰에 인증 정보를 담고 있어, 서버가 상태를 유지할 필요가 없다. 서버 간 정보를 공유할 필요 없이 토큰만 확인하면 인증이 완료되므로, 단순하면서도 유연한 구조를 제공한다.
추가로 알아두면 좋은 점
세션은 서버 중심이라 높은 보안을 제공하지만, 사용자 수가 늘어나면 확장성이 떨어질 수 있다. 세션 정보를 저장하기 위한 별도의 저장소(예: Redis)가 필요하기도 하다.
JWT는 클라이언트 중심이라 확장성이 좋지만, 토큰이 만료되기 전까지 무효화가 어려운 점(예: 탈취된 토큰 악용 가능성)이 단점이다. 또한, 토큰 크기가 커지면 네트워크 비용이 증가할 수 있다.
면접에서 "세션 vs. JWT" 질문에 대답하는 법
면접에서 중요한 건 단순한 지식 전달이 아니라, 자신의 이해력과 실무적 사고를 보여주는 것. 이 질문에 답할 때는 아래와 같은 흐름으로 설명하면 돋보일 수 있음:
1. 세션과 JWT의 기본 워크플로 간단 설명
- 세션 기반 인증:
사용자가 로그인하면 서버에서 세션 ID를 생성하고, 이를 클라이언트에게 쿠키로 전달. 서버는 모든 세션 상태를 중앙에서 관리하며, 요청이 올 때마다 쿠키의 세션 ID를 확인해 인증. - JWT 기반 인증:
사용자가 로그인하면 서버가 서명된 JWT 토큰을 생성하고 클라이언트에 전달. 클라이언트는 이 토큰을 저장하고 이후 요청마다 함께 보냄. 서버는 토큰만 검증하고 상태를 따로 관리하지 않음(무상태).
2. 각 방식의 장단점 요약
- 세션 기반 인증의 장점:
- 로그아웃, 계정 잠금 등 실시간 상태 관리가 쉬움.
- 중앙에서 사용자 세션을 추적하고 관리 가능.
- 세션 기반 인증의 단점:
- 사용자 수가 늘어나면 세션 저장소가 병목이 될 수 있음.
- 서버에 세션 정보를 유지해야 하므로, 서버 종속적임.
- JWT 기반 인증의 장점:
- 무상태라 서버에 세션 저장 공간이 필요 없고, 확장성에 유리.
- 토큰만 있으면 여러 서비스와 도메인 간 인증 가능(이식성).
- JWT 기반 인증의 단점:
- 무효화가 어려움: 발급된 토큰은 만료 전까지 유효.
- 발행 당시의 정보만 담겨 있어 데이터 최신성 부족.
- 토큰 크기가 커서 전송 비용이 늘어날 수 있음.
3. 실제 시나리오로 차이점 강조
이론만 말하면 밋밋할 수 있으니, 실제 사례로 연결:
- 세션이 적합한 경우:
"만약 우리가 은행 애플리케이션을 개발한다면, 로그아웃이나 계정 잠금이 즉시 반영되어야 하기 때문에 세션 기반 인증이 적합합니다. 관리자는 현재 로그인 중인 사용자들을 쉽게 추적할 수도 있죠." - JWT가 적합한 경우:
"반대로, 마이크로서비스 환경에서 여러 서비스가 인증 정보를 공유해야 한다면 JWT가 더 적합합니다. 서버가 상태를 유지하지 않으니 확장이 쉽고, 각 서비스가 독립적으로 인증을 처리할 수 있기 때문입니다."
4. 후속 질문에 대비하기
면접관은 당신의 대답을 기반으로 추가 질문을 던질 가능성이 높음. 몇 가지 예를 들어 준비해두면 좋음:
- Q1. 세션과 JWT를 함께 사용하는 하이브리드 접근법이 있을까요?
- "가능합니다. 예를 들어, 중요한 데이터의 상태 관리에는 세션을 사용하고, API 요청에는 JWT를 사용해 확장성을 유지하는 방식입니다."
- Q2. JWT의 무효화 문제를 어떻게 해결할 수 있나요?
- "짧은 만료 시간을 설정하고, 새로 고침 토큰(refresh token)을 사용하는 방법이 있습니다. 이외에도 서버에서 별도의 블랙리스트를 유지해 유효하지 않은 토큰을 차단할 수도 있습니다."
- Q3. 보안 문제를 어떻게 해결할 수 있나요?
- "세션의 경우 세션 하이재킹을 막기 위해 HTTPS를 사용하고 쿠키의 보안을 강화합니다. JWT는 토큰 탈취를 막기 위해 짧은 만료 시간, 서명 검증, 암호화된 토큰 사용 등을 고려합니다."
5. 답변 마무리
마지막으로 면접관에게 반문해 대화를 이어가면 깊이 있는 논의로 이어질 수 있음:
- "이 애플리케이션이 실시간 상태 관리가 중요한가요, 아니면 확장성이 더 중요한가요?"
- "JWT를 도입할 때 새로 고침 토큰 관리와 같은 부분도 고려하고 계신가요?"
이런 방식으로 자신의 지식을 응용해 상황에 맞는 질문을 던지면, 단순히 정보를 아는 것이 아니라 실제 문제 해결 능력을 갖춘 후보자로 보일 수 있음.
'SpringBoot' 카테고리의 다른 글
| SpringBoot 잡동사니 (0) | 2025.01.12 |
|---|