Building Real-Time APIs with API Gateway Response Streaming

스트리밍 시 중간 버퍼링 피하는 방법

🚀 무슨 일이 생겼나 — 응답 스트리밍 지원

• Amazon API Gateway(이하 API Gateway)가 2025년 11월 19일부로 REST API에 대해 “response streaming” 기능을 정식 지원하기 시작했다. (Amazon Web Services, Inc.)

• 즉, 백엔드가 스트리밍을 지원하면 — 예: AWS Lambda(Lambda proxy), HTTP 프록시, 사설(private) 통합 등 — API Gateway가 응답 본문을 생성되는 즉시 클라이언트로 “부분 전달(chunked)”할 수 있다. (Amazon Web Services, Inc.)

• 덕분에 다음 같은 이점이 생긴다:
• 최초 바이트 도달 시간(Time-to‑First‑Byte, TTFB) 단축 → 사용자 입장에서 “실시간 생산되는 데이터” 체감 향상. (Amazon Web Services, Inc.)
• 10 MB 페이로드 제한 해제, 대용량 데이터/미디어 스트리밍 가능. (AWS Documentation)
• 통합 타임아웃이 기존 29초 제한에서 최대 15분까지 연장 가능. (AWS Documentation)
• 실시간 진행 상태 피드백, SSE(Server‑Sent Events) 등 long‑polling/streaming 패턴을 REST API로 쉽게 구현 가능. (AWS Documentation)

⚠️ 다만 — 중간 프록시나 CDN 환경에서는 주의 필요

하지만 “스트리밍되게 했다”고 해서 항상 진짜 실시간으로 전달된다는 보장은 없다. 다음과 같은 caveat이 존재한다:

• 스트리밍 모드에서는 응답 변형(Content encoding / VTL 변환), 엔드포인트 캐싱 등은 지원되지 않는다. (AWS Documentation)

• 만약 API Gateway 뒤에서 CDN 또는 프록시(예: Cloudflare)를 거친다면, 이 중간 계층이 데이터의 청크(chunk)를 버퍼링(buffer)했다가 일정 조건(크기, 시간, 연결 종료 등)에서 한꺼번에 내보낼 수 있다. 실제로 SSE 구현에서 이런 이슈가 많이 보고된다. (GitHub)

• 예: Cloudflare를 거친 SSE endpoint는 “실시간 → 전송 지연 → 한꺼번에 flush” 같은 동작을 보인다는 커뮤니티 보고가 반복됨. (GitHub)

• 또한, 자동 HTTP 압축(compression) 설정이 활성화돼 있으면 스트리밍된 청크가 먼저 클라이언트로 가기 전에 압축 버퍼링이 끝날 때까지 기다리는 일이 발생할 수 있다. 실제로 일부 서비스에서는 “HTTP compression이 스트리밍을 깨뜨렸다”고 한다. (Mintlify)

💡 실무에서 내가 보는 시사점 — 너한테 특히 유용한 이유

너처럼 AI 모델을 호출해서 실시간으로 토큰 스트리밍하거나, 긴 처리 결과를 점진적으로 돌려주는 애플리케이션을 만든다면:

• API Gateway + Lambda + streaming 응답 조합만으로도 WebSocket 없이 구현 가능 — 구조 단순화.

• REST‑API 기반이라 기존 HTTP/HTTPS 도구들 그대로 사용 가능 (fetch, curl, Axios, React 같은 일반 HTTP 클라이언트들).

• 그러나 중간 계층(CDN, 프록시, 압축 설정 등)이 “실시간”을 망칠 수 있으므로, 운영 환경을 설계할 때는 버퍼링 비활성화, 압축 끄기, 캐시 비허용 등 스트리밍 친화 설정을 꼭 명시할 것.