API Gateway Pattern
🧭 배달의민족은 왜 API 게이트웨이를 만들었을까?
우아한형제들 서버 개발자 권용근님의 우아콘 발표 “배달의민족 API 게이트웨이는 왜 필요했을까”를 기반으로, API 게이트웨이 도입 배경과 설계 과정, 운영 전략을 실무적인 시각에서 리뷰합니다.
👋 도메인부터 게이트웨이까지, 개발 여정
권용근님은 결제 → 주문 → 전시 → 회원 → API 게이트웨이로 개발 영역을 확장해오며, MSA의 겉과 속을 모두 경험했습니다. 각 영역에서 발생하는 도메인 분리, 비즈니스 의존성, 공통 관심사 문제를 직접 겪은 경험은 이번 게이트웨이 설계의 초석이 되었습니다.
📌 API 게이트웨이는 무엇인가?
API (Application Programming Interface): 시스템 간 통신을 위한 인터페이스.
게이트웨이 (Gateway): 네트워크 트래픽을 제어하는 진입점.
두 용어를 합친 API 게이트웨이는 결국 클라이언트 요청을 받아 적절한 서비스로 전달하며, 공통 관심사를 처리하는 중간자 역할을 수행합니다.
넷플릭스 Zuul, AWS API Gateway, Kong, Spring Cloud Gateway 등 다양한 솔루션이 이를 실현하고 있지만, 정형화된 정의는 없었습니다. GPT에 물어봐도 “AWS 출시 이후 대중화됐다” 정도로만 알려져 있죠. 결국 실제로 무엇을 하는지가 핵심입니다.
🧩 API 게이트웨이의 두 축
라우팅 (Routing)
클라이언트 요청을 적절한 내부 서비스로 연결합니다.2. 횡단 관심사 처리 (Cross-Cutting Concerns)
인증, 보안, 로깅, 탄력성, 모니터링 등 모든 서비스가 공유해야 하는 로직을 게이트웨이 한 곳에서 처리합니다.API 게이트웨이는 클라이언트와 API를 제공하는 서버 사이에서 클라이언트 요청을 적절한 서비스로 라우팅하고, 인증, 보안, 모니터링, 탄력성과 같은 횡단 관심사를 중앙에서 일관되게 처리한다.
🔍 왜 배민은 API 게이트웨이를 필요로 했나?
배달의민족은 MSA 전환 이후, 다음과 같은 문제가 현실이 되었습니다:
도메인 분산: '마이배민' 화면은 쿠폰, 포인트, 회원, 선물, 페이 등 다양한 마이크로서비스의 조합으로 만들어짐.
클라이언트-도메인 직접 연결의 문제:
확장성 저하 (변경에 민감)
과도한 정보 노출
클라이언트에 비즈니스 정책 노출 위험
이러한 문제를 해결하기 위해 '중간자'가 필요했고, 프론트 서버(API Gateway Pattern) 개념이 도입되었습니다.
🧱 프론트 서버와 API 게이트웨이의 차이
프론트 서버 (API Gateway Pattern):
클라이언트 맞춤형 API를 제공. 도메인 간 데이터를 조합해 화면 정책을 클라이언트 대신 처리.
API 게이트웨이 (Tool):
비즈니스와 무관한 공통 관심사만 처리. 인증, 보안, 트래픽 제어 등.
🚨 프론트 서버는 API 게이트웨이가 아니다!
서로 역할이 다르며, 게이트웨이는 프론트 서버의 조합과 연결될 때 그 의미를 가진다.
MSA에서 도메인들이 분할되면서 발생하는 문제 때문에 API Gateway가 필요한 것은 아니다.
🏛 조직 구조와 시스템 설계: 콘웨이의 법칙
“조직의 커뮤니케이션 구조가 시스템 구조를 결정한다.”
프론트 서버도 도메인처럼 분화된다.
주문 지면→ 주문 조직로그인 화면→ 회원 조직가게 목록→ 여러 도메인 조합 → 별도 조직 필요
조직이 분화되면 시스템도 분화되고, 프론트 서버도 늘어난다.
🔄 프론트 서버의 한계: 횡단 관심사 문제
인증, 모니터링, 보안 등을 모든 프론트 서버에서 개별 구현?
시스템 수가 늘수록 유지보수 비용 기하급수적으로 증가.
정책 변경 시 N개의 서비스에 반영 필요 → 현실적으로 불가능.
MSA가 커질수록 반드시 횡단 관심사를 공통 처리해야 함 → 여기서 API 게이트웨이가 필요해짐.
🎯 API 게이트웨이의 역할 정리
프론트 서버: 클라이언트 전담, 비즈니스 로직 처리
API 게이트웨이: 프론트 서버를 포함한 모든 서비스에 적용되는 공통 로직 처리
✅ API 게이트웨이는 프론트 서버 위에 존재하는 인프라 구성 요소입니다.
🙅 API 게이트웨이 ≠ 프론트 서버
“API 게이트웨이를 프론트 서버로 쓰고 싶어요!”
→ NO! 비즈니스 처리를 포함할 수 없으며, API 게이트웨이의 역할을 왜곡하게 됩니다.
API 게이트웨이는 ‘비즈니스 무관한’ 레이어입니다.
API Gateway Pattern에서 다루는 문제는 Gateway Tool이 처리할 수 없습니다.
API Gateway Pattern은 클라이언트의 요구사항을 해결해주는데 초점이 맞춰져 있습니다.
API Gateway는 비즈니스에 무관한 서버들의 횡단 관심사를 해결하는데 초점이 맞춰져 있습니다.
🏗 배달의민족 API 게이트웨이 구조
구성
클라이언트 ↔ API Gateway ↔ 프론트 서버 ↔ 도메인 서비스
Spring Cloud Gateway 기반
멀티 테넌시 운영 (서비스 영향도 기반으로 클러스터 분리. SPOF 예방)
MSA로 라우팅하면서, 요청에 맞는 설정을 적용
스케일 아웃 가능한 인프라 구조
확장 전략
DNS 기반 장애 복구
테스트 서버, 임직원 전용 경로 분기 가능
🧪 인증: 가장 강력한 횡단 관심사
JWT + Passport 개념
JWT는 클라이언트 서명 확인으로 인증 무결성 확보
Passport는 Gateway에서 인증된 사용자 정보를 프론트 서버에 전달
문제 해결
Key 교체/알고리즘 변경 시 빠른 대응
인증 서버 장애 시에도 JWT 기반 최소한의 인증 제공 가능
🚦 라우팅: 유연성과 실험을 동시에
호스트 기반 라우팅 + 필터 체인
활용 예시
특정 IP 대역은 테스트 환경으로 보냄
특정 유저 토큰 → 실험적 백엔드 연결
카나리 릴리스, 점진적 전환 가능
🔐 보안: 어뷰징 방어의 최전선
API Gateway가 1차 방어선 역할 수행
요청 이상 패턴, IP 차단 등 실시간 감지 및 차단
각 프론트 서버에서 중복 방어할 필요 없음
🌊 흐름 제어(탄력성): 장애에 강한 시스템
Rate Limiting
Circuit Breaker
계속 실패하는 서비스에 대한 호출을 잠깐 끊어버리는 안전장치
“결제 서비스 다운” → 계속 호출되지 않도록 끊어버림
Retry / Static Fallback
게이트웨이 수준에서 빠르게 응답 가능
Static Fallback: 호출 실패시, 미리 준비해둔 응답을 대신 내려주는 전략
🧠 교훈과 인사이트
API 게이트웨이 도입은 필연이 아니라 결과
→ MSA에서 발생하는 구조적 문제를 풀다 보면 자연스럽게 등장
게이트웨이와 패턴을 구분하라
→ 프론트 서버와 게이트웨이는 역할이 다르며, 혼용은 시스템 실패의 지름길
공통 로직을 단일 지점에서 처리하라
→ 유지보수 효율 + 장애 대응력 + 테스트 유연성 확보
Last updated