Cloudflare Dynamic Workflows, AI 에이전트 런타임이 테넌트별 장기 실행으로 간다

Cloudflare가 Dynamic Workflows를 공개하며 AI 에이전트와 멀티테넌트 SaaS가 “런타임에 정해지는 작업”도 실패 복구와 대기 상태를 갖고 오래 실행할 수 있는 길을 열었다. 핵심은 에이전트가 만든 계획이나 고객별 자동화 코드를 한 번의 요청 안에 가두지 않고, 테넌트 맥락을 따라 다시 불러와 이어 실행하게 만든 점이다.

테넌트별 실행 흐름이 제품 기능으로 올라왔다

Cloudflare 발표의 제목은 “durable execution that follows the tenant”다. 이 문장은 이번 변화의 방향을 꽤 정확히 보여준다. 기존 서버리스 자동화는 미리 배포된 함수와 미리 등록된 워크플로우를 기준으로 움직였다. 반면 Dynamic Workflows는 Dynamic Workers와 Workflows를 연결해, 런타임에 불러온 고객별 코드나 에이전트 계획에도 오래 살아남는 단계 실행을 붙인다.

이 변화는 AI 에이전트 서비스에 특히 중요하다. 에이전트가 사용자의 지시를 받아 여러 도구를 호출하고, 중간에 사람 승인을 기다리고, 외부 시스템의 웹훅을 기다린 뒤 다음 작업을 이어가야 한다면 단일 HTTP 요청으로는 부족하다. 실패하면 어디까지 끝났는지 알아야 하고, 이미 성공한 단계를 다시 실행하지 않아야 하며, 몇 시간 또는 며칠 뒤에도 같은 고객의 로직으로 재개해야 한다. Cloudflare가 이번에 강조한 부분은 바로 이 “누가 만든 어떤 로직을 어디서 다시 이어 실행할 것인가”라는 런타임 문제다.

단순 큐보다 어려운 문제

작업 큐는 메시지를 다시 처리할 수 있게 해주지만, 에이전트 플랜의 각 단계가 어떤 입력과 결과를 가졌는지, 승인 대기 중인지, 어느 테넌트의 코드로 돌아가야 하는지를 자동으로 해결하지는 않는다. Cloudflare Workflows는 step.do(), step.sleep(), step.waitForEvent() 같은 단계 모델을 제공하고, Dynamic Workflows는 이 모델을 동적으로 로드된 Worker 코드와 묶는다. 즉 “고객 A가 작성한 자동화”와 “고객 B가 작성한 자동화”가 서로 다른 로직을 가져도, 플랫폼은 각 실행의 메타데이터를 따라 올바른 코드를 다시 불러오는 구조를 갖게 된다.

이 지점에서 AI 코딩 플랫폼의 경쟁 축도 바뀐다. 좋은 모델을 붙이는 것만으로는 충분하지 않다. 생성된 작업 계획이 장시간 실행될 때 어떤 상태를 남기는지, 어떤 경계 안에서 네트워크와 저장소에 접근하는지, 실패 후 재시도 기준이 무엇인지, 사용자가 중간 승인 지점을 어디에 둘 수 있는지가 제품 품질을 결정한다.

에이전트 런타임은 상태와 재개 능력으로 평가된다

Cloudflare Workflows 문서는 이 기능을 “durable multi-step applications”로 설명한다. 여러 단계를 묶고, 실패한 작업을 다시 시도하며, 상태를 분·시간·주 단위로 보존한다는 의미다. AI 애플리케이션에서는 이 설명이 단순한 백엔드 편의 기능을 넘어선다. 에이전트가 이미 파일을 만들었는지, 결제 승인 요청을 보냈는지, 외부 서비스에서 콜백을 받았는지, 사람이 리뷰를 끝냈는지에 따라 다음 행동이 달라지기 때문이다.

Cloudflare Agents 문서도 같은 방향을 가리킨다. 오늘날 많은 AI 앱은 요청을 처리하고 응답을 돌려준 뒤 상태를 잊지만, 실제 에이전트는 대화를 기억하고, 일정에 따라 행동하고, 도구를 호출하고, 다른 에이전트와 조율하며, 사용자와 실시간 연결을 유지해야 한다. Agents SDK는 Durable Object 기반의 상태, SQL 저장소, WebSocket, 스케줄링을 제공한다. Dynamic Workflows는 여기에 “각 고객이나 각 에이전트가 만든 워크플로우를 오래 실행한다”는 계층을 얹는다.

VIBE 코딩에서 달라지는 지시서

VIBE 코딩 관점에서는 작업 지시서의 내용이 더 구체적이어야 한다. “이 기능을 자동화해줘”가 아니라 “단계를 분리하고, 성공한 단계는 재실행하지 말고, 승인 대기 지점을 두고, 실패 시 재시도 횟수와 중단 조건을 남기고, 테넌트별 권한을 섞지 말라”는 식의 실행 계약이 필요하다. 특히 AI가 고객별 로직을 생성하거나 수정하는 제품이라면 샌드박스, 네트워크 접근, 로그 마스킹, 비용 상한, 수동 승인 범위를 지시서에 넣어야 한다.

이제 에이전트 코딩의 품질은 PR 설명이나 테스트 통과만으로 끝나지 않는다. 워크플로우 인스턴스가 중간에 멈췄을 때 어떤 상태로 보이는지, 다시 시작해도 중복 처리하지 않는지, 사람이 승인하지 않은 단계가 진행되지 않는지, 테넌트 식별자가 로그나 화면에 과하게 노출되지 않는지까지 검증해야 한다. AI가 만든 자동화가 많아질수록 이런 운영 계약이 곧 제품 안정성이다.

Cloudflare 조합이 노리는 개발자 경험

이번 발표에서 중요한 조합은 Dynamic Workers, Workflows, 그리고 @cloudflare/dynamic-workflows 라이브러리다. Dynamic Workers는 런타임에 코드를 구성해 격리된 Worker로 실행하는 저수준 프리미티브다. 문서는 이를 AI Agent “Code Mode”, AI-generated applications, Vibe Code, 빠른 미리보기, 커스텀 자동화, 플랫폼형 사용자 업로드 앱 실행에 맞는 패턴으로 설명한다. Workflows는 그 코드가 여러 단계를 거치며 멈추고 다시 시작할 수 있게 만든다.

Cloudflare 개발자 문서에 따르면 구조는 세 부분으로 나뉜다. Worker Loader는 배포된 주 Worker로 요청을 받고 어느 Dynamic Worker를 불러올지 결정한다. Dynamic Worker는 고객별 또는 실행별 실제 단계 로직을 담는다. DynamicWorkflow 클래스는 Workflows 엔진이 단계를 실행하거나 재개할 때 올바른 Dynamic Worker를 다시 로드한다. 라이브러리의 wrapWorkflowBinding은 테넌트 같은 메타데이터를 Workflow 인스턴스에 붙이고, createDynamicWorkflowEntrypoint는 재개 시점에 올바른 클래스를 다시 찾게 한다.

개발자가 얻는 것은 배포 속도만이 아니다

이 설계의 장점은 새 자동화를 하나 추가할 때마다 별도 Workflow를 배포하지 않아도 된다는 데 있다. 하지만 더 큰 의미는 운영 모델이다. SaaS 플랫폼은 고객마다 다른 온보딩 순서, 승인 체인, 청구 재시도, 데이터 변환 규칙을 갖는다. AI 에이전트 플랫폼은 사용자마다 다른 도구 조합과 계획을 실행한다. 이런 상황에서 모든 로직을 하나의 고정 코드베이스에 밀어 넣으면 제품은 빠르게 복잡해지고, 반대로 모든 고객 로직을 완전히 분리 배포하면 운영 부담이 커진다.

Dynamic Workflows는 그 중간 지대를 노린다. 코드는 필요할 때 로드하고, 실행 상태는 Workflows가 보존하며, 재개 시에는 저장된 메타데이터로 같은 테넌트 로직을 따라간다. 개발자는 컨테이너 오케스트레이터를 직접 만들지 않고도 고객별 자동화와 에이전트 플랜을 더 세밀하게 다룰 수 있다. AI 제품을 만드는 팀에게는 “사용자가 만든 로직을 어디서, 얼마나 안전하게, 얼마나 오래 실행할 것인가”라는 질문에 대한 새 선택지가 생긴 셈이다.

실무 적용은 작은 장기 작업부터 시작해야 한다

가장 좋은 첫 적용 대상은 되돌리기 쉬운 장기 작업이다. 예를 들어 가입 후 온보딩 이메일과 승인 대기, 이미지나 문서 처리 후 사람 검수, 외부 웹훅 수신 뒤 후속 작업, 결제 실패 후 재시도, 에이전트가 만든 배포 전 점검 리스트 실행 같은 흐름이다. 이런 작업은 단일 요청으로 끝나지 않고, 실패 복구와 재개 가능성이 실제 사용자 경험을 좌우한다.

팀이 검증해야 할 항목은 명확하다. 첫째, 각 단계가 멱등적으로 설계되어야 한다. 이미 발송한 알림이나 이미 만든 리소스를 재시도 때 중복으로 만들면 안 된다. 둘째, 사람 승인 또는 외부 이벤트 대기 단계는 만료 시간을 가져야 한다. 무기한 대기 인스턴스가 쌓이면 비용과 운영 노이즈가 커진다. 셋째, 테넌트 식별과 권한 경계를 테스트해야 한다. 다른 고객의 로직이나 상태로 이어 실행되는 일은 치명적이다.

검증 루프는 코드 테스트보다 길다

로컬 단위 테스트만으로는 충분하지 않다. Dynamic Workflow는 “성공한 뒤 재실행하지 않는가”, “sleep 이후 같은 입력으로 돌아오는가”, “event 대기 중 취소하면 어떻게 되는가”, “Loader가 잘못된 테넌트 메타데이터를 받으면 거부하는가” 같은 상태 전이 테스트가 필요하다. AI 에이전트가 계획을 생성한다면, 생성된 단계 이름과 입력값이 관찰 가능한 로그로 남되 민감한 자격 증명이나 사용자 원문을 그대로 공개하지 않도록 해야 한다.

또한 실무자는 비용 모델을 함께 봐야 한다. 장시간 대기와 많은 인스턴스는 무료로 사라지는 것이 아니다. Cloudflare Limits 문서는 Workflows 한계와 Workers 한계가 함께 작동한다고 설명한다. 따라서 파일럿에서는 “동시 인스턴스 수, 대기 시간, 재시도 횟수, 외부 호출 실패율, 수동 승인 지연 시간”을 계측 지표로 잡아야 한다. AI가 자동화 단계를 많이 만들수록 관찰 가능한 수치가 없으면 장애 원인을 찾기 어렵다.

위험은 동적 코드와 긴 수명에서 나온다

Dynamic Workers 문서는 런타임 코드 실행을 강력한 샌드박스 프리미티브로 설명하지만, 그만큼 설계 책임도 커진다. AI가 만든 코드나 고객이 올린 자동화 코드는 기본적으로 신뢰하기 어렵다. 네트워크 접근, 바인딩, 저장소, 외부 호출, 실행 시간, 로그 범위를 제한하지 않으면 에이전트 자동화는 편리함보다 사고 가능성을 먼저 키운다.

특히 멀티테넌트 환경에서는 “동적으로 불러온 코드가 무엇을 볼 수 있는가”가 핵심이다. 테넌트 A의 자동화가 테넌트 B의 상태, 파일, 연결 정보, 승인 이벤트를 볼 수 없어야 한다. Loader가 메타데이터를 붙이는 구조는 편리하지만, 잘못된 메타데이터 검증은 곧 권한 혼선으로 이어질 수 있다. 따라서 프로덕션 도입 전에는 샌드박스 권한 표, 네트워크 허용 목록, 이벤트 이름 규칙, 로그 보존 정책, 관리자 승인 경로를 먼저 문서화해야 한다.

AI 제품이 조심해야 할 과장

이번 발표를 “에이전트가 모든 장기 작업을 알아서 운영한다”로 읽으면 위험하다. Dynamic Workflows는 실행과 재개를 위한 인프라를 제공하지만, 좋은 단계 설계와 안전한 승인 흐름을 대신 만들어주지는 않는다. AI가 플랜을 만들더라도 사람이 승인해야 할 단계, 자동 재시도하면 안 되는 단계, 실패하면 즉시 중단해야 할 단계는 제품 팀이 정해야 한다.

또 하나의 리스크는 관찰성이다. 동적으로 생성된 코드가 늘어나면 같은 오류도 고객별로 다르게 나타난다. 따라서 운영 화면은 단순 성공·실패보다 “어떤 테넌트의 어떤 단계가 어떤 입력 범위에서 멈췄는지”를 보여줘야 한다. 단, 그 정보가 공개 화면이나 사용자 공유 링크에 과도하게 드러나면 보안 문제가 된다. 내부 관찰성과 공개 안전성 사이의 경계를 설계하는 일이 중요하다.

다음 관전 포인트는 표준화와 이식성이다

Cloudflare의 Dynamic Workflows는 에이전트 런타임이 어디로 가는지 보여주는 사례다. 서버리스 플랫폼은 더 이상 짧은 요청 처리만 겨루지 않는다. AI 에이전트가 장기 계획을 실행하고, 사용자별 코드를 다루고, 승인을 기다리고, 다시 깨어나는 흐름을 얼마나 안전하게 제품화하는지가 경쟁력이 된다.

다음으로 볼 지점은 표준화다. 에이전트 플랜의 단계 표현, 이벤트 이름, 승인 신호, 실패 사유, 비용 한도, 관찰성 이벤트가 플랫폼마다 다르면 팀은 특정 런타임에 강하게 묶인다. 반대로 최소한의 추상화가 생기면 개발자는 모델과 런타임을 더 자유롭게 조합할 수 있다. MCP 같은 도구 인터페이스가 확산되는 흐름과 맞물려, 장기 실행 워크플로우에도 비슷한 계약 논의가 커질 가능성이 있다.

VIBE 코딩 팀이 지금 얻을 교훈은 현실적이다. 에이전트에게 더 큰 작업을 맡기려면 먼저 작업을 오래 살아남는 단계로 나누고, 각 단계의 입력·출력·재시도·승인·중단 기준을 글로 적어야 한다. 그 기준을 테스트와 라이브 스모크로 검증할 때만 AI 자동화는 데모를 넘어 운영 가능한 제품이 된다.

짧은 출처

• Cloudflare 발표
• Dynamic Workflows
• Workflows 개요
• Dynamic Workers
• Agents 개요