API 게이트웨이 패턴(API Gateway) 완벽 정리

"모바일 앱에서 메인 화면을 띄우려면 회원 정보, 주문 목록, 추천 상품, 알림 개수 API를 각각 4번 호출해야 합니다. LTE 환경에서는 너무 느려요."

클라이언트가 수십 개의 마이크로서비스를 직접 호출하게 두면 보안, 인증, 네트워크 지연 등 헬게이트가 열립니다. 그래서 중간에 **관문(Gateway)**을 두어 요청을 통합하고 라우팅합니다.

하지만 이 관문을 "모든 클라이언트가 같이 쓸지", 아니면 **"클라이언트별로 따로 만들지"**가 아키텍처의 유연성을 결정합니다.

Shutterstock

 

 

---

1. 방식 1: 단일 중앙 게이트웨이 (Single Central Gateway) - "만능 해결사"

Netflix Zuul(과거)이나 Spring Cloud Gateway처럼 하나의 거대한 게이트웨이가 모든 클라이언트(Web, iOS, Android, IoT)의 요청을 처리하는 방식입니다.

특징

• 중앙 집중 관리: 인증(Auth), 로깅(Logging), 속도 제한(Rate Limiting), CORS 처리를 한곳에서 수행합니다.
• 단일 진입점: 클라이언트는 무조건 api.domain.com 하나만 바라보면 됩니다.

상황 (쇼핑몰)

• 웹 사용자든 모바일 사용자든 모두 /api/v1/products를 호출합니다.
• 게이트웨이는 이 요청을 받아 Product-Service로 토스합니다.

장단점

• 장점:
  • 구축 용이성: 게이트웨이 하나만 띄우면 되므로 인프라 관리가 쉽습니다.
  • 보안 일관성: 모든 트래픽이 한곳을 통하므로 보안 정책을 적용하기 좋습니다(횡단 관심사 처리).
• 단점:
  • 병목 현상(Bottleneck): 모든 트래픽이 몰리므로 게이트웨이가 죽으면 서비스 전체가 마비됩니다.
  • 팀 간 의존성: 모바일 팀이 "응답값에서 description 필드 빼주세요(데이터 절약)"라고 요청하면, 웹 팀은 "우린 필요한데요?"라고 반대합니다. 결국 게이트웨이 안에 지저분한 if (client == mobile) 로직이 쌓입니다.

---

2. 방식 2: BFF (Backend For Frontend) - "맞춤형 비서"

**"프론트엔드를 위한 백엔드"**라는 뜻으로, 클라이언트 종류별로 게이트웨이를 별도로 두는 방식입니다. 사운드클라우드(SoundCloud)가 처음 제안하여 유명해졌습니다.

특징

• 클라이언트별 특화: Web-BFF, Mobile-BFF, Public-API-BFF 등으로 나뉩니다.
• API 조합(Aggregation): 모바일 BFF는 한 번의 호출로 회원+주문+알림 정보를 묶어서(Aggregation) 내려주고, 불필요한 데이터는 쳐냅니다.

상황 (쇼핑몰)

• Mobile App: /mobile-api/dashboard 호출 -> Mobile-BFF가 받음 -> 필요한 데이터만 최소한으로 조합해서 JSON 응답.
• PC Web: /web-api/dashboard 호출 -> Web-BFF가 받음 -> 고해상도 이미지 URL과 상세 설명을 포함한 풍부한 JSON 응답.

장단점

• 장점:
  • 최적화: 각 클라이언트 환경에 딱 맞는 데이터 포맷을 제공하여 네트워크 비용을 줄입니다.
  • 자율성: 모바일 팀이 모바일 BFF를 직접 관리하면(Node.js 등으로), 백엔드 팀의 지원을 기다릴 필요 없이 API를 수정하고 배포할 수 있습니다.
• 단점:
  • 코드 중복: 회원 인증 로직 같은 공통 기능이 여러 BFF에 중복 구현될 수 있습니다.
  • 관리 포인트 증가: 관리해야 할 배포 단위(서버)가 늘어납니다.

---

3. 실무 비교: 언제 무엇을 쓰는가?

구분	Single Central Gateway	BFF (Backend For Frontend)
진입점 개수	1개 (Unified)	N개 (Web, App, IoT 등)
개발 주체	주로 백엔드/인프라 팀이 관리	주로 각 클라이언트(FE) 팀이 관리
응답 형태	모든 클라이언트에 동일한 응답 (범용성)	각 클라이언트에 최적화된 응답 (특수성)
사용 기술	Spring Cloud Gateway, Nginx, Kong	Node.js(Express), GraphQL, Kotlin
추천 상황	클라이언트 종류가 적거나(웹 only), 초기 단계	모바일/웹의 요구사항이 크게 다를 때, MSA 성숙기

결론

서비스 초기 단계이거나 클라이언트가 웹(Web) 하나뿐이라면 단일 게이트웨이로 시작하세요. 관리 비용이 가장 적게 듭니다.

하지만 서비스가 커져서 "모바일 앱이 너무 무거워요", "API 하나 고치는데 회의를 3번 해야 해요" 같은 소리가 나오기 시작하면, 즉시 BFF 패턴을 도입하여 프론트엔드 팀에게 API 구성의 자유를 줘야 할 때입니다. (최근에는 BFF 계층을 GraphQL로 구현하는 것이 트렌드입니다.)