CJ푸드빌 같은 디지털 채널 운영사는 사내 어드민과 매장/가맹점용 웹은 여전히 JSP + jQuery + 서버 세션 기반인 경우가 많고, 동시에 자사 앱과 외부 파트너 연동은 토큰 기반 API로 굴린다. 시니어 백엔드 인터뷰에서 "세션이랑 토큰의 차이가 뭐냐"라는 질문은 단순 정의를 보는 게 아니라, 하나의 인증 인프라 위에서 레거시 채널과 신규 채널이 공...
CJ푸드빌 같은 디지털 채널 운영사는 사내 어드민과 매장/가맹점용 웹은 여전히 JSP + jQuery + 서버 세션 기반인 경우가 많고, 동시에 자사 앱과 외부 파트너 연동은 토큰 기반 API로 굴린다. 시니어 백엔드 인터뷰에서 "세션이랑 토큰의 차이가 뭐냐"라는 질문은 단순 정의를 보는 게 아니라, 하나의 인증 인프라 위에서 레거시 채널과 신규 채널이 공존하는 상황을 어떻게 설계해 봤는지를 본다. 인증은 장애가 나면 사용자 전부가 막힌다는 점에서 SLA에 직접 영향을 주는 영역이고, 보안 이슈(CSRF, 세션 고정, 토큰 탈취)는 이력서 한 줄짜리 사고로 직결된다.
이 문서는 HTTP의 stateless 특성에서 출발해 Cookie → Session → Token 순서로 인증 모델을 쌓고, JSP 레거시와 모바일 API가 공존하는 구체 패턴, CSRF/CORS/SameSite의 실전 함정, 흔한 인증 장애 회복 시나리오, 그리고 인터뷰 답변 프레임을 한 번에 정리한다.
HTTP는 한 번의 요청과 한 번의 응답을 한 단위로 처리한다. 서버는 기본적으로 이전 요청을 기억하지 않는다. 같은 사용자가 보낸 요청이라는 사실조차 프로토콜 자체로는 알 수 없다. 이게 stateless의 핵심이다.
그런데 실서비스에서는 "이 요청을 보낸 사용자가 누구인가"라는 상태가 반드시 필요하다. 결제 요청을 보낸 사용자와 장바구니에 담은 사용자가 동일인이라는 보장이 있어야 하기 때문이다. 그래서 우리는 stateless 위에 인증 상태를 얹는 장치를 추가로 구현한다. Cookie, Session, Token이 모두 그 장치다.
stateless를 "서버가 아무 상태도 안 가진다"로 오해하면 안 된다. 정확히는 **"HTTP 프로토콜 레벨에서 요청 간 연결성이 없다"**는 의미고, 애플리케이션 레벨에서는 거의 항상 무언가 상태를 들고 있다. 다만 그 상태를 어디에 두느냐(서버 메모리 / 외부 저장소 / 클라이언트)에 따라 운영 특성이 완전히 달라진다.
Cookie는 서버가 응답에 Set-Cookie 헤더를 실어서 클라이언트에 저장시키고, 이후 같은 도메인으로 요청이 갈 때 브라우저가 자동으로 Cookie 헤더에 실어 보내는 단순한 키-값이다. Cookie 그 자체는 인증 수단이 아니라 인증 식별자를 운반하는 수단이다.
실무에서 반드시 챙겨야 하는 속성:
Secure — HTTPS에서만 전송. 운영 환경 쿠키는 무조건 켠다.HttpOnly — JavaScript document.cookie에서 읽지 못하게 막는다. XSS로 토큰이 탈취되는 가장 흔한 경로를 차단한다.SameSite — 다른 사이트에서 시작된 요청에 쿠키를 자동 첨부할지 결정한다. Strict, Lax, None 세 가지.
Lax(브라우저 기본값) — 일반적인 GET 이동에는 쿠키가 가지만, 외부 사이트의 form POST에는 가지 않는다. CSRF 1차 방어선.None — 크로스 사이트 요청에도 쿠키를 보낸다. 단, Secure가 강제된다. 외부에서 자사 API를 쿠키로 호출하는 도메인 분리 환경에서 필요.Strict — 외부 링크 클릭으로 들어와도 쿠키가 안 붙는다. 로그인이 풀린 것처럼 보이기 때문에 사용자 동선에 따라 신중히 적용.Domain, Path — 어느 범위에서 쿠키가 자동 첨부될지 결정. 서브도메인 분리 환경에서 의도와 다르게 다른 서비스로 쿠키가 새는지 점검한다.Max-Age / Expires — 만료. 세션 쿠키는 굳이 영구 만료를 줄 필요가 없다.Cookie 자체는 단순하지만 위 속성을 빼먹어서 사고가 나는 경우가 압도적으로 많다.
Session은 인증 상태를 서버 측 저장소에 두고, 클라이언트에는 식별자만 쿠키로 내려주는 패턴이다. 톰캣/스프링 시큐리티 기본 설정도 이 모델이고, JSP 시대부터 가장 익숙한 형태다.
흐름:
Set-Cookie: JSESSIONID=...; HttpOnly; Secure; SameSite=Lax를 실어 보낸다.세션 저장소 위치는 운영 특성을 좌우한다.
spring-session-data-redis로 거의 코드 수정 없이 전환된다. 운영 표준에 가깝다.세션 모델의 강점은 로그아웃이 즉시 반영된다는 점이다. 서버에서 세션을 지우면 끝이다. 이는 토큰 모델 대비 명확한 이점이다.
약점은 상태가 서버에 있다는 점에서 온다. 서버를 무중단 배포할 때 세션 호환성을 고려해야 하고, 모바일 앱이나 외부 파트너 API가 쿠키 기반 세션을 쓰는 건 어색하다. 그래서 토큰이 등장한다.
Token 인증은 인증 정보를 토큰 자체에 넣어 클라이언트가 보관하고, 매 요청마다 Authorization: Bearer <token> 헤더로 실어 보내는 모델이다. JWT(JSON Web Token)가 가장 흔하다.
JWT는 header.payload.signature 형태의 점-구분 문자열이다. payload에는 sub(사용자 식별자), exp(만료 시각), iat(발급 시각), 권한 같은 클레임이 base64url로 인코딩되어 들어간다. signature는 비밀키 또는 RSA 키쌍으로 서명되어, 위변조 시 검증에서 실패한다.
핵심: JWT의 payload는 암호화가 아니라 서명이다. base64 디코드만 하면 누구나 읽는다. 따라서 비밀번호, 주민번호, 결제 카드 정보를 payload에 넣으면 안 된다. 식별자, 권한 같은 노출돼도 무방한 정보만 담는다.
토큰 모델 특성:
토큰 수명을 짧게 두면 보안은 좋아지지만 사용자 경험이 나빠진다. 그래서 보편 패턴은 다음과 같다.
Refresh token은 access token과 달리 서버 측에 저장해서 폐기 가능 상태로 관리하는 게 일반적이다. 사용자 로그아웃, 비밀번호 변경, 디바이스 강제 로그아웃 시 refresh token 자체를 무효화하면 access token이 만료되는 순간부터 재발급이 막힌다.
저장 위치 선택:
HttpOnly + Secure + SameSite=Strict 쿠키에 두는 패턴이 안전하다. localStorage에 두면 XSS 한 방에 털린다.흔한 실수: refresh token으로 새 access token만 받고, refresh token은 그대로 재사용. rotation이 권장된다. 즉, refresh 호출마다 새 refresh token을 같이 발급하고 이전 것을 무효화한다. 토큰 재사용 탐지 시 즉시 모든 세션을 만료시키면, 탈취된 refresh token으로 공격자가 활동하는 흔적을 잡을 수 있다.
| 관점 | Session(Stateful) | Token(Stateless) |
|---|---|---|
| 상태 위치 | 서버 측 저장소 | 클라이언트(JWT 자체) |
| 수평 확장 | 외부 세션 스토어 필요 | 자연스러움 |
| 즉시 로그아웃 | 즉시 가능 | 어려움(블랙리스트 필요) |
| 모바일/외부 API | 어색함 | 자연스러움 |
| 탈취 시 회복 | 세션 삭제로 종료 | 만료까지 유효 |
| 페이로드 노출 | 식별자만 노출 | payload base64로 노출 |
| 디버깅 | 서버 로그로 풍부 | 토큰 디코드로 일부 |
핵심 판단 기준은 채널 구성이다. 사내 어드민/JSP 화면처럼 브라우저-서버가 동일 도메인에서 끝나면 세션이 단순하고 강하다. 모바일 앱·외부 파트너·SPA가 끼면 토큰이 자연스럽다. 실무는 둘을 같이 운영하는 경우가 많다.
CJ푸드빌처럼 외식·매장 운영 백엔드는 다음 구성이 흔하다.
같은 사용자 도메인을 다루지만 인증 채널이 다르다. 설계 포인트:
SecurityFilterChain을 URL 패턴별로 분리해 어드민 경로는 폼 로그인 + 세션, /api/**는 JWT 필터로 묶는다.admin.example.com, API는 api.example.com처럼 호스트를 분리하면 쿠키와 토큰이 서로 간섭하지 않는다. 같은 호스트에서 둘 다 받으려면 SameSite/Secure/Path를 정밀하게 잡아야 한다.Authorization 헤더로 토큰을 명시적으로 싣는 API 경로는 CSRF가 구조적으로 발생하지 않는다. Spring Security 기본 설정에서 /api/**는 csrf.disable() 또는 ignoringRequestMatchers로 빼고, 어드민 경로는 활성화한다.이 셋은 다른 문제를 푸는데 같이 등장해서 자주 섞인다.
SameSite=Lax/Strict, (2) CSRF 토큰(폼/헤더에 추가 토큰), (3) 중요한 변경은 POST + Origin 검증. Authorization 헤더로 토큰을 명시하는 API에는 발생하지 않는다.Access-Control-Allow-Origin, Access-Control-Allow-Credentials 등을 응답으로 주면 브라우저가 통과시킨다. 공격 방어가 아니라 합법적 크로스오리진 허용 메커니즘이라는 점이 중요하다. CORS를 푼다고 CSRF가 같이 풀리는 게 아니다.None을 쓰려면 반드시 Secure가 같이 필요하다.흔한 사고: 프론트가 다른 origin으로 분리되며 CORS를 열고 credentials: include로 쿠키를 보내려는데 SameSite가 Lax라 쿠키가 안 가서 401이 난다. 또는 그걸 풀려고 SameSite=None; Secure로 바꿨는데, 운영 환경 HTTPS 인증서가 일부 경로에 누락되어 쿠키가 안 실리는 경우. 둘 다 운영에서 자주 겪는다.
// 프론트 - 로그인 응답 처리
const res = await fetch('/api/login', { method: 'POST', body: ... });
const { accessToken } = await res.json();
localStorage.setItem('token', accessToken);
// 매 요청
fetch('/api/orders', { headers: { Authorization: `Bearer ${localStorage.getItem('token')}` } });문제:
POST /auth/login → 200
Set-Cookie: refresh=eyJ...; HttpOnly; Secure; SameSite=Strict; Path=/auth; Max-Age=604800
Body: { "accessToken": "eyJ...", "expiresIn": 600 }
GET /api/orders
Authorization: Bearer eyJ...
POST /auth/refresh (브라우저가 refresh 쿠키 자동 첨부)
→ 200
Set-Cookie: refresh=eyJ_NEW...; HttpOnly; Secure; SameSite=Strict; Path=/auth
Body: { "accessToken": "eyJ_NEW...", "expiresIn": 600 }핵심:
HttpOnly 쿠키라 JS가 못 읽음 → XSS로 못 빼간다.Path=/auth로 다른 API 호출에는 자동 첨부되지 않게 범위 제한.<a href="/admin/users/42/grant?role=ADMIN">관리자로 승격</a>문제: 외부 사이트가 <img src="https://admin.example.com/admin/users/42/grant?role=ADMIN">만 심어두면, 운영자 브라우저에 JSESSIONID가 자동 첨부되어 호출이 성공한다. 전형적 CSRF.
<form method="post" action="/admin/users/42/grant">
<input type="hidden" name="_csrf" value="${_csrf.token}">
<input type="hidden" name="role" value="ADMIN">
<button>관리자로 승격</button>
</form>서버는 세션에 보관한 CSRF 토큰과 폼 토큰을 비교한다. SameSite=Lax가 같이 걸려 있으면 외부 form POST에는 JSESSIONID 자체가 안 붙어 1차 방어가 더해진다.
Spring Boot 3 + Spring Security 6 기준이면 충분하다. 별도 인증 서버 없이 같은 애플리케이션에서 두 채널을 모두 흉내 낼 수 있다.
mkdir auth-lab && cd auth-lab
curl https://start.spring.io/starter.tgz \
-d dependencies=web,security,thymeleaf,session \
-d type=gradle-project -d language=java -d javaVersion=21 \
-d groupId=com.example -d artifactId=auth-lab \
| tar -xzvf -
./gradlew bootRun세션 모델 확인:
curl -i -c cookies.txt -b cookies.txt -X POST localhost:8080/login \
-d username=user -d password=...
curl -i -b cookies.txt localhost:8080/admin응답 헤더에서 Set-Cookie: JSESSIONID=...; HttpOnly가 보이는지, 두 번째 호출에서 같은 세션이 유지되는지 확인한다.
JWT 모델은 spring-boot-starter-oauth2-resource-server를 추가하고 OncePerRequestFilter에서 Authorization 헤더를 파싱하는 방식으로 작은 필터를 직접 구현해도 학습 효과가 크다.
SameSite 동작 확인:
docker run -it --rm -p 8080:8080 nginxdemos/hello # 다른 origin 흉내다른 origin에서 <form action="http://localhost:8081/transfer">를 만들어 제출했을 때 JSESSIONID가 첨부되는지 브라우저 개발자도구 Network 탭에서 직접 확인한다. 쿠키 속성을 Lax → None; Secure → Strict로 바꿔가며 동작이 변하는 걸 눈으로 본다.
kid(key id)로 식별하니, 신규 kid 발급 + 구 kid 거부 정책으로 점진 전환한다. refresh token까지 모두 폐기 후 강제 재로그인.exp 기반 검증이라 서버 시계가 어긋나면 모든 토큰이 만료/미만료 오판된다. NTP는 인프라 점검 항목.Domain=.example.com으로 설정해 서브도메인 전체에 쿠키가 새는 사고. 점검 포인트는 항상 가장 좁게.질문: "세션과 토큰의 차이를 설명해 주세요."
답변 프레임(60초):
질문: "CSRF와 CORS는 다른 문제인가요?"
답변 프레임:
Authorization 헤더 기반 API에서는 구조적으로 발생하지 않는다.질문: "JWT를 어디에 저장하시나요?"
답변 프레임:
Secure, HttpOnly, SameSite 모두 명시했는가Domain 범위가 의도한 호스트만 포함하는가