eve 소개

오늘 우리는 에이전트를 구축, 실행 및 확장하기 위한 오픈 소스 에이전트 프레임워크인 eve를 소개하게 되어 자랑스럽게 생각합니다. eve는 에이전트를 구축한다는 것이 프로덕션(production)에서 실행하는 데 필요한 모든 구성 요소를 직접 조립할 필요 없이, 에이전트가 무엇을 하는지 정의하는 것을 의미해야 한다는 아이디어를 중심으로 설계되었습니다. 대신, eve는 프로덕션 환경이 이미 내장되어 있습니다: eve

eve는 우리가 자체 에이전트를 구축하고 실행하는 데 사용하는 프레임워크입니다.

오늘날의 에이전트는 프레임워크가 등장하기 전의 웹과 같습니다. 모두가 동일한 배관(plumbing) 작업을 수동으로 처리하고 있으며, 다음 프로젝트로 이어지는 것이 아무것도 없습니다. Next.js가 웹을 위해 이 문제를 해결했듯이, eve는 에이전트를 위해 동일한 일을 하고 있습니다.

이것은 eve 에이전트입니다.

각 파일은 에이전트의 한 구성 요소를 설명하므로, 한눈에 트리 구조를 통해 에이전트가 무엇인지, 무엇을 하는지, 어디에 거주하는지, 그리고 언제 스스로 행동하는지를 알 수 있습니다.

모든 에이전트는 그 정의와 함께 시작됩니다.

agent.ts 파일은 에이전트 자체를 구성하는 곳입니다. 단 한 줄로 모델을 정의할 수 있으며, AI Gateway를 통한 제공자 폴백(provider fallbacks)과 압축(compaction), 모델 옵션 및 기타 선택적 필드를 지원하므로 필요한 경우 바로 사용할 수 있습니다.

에이전트에게 직업과 개성을 부여하는 것은 instructions.md 파일을 생성하는 것만큼 간단하며, 이 파일은 eve가 모든 모델 호출 앞에 배치하는 시스템 프롬프트(system prompt) 역할을 합니다.

에이전트가 수행하는 작업(예: post_chart.ts)이나 도구 및 기술(예: revenue-definitions.md)을 위한 파일을 생성하면, eve는 관리해야 할 보일러플레이트(boilerplate)나 배관 작업 없이 이를 작동하는 에이전트로 연결합니다. 여러분은 에이전트가 '어떻게' 하는지가 아니라 '무엇을' 하는지에만 집중할 수 있습니다.

우리는 Vercel에서 수년 동안 v0를 포함한 여러 에이전트를 구축해 왔습니다. 하지만 코딩 에이전트가 등장하면서 누구나 에이전트를 구축할 수 있게 되자, 모두가 이를 실행했습니다. 우리는 수백 개의 에이전트와 내부 앱을 출시했으며, 이는 생산성 혁명처럼 보였습니다.

하지만 그 이면에서는, 모든 팀이 에이전트가 무언가를 수행하기도 전에 동일한 배관(plumbing) 작업을 구축하고 재구축하고 있었으며, 그 중 어느 것도 다음 사용 사례로 이어지지 않았습니다. 각 에이전트는 서로 다른 작업을 위해 설계되었지만, 모두 동일한 요구 사항을 가지고 있었고, 이를 충족하기 위해 동일한 구조가 계속해서 나타났습니다. 에이전트에는 형태(shape)가 있습니다.

eve는 그 형태를 프레임워크로 만든 것입니다. 모든 세대의 소프트웨어는 충분히 많은 사람들이 동일한 것을 어려운 방식으로 구축하고 나면 비로소 그 추상화(abstractions)를 얻게 되며, 에이전트가 바로 지금 그 단계에 와 있습니다.

프로덕션 환경에서 에이전트가 필요로 하는 모든 것이 이 프레임워크와 함께 제공됩니다.

에이전트는 사람을 기다리고, 느린 시스템을 호출하며, 몇 시간, 며칠, 또는 몇 주 동안 실행됩니다. eve에서 모든 대화는 각 단계가 체크포인트(checkpointed)로 저장되는 내구성이 있는 워크플로(durable workflow)이므로, 세션이 일시 중지되거나, 충돌 또는 배포(deploy) 상황에서도 살아남아 정확히 멈췄던 지점에서 재개될 수 있습니다. 이 내구성(durability)은 오픈 소스인 .Workflow SDK를 기반으로 구축되었습니다.

에이전트가 작성하는 코드는 신뢰할 수 없는 것으로 취급되어야 하므로, eve는 에이전트가 생성한 코드를 애플리케이션 런타임(runtime)에서 완전히 분리하여 유지합니다. 모든 에이전트는 쉘 명령(shell commands), 스크립트, 파일 읽기 및 쓰기를 위한 격리된 환경인 자체 샌드박스(sandbox)를 할당받으며, 이는 에이전트를 제어하는 하네스(harness)와는 별도의 보안 컨텍스트(security context)에서 실행됩니다. 이 샌드박스의 백엔드는 어댑터(adapter)입니다. 배포 시에는 , 로컬에서는 Docker, microsandbox, 또는 로 실행되며, 다른 어떤 제공업체를 위해서도 어댑터를 작성할 수 있습니다.Vercel Sandboxjust-bash

에이전트는 실제 시스템에서 동작하며, 그러한 동작 중 일부는 사람의 승인을 필요로 해야 합니다. eve의 모든 동작은 승인을 요구하도록 구성할 수 있으며, 에이전트는 컴퓨팅 자원을 전혀 소모하지 않고 필요한 경우 무기한으로 그 지점에서 일시 중지하고 기다립니다. 승인이 완료되면 eve는 중단되었던 지점부터 즉시 작업을 계속합니다.

에이전트는 사용자의 백엔드, 데이터 및 기타 제3자 서비스에 연결해야 합니다. eve에서 연결(connection)은 MCP 서버 또는 호환 가능한 OpenAPI 문서를 가진 모든 API를 가리키는 파일입니다.

eve는 원격 도구(remote tools)를 발견하여 모델에게 전달하고 인증(auth)을 중개하며, 모델은 연결(connection)의 URL이나 자격 증명(credentials)을 절대 볼 수 없습니다. 동의(consent) 및 토큰 갱신(token refresh) 기능이 내장된 대화형 OAuth를 처리합니다. 출시 시점에 eve 에이전트는 Slack, GitHub, Snowflake, Salesforce, Notion, Linear에 연결할 수 있으며, 그 외에도 OAuth, API 키 또는 MCP 서버를 통해 접근 가능한 모든 것에 연결할 수 있습니다.Vercel Connect

새로운 접점(surface)이 생길 때마다 매번 별도의 통합(integration)을 구축해야 하기 때문에, 대부분의 에이전트는 정확히 한 곳에만 존재합니다. eve에서는 동일한 에이전트가 모든 접점에 서비스를 제공하며, 각 채널은 단지 작은 어댑터(adapter) 파일일 뿐입니다. HTTP API는 기본적으로 활성화되어 있으며 Slack, Discord, Teams, Telegram, Twilio, GitHub, Linear가 포함되어 있고 커스텀 채널도 지원합니다. 하나의 채널이 다른 채널로 작업을 넘길 수도 있어, 인시던트 웹훅(incident webhook)이 Slack에서 조사 스레드를 열 수도 있습니다.defineChannel

에이전트가 무언가 잘못했을 때, 첫 번째 질문은 에이전트가 실제로 무엇을 했는가입니다. eve에서는 모든 실행(run)이 트레이스(trace)를 생성합니다. 각 모델 호출(model call)과 도구 호출(tool call)은 입력값 및 출력값과 함께 순서대로 나타나며, 에이전트가 샌드박스(sandbox)에서 실행한 명령까지 상세히 기록되므로 로그를 조각조각 모으는 대신 실행 과정을 다시 재생(replay)할 수 있습니다.

스팬(spans)은 표준 OpenTelemetry를 따르며 Braintrust, Honeycomb, Datadog 또는 Jaeger와 같이 이미 사용 중인 모든 트레이싱 서비스로 내보낼 수 있습니다. Vercel에서는 관측성(Observability) 아래의 Agent Runs 탭에 표시되어, 모든 세션을 모니터링하고 모든 실행 내용을 상세히 조사할 수 있는 단일 지점을 제공합니다. 평가(Evals)를 통해 더 나아가, 로컬에서 실행하거나 CI에 연결할 수 있는 점수가 매겨진 테스트 스위트(test suites)를 활용할 수 있습니다.

이제 어떤 프레임워크도 대신 작성해 줄 수 없는 부분, 즉 에이전트가 실제로 무엇을 할 것인가라는 과제가 남았습니다.

에이전트에게 능력을 부여하는 가장 일반적인 방법은 도구(tools)를 제공하고, 스킬(skills)을 통해 무언가를 수행하는 방법을 가르치는 것입니다. 오늘날 이는 도구를 구축하고, 스킬을 작성한 다음, 에이전트 루프(agent loop)를 실행하는 무엇인가에 두 가지를 모두 연결하는 것을 의미합니다. eve에서 도구는 하나의 TypeScript 파일이며, 스킬은 하나의 markdown 파일입니다.

무엇이 빠져 있는지 주목해 보세요. 이들을 연결하고 에이전트 (agent)에 등록하기 위한 모든 상용구 코드 (boilerplate)를 작성하는 대신, eve가 이를 대신 처리해 줍니다.

파일의 이름과 트리 내의 위치가 곧 정의가 됩니다. eve는 빌드 타임 (build time)에 도구 (tool)와 스킬 (skill)을 포착하여 모델에게 해당 설명을 전달하며, 모델은 그 이후부터 작업을 수행합니다. turns가 라우팅 (routing)을 소유함으로써 폴더를 라우트 (route)로 만드는 것처럼, eve는 에이전트 루프 (agent loop)를 소유함으로써 파일을 능력 (ability)으로 변환합니다. Next.js

액션 (action)에 대한 승인을 요구하는 것은 도구의 한 가지 필드입니다.

이제 비용이 많이 드는 쿼리 (query), 파괴적인 쓰기 (write), 또는 감독 없이 실행되는 것을 원치 않는 그 어떤 것이든 보호할 수 있습니다.

정의한 도구들이 한계는 아닙니다. eve는 에이전트에게 셸 (shell)이 포함된 실제 컴퓨터를 제공하므로, bash, grep, 그리고 터미널 (terminal)에서 실행할 수 있는 그 어떤 것이든 실행할 수 있습니다. 작업이 아직 존재하지 않는 코드를 요구할 때, 에이전트는 코드를 직접 작성하고 실행합니다.

에이전트는 보안 샌드박스 (sandbox) 내에서 스스로 문제를 해결할 수 있으며, 데이터셋 (dataset)을 재구성하거나, 일회성 분석을 수행하거나, 어떤 도구로도 커버되지 않는 작업에 필요한 코드를 무엇이든 작성할 수 있습니다.

eve 에이전트는 위임 (delegate)할 수도 있습니다. 서브에이전트 (subagent)는 한 단계 아래에서 동일한 형태를 가지며, 자체적인 지침, 도구, 샌드박스를 가진 디렉터리 형태로 존재합니다. 부모는 도구를 호출하는 것과 똑같이 서브에이전트를 호출합니다. subagents/

자식은 깨끗한 컨텍스트 윈도우 (context window)와 당신이 부여한 도구들만 가지고 시작하여, 작업을 수행한 뒤 그 결과를 부모에게 다시 전달합니다.

이제 모든 개발자가 고대하는 부분인 에이전트 테스트 단계가 나옵니다. 이전에는 프로세스를 시작하고, 질문을 던지고, 로그를 읽어야 했으며, 어떤 도구가 사용되었는지, 모델이 무엇을 로드했는지, 혹은 왜 그렇게 답변했는지에 대한 간단한 뷰 (view)조차 없었습니다. 에이전트와 대화하며 작동하는 모습을 보고 싶었지만, 당신이 얻은 것은 stdout뿐이었습니다. eve를 사용하면 개발 루프 (dev loop)는 단 하나의 명령어로 이루어집니다.

eve 에이전트를 시작하려면, 해당 개발 서버 (dev server)를 실행하면 됩니다.

에이전트가 수행한 모든 작업은 TUI (Terminal User Interface)에서 확인할 수 있습니다. 에이전트는 스킬 (skill)을 로드하고, 쿼리 (query)를 실행하며, 팀의 규칙에 따라 답변을 생성합니다. 이 각각의 라인은 내구성이 있는 세션 (durable session) 내에서 체크포인트가 지정된 단계 (checkpointed step)입니다. 터미널 UI는 단지 클라이언트일 뿐이며, 에이전트는 HTTP를 통해 동일한 구조화된 이벤트 (structured events)를 제공하므로, curl 명령어나 테스트 스크립트, 또는 CI (Continuous Integration)를 통해 에이전트를 구동하고 수행한 작업을 정확히 확인할 수 있습니다.

에이전트와 직접 대화하는 것은 한 번에 한 번의 실행을 검증하는 방식입니다. 반면, Evals (평가)는 프로젝트의 다른 부분과 마찬가지로 파일에 작성된 점수화된 체크 (scored checks)를 통해 소프트웨어의 나머지 부분을 테스트하는 방식과 동일하게 에이전트를 테스트합니다.

로컬에서 실행하거나 배포된 앱을 대상으로 지정할 수 있으므로, 프롬프트 (prompt) 변경이나 모델 교체 시 사용자가 발견하기 전에 무엇이 망가졌는지 미리 확인할 수 있습니다. eve eval

에이전트가 여러분의 노트북에서 머무는 시간은 충분했습니다. 일반적으로 에이전트를 배포 (shipping)하는 단계는 에이전트 작업이 끝나고 인프라 (infrastructure) 작업이 시작되는 지점입니다. 하지만 eve의 경우 프로비저닝 (provisioning)할 것이 아무것도 없습니다. 에이전트가 일반적인 Vercel 프로젝트이기 때문에, 다른 프론트엔드 (frontend)나 백엔드 (backend)와 동일한 방식으로 배포되기 때문입니다.

eve는 처음부터 어댑터 (adapters)를 염두에 두고 설계되었기 때문에, 배포한다고 해서 에이전트의 어떤 것도 변하지 않습니다. 출시 시점에 eve는 Vercel에 배포되며, 다른 플랫폼에 대한 지원도 예정되어 있습니다. 동일한 디렉토리가 여러분의 노트북에서 실행되었던 것과 정확히 똑같이 프로덕션 (production) 환경에서 실행됩니다. 샌드박스 (sandbox)는 코드 변경 없이 Vercel Sandbox로 전환되며, 개발 환경에서 대화하던 에이전트는 이제 공개 URL을 통해 접속할 수 있습니다. 배포는 에이전트를 중단시키지도 않습니다. 푸시 (push)를 할 때 작업 중간에 있던 세션은 시작되었던 버전에서 그대로 완료됩니다.

이 모든 과정에서 별도의 대시보드 (dashboard) 단계는 필요하지 않습니다. 여러분의 에이전트를 구축했던 바로 그 코딩 에이전트가 에이전트를 배포하고 그 작업 결과까지 검증할 수 있습니다.

하지만 배포되었다고 해서 완료된 것은 아닙니다. 프로덕션 환경에서 에이전트는 만나야 할 사용자가 있고, 자체적인 일정에 따라 수행해야 할 작업이 있습니다.

에이전트를 Slack에 도입하려면, 에이전트가 한 마디를 내뱉기도 전에 앱 설정, 봇 토큰 (bot token), 이벤트 구독 (event subscriptions), 웹훅 엔드포인트 (webhook endpoint), 그리고 서명 비밀값 (signing secret)을 포함한 Slack 앱을 먼저 구축해야 했습니다. eve를 사용하면 채널을 연결하는 것은 단 하나의 명령어일 뿐입니다.

해당 명령은 channels/slack.ts라는 단일 파일을 작성하며, 이는 다른 코드 변경 사항과 마찬가지로 배포됩니다. 이제 방금 배포한 에이전트가 Slack에서 응답합니다. 플랫폼의 기능(affordances)은 채널과 함께 제공되므로, 승인 요청은 Slack 버튼으로 나타나고, 질문은 선택 메뉴(select menus)로 나타나며, 에이전트는 작업하는 동안 타이핑 표시기(typing indicators)를 게시합니다. 자격 증명(credentials)을 전달하면 파일에 복사할 봇 토큰(bot token)도 필요 없습니다. discord 또는 teams와 함께 명령을 다시 실행하면 동일한 에이전트가 채널당 하나의 파일 형태로 존재하게 됩니다. Vercel Connect

채널은 에이전트의 사용자 인터페이스(UI)이며, 세션은 채널 간에 이동합니다. Slack에서 던진 질문은 웹에서 계속 이어질 수 있으며, HTTP를 통해 전달된 인시던트 웹훅(incident webhook)은 Slack에서 조사 스레드를 열고 팀이 이미 머물고 있는 곳에서 작업을 마무리할 수 있습니다.

월요일 매출 보고서는 누군가 요청할 때까지 기다려서는 안 됩니다. 스케줄(schedule)은 파일 하나를 더 추가하는 것과 같으며, 크론 표현식(cron expression)과 에이전트를 자체적인 시간에 시작하는 핸들러(handler)로 구성됩니다.

Vercel에서는 각 스케줄이 Vercel Cron Job으로 배포되므로, 아무도 신경 쓸 필요 없이 매주 월요일마다 보고서가 게시됩니다.

팀이 의존하는 에이전트는 프로덕션 소프트웨어(production software)이며, 에이전트의 지침(instructions)을 변경하는 것은 코드 변경만큼이나 확실하게 에이전트를 망가뜨릴 수 있습니다. eve 에이전트는 디렉토리 내의 파일들이기 때문에 나머지 코드와 마찬가지로 Git에서 관리됩니다. 따라서 새로운 프롬프트(prompt), 도구(tool), 또는 기술(skill)은 diff, 리뷰, 그리고 이력을 가진 하나의 커밋(commit)이 됩니다.

CI(지속적 통합)에 연결하면 작성한 테스트 스위트(suites)가 배포 게이트(deploy gate)가 되어 모든 커밋의 점수를 매기며, 이를 통해 회귀(regression) 문제가 프로덕션이 아닌 CI 단계에서 차단됩니다. eve eval

모든 커밋은 자체적인 프리뷰 배포(preview deployment)를 가지며, 에이전트의 채널들도 함께 가져갑니다. 팀은 매일 사용하는 봇을 교체하기 전에 다음 버전의 Slack 봇과 미리 대화해 볼 수 있습니다.

그리고 어떤 평가(eval)로도 잡아내지 못한 잘못된 변경이 발생하면, 즉시 이전 버전으로 roll production back할 수 있습니다.

Vercel에서는 프로덕션(production) 환경에서 100개 이상의 에이전트(agent)를 실행하고 있으며, 이들은 각자 비즈니스에서 특정 역할을 맡아 회사가 매일 운영되는 방식의 일부를 구성합니다. 그중 몇 가지를 소개합니다.

Vercel에서 가장 많이 사용되는 내부 도구는 에이전트이며, 한 달에 30,000개 이상의 질문을 처리합니다. 누구나 Slack에서 d0에게 무엇이든 물어볼 수 있으며, 데이터 웨어하우스(warehouse)로부터 답변을 받을 수 있습니다. 모든 쿼리(query)는 질문자의 권한 범위 내로 제한되므로, d0는 사용자가 이미 볼 수 없는 테이블을 보여줄 수 없습니다.

Lead Agent는 당사의 가장 뛰어난 영업 담당자의 플레이북(playbook)을 24시간 내내 실행합니다. 이 에이전트는 새로운 리드(lead)가 들어오는 즉시 작업하며 스스로 후속 조치(follow up)를 취하기 때문에, 어떤 리드도 하룻밤 사이에 식어버리지 않습니다. 운영 비용은 연간 약 5,000달러가 들지만, 그 32배에 달하는 수익을 가져다주며, 엔지니어 한 명이 파트타임으로 유지 관리하고 있습니다.