> For the complete documentation index, see [llms.txt](https://wonjoon.gitbook.io/joons-til/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wonjoon.gitbook.io/joons-til/techtalk-review/woowacon/2024/api-gateway-pattern.md).

# API Gateway Pattern

## 🧭 배달의민족은 왜 API 게이트웨이를 만들었을까?

우아한형제들 서버 개발자 권용근님의 우아콘 발표 “배달의민족 API 게이트웨이는 왜 필요했을까”를 기반으로, API 게이트웨이 도입 배경과 설계 과정, 운영 전략을 실무적인 시각에서 리뷰합니다.

***

### 👋 도메인부터 게이트웨이까지, 개발 여정

권용근님은 결제 → 주문 → 전시 → 회원 → API 게이트웨이로 개발 영역을 확장해오며, MSA의 겉과 속을 모두 경험했습니다. 각 영역에서 발생하는 **도메인 분리, 비즈니스 의존성, 공통 관심사 문제**를 직접 겪은 경험은 이번 게이트웨이 설계의 초석이 되었습니다.

***

### 📌 API 게이트웨이는 무엇인가?

![Image](https://github.com/user-attachments/assets/07a9228d-a948-4853-b487-c3964a4fdf57)

* **API (Application Programming Interface)**: 시스템 간 통신을 위한 인터페이스.
* **게이트웨이 (Gateway)**: 네트워크 트래픽을 제어하는 진입점.
* 두 용어를 합친 **API 게이트웨이**는 결국 **클라이언트 요청을 받아 적절한 서비스로 전달하며, 공통 관심사를 처리하는 중간자** 역할을 수행합니다.

넷플릭스 Zuul, AWS API Gateway, Kong, Spring Cloud Gateway 등 다양한 솔루션이 이를 실현하고 있지만, 정형화된 정의는 없었습니다. GPT에 물어봐도 “AWS 출시 이후 대중화됐다” 정도로만 알려져 있죠. 결국 **실제로 무엇을 하는지가 핵심**입니다.

***

### 🧩 API 게이트웨이의 두 축

1. **라우팅 (Routing)**

![Image](https://github.com/user-attachments/assets/9bdf7f01-2891-440f-8ac6-c974169f1033)

```
클라이언트 요청을 적절한 내부 서비스로 연결합니다.
```

2\. **횡단 관심사 처리 (Cross-Cutting Concerns)**

![Image](https://github.com/user-attachments/assets/28568935-7443-4e43-b9bb-0b6647d4e476)

```
인증, 보안, 로깅, 탄력성, 모니터링 등 모든 서비스가 공유해야 하는 로직을 게이트웨이 한 곳에서 처리합니다.
```

API 게이트웨이는 클라이언트와 API를 제공하는 서버 사이에서 클라이언트 요청을 적절한 서비스로 라우팅하고, 인증, 보안, 모니터링, 탄력성과 같은 횡단 관심사를 중앙에서 일관되게 처리한다.

***

### 🔍 왜 배민은 API 게이트웨이를 필요로 했나?

배달의민족은 MSA 전환 이후, 다음과 같은 문제가 현실이 되었습니다:

* **도메인 분산**: '마이배민' 화면은 쿠폰, 포인트, 회원, 선물, 페이 등 다양한 마이크로서비스의 조합으로 만들어짐.
* **클라이언트-도메인 직접 연결의 문제**:
  * 확장성 저하 (변경에 민감)
  * 과도한 정보 노출
  * 클라이언트에 비즈니스 정책 노출 위험

이러한 문제를 해결하기 위해 '중간자'가 필요했고, **프론트 서버(API Gateway Pattern)** 개념이 도입되었습니다.

***

### 🧱 프론트 서버와 API 게이트웨이의 차이

* **프론트 서버 (API Gateway Pattern)**:

  클라이언트 맞춤형 API를 제공. 도메인 간 데이터를 조합해 화면 정책을 클라이언트 대신 처리.
* **API 게이트웨이 (Tool)**:

  비즈니스와 무관한 공통 관심사만 처리. 인증, 보안, 트래픽 제어 등.

🚨 프론트 서버는 API 게이트웨이가 아니다!

서로 역할이 다르며, **게이트웨이는 프론트 서버의 조합과 연결될 때 그 의미를 가진다.**

MSA에서 도메인들이 분할되면서 발생하는 문제 때문에 API Gateway가 필요한 것은 아니다.

***

### 🏛 조직 구조와 시스템 설계: 콘웨이의 법칙

“조직의 커뮤니케이션 구조가 시스템 구조를 결정한다.”

* 프론트 서버도 도메인처럼 분화된다.
  * `주문 지면` → 주문 조직
  * `로그인 화면` → 회원 조직
  * `가게 목록` → 여러 도메인 조합 → 별도 조직 필요
* **조직이 분화되면 시스템도 분화되고, 프론트 서버도 늘어난다.**

***

### 🔄 프론트 서버의 한계: 횡단 관심사 문제

![Image](https://github.com/user-attachments/assets/2b4d4d36-e950-4290-9007-b7f7e6f4177e)

* **인증, 모니터링, 보안** 등을 모든 프론트 서버에서 개별 구현?
  * 시스템 수가 늘수록 유지보수 비용 기하급수적으로 증가.
  * 정책 변경 시 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 기반 장애 복구
  * 테스트 서버, 임직원 전용 경로 분기 가능

***

### 🧪 인증: 가장 강력한 횡단 관심사

![Image](https://github.com/user-attachments/assets/4cc8472f-546c-4e37-8fb3-d995102e804f)

* **JWT + Passport 개념**
  * JWT는 클라이언트 서명 확인으로 인증 무결성 확보
  * Passport는 Gateway에서 인증된 사용자 정보를 프론트 서버에 전달
* **문제 해결**
  * Key 교체/알고리즘 변경 시 빠른 대응
  * 인증 서버 장애 시에도 JWT 기반 최소한의 인증 제공 가능

![Image](https://github.com/user-attachments/assets/45067e51-d734-4f35-89ee-b0405cdc8e1d)

***

### 🚦 라우팅: 유연성과 실험을 동시에

![Image](https://github.com/user-attachments/assets/cea78f34-0e6d-43f2-86f5-852af7eee14f)

* **호스트 기반 라우팅 + 필터 체인**
* **활용 예시**
  * 특정 IP 대역은 테스트 환경으로 보냄
  * 특정 유저 토큰 → 실험적 백엔드 연결
  * 카나리 릴리스, 점진적 전환 가능

***

### 🔐 보안: 어뷰징 방어의 최전선

![Image](https://github.com/user-attachments/assets/9326e6f6-3cc2-44a7-8c98-310735d3e57b)

* API Gateway가 **1차 방어선** 역할 수행
* 요청 이상 패턴, IP 차단 등 실시간 감지 및 차단
* 각 프론트 서버에서 중복 방어할 필요 없음

***

### 🌊 흐름 제어(탄력성): 장애에 강한 시스템

![Image](https://github.com/user-attachments/assets/1abf49ed-bc0f-4630-ad7c-c106c398f3d5)

* **Rate Limiting**

![Image](https://github.com/user-attachments/assets/d9ae3ae3-11a3-422e-9097-c3f392ac2811)

* **Circuit Breaker**
  * 계속 실패하는 서비스에 대한 호출을 잠깐 끊어버리는 안전장치
  * “결제 서비스 다운” → 계속 호출되지 않도록 끊어버림
* **Retry / Static Fallback**
  * 게이트웨이 수준에서 빠르게 응답 가능
  * Static Fallback: 호출 실패시, 미리 준비해둔 응답을 대신 내려주는 전략

***

### 🧠 교훈과 인사이트

![Image](https://github.com/user-attachments/assets/13e78e91-4f12-4bb2-b197-4e56887718cf)

* **API 게이트웨이 도입은 필연이 아니라 결과**

  → MSA에서 발생하는 구조적 문제를 풀다 보면 자연스럽게 등장
* **게이트웨이와 패턴을 구분하라**

  → 프론트 서버와 게이트웨이는 역할이 다르며, 혼용은 시스템 실패의 지름길
* **공통 로직을 단일 지점에서 처리하라**

  → 유지보수 효율 + 장애 대응력 + 테스트 유연성 확보