How We Solved Agent Building — Andrew Qu, Vercel

한 줄 핵심

Vercel은 데이터팀 문제를 계기로 단순 프롬프트에서 파일 시스템 기반 에이전트와 Eve 프레임워크까지 진화시키며, 회사별 지식과 도구를 내장한 업무용 에이전트를 빠르게 만들 수 있는 방법을 제시한다.

시간별 요약

1. 0:00
   Vercel과 AI SDK Vercel은 웹 인프라를 넘어 에이전트를 쉽게 만들기 위한 AI SDK를 제공하며, 서로 다른 모델 제공자 간의 코드를 한 줄 수준으로 바꾸고 폴백, 안전한 코드 실행, 비용 최적화, 복원성을 지원하는 방향으로 제품을 확장했다.
2. 1:35
   모든 책상 위의 에이전트 개인용 컴퓨터가 모든 책상에 있듯이 에이전트도 모든 업무 책상에 놓일 수 있다는 가설 아래, 마케팅·세일즈·재무·법무 등 여러 직무를 살펴보며 가장 고통스러운 반복 업무를 찾는 실험을 시작했다.
3. 2:45
   데이터팀이 병목이 된 이유 고객·분석·세일즈 데이터가 급증하면서 데이터팀이 질의 작성과 분석 요청에 계속 끌려다니게 되었고, 다른 부서의 질문이 들어올 때마다 작업을 멈춰야 하는 구조가 생산성을 크게 떨어뜨렸다.
4. 3:39
   버전 1, 하나의 거대한 프롬프트 처음에는 Snowflake 스키마를 시스템 프롬프트에 넣고 질문을 던져 SQL을 생성하게 하는 가장 단순한 방식으로 가능성을 확인했으며, 이 과정을 통해 모델 자체보다 컨텍스트와 가드레일 설계가 중요하다는 점을 배웠다.
5. 4:51
   버전 2, 범위가 분리된 에이전트 체인 질문 처리, 계획, 실행, 보고를 서로 다른 에이전트로 나누고 각자 전용 시스템 프롬프트와 도구만 갖게 하자 종단 간 흐름은 좋아졌지만, 단계가 늘어날수록 상태가 잘려 나가고 아키텍처가 벽에 부딪히기 시작했다.
6. 5:58
   버전 3, 자신의 상태를 관리하는 하나의 에이전트 여러 에이전트를 이어 붙이기보다 하나의 에이전트가 내부 메모리와 진행 상태를 직접 관리하도록 바꾸자, 실행 중 오류가 나도 되돌아가 탐색하고 다시 읽으며 스스로 복구하는 능력이 크게 좋아졌다.
7. 7:17
   초기 롤아웃의 실패와 파일 시스템의 해방 초기 배포는 기대보다 형편없었지만, Claude Code와 Opus 4.5가 파일 시스템 중심의 최소 도구 세트로 훨씬 잘 동작하는 것을 보며 핵심은 도구를 억지로 제한하는 것이 아니라 에이전트가 잘 훈련된 파일 시스템 방식으로 탐색하게 하는 데 있다는 사실을 깨달았다.
8. 10:14
   반복 질의를 스킬로 압축하기 매일 반복되는 수많은 데이터 질의를 자동으로 모아 스킬로 정리하는 구조를 만들고 약 100개의 스킬을 축적하면서, 새 실행이 처음부터 시작하는 문제를 줄이고 회사 고유의 맥락을 재사용 가능하게 만들었다.
9. 12:04
   에이전트를 위한 Next.js 만들기 에이전트를 파일 시스템 기반으로 선언적으로 조립하는 프레임워크가 필요하다고 보고 Eve를 출시했으며, 런타임·채널·도구·스킬·내구성·샌드박스·연결을 표준화해 오픈소스와 Vercel 배포를 모두 쉽게 만들었다.
10. 14:18
    초기 사용자, 성과, 그리고 시작점 초기 사용자들은 Eve로 더 적은 단계와 더 나은 성공률, 더 풍부한 관측성을 얻었고, 회사별 지식을 많이 넣을수록 범용 도구보다 훨씬 강력해진다는 결론 아래 누구나 자기 업무에 맞는 전용 에이전트를 직접 만들어야 한다고 정리했다.

실무 인사이트

• 에이전트 품질은 모델 성능만이 아니라 파일 시스템, 샌드박스, 도구 구성이 좌우하므로 먼저 작업 환경을 설계해야 한다.
• 반복되는 질문과 워크플로를 스킬로 축적하면 새 실행의 초기 맥락 부족을 줄이고 조직 지식을 재사용할 수 있다.
• 범용 에이전트보다 회사별 데이터 구조와 업무 맥락을 깊게 반영한 전용 에이전트가 실제 생산성 향상에 더 유리하다.