Cloudflare의 워크플로우(Workflows) 컨트롤 플레인 재설계 과정을 다룬 이 글은, 인간 중심의 트리거에서 AI 에이전트 중심의 고속 트리거로 변화하는 기술 환경에 대응하기 위한 아키텍처 전환을 설명합니다. 기존의 중앙 집중식 구조에서 발생하는 병목 현상을 해결하기 위해 수평적 확장이 가능한 새로운 컴포넌트를 도입하였으며, 이를 통해 동시 실행 인스턴스 수를 기존 대비 10배 이상인 50,000개까지 확장하는 데 성공했습니다. 결과적으로 에이전트가 생성하는 방대한 양의 워크로드를 안정적이고 탄력적으로 처리할 수 있는 기반을 마련했습니다.

에이전트 시대의 워크로드 변화와 새로운 요구사항

트리거 주체의 변화: 과거에는 사용자의 회원가입이나 주문 등 인간의 행동에 의해 워크플로우가 시작되었으나, 현재는 자율적인 AI 에이전트가 기계적인 속도로 워크플로우를 생성합니다.
지속성 및 내구성의 중요성: 에이전트가 며칠 동안 작업을 수행하거나 인간의 승인을 기다리는 동안, 워크플로우는 각 단계를 독립적으로 재시도하고 실패 시에도 진행 상황을 유지하는 내구성이 필요합니다.
폭발적인 인스턴스 생성: 단일 에이전트 세션이 수십 개의 워크플로우를 생성하고 수천 개의 인스턴스가 동시에 실행되는 환경에 대응하기 위해 더 높은 처리량이 요구됩니다.

V1 아키텍처의 한계: 중앙 집중형 구조의 병목

단일 Durable Object(DO) 의존: 모든 계정 레벨의 정보와 인스턴스 관리를 'Account'라는 단일 Durable Object가 담당하여 병목 현상이 발생했습니다.
확장성 제약: 인스턴스 생성, 업데이트, 조회 등의 모든 작업이 하나의 DO를 거쳐야 했으므로, 동시 실행 4,500개 및 10초당 100개의 생성 제한이라는 물리적인 한계에 부딪혔습니다.
상태 불일치 가능성: 워크플로우를 큐에 넣기 전 실제 실행 엔진(Engine)의 생성 여부를 확인하는 로직이 부족하여 비정상적인 상태가 발생할 가능성이 있었습니다.

V2 아키텍처: 수평적 확장을 위한 재설계 원칙

엔진 중심의 진실 공급원(Source of Truth): 특정 인스턴스의 존재 여부에 대한 권한을 해당 인스턴스의 실행 엔진(Engine)에만 부여하여 의존성을 분산했습니다.
메타데이터의 최소화: 계정 수준의 싱글톤(Singleton) 객체는 최소한의 메타데이터만 저장하고, 요청 수에 관계없이 일정한 성능을 유지하도록 설계했습니다.
새로운 컴포넌트 도입: 'Account' DO의 부하를 분산하기 위해 메타데이터와 생명주기 관리를 보조하는 SousChef와 동시성 제어 및 액세스를 담당하는 Gatekeeper를 새롭게 구축했습니다.

향상된 성능 지표 및 확장된 한계치

동시 실행 인스턴스: 기존 4,500개에서 50,000개로 대폭 상향되었습니다.
인스턴스 생성 속도: 계정당 초당 100개에서 초당 300개로 향상되었습니다.
대기열 용량: 워크플로우당 대기 중인 인스턴스 수가 100만 개에서 200만 개로 두 배 늘어났습니다.

AI 에이전트가 주도하는 애플리케이션을 구축하는 개발자라면, 이제 인프라의 한계에 구애받지 않고 고도로 병렬화된 워크플로우를 설계할 수 있습니다. Cloudflare Workflows의 V2 컨트롤 플레인은 대규모 자동화 인프라를 위한 강력하고 탄력적인 토대를 제공합니다.