MSA 환경 JWT 문제

 

 

MSA(Microservices architecture) 환경에서 JWT는 엄청 많이 쓰이지만, 실제로는 문제도 굉장히 많다.

핵심은:

JWT는 "확장성"은 좋지만,
"상태 제어"가 어렵다

 

는 것.

---

왜 MSA에서 JWT 많이 쓰냐?

MSA는 서버가 수십~수백 개다.

예:

user-service
order-service
payment-service
inventory-service

 

---

Session 방식 문제

만약 Session 사용하면:

모든 서비스가 세션 공유

 

해야 함.

---

즉:

• Redis 중앙 세션
• Sticky Session

등 필요.

복잡해짐.

---

JWT 장점

JWT는:

토큰 자체에 사용자 정보 존재

 

한다.

즉 각 서비스가:

서명만 검증

 

하면 됨.

---

그래서 구조

Client
↓ JWT
Gateway
↓
각 MSA 서비스

 

---

각 서비스는 DB 조회 없이 인증 가능.

엄청 확장성 좋음.

---

그런데 실제 문제들이 터짐

엄청 중요.

---

문제 1 — 로그아웃 어려움

JWT 가장 큰 문제.

---

상황

사용자가 로그아웃해도:

이미 발급된 JWT는 살아있음

 

---

왜?

JWT는:

Stateless

 

기반이기 때문.

---

즉 서비스들은:

JWT 서명만 확인

 

한다.

---

결과

토큰 만료 전까지 사용 가능.

---

그래서 현실은 Redis 사용

예:

블랙리스트
revoked token

 

저장.

---

즉 완전 Stateless 포기.

---

문제 2 — 권한 변경 반영 어려움

예:

ADMIN → USER 강등

 

---

그런데 기존 JWT 안에는:

 

{
  "role":"ADMIN"
}

 

들어있다.

---

결과

만료 전까지 관리자 권한 유지 가능.

---

해결 방법

---

1. Access Token 짧게

예:

15분

 

---

2. 권한 서버 조회

중요 API는:

Redis/DB 재검증

 

---

문제 3 — 토큰 크기 증가

MSA에서는 종종:

• role
• tenant
• scope
• permissions

다 넣고 싶어짐.

---

결과

JWT 커짐.

---

JWT는 매 요청마다 전송

즉:

네트워크 비용 증가

 

---

특히 모바일에서 영향.

---

문제 4 — 서비스 간 신뢰 문제

MSA에서는:

서비스끼리도 JWT 전달

 

한다.

---

그런데 문제

모든 서비스가:

JWT Secret 공유

 

하면 위험.

---

한 서비스 털리면?

가짜 JWT 생성 가능

 

---

그래서 해결

보통:

• RSA
• ECDSA

기반 공개키 구조 사용.

---

즉:

인증 서버만 Private Key 보유

 

---

각 서비스는:

Public Key 검증만

 

---

이것이 대규모 표준.

---

문제 5 — Token Revocation 어려움

예:

• 계정 정지
• 비밀번호 변경
• 탈취 탐지

즉시 반영 어려움.

---

그래서 현실은

JWT + 중앙 상태 저장소

 

조합 많다.

---

문제 6 — Refresh Token 관리 지옥

MSA에서는:

• 모바일
• 웹
• 멀티 디바이스

존재.

---

그래서 필요

• Rotation
• Redis
• Device 관리

---

결국 상태 저장 필요.

---

문제 7 — 서비스별 인가 복잡성

JWT만으로 부족.

---

예:

"이 사용자가 이 매장 주문 접근 가능?"

 

---

JWT에는 보통:

세밀한 리소스 권한

 

전부 못 넣음.

---

그래서 현실은

JWT 인증
+
DB/Redis 권한 조회

 

많이 한다.

---

문제 8 — 토큰 탈취 위험

JWT는 보통:

Bearer Token

 

이다.

즉:

가진 사람이 사용자

 

---

탈취되면 끝.

특히:

• XSS
• 로그 유출
• 브라우저 저장

위험.

---

그래서 최근 추세

• HttpOnly Cookie
• BFF 패턴

증가.

---

BFF 패턴

Backend for frontend

---

핵심

브라우저가 JWT 직접 안 들고 있음.

---

구조

Browser
↓ Session Cookie
BFF
↓ JWT
MSA

 

---

즉 JWT를 서버 내부로 숨김.

---

문제 9 — Gateway 의존성

Gateway만 검증하면 위험.

---

왜?

내부 서비스 직접 호출 가능할 수 있음.

---

그래서 각 서비스도 검증 필요.

즉:

Zero Trust 방향

 

---

현재 실무 타협점

대부분 완전 Stateless 안 함.

---

현실 구조

JWT
+
Redis
+
짧은 Access Token
+
Refresh Rotation
+
Gateway

 

---

즉:

"Stateless 인증"
+
"필요 최소 상태관리"

 

혼합.

---

실무 추천 구조

요소추천

Access Token	JWT 짧게
Refresh	Redis 저장
서명	RSA/ECDSA
Gateway	공통 인증
서비스간 인증	mTLS/JWT
권한	별도 조회 가능

---

핵심 한 줄

MSA 환경에서 JWT의 가장 큰 문제는:

확장성은 뛰어나지만,
로그아웃·권한변경·토큰폐기·세밀한 인가 같은
"상태 관리"가 어렵다는 점

 

이며,

실무에서는 보통:

JWT + Redis + Gateway + 짧은 토큰 수명

 

구조로 타협한다.