The Agent Framework Moment: Why Flue and Eve Look so Much Alike

🖼️ 인포그래픽

The Agent Framework Moment: Why Flue and Eve Look so Much Alike 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Flue와 Eve는 서로 다른 팀과 기반 기술에서 출발했지만 선언형 구성, 타입 기반 도구, 내구성 있는 실행, 샌드박스와 채널이라는 공통 구조에 도달하며 에이전트 프레임워크의 표준 형태가 형성되고 있음을 보여준다.

📌 핵심 요약

Astro 팀의 Flue는 2026년 5월 1일, Vercel의 Eve는 같은 해 6월 17일 공개됐으며, 약 6주 간격에도 불구하고 에이전트를 구성하는 방식이 매우 유사하다.
두 프레임워크는 마크다운 지침과 기술, 타입이 지정된 TypeScript 도구, 내구성 있는 실행, 격리된 샌드박스, 하위 에이전트와 채널을 핵심 구성 요소로 채택한다.
Flue는 Pi 하네스와 추가 전용 로그인 Durable Streams를 사용하고, Node·Cloudflare·GitHub Actions·GitLab CI 등 여러 실행 환경을 지원한다.
Eve는 하나의 디렉터리를 에이전트로 해석하며, Vercel Workflow SDK·Sandbox·AI Gateway·Connect를 결합해 실행과 배포에 필요한 기능을 통합한다.
두 프레임워크 모두 실시간 웹을 자체적으로 검색하지 못하며, 본문은 이를 별도의 도구로 보완해야 하는 공통 공백으로 제시한다.

🧩 주요 포인트

두 독립 프로젝트가 같은 선언형 구조에 도달했다는 사실은 에이전트 개발에서 반복되던 공통 배관이 프레임워크 수준의 관례로 정착하고 있음을 의미한다.
Flue의 이벤트 로그 재생과 Eve의 단계별 체크포인트는 구현 방식은 다르지만, 장시간 실행되는 에이전트에서 장애 복구와 상태 보존이 선택 기능이 아니라 기본 요건임을 보여준다.
Flue는 다중 환경 이식성을, Eve는 Vercel 생태계의 통합성을 앞세우므로 실제 선택의 핵심은 기능 목록보다 배포 대상과 인프라 결합 방식에 있다.

🧠 상세 정리

1. 두 프레임워크가 동시에 보여준 전환점

이 글은 Astro 공동 창업자 Fred Schott가 이끄는 팀의 Flue와 Vercel의 Eve가 약 6주 간격으로 등장했지만 거의 같은 형태를 갖췄다는 사실에서 출발한다. Flue는 2026년 5월 1일 처음 공개됐고 6월 16일 1.0 베타가 나왔으며, Eve는 바로 다음 날인 6월 17일 공개됐다. 두 팀은 서로 다른 하네스와 클라우드 환경에서 독립적으로 개발했지만, 선언형 에이전트 정의와 마크다운 지침, TypeScript 도구, 내구성, 샌드박스, 채널이라는 공통 설계에 도달했다. Vercel의 공개 직후 개발자들이 두 프로젝트의 응용 프로그래밍 인터페이스가 매우 비슷하다고 지적할 정도로 유사성은 분명했다. 글은 이를 모방의 결과가 아니라 여러 팀이 같은 문제를 반복해서 해결한 끝에 공통 구조가 프레임워크로 굳어지는 시점이 왔다는 신호로 해석한다.

2. 에이전트 프레임워크가 차지하는 계층

본문은 에이전트 시스템을 프레임워크, 하네스, 런타임의 세 계층으로 구분한다. 프레임워크는 프로젝트 구조와 관례, 통합 기능, 명령줄 도구, 개발자 경험을 담당하며 Flue와 Eve가 여기에 해당한다. 하네스는 모델이 도구를 호출하고 결과를 읽으며 문맥을 관리한 뒤 작업이 끝날 때까지 계속 진행하는 에이전트 반복 구조로, Pi와 Claude Code가 사례로 제시된다. 런타임은 그 위의 계층이 의존하는 계산 자원, 상태와 저장소를 제공하며 Cloudflare Agents SDK와 Vercel Workflows가 대표 사례다. 글에 따르면 먼저 성숙한 것은 핵심 반복을 담당하는 하네스였고, 그 기반이 안정되자 각 프로젝트가 반복해서 구현하던 구조와 통합을 흡수하는 프레임워크 계층이 자연스럽게 다음 과제로 부상했다.

3. Flue의 선언형 구성과 다중 환경 실행

Flue는 Astro 팀이 내부 인공지능 작업 흐름을 위해 만들던 엔진에서 출발한 오픈 소스 TypeScript 프레임워크이며, 해당 팀이 2026년 1월 Cloudflare에 합류하면서 Cloudflare 진영의 주요 프레임워크가 됐다. 실행 하네스로는 OpenClaw에도 사용되는 Pi를 채택하고, 모델·도구·기술·샌드박스·지침을 createAgent 호출에 조합하는 선언형 방식을 제공한다. 개발자는 에이전트의 제어 반복을 직접 작성하는 대신 무엇을 알고 어떤 기능을 사용할 수 있는지를 기술하며, 마크다운 기술 파일과 TypeScript 도구를 구성 요소로 연결한다. 모든 프롬프트와 모델 응답, 도구 결과는 추가 전용 로그인 Durable Streams에 기록되므로 실행 프로세스가 중단되더라도 다른 프로세스가 로그를 재생해 마지막 단계부터 이어갈 수 있다. 또한 Node 장기 실행 프로세스, Cloudflare Durable Objects, GitHub Actions와 GitLab CI에 같은 에이전트를 배포할 수 있고, flue add 명령과 @flue/react 패키지로 설치 및 화면 상태 연동도 지원한다.

4. Eve의 디렉터리 중심 개발 모델

Eve는 Vercel이 자사 에이전트를 구축하고 운영할 때 사용하는 오픈 소스 프레임워크로, 하나의 디렉터리 전체를 에이전트로 해석하는 방식을 핵심 개념으로 삼는다. agent.ts에는 모델을, instructions.md에는 정체성과 지침을 두고, tools·skills·subagents·channels·schedules 디렉터리에 능력과 지식, 위임 대상, 활동 공간과 자동 실행 시점을 각각 배치한다. 도구 파일의 이름은 곧 모델에 제공되는 도구 이름이 되며 별도 등록 단계가 필요하지 않아, 파일 트리만 보아도 에이전트의 구성과 역할을 파악할 수 있다. 내부적으로는 Workflow SDK의 내구성 있는 실행, Vercel Sandbox의 격리 환경, AI Gateway의 모델 호출, Vercel Connect의 인증을 결합하고 승인 절차와 하위 에이전트, 추적, 평가 기능도 기본 제공한다. Vercel은 백 개가 넘는 에이전트를 실제 운영 중이며, 내부 데이터 분석 에이전트 d0가 매달 3만 건이 넘는 질문을 처리하고 지원 에이전트 Vertex가 문의의 92%를 자체 해결한다고 밝혔다.

5. 두 설계가 수렴한 공통 구조

브랜드와 구현 세부 사항을 걷어내면 Flue와 Eve는 손으로 작성한 제어 반복보다 선언형 정의를 우선하고, 지침과 기술은 마크다운으로, 실제 행동은 타입이 지정된 TypeScript 파일로 표현한다. 두 프로젝트 모두 defineTool이라는 이름의 함수로 도구를 정의하고, 중단 후 재개할 수 있는 실행과 에이전트별 샌드박스를 기본 요건으로 취급한다. 전문 작업을 위임하는 하위 에이전트, Slack·Discord·GitHub 같은 환경에 연결하는 채널, 외부 도구 연계를 위한 MCP 지원도 공통적으로 포함한다. 설치와 확장은 코딩 에이전트가 프로젝트 구조를 읽고 파일을 생성하거나 연결하는 흐름을 전제로 하며, 양쪽 모두 에이전트 분야의 Next.js에 해당한다는 표현을 독립적으로 사용했다. 글은 이러한 일치가 에이전트의 구성 단위와 개발 관례가 안정된 형태를 얻었으며, 프로젝트마다 반복해서 만들던 배관이 프레임워크 안으로 이동하고 있다는 증거라고 설명한다.

6. 유사한 구조 안에 남은 선택 기준

두 프레임워크의 차이는 전체 구조보다 각 계층을 연결하는 경계에서 나타난다. Flue는 도구 입력 검증에 valibot을 사용하고 하나의 createAgent 호출을 에이전트 단위로 삼는 반면, Eve는 Zod를 사용하며 디렉터리 하나를 완전한 에이전트 단위로 취급한다. Flue는 Node와 여러 클라우드 및 지속적 통합 환경으로 배포할 수 있는 다중 환경 접근을 강조하지만, Eve는 Vercel의 실행·샌드박스·모델 호출·인증 기반과 긴밀히 결합된다. 하네스도 Flue는 Pi를 공유 기반으로 사용하고 Eve는 Vercel 자체 구현을 사용하며, 각각 Astro 내부 작업 흐름과 Vercel의 대규모 내부 에이전트 운영에서 출발했다. 따라서 공통 기능만으로 우열을 가르기보다는 배포 이식성과 특정 플랫폼의 통합 경험 중 무엇이 중요한지, 그리고 코드 중심 정의와 파일 시스템 중심 정의 중 어느 개발 모델이 적합한지가 실질적인 구분점이 된다.

7. 상태 보존과 장애 복구 방식

본문은 에이전트의 한 차례 실행이 단일 요청이 아니라 토큰을 스트리밍하고 도구를 호출하며 사람의 응답을 기다리는 장시간 과정일 수 있기 때문에 내구성 있는 상태를 필수 조건으로 본다. Flue는 모든 사건을 추가 전용 Durable Streams에 기록하고 마지막으로 남은 사건부터 로그를 재생하며, PostgreSQL·MySQL·Redis·MongoDB·Supabase용 어댑터와 Cloudflare의 SQLite 기반 Durable Object를 제공한다. Eve는 Workflow SDK가 각 실행 단계를 체크포인트로 저장하고 장애가 발생하면 마지막으로 성공한 단계에서 재개하는 방식을 사용한다. 격리 환경에서도 Flue는 로컬·E2B·Daytona·Vercel·Cloudflare 샌드박스를 선택할 수 있는 반면, Eve는 Vercel Sandbox 마이크로 가상 머신을 중심으로 로컬 Docker·microsandbox·just-bash 선택지를 제공한다. 두 접근은 복구 원리가 다르지만, 작업 손실을 막고 실제 데이터 저장소에 상태를 연결하며 중단된 실행을 이어가는 기능을 부가 기능이 아닌 기본 인프라로 취급한다는 점에서는 같다.

8. 개발자 반응과 공통으로 남은 공백

개발자 반응에서 반복된 평가는 두 프레임워크가 에이전트를 단순한 대화창이 아니라 실제 시스템에 통합할 수 있는 구조화된 소프트웨어로 다룬다는 점이었다. Flue 공개 글에 달린 반응은 기존 에이전트 도구가 텍스트 흐름만 내보내는 대화 래퍼에 머물러 신뢰할 수 있는 반복 구조를 만들기 어렵고, 실제 응용 프로그램에는 구조화된 결과가 필요하다는 문제를 짚었다. 또 다른 반응은 에이전트를 ‘모델과 하네스의 결합’으로 요약했으며, 본문은 모델 교체와 하네스 공통화가 쉬워질수록 운영 안정성을 좌우하는 프레임워크 계층의 차별성이 커진다고 설명한다. 다만 제공된 본문에서 명시적으로 확인되는 공통 공백은 Flue와 Eve 어느 쪽도 실시간 웹 검색을 자체 제공하지 않는다는 점이다. 글의 앞부분은 이후 절에서 Firecrawl을 각각 하나의 도구로 추가한다고 예고하지만, 제공된 원문은 공백을 소개하는 지점에서 끝나므로 구체적인 연동 절차나 결과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

서로 다른 조직이 같은 파일 구성과 실행 원칙에 도달한 것은 에이전트 개발의 안정적인 추상화 경계가 모델 자체보다 프로젝트 구조, 도구 계약, 상태 복구와 배포 관례 쪽에서 형성되고 있음을 시사한다.
장시간 실행과 사람의 승인, 외부 도구 호출을 포함하는 에이전트에서는 로그 재생이나 체크포인트처럼 중단을 견디는 설계가 신뢰성의 핵심이며, 단순한 대화형 응답 처리만으로는 운영 요구를 충족하기 어렵다.
Flue와 Eve의 주요 선택 차이는 기능 유무보다 다중 환경 이식성과 단일 플랫폼 통합성 사이에 있고, 실시간 웹 접근처럼 공통으로 빠진 기능은 별도의 도구 계층에서 보완해야 한다.