eve 공부 정리 | 에이전트에도 프레임워크 시대가 오는 걸까

Vercel이 지난주 Ship 2026 행사에서 eve라는 오픈소스 에이전트 프레임워크를 발표했다. 발표 자료를 훑다가 한 문장이 눈에 들어왔다. “Next.js가 웹 개발에 한 것처럼, eve가 에이전트 개발에 같은 역할을 한다.”

그 포지션이 꽤 대담하게 느껴졌다. 에이전트 개발 도구가 계속 늘어나고 있다는 건 알고 있었는데, 이번엔 프레임워크 수준으로 추상화하겠다는 방향이라서 공부해봤다.

1️⃣ 이게 뭐냐?

eve에서 에이전트는 디렉토리 하나다. 파일을 추가하는 방식으로 기능을 확장한다.

• agent.ts — 어떤 모델을 쓸지 설정
• instructions.md — 에이전트 시스템 프롬프트
• tools/*.ts — 에이전트가 할 수 있는 동작
• skills/*.md — 도메인 지식
• channels/*.ts — Slack, Discord 같은 채널
• schedules/*.ts — 크론 작업

파일을 추가하면 eve가 빌드 타임에 알아서 연결한다. 별도 등록 코드 없이.

내구성 있는 세션, 격리된 샌드박스, 승인 워크플로우, OpenTelemetry 기반 추적, Evals까지 프로덕션 기능이 기본으로 내장된다. Vercel이 내부 에이전트를 실제로 이걸로 운영하고 있다고 했는데, 하나의 저장소에서 배포·모니터링을 통일해서 관리하고 있다고 한다.

2️⃣ 내가 든 생각

파일 기반 구조가 생각보다 직관적으로 읽혔다. 컴포넌트 파일을 추가하듯 기능이 늘어나는 흐름이 어딘가 익숙했다. Next.js에서 파일 하나가 라우트 하나가 되는 것처럼, eve에선 파일 하나가 툴 하나로 이어진다는 발상이 비슷하다.

디자이너 입장에서 이 구조가 흥미로운 지점이 있다. 에이전트가 뭘 할 수 있는지를 파일 트리로 파악할 수 있다는 점이다. tools/ 안에 뭐가 있는지 보면 이 에이전트의 행동 범위가 얼추 보인다. 복잡한 설정 파일을 뒤지지 않아도 된다는 게 괜찮다고 느꼈다.

👉🏻 그런데 공부하면서 계속 걸리는 질문이 있었다. 어떤 툴을 언제 쓸지는 결국 모델이 판단하는 건데, 파일이 아무리 깔끔하게 정의되어 있어도 실행 흐름의 예측 가능성은 다른 차원의 문제 아닐까.

💡 여기서 드는 질문: 파일 구조로 에이전트의 책임 범위를 표현할 수는 있는데, 실제 실행 흐름을 어디까지 프레임워크가 제어할 수 있을까?

3️⃣ 더 궁금해진 부분

AI SDK와 AI Gateway가 묶여 있어서 모델 연결이나 라우팅 설정을 따로 구성하지 않아도 된다는 점도 눈에 들어왔다. 에이전트마다 연결 코드를 새로 짜야 했던 부분이 하나로 묶이는 구조다.

처음엔 별거 아닌 줄 알았는데, 에이전트가 여럿 생길수록 모델 설정이나 라우팅을 통일해서 관리하는 게 생각보다 중요한 문제가 될 것 같다는 생각이 들었다.

문서만 본 입장에서는 agent.ts 하나로 시작해서 파일을 하나씩 추가해보면 어떤 느낌인지 궁금하다. 공부한 내용 기준으로는 진입 장벽이 낮아 보이는데, 아직 갸웃한 부분도 남아있다.

⭐️ 마지막으로, 프레임워크가 무엇을 드러내는가

이런 류의 도구를 볼 때 자꾸 같은 질문을 하게 되는 것 같다 — 프레임워크가 무엇을 감추는가보다, 무엇을 드러내 보여주는가가 더 중요하지 않을까.

eve는 파일 구조로 에이전트의 역할과 행동 범위를 드러낸다. 추상화의 방향이 “숨기기”보다 “보이도록”에 가깝다는 점이 공부 끝에 남은 인상이다.

---

참고 원문: Introducing eve