[kt cloud TECH UP] API Gateway 인증 통합과 헤더 스푸핑(Spoofing) 방어전

2026. 2. 18.
API GatewaySecurityJWTSpoofingkt cloud TECH UPMSA

본 포스팅은 치열하게 진행 중인 kt cloud TECH UP 실무 통합 프로젝트의 일환으로 진행된 마라톤 티켓팅 플랫폼 구축기의 이어지는 기록입니다.)

1. Gateway 로드맵: 쏟아지는 트래픽 속 인증의 병목

15,000명의 동시 접속자가 몰리는 티켓팅 상황에서, 백엔드의 가장 큰 병목 중 하나는 '인증(Authentication)'입니다. 만약 티켓팅 요청, 좌석 조회, 결제 등 수많은 MSA 서비스(main, payment 등)가 각각 개별적으로 JWT 토큰을 까보고 검사(Verify)한다면 엄청난 컴퓨팅 리소스가 낭비됩니다.

이를 해결하기 위해 우리는 분산된 API Gateway를 거대한 "인증 수문장"으로 설계하기로 했습니다.

2. Gateway 뒤의 세상: 오직 헤더만 신뢰하라

설계는 간결하고 강력했습니다. 클라이언트의 모든 요청은 무조건 인증의 최전방인 Gateway를 최초로 통과합니다.

  1. Gateway 내부의 JwtAuthenticationWebFilter가 클라이언트의 JWT를 뜯어보고 서명을 검증합니다.
  2. 유효한 토큰이라면 Payload에 담긴 사용자 식별 번호와 권한을 꺼내, HTTP Header에 X-User-Id, X-User-Role 형식으로 주입(Inject)합니다.
  3. 그리고 뒷단(Downstream) 마이크로서비스들(main)로 요청을 넘깁니다.

이 구조의 치명적인 매력은 비즈니스 서버(main)에서 Spring Security나 JWT 파싱 로직을 완전히 걷어낼 수 있다는 점입니다. main 서비스 컨트롤러는 토큰이 무엇인지 알 필요도 없이, 단순히 들고 들어온 X-User-Id 헤더 값만 꺼내서 비즈니스 로직에 100% 집중하면 됩니다.

3. 코드 리뷰의 서늘함: X-User-Id 헤더 스푸핑(Spoofing)

그러나 완벽해 보였던 이 아키텍처는 코드 리뷰 중 발견된 하나의 치명적인 결함으로 인해 팀 전체에 서늘함을 안겨주었습니다.

만약, 악의적인 해커가 애초에 JWT 토큰을 빼고, 자기가 직접 조작한 HTTP 헤더(X-User-Id: 1)를 담아서 Gateway로 전송하면 어떻게 될까요?

초기 구현에서는 토큰이 없는(혹은 만료된) 요청이 비인가(Permit All) 엔드포인트나 예외 처리를 타고 그냥 흘러 들어갈 때, Gateway가 클라이언트가 조작한 이 가짜 X-User-Id 헤더를 굳이 막지 않고 뒷단의 main 서버로 그대로 통과시키는 상태였습니다. 뒷단 서버는 아키텍처 규칙에 따라 "헤더에 X-User-Id가 있으니 검증된 유저 1번이구나" 라고 철석같이 믿어버리게 됩니다. 즉, 남의 계정을 단 한 줄의 헤더 조작으로 완벽하게 탈취(Spoofing)할 수 있는 엄청난 로직 버그였습니다.

치명적 방어전: 필터 진입 시점의 Header Remove 로직

해결책은 Gateway 인증 필터의 맨 앞에 아주 강력한 단일 규칙을 세우는 것이었습니다.

"클라이언트가 어떤 헤더를 담아서 보내든, Gateway 수문장 경계선에서 민감한 헤더(X-User-Id, X-User-Role)를 무조건 전부 강제 삭제(Remove) 시켜버린다."

그리고 오직 "Gateway 내부에서 자체적인 JWT 서명 검증이 완벽하게 끝난(Trusted) 경우"에 한해서만 다시 해당 헤더 값을 세팅해 주는 것입니다. 이를 통해 외부에서 주입된 어떠한 위조 헤더도 비즈니스 레이어에 닿기 전에 증발하게 되었고, 이 지독한 스푸핑 위협을 깔끔하게 차단할 수 있었습니다.

4. 맺음말: 단순히 코드를 치는 것을 넘어

단순한 모놀리식 토이 프로젝트에서는 겪어보지 못할 고민들이었습니다. UX를 처음부터 재설계하여 사용자의 티켓팅 경로를 바꾸고(1편), 그 설계를 뒷받침하기 위해 멀티 모듈 아키텍처를 세우고 끊임없이 의존성의 캡슐화를 논의하며(2편), 마침내 들이닥친 대규모 트래픽과 매크로/해킹 공격을 Gateway 단에서 우아하고 견고하게 방어해내는 것(3편).

kt cloud TECH UP에서의 이 숨 가빴던 프로젝트는, '기능 작동'에 멈춰있던 제 개발 시야를 '안정적인 시스템 엔지니어링과 아키텍처'의 영역으로 넓혀준 아주 값진 마라톤이 되었습니다. 프로젝트는 아직 끝나지 않았습니다. 앞으로 이어질 더 깊은 아키텍처 개선 과정도 순차적으로 공유하겠습니다.