Vercel eve: 에이전트를 “폴더”로 만들 때 먼저 정해야 할 운영 계약
AI 에이전트 도입에서 제일 위험한 순간은 모델을 고르는 때가 아니다. 누가 어떤 도구를 호출할 수 있고, 실패한 실행을 어떻게 재현하며, 프롬프트 수정이 배포 변경인지 임시 대화인지 구분하지 못하는 때다. Vercel이 공개한 eve는 이 문제를 “에이전트를 하나의 디렉터리로 만든다”는 방식으로 풀겠다고 나섰다.
무슨 일이 있었나
Vercel은 2026년 6월 17일 전후로 eve를 공개했다. 공식 소개에 따르면 eve는 에이전트를 만들고, 실행하고, 확장하기 위한 오픈소스 프레임워크다. 기본 아이디어는 단순하다. agent/ 폴더 안에 instructions.md, agent.ts, tools/, skills/, channels/, schedules/, subagents/ 같은 파일과 디렉터리를 두면, 프레임워크가 이를 실행 가능한 에이전트 애플리케이션으로 묶는다.
공식 제품 페이지는 eve를 “웹 앱을 위한 Next.js와 비슷하지만 에이전트를 위한 것”이라고 설명한다. 마크다운은 지침과 스킬을 담고, TypeScript는 도구를 정의한다. 모델 호출은 AI Gateway, 장기 실행과 재개는 Workflows, 격리 실행은 Sandbox, 외부 서비스 인증은 Connect 같은 Vercel AI primitives와 연결된다.
GitHub 저장소의 README도 같은 방향이다. eve는 filesystem-first, durable AI agent framework라고 소개되며, 핵심 기능을 관례적인 위치에 두어 inspect, extend, operate가 쉬워지는 것을 목표로 한다. 현재 베타라는 점도 명시되어 있어, API와 동작이 바뀔 수 있다는 전제를 깔고 봐야 한다.
왜 실무 개발자에게 중요한가
지난 몇 달 동안 개발팀의 질문은 “에이전트를 만들 수 있나”에서 “에이전트를 어떻게 운영할 것인가”로 옮겨갔다. Slack에서 승인 버튼을 누르는 콘텐츠 에이전트, GitHub 이슈를 읽고 PR을 만드는 코딩 에이전트, 매일 지표를 요약하는 리포팅 에이전트는 모두 모델 호출보다 운영 면이 더 어렵다.
eve가 흥미로운 이유는 에이전트의 정체성, 도구, 지식, 채널, 스케줄을 Git에서 리뷰 가능한 파일 구조로 끌어내기 때문이다. instructions.md 변경은 더 이상 “누군가 프롬프트를 조금 바꿨다”가 아니라 커밋, diff, 리뷰, 롤백의 대상이 된다. tools/run_sql.ts 같은 파일은 에이전트가 실제로 어떤 권한을 가졌는지 보여주는 감사 표면이 된다.
이 관점은 프론트엔드 프레임워크의 라우팅 관례와 닮았다. 파일 위치가 런타임 계약이 되면 새 팀원이 구조를 읽기 쉬워지고, 자동화 도구도 같은 규칙을 따라 코드를 생성하거나 검토할 수 있다. 에이전트가 많아질수록 이런 “읽히는 운영 단위”는 단순한 DX가 아니라 통제면이 된다.
커뮤니티가 신경 쓰는 지점
커뮤니티 반응은 아직 큰 규모의 합의라기보다 초기 질문에 가깝다. Hacker News의 관련 스레드에서는 “Vercel 외 플랫폼에 배포할 수 있나”라는 질문이 먼저 나왔다. 이어 sandbox backend가 여러 개 있고 오픈소스라 직접 구현할 수도 있다는 답변이 붙었다. 이 짧은 대화가 보여주는 쟁점은 명확하다. 개발자들은 에이전트 프레임워크의 DX만큼 배포 종속성과 실행 백엔드를 본다.
또 하나의 신호는 Vercel이 같은 주에 Workflow SDK의 inflight cancellation도 공개했다는 점이다. AbortController와 AbortSignal을 워크플로와 step 경계 너머로 전달해 느린 작업, 병렬 요청, 타임아웃 경쟁을 취소할 수 있게 했다는 내용이다. 에이전트가 실제 업무를 맡으면 “실행을 시작했다”보다 “중간에 멈추고, 재개하고, 취소하고, 추적할 수 있다”가 더 중요해진다.
운영 영향: 에이전트는 작은 백엔드 서비스다
eve를 단순한 프롬프트 래퍼로 보면 핵심을 놓친다. 에이전트는 사용자 대신 외부 API를 호출하고, 파일을 만들고, 코드를 실행하고, 일정에 따라 움직이는 작은 백엔드 서비스에 가까워지고 있다. 따라서 운영 기준도 백엔드 서비스 수준으로 올라가야 한다.
첫째, 권한 모델이 필요하다. connections/와 tools/가 어떤 외부 시스템에 닿는지, 사용자별 토큰과 공유 토큰이 어디서 갈리는지 명확히 해야 한다. 둘째, 샌드박스 정책이 필요하다. 파일시스템, 네트워크, 프로세스 실행을 어디까지 허용할지 정해야 한다. 셋째, 관측성이 필요하다. 공식 글은 eve가 실행 trace와 eval을 제공한다고 설명한다. 실패한 모델 호출과 도구 호출을 순서대로 재생할 수 없다면 운영 중인 에이전트는 디버깅하기 어렵다.
넷째, 배포 정책이 필요하다. 에이전트 instructions와 skills는 코드처럼 보이지 않지만 실제 동작을 바꾼다. 운영팀은 이 변경을 feature flag, staged rollout, review rule, rollback과 연결해야 한다. 다섯째, 비용 정책이 필요하다. 모델 선택, 장기 실행 워크플로, 샌드박스 리소스, 재시도 정책은 모두 비용 표면이다.
운영 계약 체크포인트
• 1. 에이전트마다 owner, 목적, 금지 작업, 허용 도구를 `instructions.md` 첫머리에 명시한다.
• 2. `tools/`는 실제 권한 경계로 보고, DB 쓰기·결제·배포·메일 발송 도구에는 별도 승인 단계를 둔다.
• 3. sandbox backend와 네트워크 허용 목록을 문서화한다. “기본값”으로 프로덕션 비밀값에 접근하게 두지 않는다.
• 4. 에이전트 변경을 일반 코드 리뷰와 같은 PR 흐름에 태운다. 프롬프트와 skill 변경도 테스트 대상이다.
지금 팀이 할 수 있는 체크리스트
1. 에이전트마다 owner, 목적, 금지 작업, 허용 도구를 instructions.md 첫머리에 명시한다.
2. tools/는 실제 권한 경계로 보고, DB 쓰기·결제·배포·메일 발송 도구에는 별도 승인 단계를 둔다.
3. sandbox backend와 네트워크 허용 목록을 문서화한다. “기본값”으로 프로덕션 비밀값에 접근하게 두지 않는다.
4. 에이전트 변경을 일반 코드 리뷰와 같은 PR 흐름에 태운다. 프롬프트와 skill 변경도 테스트 대상이다.
5. 최소 eval 세트를 만든다. 성공 케이스보다 위험한 실패 케이스, 거절해야 하는 요청, 권한 없는 도구 호출을 먼저 넣는다.
6. trace 보존 기간과 개인정보 마스킹 규칙을 정한다. 모델 입력·출력, 도구 결과, 파일 내용은 로그가 아니라 감사 자료다.
7. Vercel 외 실행이 필요한 팀은 초기 PoC에서부터 배포 경로와 sandbox backend 교체 가능성을 검증한다.
리스크와 반론
첫 번째 리스크는 베타 성숙도다. GitHub 저장소는 eve가 베타이며 API와 문서, 동작이 GA 전에 바뀔 수 있다고 알린다. 장기 운영 시스템의 중심에 두기 전에는 파일 구조, 배포 경로, 로컬 실행, tracing, eval, rollback을 모두 작은 범위에서 확인해야 한다.
두 번째 리스크는 플랫폼 결합이다. eve는 Vercel AI primitives와 잘 맞도록 설계되어 있다. 이 통합은 빠른 생산성을 주지만, 이미 AWS Step Functions, Temporal, 자체 Kubernetes sandbox, LangGraph, Mastra 같은 스택을 운영하는 팀에게는 중복 레이어가 될 수 있다.
세 번째 반론은 “에이전트를 폴더로 만드는 것만으로 운영 문제가 해결되지는 않는다”는 점이다. 맞다. 파일 구조는 통제의 시작일 뿐이다. 실제 품질은 권한 설계, 평가 데이터, 장애 대응, 비용 한도, 사용자 승인 UX에서 결정된다. 다만 eve의 등장은 에이전트 프레임워크 경쟁이 모델 추상화에서 운영 계약으로 이동하고 있다는 신호로 볼 만하다.
정리
결론적으로 eve를 오늘 바로 표준으로 삼을 필요는 없다. 하지만 에이전트가 `agent/` 폴더처럼 리뷰 가능한 운영 단위가 되어야 한다는 방향성은 이미 실무적인 질문이다. 앞으로 에이전트 도구를 고를 때는 “무슨 모델을 지원하나”보다 “권한, 재현, 승인, 취소, 평가, 배포가 코드 리뷰 가능한 형태로 남는가”를 먼저 물어야 한다.