기존 API 게이트웨이가 생성형 AI와 충돌하는 이유

수년 동안 엔터프라이즈 아키텍처는 표준 규칙을 따랐습니다. 즉, 모든 백엔드 서비스 앞에 엔터프라이즈 API 관리 게이트웨이를 배치하는 것이었습니다.

이 패턴은 REST 및 GraphQL 마이크로서비스에 대해 검증되었습니다. 클라이언트가 요청을 보내면, 게이트웨이가 토큰을 확인하고 분당 100회와 같은 속도 제한(rate limit)을 적용한 후, 데이터베이스로 호출을 전달하고 50밀리초 만에 원자적 JSON 응답을 반환했습니다.

하지만 조직들이 이러한 레거시 게이트웨이를 생성형 AI 모델과 자율 에이전트 앞에 배치할 때, 아키텍처가 무너집니다.

본 게시물에서는 기존 API 게이트웨이가 생성형 AI 워크로드에 왜 어려움을 겪는지, 스트리밍 네이티브(streaming-native) 엣지 레이어가 이 문제를 어떻게 해결하는지, 그리고 무엇을 주의해야 하는지를 설명합니다.

문제점: 생성형 AI의 불일치 (Mismatch)

기존 API 게이트웨이는 LLM에 부적합한 세 가지 핵심 가정에 기반하여 설계되었습니다:

1. 원자적 응답(Atomic Responses) 대 실시간 토큰 스트림(Real-Time Token Streams): 기존 프록시는 헤더를 검사하거나, 데이터 유출을 확인하거나, 압축률을 계산하기 위해 전체 HTTP 응답을 메모리에 버퍼링하는 경우가 많습니다. LLM은 텍스트 토큰을 하나씩 생성합니다. 버퍼링은 실시간 타이핑 경험을 파괴하고, 긴 응답에서 버퍼 오버플로우를 일으키며, 게이트웨이의 조기 타임아웃(timeout)을 유발합니다.
2. 단기 연결(Short-Lived Connections) 대 분 단위 세션(Minute-Long Sessions): 기존 마이크로서비스 요청은 밀리초 만에 완료됩니다. 하지만 AI 에이전트 추론, 다단계 도구 실행, 복잡한 합성 과정은 HTTP 연결을 30초에서 120초 동안 열어둘 수 있습니다. 높은 동시성 환경에서 장기 연결은 게이트웨이 연결 풀(connection pools)을 빠르게 고갈시켜, 서버 CPU 사용률이 낮더라도 잘못된 타임아웃을 유발합니다.
3. 요청 카운팅(Request Counting) 대 토큰 소비(Token Consumption): 표준 게이트웨이는 요청 횟수(예: 분당 60회 요청)로 속도 제한을 설정합니다. 하지만 생성형 AI에서는 한 요청이 10토큰짜리 인사말일 수 있는 반면, 다른 요청은 80,000토큰짜리 문서 분석일 수 있어 컴퓨팅 비용이 1,000배 더 많이 들 수 있습니다. 요청 기반 속도 제한은 상위 할당량(upstream quotas)을 보호하거나 비용 초과를 방지하는 데 실패합니다.

아이디어: 스트리밍 네이티브 엣지 아키텍처

기존의 API 게이트웨이를 통해 생성형 AI 트래픽을 강제하는 대신, 전통적인 API 관리와 스트리밍 AI 트래픽을 분리하는 것이 목표였습니다.

저희는 AI 프로토콜의 작동 방식에 맞춰 설계된 가볍고 스트리밍 우선(streaming-first)의 엣지 프록시를 구축했습니다:

• 제로 버퍼링 패스스루 (Zero-Buffering Passthrough): 엣지 프록시는 초기 HTTP 핸드셰이크 과정에서 호출자를 인증한 후, 데이터 경로에서 즉시 벗어나 업스트림 모델 서비스로부터 클라이언트로 원시 바이트(raw bytes)를 스트리밍합니다.
• 토큰 및 동시성 할당량 (Token and Concurrency Quotas): 단순 요청 횟수를 세는 대신, 속도 제한기(rate limiter)가 활성화된 동시 실행 횟수와 누적 토큰 사용량을 추적하여, 테넌트가 사용 한계에 접근할 때 트래픽을 조절합니다.
• 하트비트 관리 (Heartbeat Management): 첫 번째 토큰을 출력하기까지 몇 초 동안 생각하는 추론 모델(reasoning models)의 경우, 엣지 계층은 주기적인 keep-alive 주석 프레임(comment frames)을 발생시켜 중간 기업용 프록시나 방화벽이 유휴 TCP 연결을 끊는 것을 방지합니다.

잘 작동한 방식

1. 즉각적인 사용자 반응성: 게이트웨이 응답 버퍼링을 제거함으로써 첫 번째 가시적 토큰까지의 지연 시간이 줄어들었고, 최종 사용자에게 부드러운 스트리밍 타이핑 효과가 복원되었습니다.
2. 탄력적인 연결 풀 (Resilient Connection Pools): 스레드당 연결 풀(thread-per-connection pools) 대신 가벼운 이벤트 루프를 사용하여 비동기적으로 연결을 처리함으로써, 엣지 계층은 성능 저하 없이 수천 개의 동시 장기 스트림을 지원할 수 있었습니다.
3. 공정한 사용 및 비용 보호: 토큰 기반 속도 제한(Token-based rate limiting)은 무분별한 스크립트나 대용량 배치 쿼리가 상호작용 사용자에게 자원을 고갈시키거나 클라우드 제공업체 할당량을 소진시키는 것을 방지했습니다.
4. 깔끔한 운영 분리 (Clean Operational Separation): 플랫폼 엔지니어들은 기업 전체의 API 게이트웨이 출시 주기(release cycles)에 구애받지 않고, AI 전용 엣지 정책에 대한 완전한 통제권을 유지할 수 있었습니다.

주의해야 할 점

1. 기업 중간 프록시 (Corporate Intermediary Proxies): 엣지 프록시가 버퍼링 없이 스트리밍하더라도, 사용자 네트워크에 있는 중간 기업 프록시, VPN 또는 웹 애플리케이션 방화벽(WAF)이 응답을 여전히 버퍼링할 수 있습니다. 모든 스트리밍 응답에서 명시적으로 버퍼링 헤더(X-Accel-Buffering: no)를 비활성화하십시오.
2. 사일런트 클라이언트 연결 끊김 (Silent Client Disconnects): 사용자가 스트림 도중에 브라우저 탭을 닫으면 연결이 끊어집니다. 만약 엣지 계층이 클라이언트 연결 끊김을 능동적으로 감지하지 못하면, 백엔드 모델 서비스는 더 이상 존재하지 않는 청중을 위해 토큰을 계속 생성하고 비용을 소모하게 됩니다. 클라이언트 연결 끊김이 추론 실행을 취소하도록 업스트림으로 즉시 전파되도록 보장하십시오.
3. 토큰 회계 지연 (Token Accounting Lag): 토큰을 정확하게 계산하려면 스트림의 맨 끝에서 최종 사용 메타데이터를 읽어야 합니다. 요청 시작 전에만 동기적으로 할당량을 강제하면, 사용자가 첫 번째 요청이 완료되기 전에 할당량을 초과하는 여러 개의 대규모 동시 요청을 시작할 수 있습니다. 사전 요청 동시성 제한(pre-request concurrency limits)과 사후 요청 토큰 회계(post-request token accounting)를 결합하십시오.
4. 하트비트 관리 (Heartbeat Hygiene): Keep-alive 프레임은 장시간 추론 모델에 필수적이지만, 클라이언트 측 파서가 주석 프레임(`: keepalive

`)을 UI에서 깨진 텍스트로 렌더링하지 않으면서 무시하는 방법을 알아야 합니다.