본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
2026년은 에이전트 하네스가 프로덕션을 시작하는 해입니다. Codex, Claude Code, OpenCode, Pi, Project Think 등의 장치와 같이 외부 세계에 대한 모델의 액세스를 제어하는 소프트웨어는 팀에서 에이전트를 단순한 프로토타입이 아닌 실제적인 부하 인프라로 배포할 정도로 성숙했습니다.
하지만 프로덕션에서도 살아남을 수 있는 에이전트를 구축하는 것은 어려운 일입니다.
이를 통해 Project Think 직접 구축하는 것을 자사 에이전트 도구로 직접 배웠습니다. 프로덕션 환경에서 에이전트를 실행하기 위해 고객을 찾는 과정에서, Cloudflare는 모든 에이전트를 클라우드에서 실행할 때 직면하는 분산 시스템 공통 문제를 발견했습니다. 에이전트가 중단되었을 때 어떻게 해야 컨텍스트를 잃지 않고 토큰을 낭비하는 일 없이 중단된 지점부터 자동으로 원활하게 재개할 수 있을까요? 에이전트가 신뢰할 수 없는 코드를 안전하게 실행하는 방법은? 에이전트는 학습의 대상이 된 도구를 어떻게 사용할 수 있을까요?
하네스만으로는 이러한 문제를 해결할 수 없습니다. 에이전트는 상태, 스토리지, 컴퓨팅과 묶여 있으므로 에이전트가 실행되는 플랫폼에 종속됩니다. 그래서 프로덕션용 Project Think를 강화하면서 얻은 교훈을 Cloudflare Agents SDK의 기본 계층에 적용하고 있습니다. 이제 Agents SDK에서 구축된 모든 장치에 영구적인 실행, 동적 코드 실행, 지속형 파일 시스템 및 동적 워크플로우가 제공됩니다.
동시에 안전벨트 위에 새로운 층이 등장했습니다. Flue와 같은 프레임워크는 에이전트를 생산적으로 구축할 수 있도록 프로젝트 구조, 규칙, 통합, 개발자 경험으로 하네스를 감쌉니다.
이러한 확장 문제를 해결하기 위해 프로덕션급 AI 구축을 위해 새로운 3계층 스택이 부상하고 있습니다. 다음은 사용자 대면 개발자 경험에서 기본 플랫폼 기본 요소로 이동하면서 각 요소가 함께 조화를 이루는 방식입니다.
프레임워크(Flue) — 프로젝트 구조, 규칙, 통합, CLI, 에이전트 구축을 위한 개발자 경험.
하네스 (Pi, Project Think) — 도구를 호출하고, 결과를 읽고, 컨텍스트를 관리하며 작업이 완료될 때까지 계속 작동하는 에이전트 루프입니다.
런타임/플랫폼 (Cloudflare Agents SDK) — 위의 모든 것이 의존하는 컴퓨팅, 상태, 스토리지 기본 요소
Agents SDK는 가장 아래에 있는 계층으로, 모든 장치 및 프레임워크에서 지속형 실행과 같은 기본 요소를 사용할 수 있도록 합니다. Astro 개발팀에서 선보이는 새로운 오픈 소스 프레임워크인 Flue는 Astro를 기반으로 구축한 최초의 제품입니다. 방법은 다음과 같습니다.
Flue 는 이번 주에 1.0 베타를 출시했으며, 이는 OpenClaw가 구축된 것과 동일한 하네스인 Pi 하네스를 기반으로 구축되었습니다. 에이전트 프레임워크와 다른 점은 에이전트가 수행하는 내용을 스크립팅하는 것이 아니라 알고 있는 내용을 설명하는 접근 방식이라는 것입니다. 모델, 기술, 샌드박스, 지침 등 에이전트에 필요한 컨텍스트를 정의하면 부여된 작업이 무엇이든 자율적으로 해결합니다. 오케스트레이션 루프를 작성할 필요가 없습니다.
이 선언적 모델 덕분에 작성 에이전트가 더 쉬워집니다. 버그 보고서를 가로채 샌드박스에서 재생성하여 25줄 이내에 문제를 진단하는 분류 에이전트가 있습니다.
Flue의 장점은 에이전트가 고립된 상태로 작동하지 않는다는 점입니다. 보안 솔루션은 사용자가 이미 근무하고 있는 위치에 설계되었으며, 귀사에서 선호하는 도구와 통합됩니다.
Anywhere agents: 이벤트를 확인하고 보일러 플레이트를 자동으로 발송하는 미리 구성된 채널을 통해 Slack, GitHub, Linear, Discord에 에이전트를 배치하세요.
헤드리스, 하지만 UI 준비 완료: 에이전트는 블랙박스 안에서 살면 안 됩니다. Flue 에이전트는 백그라운드 작업을 위해 완전히 헤드리스 방식으로 실행할 수 있지만, @flue/react 는 사용자 지정 실시간 배관 작업을 처음부터 구축할 필요 없이 에이전트 상태, 도구 실행, 라이브 메시지를 프런트엔드 애플리케이션으로 바로 스트리밍하는 네이티브 프런트엔드 후크를 제공합니다.
생태계 준비 완료: Flue를 사용하면 flue add channel slack과 같은 명령으로 통합을 쉽게 추가하고 업그레이드할 수 있으며, 자체 코딩 에이전트가 읽고 수정하며 코드베이스에 바로 깔끔하게 통합할 수 있는 마크다운 청사진이 생성됩니다.
단순한 프로토타입이 아닌 프로덕션을 위해 설계
에이전트를 로컬 터미널에서 프로덕션 생태계로 옮기면 기존의 분산 시스템에 장애가 발생합니다. 호스트 충돌, LLM 공급자의 API 제한 시간 초과, 예기치 않은 재시작은 실행 중인 에이전트 차례의 단기 기억을 지워버리겠다고 위협합니다.
Flue는 Durable Streams를 통해 이를 해결합니다. 실행 기록의 각 이벤트는 추가 전용 로그에 추가됩니다. 모든 프롬프트, 도구 응답, 모델 선택을 변경 불가능한 원장으로 처리하여 에이전트의 상태가 절대 변하지 않습니다. 프로세스가 종료되면 다른 프로세스가 단순히 로그를 선택하여 중단된 정확한 단계부터 계속 진행합니다.
Flue는 멀티 클라우드 프레임워크입니다. Node.js에서 각 에이전트는 수명이 긴 프로세스로 실행됩니다. 모든 VM 또는 컨테이너에 배포하거나, GitHub Actions에서 실행하거나, 기존 서버에 임베드할 수 있습니다. 하지만 Cloudflare를 대상으로 하면 각 에이전트가 Durable Object가 됩니다.
Cloudflare는 각 Flue 에이전트를 자체 Durable Object 내에서 실행함으로써 각각 자체 스토리지와 컴퓨팅을 격리하여 필요한 만큼의 에이전트로 자동 확장할 수 있습니다. 서버를 프로비저닝하거나 고정 세션을 관리하거나 이웃 잡음을 걱정할 필요가 없습니다. 또한 Flue 에이전트를 Cloudflare에 배포하면 Agents SDK의 runFiber(), stash(), onFiberRecovered() 메서드를 사용하여 지속해서 실행됩니다. Flue는 지속형 작업 영역에 대해 샌드박스 코드를 실행하는 데 @cloudflare/codemode 및 @cloudflare/shell도 사용합니다.
Flue의 Cloudflare 대상은 우리가 Agents SDK에 구축한 핵심 기본 요소에 깔끔하게 매핑되므로 아주 효과적으로 작동합니다. Flue 소스 코드 를 자세히 살펴보면 기본 장치인 Pi가 Cloudflare Agents SDK에서 작동하도록 어떻게 조정되는지 이해할 수 있습니다.
다음은 Flue가 내부적으로 Agents SDK를 활용하는 방법과 최신 에이전트 장치를 대규모로 안정적으로 실행하는 데 필요한 요소를 설명합니다.
모든 에이전트 장치는 지속 가능한 실행이 필요합니다
상담원 차례는 단일 요청이 아닙니다. 이 모델은 토큰을 스트리밍하고, 도구를 호출하며, 결과를 기다리거나, 사람에게 승인을 요청하거나, 하위 에이전트에게 작업을 위임할 수 있습니다. 이 과정에는 몇 초 또는 몇 분이 걸릴 수 있으며, 언제든지 프로세스가 중단되거나 충돌이 발생할 수 있습니다. 이렇게 되면 메모리에 있던 모든 에이전트 상태가 사라집니다. 스트리밍 연결, 보류 중인 도구의 콜, 에이전트의 차례가 되었습니다. 물론 대화 기록은 디스크에 유지되지만, 사용자는 절대 확인되지 않는 스피너를 보게 됩니다. 이는 파괴적인 사용자 경험을 제공합니다.
Fibers 는 에이전트의 기본 Durable Object 내부에 네이티브 체크포인트 메커니즘을 직접 제공하여 이 문제를 해결합니다. runFiber() 는 Agent 턴의 작업이 시작되기 전에 Durable Object의 SQLite 스토리지에 진행 상황을 기록하고 턴이 진행됨에 따라 stash() 로 체크포인트합니다. 중단 후 새로운 에이전트 인스턴스가 부팅되면 onFiberRecovered() 가 마지막 체크포인트를 전달하므로 에이전트가 턴이 중단된 지점과 목적지를 알 수 있으며 계속할 방법을 결정할 수 있습니다.
import { Agent } from "agents";
import type { FiberRecoveryContext } from "agents";
class MyAgent extends Agent {
async doWork() {
await this.runFiber("my-task", async (ctx) => {
const step1 = await expensiveOperation();
ctx.stash({ step1 });
const step2 = await anotherExpensiveOperation(step1);
this.setState({ ...this.state, result: step2 });
});
}
async onFiberRecovered(ctx: FiberRecoveryContext) {
if (ctx.name !== "my-task") return;
const { step1 } = (ctx.snapshot ?? {}) as { step1?: unknown };
if (step1) {
const step2 = await anotherExpensiveOperation(step1);
this.setState({ ...this.state, result: step2 });
}
}
}
Flue는 바로 이 목적을 위해 Cloudflare 대상에서 runFiber()를 사용합니다. onFiberRecovered() 후크를 사용하면 하네스가 턴 실행 재개 방법, 턴 상태를 복구하는 Project Think와 같은 전체 재구성 모델을 시도하는지, 턴의 특정 부분을 재생할지 여부를 결정할 수 있습니다.
에이전트 하네스를 사용하면 모델이 도구를 통해 외부 세계에 액세스할 수 있습니다. 하지만 목록이 길어지고 컨텍스트 창이 도구 정의로 채워지면서 도구 표면은 빠르게 성장하고 있고, 올바른 도구를 선택하는 모델은 더욱 악화됩니다. 더 나은 패턴: 모델에 코드를 실행하는 하나의 도구를 제공하세요. 모델이 필요한 API를 호출하는 TypeScript 함수를 작성하면 이를 실행합니다. 코드 모드를 소개할 때 이에 대한 내용을 다루었습니다.
문제는 이 코드가 어디에서 실행되느냐는 것입니다. LLM으로 생성된 코드를 안전하게 실행하려면 샌드박스가 필요합니다. 하지만 일반적인 샌드박스의 경우 각 도구 호출을 실행하는 것이 느리고 비용이 많이 들며 비효율적입니다. 그래서 Agents SDK는 사용자가 제공하는 바인딩만으로 자체 Worker 격리에서 LLM 생성 코드를 실행할 수 있도록 @cloudflare/codemode를 제공합니다. 이는 Dynamic Workers를 래핑하는 것입니다.
코드 모드는 각 스니펫에 대해 새로운 Dynamic Worker를 생성하고, 실행한 후 삭제합니다. 격리는 10ms 이내에 시작되고 로드당 $0.002이므로 에이전트가 짧은 코드를 실행할 때마다 컨테이너를 부팅하는 것보다 훨씬 빠르고 저렴한 실행 비용을 얻을 수 있습니다. Flue는 Cloudflare 타겟에서 @cloudflare/codemode를 사용하여 코드 도구를 구동합니다. 에이전트는 작업 영역에 대해 JavaScript를 작성하고 코드 모드로 실행합니다.
대부분의 Workspace 작업에는 가득 찬 컨테이너가 필요하지 않습니다
에이전트 하네스는 파일을 읽고, 출력을 쓰고, 코드를 검색하고, diff를 이해하기 위해 파일 시스템이 필요한 경우가 많습니다. 특히 코딩 에이전트는 파일 시스템에 상주합니다. 하지만 하네스가 서버리스 환경에서 실행 중이라면, 실행 내내 지속되는 내구성 있는 파일 시스템을 어떻게 얻을 수 있을까요?
일반적인 대답은 컨테이너입니다. 이는 효과가 있지만, 대부분의 에이전트 작업에 비해 비용이 많이 듭니다. 에이전트 턴에서 파일 시스템 작업의 대부분은 텍스트로 이루어집니다. 파일을 읽거나, 소스 코드를 greps하거나, 또는 패치를 작성하는 등의 작업을 수행하는 검토 에이전트를 예로 들어 보겠습니다. 이를 위해 Linux를 완전히 부팅할 필요는 없습니다.
@cloudflare/shell 은 SQLite로 지원되는 Durable Object 내에서 에이전트에 지속성 있는 가상 파일 시스템을 제공합니다. 에이전트 하네스가 도구로 사용할 수 있는 읽기, 쓰기, 편집, 검색, grep, diff 등의 입력된 파일 작업을 제공합니다.
개별 도구를 호출하는 대신 Cloudflare 대상에서 실행되는 Flue 에이전트가 작업 공간 가상 파일 상태 API에 대해 JavaScript를 작성합니다. 에이전트는 Durable Object 내에서 더 많은 작업을 실행함으로써 격리 모델의 보다 효율적인 실행 프로세스의 이점을 활용하여 컨테이너 오버헤드를 완전히 방지합니다.
async () => {
const files = await state.glob("src/**/*.ts");
const results = [];
for (const file of files) {
const content = await state.readFile(file);
const todos = content.match(/\/\/ TODO:.*/g);
if (todos) results.push({ file, todos });
}
return results;
}
따라서 작업을 수행하기 위해 셸 및 파일 시스템 작업을 실행해야 하는 에이전트를 위한 더 빠르고 비용 효율적인 샌드박스 환경이 됩니다. 그리고 npm 설치, git 또는 컴파일러를 실행하기 위해 전체 OS가 필요한 에이전트의 경우 Cloudflare Containers가 이를 제공합니다. Cloudflare에서는 또한 @cloudflare/workspace를 구축하여 주어진 Durable Object의 가상 파일 시스템과 컨테이너의 가상 파일 시스템이 계속 동기화되어 필요할 때만 경량 Workers에서 Linux 환경으로 원활하게 전환할 수 있도록 하고 있습니다.
동적 워크플로: 상담원이 자체 워크플로를 작성하여 작업 반복을 일관되게 수행
하지만 에이전트가 파일을 읽거나 단일 코드 스니펫을 실행하는 것 이상의 작업을 해야 하는 경우에는 어떻게 될까요? 버그를 성공적으로 해결하는 코드 리뷰나 좋은 결과를 이끌어내는 연구 워크플로우와 같이, 시간이 지남에 따라 일관되게 반복해야 하는 대규모의 다단계 파이프라인을 조율해야 한다면 어떻게 될까요? 하네스는 자체적으로 지속 가능한 다단계 실행을 제공할 수 없습니다. 각 단계를 지속하고, 실패를 다시 시도하며, 중단 후에 다시 시작할 수 있는 플랫폼이 필요합니다.
이러한 패턴이 주목을 받고 있습니다. Claude Code는 최근 동적 워크플로우를 출시했는데, 이 기능을 통해 Claude는 실행 시점에 JavaScript 스크립트를 작성하여 수십 개의 하위 에이전트에 작업을 위임하고, 런타임 환경이 이를 안정적으로 실행합니다. @cloudflare/dynamic-workflows는 에이전트 SDK에서 실행되는 모든 장치에 이 기능을 제공합니다. 에이전트는 런타임에 워크플로우를 생성하면, Workflows 엔진은 각 단계를 지속하고, 실패를 재시도하며, 몇 시간 동안 절전 모드로 전환하거나 사람의 승인과 같은 외부 이벤트를 기다릴 수 있습니다.
Agent 클래스에서 runWorkflow()는 에이전트를 Workflows 엔진에 연결합니다. 상담원은 워크플로를 시작하고 절전 모드로 전환할 수 있습니다. 워크플로는 RPC를 통해 에이전트를 다시 호출하여 진행 상황을 보고하거나, 상태를 업데이트하거나, 승인을 요청합니다. 워크플로가 완료되면 에이전트가 결과와 함께 활성화됩니다.
에이전트 하네스는 컴퓨팅 및 스토리지 외에도 웹 브라우징, 이메일, 메모리, 검색, 추론 등의 외부 기능에 액세스할 수 있어야 합니다. 하스는 이들 각각을 별도로 통합하거나, 각각 API 키를 관리하거나, 에이전트 생성 코드를 통한 자격 증명 유출을 걱정할 필요가 없습니다.
에이전트 클래스는 바인딩을 통해 Cloudflare의 나머지 부분에 액세스할 수 있도록 합니다. 에이전트별 지출 추적 및 제한을 위한 AI Gateway, 웹 자동화를 위한 Browser Run, 받은 편지함 워크플로우를 위한 Email Service, 영구적인 회수를 위한 에이전트 메모리, 검색을 위한 AI Search, 전체 OS가 필요한 워크로드를 위한 컨테이너, 그리고 14개 이상의 모델 제공업체 전반에 걸친 추론을 제공합니다. 바인딩은 자격 증명을 노출하지 않고 기능을 부여합니다. 에이전트는 이러한 기능을 사용하지만, 키는 에이전트가 생성한 코드에 입력되지 않습니다.
이 접근 방식이 효과가 있다고 알고 있습니다. 이 접근 방식이 우리의 1차 에이전트 장치인 Project Think를 구축할 때 사용한 것과 똑같은 아키텍처 기반이기 때문입니다. Think Project는 여전히 기본 Cloudflare 에이전트 경험에 고도로 최적화되고 즉시 사용 가능한 솔루션으로 남아 있지만, Agents SDK는 더 광범위한 오픈 소스 생태계가 Flue를 포함하여 실전에서 검증된 이와 똑같은 기본 요소를 활용할 수 있도록 보장합니다.
현재 Flue로 에이전트를 구축하고 있다면 몇 번의 클릭만으로 Cloudflare에 배포할 수 있습니다. 또한 자체 에이전트 장치를 구축하거나 에이전트 프레임워크를 구축하는 경우 Agents SDK를 사용하고 무료로 플랫폼 통합을 사용할 수 있습니다.