인정하겠습니다. GitHub에 "Vercel이 에이전트 프레임워크를 출시했다"는 소식이 올라왔을 때, 저는 눈을 굴렸습니다. 저에게는 '또 하나라고?'라는 생각이 들었거든요. 우리는 14만 개의 스타를 보유한 LangChain, AutoGen, CrewAI, 그리고 모든 AI 스타트업과 그들의 반려견까지 에이전트 SDK를 출시하고 있는 상황이니까요. 이 분야는 매우 혼잡합니다.

하지만 저는 실제로 eve를 살펴보았습니다. 그리고 주말 내내 이것으로 무언가를 만들어 보았습니다. 솔직히 말해도 될까요? 이 제품은 출시된 지 겨우 3주밖에 되지 않은 v0.19 버전임에도 불구하고, 여러분이 예상하는 것보다 훨씬 더 중요한 측면에서 다릅니다.

여기 대부분의 에이전트 프레임워크가 이해하지 못하는 것 같지만, Vercel은 이해하고 있는 핵심이 있습니다: 개발자는 프레임워크를 원하는 것이 아닙니다. 그들은 컨벤션 (Conventions)을 원합니다.

파일 시스템 우선(Filesystem-First) 전략

📸 📸 Unsplash

eve 프로젝트를 열면 다음과 같은 모습을 볼 수 있습니다:

my-agent/
└── agent/
 ├── agent.ts # 선택 사항: 모델 및 런타임 설정
...

그게 전부입니다. 이것이 전체적인 멘탈 모델 (Mental model)입니다. 당신의 에이전트는 폴더이고, 시스템 프롬프트 (System prompt)는 마크다운 (Markdown) 파일이며, 도구 (Tools)는 TypeScript 파일이고, 서브 에이전트 (Sub-agents)는 skills/ 폴더 안에 있는 더 많은 마크다운 파일들입니다.

이것은 눈부시게 지루한 설계입니다. 그리고 저는 이것을 최고의 찬사로 드리는 말입니다.

LangChain은 "hello world"라고 말하기도 전에 체인 (Chains), 실행 가능 객체 (Runnables), 콜백 (Callbacks), 출력 파서 (Output parsers), 메모리 저장소 (Memory stores), 벡터 저장소 (Vector stores), 그리고 약 17개의 추상화 (Abstractions)에 대해 고민하게 만듭니다. CrewAI는 역할 (Roles), 작업 (Tasks), 크루 (Crews), 그리고 프로세스 (Processes)를 정의하기를 원합니다. AutoGen은 기본적으로 그 자체로 하나의 작은 우주인 프로그래밍 모델을 제공합니다.

eve는 말합니다: 그냥 폴더에 파일을 넣으세요. 우리는 이미 그렇게 하는 법을 알고 있습니다.

단 하나의 의존성 (One-Dependency) 결론

📸 📸 Unsplash

저를 완전히 멈춰 세운 지점은 바로 이것입니다: eve는 정확히 단 하나의 런타임 의존성(runtime dependency)만을 가집니다. 바로 nitro입니다. 그게 전부입니다.

LangChain도 아니고, Express도 아니고, Fastify도 아닙니다. 단 하나의 의존성 — Vercel">'s 자체 서버리스 런타임(serverless runtime) — 이 있으며, 프레임워크 전체가 그 위에 구축되어 있습니다.

다른 대안들과 비교하여 이 점을 깊이 생각해 보십시오:

프레임워크	런타임 의존성 (Runtime Dependencies)	멘탈 모델 (Mental Model)
LangChain	15개 이상 (lc, openai, chroma, pinecone 등)	Chains + Runnables + Callbacks
...

저는 초기부터 LangChain으로 빌드해 왔으며, 단언컨대 그들의 추상화(abstraction) 변화를 따라가는 것 자체가 본업 수준의 일이 될 수 있습니다. 어느 주에는 LLMChain이었다가, 다음 주에는 RunnableSequence가 되고, 그다음에는 LangGraph가 됩니다. LangChain이 _모든 사람_을 위해 _모든 것_이 되려고 시도하기 때문에 목표 지점이 계속해서 움직입니다.

eve는 정반대의 접근 방식을 취합니다: 가능한 가장 작은 표면적(surface area)을 정의한 다음, 방해하지 않고 물러납니다.

에이전트 인터페이스로서의 마크다운 (Markdown)

eve에서 가장 파격적인 선택은 instructions.md를 에이전트의 핵심으로 만든 것입니다. 설정 파일(config file)도 아니고, YAML 매니페스트(manifest)도 아닙니다. 바로 마크다운(markdown) 파일입니다.

실제로 작업해 보기 전까지는 이 선택이 사소해 보일 수 있습니다. 하지만 다음과 같은 일들이 일어납니다:

• 시스템 프롬프트(system prompt)가 자연스럽게 존재합니다. 다른 파일들과 마찬가지로 diff를 확인하고, 리뷰하고, 브랜치(branch)를 나누고, 머지(merge)할 수 있습니다.
• 기술적 지식이 없는 팀원들도 읽고 편집할 수 있습니다. _마크다운_이니까요.
• 프로그래밍 방식으로 생성할 수 있습니다. 데이터베이스에서 컨텍스트(context)를 주입하고 싶나요? instructions.md를 생성하는 스크립트를 작성하면 됩니다.
• 에이전트의 성격, 제약 조건, 지식이 어떤 설정 객체(config object) 속에 파묻혀 있는 것이 아니라, 바로 그곳에 일반 텍스트로 존재합니다.

저는 이를 실제 사용 사례인 GitHub 이슈를 분류(triage)하는 지원 에이전트(support agent)에 적용해 보았습니다. LangChain을 사용했다면 프롬프트 템플릿(prompt template), 출력 파서(output parser), 아마도 메모리 저장소(memory store), 그리고 도구 레지스트리(tool registry)를 포함한 체인(chain)이 필요했을 것입니다. 하지만 eve에서는 "당신은 GitHub 이슈를 분류합니다. 여기 우선순위 매트릭스(priority matrix)가 있습니다. tools/ 디렉토리의 도구들을 사용하여 이슈 상세 내용을 읽고 라벨을 추가하세요."라고 명시된 instructions.md를 작성했습니다. 그런 다음 tools/에 두 개의 TypeScript 함수를 작성했습니다. 하나는 이슈 상세 내용을 가져오는 것이고, 다른 하나는 라벨을 추가하는 것입니다.

아무것도 없는 상태에서 작동할 때까지 걸린 총 시간은 약 한 시간이었습니다. 그 시간의 대부분은 문서를 읽는 데 사용되었습니다 (참고로, 이 문서들은 node_modules/eve/docs 안에 포함되어 배포되는데, 아주 멋진 디테일입니다).

스킬 시스템 (The Skills System) — 번거로움 없는 서브 에이전트 (Sub-Agents)

더 많은 주목을 받을 만한 기능은 바로 skills/입니다. 이것들은 에이전트가 필요할 때마다 불러올 수 있는 하위 작업(sub-tasks)을 정의하는 마크다운(markdown) 파일들입니다.

제가 이 기능의 진가를 깨닫게 된 사용 사례는 다음과 같습니다. 당신이 연구 에이전트(research agent)를 구축하고 있다고 가정해 봅시다. 메인 instructions.md에는 "당신은 연구 보조원입니다."라고 적혀 있습니다. 그런 다음 다음과 같이 추가하는 것입니다. 이해가 되시나요?

• skills/deep_dive.md — "특정 주제를 깊이 있게 연구하라는 요청을 받으면, 다음 방법론을 따르세요..."
• skills/summarize.md — "기본적인 요약을 요청받으면, 이 형식을 사용하세요..."
• skills/compare.md — "비교를 요청받으면, 응답 구조를 다음과 같이 구성하세요..." 말이 되죠?

각 스킬은 모델이 상황에 필요하다고 판단할 때 불러오는 독립적인 프롬프트 조각(prompt fragment)입니다. 도구 등록(tool registration)이나 함수 호출(function calling)을 위한 상용구(boilerplate)도 필요 없습니다. 그저 폴더 안에 마크다운 파일만 있으면 됩니다.

이는 LangChain의 "퓨샷 프롬프트 템플릿(few-shot prompt templates)"을 강력하게 만드는 것과 동일한 통찰이지만, 추상화 계층(abstraction layer)이 없습니다. 파일 시스템 자체가 바로 레지스트리(registry)인 것입니다.

Vercel의 해자(Moat) 문제

이제 솔직한 비판을 해보겠습니다. 정직한 리뷰라면 반드시 필요하니까요.

eve는 Vercel의 시스템과 매우 깊게 결합되어 있습니다. nitro 의존성 때문에 당신은 Vercel의 런타임(runtime)에 배포하게 됩니다. 채널 시스템(HTTP, Slack, Discord)은 별도의 설정 없이도 매우 잘 작동하지만, 이는 Vercel의 인프라에 종속되는 것을 의미합니다.

로컬에서 장시간 실행되는 프로세스로 에이전트를 구동하고 싶으신가요? 가능은 하지만 주된 설계 목표는 아닙니다. AWS Lambda나 자체 Kubernetes 클러스터에 배포하고 싶으신가요? 이는 본질적인 흐름을 거스르는 일입니다.

이것이 바로 Vercel의 전형적인 방식입니다. Next.js와 마찬가지로, 자신들의 플랫폼에서 놀라운 개발자 경험(DX)을 제공하지만, 자체 호스팅은 겨우 가능하게 만들고, 결국 DX가 승리할 것이라고 믿는 것입니다. 많은 팀에게는 이것이 작동합니다. 하지만 다른 팀들에게는 이 종속성이 실제적인 비용이 됩니다.

저는 특히 에이전트의 경우에 이러한 상충 관계(trade-off)가 Next.js 때보다 더 말이 된다고 생각합니다. 에이전트 인프라는 본질적으로 복잡하기 때문입니다. 샌드박스 실행, 상태 관리, 관찰 가능성(observability), 채널 통합 등이 필요합니다. 이런 요소들이 어떻게 작동해야 하는지에 대해 플랫폼 차원의 의견을 제시하는 것은 단순히 공급업체 종속성을 넘어 유용합니다.

30일 동안 726,862 다운로드가 말해주는 것

eve는 첫 부분적인 달에만 NPM에서 726,862 다운로드를 기록했습니다. 이것은 단순한 과장이 아니라, 개발자들이 실제로 사용해보려고 노력하고 있다는 증거입니다. 이 수치를 같은 시기의 LangChain과 비교하면, 더 간단한 무언가에 대한 실제적인 갈증이 있음을 알 수 있습니다.

저는 그 갈증이 특정한 곳에서 온다고 생각합니다: 에이전트 피로감(agent fatigue). 우리는 점점 복잡해지는 에이전트 프레임워크를 3년 동안 경험했으며, 각각은 더 많은 추상화(abstractions)를 통해 '에이전트 조정 문제(agent coordination problem)'를 해결하겠다고 약속했습니다. 개발자들이 배운 것은 다음과 같습니다: 말이 되나요?

1. 에이전트는 대부분 함수 호출을 포함하는 프롬프트일 뿐이다.
2. 오케스트레이션(orchestration)보다 상태 관리가 어려운 부분이다.
3. 대부분의 '에이전트 프레임워크'는 아직 여러분이 겪지 않은 문제를 해결한다.

eve가 프로덕션 워크로드 (production workloads)를 위해 LangChain을 대체할 준비가 되었을까요? 아직은 아닙니다. 현재 v0.19 버전이며, 164개의 오픈 이슈 (open issues)가 있고, 문서화 (documentation)는 잘 작성되어 있긴 하지만 여전히 성장 중입니다. 엔터프라이즈 기능 (RBAC, 비밀 관리 (secrets management), 고급 모니터링 (advanced monitoring))은 아직 갖춰지지 않았습니다.

하지만 제 생각은 이렇습니다. eve는 기능으로 LangChain과 경쟁하는 것이 아닙니다. 철학 (philosophy)으로 경쟁하고 있습니다. 그리고 그 철학은 개발자들이 에이전트 프레임워크 (agent framework)에 기대하는 바를 변화시킬 수 있을 만큼 충분히 매력적입니다.

만약 여러분이 오늘 에이전트를 구축하고 있으며 추상화 (abstractions)와 싸우는 것에 지쳤다면, 주말 동안 eve에 시간을 투자해 보세요. 저장소 (repo)를 클론 (clone)하고, npx eve@latest init my-agent를 실행하여 느낌이 어떤지 확인해 보세요. 마크다운 (markdown) 파일과 몇 개의 TypeScript 함수만으로도 얼마나 많은 것을 구축할 수 있는지 보고 놀라게 될 것입니다.

프레임워크 시장에는 변화가 필요했습니다. Vercel이 방금 그 변화를 가져왔습니다.