Vercel Functions 30분 시대: 긴 AI 요청을 서버리스에 넣기 전에 정할 것

테크

서버리스 함수의 시간 제한은 개발자가 아키텍처를 결정할 때 보이지 않는 벽처럼 작동해 왔다. LLM 응답이 길어지거나, PDF에서 OCR을 돌리거나, 브라우저 자동화로 여러 페이지를 훑는 순간 “이건 API Route에 넣어도 되나, 별도 워커를 둬야 하나”라는 질문이 먼저 나왔다.

2026년 6월 15일 Vercel은 Node.js와 Python 런타임의 Vercel Functions가 Pro 및 Enterprise 팀에서 최대 30분까지 실행될 수 있다고 발표했다. 기존 800초 상한보다 긴 시간이며, 800초를 넘는 duration은 Fluid Compute가 필요하고 베타로 제공된다고 명시되어 있다. 중요한 변화지만, 결론은 “모든 작업을 하나의 함수에 넣어도 된다”가 아니다. 오히려 이제는 함수, Workflow, Queue, Sandbox를 더 명확하게 구분해야 한다.

Vercel에서 30분 Function, Workflow 또는 Queue, Sandbox를 고르는 의사결정 다이어그램
30분 실행 시간은 선택지를 넓히지만, 재시도·상태 보존·권한 경계는 여전히 별도의 설계 문제다.

무엇이 바뀌었나

공식 변경점은 간단하다. Vercel Functions는 Node.js와 Python 런타임에서 최대 30분 실행을 지원한다. Vercel은 긴 LLM reasoning과 tool call, 몇 분 동안 이어지는 AI streaming 응답, 문서·미디어 처리, OCR과 추출, 웹 스크래핑과 브라우저 자동화, 복잡한 Workflow step 또는 Queue handler를 예시로 들었다.

Next.js App Router에서는 route 파일에서 export const maxDuration = 1800으로 opt in할 수 있고, 다른 런타임과 프레임워크는 vercel.json의 functions 설정으로 특정 함수 경로에 duration을 줄 수 있다.

export const maxDuration = 1800; // 30 minutes

export async function POST(request: Request) {
  return Response.json({ ok: true });
}

다만 Vercel의 duration 문서는 기본 duration과 최대 duration을 plan별로 설명하면서, 함수가 설정된 최대 시간을 넘으면 종료된다고 경고한다. 또한 usage 문서는 Fluid Compute에서 active CPU, provisioned memory, invocation이 별도 비용 축으로 작동한다고 설명한다. 즉, 긴 실행이 가능해졌다는 말은 비용과 장애 반경을 더 오래 열어둘 수 있다는 뜻이기도 하다.

왜 지금 중요한가

AI 앱은 전통적인 API 요청보다 “기다리는 시간”이 많다. 모델 응답을 기다리고, 벡터 DB를 조회하고, 외부 SaaS API가 돌아오기를 기다리고, 사용자의 브라우저에는 streaming으로 진행 상황을 보여준다. 이전에는 이 시간이 조금만 길어져도 작업을 queue로 넘기거나 별도 worker를 운영해야 했다. 이제는 사용자에게 실시간 응답을 유지해야 하는 작업 중 일부를 Function 안에 남겨둘 여지가 커졌다.

하지만 그 경계는 여전히 선명하다. 사용자가 연결을 유지하고 결과를 기다리는 작업이라면 긴 Function과 streaming이 자연스럽다. 실패 후 재개되어야 하거나, 며칠 뒤 sleep 후 이어져야 하거나, 여러 step의 중간 상태가 중요한 작업이라면 Workflow나 Queue가 더 맞다. 파일 시스템 상태, 브라우저 세션, 테스트 런너, 장시간 에이전트 workspace가 필요하면 Sandbox가 맞다. Vercel이 같은 주에 Workflow SDK의 TanStack Start 지원과 Sandbox 24시간 실행도 발표한 이유를 함께 보면, 플랫폼의 메시지는 “모든 장시간 작업을 Function으로”가 아니라 “작업 성격별 런타임을 고르라”에 가깝다.

커뮤니티 신호

Reddit과 Next.js 커뮤니티에서는 오래전부터 Vercel runtime limit 때문에 LLM 앱, 이미지 생성, 장시간 API 작업을 어떻게 처리할지 질문이 반복됐다. 어떤 개발자는 streaming을 빨리 열어 사용자의 연결을 유지하라고 조언했고, 어떤 개발자는 15분을 넘는 작업은 별도 queue나 worker로 빼야 한다고 봤다. 이런 글들은 사실 출처라기보다 수요의 신호다. 개발자들이 원했던 것은 “더 긴 timeout”만이 아니라, timeout·비용·재시도·관측성을 함께 설명하는 운영 모델이었다.

실무 영향: API Route가 다시 후보가 된다

작업 유형30분 Function에 적합한 경우다른 런타임이 나은 경우
LLM streaming사용자가 화면에서 결과를 기다리고, partial output을 바로 보여줄 때작업이 중단 후 재개되어야 하거나 여러 agent step을 저장해야 할 때
OCR / 문서 처리파일 크기가 제한되어 있고 요청 단위 결과가 명확할 때대량 파일, 배치 재처리, 실패 재시도가 핵심일 때
웹 스크래핑 / 브라우저 자동화짧은 탐색과 추출이 요청 단위로 끝날 때로그인 세션, workspace 상태, 장시간 브라우저 실행이 필요할 때
Queue handler단일 job이 길지만 idempotent하고 상태 저장이 외부에 있을 때여러 step, backoff, human approval, 장기 sleep이 필요할 때

가장 큰 변화는 “별도 worker를 만들기 전에 Function으로 충분한가”를 다시 검토할 수 있다는 점이다. 특히 I/O-bound AI 작업은 Fluid Compute의 active CPU 과금 모델과 잘 맞을 수 있다. 반대로 이미지·영상 변환처럼 CPU와 메모리를 오래 쓰는 작업은 duration이 길어졌다고 해서 비용 리스크가 사라지지 않는다.

배포 전 체크리스트

• 요청이 30분 가까이 걸릴 때 사용자가 연결을 유지해야 하는가, 아니면 job id만 받고 나중에 조회해도 되는가?

• 함수가 중간에 종료되면 같은 입력으로 안전하게 재시도할 수 있는가?

• 외부 API timeout, model timeout, DB statement timeout이 Vercel maxDuration보다 짧게 정리되어 있는가?

• 로그에는 progress, correlation id, model/provider, retry count, elapsed time이 남는가?

• 비용 알림과 rate limit이 긴 실행 시간에 맞춰 조정되어 있는가?

반론과 리스크

첫째, 30분 duration은 베타 조건과 plan 조건이 붙는다. Vercel의 changelog는 800초 초과 duration이 Fluid Compute를 요구한다고 설명하지만, 일반 duration 문서의 plan별 표는 아직 800초를 기준으로 보이는 부분이 있다. 실제 팀에서는 대시보드, 프로젝트 설정, 현재 plan의 beta availability를 먼저 확인해야 한다.

둘째, 긴 Function은 queue의 대체재가 아니다. Function invocation은 실패 후 자동으로 “정확히 이어서” 재개되는 durable state machine이 아니다. 결제, 메일 발송, 데이터 마이그레이션처럼 중복 실행이 치명적인 작업은 idempotency key와 외부 상태 저장이 필요하다. 이 조건을 만족하지 못하면 더 긴 timeout은 버그가 늦게 터지는 공간이 된다.

셋째, 사용자 경험은 duration보다 feedback loop가 좌우한다. 30분 동안 아무 응답이 없는 API는 운영상 성공해도 제품상 실패다. 긴 작업을 Function에 둔다면 early streaming, progress event, 취소 버튼, 재조회 URL을 같이 설계해야 한다.

지금 할 일

새 기능을 바로 켜기보다, 현재 timeout 우회 코드부터 분류하는 것이 좋다. API Route에서 억지로 60초 안에 끝내려고 줄인 품질 옵션, 임시로 만든 external worker, 중간 상태 없이 돌던 queue handler를 목록화한다. 그다음 “사용자 대기형”, “durable job형”, “workspace형”으로 나누면 된다.

사용자 대기형은 긴 Function과 streaming으로 단순해질 수 있다. durable job형은 Workflow나 Queue를 유지하되 step duration만 조정한다. workspace형은 Sandbox로 넘긴다. 이렇게 나누면 30분 실행 시간은 아키텍처를 흐리는 예외가 아니라, 더 적은 인프라로 더 명확한 경계를 만드는 도구가 된다.

출처

다른 글