에이전트 구축의 해법 — Andrew Qu, Vercel

URL: https://www.youtube.com/watch?v=9dYcwOkpCE8 날짜: 2026-09-15 채널: aiDotEngineer

---

source: YouTube video_id: 9dYcwOkpCE8 title_original: How We Solved Agent Building — Andrew Qu, Vercel speaker: Andrew Qu company: Vercel

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==기업이 에이전트(agent)를 실제 업무에 투입할 때, 거대한 프롬프트와 고정된 도구 체인에서 벗어나 파일 시스템·기술·프레임워크 중심의 조합으로 어떻게 안정적인 에이전트를 만드는가?==

• Vercel은 웹 애플리케이션 인프라를 단순화해 온 경험을 에이전트 구축에도 적용했다.
• Snowflake 데이터 질의 에이전트 DZero는 거대한 프롬프트, 전문화된 다중 에이전트, 단일 메가 에이전트, 파일 시스템 에이전트 순서로 진화했다.
• 파일 시스템과 재사용 가능한 기술(skill), 그리고 실행·내구성·관찰 가능성을 제공하는 Eve 프레임워크가 기업별 에이전트의 생산 경로를 단축한다.

Vercel의 사례는 에이전트의 성능이 도구를 많이 붙이는 데서 자동으로 나오지 않으며, 모델이 이미 학습한 범용 인터페이스를 이용해 필요한 맥락을 스스로 탐색하게 하고 회사 고유의 지식을 기술로 축적할 때 실용성이 커진다는 점을 보여준다. 데이터 질의를 시작점으로 삼은 실험은 약 1년 동안 내부 에이전트 약 20개와 Eve로 이어졌고, HR·재무·영업·마케팅·법무 같은 비기술 업무에도 적용 가능한 운영 패턴을 만들었다.

1. Vercel이 에이전트 문제를 맡게 된 배경

웹 애플리케이션 인프라를 추상화해 온 Vercel은 사람들이 페이지가 아니라 에이전트와 에이전트형 애플리케이션을 만들기 시작한 변화에 대응했다.

1.1. Andrew Qu의 역할과 Vercel의 출발점

1. 소프트웨어 총괄의 업무 범위

   1. Andrew Qu는 Vercel의 Chief of Software로서 내부 엔지니어링, 외부 실험, 최전선의 새로운 라이브러리·프레임워크·기술 구축을 함께 담당한다.
   2. 이러한 역할은 이미 완성된 제품을 유지하는 일보다 새로운 개발 방식이 실제로 작동하는지 빠르게 검증하는 일에 가깝다.

2. Vercel이 해결해 온 인프라 문제

   1. Vercel은 사람들이 애플리케이션의 품질을 높이지 않는 인프라 세부 사항을 직접 걱정하지 않고 웹사이트와 웹 앱을 출시하도록 돕는 에이전틱 인프라(agentic infrastructure)를 만든다.
   2. 제공하는 실행 환경은 최대 100만 규모까지 확장되고 사용량이 없을 때는 0까지 자연스럽게 축소된다.
   3. 인프라를 자동으로 확장·축소하는 방식은 애플리케이션 제작자가 배포와 운영보다 제품 자체에 집중하게 하는 Vercel의 기존 철학을 반영한다.

1.2. 페이지에서 에이전트로 이동한 개발 수요

1. 사람들이 만들고 싶은 대상의 변화

   1. 과거에는 사람들이 페이지와 웹 앱을 만드는 데서 출발했지만, 이제는 스스로 작업을 수행하는 에이전트를 만들고 싶어 한다.
   2. Vercel은 이 수요에 맞춰 에이전트와 에이전트형 애플리케이션을 더 쉽게 만드는 여정을 시작했다.

2. AI SDK와 주변 기반 도구

   1. Vercel의 AI SDK는 모델 제공업체별 코드 300~400줄을 갈아끼우는 대신 한 줄만 바꾸도록 하고, 여러 제공업체에 동일한 모델 인터페이스를 제공한다.
   2. 모델 폴백(model fallback)은 한 모델의 실패나 불안정성을 다른 모델로 넘겨 서비스 중단 가능성을 낮춘다.
   3. 안전한 코드 실행(secure code execution)은 에이전트가 실행하는 코드를 격리하고, 유휴 상태에서 응답을 기다리는 동안 더 나은 비용 구조를 제공한다.
   4. 내구성(durability)과 재개 가능성(resumability)은 긴 작업이 중단되어도 처음부터 다시 시작하지 않고 이어지게 한다.

2. ‘모든 책상에 에이전트 하나’라는 실험의 시작

Bill Gates의 개인용 컴퓨터 비유를 회사의 모든 업무에 에이전트를 배치한다는 가설로 확장하면서 실험이 시작됐다.

2.1. 컴퓨터 한 대에서 에이전트 한 대로

1. 1980년의 대담한 예측

   1. 1980년 무렵 Bill Gates는 모든 책상과 모든 가정에 컴퓨터가 한 대씩 놓이리라고 상상했다.
   2. 당시에는 상당히 반(反)직관적인 예측이었지만, 오늘날 모든 책상과 가정에 컴퓨터가 있는 풍경은 자연스럽게 받아들여진다.

2. Vercel의 다음 가설

   1. Andrew Qu와 CTO는 “모든 책상 위의 컴퓨터”를 “모든 책상 위의 에이전트”로 바꿔 생각했다.
   2. 당시 에이전트는 코딩과 기술 업무에 주로 쓰였지만, 디자인·제품 관리(product management)·다른 직무 영역으로 확장되기 시작했다.
   3. 이 가설을 세운 시점은 약 1년 전이며, 당시에는 Sonnet 4가 사용되던 때라 현재보다 모델이 덜 정교했다.

2.2. 직무별 불편을 찾아 데이터 팀을 선택하다

1. 현업에 던진 동일한 질문

   1. Andrew Qu는 마케팅, 영업, 재무, 법무 등 Vercel의 여러 직무를 찾아가 “업무에서 가장 싫어하는 일이 무엇인가?”라고 물었다.
   2. 가장 설득력 있는 답은 빠르게 성장하는 Vercel에 비해 매우 작은 규모로 운영되던 데이터 팀에서 나왔다.

2. 데이터 팀의 병목

   1. Vercel이 성장하면서 고객 데이터, 분석 데이터, 지표, 영업 데이터가 계속 늘어났고, 데이터 팀은 이를 집계해 구성원들이 사용할 수 있게 만들어야 했다.
   2. 마케팅이나 영업에서 고객 또는 제품에 관한 질문이 나오면 데이터 과학자는 진행 중인 일을 모두 멈추고 질의를 작성해야 했다.
   3. 데이터 과학자는 질의를 실행하고 분석한 뒤 무엇을 해야 할지 추천하는 결과를 다시 전달해야 했다.
   4. 이러한 반복은 데이터 팀의 생산성을 크게 떨어뜨렸고, 데이터 과학자들은 하루 종일 질의만 작성하는 일을 원하지 않았다.

3. DZero의 첫 번째 설계: 거대한 프롬프트와 전문 에이전트 체인

데이터 과학자가 질문을 받아 답을 만드는 실제 단계를 분해하고, 처음에는 거대한 프롬프트로 검증한 다음 역할별 에이전트 체인으로 확장했다.

3.1. 거대한 메가 프롬프트로 가능성을 확인하다

1. Snowflake 스키마를 맥락으로 넣기

   1. 첫 시도는 질문을 대규모 언어 모델(LLM)에 전달하고 응답을 받는 거대한 메가 프롬프트(mega prompt)였다.
   2. Snowflake 스키마 전체 덤프를 받아 시스템 프롬프트에 붙여 넣고, 모델이 만든 SQL을 Andrew Qu가 직접 복사해 실행했다.

2. 최초 실험이 제공한 신뢰

   1. 좋은 구조가 주어졌을 때 모델이 유효한 SQL을 작성할 수 있는지 확인하는 것이 첫 목표였다.
   2. 모델의 기본 능력은 아직 충분히 뛰어나지 않았지만, 맥락을 더 잘 설계하고 가드레일을 추가하면 실용적인 수준으로 끌어올릴 수 있다는 자신감을 얻었다.

3.2. 데이터 과학자의 실제 작업을 단계로 나누다

1. 질문에서 의미 계층까지

   1. 데이터 과학자는 먼저 자연어 질문을 처리하고, 의미 계층(semantic layer)을 탐색해 어떤 엔터티와 조인 패턴(join pattern)이 필요한지 파악한다.
   2. 의미 계층은 단순한 테이블 목록이 아니라 어떤 데이터가 서로 어떻게 연결되는지 판단하기 위한 회사 고유의 지식 층이다.

2. 실행·수정·보고의 반복

   1. 데이터 과학자는 SQL을 실행하고, SQL이 실패하거나 비용이 너무 높으면 원인을 찾아 다시 수정하고 실행한다.
   2. 최종 결과에는 데이터 시각화, 설명 문단, 회고(retro), 후속 분석 같은 보고 작업이 포함될 수 있다.

3.3. DZero의 역할별 에이전트 체인

1. 전문화된 작업 흐름

   1. 두 번째 버전의 데이터 과학 에이전트인 DZero(D0)는 질문을 받는 쿼리 에이전트(query agent)에서 출발한다.
   2. 쿼리 에이전트는 계획 에이전트(planning agent)로 넘기고, 계획 에이전트는 실행 에이전트(execution agent)와 SQL 에이전트(SQL agent), 보고 에이전트(reporting agent)로 작업을 이어 보낸다.

2. 프롬프트와 도구의 범위 제한

   1. 각 에이전트는 자신의 역할에만 집중하는 전용 시스템 프롬프트를 가진다.
   2. 각 에이전트에 부여된 도구도 해당 기능에 정확히 맞도록 범위가 제한된다.
   3. 계획 에이전트는 엔터티 YAML을 읽는 read entity YAML 도구와 스키마를 검색하는 search schemas 도구만 사용해 계획을 세운다.
   4. 계획 결과는 SQL 에이전트로, SQL 결과는 보고 에이전트로 넘겨져 질문에서 답까지의 전체 순환이 자동으로 수행된다.

3. 첫 번째 개선

   1. 사람이 SQL을 복사해 실행하고 결과를 다시 작성해야 했던 과정에서 벗어나 질문부터 답까지의 엔드투엔드 루프를 만들었다.
   2. 작업을 기능별로 좁힌 도구와 프롬프트가 초기 품질을 높였지만, 에이전트 사이의 맥락 전달에는 한계가 남았다.

4. 단일 메가 에이전트로의 전환과 한계

역할별 체인은 단계별 전문성을 얻었지만, 전체 작업의 상태와 실패 원인을 다음 단계가 충분히 볼 수 없다는 문제를 드러냈다.

4.1. 요약만 전달되는 기억의 손실

1. 체인의 맥락 단절

   1. 앞 단계의 결과 중 다음 에이전트가 받는 것은 요약과 직전 작업의 작은 일부뿐이었다.
   2. 다음 단계는 앞서 어떤 탐색을 했고 어떤 판단을 거쳤는지 전체 기록을 되돌아볼 수 없었다.

2. 반성적 실행의 필요

   1. 에이전트가 지금까지의 작업을 되돌아보고 현재 단계에 도달한 경로를 스스로 파악해야 했다.
   2. 계획·구축·실행·보고를 모두 하나의 상태 안에서 오갈 수 있어야 SQL 오류나 조인 오류 뒤에 추가 탐색과 추가 읽기를 수행할 수 있었다.

4.2. 상태를 직접 관리하는 단일 에이전트

1. 메가 에이전트 구조

   1. DZero는 최대 단계 수(max steps) 100으로 설정된 하나의 큰 AI 호출로 재구성됐다.
   2. 하나의 에이전트가 내부 상태를 관리하면서 시점에 따라 계획하고, 만들고, 실행하고, 보고하는 구조가 됐다.

2. 오류에서 되돌아가는 능력

   1. SQL을 실행하거나 조인하는 중 오류가 나면 단일 에이전트가 이전 단계의 맥락을 유지한 채 더 탐색하거나 더 읽을 수 있었다.
   2. 실패한 작업을 단순히 다음 에이전트에 넘기는 대신 무엇을 잘못했는지 찾아 실행 경로를 수정할 수 있었다.

4.3. 실제 사용자에게서 드러난 평가의 벽

1. 제한된 초기 배포

   1. 시스템에 대한 확신이 생긴 뒤에도 핵심 업무나 매우 중요한 데이터를 사용하는 사람에게 바로 배포하지 않았다.
   2. 잘못된 사용자가 강력한 도구를 사용하거나 중요한 업무에 적용하는 위험을 피하기 위해 신뢰할 수 있는 일부 Vercel 구성원에게만 제공했다.

2. 예상 밖 질문과 낮은 체감 품질

   1. 내부 제작자들은 평가에서 약 30%를 맞히고 있다고 생각하며 상당히 잘 만들었다고 판단했다.
   2. 그러나 실제 사용자들의 즉각적인 반응은 “끔찍하다(awful)”였고, 사전에 예상하지 못한 질문이 대거 드러났다.
   3. 가능한 시나리오를 사람이 하나씩 직접 매핑해 보완하는 방식은 확장 가능한 해결책이 아니었다.

5. Claude Code에서 얻은 파일 시스템 에이전트의 돌파구

Claude Code와 Opus 4.5의 조합은 최소한의 파일 시스템 도구만으로 모델이 필요한 작업 공간을 스스로 탐색하는 패턴을 보여줬다.

5.1. 범용 모델과 파일 시스템이 만든 격차

1. 압도적인 비교 대상

   1. Opus 4.5가 Claude Code와 함께 등장하자, Andrew Qu가 만든 에이전트보다 대부분의 질문에 거의 막힘없이 답했다.
   2. 체감상 기존의 손수 만든 에이전트에 비해 사실상 AGI처럼 느껴질 정도로 큰 격차가 났다.

2. 최소 도구 집합

   1. Claude Code의 핵심 도구는 파일 목록 보기(list file), 파일 읽기(read file), Bash 실행(run bash)이었다.
   2. Vercel은 데이터 에이전트 용도에 필요한 도구를 몇 가지 더 추가했지만, 기본 인터페이스 자체는 매우 작았다.

5.2. 처방적 체인에서 탐색적 공간으로

1. 모델이 잘 학습한 인터페이스 활용

   1. Claude Code는 특정 순서로 도구를 호출하라는 처방적 도구 세트를 받지 않고, 파일 시스템을 탐색하고 필요한 곳에 작업물을 작성했다.
   2. 모델이 이미 충분히 학습한 파일 읽기·쓰기·Bash 실행을 제공하자 예상하지 못했던 창발적 행동(emergent behavior)이 나타났다.

2. 핵심 학습

   1. 에이전트가 실제로 필요한 정보를 직접 찾고 중간 결과를 작업 공간에 남기도록 하는 파일 시스템만으로도 강력한 실행 구조를 만들 수 있었다.
   2. 도구의 개수를 늘리고 단계 순서를 강제하는 일보다, 모델이 탐색할 수 있는 작업 공간과 적절한 맥락을 제공하는 일이 더 중요한 돌파구가 됐다.

5.3. Vercel용 파일 시스템 에이전트 재구축

1. 샌드박스 기반 실행

   1. Vercel은 Claude Code의 학습을 재현하기 위해 에이전트를 클라우드 샌드박스(sandbox)에서 실행하도록 다시 만들었다.
   2. 샌드박스 안에 의미 계층 전체를 넣고, 에이전트가 Bash·파일 읽기·파일 쓰기를 사용해 필요한 정보를 찾아 작업하게 했다.

2. Vercel 고유 도구의 얇은 추가

   1. 기본 파일 시스템 위에 Vercel 데이터 업무에만 필요한 몇 가지 도구를 얹었다.
   2. 범용 탐색 능력은 그대로 두면서 회사 고유의 데이터와 실행 요구사항만 보강하는 방식이 기존의 복잡한 체인보다 효과적이었다.

3. 평가 점수의 변화

   1. 단일 에이전트에서 Claude Code SDK로, 다시 특정 용도에 맞춘 파일 시스템 에이전트로 이동하는 단계마다 큰 도약이 일어났다.
   2. 파일 시스템 에이전트로 전환한 뒤 평가 점수는 사실상 두 배가 됐다.

5.4. 구현 형태와 대중적 관심

1. 단순한 구성 요소

   1. 구현은 Bash 도구 하나를 제공하는 형태로 단순화됐다.
   2. npm의 bash tool 헬퍼를 샌드박스에 연결하고, 에이전트가 읽고·쓰고·실행할 파일을 샌드박스에 첨부하면 된다.

2. 실험 결과의 공개

   1. 성능이 크게 좋아지고 이전에 실패하던 질문을 통과하기 시작하자 Andrew Qu는 이를 정리한 블로그 글을 작성했다.
   2. 해당 글은 게시된 그 주에 Vercel.com 전체 트래픽의 70%를 차지할 정도로 큰 관심을 받았다.

6. 반복 질의를 기술(skill)로 축적하다

수천 건의 실제 질의를 분석해 반복되는 업무 패턴을 기술로 추출하면서, 매번 빈 상태에서 시작하던 에이전트에 회사의 누적 지식을 주입했다.

6.1. 실제 사용자에게 풀어 둔 뒤 발견한 공통 패턴

1. 질의 규모와 범위

   1. Vercel 구성원들이 사용할 수 있도록 에이전트의 제약을 풀자 하루 수천 건의 질의가 들어왔다.
   2. 질의는 고객 지표, 영업 지표, 번호 지표(number metrics), npm 다운로드 수, 특정 제품 정보 등 여러 업무를 다뤘다.

2. 반복되는 질의 모양

   1. 집계(aggregation)를 수행하는 방식에는 일정한 패턴이 반복됐다.
   2. 제품 정보를 조회하거나 청구(billing) 정보를 확인하는 방식에도 반복되는 구조가 있었다.
   3. 가능한 질의의 모양이 무한히 다양하지 않다는 사실은 성공한 실행을 재사용 가능한 지식으로 전환할 수 있음을 뜻했다.

6.2. 최근 질의에서 약 100개의 기술을 만드는 반복 작업

1. 기술 추출 잡(job)

   1. Vercel은 최근 질의를 주기적으로 가져와 공통 절차를 하나의 기술(skill)로 정제하는 반복 작업을 만들었다.
   2. 현재 약 100개의 기술이 있으며, 단순 집계부터 특정 사람에 관한 데이터를 조회하는 작업까지 폭넓게 다룬다.

2. 빈 상태 문제의 해결

   1. 새로운 에이전트 실행은 의미 계층과 시스템 프롬프트 외에 미리 갖춰진 맥락이 거의 없는 상태에서 시작한다.
   2. 기술을 포함하면 이미 수행된 탐색과 판단이 맥락 지식으로 제공되어 에이전트가 매번 처음부터 추론하지 않아도 된다.
   3. 기술은 모델을 재훈련하지 않고도 성공한 업무 절차를 다음 실행에 전달하는 가벼운 지식 계층이 된다.

6.3. 기술을 찾고 실행하는 생태계

1. skills.sh

   1. Vercel은 에이전트 기술을 찾아 직접 실행하는 가장 대중적인 방식으로 skills.sh를 구축했다.
   2. 기술을 파일 시스템에 추가하면 에이전트는 기존 작업 공간과 같은 방식으로 해당 기술을 읽고 조합할 수 있다.

2. 복잡성이 생산 경로가 되는 과정

   1. 단순한 프롬프트에서 시작해 다중 에이전트, 단일 메가 에이전트, 파일 시스템, 기술 계층을 차례로 추가하는 과정은 실험이 프로덕션 시스템으로 성장하는 일반적인 경로가 됐다.
   2. Vercel 내부의 에이전트에 관심 있는 구성원들은 DZero를 포크해 각 단계에서 자신의 에이전트를 만들었고, 매 단계마다 이전에 몰랐던 더 나은 방법을 발견했다.
   3. 마지막 통찰을 처음부터 제공하면 모든 팀이 단순 프롬프트에서 출발해 같은 원리를 다시 발견할 필요가 없다는 문제가 Eve의 출발점이 됐다.

7. Next.js의 설계 철학을 에이전트 프레임워크 Eve로 옮기다

Eve는 파일과 폴더의 규칙만으로 에이전트의 구성 요소를 선언하는, 에이전트를 위한 Next.js에 해당하는 프레임워크로 설계됐다.

7.1. Next.js에서 가져온 파일 시스템 기반 추상화

1. Next.js의 규칙 기반 인프라

   1. Next.js는 Vercel이 만든 대중적인 웹 프레임워크로, 파일 시스템이 프레임워크 정의 인프라를 결정하게 했다.
   2. 개발자는 각 요소가 어디에 배치될지 직접 고민하지 않고 정해진 규칙에 맞는 파일을 만들면 된다.
   3. 페이지는 CDN으로, 서버리스 함수는 해당 실행 위치로, 캐시는 중간 계층으로 자동 배치된다.

2. 에이전트에도 같은 단순성을 적용하기

   1. 에이전트 개발자도 skills 폴더, tools 폴더, channels 폴더만 만들고 각 요소를 선언할 수 있어야 한다.
   2. 프레임워크가 폴더와 파일을 읽어 전체 에이전트로 조립하면 개발자는 배치·연결·실행 인프라보다 도메인 지식에 집중할 수 있다.

7.2. Eve의 런타임과 채널 구조

1. 에이전트의 두 축

   1. 에이전트는 런타임(runtime)과 채널(channels)로 구성된다.
   2. 런타임은 작업을 실행하고 상태를 관리하며, 채널은 에이전트가 사용자가 익숙한 서비스와 상호작용하는 접점을 제공한다.

2. 런타임이 제공해야 할 기반 기능

   1. 긴 작업을 보존하는 내구성(durability)이 필요하다.
   2. 에이전트가 코드를 안전하게 실행할 수 있는 격리 환경(isolate environment)이 필요하다.
   3. 여러 모델을 호출하고 필요에 따라 모델을 바꿀 수 있어야 한다.
   4. 외부 서비스와 연결하는 커넥션(connections)이 있어야 한다.

7.3. 오픈소스 어댑터와 Vercel 배포 경험

1. 오픈소스로 교체 가능한 구성

   1. Eve는 오픈소스를 염두에 두고 만들어져 Postgres, OpenAI Responses API, Docker 및 다른 커넥터용 자체 어댑터를 연결할 수 있다.
   2. 특정 클라우드 사업자의 서비스에만 종속되지 않고 필요한 기반을 직접 호스팅할 수 있다는 선택지가 제공된다.

2. Vercel에서 사용하는 관리형 기반

   1. Vercel에 배포할 때는 장기간 쌓아 온 제품을 사용해 에이전트 경험을 쉽게 구성할 수 있다.
   2. Vercel Workflows는 내구성 있는 작업 실행을, Vercel Sandbox는 안전한 코드 실행을, Vercel Connect는 연결을 위한 단기 OIDC(OpenID Connect) 토큰 생성을 담당한다.
   3. 오픈소스 어댑터를 사용할 수 있으면서 Vercel의 관리형 기능으로 배포·보안·연결을 단순화하는 이중 경로가 마련됐다.

7.4. DZero를 Eve로 다시 만들며 검증한 구성

1. 복잡한 내부 구조의 단순화

   1. Eve를 만드는 과정에서 DZero 전체를 Eve 위에 다시 작성했다.
   2. 외부에서 보이지 않던 복잡한 구조가 시스템 지침 몇 개, 기술 몇 개, 도구 몇 개로 정리됐다.

2. 빠른 조합과 반복

   1. 파일 시스템에 시스템 지침·기술·도구를 배치하면 실제 에이전트로 쉽게 조합된다.
   2. 구성을 바꾸고 다시 실행하는 반복 주기가 짧아져 도메인 지식을 추가하고 결과를 검증하기 쉬워졌다.

8. 베타 고객과 관찰 가능성으로 Eve를 검증하다

Eve는 정식 공개 전 베타 고객에게 제공됐고, 실제 서비스 테스트와 실행 추적 기능을 통해 오프더셸프 에이전트보다 나은 개발 경험을 검증했다.

8.1. Aura의 서비스 테스트 에이전트

1. Aura의 사용 사례

   1. Vercel과 긴밀히 협력하는 회사 Aura는 사람들의 서비스를 시험하는 ‘미니 Claude Code’ 같은 에이전트를 만들었다.
   2. 에이전트는 웹사이트로 이동해 서비스를 설치하고 실제로 사용하면서 서비스가 동작하는지 검증한다.

2. 오프더셸프 도구와의 비교

   1. Aura는 Eve로 에이전트를 밑바닥부터 구축하면서 기존의 기성 Claude Code와 비교했다.
   2. Eve 기반 구현은 더 적은 단계로 작업을 수행했고, 성공률과 내부 동작에 대한 인사이트도 더 나았다.

3. 공개 시점

   1. Eve는 Vercel의 런던 행사에서 약 2주 전에 정식 공개됐다.
   2. 정식 공개 전 일부 베타 고객에게 제공해 파일·기술·도구 조합이 실제 업무에 맞는지 확인했다.

8.2. 배포 즉시 제공되는 관찰 가능성

1. 실행 전 과정의 가시화

   1. Eve를 Vercel에 배포하면 별도의 관찰 시스템을 조립하지 않아도 관찰 가능성(observability)이 기본 제공된다.
   2. 모든 에이전트 실행, 모든 도구 호출, 각 단계의 진행 상황을 확인할 수 있다.

2. 비용과 개선 지점 확인

   1. 실행 과정에는 예상 비용(estimated costs)이 표시된다.
   2. 어떤 단계를 최적화할 수 있는지와 추가로 취할 수 있는 개선 조치도 확인할 수 있다.

8.3. 시작 방법

1. 즉시 실행

   1. eve.dev에서 템플릿을 복제하고 시작할 수 있다.
   2. Vercel에 쉽게 배포하거나 필요하면 직접 셀프 호스팅(self-host)할 수 있다.

2. 제공하려는 개발 경험

   1. 샘플 템플릿에서 출발해 고유 지식과 도구를 추가하고 익숙한 채널에 연결하는 흐름이 짧다.
   2. 실행 인프라를 다시 설계하지 않고 회사 업무에 맞는 기술과 도구를 반복해서 조정할 수 있다.

9. 오프더셸프 에이전트보다 회사 고유 지식이 중요하다

에이전트의 최종 품질은 범용 기능의 양보다 조직이 언제 무엇을 조회하고 데이터가 어떻게 연결되는지에 관한 구체적인 지식에서 결정된다.

9.1. 수직형 데이터 에이전트에 대한 검증

1. 기성 수직형 에이전트의 접근

   1. Vercel은 Snowflake 인스턴스를 연결해 Snowflake 질의를 실행하는 데 집중한 자금력 있는 수직형 에이전트 스타트업들을 광범위하게 시험했다.
   2. 이 제품들은 빠르게 시도하기에는 좋고 기본 기능도 잘 제공하지만, 모든 회사의 실제 업무 맥락을 깊게 알 수는 없었다.

2. Vercel의 도메인 특수성

   1. Vercel은 웹 기반 회사라 고객이 운영하는 웹사이트와 웹 프로퍼티(web properties)에 관한 정보가 매우 많다.
   2. 어떤 질문에 언제 어떤 데이터를 조회해야 하는지, 어떤 정보가 다른 정보와 연결되는지에 대한 규칙이 Snowflake 연결만으로는 드러나지 않는다.
   3. 이러한 회사별 맥락이 깊어질수록 같은 데이터베이스를 연결한 범용 에이전트보다 Vercel 고유 에이전트의 답변이 좋아진다.

9.2. 자체 에이전트를 만들 때의 원칙

1. 기성품의 올바른 사용

   1. 오프더셸프 에이전트는 가능성을 빠르게 시험하고 기본 작업을 확인하는 데 유용하다.
   2. 그러나 조직의 데이터 모델과 의사결정 규칙이 결과의 핵심이라면 기성품만으로 최상의 성능을 얻기는 어렵다.

2. 회사 지식으로 성능을 짜내기

   1. 가장 큰 효과를 얻으려면 자체 에이전트를 만들고 회사 고유의 지식을 가능한 한 많이 기술과 작업 공간에 넣어야 한다.
   2. “한 방울에서 최대한 많은 주스를 짜내려면”이라는 비유처럼, 모델의 범용 능력에 조직의 누적 맥락을 결합해야 한다.

10. Vercel 내부의 에이전틱 운영과 결론

Vercel은 특정 한 팀의 실험을 넘어 여러 직무에서 실제 시간과 생산성을 절약하는 약 20개의 PMF 에이전트를 운영하고 있다.

10.1. 약 20개의 적합한 내부 에이전트

1. 직무별 적용 사례

   1. 마케팅 회고(marketing retrospective)를 자동화하는 에이전트가 있다.
   2. 누구에게 연락해야 할지 찾아주는 에이전트가 있다.
   3. 법무 팀이 새 협상에 들어갈 때 계약서의 첫 번째 레드라인(redline)을 만드는 에이전트가 있다.
   4. DZero 데이터 과학 에이전트는 데이터 질의를 지원한다.

2. PMF와 조직 확산

   1. 이들 에이전트는 단순한 데모가 아니라 Vercel 내부에서 충분히 쓸 만한 제품-시장 적합성(PMF, product-market fit)을 보이는 수준으로 운영된다.
   2. 여러 부서에서 실제 업무 흐름과 연결되면서 Vercel은 에이전트가 업무의 일부가 된 조직으로 변했다.

10.2. 데이터 팀 생산성의 재배치

1. 질의 작성에서 인프라 개선으로

   1. 데이터 팀은 반복 질의를 직접 작성하느라 시간을 소모하는 대신 Snowflake 성능을 개선할 시간이 늘었다.
   2. 이전에는 시간이 없어 추가하지 못했던 데이터 소스를 연결하고, 누락된 데이터 공백을 메울 수 있게 됐다.

2. 자동화의 실질적 효과

   1. 에이전트는 데이터 팀의 일을 없애기보다 반복 작업을 맡아 더 높은 가치의 분석·인프라 작업에 집중하게 했다.
   2. 질문을 기다리며 수동으로 처리하던 병목이 줄어들면서 데이터 팀의 전반적인 생산성이 크게 높아졌다.

10.3. 다른 회사로 확장되는 적용 영역

1. 자동화 가능한 비기술 업무

   1. HR, 재무, 영업 업무에도 반복적인 조회·검토·보고 작업이 있어 에이전트로 어느 정도 자동화할 수 있다.
   2. 규모가 크든 작든 중간이든 모든 회사가 하고 싶지 않거나 과도한 시간을 쓰는 작업을 찾아 자동화할 수 있다.

2. Eve의 목표

   1. Eve는 회사별 지식과 업무 규칙을 기술·도구·채널로 조합해 이러한 업무 특화 에이전트를 만드는 가장 쉬운 경로를 제공한다.
   2. 오픈소스 어댑터, Vercel의 실행 기반, 샌드박스, 관찰 가능성을 함께 사용하면 실험에서 프로덕션까지의 간극을 줄일 수 있다.

주요 발언 모음

“모든 책상 위의 컴퓨터 대신, 모든 책상 위에 에이전트를 둘 수 있을까?”

“모델 제공업체별 코드 300~400줄을 바꾸는 대신 한 줄만 바꾸면 된다.”

“Claude Code와 Opus 4.5는 우리가 이전에 만들던 것과 비교하면 사실상 AGI처럼 느껴졌다.”

“가장 큰 돌파구는 파일 시스템이었다.”

“모든 새 에이전트 실행은 거의 아무것도 없는 상태에서 시작하지만, 기술은 이미 많은 맥락을 가진 상태에서 시작하게 한다.”

“정말 최대한의 효과를 얻고 싶다면 자체 에이전트를 만들고 회사 고유의 지식을 가능한 한 많이 넣어야 한다.”

핵심 데이터 & 수치

• 최대 100만에서 0까지: Vercel의 기존 실행 인프라는 최대 100만 규모까지 확장되고 유휴 상태에서는 0까지 축소된다.
• 300~400줄 대 한 줄: AI SDK는 모델 제공업체 전환에 필요한 코드를 300~400줄에서 한 줄 변경으로 줄이는 인터페이스를 제공한다.
• 약 1년 전: 모든 책상에 에이전트를 두자는 실험은 Sonnet 4가 사용되던 약 1년 전 시작됐다.
• 최대 단계 100: 단일 메가 에이전트 DZero의 실행은 max steps 100으로 구성됐다.
• 약 30% 평가 통과: 초기 제작팀은 DZero가 평가의 약 30%를 맞힌다고 판단하며 성과가 있다고 생각했다.
• 2배 평가 점수: 파일 시스템 에이전트로 전환한 뒤 평가 점수가 사실상 두 배가 됐다.
• 70% 트래픽: 파일 시스템 에이전트의 돌파구를 담은 블로그 글은 게시된 주에 Vercel.com 트래픽의 70%를 차지했다.
• 하루 수천 건: 제약을 풀어 내부에 배포한 뒤 에이전트에는 하루 수천 건의 질의가 들어왔다.
• 약 100개 기술: 반복 질의를 정제한 기술이 집계부터 특정 인물 데이터 조회까지 약 100개 축적됐다.
• 2주 전 공개: Eve는 런던 행사에서 약 2주 전에 정식 공개됐다.
• 약 20개 PMF 에이전트: Vercel 내부에는 마케팅·영업·법무·데이터 과학 등에 적용된 제품-시장 적합성 수준의 에이전트가 약 20개 있다.

결론 및 시사점

1. 에이전트 구축의 출발점: 거대한 프롬프트로 가능성을 확인하되, 실제 업무 단계·실패·반복을 관찰해 필요한 구조를 도출해야 한다.
2. 도구 설계의 원칙: 역할별 도구를 무작정 늘리기보다 모델이 이미 잘 학습한 파일 시스템, 파일 읽기·쓰기, Bash 같은 단순 인터페이스를 작업 공간으로 제공해야 한다.
3. 맥락의 원천: 의미 계층과 시스템 지침만으로는 부족하며, 성공한 실행에서 추출한 기술을 쌓아 매번 빈 상태에서 시작하는 문제를 줄여야 한다.
4. 회사별 차별화: 동일한 Snowflake나 모델을 사용해도 언제 무엇을 조회하고 어떤 데이터가 연결되는지에 관한 회사 고유 지식이 답변 품질을 좌우한다.
5. 프로덕션 조건: 내구성, 재개 가능성, 격리 실행, 모델 폴백, 커넥션, 관찰 가능성, 비용 추적을 프레임워크 수준에서 확보해야 실험이 운영 시스템으로 이어진다.
6. 조직적 효과: 데이터 팀을 반복 질의에서 해방하면 Snowflake 성능 개선, 데이터 소스 확장, 누락 보완 같은 더 높은 가치의 업무에 시간을 재배치할 수 있다.
7. 확장 대상: HR·재무·영업·마케팅·법무에도 반복 조회·검토·보고 업무가 있으므로 업무 특화 에이전트를 만들 여지가 크다.
8. 실행 순서: 작은 실제 문제를 선택하고, 메가 프롬프트로 검증한 뒤, 파일 시스템과 기술 계층을 추가하고, 회사 지식을 넣어 반복 평가하며 프로덕션에 배포해야 한다.

핵심 요약 (20줄)

1. Vercel은 웹사이트 인프라를 단순화해 온 경험을 에이전트 구축 문제에 적용했다.
2. Andrew Qu와 Vercel CTO는 모든 책상에 컴퓨터가 있듯 모든 책상에 에이전트를 두는 가설을 세웠다.
3. Vercel은 마케팅·영업·재무·법무에 업무에서 가장 싫은 일을 물어 데이터 팀의 질의 병목을 찾았다.
4. 첫 데이터 에이전트 실험은 Snowflake 스키마 전체를 시스템 프롬프트에 넣고 모델이 만든 SQL을 직접 실행하는 방식이었다.
5. 거대한 프롬프트는 모델의 SQL 작성 가능성을 검증했지만 맥락 설계와 가드레일이 더 필요하다는 점을 드러냈다.
6. DZero는 질문·계획·실행·SQL·보고를 전담하는 여러 에이전트로 나뉘어 엔드투엔드 업무를 수행했다.
7. 전문 에이전트 체인은 다음 단계에 요약과 일부 결과만 전달해 전체 실행 맥락과 반성 능력을 잃었다.
8. 단일 메가 에이전트는 최대 100단계 동안 상태를 관리하며 SQL이나 조인 오류가 나면 추가 탐색으로 되돌아갔다.
9. 제한된 내부 사용자에게 배포한 결과는 예상 밖 질문 때문에 평가 약 30%의 초기 자신감보다 훨씬 나빴다.
10. Claude Code와 Opus 4.5는 목록·읽기·Bash라는 최소 파일 시스템 도구만으로 기존 에이전트를 크게 앞섰다.
11. Vercel은 의미 계층을 샌드박스에 넣고 Bash·파일 읽기·파일 쓰기를 제공하는 파일 시스템 에이전트를 재구축했다.
12. 파일 시스템 에이전트로 바꾼 뒤 평가 점수는 두 배가 됐고 이를 다룬 블로그 글은 한 주간 Vercel.com 트래픽의 70%를 차지했다.
13. 하루 수천 건의 내부 질의에서 반복 패턴을 추출한 결과 집계와 데이터 조회를 다루는 기술 약 100개가 만들어졌다.
14. 기술은 매번 빈 상태에서 시작하는 에이전트에 이미 검증된 회사 맥락과 작업 절차를 제공한다.
15. Vercel은 파일 시스템 규칙으로 웹 인프라를 선언하는 Next.js의 철학을 에이전트용 프레임워크 Eve에 옮겼다.
16. Eve는 skills·tools·channels 폴더를 조합해 런타임과 채널을 갖춘 에이전트를 만들고 오픈소스 어댑터와 Vercel 기능을 모두 지원한다.
17. Aura는 Eve로 웹사이트를 설치하고 사용해 서비스 품질을 시험하는 미니 Claude Code를 만들어 더 적은 단계와 높은 성공률을 얻었다.
18. Eve의 Vercel 배포는 Workflows·Sandbox·Connect와 기본 관찰 가능성으로 내구성·보안·연결·비용 추적을 제공한다.
19. Snowflake용 기성 에이전트보다 Vercel의 웹 도메인과 데이터 연결 규칙을 담은 자체 에이전트가 더 높은 가치를 냈다.
20. 약 20개의 PMF 에이전트는 데이터 팀을 반복 질의에서 해방하고 HR·재무·영업까지 업무 자동화의 범위를 넓혔다.