블로그로 돌아가기
API GatewayAWSRESTGraphQLMSA마이크로서비스보안
API Gateway 완전 정복: 마이크로서비스의 '정문'을 설계하는 법
클라이언트가 50개의 마이크로서비스와 각각 통신하면 어떤 일이 벌어질까? API Gateway가 왜 필요한지, AWS API Gateway부터 Kong, Envoy, AppSync까지 — 실전 선택 가이드와 보안 사례를 풀어본다.
코어닷투데이2026-02-2134분
들어가며: 마이크로서비스가 50개가 되면
이 시리즈에서 다룬 기술들을 모아 마이크로서비스 아키텍처를 구축했다고 하자. 사용자 서비스, 주문 서비스, 결제 서비스, 재고 서비스, 추천 서비스, 알림 서비스... 각각 ECS나 Lambda에서 독립적으로 실행된다.
모바일 앱이 "주문 내역" 화면을 보여주려면 어떤 데이터가 필요한가?
- 주문 서비스에서 주문 목록
- 상품 서비스에서 상품 상세 정보
- 결제 서비스에서 결제 상태
- 배송 서비스에서 배송 추적 정보
- 리뷰 서비스에서 작성 가능한 리뷰 여부
클라이언트가 5개 서비스에 직접 통신해야 한다면:
5개
API 호출
화면 하나를 그리기 위해
5개
서비스 주소를 알아야 함
클라이언트가 직접 관리
5번
인증 처리
각 서비스마다 토큰 검증
서비스가 50개로 늘어나면? 클라이언트가 50개의 서로 다른 엔드포인트를 알아야 하고, 각 서비스의 인증 방식을 이해해야 하고, 하나의 화면을 그리기 위해 수십 번의 API 호출을 해야 한다. 모바일 환경에서 이 수십 번의 라운드트립은 사용자 경험을 망친다.
"클라이언트는 하나의 문을 통해 모든 서비스에 접근할 수 있어야 한다."
이것이 API Gateway 패턴의 핵심이다.
1. API Gateway 패턴의 기원
마이크로서비스의 필연적 동반자
API Gateway는 마이크로서비스 아키텍처(MSA) 에서 거의 필수적으로 등장하는 패턴이다.
Chris Richardson은 그의 저서 "Microservices Patterns"(2018)에서 API Gateway를 마이크로서비스의 핵심 패턴 중 하나로 정의했다:
"API Gateway는 마이크로서비스 아키텍처의 단일 진입점이다. 외부 요청을 받아, 적절한 내부 서비스로 라우팅하고, 결과를 조합하여 클라이언트에게 반환한다."
Netflix의 엔지니어들이 이 개념을 2013년 Zuul이라는 이름으로 오픈소스화하면서 업계에 널리 퍼졌다.
API Gateway가 없으면 vs 있으면
API Gateway 없이 (클라이언트가 직접 통신)
모바일 앱
주문
상품
결제
배송
리뷰
API Gateway 있을 때 (단일 진입점)
모바일 앱
API Gateway
인증, 라우팅, 조합, 보호
주문
상품
결제
배송
리뷰
API Gateway의 7가지 역할
| 역할 | 설명 | 비유 |
|---|---|---|
| 라우팅 | /orders는 주문 서비스로, /products는 상품 서비스로 | 호텔 프론트 데스크 |
| 인증/인가 | 모든 요청의 JWT 토큰 검증을 중앙에서 처리 | 건물 출입증 확인 |
| Rate Limiting | 초당 요청 수 제한으로 남용·DDoS 방지 | 교통 신호등 |
| 요청/응답 변환 | 클라이언트 포맷 ↔ 백엔드 포맷 변환 | 통역사 |
| 응답 집계 | 여러 서비스의 결과를 하나로 조합 | 비서가 여러 부서에서 정보를 모아 보고 |
| 캐싱 | 자주 요청되는 응답을 캐싱하여 백엔드 부하 감소 | 자주 묻는 질문 안내판 |
| 모니터링 | 모든 API 호출의 지연 시간, 에러율, 사용량 추적 | CCTV |
2. AWS API Gateway
세 가지 유형
AWS API Gateway는 세 가지 유형을 제공한다:
| 유형 | 출시 | 프로토콜 | 주요 용도 |
|---|---|---|---|
| REST API | 2015 | HTTP/1.1 | 풀기능 REST API. 캐싱, WAF, 사용량 계획 |
| HTTP API | 2019 | HTTP/1.1, HTTP/2 | 저비용·저지연. 프록시 위주 |
| WebSocket API | 2018 | WebSocket | 실시간 양방향 통신 (채팅, 알림) |
선택 가이드: 대부분의 경우 HTTP API로 시작하라. REST API 대비 70% 저렴하고, 지연 시간이 짧다. REST API의 고급 기능(캐싱, API 키 사용량 계획, 요청 검증)이 필요한 경우에만 REST API를 선택하라.
API Gateway + Lambda: 서버리스 API의 표준 패턴
이 시리즈에서 반복 등장한 패턴:
클라이언트 → API Gateway → Lambda → DynamoDB/RDS
API Gateway가 HTTP 요청을 받으면:
- 인증 검증 (Cognito, Lambda Authorizer)
- 요청을 Lambda로 전달
- Lambda가 비즈니스 로직 수행
- 결과를 클라이언트에 반환
이 전체 스택에서 관리할 서버: 0대.
핵심 기능들
커스텀 도메인: api.yourdomain.com으로 접근 가능. ACM에서 SSL 인증서를 무료 발급하여 연결.
스테이지(Stage): dev, staging, prod 같은 배포 환경을 분리. 같은 API를 여러 환경에서 독립적으로 운영.
Lambda Authorizer: 인증 로직을 Lambda 함수로 커스터마이징. JWT 검증, API 키 확인, IP 기반 접근 제어 등을 자유롭게 구현.
사용량 계획(Usage Plan): API 키별로 일/월 할당량과 초당 제한을 설정. 외부 파트너에게 API를 제공할 때 필수.
캐싱(REST API만): 자주 요청되는 GET 응답을 API Gateway 레벨에서 캐싱. 백엔드 호출 없이 즉시 응답.
비용 구조
| 유형 | 요청 비용 | 비고 |
|---|---|---|
| REST API | $3.50 / 100만 건 | 캐싱, WAF 추가 가능 |
| HTTP API | $1.00 / 100만 건 | 기본 기능에 최적화 |
| WebSocket | $1.00 / 100만 메시지 + 연결 시간 | 실시간 통신 |
비용 함정 — 데이터 전송비: API Gateway의 요청 비용만 보면 저렴해 보이지만, 응답 데이터 전송비($0.09/GB)가 추가된다. 대용량 응답(이미지, 파일)을 API Gateway로 전달하면 비용이 급증한다. 대용량 데이터는 S3 + CloudFront Signed URL로 직접 전달하고, API는 메타데이터만 반환하라.
3. API 보안: 게이트웨이가 뚫리면 모든 것이 뚫린다
API는 공격자의 최우선 표적
API Gateway는 모든 요청의 진입점이다. 즉, 해커의 최우선 공격 대상이기도 하다. OWASP는 2023년 API Security Top 10을 별도로 발표할 만큼 API 보안을 중요하게 다루고 있다.
주요 API 보안 사고
2018
Facebook: 5,000만 계정 토큰 탈취
API의 "View As" 기능의 취약점을 통해 5,000만 명의 액세스 토큰이 유출. BOLA(Broken Object Level Authorization) 공격
2019
T-Mobile: 고객 정보 유출
API 엔드포인트에 인증 없이 접근 가능. 수백만 고객의 이름, 주소, 계정 번호 노출
2021
Peloton: 사용자 데이터 노출
API가 인증 없이 모든 사용자의 나이, 성별, 위치, 운동 기록을 반환. API 인증 누락
2023
Optus (호주 통신사): 1,000만 명 유출
공개 인터넷에 노출된 API 엔드포인트를 통해 1,000만 명의 여권번호, 운전면허, 주소 유출. Rate Limiting 부재
OWASP API Security Top 10 (2023) 핵심
| 순위 | 취약점 | 의미 | API Gateway에서의 대응 |
|---|---|---|---|
| 1 | BOLA | 다른 사용자의 데이터에 접근 | 인가 로직 강화 |
| 2 | 인증 결함 | 인증 메커니즘 우회 | Cognito/JWT 검증 |
| 3 | 과도한 데이터 노출 | 불필요한 필드까지 반환 | 응답 필터링 |
| 4 | 자원 제한 없음 | Rate Limiting 없이 무한 요청 | Usage Plan, WAF |
| 5 | 기능 수준 인가 결함 | 관리자 API에 일반 사용자 접근 | Lambda Authorizer |
API 보안 체크리스트: (1) 모든 엔드포인트에 인증 필수 — "인증 불필요"로 설정하기 전에 세 번 확인하라, (2) Rate Limiting 반드시 설정 — 무제한 API는 DDoS의 초대장, (3) WAF 연동 — SQL 인젝션, XSS 차단, (4) 응답에 민감 정보 포함 여부 확인, (5) CloudWatch로 이상 패턴 모니터링.
4. API Gateway 대안들: 풍경 비교
AWS API Gateway만이 선택지가 아니다. 다양한 대안이 있으며, 각각의 강점이 다르다.
주요 API Gateway 제품 비교
| 제품 | 유형 | 강점 | 약점 |
|---|---|---|---|
| AWS API Gateway | 관리형 (서버리스) | Lambda 통합, AWS 생태계 | 벤더 종속, 커스터마이징 제한 |
| Kong | 오픈소스 / 관리형 | 플러그인 생태계 풍부, 멀티클라우드 | 운영 복잡도, 자체 관리 필요 |
| Envoy Proxy | 오픈소스 | 고성능 L7 프록시, Istio 기반 | 설정 복잡, 학습 곡선 가파름 |
| NGINX | 오픈소스 / 상용 | 검증된 성능, 리버스 프록시 | API 전용 기능 제한적 |
| Traefik | 오픈소스 | K8s 네이티브, 자동 설정 | 대규모 커스터마이징 제한 |
| Cloudflare API Gateway | 관리형 | CDN + API 보안 통합, 글로벌 | AWS 서비스 통합 약함 |
| AWS AppSync | 관리형 (서버리스) | GraphQL 네이티브, 실시간 구독 | REST 미지원, GraphQL 전용 |
| AWS ALB | 관리형 | HTTP 라우팅, 비용 효율 | API 관리 기능 없음 |
상황별 선택 가이드
AWS API Gateway를 선택
서버리스(Lambda) 아키텍처
AWS 올인, 빠른 시작이 목표
API 키 관리, 사용량 계획 필요
인프라 관리를 최소화하고 싶음
대안을 고려해야 할 때
멀티클라우드/온프레미스 → Kong, Envoy
K8s 환경 → Envoy (Istio), Traefik
GraphQL 위주 → AppSync
단순 HTTP 라우팅만 → ALB가 더 저렴
Kong: 가장 대중적인 오픈소스 API Gateway
Kong은 2015년 출시된 오픈소스 API Gateway로, NGINX 위에 구축됐다. 가장 큰 강점은 플러그인 생태계:
- 인증 (OAuth2, JWT, LDAP, API Key)
- Rate Limiting
- 로깅 (Datadog, Splunk, Kafka)
- 변환 (요청/응답 변환)
- 커스텀 플러그인 (Lua/Go로 직접 작성)
Kong은 K8s 환경에서 Ingress Controller로도 작동한다. API Gateway와 K8s 인그레스를 하나의 도구로 해결할 수 있다.
Envoy: 서비스 메시의 기반
Google이 내부적으로 사용하던 프록시를 Lyft가 오픈소스화한 Envoy Proxy는 L7 프록시 + API Gateway + 서비스 메시 데이터 플레인을 모두 겸한다.
Istio(서비스 메시)의 데이터 플레인이 Envoy다. K8s 환경에서 마이크로서비스 간 트래픽을 관리하려면 Envoy/Istio가 가장 강력한 선택지다.
AppSync: GraphQL이 필요하면
REST API가 "정해진 형태의 데이터"를 반환한다면, GraphQL은 "클라이언트가 원하는 필드만 골라서 한 번에 가져오는" 방식이다.
hljs language-graphql
# REST: 3번 호출 필요
GET /users/123
GET /users/123/orders
GET /users/123/reviews
# GraphQL: 1번 호출로 원하는 데이터만
query {
user(id: "123") {
name
orders { id, total }
reviews { rating }
}
}
AWS AppSync는 GraphQL을 완전 관리형으로 제공한다. DynamoDB, Lambda, RDS를 리졸버로 연결하면 GraphQL API가 자동으로 구축된다.
REST vs GraphQL 선택 기준: 클라이언트가 다양하고 각각 다른 데이터가 필요하면(모바일은 축소 버전, 웹은 전체) → GraphQL(AppSync). 서버 대 서버 통신이 주이거나 단순한 CRUD → REST(API Gateway HTTP API). 둘 다 필요하면 혼합 사용이 가능하다.
ALB를 API Gateway 대신 쓸 수 있을까?
Application Load Balancer(ALB) 도 경로 기반 라우팅, 호스트 기반 라우팅을 지원한다. 단순 라우팅만 필요하면 ALB가 훨씬 저렴하다:
| 기능 | API Gateway (HTTP API) | ALB |
|---|---|---|
| 요청 비용 | $1.00/100만 건 | ~$0.008/100만 건 |
| 인증 | Lambda Authorizer, Cognito | Cognito, OIDC |
| Rate Limiting | 기본 제공 | 없음 (WAF 별도) |
| API 키 관리 | 있음 | 없음 |
| WebSocket | 지원 | 지원 (제한적) |
| 서버리스 연동 | Lambda 네이티브 | Lambda (타겟 그룹) |
비용 최적화 팁: ECS/EKS 서비스 앞에 단순 라우팅만 필요하다면 ALB가 API Gateway 대비 100배 이상 저렴하다. API 키 관리, 사용량 계획, Lambda 직접 연동이 필요한 경우에만 API Gateway를 사용하라.
5. 실전 아키텍처 패턴
패턴 1: 서버리스 REST API
클라이언트 → API Gateway (HTTP API) → Lambda → DynamoDB
가장 단순하고 가장 많이 쓰이는 패턴. 서버 0대, 완전 자동 스케일링.
패턴 2: BFF (Backend for Frontend)
모바일, 웹, IoT 디바이스가 각각 다른 데이터 형태를 필요로 할 때:
BFF 패턴
모바일 앱
웹 앱
IoT
Mobile BFF
Web BFF
IoT BFF
주문
상품
결제
배송
각 BFF가 자기 클라이언트에 최적화된 응답을 조합한다. Mobile BFF는 데이터를 최소화하고, Web BFF는 풍부한 데이터를 반환한다.
패턴 3: API Gateway + ALB 하이브리드
외부 API → API Gateway (인증, Rate Limiting, API 키) → ALB → ECS
내부 API → ALB → ECS (API Gateway 생략으로 비용 절감)
외부에 노출되는 API만 API Gateway를 거치고, 내부 서비스 간 통신은 ALB로 직접하여 비용을 절감한다.
6. 실제 사례
Netflix: Zuul에서 시작된 API Gateway 패턴
Netflix는 2013년 Zuul을 오픈소스로 공개했다. Netflix의 모든 외부 트래픽은 Zuul을 거치며, 초당 수만 건의 요청을 라우팅한다. 동적 필터로 A/B 테스트, 카나리 배포, 인증, 로깅을 처리한다.
Stripe: API 우선 기업의 교과서
결제 서비스 Stripe는 API 자체가 제품인 기업이다. API Gateway를 통해 외부 개발자에게 결제 API를 제공하며, API 키 관리, 사용량 추적, 버전 관리를 체계적으로 운영한다. Stripe의 API 설계는 업계의 교과서로 꼽힌다.
Twilio: API 경제의 선두주자
음성/문자 API를 제공하는 Twilio는 API Gateway를 통해 전 세계 개발자에게 통신 API를 제공한다. Rate Limiting, 인증, 과금이 모두 API Gateway 레벨에서 처리된다.
한국 기업 사례
- 카카오: 카카오 로그인, 카카오맵 등 외부 API를 자체 API Gateway로 관리
- 토스: 금융 Open API를 파트너에게 제공. 엄격한 인증과 Rate Limiting 적용
- 쿠팡: 내부 마이크로서비스 간 통신에 API Gateway + ALB 하이브리드 패턴
7. API Gateway의 미래
AI와 API Gateway
2025~2026년의 트렌드는 AI 모델을 API로 서빙하는 것이다:
- AI 추론 API: 모델을 Lambda/ECS에 배포하고 API Gateway로 노출
- LLM Gateway: 여러 AI 모델(GPT, Claude, Gemini)에 대한 통합 API Gateway. Rate Limiting, 비용 추적, 모델 라우팅
- RAG API: 벡터 검색 + LLM 생성을 하나의 API로 조합
API First 문화
"API를 먼저 설계하고, 구현은 그 다음" — 이 API First 접근이 확산되고 있다. OpenAPI (Swagger) 스펙으로 API를 먼저 정의하고, 이 스펙에서 문서, 클라이언트 SDK, 서버 스텁, 테스트를 자동 생성한다.
마치며: API Gateway는 "계약"이다
API Gateway의 본질은 이것이다:
"외부 세계와 내부 시스템 사이의 계약서."
클라이언트에게는 안정적이고 일관된 인터페이스를 약속하고, 내부적으로는 마이크로서비스가 자유롭게 진화할 수 있게 해방한다. 주문 서비스를 Python에서 Go로 바꿔도, Lambda에서 ECS로 옮겨도, API Gateway 뒤에서 일어나는 일이므로 클라이언트는 알 필요가 없다.
이 시리즈를 통해 구축한 전체 아키텍처의 그림이 완성된다:
- CloudFront → 정적 콘텐츠를 전 세계에서 빠르게 (거리 추상화)
- API Gateway → 모든 API 요청의 단일 진입점 (접근 추상화)
- Lambda / ECS → 비즈니스 로직 실행 (컴퓨팅 추상화)
- DynamoDB / RDS / OpenSearch → 데이터 저장과 검색 (데이터 추상화)
- S3 → 파일과 객체의 무한 저장소 (스토리지 추상화)
코어닷투데이의 AI API도 이 패턴 위에 있다. API Gateway가 외부 요청을 받고, Lambda가 추론을 실행하며, DynamoDB가 결과를 캐싱하고, S3가 모델을 저장한다. 클라이언트에게는 POST /v1/predictions 하나의 엔드포인트만 보인다 — 그 뒤의 복잡성은 모두 추상화되어 있다.