AI 게이트웨이는 왜 버퍼링을 꺼야 하는가 — 스트리밍 응답의 내부

ChatGPT의 응답은 한 글자씩 타이핑되듯 도착한다. 이 글은 그 화면 뒤에서 게이트웨이가 무엇을 하고 있는지, 그리고 AI 트래픽을 다룰 때 왜 “버퍼링을 끄는” 판단이 필요한지에 집중한다.

LLM 애플리케이션을 운영하다 보면 LiteLLM 같은 게이트웨이 뒤에 Envoy Gateway 같은 프록시를 두게 된다. 그런데 일반 REST API를 다룰 때는 신경 쓰지 않던 문제가 하나 튀어나온다. 응답이 한 번에 오지 않고, 조금씩 흘러 들어온다. ChatGPT처럼 토큰이 하나씩 화면에 찍히는 그 경험을, 내 인프라에서도 똑같이 재현하려면 게이트웨이가 그 흐름을 방해하지 않아야 한다.

이 글은 그 “흐름”의 정체 — Streamable HTTP — 를 뜯어보고, 버퍼링을 켜고 끄는 선택이 사용자 경험과 메모리 사이의 트레이드오프라는 점을 정리한다.

스트리밍 응답의 정체 — Streamable HTTP

“응답이 조금씩 도착한다”는 건 마법이 아니다. HTTP가 원래 지원하는 기능이고, 다만 HTTP 버전에 따라 구현 방식이 다르다.

HTTP/1.1 — Chunked Transfer Encoding. 서버가 응답 전체 크기를 미리 알 수 없을 때(스트리밍이 정확히 이 경우다) Content-Length 대신 Transfer-Encoding: chunked를 쓴다. 응답을 여러 청크로 쪼개서, 준비되는 대로 하나씩 내보낸다. 각 청크 앞에는 그 청크의 크기가 붙고, 크기 0인 청크가 오면 응답이 끝난다.

HTTP/2 — DATA Frame. HTTP/2는 “청크”라는 개념 자체를 쓰지 않는다. 프로토콜이 처음부터 프레임(frame) 기반으로 설계됐기 때문이다. 응답 본문은 여러 개의 DATA 프레임으로 나뉘어 연속으로 전송된다. 청크 인코딩이라는 별도 장치 없이, 프로토콜 계층에서 자연스럽게 스트리밍이 이뤄진다.

겉으로 보면 둘 다 똑같은 “스트리밍 응답”이다. 개발자 입장에서 알아야 할 핵심은 딱 하나다 — 응답이 완성되기를 기다리지 않고, 도착하는 대로 흘려보낸다. 어떤 버전을 쓰든 이 개념은 같고, 실제 인코딩 차이는 대부분 라이브러리와 프록시가 알아서 처리한다.

여기에 애플리케이션 레이어 규약인 SSE(Server-Sent Events) 가 얹힌다. Content-Type: text/event-stream으로 선언하고 data: 라인을 하나씩 내보내는 방식으로, OpenAI를 비롯한 대부분의 LLM API가 토큰 스트리밍에 SSE를 쓴다. SSE 역시 그 밑에서는 위의 chunked 또는 DATA frame 위에서 동작한다.

그래서 게이트웨이가 문제가 된다

서버가 아무리 토큰을 하나씩 잘 내보내도, 그 사이에 낀 게이트웨이가 응답을 다 모았다가 한꺼번에 넘기면 스트리밍은 무의미해진다. 사용자 화면에는 몇 초간 아무것도 안 보이다가 완성된 답변이 통째로 툭 떨어진다. 서버는 스트리밍했는데 프록시가 버퍼링해서 경험을 망치는, 흔한 실패다.

그래서 AI 스트리밍 라우트에서는 게이트웨이가 버퍼링 없이 즉시 전달(pass-through) 하는 스트리밍 프록시로 동작해야 한다. 받은 데이터를 쌓지 않고 곧바로 클라이언트로 흘려보내는 구조다.

”그럼 버퍼링은 무조건 나쁜가?” — 아니다

여기서 반문이 나온다. 버퍼링이 없는 게 항상 좋은 거라면 왜 존재하는가?

일반 웹 서비스에서는 오히려 버퍼링이 도움이 되는 경우가 많다. 응답 크기가 어느 정도 정해져 있고 한 번에 보내도 되는 REST API라면, 게이트웨이가 응답을 모아서 한 번에 내보내는 편이 유리할 수 있다. 느린 클라이언트가 데이터를 천천히 읽는 동안 백엔드 연결을 빨리 놓아줄 수 있고(백엔드 커넥션을 오래 붙잡지 않는다), 작은 조각들을 모아 전송 효율을 높일 수도 있다.

핵심은 워크로드에 따라 다르다는 것이다.

즉 게이트웨이를 전역으로 “버퍼링 ON/OFF” 하는 게 아니라, 라우트 단위로 AI 스트리밍 경로만 버퍼링을 끄는 식으로 운영하는 게 일반적이다.

버퍼링의 진짜 비용 — 메모리

버퍼링을 켜는 데는 눈에 잘 안 보이는 대가가 있다. 메모리다.

버퍼링은 본질적으로 “응답을 게이트웨이 메모리에 잠깐 쌓아두는” 동작이다. 동시 접속 세션이 늘어나면 이 메모리는 대략 세션 수 × 세션당 버퍼 크기로 곱해진다. LLM 응답처럼 길고, 느리게 생성되고, 수천 명이 동시에 붙는 트래픽에서 응답을 통째로 버퍼링하겠다는 건 현실적이지 않다.

이것이 대규모 AI 서비스에서 게이트웨이가 거의 예외 없이 스트리밍 프록시 방식으로 동작하는 이유다. 받은 데이터를 곧바로 흘려보내면 게이트웨이는 응답 전체를 들고 있을 필요가 없다. 버퍼를 최소화하고 즉시 전달하는 구조는 UX만을 위한 게 아니라, 메모리 관점에서도 사실상 유일하게 지속 가능한 선택이다.

정리하면 AI 스트리밍에서 버퍼링을 끄는 건 두 가지를 동시에 얻는다 — 사용자 경험(토큰이 즉시 보인다)과 자원 효율(메모리가 세션 수만큼 폭발하지 않는다).

무엇으로 구현하는가 — Envoy Gateway vs APISIX

AI 게이트웨이 앞단 프록시를 고를 때 자주 비교되는 두 오픈소스가 Envoy Gateway와 Apache APISIX다.

Envoy Gateway — Envoy Proxy를 Gateway API 표준으로 다루기 쉽게 감싼 CNCF 프로젝트다. Envoy 자체가 스트리밍 프록시로 설계돼 있어 HTTP/2, gRPC, SSE를 자연스럽게 처리한다.

Apache APISIX — Apache 재단 오픈소스 API 게이트웨이로, 플러그인 생태계가 넓고 동적 설정에 강하다.

둘 다 오픈소스라 라이선스 비용 없이 시작할 수 있고, JWT 인증, mTLS, rate limiting, SSE, HTTP/2, gRPC 등 AI 플랫폼에 필요한 기능을 공통으로 지원한다. “무료냐”는 질문의 답은 — 소프트웨어 자체는 무료다. 다만 Kubernetes(AKS 등) 위에서 운영하면 노드 비용, 로드밸런서 비용, 운영 비용은 당연히 발생한다. 반면 상용 API 게이트웨이 제품은 별도의 라이선스 정책을 따른다.

선택 기준을 거칠게 요약하면, Gateway API 표준과 Envoy 생태계에 맞추려면 Envoy Gateway, 풍부한 플러그인과 유연한 동적 라우팅이 우선이면 APISIX 쪽을 검토하게 된다. 어느 쪽이든 AI 스트리밍 라우트에서 버퍼링을 끄고 pass-through로 동작하도록 설정하는 것이 핵심 체크포인트다.

그런데 HTTP/3는 요즘 안 쓰나?

스트리밍 얘기가 나오면 자연스럽게 최신 프로토콜 질문이 따라온다. HTTP/3는 안 쓰이는 게 아니라 점점 늘어나는 추세다. 다만 위치가 다르다.

HTTP/3는 QUIC(UDP 기반) 위에서 동작해 연결 수립이 빠르고 head-of-line blocking에 강하다는 장점이 있다. 그래서 CDN과 공개 웹 서비스 쪽에서는 채택이 빠르게 늘고 있다. 반면 기업 내부망·엔터프라이즈 환경에서는 여전히 HTTP/2가 가장 널리 쓰인다. UDP 기반이라 기존 방화벽·로드밸런서·관측 도구와의 호환성 검증이 더 필요하고, 내부 서비스 간 통신에서 얻는 이득이 공개 인터넷만큼 크지 않기 때문이다.

정리하면, AI 게이트웨이를 지금 구성한다면 실무의 기본선은 여전히 HTTP/2다. HTTP/3는 외부 엣지(CDN) 구간에서 먼저 만나게 되고, 내부 스택 전면 도입은 조금 더 지켜볼 단계에 가깝다.

마치며

스트리밍 응답은 화면에서는 단순해 보인다 — 글자가 하나씩 찍힌다. 하지만 그 뒤에는 HTTP 버전별 전송 방식, 게이트웨이의 버퍼링 정책, 세션당 메모리 계산, 프로토콜 선택이 얽혀 있다.

기억할 한 줄은 이것이다. 일반 REST는 버퍼링을 써도 되지만, LLM 토큰 스트리밍 라우트는 버퍼링을 꺼서 즉시 흘려보내야 한다 — 사용자 경험을 위해서, 그리고 메모리가 세션 수만큼 터지지 않게 하기 위해서. AI 게이트웨이를 고를 때 이 한 가지 — 스트리밍 pass-through를 제대로 지원하는가 — 만큼은 반드시 확인하고 넘어가는 게 좋다.