API Gateway는 클라이언트와 백엔드 서비스 사이의 중간 계층 역할을 수행하는 컴포넌트로, MSA(Microservices Architecture), 클라우드 네이티브 아키텍처, 서버리스 환경 등에서 핵심적인 역할을 합니다.
📌 API Gateway란?
API Gateway는 여러 개의 백엔드 서비스를 대표하여 **단일 진입점(Single Entry Point)**을 제공합니다. 외부 요청은 모두 이 Gateway를 거쳐 내부 서비스로 전달됩니다.
예:
🎯 주요 기능
| 라우팅(Routing) | 요청 URI 또는 메서드 기반으로 내부 마이크로서비스로 전달 |
| 인증/인가(Authentication/Authorization) | JWT, OAuth2, API Key 등으로 인증/인가 수행 |
| 속도 제한(Rate Limiting) | 악의적 트래픽 또는 과도한 요청 제어 |
| 로드 밸런싱(Load Balancing) | 여러 백엔드 인스턴스에 트래픽을 분산 |
| 로깅 및 모니터링 | 요청/응답 기록 및 성능 추적, APM 연동 |
| 트랜스포트 보안 | TLS 종료, HTTPS 지원 |
| 요청 변환 | 요청/응답 포맷 조작 (예: JSON ↔ XML) |
| 캐싱(Caching) | 빈번한 API 응답을 Gateway에서 캐싱 |
| CORS 처리 | Cross-Origin Resource Sharing 제어 |
🏗 아키텍처 예시 (MSA 기반)
🚀 장점
- 클라이언트는 여러 서비스 주소를 알 필요 없음 → 단일 엔드포인트 관리
- 인증, 보안, 로깅, 트래픽 제어 등 공통 기능을 중앙 집중화
- 백엔드 마이크로서비스는 핵심 로직에 집중 → 관심사 분리
🛑 단점 및 주의점
- **단일 장애 지점(SPOF)**이 될 수 있음 → HA 구성 필요
- Gateway 자체의 성능 병목 가능성 → Auto Scaling, 캐싱, Rate Limiting 고려
- 트래픽이 많은 경우 → L7 프록시 최적화 및 이중화 필요
🔧 대표적인 API Gateway 솔루션
| NGINX / NGINX Plus | 오픈소스 기반, 성능 우수, 다양한 설정 가능 |
| Kong | 확장성 뛰어난 오픈소스, 플러그인 기반 |
| AWS API Gateway | 서버리스 환경, Lambda와 잘 통합됨 |
| Azure API Management | Azure 서비스와 통합, 정책 기반 관리 |
| Spring Cloud Gateway | Java/Spring 기반 MSA 환경에 최적화 |
| Ambassador / Gloo Gateway | Kubernetes 환경에 특화된 Ingress 기반 |
📂 실무 시나리오 예 (TA 시험용)
- API Gateway 장애 발생 시 조치 방안은?
- 로깅 시스템을 통해 요청 추적
- 백엔드 헬스체크 상태 확인
- Load Balancer 상태 점검 및 이중화 확인
- JWT 인증을 Gateway에서 수행하는 이유는?
- 각 마이크로서비스에서 인증을 반복하지 않기 위해 (중복 제거, 성능 향상)
- MSA 환경에서 Rate Limiting이 필요한 이유는?
- API 오용 또는 DDoS 방어, 백엔드 과부하 방지
📚 관련 개념과 비교
| Ingress Controller | Kubernetes에서 API Gateway 역할 일부 수행 |
| Service Mesh | Istio/Linkerd 등 사이드카 기반 통신 제어 (L7 기능 분리) |
| Load Balancer | L4/L7 트래픽 분산, API Gateway와 기능 일부 중첩됨 |
필요하면 아래 항목도 도와줄 수 있어요:
- Spring Cloud Gateway 설정 예시
- AWS API Gateway vs NGINX 비교
- 실무 시나리오 기반 문제 10~20문항 제작
🧠 API Gateway 암기카드 요약본
🔹 기본 개념
- 🔑 API Gateway: 클라이언트 요청을 백엔드에 라우팅하고, 인증·속도제한·로깅 등을 처리하는 중간자
- 🔑 역할: 인증/인가, 라우팅, 캐싱, 트래픽 제어, 응답 변환, CORS 처리
- 🔑 위치: 클라이언트 ↔ 백엔드 사이 (MSA 앞단)
🔹 기능별 정리
✅ 인증·인가
- 🔑 JWT 검증 → Gateway에서 서명 키/클레임 검증
- 🔑 OAuth2 연동 → 인증 서버 리디렉션 경로 주의
- 🔑 Subscription Key (APIM) → 클라이언트 인증에 사용
✅ 라우팅
- 🔑 Path/Host/Header 기반 분기
- 🔑 RewritePath, StripPrefix → URI 변경 필터
✅ 속도 제한 / 보안
- 🔑 Rate Limiting → 사용자/IP/키 기준 요청수 제한
- 🔑 Quota → 일정 시간당 총 요청수 제한
- 🔑 IP Whitelist/Blacklist → 보안 강화
- 🔑 RemoveResponseHeader → 민감 헤더 제거
✅ 응답 처리
- 🔑 응답 캐싱 → 동일 요청 결과 재사용
- 🔑 응답 압축 → gzip 등 클라이언트 Accept-Encoding 필요
- 🔑 응답 변환 → BodyRewrite(Filter), 헤더 추가/삭제
✅ 모니터링·로깅
- 🔑 Trace-ID 주입 → X-Request-ID 로깅용
- 🔑 Azure → App Insights 연동, Spring → Sleuth, Zipkin, ELK
🔹 플랫폼별 특징
🔸 Spring Cloud Gateway
- 🔑 Java 기반, Netty 내장, Spring 생태계와 연계 우수
- 🔑 application.yml 기반 설정
- 🔑 GlobalFilter vs RouteFilter 분리
- 🔑 커스텀 필터 구현 가능 (@Component)
🔸 Azure API Management
- 🔑 완전관리형 API Gateway
- 🔑 Developer Portal + JWT/OAuth2 + 정책 기반 처리
- 🔑 validate-jwt, set-header, rate-limit-by-key 등 Policy 사용
- 🔑 하이브리드 게이트웨이 가능 (Self-hosted Gateway)
🔸 Kong / NGINX
- 🔑 플러그인 구조 + Lua 기반 커스터마이징
- 🔑 오픈소스 또는 Enterprise 모델 선택
- 🔑 NGINX는 Reverse Proxy → 라우팅과 보안 기본기 탁월
🔹 실무 이슈 키워드 정리
| 🔸 401 Unauthorized | JWT 키 불일치 |
| 🔸 504 Timeout | Gateway Timeout 설정 |
| 🔸 429 Too Many Requests | Rate Limit 초과 |
| 🔸 CORS 오류 | Access-Control-Allow-Origin 누락 |
| 🔸 리디렉션 실패 | PathRewrite 미설정 |
| 🔸 쿠키 미전송 | Secure + HTTPS 미사용 |
| 🔸 응답 누락 | LB HealthCheck 실패 |
✅ API Gateway 실무 시나리오 기반 문제집 (10문항)
NO.01 – 인증 연계 오류 시나리오
문제:
Spring Cloud Gateway를 사용하는 시스템에서 인증서버(JWT 기반)는 별도로 존재한다. 최근 클라이언트의 요청이 "401 Unauthorized"로 반환되는 현상이 다수 발생하고 있다. 아래 중 가장 먼저 확인해야 할 항목은?
① 인증 서버의 DB 연결 상태
② JWT 토큰의 서명 키(Key) 일치 여부
③ 클라이언트의 요청 헤더 구조
④ 백엔드 서비스의 응답 상태
⑤ 클라이언트의 IP 화이트리스트 설정
정답: ②
해설:
Gateway가 JWT 토큰을 검증할 때 사용하는 서명 키가 인증서버와 일치하지 않으면 모든 요청이 실패하게 된다. 이는 인증서버 변경 후 Gateway 설정이 반영되지 않았을 때 자주 발생한다.
NO.02 – URI 라우팅 오류
문제:
API Gateway에서 /api/v1/user/** 요청을 백엔드의 USER-SERVICE로 라우팅하려 한다. 그러나 요청이 404로 실패하고 있다. 설정에서 가장 의심할 부분은?
① CORS 정책
② LoadBalancer 설정
③ Route Path 설정
④ 요청 본문 크기 제한
⑤ Retry 정책
정답: ③
해설:
Spring Cloud Gateway에서 Path=/api/v1/user/**로 설정되어 있어야 해당 경로의 요청이 올바르게 라우팅된다. 패턴 매칭이 잘못되면 요청이 대상 서비스로 전달되지 않는다.
NO.03 – 요청 시간 초과 문제
문제:
API Gateway를 통해 호출된 일부 API가 5초 이상 지연되며 클라이언트는 504 Gateway Timeout을 겪고 있다. 가장 먼저 점검해야 할 것은?
① 백엔드 서비스의 DB CPU 사용량
② Gateway의 Timeout 설정
③ API의 응답 페이로드 크기
④ 클라이언트의 네트워크 대역폭
⑤ HTTPS 설정
정답: ②
해설:
Spring Cloud Gateway는 기본 Timeout이 설정되어 있으며, 백엔드 서비스가 정상 동작하더라도 Timeout 설정이 짧으면 요청이 끊긴다. 설정은 spring.cloud.gateway.httpclient.connect-timeout 등으로 조정 가능하다.
NO.04 – Rate Limiting 이슈
문제:
외부 파트너 시스템에서 특정 API 호출 시 429 Too Many Requests가 지속적으로 발생하고 있다. 가장 가능성이 높은 원인은?
① 백엔드 서비스 오류
② Gateway의 Rate Limiter 설정
③ DNS 캐시 문제
④ JWT 만료
⑤ 로깅 설정 누락
정답: ②
해설:
API Gateway에 Redis 기반 Rate Limiter를 설정한 경우, 사용자 단위 또는 IP 단위로 초당 요청 수를 제한할 수 있다. 과도한 요청은 자동으로 차단된다.
NO.05 – CORS 정책 실패
문제:
프론트엔드에서 API 호출 시 "CORS policy: No ‘Access-Control-Allow-Origin’ header" 오류가 발생한다. 해결 방법으로 올바른 것은?
① Gateway에서 CORS 필터를 제거한다
② 백엔드 서비스의 포트를 변경한다
③ Gateway에 Global CORS 설정을 추가한다
④ 클라이언트 요청을 HTTPS로 전환한다
⑤ 인증 서버 설정을 변경한다
정답: ③
해설:
Spring Cloud Gateway에 Global CORS 설정을 명시적으로 추가해야 하며, allowedOrigins, allowedHeaders, allowedMethods 등을 포함해야 한다.
NO.06 – JWT 토큰 검증 실패
문제:
Gateway에서 JWT 토큰 검증 시 항상 실패한다. JWT는 HS256 알고리즘으로 서명되어 있다. 아래 중 가장 높은 우선순위로 점검할 항목은?
① JWT 발급자의 이메일 주소
② 백엔드 응답 바디 구조
③ Gateway의 Signing Key 설정
④ HTTP 상태코드 설정
⑤ 클라이언트 버전
정답: ③
해설:
HS256은 대칭키 기반 알고리즘이므로 Gateway와 인증 서버가 동일한 시크릿 키를 사용해야 한다. 키가 불일치할 경우 인증은 항상 실패한다.
NO.07 – 로깅 및 추적
문제:
여러 마이크로서비스 호출 간 트랜잭션 추적이 어려운 상황이다. 아래 기능 중 이를 해결하기 위한 가장 적절한 조치는?
① API Gateway에서 X-Trace-ID 헤더를 강제 주입
② 각 서비스별 DB 로그 활성화
③ API Gateway의 응답 캐싱 비활성화
④ 클라이언트의 디버깅 툴 설치
⑤ JWT 페이로드 내 사용자명 삽입
정답: ①
해설:
추적용 ID(X-Request-ID, X-Trace-ID 등)를 Gateway에서 주입하면 이후 모든 서비스가 해당 요청을 식별 가능하게 된다. 로그 상에서도 연관 추적이 쉬워진다.
NO.08 – 캐싱 설정 문제
문제:
API Gateway의 캐싱 정책이 활성화되어 있지만, 매 요청마다 백엔드까지 호출되는 현상이 있다. 설정상 가장 먼저 확인해야 할 것은?
① 응답 바디 구조
② 캐시 TTL 값
③ 요청 메서드 (GET, POST 등)
④ HTTP 상태코드
⑤ CORS 설정
정답: ③
해설:
대부분의 캐시 시스템은 GET 요청에 대해서만 캐싱이 가능하다. POST, PUT은 상태 변경이 동반되므로 캐시하지 않는다.
NO.09 – 요청 헤더 필터링
문제:
특정 API 호출 시 민감한 내부 헤더(X-Internal-Token)가 외부 클라이언트에도 전달되고 있다. 이를 방지하기 위한 Gateway의 기능은?
① AddHeader
② RewritePath
③ RemoveResponseHeader
④ AddRequestParameter
⑤ Retry
정답: ③
해설:
Spring Cloud Gateway에서는 RemoveResponseHeader 필터를 통해 응답 시 특정 헤더를 제거할 수 있다. 보안 측면에서 필수 설정이다.
NO.10 – 고가용성 이슈
문제:
API Gateway 서버 하나만 운영 중인데, 간헐적으로 접근 불가 문제가 발생한다. 인프라적으로 가장 먼저 취해야 할 조치는?
① TLS 인증서 재발급
② JWT 만료 시간 변경
③ 다중 인스턴스 및 로드밸런서 구성
④ 캐싱 무효화
⑤ 클라이언트 SDK 변경
정답: ③
해설:
단일 인스턴스 구조는 SPOF(Single Point of Failure) 문제가 존재하므로, 다중 인스턴스 + L4 로드밸런서를 통해 이중화해야 한다.
필요하시면 다음과 같이도 확장해드릴 수 있습니다:
- 20~30문항 문제집으로 확대
- 문제 난이도 표시 (상/중/하)
- 실습 기반 설정 파일 예시 (application.yml, Kong 설정 등)
- Gateway + 인증서버 + 백엔드 연동 시나리오 예시
원하시는 방향 알려주시면 계속 제작해드릴게요.
나의 말:
ChatGPT의 말:
좋습니다. 아래는 API Gateway 실무 시나리오 기반 문제 25문항이며, 각 문항마다 난이도(상/중/하) 및 정답과 해설을 포함했습니다.
현업에서 발생 가능한 Spring Cloud Gateway, Kong, AWS API Gateway 환경을 혼합해 구성했습니다.
✅ API Gateway 실무 시나리오 문제집 (25문항, 정답·해설 포함)
| 01 | 중 | 인증 연계 오류 | JWT 키 불일치 |
| 02 | 하 | 라우팅 설정 | URI 패턴 매칭 |
| 03 | 중 | 타임아웃 | 504 오류 원인 |
| 04 | 하 | Rate Limiting | 429 Too Many Requests |
| 05 | 하 | CORS | CORS 오류 |
| 06 | 중 | JWT 검증 실패 | Signing Key 문제 |
| 07 | 중 | 트레이싱 | Trace-ID 주입 |
| 08 | 하 | 캐시 | 캐시가 작동 안함 |
| 09 | 하 | 응답 헤더 보안 | 헤더 제거 |
| 10 | 중 | 고가용성 | SPOF 제거 |
NO.11 – 필터 체이닝 오류
난이도: 중
문제:
Spring Cloud Gateway에서 여러 Custom Filter를 등록했는데, 예상한 순서로 필터가 실행되지 않는다. 해결을 위해 설정해야 하는 것은?
① 필터 이름 순서
② 필터 체인 우선순위
③ 필터 내부 로그 레벨
④ 글로벌 CORS 우선순위
⑤ fallback URL 설정
정답: ②
해설:
Spring Cloud Gateway에서는 필터 우선순위를 명시적으로 지정하지 않으면 의도한 실행 순서가 보장되지 않는다. @Order 또는 GatewayFilterSpec.order()로 순서를 명시해야 한다.
NO.12 – OpenAPI 연동 실패
난이도: 하
문제:
API Gateway를 통해 프록시된 서비스에서 Swagger UI 접속이 실패하고 있다. 가장 가능성 높은 원인은?
① JWT 미사용
② Swagger 경로 라우팅 누락
③ 인증 서버 설정 오류
④ Circuit Breaker 미설정
⑤ 클라이언트 TLS 버전 불일치
정답: ②
해설:
Swagger 문서는 별도의 URI (/swagger-ui/) 경로를 사용하므로, 라우팅 설정에 이 경로를 포함하지 않으면 접근이 불가능하다.
NO.13 – 응답 압축 적용 안됨
난이도: 하
문제:
Gateway에서 gzip 압축 응답을 사용했으나, 실제 클라이언트에서는 압축이 적용되지 않는다. 가장 먼저 확인할 항목은?
① 클라이언트 Accept-Encoding 헤더
② 백엔드의 MIME 타입
③ JWT 암호화 여부
④ Redis TTL
⑤ 요청 Method
정답: ①
해설:
압축은 클라이언트가 Accept-Encoding: gzip 헤더를 포함시켜야 서버(Gateway)가 적용한다.
NO.14 – 쿠키 누락 현상
난이도: 중
문제:
프론트엔드 앱에서 인증 후 세션 쿠키를 발급받았으나, 이후 요청에 쿠키가 포함되지 않는다. 가장 유력한 원인은?
① API Gateway 캐시 설정
② 쿠키 Secure 설정 + HTTPS 미사용
③ DNS TTL 값
④ Signing Key 누락
⑤ Rate Limit 설정
정답: ②
해설:
쿠키가 Secure로 설정되어 있을 경우 HTTPS를 통해서만 전송된다. HTTP로 테스트 시 쿠키가 누락된다.
NO.15 – 클라이언트별 라우팅
난이도: 상
문제:
특정 클라이언트(Android)에서만 특정 백엔드 서비스로 라우팅하고자 한다. 이를 위해 사용할 수 있는 Gateway 설정 항목은?
① AddRequestHeader
② RequestPredicate + Header Match
③ RewritePath
④ AddCookie
⑤ Response Timeout 설정
정답: ②
해설:
Spring Cloud Gateway는 Header=User-Agent, Android 조건을 추가하여 Android 기반 요청만 특정 서비스로 라우팅할 수 있다.
NO.16 – IP 기반 접근제어
난이도: 중
문제:
내부망에서만 접근 가능한 API를 구성 중이다. Gateway에서 외부 접근을 차단하기 위한 설정으로 적절한 것은?
① CORS Deny-All
② IP Whitelist/Blacklist 필터
③ HTTPS 강제화
④ Rate Limiting
⑤ JWT Scope 제한
정답: ②
해설:
Spring Gateway 또는 NGINX에서는 IP 기반으로 화이트리스트/블랙리스트 설정이 가능하다. 민감 API 보호 시 유용하다.
NO.17 – 클러스터 모드 장애
난이도: 상
문제:
API Gateway를 3노드로 구성하고 HAProxy로 부하를 분산하였으나 간헐적으로 요청이 유실된다. 가능성 높은 원인은?
① 세션 쿠키 없음
② Redis Rate Limit 동기화 실패
③ LB의 HealthCheck 설정 누락
④ HTTP/2 비활성화
⑤ 인증서 만료
정답: ③
해설:
로드밸런서가 비정상 노드로 트래픽을 분산하면 유실이 발생할 수 있다. Health Check 설정 필수.
NO.18 – 인증 후 리디렉션 오류
난이도: 중
문제:
OAuth2 인증 후 /login/oauth2/code/...로 리디렉션되지 않고 404 오류가 발생한다. 가장 먼저 확인할 항목은?
① 클라이언트 리다이렉트 URI
② API Gateway PathRewrite
③ 로그인 폼 ID
④ CORS 응답헤더
⑤ JWT Payload 구조
정답: ②
해설:
OAuth 인증 후의 리디렉션 URI는 Gateway가 백엔드로 전달해야 하므로, 해당 경로에 대한 RewritePath 설정이 필요하다.
NO.19 – Multi-Tenant 구조 분기
난이도: 상
문제:
API Gateway에서 다중 고객 도메인별로 서로 다른 백엔드 서비스에 연결되도록 구성하고자 한다. 적절한 기능은?
① Header 기반 필터링
② Host 기반 라우팅
③ JWT Scope 사용
④ Circuit Breaker
⑤ Path Strip
정답: ②
해설:
Host=client1.domain.com → backend-A,
Host=client2.domain.com → backend-B 식으로 호스트 기반 라우팅이 가능하다.
NO.20 – 응답 변환 문제
난이도: 상
문제:
외부 API에서 받은 JSON 응답을 내부 표준 스키마로 변환해야 한다. Gateway 수준에서 처리 가능한 방식은?
① ResponseBodyRewrite Filter
② WebClient 호출 내부 가공
③ AddResponseHeader
④ PathRewrite
⑤ CORS 설정 변경
정답: ①
해설:
Spring Cloud Gateway 3.x 이후로는 응답 본문도 가공 가능한 필터를 정의할 수 있으며, 표준화된 응답 스키마로 변환 가능하다.