[기술면접 대비] 면접에서 'JWT는 왜 썼어요?' 물어보면 이렇게 대답하세요

기술면접이 어려운 이유

기술면접이 어렵게 느껴지는 건 단순히 모르는 문제가 나와서가 아닙니다. 문제는, 대부분의 질문이 단답형으로 끝나지 않는다는 점에 있습니다.

프로젝트 경험을 열심히 설명해도 면접관은 금방 이런 식으로 되묻습니다.

왜 이 구조를 선택했는지 이 방식이 다른 방법보다 나은 이유는 무엇인지 단점은 없었는지, 있었다면 어떻게 해결했는지...

이런 질문이 이어지는 순간부터 많은 분들이 당황하기 시작합니다. 인터넷에서 본 내용이나 외운 정의만으로는 절대 풀 수 없는 흐름이 시작되기 때문입니다.

특히 꼬리질문이 어렵습니다. JWT를 썼다고 하면 바로 이어서 Refresh Token은 어떻게 관리했는지 토큰 만료 시간은 어떻게 정했는지 로그아웃 처리는 어떻게 했는지 등 실제 상황에서 겪고 고민하지 않았다면 대답하기 힘든 질문이 나옵니다.

결국 기술면접은 정답을 말하는 시험이 아니라 맥락을 설명하고 판단을 검증받는 자리입니다. 경험의 무게와 선택의 논리를 말할 수 있어야 비로소 신뢰를 얻을 수 있는 구조죠.

JWT처럼 많은 개발자가 사용했다고 적는 기술일수록 면접관은 더 깊이 파고들 수밖에 없습니다. 표면적인 설명만으로는 절대 통과할 수 없습니다.

기술면접이 어렵게 느껴졌다면 지식이 부족해서가 아니라 경험을 구조화해서 말하는 연습이 부족했을 가능성이 큽니다.

이 아티클을 읽어야 하는 이유

JWT에 대한 자료는 이미 많습니다.

검색만 해도 구조, 장단점, 사용법이 정리된 글이 넘쳐나죠.

하지만 그런 글을 아무리 읽어도 막상 면접장에서는 말문이 막히는 경우가 많습니다.

문제는 대부분의 자료가 '설명'에만 초점이 맞춰져 있다는 겁니다. 실제로 면접에선 설명이 아니라, 판단과 선택의 이유를 말해야 합니다.

더 정확히 말하면, 두괄식으로 명쾌하게 말해야 하죠.

그게 어렵습니다.

답은 알고 있는 것 같은데,막상 질문이 들어오면 말이 맴돌거나핵심을 놓치고 장황하게 말하게 되는 경우가 많습니다.

이 아티클은 그걸 도와줍니다.

JWT를 왜 썼는지를 한 문장으로 명확하게 설명할 수 있도록 정리했습니다.
꼬리질문이 들어왔을 때도 흔들리지 않고 말할 수 있는 흐름을 제공합니다.
실제 기술 선택의 배경과, 장단점, 트레이드오프를 어떻게 연결해서 말해야 하는지까지 정리돼 있습니다.

결국 이 글의 목적은 단 하나입니다.

JWT에 대해 질문이 들어왔을 때, 바로바로, 정확하고 논리적으로 답변할 수 있도록 돕는 것.

이 주제에 자신이 없었던 분들이라면끝까지 정독하고 소화하는 것만으로도 면접장에서 전혀 다른 대답을 하게 될 겁니다.

그럼 바로 본론으로 들어가보겠습니다 :)

확장성이 뛰어나다

무상태성(stateless)으로 수평 확장 용이

이미 JWT 자체가 인증된 정보이기 때문에 세션 저장소와 같이 별도의 인증관련 저장소가 필수적으로 필요하지 않습니다.
클라이언트의 상태를 저장(stateful)하지 않기 때문에 사용자가 많이 늘어나도 Session에 비해 크게 메모리를 차지하지 않습니다.
stateless 덕분에 클라이언트 상태를 저장하지 않고, 또 인증과정에서 클라이언트의 인증관련 정보를 db 조회 할 필요도 없기 때문에 수평 확장에 매우 유리합니다. Session 인증 방식의 경우, Sticky Session 설정을 필요로하는 경우가 많습니다. 서버에서 클라이언트의 인증 상태를 관리하기 때문에 요청을 보냈던 서버로 다시 연결을 해주어야 세션이 유지되기 때문이죠. 이렇게 stateful하게 되면 수평 확장이 상당히 어려워집니다.

JWT 기본 개념

JWT(Json Web Token)은 웹상에서 사용되는 토큰에 대한 표준 규격(RFC 7519)를 의미합니다. 특정 기술이라기보다는 HTTP처럼 표준을 정의한 것이죠.

JSON 형식으로 토큰이 만들어진 것이라고 볼 수 있는데요. Web은 웹상에서 사용된다는 의미일테고요. Token은 말하자면 티켓같은 것입니다.

자, 그럼 종합해보면 웹상에서 사용하는 토큰(티켓같은)인데 형식이 JSON으로 되어있다라고 생각하면 될 것입니다. 그럼 이건 어디에다쓰는 걸까요? 일상에서 우리가 회사에 출근하거나, 지하철을 타거나, 어딘가에 갈 때 출입증이 필요한 경우가 있습니다. 공개된 장소가 아닌 경우에는 대다수 “인증”과정을 거치게 됩니다. 아무나 들여보내지 않겠다는 얘기죠. 이럴때 출입증을 대거나 입장권 같은 것을 끊어서입장하게 됩니다. 웹에서도 상당히 비슷하게 돌아갑니다. 웹사이트에 들어가서 서비스를 이용하려면 가입을 하라고 뜹니다. 가입을 하게 되면 그 다음부터 뭔가를 할 수 있는데요. 앞서 설명한 것과 동일한 과정을 거쳐 이루어집니다. 가입할 때 입장권을 받게 되는데요 이것이 바로 토큰입니다.

Session 방식과의 차이

웹상에서 사용하는 인증방식이 JWT가 처음일까요? 아닙니다. 기존에 사용하던 방식(Cookie와 Session. 여전히 사용되는 곳이 많습니다)이 있고 어떤 불편함이 있기 때문에 새로운 인증방식이 나오게 된 것입니다. 이제 기존 인증방식의 문제점과 JWT가 이를 어떻게 해결할 수 있는지 한번 살펴보겠습니다.

기존의 인증방식 Cookie와 Session

기존에는 먼저 Cookie라는 인증방식을 사용했는데요. 웹사이트에 접속하게 되면 Cookie를 허용하겠냐는 알람 받아보신 적 있을겁니다. 크롬이나 사파리같은 브라우저에 흔적(데이터)를 남길 수 있도록 하는 것이죠. 이 Cookie에 Id와 Password 정보가 남아있다면 웹사이트에 한번 로그인한 뒤 제공하는 서비스를 사용할 수 있습니다. Cookie에 저장된 정보를 바탕으로 서버쪽에서 인증을 할 수 있기 때문이죠. Cookie는 브라우저에 텍스트 파일 형태로 저장되는데요. 아래와 같은 한계가 존재하기 때문에 Cookie 자체로는 인증방식으로 사용되기 어렵습니다.

Cookie에 민감한 정보(id, password)가 담겨있는 경우, 노출되면 보안상 큰 문제가 발생한다.
Cookie를 조작할 수 있어 제대로 된 인증이 어렵다.
웹 브라우저마다 Cookie를 저장하는 방식이 달라 브라우저간 공유가 어렵다.
Cookie에는 사이즈 제한(4KB)이 있어 원하는 만큼의 데이터를 담을 수 없다.
서버에서는 매번 Cookie에 담긴 인증정보를 확인해야하는 불편함이 있으며 조작된 데이터가 넘어오는 경우 대처할 수 없다.

그래서 등장하게 된 것이 바로 Session입니다. Cookie에 민감한 정보를 담지 않고 인증에 대한 정보를 담아서 클라이언트가 가지고 있을 수 있게 한 것이죠. 해당 인증정보를 서버에 저장해놓고 요청이 오면 클라이언트의 인증정보와 서버의 인증정보를 비교하는겁니다.

Cookie만 사용했을 때와 Cookie&Session을 사용했을 때 차이를 예를 한번 들어보겠습니다.

테마파크에 들어가려고 입장권을 샀습니다. 테마파크를 드나들려면 입장권을 보여줘야 합니다. 그런데 입장권에 내 이름과 전화번호가 쓰여있습니다. 나갔다가 다시 테마파크로 들어가려면 내 개인정보가 쓰인 입장권을 보여줘야 하는데요. 놀다가 입장권을 흘리게 되면 내 개인정보가 노출되는 문제가 발생하게 됩니다. 그래서 테마파크 측에서는 입장권을 구매할 때 식별이 가능한 코드가 적힌 팔찌를 주게 됩니다. 이제 드나들 때 팔찌를 보여주기만 하면 입장이 가능해졌습니다. 그런데 문제가 또 발생합니다. 팔찌의 코드가 유효한지 매번 저장기록을 뒤져서 확인을 해야 했던 것이죠.

이렇게 Cookie와 Session을 함께 사용하면 보안측면에서 좀 더 나아집니다. Session ID를 탈취당했다고 해도 Session 저장소를 전부 지워버리면 서버 측에서 유효하지 않는 인증을 전부 차단할 수 있기 때문이죠. 하지만 매번 요청이 들어올 때마다 Cookie에 저장된 Session ID를 서버 쪽에서 데이터 조회를 통해 검증해야한다는 점이 조금 걸립니다.

Session 방식은 클라이언트의 인증상태를 서버쪽에 저장하게 됩니다. 이것이 의미하는 것은 서버에서 클라이언트의 상태가 어떤지 알고 있다는 것인데요. 이것을 Stateful 하다고 얘기합니다. HTTP 통신은 기본적으로 Stateless(무상태성)입니다. 이는 큰 장점으로 작용하는데요. 클라이언트 쪽의 상태를 알 필요가 없어지면 서버 쪽에서는 이와 관련된 로직도 들어갈 필요가 없고 관리해야 하는 인증 관련 데이터도 사라지게 됩니다. 즉, 데이터 요청이 오면 로직에 의해 원하는 값만 반환해 주면 되는 것이죠.

Session을 사용하게 되면 Stateful 해지기 때문에 서버를 늘릴 때에도 문제가 생기게 됩니다.

그림과 같이 서버가 늘어나게 되면 기존 서버는 Session 정보를 따로 또 저장을 해야 하는데요. 이러면 각 서버마다 차이가 생길 수 있어 동기화 문제가 필히 발생하게 됩니다. 이런 문제를 없애려면 중앙에 공통적으로 사용하는 인증서버를 만들어야겠죠. 그럼 새로운 서버는 사용자로부터 요청을 받으면 인증을 위해 인증서버에 Session 검증을 위한 요청을 또 보내야 합니다.

이렇게 Session을 사용했을 때에도 단점들이 존재하는데요.

Session 저장소에 문제가 발생하면 다른 인증된 유저도 인증이 불가해짐 → 사이트에 로그인해서 잘 사용하고 있는데 갑자기 튕기면서 다시 로그인하라고 하는 경우 Session에 문제가 생겼을 가능성이 높습니다.
Stateful 하기 때문에 서버를 증설(Scale-Out)했을 때 비효율적인 부분이 발생
사용자가 많아질수록 Session 정보를 저장하는 저장소도 커지기 때문에 서버 부담이 커짐
사용자 요청마다 Session 저장소를 조회해야 하기 때문에 사용자가 많아질수록 성능 이슈가 생길 수 있음

다양한 플랫폼 지원

JWT 인증 방식은 다양한 플랫폼을 지원할 수 있는데요. 웹, 모바일 플랫폼, API client, Micro Service 등 다양한 플랫폼을 하나의 중앙 인증 서버에서 인증처리한다고 했을 때 매우 적합한 방식입니다.

먼저, Cookie를 사용하지 않으므로 CORS(Cross-Origin Resource Sharing) 문제에서 자유롭습니다. 이는 Session 방식과 큰 차이를 보이는 부분인데요. Session은 기본적으로,

로그인 시 서버는 세션 ID를 생성하고, 사용자 정보와 함께 서버 메모리(DB/Redis 등)에 저장
클라이언트는 세션 ID를 쿠키에 저장
이후 요청마다 쿠키로 세션 ID를 보내고, 서버는 그걸로 상태 조회 위처럼 클라이언트 상태를 저장하기 때문에 다양한 플랫폼을 지원해야하는 상황에서 여러 제약이 발생할 수 있습니다.

플랫폼	문제점
웹 브라우저	쿠키 기반이라 별 문제 없음 (Same-Origin 기준)
모바일 앱	쿠키 저장과 자동 전송이 귀찮고, 서버 쿠키 전략에 맞춰 구현 복잡
API 클라이언트	세션 저장소를 요구 → 서버 확장성 제한
마이크로서비스	모든 서비스가 같은 세션 저장소를 공유해야 해서 관리 복잡

반면, JWT는 모든 플랫폼에서 동일한 인증 과정을 거칩니다. 토큰 안에 필요한 인증 정보를 클라이언트에 담아 주고, 매 요청마다 이 토큰을 보내는 구조인데요. 서버는 그냥 매 요청마다 토큰을 검증만 하면 끝나기 때문에 어떤 플랫폼에서 보냈는지 크게 신경쓸 필요가 없습니다.

성능적 이점이 존재한다

인증을 위한 DB 조회가 필요 없음

위의 Session 방식과의 차이에서 알 수 있듯이 JWT 인증은 무상태 기반 구조를 통해 서버 리소스 소비를 최소화 할 수 있습니다. 인증을 위한 DB 조회가 필요없기 때문이죠. 이는 대규모 트래픽 환경에서 성능적 이점을 가져갈 수 있습니다. 특히 MSA나 서버리스 구조처럼 확장성과 응답속도가 중요한 시스템에 최적화된 방식이죠.

캐싱을 적용하기 좋음

JWT는 토큰 자체에 사용자를 식별할 수 있는 값이 포함되어 있습니다(sub). 추가로 DB 조회 없이 사용자를 식별해서 응답을 처리할 수 있기 때문에 캐싱을 적용하기 좋고, 이는 성능상 이점으로 작용할 수 있습니다.

Session의 경우를 살펴보면,

클라이언트가 /my-page를 요청
서버는 쿠키에 담긴 세션 ID를 확인
서버 메모리나 Redis에서 세션 상태 조회
사용자 정보를 찾은 후 응답 생성
응답은 사용자별로 다르므로 캐시하기 어렵다

즉, 매 요청마다 각기 다른 사용자의 다른 응답을 만들기 때문에

**정적 캐시(프록시 캐시, CDN 캐시)가 어렵고 무조건 서버가 작업해야 합니다. 이런 경우는 트래픽이 많아지면 많아질수록 성능 이슈를 맞이하게 됩니다.

반면, JWT는 어떨까요?

클라이언트가 /my-page를 요청하며 JWT 토큰을 Authorization 헤더에 포함
서버는 토큰만 디코딩해서 사용자 정보를 바로 얻음
응답 생성 → 이때 내용이 사용자별로 다르더라도,토큰 값에 있는 사용자 정보를 바탕으로 캐시 키를 만들 수 있음

즉, JWT를 캐시의 Key처럼 사용할 수 있는 것이죠. 그럼 프록시 캐시나 CDN 캐시를 적용하기가 수월해집니다. 특정 사용자의 응답은 한번만 생성하고, 같은 요청이 왔을 경우에는 응닶을 캐시해서 바로 내려보내줄 수 있는 것이죠. 정적 리소스 + 인증된 사용자별 리소스를 구분해서 JWT로 인증된 캐싱 정책을 적용할 수도 있습니다.

예를 들어 “로그인한 유저만 보는 /dashboard 페이지, 5분 동안 캐시”하도록 만들 수 있는 것이죠.

단점

토큰 탈취시 심각한 보안 위협

JWT 인증방식의 경우 Token을 탈취당하면 만료될때까지 대처가 불가능하다는 단점을 가지고 있습니다. Session의 경우 Cookie만 쓸때에 비해 좋았던 점이 바로 보안적인 부분이었는데요.

Session ID를 탈취당하더라도 저장소의 값을 지워서 인증이 안되도록 할 수 있었죠.

하지만 JWT같은 경우 한번 서버에서 발급을 하게 되면 클라이언트가 관리하는 형태이기때문에 서버쪽에서 조치할 수 있는게 없습니다.

이를 해결하기 위한 몇가지 방법을 알고 있으면 좋습니다.

Refresh Token 만료시간 짧게 가져가기

이런 경우 JWT 스펙에 나와있던 토큰 만료 시간(exp)을 짧게 가져가는 것으로 보완할 수 있는데요. 만료시간을 짧게 가져가면 토큰이 탈취된다고해도 짧은 시간만 유효하기 때문에 피해를 최소화 할 수 있겠죠.

Refresh Token Rotation

이 전략은 매번 Access Token을 발급할 때 Refresh Token을 새로 발급해서 교체하는 방식입니다. 이렇게하면 이전 Refresh Token은 즉시 폐기되기 때문에 공격자가 Refresh Token 탈취 후, 재사용하려고 할 때 서버에서 차단할 수 있습니다.

📦 예시로 보는 Refresh Token Rotation과 탈취 대응

🔷 정상 흐름

A 사용자가 로그인해서 Refresh Token #1을 발급받음
일정 시간 후 Access Token이 만료됨 → A가 Refresh Token #1로 재발급 요청
서버는 Access Token과 함께 Refresh Token #2를 새로 발급함
서버는 Refresh Token #1을 사용 완료 처리(무효화)

🔷 탈취 시나리오

A 사용자가 Refresh Token #1을 가지고 있고,
탈취자(B)가 동일한 Refresh Token #1을 몰래 복사함(예: XSS, 앱 디컴파일, 로컬 저장소 노출 등)
나중에 A가 먼저 재발급 요청해서 Refresh Token #2를 받음
이후 B가 탈취한 Refresh Token #1로 요청을 보내면…

🔥 서버의 대응

서버는 Refresh Token #1은 이미 사용된 토큰(재사용됨)이라는 걸 알고 있음
이 요청은 Replay Attack으로 판단됨 → A와 B 모두 강제 로그아웃, 보안 알림 발생

✅ 핵심: Refresh Token의 "1회성 사용" 원칙을 통해 탈취된 토큰이 나중에 사용되면 바로 감지 가능

일반 Refresh Token	Rotation 적용 시
토큰이 탈취되어도 만료 전까지 계속 사용 가능	탈취자가 재사용하면 즉시 감지 및 차단 가능
탈취 시 피해 추적 어려움	Replay Attack 시도 감지 가능
보안상 Refresh Token 자체를 믿어야 함	서버가 유일한 토큰만 인정함

Refresh Token Rotation을 활용하려면 일단 서버에 Refresh Token 사용 이력을 저장해야 합니다. DB나 Redis를 활용하여 이력을 관리하면 됩니다. 사용된 토큰 목록을 관리하는 블랙리스트나 토큰 ID(jti)를 기반으로 추적하도록 구현합니다.

JTI + 서버 저장소 확인

JWT 발급시 식별이 가능한 토큰 ID(jti)를 생성하고, 서버에 저장하는 방식입니다. 클라이언트에서 보내는 매 요청마다 해당 토큰 id가 유효한지 검증하는 것이죠.

이 방식을 활용하면 JWT가 공격자에 의해 탈취되었을 때 서버에서 해당 토큰을 무효화 할 수 있다는 것입니다. 서버에 저장된 토큰 식별자를 무효화해버리면 되는 것이죠.

하지만, 이는 JWT의 이점인 stateless를 포기하고 stateful을 채택하는 것이기 때문에 많은 고민을 필요로합니다. 보안에 매우 민감한 시스템에 주로 사용합니다.

이 글을 마무리하며

기술면접은 결국 나의 선택을 검증받는 자리입니다. 단순히 JWT를 썼다, 알고 있다를 말하는 건 누구나 할 수 있지만 왜 그 선택이 타당했는지를 설명하는 건 경험과 사고력이 담겨 있어야만 가능한 일이죠.

무작정 외우지 않아도 됩니다. 한번 제대로 맥락을 이해하고 자기 언어로 설명할 수 있게 정리만 해두면 면접장에서 나오는 질문에 훨씬 자연스럽게 대응할 수 있습니다.

끝까지 읽어주셔서 감사합니다!

이제 JWT 관련 질문이 들어왔을 때 정리된 흐름으로 깔끔하게 답할 수 있을 겁니다.

궁금한 점은 댓글로 언제든 질문 남겨주세요 :)

개발자 취업