Spring Boot 성능 최적화 9

API 보안 · 인증 구조 성능 최적화 (JWT · 세션 · OAuth2)

API 보안 구조는 단순히 인증(Authenticate)과 인가(Authorize)를 처리하는 것을 넘어,
성능 · 확장성에도 직접적인 영향을 준다.
잘못 설계된 인증 로직은 API 성능 병목, 세션 누락, 캐시 미스 증가 등 다양한 문제를 일으킨다.
이 글에서는 Spring Boot 기반 서비스에서 자주 사용되는 인증 구조(JWT, 세션, OAuth2)의 성능 최적화 전략을 정리한다.

---

＃JWT vs 세션 vs OAuth2 — 무엇을 선택해야 할까?

인증 방식은 서비스 성격에 따라 적절한 선택이 필요하다.
성능, 확장성, 보안 요구사항을 기준으로 비교해보자.

JWT의 장점

• 서버에 세션 저장 필요 없음 → 확장성 높음
• Redis 없이도 멀티 서버 운영 가능
• API Gateway·모바일 앱에서 사용하기 좋음

세션(Session) 방식 장점

• 로그아웃 시 즉시 세션 제거 가능
• Token 탈취 대비 안전
• 백오피스처럼 내부 서비스에서 편리

OAuth2가 필요한 경우

• 소셜 로그인 연동
• 3rd-party에게 권한(scope) 기반 액세스 제공
• Access Token + Refresh Token 구조가 필요한 경우

대규모 API 서비스는 대부분 다음 조합을 사용한다:
“OAuth2 (소셜 로그인) → JWT 발급 → API 인증”

---

＃JWT 성능 최적화

JWT는 서버 부하가 적지만, 서명(Signature) 검증이 CPU 비용을 많이 사용한다.
잘못된 방식으로 검증하면 고트래픽 환경에서 병목이 된다.

1) JWT 파싱 규칙

• 매 요청마다 DB 조회 금지
• Black List 저장 방식 최소화
• 헤더에서 파싱 시 정규식 사용 금지(비용 높음)

2) HS256 → ES256 고려

HS256(HMAC) 검증은 빠르지만 키 공유 방식이라 위험할 수 있다.
서버 확장성과 보안 측면에서 ES256(ECDSA) 방식이 점점 증가하는 추세다.

3) Access Token + Refresh Token 전략

Access Token은 15~30분, Refresh Token은 7~30일로 설정하는 것이 일반적이다.
토큰 재발급에 Redis를 사용하면 보안과 성능을 높일 수 있다.

redis.set("refresh:{userId}", refreshToken, Duration.ofDays(14));

4) JWT Claim 최소화

• 불필요한 이메일/프로필 정보 포함 금지
• userId, role 정도로 최소 구성
• Claim이 많으면 토큰 길어지고 네트워크 비용 증가

---

＃세션(Session) 기반 인증 최적화

세션 기반 인증은 로그인 상태를 서버가 관리한다는 점에서 성능에 영향을 줄 수 있다.
특히 세션 저장소 선택이 매우 중요하다.

1) 로컬 메모리 세션 금지

멀티 서버 환경에서는 절대 사용하면 안 된다.
재배포/스케일아웃 시 로그인이 강제 초기화된다.

2) Redis 세션 스토리지 사용

Redis는 높은 처리량과 TTL 관리 기능이 있어 세션 저장소로 이상적이다.

spring:
  session:
    store-type: redis

3) 세션 용량 최적화

• 세션에 대형 객체 저장 금지
• 세션 값은 userId, role 정도로 최소화
• TTL은 서비스 특성에 맞게 설정

세션 기반 인증은 로그인 유지가 잘 되어야 하는 백오피스·내부 시스템에서 특히 유리하다.

---

＃OAuth2 기반 로그인 최적화

OAuth2는 인증 서버와 통신하는 구조라 기본적으로 비용이 크다.
특히 다음 부분에서 성능 차이가 발생한다.

1) 사용자 정보 요청 최소화

OAuth2 로그인 과정에서 “프로필 조회 API” 호출을 최소화해야 한다.
최적 전략은 다음과 같다:

• 최초 로그인 때만 프로필 요청
• 로그인 이후에는 자체 DB 사용자 정보 사용
• 소셜 API 재호출 절대 금지

2) Refresh Token 저장 전략

• 서버 DB/Redis에 암호화하여 저장
• 탈취 방지를 위해 rotation 적용

3) JWT와 결합

OAuth2 로그인 → Access Token → 자체 JWT 발급
대규모 API 구조에서 가장 많이 쓰이는 형태다.

---

＃필터(Filter) · 인터셉터(Interceptor) 최적화

인증 로직이 느리면 전체 API가 병목된다.
특히 필터는 모든 요청마다 실행되기 때문에 최적화가 필수적이다.

1) DB 접근 금지

인증 Filter에서 DB 조회가 발생하면 고트래픽 환경에서는 절대 버틸 수 없다.
반드시 JWT 자체 검증 또는 캐시 기반 인증을 사용해야 한다.

2) 정규식 기반 URI 검사 금지

정규식은 매우 비싸다. prefix 매칭으로 대체해야 한다.

if (path.startsWith("/public/")) { 
    chain.doFilter(request, response);
    return;
}

3) 인증 성공/실패 Logging 최소화

• 로그는 batch 형태로 모아서 저장
• 로그 때문에 IO가 증가하면 역효과

---

＃Redis + JWT + OAuth2 조합 예시

대규모 서비스에서 가장 많이 사용되는 인증 구조는 다음과 같다:

• OAuth2로 최초 사용자 인증
• 자체 서버에서 JWT 발급
• Refresh Token은 Redis에 저장
• Access Token만으로 대부분의 API 인증 처리
• 필요 시 Rate Limit / Circuit Breaker로 보호

이 구조는 확장성, 성능, 보안을 균형 있게 만족한다.

---

마치며

API 인증 구조는 단순한 보안 문제를 넘어 성능과 확장성에도 직접적인 영향을 준다.
JWT는 무상태 인증으로 확장성이 뛰어나고, 세션은 내부 서비스에서 편리하며, OAuth2는 외부 인증 연동에 적합하다.
각 방식의 장단점을 이해하고 최적의 조합을 선택해야 한다.

다음 글에서는 대규모 로그 처리 및 모니터링 최적화 (ELK · Prometheus · Grafana)를 다룬다.
실전 운영 환경에서 필수적인 로깅 및 관측성(O11y) 전략을 정리할 예정이다.