pile·
아키텍처·vercel-blogVercel Blog·

지속형 실행을 위한 새 프로그래밍 모델 — Vercel Workflows GA

Vercel이 장시간 실행 작업·에이전트·백엔드를 위한 지속형 실행 프레임워크 Vercel Workflows를 GA 출시하며 새 프로그래밍 모델을 공개했다. "use workflow"·"use step" 디렉티브만으로 별도 오케스트레이션 서비스(큐·워커·상태 테이블·재시도 로직) 없이 내결함성 있는 분산 작업 파이프라인을 정의할 수 있다. 베타 기간 동안 1,500개 이상 고객이 1억 건 이상의 워크플로우를 실행했다.

핵심 포인트
  • "use workflow"·"use step" 디렉티브 기반 선언적 오케스트레이션 — 큐·워커·상태 DB·재시도 로직을 별도 구성할 필요 없다.
  • 세 가지 기반 레이어: Event Log(실행 히스토리 단일 소스), Fluid Compute(각 단계가 독립 함수 호출), Vercel Queues(자동 단계 큐잉).
  • 지속형 스트림: 사용자가 브라우저를 닫아도 워크플로우가 계속 실행되고, 재연결 시 정확한 시점에서 재개된다.
  • Hooks + Sleep: 외부 트리거 대기(인간 승인 흐름, 3rd-party 콜백) + 컴퓨팅 비용 없는 분~개월 단위 sleep.
  • SDK는 오픈소스이며 Worlds 어댑터로 Postgres 자체 호스팅·MongoDB·Redis·Cloudflare 등 다중 인프라에서 실행 가능.
상세 정리
  • 문제: 로컬에서 동작하는 코드가 프로덕션에서 장애 복구·재시작·실패 처리로 복잡해진다. 기존에는 큐+워커+상태 테이블+재시도 로직을 따로 구성하거나 Kubernetes 위에 별도 오케스트레이션 서비스를 운영해야 했다.
  • 해결 방향: "Framework defined infrastructure" — 애플리케이션 코드 자체가 오케스트레이션을 내장하는 방식.
  • TypeScript 구현: 함수에 "use workflow" 선언으로 워크플로우, "use step" 선언으로 격리 실행 단위 정의. 각 step은 자동으로 재시도·지속성·관찰성을 획득한다.
  • Python 구현(베타): @wf.workflow, @wf.step 데코레이터로 동일 모델 구현.
  • Event Log: 모든 단계의 입력·출력·스트림 청크·대기·오류를 기록하는 실행 상태의 단일 정보 소스.
  • 비용 모델: 실제 실행 중인 함수 컴퓨팅만 과금. 별도 오케스트레이션 서비스 상시 구동 비용 없음.
  • 지속형 스트림: AI 에이전트 스트리밍 응답을 워크플로우로 실행해 브라우저 재연결 시 정확한 재개 지점 복원. WorkflowChatTransport + useChat 훅으로 클라이언트 연결.
  • Hooks·Sleep: 인간 승인 게이트, 3rd-party 콜백 대기에 Hooks 사용. 이메일 drip 캠페인·날짜 기반 작업에 sleep 사용(컴퓨팅 미사용 상태로 개월 단위 대기 가능).
  • 보안: 단계 입력·출력·스트림 청크가 배포 경계를 떠나기 전에 E2E 암호화. 복호화는 실행 배포 내에서만 발생.
  • 페이로드 제한: 단계당 50MB, 실행당 최대 2GB — 멀티모달 에이전트의 이미지·비디오 처리에 대응.
  • Worlds 어댑터: 관리형(Vercel), 자체 호스팅(Postgres), 임베디드(MongoDB/Redis/Turso/Cloudflare) 세 모드 지원. SDK 오픈소스.
  • Workflows 5 예정: 네이티브 동시성 제어(다중 실행 간 잠금 기본 요소), 스냅샷 기반 런타임(이벤트 히스토리 재생 오버헤드 감소), 글로벌 배포 인프라.
  • 실사례: Mux(비디오+AI 파이프라인), Durable(300만 사업자 웹사이트 30초 생성), Flora(50+ 이미지 모델 에이전트) 모두 자체 오케스트레이션을 폐기하고 Workflows로 전환했다.
왜 읽나AI 에이전트·백엔드 파이프라인을 신뢰성 있게 운영해야 하는 풀스택·백엔드 엔지니어에게 별도 오케스트레이션 서비스 없이 내결함성 있는 장시간 실행 작업을 정의하는 패턴 레퍼런스.
vercel-blog
Vercel Blog 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 아키텍처·aws-architectureAWS Architecture·

    일관성이 새로운 지연이다: 데이터 레이어에서의 AI

    AI 에이전트가 데이터베이스 레이어에서 겪는 데이터 정합성 문제를 다룬다. 비동기 복제 지연(replication lag)으로 stale 데이터를 읽은 에이전트가 잘못된 판단을 내리는 "조용한 독"을 AWS 서비스 기반 세 가지 아키텍처 패턴으로 해결하는 방법을 제시한다. "빠르지만 틀린 답이 약간 느리지만 맞는 답보다 비싸다"는 주장 아래, 데이터베이스 아키텍처를 AI 신뢰성의 기반으로 재정의한다.

    요약 이어보기
    #ai-agent#data-consistency#aurora+2
  2. 아키텍처·flexflex·

    사람도 에이전트도, 덜 읽을수록 더 잘 고칩니다

    flex 팀이 코드베이스의 모듈 경계 설계가 AI 에이전트의 코드 탐색 효율에 미치는 영향을 실측한 글이다. 193개 에이전트 작업 로그를 분석하고, 잘 나뉜 모듈과 뭉친 모듈을 비교한 결과 — 도메인이 물리 모듈로 분리된 저장소에서 에이전트가 불필요한 파일을 덜 읽고 목표 코드에 더 집중했다. 사람도 에이전트도 컨텍스트 한도가 있어, 무관 코드를 덜 읽을수록 수리 성공률이 높다는 것이 핵심 결론이다.

    요약 이어보기
    #llm-agent#context-window#modular-architecture+1
  3. 아키텍처·aws-architectureAWS Architecture·

    데이터 거주 요건을 충족하는 재해 복구 전략

    데이터 거주(data residency) 규정을 지키면서 재해 복구(DR)를 구현해야 하는 조직을 위해 AWS가 세 가지 전략 프레임워크를 제시한다. 금융, 의료, 공공 부문처럼 지리적 데이터 보관 의무가 있는 환경에서도 복구 목표(RTO/RPO)를 달성할 수 있는 아키텍처 선택지를 비교한다.

    요약 이어보기
    #multi-cloud#compliance#disaster-recovery+2