서비스가 커지면서 인증 코드가 모든 백엔드에 복붙되고, 어떤 서비스는 요청 제한이 없어 한 클라이언트의 폭주에 통째로 다운됐습니다. 결제사 웹훅은 검증 없이 받다가 위조 요청에 당했습니다. 백엔드마다 같은 일(인증·제한·로깅)을 제각각, 어떤 곳은 빠뜨린 채 구현한 탓입니다. 모든 요청이 지나는 관문 하나에서 공통 처리하면 이 중복과 누락이 사라집니다.
- 1API 게이트웨이가 횡단 관심사를 중앙 처리하는 이유를 안다
- 2요청 제한(throttling)이 과부하·비용·남용을 막는 원리를 안다
- 3동기 API와 비동기 메시징의 사용 경계를 구분할 수 있다
- 4웹훅 수신 시 서명 검증과 멱등 처리의 필요성을 안다
- 5게이트웨이가 인증·캐싱·라우팅을 어떻게 위임받는지 이해한다
모든 요청이 지나는 한 곳
API 게이트웨이 — 횡단 관심사를 관문에서
인증, 요청 제한, 라우팅, 캐싱, 로깅/지표는 거의 모든 API가 공통으로 필요로 합니다. 이를 각 백엔드가 따로 구현하면 중복되고, 한 곳이라도 빠뜨리면 사고가 납니다.
API 게이트웨이는 모든 클라이언트 요청이 거치는 단일 관문에서 이 횡단 관심사를 중앙 처리합니다. 백엔드는 비즈니스 로직에만 집중하고, 클라이언트는 단일 진입점을 갖습니다. MSA(모놀리식 vs 마이크로서비스)에서 특히 중요한 패턴입니다.
요청 제한(throttling) — 폭주로부터 백엔드를 지킨다
한 클라이언트의 폭주나 공격이 백엔드를 마비시키지 않도록, 게이트웨이는 단위 시간당 요청 수를 제한합니다. 초과분은 429 Too Many Requests로 거절하고 정상 사용자를 보호합니다.
서버리스(서버리스(Lambda))처럼 호출당 과금되는 백엔드에서는 요청 제한이 비용 방어이기도 합니다 — 무한 호출로 청구서가 폭증하는 것을 막습니다(클라우드 비용 최적화). 정상 트래픽과 남용을 가르는 임계값 설정이 핵심입니다.
동기(게이트웨이) vs 비동기(큐) — 경계를 가른다
- 동기 — API 게이트웨이: 사용자가 결과를 즉시 기다리는 요청(로그인·조회·결제 승인). 받아서 응답을 돌려줌.
- 비동기 — 메시지 큐: 결과를 당장 안 기다려도 되는 후속(알림·집계·정산). 큐로 흘려 백엔드가 자기 속도로(메시지 큐와 이벤트).
흔한 패턴: 게이트웨이가 요청을 받아 즉시 응답하고, 무거운 후속 작업은 큐에 넣어 비동기로 처리합니다. "모든 걸 동기로"는 느리고 취약하고, "모든 걸 비동기로"는 즉시성이 필요한 곳에서 어색합니다.
웹훅 수신 — 검증과 멱등이 필수
웹훅은 외부 시스템(결제사·깃허브 등)이 우리 엔드포인트로 보내는 이벤트 알림입니다. 공개 엔드포인트라 누구나 위조 요청을 보낼 수 있으므로:
- 서명 검증: 발신자가 준 시크릿(시크릿·키 관리)으로 만든 서명을 확인해 진짜인지 검증
- 멱등 처리: 외부는 보통 재시도하므로 같은 이벤트가 중복 도착 → 두 번 처리해도 결과가 같게(메시지 큐와 이벤트의 멱등성)
검증 없는 웹훅 수신은 위조·재생 공격에 그대로 노출됩니다.
스테이지의 throttling 설정(초당 한도·버스트)을 확인합니다. 없으면 폭주에 무방비입니다.
aws apigateway get-stage --rest-api-id "$API_ID" --stage-name prod \
--query "{RateLimit:methodSettings.*.throttlingRateLimit,Burst:methodSettings.*.throttlingBurstLimit}"
{ "RateLimit": [1000.0], "Burst": [2000] }
aws apigateway get-stage게이트웨이의 4XX(클라이언트 오류)·5XX(백엔드 오류)·지연을 봅니다. 429가 잦으면 한도나 클라이언트 폭주를 점검합니다.
aws cloudwatch get-metric-statistics --namespace AWS/ApiGateway \
--metric-name 4XXError --dimensions Name=ApiName,Value=my-api \
--start-time 2026-06-16T00:00:00Z --end-time 2026-06-16T01:00:00Z \
--period 3600 --statistics Sum --query "Datapoints[0].Sum"
142.0 # 1시간 4XX 142건 — 429(throttle)인지 인증실패(401/403)인지 분해 필요
aws cloudwatch get-metric-statistics- 스테이지에 throttling 설정이 없거나 과도하게 높음 — 폭주·비용 폭증에 무방비. 정상 트래픽 기준으로 한도·버스트 설정
- 4XX 중 429 비중 — 높으면 한도가 빡빡하거나 특정 클라이언트 폭주. 401/403이면 인증·권한 문제(용어사전)
- 5XX 발생 — 게이트웨이가 아니라 뒷단 백엔드 오류·타임아웃. 502/504 구분해 백엔드 상태 점검
- 웹훅 엔드포인트에 서명 검증·멱등 처리가 있는지 — 없으면 위조·중복 처리 위험. 코드·게이트웨이 권한정책 점검
상황: 게이트웨이는 받는데 뒷단(서버리스/백엔드)이 한계에 부딪힘.
원인: ① 게이트웨이 요청 제한은 없는데 뒷단 동시성 한도에 먼저 도달, ② 서버리스 동시성 폭증으로 DB 커넥션 고갈(서버리스(Lambda)의 커넥션 폭주), ③ 무거운 동기 처리를 게이트웨이 뒤에서 다 하려다 지연 누적.
진단: 게이트웨이 429 vs 백엔드 throttle/에러 분리 → 뒷단 동시성·DB 커넥션 지표 확인 → 동기로 처리 중인 무거운 작업이 있는지 점검.
해결: 게이트웨이에 요청 제한을 둬 뒷단 도달 전에 완충, 뒷단 동시성·커넥션 풀(RDS Proxy 등) 조정, 즉시 응답이 불필요한 무거운 작업은 큐로 비동기화(메시지 큐와 이벤트). "게이트웨이로 받아 즉시 응답 + 후속은 큐"가 스파이크를 견디는 표준 구조입니다.
API 게이트웨이는 클라우드 API 운영의 표준 구성요소입니다. "외부에 API를 어떻게 안전하게 공개하나요?"에 "게이트웨이에서 인증·요청 제한·CORS를 중앙 처리하고, 웹훅은 서명 검증·멱등, 무거운 후속은 큐로 비동기"라 답하면 탄탄합니다.
PM 관점에서도 연동 요구사항을 게이트웨이 기준으로 적으면 사고를 줄입니다 — "초당 N건 제한", "허용 출처(CORS)", "웹훅 서명 검증", "Idempotency-Key"를 인수 기준에 넣습니다(용어사전). 이 모듈은 동기 API(모놀리식 vs 마이크로서비스의 API 계약)와 비동기 메시징(메시지 큐와 이벤트)을 잇는 경계에 서 있어, 둘을 함께 이해할 때 시스템 전체 그림이 완성됩니다.
다음으로는 이 게이트웨이·서버리스·큐가 코드로 선언되고(IaC와 Terraform) 관측·통제되는(관측과 거버넌스) 큰 그림을 Well-Architected 6대 기둥으로 점검해 보세요.