API Gateway

ChoRong0824·2025년 9월 1일

CS & 필수 및 기본 지식

목록 보기

18/30

📌 API Gateway 정리

1️⃣ 개념과 필요성

📌 API Gateway란?

정의: API Gateway는 클라이언트(웹/앱)와 백엔드 서비스(Microservices, DB, Lambda 등) 사이에서 단일 진입점(Single Entry Point) 역할을 하는 중간 계층이다.
핵심 역할: 들어오는 API 요청을 받아서 적절한 서비스로 라우팅, 보안 검증, 트래픽 제어, 응답 가공 등을 수행한다.
즉, 클라이언트는 내부 서비스 구조를 몰라도 되고, 서버는 외부 노출을 최소화할 수 있다.

📌 왜 필요한가?

MSA 환경에서의 필수 요소
- 마이크로서비스 아키텍처(MSA)에서는 서비스가 수십~수백 개로 쪼개진다.
- 클라이언트가 각각의 서비스와 직접 통신한다면 → 복잡해지고 보안도 약해진다.
- API Gateway는 단일 접점을 제공해 이 문제를 해결한다.
보안 강화
- 인증(Authentication)과 인가(Authorization)를 게이트웨이에서 처리한다.
- JWT 토큰 검증, OAuth, IAM 연동 등 → 서비스마다 구현할 필요가 없다.
일관된 API 제공
- 다양한 백엔드(레거시 시스템, 클라우드, 서드파티 API)가 있더라도 게이트웨이를 통해 통합된 API 포맷으로 제공할 수 있다.
- 예: 클라이언트는 /api/v1/user만 호출하면 되지만, 실제로는 내부에서 3개의 서비스가 협력해서 응답한다.
운영 효율성
- 로깅/모니터링/트래픽 제어를 한 곳에서 관리 가능 → DevOps 효율성 극대화.

💡 정리

API Gateway는 복잡한 시스템 구조를 숨기고, 보안·트래픽 제어·일관성을 제공하는 필수 인프라 구성요소다.
특히 MSA와 서버리스 시대에 더 중요한 역할을 맡고 있다.

2️⃣ 기능 (범주별)

API Gateway는 단순히 요청을 받아서 전달하는 게 아니라, 부가적인 기능을 통해 보안·운영·성능까지 책임진다.
대표적으로 네 가지 범주로 나눌 수 있다.

1. 요청 처리 (Request Handling)

라우팅 (Routing)
- 클라이언트 요청을 적절한 서비스로 전달
- URL 경로나 메서드(GET, POST 등)에 따라 다르게 동작
- 예: /user/* → User Service, /order/* → Order Service
데이터 변환 (Transformation)
- 요청/응답 포맷 변환: JSON ↔ XML, gRPC ↔ REST
- 필드 매핑: 클라이언트와 백엔드 간 데이터 스키마 차이를 흡수
Aggregation (집계)
- 여러 서비스에서 가져온 데이터를 하나로 합쳐 응답
- 예: 사용자 프로필 요청 시 → User Service + Order Service + Payment Service 데이터 통합 후 반환

2. 보안 (Security)

인증 (Authentication)
- 사용자가 누구인지 확인 (JWT, OAuth2, SAML, API Key 등)
- 클라이언트가 직접 서비스마다 인증하지 않고 게이트웨이에서 통합 인증 처리
인가 (Authorization)
- 사용자가 요청한 자원에 접근할 권한이 있는지 확인
- Role 기반 접근 제어(RBAC), 정책 기반 접근 제어(PBAC) 적용
보안 정책 관리
- TLS 암호화, DDoS 방어, WAF(Web Application Firewall) 연동
- 기업 환경에서는 LDAP, IAM, 보안 정책과 연계해 통합 보안 제공

3. 트래픽 제어 (Traffic Control)

Rate Limiting
- 일정 시간 동안 허용되는 요청 수 제한
- 예: 사용자당 초당 100회 호출 제한
Throttling
- 순간적으로 트래픽이 몰릴 때 요청 속도를 늦춰서 서버 과부하 방지
Caching
- 자주 요청되는 응답을 게이트웨이 레벨에서 캐싱
- 예: GET /products 요청 결과를 60초 동안 캐싱 → 서버 부하 감소

4. 운영/관리 (Operations & Management)

모니터링 & 로깅
- API 호출 수, 오류율, 응답 시간 → 대시보드에서 시각화
- 장애 조기 감지, SLA 준수 여부 확인
분석 (Analytics)
- 어떤 API가 가장 많이 호출되는지, 트래픽 패턴은 어떤지 분석
- 비즈니스 인사이트로 활용 가능
DevOps 연계
- CI/CD 파이프라인에 API 배포 자동화 연계
- API 버저닝, 롤백, Canary Release 지원

💡 정리

API Gateway는 단순 라우터가 아니라,

요청 라우팅/데이터 변환
인증/인가/보안 정책 적용
Rate Limit/Throttling/Caching으로 트래픽 제어
로깅/모니터링/DevOps 연계

까지 포함한 API 관리의 허브(Hub) 역할을 한다.

3️⃣ 아키텍처 관점

API Gateway는 시스템 설계의 어디에 위치하는지, 그리고 요청이 어떻게 흐르는지를 이해하는 것이 핵심이다.

1. MSA / 서버리스에서 API Gateway의 위치

Monolithic 아키텍처에서는 클라이언트가 하나의 서버와 직접 통신한다.
하지만 MSA(Microservice Architecture)나 Serverless 환경에서는 서비스가 여러 개로 쪼개져 있다.
- 예: 사용자 서비스, 주문 서비스, 결제 서비스, 알림 서비스 등.
이때 API Gateway가 단일 진입점(Single Entry Point) 역할을 맡아 클라이언트 요청을 대신 받아 각 서비스로 분배한다.

장점

클라이언트는 단순화된 API만 호출하면 됨.
내부 서비스는 외부 노출 최소화 → 보안 강화.
인증/로깅/트래픽 제어를 중앙 집중화.

2. 데이터 플로우 (Request → Gateway → Service)

요청의 흐름을 단계별로 살펴보자.

[ Client (웹/앱) ]
│
▼
[ API Gateway ]
├─ 인증/인가 처리 (JWT, OAuth2 등)
├─ 라우팅 (URL 기반, 메서드 기반)
├─ 요청 데이터 변환 (JSON ↔ XML 등)
├─ Rate Limiting / Throttling / Caching
│
▼
[ Backend Services ]

User Service

Order Service

Payment Service
│
▼
[ API Gateway 응답 가공 ]
│
▼
[ Client ]

예시: 주문 조회 요청
1. 클라이언트가 /api/v1/orders/123 요청
2. API Gateway에서 JWT 인증 → 사용자 권한 확인
3. 내부 Order Service로 요청 라우팅
4. 응답 데이터(JSON)를 클라이언트 스펙에 맞게 변환 후 반환

3. 아키텍처 패턴 속 API Gateway

BFF(Backend for Frontend)
- API Gateway는 여러 프론트엔드(웹, 모바일)에 맞춰 응답을 조정할 수 있어 BFF 패턴과 밀접한 관계가 있다.
Service Mesh와 비교
- Service Mesh(예: Istio)는 서비스 간 통신을 관리
- API Gateway는 클라이언트 ↔ 서비스 통신을 관리
- 두 개념은 보완적이다.

💡 정리

API Gateway는 클라이언트 요청의 단일 진입점
요청을 받아 → 보안/정책/트래픽 제어를 적용하고 → 적절한 서비스로 라우팅
MSA/서버리스 아키텍처에서 복잡성을 줄이고 운영 효율성을 제공한다.

4️⃣ 대표 구현 사례

API Gateway는 개념적으로는 같지만, 클라우드 벤더나 솔루션 제공사마다 구현 방식과 강조점이 다르다.
대표적인 사례로 AWS API Gateway와 IBM API Gateway(API Connect)를 비교해보자.

4.1 AWS API Gateway

특징
- AWS에서 제공하는 클라우드 네이티브 서비스
- 서버리스 아키텍처(Lambda, DynamoDB, S3)와 긴밀하게 연동
- REST, HTTP, WebSocket API 모두 지원
강점
- 자동 스케일링: 트래픽 급증에도 대응
- 저비용 과금: 호출 수 기반 과금, 초기 비용 부담 적음
- 개발자 친화: OpenAPI/Swagger 지원, Postman·CI/CD 연계
활용 예시
- 모바일 앱 백엔드 API
- 스타트업/소규모 서비스의 서버리스 API 구축
- 실시간 알림(WebSocket API)

4.2 IBM API Gateway (API Connect)

특징
- IBM API Connect라는 통합 플랫폼의 핵심 구성 요소
- 온프레미스·멀티클라우드·하이브리드 환경을 모두 지원
- 엔터프라이즈급 보안/정책 관리 기능 강화
강점
- 엔터프라이즈 보안: OAuth2, SAML, LDAP, AD, JWT 연계 가능
- 정책 기반 관리: GUI로 접근 제어, 트래픽 제어, 규제 준수 정책 적용
- 레거시 Modernization: 기존 온프레미스 시스템을 API 형태로 노출
활용 예시
- 금융, 의료, 공공기관 등 규제 산업
- 멀티클라우드 전략(온프레미스 + 클라우드) 환경
- 보안팀·운영팀이 주도적으로 관리하는 대규모 조직

4.3 AWS vs IBM 비교 요약

구분	AWS API Gateway	IBM API Gateway (API Connect)
초점	서버리스, 개발자 친화	엔터프라이즈 보안, 정책 관리
운영 환경	AWS 클라우드 전용	온프레미스 + 멀티클라우드
비용 구조	호출 수 기반 저비용	라이선스 기반 고비용
보안	IAM, Cognito 중심	LDAP, AD, SAML, OAuth, 정책 기반
사용 사례	스타트업, 모바일 앱	금융, 공공, 제조 등 규제 산업

💡 정리

AWS는 서버리스와 개발 생산성을 강조한 클라우드 네이티브 서비스
IBM은 엔터프라이즈 환경에서 필요한 보안·정책·하이브리드 통합을 강조
둘 다 API Gateway지만, 적용 대상과 포커스가 완전히 다르다.

5️⃣ 장단점과 고려사항

API Gateway는 MSA, 서버리스 아키텍처에서 사실상 표준 구성 요소지만, 사용 시 반드시 고려해야 할 장점과 단점이 존재한다.

1. 장점

중앙 집중 관리
- 인증, 인가, 보안 정책, 로깅, 모니터링 등을 게이트웨이에서 한 번에 처리
- 각 서비스마다 별도 구현할 필요가 없어 개발 속도와 일관성 확보
보안 강화
- 외부 트래픽이 직접 서비스로 들어가지 않고 게이트웨이에서 방어벽 역할
- DDoS, SQL Injection, XSS 같은 공격을 1차적으로 차단 가능
- TLS 종료 지점(Termination Point) 역할도 수행
일관된 API 제공
- 클라이언트는 단일 엔드포인트만 알면 됨
- 내부 서비스 구조가 변경돼도 게이트웨이 레벨에서 추상화 가능
운영 효율성
- API 호출량, 오류율, 응답 시간 등 메트릭을 한 곳에서 수집·분석
- 장애 대응, SLA 관리, 성능 튜닝이 쉬워짐

2. 단점

단일 장애 지점 (SPOF, Single Point of Failure)
- 게이트웨이에 문제가 생기면 전체 API가 마비될 수 있음
- 고가용성(HA) 아키텍처 구성 필요 (멀티 AZ, 멀티 리전 배포)
성능 병목 가능성
- 모든 요청이 게이트웨이를 거치므로 부하 집중
- 요청 변환/응답 집계 기능을 과도하게 쓰면 지연(latency) 발생
운영 복잡성
- API 정책, 버저닝, 인증 체계 관리 등 운영 부담 증가
- DevOps, 보안팀, 개발팀 간 협업 구조가 필요

3. 고려사항

트래픽 규모
- 소규모 서비스는 AWS 같은 저비용·자동 스케일링 서비스로 충분
- 대규모/규제 산업은 엔터프라이즈 솔루션(IBM 등) 필요
보안 요구 수준
- 규제 산업(금융, 의료, 공공) → 고급 보안·정책 관리 기능 중요
- 일반 스타트업 → IAM, JWT 정도로 충분
비용 모델
- 호출 수 과금(AWS) vs 라이선스 기반(IBM) → 장기 운영 시 총비용 비교 필요
운영 조직 구조
- 운영팀·보안팀 중심: GUI 기반 정책 관리(IBM)
- 개발팀·DevOps 중심: IaC 기반 관리(AWS)

💡 정리

API Gateway는 보안·일관성·운영 효율성을 제공하는 강력한 도구지만,
동시에 SPOF, 성능 병목, 운영 복잡성이라는 리스크를 안고 있다.
따라서 서비스 규모·보안 요구·비용·조직 문화를 종합적으로 고려해야 최적의 선택이 가능하다.

6️⃣ 활용 사례

API Gateway는 개념적으로 보편적이지만, 실제로는 서비스 규모와 도메인 특성에 따라 활용 방식이 달라진다.
대표적으로 AWS와 IBM의 사례를 기반으로 정리해보자.

1. AWS API Gateway 활용 사례

스타트업 / 소규모 서비스
- 초기 인프라 비용을 최소화하고 빠르게 API를 배포해야 하는 경우
- 예: 모바일 앱 백엔드, 간단한 웹 서비스
- API Gateway + Lambda 조합으로 서버 관리 부담을 제거
실시간 서비스
- WebSocket API를 통해 실시간 채팅, 알림, 주식 시세 스트리밍 등 구현
IoT
- 수많은 기기에서 발생하는 요청을 API Gateway로 받아 서버리스 방식으로 처리

2. IBM API Gateway (API Connect) 활용 사례

금융/공공기관
- 복잡한 보안 요구 사항과 규제 준수가 필요한 산업
- 예: 은행이 외부 파트너에게 오픈뱅킹 API를 제공할 때
- LDAP, AD, OAuth2 등 다양한 인증 체계와 정책 제어를 통해 규제 충족
멀티클라우드 전략
- 일부 워크로드는 온프레미스, 일부는 퍼블릭 클라우드에 위치
- IBM API Gateway를 사용해 통합 API 관리 → 레거시 Modernization 지원
대규모 B2B 환경
- 수십~수백 파트너사가 API를 통해 접속해야 하는 경우
- 계약별로 트래픽 제어, 접근 권한 차등 적용 가능

3. 일반적인 패턴별 활용

BFF (Backend for Frontend) 패턴
- 모바일, 웹, IoT 기기별로 다른 응답 포맷을 게이트웨이에서 처리
API 통합 계층
- 여러 마이크로서비스에서 응답을 모아 하나의 API 응답으로 가공
보안 경계선
- DMZ 구간에 API Gateway를 두어 외부 트래픽과 내부 네트워크를 분리

💡 정리

AWS: 스타트업·서버리스·실시간 서비스에 최적화
IBM: 엔터프라이즈·규제 산업·멀티클라우드 전략에 최적화
공통적으로: API Gateway는 단순 라우팅 도구가 아니라 API 보안/운영/정책 관리의 허브로 활용된다.

7️⃣ 면접/실무에서 자주 나오는 질문

Q1. API Gateway와 Load Balancer는 어떻게 다를까?

공통점: 둘 다 클라이언트 요청을 받아 뒤쪽 서버로 전달한다.
차이점:
- Load Balancer: 요청을 여러 서버에 분산 처리하는 게 목적 (L4/L7 로드밸런싱)
- API Gateway: 단순 분산뿐 아니라, 인증/인가, 요청 변환, 트래픽 제어, 모니터링 등 API 관리 기능을 제공
한 줄 정리:
- LB = “트래픽 분산기”
- API GW = “API 관리 허브”

Q2. API Gateway와 BFF(Backend for Frontend)는 같은 개념일까?

BFF: 클라이언트별(웹, 모바일 등) 맞춤 API를 제공하는 아키텍처 패턴
API Gateway: 인증, 정책, 트래픽 제어 등을 제공하는 인프라 구성 요소
관계:
- API Gateway는 BFF 패턴을 실현하는 도구로 활용될 수 있다.
- 즉, BFF는 설계 패턴, API Gateway는 구현 수단.

Q3. Rate Limiting과 Throttling은 무슨 차이가 있나?

Rate Limiting: 일정 기간 동안 허용되는 요청 수를 제한
- 예: 사용자당 초당 100회 호출 허용
Throttling: 순간적인 과부하 시 요청 속도를 늦추거나 일부를 지연시켜 서버 안정성 확보
한 줄 정리:
- Rate Limiting = “최대 허용치 정의”
- Throttling = “실시간으로 속도 조절”

Q4. API Gateway와 Service Mesh는 어떻게 다를까?

Service Mesh: 마이크로서비스 간 내부 통신을 관리 (서비스 ↔ 서비스)
API Gateway: 외부 클라이언트 ↔ 내부 서비스 간 통신을 관리
비유:
- Service Mesh = “서비스 간 도로 교통 관리”
- API Gateway = “외부에서 들어오는 톨게이트”

Q5. API Gateway를 도입하지 않고 직접 구현한다면 어떤 문제가 생길까?

모든 서비스마다 인증/인가, 로깅, 트래픽 제어를 중복 구현해야 함
서비스 간 정책이 달라져 일관성 저하
운영팀/보안팀 입장에서 통합 관리 불가능
장애 대응 및 모니터링 복잡도 증가

Q6. API Gateway가 단일 장애 지점(SPOF)이 되는 걸 어떻게 해결할까?

고가용성(HA) 아키텍처 적용
- 멀티 AZ, 멀티 리전 배치
- 오토스케일링 그룹 구성
캐싱·CDN과 연계해 일부 요청은 Gateway를 우회할 수 있도록 설계

Q7. API Gateway 도입 시 성능 저하를 막는 방법은?

데이터 변환/집계 기능을 최소화 (핵심 라우팅·보안에 집중)
캐싱 적극 활용
무거운 비즈니스 로직은 Gateway가 아닌 백엔드 서비스로 위임

💡 정리

API Gateway 면접 질문은 대부분 비슷한 개념들과의 차이점을 묻는다.
Load Balancer, BFF, Service Mesh, Rate Limiting/Throttling 같은 개념과 구분할 줄 알면 된다.
운영 측면에서는 SPOF, 성능 병목에 대한 대책을 말할 수 있으면 좋은 답변이 된다.

참고하면 좋은 정리글

IBM API GateWay
https://www.ibm.com/kr-ko/think/topics/api-gateway
아마존 API GateWay
https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/welcome.html

MSA 구현을 위한 API 게이트웨이
https://bcho.tistory.com/1005

ChoRong0824

정진, "어제보다 더 나은 오늘이 되자"

이전 포스트

프로그래머스 sql

다음 포스트

API Gateway

CS & 필수 및 기본 지식

📌 API Gateway 정리

1️⃣ 개념과 필요성

📌 API Gateway란?

📌 왜 필요한가?

💡 정리

2️⃣ 기능 (범주별)

1. 요청 처리 (Request Handling)

2. 보안 (Security)

3. 트래픽 제어 (Traffic Control)

4. 운영/관리 (Operations & Management)

💡 정리

3️⃣ 아키텍처 관점

1. MSA / 서버리스에서 API Gateway의 위치

2. 데이터 플로우 (Request → Gateway → Service)

3. 아키텍처 패턴 속 API Gateway

💡 정리

4️⃣ 대표 구현 사례

4.1 AWS API Gateway

4.2 IBM API Gateway (API Connect)

4.3 AWS vs IBM 비교 요약

💡 정리

5️⃣ 장단점과 고려사항

1. 장점

2. 단점

3. 고려사항

💡 정리

6️⃣ 활용 사례

1. AWS API Gateway 활용 사례

2. IBM API Gateway (API Connect) 활용 사례

3. 일반적인 패턴별 활용

💡 정리

7️⃣ 면접/실무에서 자주 나오는 질문

Q1. API Gateway와 Load Balancer는 어떻게 다를까?

Q2. API Gateway와 BFF(Backend for Frontend)는 같은 개념일까?

Q3. Rate Limiting과 Throttling은 무슨 차이가 있나?

Q4. API Gateway와 Service Mesh는 어떻게 다를까?

Q5. API Gateway를 도입하지 않고 직접 구현한다면 어떤 문제가 생길까?

Q6. API Gateway가 단일 장애 지점(SPOF)이 되는 걸 어떻게 해결할까?

Q7. API Gateway 도입 시 성능 저하를 막는 방법은?

💡 정리

참고하면 좋은 정리글

프로그래머스 sql

NginX

0개의 댓글