API 게이트웨이란?

API 게이트웨이는 모든 요청을 라우팅하고 인증하며 속도를 제한하는 단일 진입점, 즉 API를 위한 관리형 정문입니다. 핵심은 중앙화입니다. 모든 엔드포인트에 필요한 횡단 관심사(호출자는 누구인가, 얼마나 빠르게 호출해도 되는가, 이 요청은 어디로 가는가, 무슨 일이 있었는가)가 N개의 서비스에서 빠져나와, 클라이언트가 우회할 수 없는 하나의 정책 계층으로 모입니다.

핵심 요약

정문이 하는 일

게이트웨이의 업무 목록을 N개의 미들웨어 복사본이 아니라 설정으로 표현한, 전형적인 선언형 라우트입니다:

# 게이트웨이 라우트: 단일 진입점, 정책 부착
route: /orders/**
  service: orders-api:8080          # 라우팅 — 토폴로지는 비공개로 유지
  auth: bearer-jwt                  # 입구에서 인증
  rate_limit: 100/min per key       # 백엔드에 닿기 전에 사용량 한도
  transform:
    strip_headers: [X-Internal-*]   # 엣지와 내부 사이의 변환
  timeout: 5s
  observe: log + trace + metrics    # 모든 것을 한곳에서 관측

클라이언트 쪽에서 보면 관리형 게이트웨이는 SDK 속으로 사라집니다. 호출은 한 번이고, 사용자의 코드가 실행되기 전에 정문의 검사가 적용됩니다:

// JavaScript / Node.js — Back4app JS SDK
// One managed entry point: auth, rate limits, and routing applied per call
const receipt = await Parse.Cloud.run('placeOrder', { cartId: 'crt_812' });
// The platform's gateway verified the session, applied limits,
// and routed to the function — none of it in your code.
console.log(`Order ${receipt.orderId} confirmed`);

// Flutter / Dart — Back4app Flutter SDK
// One managed entry point: auth, rate limits, and routing applied per call
final function = ParseCloudFunction('placeOrder');
final response = await function.execute(parameters: {'cartId': 'crt_812'});
if (response.success) {
  print('Order ${response.result['orderId']} confirmed');
}

// iOS / Swift — Back4app Swift SDK
// One managed entry point: auth, rate limits, and routing applied per call
ParseCloud.callFunction("placeOrder",
                        parameters: ["cartId": "crt_812"]) { result in
  if case .success(let receipt) = result {
    print("Order confirmed: \(receipt)")
  }
}

// Android / Kotlin — Back4app Android SDK
// One managed entry point: auth, rate limits, and routing applied per call
val params = hashMapOf("cartId" to "crt_812")
ParseCloud.callFunctionInBackground<Map<String, Any>>("placeOrder", params) { receipt, e ->
  if (e == null) Log.d("Orders", "Order ${receipt["orderId"]} confirmed")
}

닮은꼴 넷, 하나씩 구분하기

정석적인 패턴 설명은 알아 둘 만한 변형을 하나 덧붙입니다. 바로 Backend-for-Frontend(BFF)입니다. 클라이언트 유형마다 얇은 게이트웨이를 하나씩 두고 각자가 자신의 클라이언트에 맞게 응답을 가공하는 방식으로, 배포 단위가 늘어나는 대신 누구에게도 맞지 않는 획일적인 API에서 벗어납니다.

단점을 있는 그대로

게이트웨이는 통제권을 한곳에 모으고, 중앙화는 네 가지 방식으로 비용을 청구합니다. 단일 장애점: 모든 것이 게이트웨이를 거쳐 흐릅니다. 로드 밸런서 뒤에서 클러스터로 운영하거나, 게이트웨이의 장애가 곧 전체 장애임을 받아들여야 합니다. 새로운 병목: 모든 기능 팀이 이제 하나의 공유 구성 요소에 설정 변경을 요청합니다. 거버넌스와 셀프 서비스 도구는 부가 요소가 아니라 도입의 일부입니다. 되살아난 모놀리스: 게이트웨이에 쌓여 가는 집계 로직은 애써 분해한 중앙집중형 앱을 조용히 다시 만듭니다. 정책은 두껍게, 로직은 얇게 유지해야 합니다. 설정 난립: 라우트마다 정책이 붙은 수백 개의 라우트는 그 자체로 코드베이스이므로, 코드베이스처럼 리뷰해야 합니다. 이 중 어느 것도 게이트웨이에 반대하는 논거는 아닙니다. 모두 가볍게 도입한 게이트웨이에 반대하는 논거입니다.

일반적인 사용 사례

• 마이크로서비스의 정문 – 게이트웨이의 출발점입니다. 서비스는 많고 API는 일관된 하나이며, 그 뒤의 토폴로지는 자유롭게 진화합니다.
• 멀티 클라이언트 제품 – 인증, 응답 형태, 제한이 서로 다른 웹, 모바일, 파트너. BFF의 본거지입니다.
• API 수익화 – 키, 요금제, 할당량, 사용량 측정을 한 지점에서 강제합니다.
• 마이그레이션 – 스트랭글러 패턴입니다. 게이트웨이가 기존 경로는 레거시 시스템으로, 새 경로는 대체 시스템으로 보이지 않게 라우팅합니다.
• 엣지 정책 – CORS, TLS, 헤더 정리, 속도 제한을 N번이 아니라 한 번만 적용합니다.

게이트웨이가 필요할까? 결정 매트릭스

대부분의 비교 페이지가 말하지 않는 답이 있습니다. 아직은 아니다도 정당한 아키텍처입니다. 정문은 그 뒤에 건물이 생겼을 때 다는 것입니다.

한계와 트레이드오프

• 가용성은 이제 게이트웨이의 가용성입니다. 클러스터로 구성하고, 헬스 체크를 걸고, 장애를 리허설해야 합니다. 이 완화책은 표준이며 선택 사항이 아닙니다.
• 홉 하나만큼의 지연 시간은 정직하게 상계해야 합니다. 그것이 없애 주는 왕복과 중복된 미들웨어와 비교해야 하며, 어느 쪽으로도 가정하지 말고 측정해야 합니다.
• 집계는 미끄러운 비탈입니다. 응답을 조합하는 것은 정당하지만, 게이트웨이 안의 비즈니스 로직은 이름만 바꾼 ESB 패턴입니다.
• 오픈소스 선택지에는 운영이 따라옵니다. 훌륭한 게이트웨이가 오픈소스로 존재하지만(Envoy 기반 스택과 그 경쟁 제품들), 각각은 사용자가 직접 운영하고 업그레이드하고 보호해야 하는 분산 시스템입니다.
• 관리형 게이트웨이는 통제력을 내주고 운영 부담을 덜어 냅니다. 플랫폼이 운영하는 정문은 게이트웨이 운영이 차별화되지 않는 고된 일일 때 정확히 맞는 답입니다.

Back4app에서의 API 게이트웨이

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 게이트웨이 계층은 플랫폼에 포함되어 있습니다. 위의 코드 탭에서처럼 REST, GraphQL, SDK, Cloud Code 호출 등 모든 요청은 관리형 엣지를 통해 들어오며, 이 엣지가 세션과 키를 인증하고, 앱별 속도 제한을 적용하고, 생성된 API나 사용자의 함수로 라우팅합니다. 정문을 안전하게 만드는 클러스터링과 확장은 플랫폼이 운영합니다. 결정 매트릭스는 단순해집니다. 첫날부터 게이트웨이의 보장을 얻고, 정문을 직접 소유하는 일은 아예 건너뜁니다.