AI 에이전트와 서버리스 함수(serverless function)는 서로 다른 것을 원합니다. 에이전트는 생각하고, 도구(tool)를 호출하고, 토큰을 스트리밍하고, 또 다른 도구를 호출하며, 그 모든 시간 동안 연결을 계속 열어두기를 원합니다. 이 과정은 수십 초 또는 그 이상이 걸릴 수 있습니다. 반면 많은 서버리스 계층(serverless tiers)은 그 반대를 원합니다. 호출에 실행 제한(execution cap)이 있기 때문에 작업을 빠르게 수행하고 반환하기를 원합니다. 이 둘을 함께 두면 에이전트를 배포해 본 사람이라면 누구나 적어도 한 번은 겪어봤을 실패 상황이 발생합니다. 즉, 플랫폼이 시간이 다 되었다고 판단하여 소켓(socket)을 닫아버릴 때 응답이 여전히 스트리밍 중인 상황입니다.

이 글은 Neon Functions에 관한 시리즈의 두 번째 포스트입니다. 첫 번째 포스트는 데이터와 관련하여 컴퓨팅이 실행되는 위치에 관한 것이었고, 이번 포스트는 얼마나 오랫동안 대화를 계속할 수 있는지에 관한 것입니다. Neon Functions는 장기 유지되는 스트리밍 연결(long-lived streaming connections)을 유지하도록 구축되었으므로, 느린 에이전트나 긴 스트림은 타임아웃과의 싸움이 아닌 정상적인 요청입니다. 이를 단순히 주장하기보다 보여주기 위해, 저는 두 개의 엔드포인트(endpoint)를 배포하고 측정했습니다.

(동반 리포지토리, 직접 배포해 보세요: The-DevOps-Daily/neon-streaming-demo.)

두 개의 엔드포인트, 하나의 설정

전체 백엔드는 neon.ts에서 AI Gateway가 활성화된 단일 Hono 함수입니다:

import { defineConfig } from '@neondatabase/config/v1';

export default defineConfig({
...

스트리밍 자체는 일반적인 Hono입니다. 첫 번째 엔드포인트는 서버 전송 이벤트(server-sent-events) 연결을 열어두고, 요청한 초만큼 매초 틱(tick)을 방출합니다:

import { streamSSE } from 'hono/streaming';

app.get('/long-stream', (c) => {
...

두 번 요청하지 않고도 90초 동안 스트리밍되었습니다

저는 /long-stream?seconds=90을 호출하고 실행해 두었습니다. 1초에 한 번씩 틱 소리가 나며 1분 30초 동안 작동했고, 스스로의 조건에 따라 깔끔하게 종료되었습니다:

90초라는 숫자가 마법의 숫자는 아닙니다. 많은 서버리스 함수 (Serverless functions)가 기본적으로 제공하는 실행 제한 시간을 여유롭게 넘기는 수치였기에 선택했을 뿐이며, 함수는 이를 전혀 개의치 않았습니다. 특별한 모드도, 설정 플래그 (Config flag)도, "스트리밍 응답 (Streaming response)" 옵트인 (Opt-in)도 필요하지 않았습니다. 핸들러 (Handler)는 그저 연결을 유지했습니다.

비교를 정확히 하자면, 이것은 "무한 대 유한"의 문제가 아니라 기본값 (Defaults)과 설계 (Design)에 관한 것입니다. 전통적인 서버리스 함수는 기본적으로 단일 호출 (Invocation) 시간을 낮게 제한하며 (Vercel의 Hobby 티어는 10초, Pro는 60초), 이는 느린 에이전트 (Agent)가 차단되는 바로 그 지점입니다. 플랫폼들은 필요할 때 더 긴 실행 시간을 제공하기도 합니다. Vercel의 Fluid Compute는 300초에서 1800초까지 확장되며, AWS Lambda는 최대 15분까지 허용합니다. 핵심은 장기 실행 스트리밍 (Long-lived streaming)이 Neon Function의 기본 동작 (Default behaviour)이라는 점이지, 프로덕션 (Production) 환경에서 에이전트가 타임아웃 (Timeout)된 후에야 발견하게 되는 설정이 아니라는 것입니다.

이제 실제 에이전트를 스트리밍하기

시계가 작동한다는 것은 연결이 유지됨을 증명합니다. 진짜 작업 부하 (Workload)은 모델이 토큰 (Tokens)을 스트리밍하는 것입니다. 두 번째 엔드포인트 (Endpoint)는 stream: true와 함께 Neon AI Gateway로 프롬프트 (Prompt)를 전송하고, 각 토큰이 도착할 때마다 호출자에게 전달합니다:

const upstream = await fetch(`${process.env.NEON_AI_GATEWAY_BASE_URL}/ai-gateway/mlflow/v1/chat/completions`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.NEON_AI_GATEWAY_TOKEN}`, 'content-type': 'application/json' },
...

작은 프롬프트로 호출했을 때, 첫 번째 토큰은 466 ms 만에 돌아왔고, 62개 토큰으로 구성된 전체 응답은 약 2.0초 만에 완료되었습니다. 사용자는 텍스트 뭉치가 나타날 때까지 2초를 기다리는 대신, 답변이 거의 즉시 형성되는 것을 보게 됩니다:

모델과 프롬프트가 작기 때문에 2초는 짧은 시간입니다. 이것이 중요한 이유는 실제 에이전트(agents)는 짧지 않기 때문입니다. 에이전트는 여러 번의 모델 호출을 수행하고, 그 사이에 도구(tools)를 실행하며, 전체 실행 과정은 통상적으로 수십 초가 소요됩니다. 호출 시간을 10초 또는 60초로 제한하는 플랫폼에서는 이러한 실행이 시간과의 도박이 됩니다. 스트리밍을 유지하도록 구축된 함수에서는, 그저 시간이 다소 걸리는 하나의 요청일 뿐입니다.

이것은 무엇이며, 무엇이 아닌가

프라이빗 프리뷰(Private preview), 단일 리전, 신규 프로젝트 전용. 모든 것은 AWS us-east-2에 있으며, 프리뷰 내에서 생성된 프로젝트에서만 작동합니다. 이를 기반으로 구축하기 전에 계획을 적절히 세우십시오.

이 기능을 사용하기 전에 알아두어야 할 두 가지 사항이 더 있습니다:

• 응답이 길더라도 이것은 요청/응답(request/response) 방식입니다. 이 함수들은 호출자에게 응답하며, WebSockets 및 SSE를 포함하여 오랫동안 스트리밍을 유지할 수 있습니다. 이것은 백그라운드 작업 실행기(background job runner)가 아닙니다. 요청보다 더 오래 지속되어야 하는 작업(큐(queues), 재시도(retries), 예약된 작업(scheduled tasks))은 Inngest나 QStash와 같은 도구에 적합합니다.
• 유휴(Idle) 상태의 함수는 제거될 수 있습니다. 길게 유지되는 활성(active) 스트림은 괜찮습니다. 하지만 함수가 유휴 상태로 있으면 0으로 스케일링(scaled to zero)될 수 있으며, 다음 호출 시 콜드 스타트(cold-start)가 발생할 수 있습니다. 이는 스트리밍 전용 문제가 아니라 일반적인 서버리스(serverless)의 트레이드오프(tradeoff)입니다.

대상 사용자

만약 여러분이 에이전트 기능이 포함된 서비스(채팅 어시스턴트, 도구 사용 에이전트, 긴 생성 작업, 세션을 유지하는 MCP 서버 등)를 출시하려 한다면, 타임아웃(timeout)은 가장 먼저 맞닥뜨리게 될 벽입니다. 일반적인 해결책은 사용 중인 플랫폼의 확장 지속 시간 모드(extended-duration mode)를 파악하고, 설정을 제대로 했기를 바라는 것뿐입니다. 기본적으로 스트림(stream)을 유지하는 함수를 사용하면, "왜 응답이 중간에 끊겼지?"와 같은 디버깅 카테고리 자체를 제거할 수 있습니다.

두 엔드포인트(endpoint)가 모두 포함된 전체 데모는 여기에 있습니다. 스트리밍 로직은 약 80줄 정도입니다:

https://github.com/The-DevOps-Daily/neon-streaming-demo

시리즈의 다음 내용: 약 20줄 내외로 작성된 Postgres 기반 MCP 서버, 그리고 프론트엔드뿐만 아니라 백엔드까지 포함하는 프리뷰 환경(preview environments)에 대해 다룹니다. 이 모든 것의 이면에 있는 전략은 Neon is becoming a backend platform, not just Postgres에서 확인할 수 있습니다.