Vercel은 AI 에이전트 개발 문제를 어떻게 해결하는가

URL: https://www.youtube.com/watch?v=scnU1ON5wBY
날짜: 2026-09-19
채널: Tech Bridge
영상 ID: scnU1ON5wBY
원문 제목: [한영자막] Vercel은 어떻게 AI 에이전트 개발 문제를 해결했을까요?

메타데이터

• Nuggets 제목: Vercel은 AI 에이전트 개발 문제를 어떻게 해결하는가
• 원문 출연자: Andrew, Vercel Chief of Software
• 핵심 키워드: AI agent, Claude Code, file-system agent, Snowflake, skills, Eve, Next.js, sandbox, durability, observability
• 저장 유형: YouTube 심층 다이제스트

---

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

==AI 에이전트를 단순한 프롬프트나 미리 정해진 체인의 묶음이 아니라, 파일 시스템·도구·회사 고유 지식·실행 런타임을 갖춘 소프트웨어로 만드는 방법은 무엇인가?==

• 거대한 프롬프트에서 시작한 데이터 분석 에이전트는 질문을 처리할 때마다 새로운 오류와 예외를 만났다.
• 전용 에이전트를 여러 단계로 연결하는 방식은 실행 흐름을 만들었지만, 단계 사이에 맥락과 작업 기억이 사라졌다.
• Claude Code에서 얻은 파일 시스템 중심 설계는 에이전트가 스스로 탐색하고 작업물을 남기며 오류에서 회복하도록 만들었고, 평가 점수를 두 배로 높였다.
• 반복된 실행에서 skills를 추출하고 이를 표준화한 프레임워크 Eve는 회사별 지식을 가진 에이전트를 빠르게 만드는 출발점이 되었다.

Vercel의 결론은 범용 수직 에이전트를 사서 설정하는 것보다, 조직의 데이터 구조·업무 규칙·도구 연결을 가장 잘 아는 팀이 자체 에이전트를 구축하는 편이 더 강력하다는 것이다. 좋은 에이전트는 모델 하나가 아니라 지식, 파일 시스템, 안전한 실행 환경, 내구성(durability), 채널, 관찰 가능성(observability)이 결합된 시스템이다.

1. Vercel의 배경과 에이전트로의 전환

Vercel은 인프라를 직접 관리하지 않고도 웹 애플리케이션을 배포하게 하던 회사에서, 에이전트형 애플리케이션을 위한 인프라를 제공하는 회사로 범위를 넓혔다.

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

1. 발표자의 업무 범위

   1. 소프트웨어 총괄: Andrew는 Vercel의 Chief of Software로서 내부 엔지니어링, 외부 실험, 새로운 라이브러리·프레임워크·기술을 만드는 최전선의 일을 함께 맡는다.
   2. 탐험과 제품화의 결합: 내부 팀이 실제로 겪는 문제를 실험하고, 그 결과를 다른 개발자가 사용할 수 있는 도구와 프레임워크로 확장한다.

2. Vercel의 기본 가치

   1. 에이전트형 인프라(Agentic Infrastructure): 사람들이 다음에 등장할 것을 만들 수 있도록 에이전트 구축에 필요한 기반을 제공한다.
   2. 웹에서 시작한 추상화: 초기에는 인프라를 신경 쓰지 않고 웹사이트와 웹 앱을 출시하도록 돕는 데 집중했다.
   3. 탄력적 확장: 서비스는 백만 사용자 규모까지 확장할 수 있고, 사용량이 없으면 손쉽게 0까지 내려간다. 앱의 본질을 개선하지 않는 인프라 운영 부담을 개발자가 직접 떠안지 않도록 하는 방식이다.

1.2. AI 애플리케이션 개발을 위한 기반

1. AI SDK의 공급자 추상화

   1. 교체 비용 절감: 모델 공급자별 코드 300~400줄을 고쳐 쓰는 대신, 한 줄만 변경하면 된다.
   2. 공통 모델 인터페이스: 서로 다른 공급자 뒤에 동일한 모델 인터페이스를 두어 애플리케이션 코드가 공급자 세부 사항에 묶이지 않도록 했다.

2. 에이전트 운영 기능

   1. 모델 폴백(Model Fallbacks): 한 모델이 실패하거나 적합하지 않을 때 다른 모델로 넘길 수 있다.
   2. 보안 실행(Secure Code Execution): 에이전트가 코드를 실행해도 애플리케이션과 격리된 환경을 사용할 수 있다.
   3. 대기 비용 최적화: 모델 응답을 기다리는 동안 비싼 컴퓨팅 자원을 계속 점유하지 않도록 가격 구조와 실행을 최적화한다.
   4. 내구성과 재개(Durability & Resumability): 긴 작업이 중단돼도 처음부터 다시 시작하지 않고 이어서 실행할 수 있다.

1.3. “모든 책상에 에이전트”라는 가설

1. 컴퓨터에서 에이전트로

   1. 과거의 예측: 1980년대 Bill Gates는 모든 책상과 모든 가정에 컴퓨터가 놓일 것이라고 말했다. 당시에는 반직관적인 전망이었지만 지금은 일상적인 현실이 됐다.
   2. 새로운 질문: CTO와 Andrew는 “모든 책상에 컴퓨터”를 넘어 “모든 책상에 에이전트”가 놓일 수 있는지 물었다.

2. 확장되는 적용 분야

   1. 초기 중심 영역: 당시 에이전트는 주로 코딩과 기술적 업무에 사용됐다.
   2. 새로운 업무 영역: 디자인, 제품 관리(Product Management), 기타 직무로 활용이 번지기 시작했다.
   3. 실험 시점: 약 1년 전, 모델이 지금만큼 정교하지 않고 Sonic 4가 언급되던 시기에 Vercel은 이 가설을 실제 회사 업무에 적용하기 시작했다.

2. D0: 데이터 팀의 고통에서 출발한 에이전트

Vercel은 “사람들이 자신의 업무에서 무엇을 가장 싫어하는가?”를 물어 실제 반복 업무를 에이전트로 바꾸는 데서 출발했다.

2.1. 가장 compelling한 문제를 찾는 탐색

1. 직무별 불편 수집

   1. 질문 대상: 마케팅, 세일즈, 재무, 법무 등 여러 직무를 돌아다니며 각 팀이 업무에서 가장 싫어하는 일을 물었다.
   2. 선정 기준: 단순히 흥미로운 자동화가 아니라, 반복 횟수가 많고 팀 생산성을 실제로 깎는 문제를 찾았다.

2. 데이터 팀이 겪던 압박

   1. 린(Lean)한 팀과 급성장하는 회사: 데이터 팀은 작았지만 Vercel은 더 빠르게 성장하고 있었다.
   2. 늘어나는 데이터: 고객 데이터, 분석 데이터, 지표, 세일즈 데이터를 계속 집계하고 팀이 사용할 수 있는 형태로 만들어야 했다.
   3. 문맥 전환의 비용: 마케팅이나 세일즈가 고객·제품에 관해 질문할 때마다 데이터 과학자는 하던 일을 멈추고 쿼리를 작성하고, 처리하고, 분석한 뒤 행동 권고까지 돌려줘야 했다.
   4. 전문성의 낭비: 데이터 과학자는 하루 종일 쿼리를 작성하고 싶어 하지 않았고, 반복적인 요청 때문에 Snowflake 성능 개선 같은 더 중요한 일에 시간을 쓰지 못했다.

2.2. 거대한 프롬프트로 만든 첫 번째 시도

1. 가장 단순한 AI 활용

   1. Mega Prompt: 질문을 언어 모델(Language Model)에 넣고 응답을 받는 거대한 프롬프트부터 시작했다.
   2. Snowflake 스키마 주입: Snowflake 스키마를 통째로 받아 시스템 프롬프트에 붙여 넣었다.
   3. 수동 SQL 실행: 모델이 SQL을 생성하면 직접 복사해 실행하며, 충분한 구조를 줬을 때 유효한 SQL을 만들 수 있는지 먼저 확인했다.

2. 초기 검증에서 얻은 판단

   1. 모델만으로는 부족함: 당시 모델은 그다지 뛰어나지 않았지만, 유효한 SQL을 만들 가능성은 있었다.
   2. 공학적 보완의 여지: 모델 자체를 기다리기보다 컨텍스트를 더 잘 설계하고 가드레일을 추가하면 성능을 끌어올릴 수 있다는 자신감을 얻었다.

2.3. 데이터 과학자의 실제 작업을 분해하다

1. 질문에서 실행까지

   1. 질문 처리: 자연어 질문이 무엇을 묻는지 해석한다.
   2. 시맨틱 레이어 탐색: 의미 계층(Semantic Layer)을 살펴보고 엔티티와 데이터의 관계를 이해한다.
   3. 조인 패턴 결정: 어떤 테이블을 어떻게 조인해야 하는지 파악한다.
   4. SQL 실행: 쿼리를 실행하고 결과를 확인한다.

2. 실패 대응과 보고

   1. 반복 실행: SQL이 실행되지 않거나 비용이 너무 높으면 쿼리를 다시 작성하고 재실행한다.
   2. 결과 보고: 실행 결과를 시각화하고, 설명 문단을 작성하고, 회고(retro)나 추가 분석을 붙인다.
   3. 행동 권고: 데이터 자체를 반환하는 데서 끝나지 않고 무엇을 해야 할지 권고한다.

2.4. D0의 체인형 구조

1. 단계별 에이전트 구성

   1. 질문에서 쿼리로: 사용자가 질문하면 Query Agent가 이를 다음 단계로 넘긴다.
   2. 계획과 실행: Planning Agent가 계획을 세우고 Execution Agent가 실제 작업을 수행한다.
   3. 후속 단계: SQL Agent가 쿼리를 만들고 Reporting Agent가 분석 결과를 보고한다.

2. 역할별 프롬프트와 도구 제한

   1. 좁고 명확한 시스템 프롬프트: 각 에이전트는 자신이 맡은 기능에만 집중하는 전용 시스템 프롬프트를 사용한다.
   2. 기능별 도구: Planning Agent에는 read entity YAML과 search schemas 도구만 주어졌고, 역할에 맞는 능력만 사용하게 했다.
   3. 개선된 자동화: 이전의 수동 복사·붙여넣기에서 벗어나 질문부터 답변 보고까지의 루프가 자동으로 이어졌다.

3. 체인형 아키텍처의 한계와 단일 에이전트

단계별 전문화는 실행 절차를 명확하게 했지만, 에이전트가 전체 작업의 맥락을 기억하고 오류를 복구하는 데는 약했다.

3.1. 체인에서 부딪힌 벽

1. 사라지는 맥락

   1. 요약만 전달: 다음 에이전트가 받는 정보는 이전 에이전트의 요약과 작업 일부를 담은 작은 스니펫뿐이었다.
   2. 전체 과정의 단절: 새 에이전트는 앞선 단계에서 어떤 탐색과 판단을 거쳤는지 전체 흐름을 볼 수 없었다.

2. 작업 기억의 필요성

   1. 회고와 반성: 에이전트는 자신이 지금까지 어떤 단계로 왔는지 되돌아보고, 현재 결과에 이른 경로를 반성할 수 있어야 했다.
   2. 동적 상태 관리: 계획, 구축, 실행, 보고를 고정된 순서의 별도 상자가 아니라 하나의 실행 상태 안에서 오갈 필요가 있었다.

3.2. 하나의 Mega Agent로 재설계

1. 자기 상태를 관리하는 에이전트

   1. 통합 컨텍스트: 하나의 에이전트 안에 거대한 컨텍스트를 넣고 스스로 메모리를 관리하게 했다.
   2. 상태 전환: 어떤 순간에는 계획하고, 다음 순간에는 만들고, 실행 중에는 도구를 쓰고, 마지막에는 보고하는 식으로 같은 에이전트가 역할을 전환했다.
   3. 실행 예산: 한 번의 큰 AI 호출에 최대 100단계(max steps 100)를 허용했다.

2. 실패에서 되돌아오는 흐름

   1. 오류 재탐색: 조인이나 실행에서 오류가 나면 처음부터 실패로 끝내지 않고 더 많은 정보를 탐색한다.
   2. 추가 읽기: 무엇을 잘못했는지 알아내기 위해 스키마와 관련 자료를 더 읽은 뒤 계획을 수정한다.
   3. 유연성의 대가: 이 구조는 훨씬 유능했지만, 어떤 질문이 들어올지 예측하기 어려워 평가 사례를 사람이 일일이 매핑하는 방식은 확장되지 않았다.

3.3. 첫 사용자 테스트가 드러낸 현실

1. 신뢰된 소수에게 먼저 공개

   1. 제한적 배포: 강력한 도구를 중요한 업무에 바로 넣지 않기 위해 신뢰할 수 있는 소수의 팀원에게만 공개했다.
   2. 기대: 내부 평가에서 약 30%를 맞히는 수준이라고 생각하며 상당히 잘 만들었다고 판단했다.

2. 즉각적인 실패 피드백

   1. 예상 밖의 질문: 실제 사용자는 제작자가 상상하지 못한 질문을 던졌고, 결과는 “끔찍했다”는 평가를 받을 정도였다.
   2. 확장 불가능한 수동 보완: 새로운 시나리오를 사람이 계속 찾아 시스템에 매핑하는 방식은 사용자와 질문이 늘어날수록 유지할 수 없었다.

4. Claude Code에서 발견한 파일 시스템 에이전트

Claude Code와 Opus 4.5의 결합은 Vercel이 에이전트 설계의 중심을 전용 도구 체인에서 파일 시스템으로 옮기는 계기가 됐다.

4.1. “AGI처럼 보인” 비교 경험

1. 기존 핸드메이드 에이전트와의 차이

   1. 비약적인 응답 품질: Claude Code와 Opus 4.5는 Vercel이 직접 만든 에이전트가 놓치던 질문 대부분에 거의 멈춤 없이 답했다.
   2. 기존 접근의 재검토: 왜 같은 모델 기반 시스템이 이렇게 다른지 되짚으면서 핵심 차이가 모델의 이름보다 작업 환경에 있다는 결론에 도달했다.

2. 파일 시스템이 만든 해방

   1. 최소 도구 세트: 파일 목록 보기(list file), 파일 읽기(read file), Bash 실행(run bash)처럼 매우 적은 도구만 제공했다.
   2. 확장 도구: 데이터 에이전트에 필요한 Vercel 전용 도구 몇 개만 추가했다.
   3. 탐색과 작업물: 에이전트는 필요한 곳을 탐색하고, 필요한 작업을 파일로 작성하며, 기존 결과를 다시 읽을 수 있었다.

4.2. 처방형 도구에서 탐색형 환경으로

1. 기존 방식의 문제

   1. 과도한 처방: Vercel은 에이전트가 어떤 순서로 어떤 전용 도구를 써야 하는지 너무 구체적으로 설계했다.
   2. 예외에 취약함: 제작자가 예상하지 못한 질문과 경로가 나오면 사전에 정의한 체인이 쉽게 막혔다.

2. Claude Code식 설계의 장점

   1. 훈련된 행동과의 정렬: 모델이 이미 잘 훈련된 파일 목록·읽기·쓰기·Bash 도구를 그대로 쓸 수 있었다.
   2. 비처방적 실행: 특정 도구를 특정 순서로 강제하지 않고, 에이전트가 필요에 따라 탐색하는 창발적 행동(emergent behavior)을 허용했다.
   3. 로컬 실행의 힘: 실행 환경을 로컬처럼 다루며 파일과 명령어를 조합할 수 있다는 점이 성능의 큰 열쇠가 됐다.

4.3. 샌드박스 기반 파일 시스템 에이전트

1. 재구축 방식

   1. 격리된 샌드박스: 에이전트를 샌드박스에서 실행했다.
   2. 시맨틱 레이어 투입: Vercel의 전체 시맨틱 레이어를 샌드박스 안에 넣어 필요한 자료를 직접 찾게 했다.
   3. 기본 조작: grep, bash, 파일 읽기, 파일 쓰기를 이용해 주변 자료를 조사하고 작업을 남기게 했다.
   4. Vercel 특화 도구: 범용 파일 시스템 위에 Vercel 업무에 꼭 필요한 소수의 도구만 얹었다.

2. 평가와 구현 결과

   1. 세 단계의 도약: 단일 에이전트에서 Claude Code SDK로, 다시 특정 업무에 맞춘 파일 시스템 에이전트로 넘어가며 성능이 크게 뛰었다.
   2. 평가 점수 두 배: 이전 방식에서 실패하던 질문을 통과하기 시작하면서 평가 점수가 사실상 두 배가 됐다.
   3. 단순한 코드 구조: npm의 bash tool 헬퍼를 샌드박스에 연결하고, 읽기·쓰기·실행할 파일을 첨부하는 정도로 핵심 구현이 가능했다.

4.4. 실험이 외부 관심으로 이어지다

1. 블로그 공개

   1. 성공 경험의 글쓰기: 파일 시스템 에이전트의 성과를 확인한 뒤 이를 설명하는 강한 반응의 블로그 글을 작성했다.
   2. 트래픽 효과: 글을 쓴 그 주에 해당 글이 vercel.com 전체 트래픽의 70%를 차지했다.

2. 사내 확산 준비

   1. 사용자 확대: 더 많은 Vercel 구성원에게 넘길 준비가 됐다.
   2. 자율 사용: 이후에는 에이전트를 Vercel 전체에 사실상 풀어 주고 각 팀이 실제 업무에 활용하게 했다.

5. 반복 실행에서 지식으로: Skills

에이전트 실행을 늘리자 매번 무지한 상태에서 출발하는 문제와 반복되는 질문의 형태가 보였고, Vercel은 이를 재사용 가능한 스킬로 추출했다.

5.1. 수천 건의 질문에서 패턴 찾기

1. 실제 사용량

   1. 질문 규모: Vercel 구성원은 하루 수천 건의 쿼리를 요청했다.
   2. 업무 범위: 고객 지표, 세일즈 지표, 각종 수치, NPM 다운로드, 특정 사람에 관한 정보 조회까지 질문 종류가 넓었다.

2. 반복되는 형태

   1. 집계의 한정된 패턴: 데이터를 집계하는 방법은 무한히 많아 보이지만 실제 업무에서 반복되는 형태는 제한적이었다.
   2. 조회 패턴: 제품 정보 조회와 청구 정보 조회도 자주 같은 구조로 반복됐다.
   3. 자동 발견: 최근 질문을 가져와 공통된 해결 절차를 하나의 스킬로 정제하는 recurring job을 만들었다.

5.2. 스킬 폴더의 역할

1. 스킬의 구성

   1. 재사용 지식: 스킬은 단순 프롬프트가 아니라 특정 집계, 조회, 사람별 데이터 확인에 필요한 맥락과 작업 절차를 담는다.
   2. 범위: 현재 약 100개의 스킬이 집계부터 특정 인물에 대한 데이터 조회까지 이어지는 업무를 처리한다.

2. 매 실행의 출발점 개선

   1. 스킬이 없을 때: 새 에이전트 실행은 시맨틱 레이어와 시스템 프롬프트 외에 미리 가진 맥락이 거의 없다.
   2. 스킬이 있을 때: 과거에 해결한 지식과 패턴을 미리 제공하므로, 동일 문제를 처음부터 다시 탐색하지 않는다.
   3. 구조적 단순성: 기존 파일 시스템 구조에 skills 폴더를 추가하는 것만으로도 이 효과를 얻었다.

5.3. 개인 실험에서 조직 표준으로

1. 스킬 공유 도구

   1. skills.sh: Vercel은 에이전트 스킬을 찾고 직접 실행할 수 있는 skills.sh도 만들었다.
   2. 확산 목적: 한 팀의 해결책을 다른 에이전트와 개발자가 재사용할 수 있는 발견·실행 경로로 바꿨다.

2. 점진적 복잡성에서 얻은 교훈

   1. 단순함에서 출발: 처음에는 단순 프롬프트로 시작한다.
   2. 실패를 통한 추가: 실제 질문에서 실패할 때마다 필요한 도구, 파일, 지식, 실행 기능을 추가한다.
   3. 프로덕션 도달: 반복적인 개선 끝에 운영 환경에 배포할 수 있는 시스템이 된다.
   4. 사내 포크: 각 단계에서 Vercel의 에이전트에 관심 있는 사람이 D0를 포크해 자신의 에이전트를 만들었고, 매번 이전에 없던 더 나은 해결 방법을 발견했다.

6. Next.js for Agents: Eve의 탄생

Vercel은 개별 팀이 시행착오의 처음부터 반복하지 않도록, 마지막에 얻은 에이전트 구축 원칙을 프레임워크로 패키징했다.

6.1. Next.js의 파일 시스템 철학을 에이전트에 적용

1. Next.js가 숨긴 인프라

   1. 파일 시스템 기반 선언: 개발자는 올바른 규칙에 맞춰 파일을 작성하기만 하면 되고, 파일이 어디에서 실행될지 직접 배치하지 않아도 된다.
   2. 자동 라우팅과 배치: 페이지는 CDN으로, 서버리스 함수는 적절한 실행 위치로, 캐시는 중간 계층으로 자동 연결된다.

2. 에이전트의 규칙 기반 구성

   1. 필요한 폴더: skills 폴더, tools 폴더, channels 폴더를 만들면 된다.
   2. 선언적 조립: 프레임워크가 폴더와 파일을 보고 지식, 도구, 채널을 가진 에이전트로 조립한다.
   3. 목표: 프롬프트 하나에서 출발해 매번 원칙을 재발명하는 대신, 마지막에 얻은 최선의 설계에서 시작하게 한다.

6.2. Eve의 공개와 기본 구조

1. Eve의 성격

   1. 출시 시점: 런던 이벤트에서 정식 공개하기 약 2주 전에 Eve를 발표했다.
   2. 정의: Eve는 에이전트를 위한 Next.js에 해당하는 프레임워크다.
   3. 시작 경험: 샘플 템플릿을 복제해 곧바로 실행 가능한 에이전트를 만들고, 이후 고유 지식과 도구, 익숙한 채널을 붙인다.

2. 에이전트의 두 축

   1. 런타임(Runtime): 내구성 있는 실행, 격리된 환경, 여러 모델 호출, 외부 연결을 담당한다.
   2. 채널(Channels): 에이전트가 사용자를 만나고 업무 결과를 전달하는 인터페이스를 담당한다.
   3. 필수 런타임 능력: 중단 후 재개할 수 있어야 하고, 안전한 격리 환경에서 실행하며, 필요에 따라 다른 모델과 연결해야 한다.

6.3. 오픈소스와 Vercel 배포의 공존

1. 오픈소스 어댑터

   1. 데이터베이스: Postgres 어댑터를 연결할 수 있다.
   2. 모델 API: OpenAI Responses API 어댑터를 사용할 수 있다.
   3. 실행과 연결: Docker 등 다른 커넥터와 오픈소스 어댑터를 조합할 수 있다.
   4. 자체 호스팅: Vercel에 묶이지 않고 필요한 경우 직접 호스팅할 수 있다.

2. Vercel 제품과의 통합

   1. Vercel Workflows: 긴 에이전트 작업의 durability를 제공한다.
   2. Vercel Sandbox: 코드와 명령을 안전하게 격리해 실행한다.
   3. Vercel Connect: 새로 공개한 기능으로 연결에 필요한 단기 OIDC 토큰을 쉽게 발급한다.
   4. 배포 선택권: 개발자는 오픈소스 구성 요소를 선택하면서도 Vercel 제품을 이용해 배포 복잡성을 줄일 수 있다.

6.4. D0를 Eve로 다시 만들다

1. 복잡성의 표면화

   1. 기존 시스템의 내부 복잡성: D0는 겉으로 보이지 않는 뒤편에 복잡한 구조가 많았다.
   2. 새 구조: Eve로 다시 작성하면서 시스템 지침, 몇 개의 스킬, 몇 개의 도구만 파일 시스템에 배치하는 형태로 바뀌었다.

2. 개발 효과

   1. 쉬운 조합: 지침, 지식, 도구를 실제 에이전트로 조립하기 쉽다.
   2. 쉬운 반복: 파일을 수정하고 필요한 스킬이나 도구를 추가하는 방식으로 빠르게 반복할 수 있다.
   3. 프레임워크 검증: 복잡한 실전 데이터 에이전트를 Eve로 옮길 수 있었으므로, 단순한 데모 이상의 설계라는 점을 확인했다.

7. 베타 고객과 운영 가시성

Eve는 정식 공개 전에 고객에게 전달됐고, 실제 서비스 테스트에서 오프더셸프 에이전트보다 짧은 실행과 높은 성공률을 보였다.

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

1. Aura의 사용 사례

   1. 미니 클로(mini claw): Aura는 사람들의 서비스를 시험하는 일종의 작은 클로 에이전트를 만들었다.
   2. 웹사이트 상호작용: 에이전트가 웹사이트에 방문하고, 서비스를 설치하고, 실제로 사용해 보며 품질을 점검한다.

2. 비교 결과

   1. 구축 방식: Aura는 오프더셸프 Claude Code를 그대로 쓰는 대신 Eve로 에이전트를 처음부터 다시 만들었다.
   2. 효과: 필요한 단계 수가 줄었고, 성공률이 더 높았으며, 실행 과정에서 얻는 인사이트도 더 많았다.

7.2. 배포 즉시 제공되는 Observability

1. 실행 추적

   1. 전체 실행 목록: 어떤 에이전트 실행이 있었는지 한 곳에서 확인한다.
   2. 도구 호출: 각 실행에서 어떤 도구가 호출됐는지 볼 수 있다.
   3. 단계별 경로: 에이전트가 어떤 순서로 각 단계를 밟았는지 확인한다.

2. 운영 최적화

   1. 예상 비용: 실행별 예상 비용을 확인할 수 있다.
   2. 개선 지점: 비용과 실행 경로를 바탕으로 어떤 최적화를 적용할지 찾을 수 있다.
   3. 시작 방법: eve.dev에서 템플릿을 복제하고 쉽게 배포하거나, 필요하면 자체 호스팅할 수 있다.

8. 범용 수직 에이전트보다 회사 고유 에이전트

데이터베이스 종류만 아는 에이전트보다 특정 조직의 데이터 의미와 의사결정 규칙을 아는 에이전트가 훨씬 유용하다.

8.1. 오프더셸프 수직 에이전트의 한계

1. Vercel의 사전 검증

   1. 대상 제품: Vercel은 Snowflake 인스턴스에 연결해 쿼리를 실행해 주는, 자금력이 큰 수직 에이전트 스타트업들을 여러 곳에서 시험했다.
   2. 일반 기능: 이 제품들은 Snowflake에 쿼리를 실행하는 기본 능력을 잘 제공했다.

2. 빠진 맥락

   1. 회사 지식의 깊이: 좋은 에이전트는 특정 회사의 데이터와 업무 맥락을 아주 많이 알아야 한다.
   2. 웹 기업의 특수성: Vercel에는 웹사이트와 웹 자산을 가진 고객이 많다.
   3. 관계와 선택 규칙: 어떤 상황에서 어떤 데이터를 조회해야 하는지, 어떤 웹 속성과 다른 속성이 어떻게 연결되는지까지 알아야 한다.

8.2. 자체 구축의 가치

1. 가장 많은 효과를 얻는 방법

   1. 자체 에이전트: 범용 제품을 시험하는 데서 멈추지 말고, 조직이 직접 에이전트를 만들어야 한다.
   2. 고유 지식 주입: 회사의 데이터 구조, 업무 규칙, 도메인 용어, 과거 해결 사례를 가능한 한 많이 넣을수록 성능이 좋아진다.

2. Vercel의 실제 포트폴리오

   1. 규모: Vercel에는 약 20개의 꽤 쓸 만하고 제품-시장 적합성(PMF)을 보이는 에이전트가 있다.
   2. 마케팅: 마케팅 회고(retro)를 수행한다.
   3. 세일즈: 누구에게 먼저 연락할지 찾아준다.
   4. 법무: 새로운 계약 협상에서 법무팀이 보는 첫 번째 레드라인(redline)을 만든다.
   5. 데이터 과학: 데이터 질문을 분석하고 쿼리 결과를 보고한다.

8.3. 조직 생산성의 변화

1. 데이터 팀의 회복

   1. 생산성 향상: 데이터 팀은 과거보다 훨씬 생산적으로 일하게 됐다.
   2. 고부가 작업으로 이동: 반복 쿼리를 쓰는 대신 Snowflake 성능을 개선하고, 새로운 데이터 소스를 추가하고, 예전에는 메우지 못했던 데이터 공백을 채울 시간이 생겼다.

2. 다른 부서로의 확장

   1. 자동화 후보: HR, 재무, 세일즈 업무 중 반복적이고 시간이 과도하게 드는 일은 에이전트로 자동화할 수 있다.
   2. 회사 규모와 무관한 접근: 큰 회사, 작은 회사, 중간 규모 회사 모두 원하지 않거나 너무 많은 시간을 빼앗는 일을 자동화할 수 있다.
   3. 현재의 선택지: Andrew는 현재 이러한 업무용 에이전트를 만드는 가장 좋은 방법으로 Eve를 제시한다.

주요 발언 모음

“Instead of a computer on every desk, could we potentially have an agent on every desk?”

“The biggest unlock was that it was just a file system.”

“You should only have to create a skills folder, a tools folder, a channels folder, and the framework should know exactly how to make an agent out of it.”

“What really makes this agent good is a lot of very specific company knowledge.”

“The data team has never been more productive.”

핵심 데이터 & 수치

• 300~400줄 → 1줄: AI SDK는 공급자별 코드를 대체하는 변경 지점을 한 줄로 줄인다.
• 0~100만 규모: Vercel의 웹 인프라는 사용량이 0까지 내려갔다가 백만 규모로 확장될 수 있다.
• 최대 100단계: Mega Agent의 한 실행에 허용한 최대 단계 수(max steps 100)다.
• 약 30%: 초기 내부 평가에서 D0가 맞힌다고 기대했던 수준이다.
• 2배: 파일 시스템 에이전트로 전환한 뒤 평가 점수가 대략 두 배가 됐다.
• 70%: 파일 시스템 에이전트 블로그 글이 작성된 주에 vercel.com 전체 트래픽에서 차지한 비중이다.
• 하루 수천 건: Vercel 전체에 에이전트를 풀었을 때 들어온 데이터·고객·세일즈 관련 질문 규모다.
• 약 100개: 반복 질문에서 추출해 운영한 스킬 수다.
• 약 2주: Eve가 런던 이벤트에서 정식 출시되기 전 공개된 시점이다.
• 약 20개: Vercel 내부에서 꽤 괜찮은 PMF를 보이는 업무별 에이전트 수다.
• 3개 폴더: Eve가 기본적으로 skills, tools, channels를 통해 에이전트를 선언하도록 한 구조다.
• 핵심 제품 3개: Vercel Workflows는 내구성, Vercel Sandbox는 보안 실행, Vercel Connect는 단기 OIDC 연결을 담당한다.

결론 및 시사점

1. 거대한 프롬프트는 가능성을 확인하는 첫 실험으로는 유용하지만, 실제 업무를 안정적으로 자동화하려면 작업 단계를 구조화하고 실행 환경을 제공해야 한다.
2. 전용 에이전트를 여러 개 체인으로 연결하면 역할은 명확해지지만, 요약만 전달되는 과정에서 전체 맥락과 작업 기억이 사라지므로 오류 회복이 어렵다.
3. 하나의 에이전트가 파일 시스템을 읽고 쓰며 Bash를 실행하도록 하면, 모델은 사전에 예측하지 못한 질문도 탐색하고 결과를 작업물로 남길 수 있다.
4. 도구를 지나치게 처방하기보다 잘 훈련된 최소 도구 세트와 탐색 가능한 환경을 주는 편이 창발적 문제 해결에 유리하다.
5. 반복 실행에서 발견한 해결 절차를 skills로 추출하면 에이전트가 매번 무지한 상태에서 출발하는 비용을 줄일 수 있다.
6. Next.js의 파일 시스템 규칙처럼 skills, tools, channels 폴더를 선언하는 방식은 복잡한 런타임을 개발자에게 숨기고 에이전트 조립을 단순하게 만든다.
7. 오픈소스 어댑터와 자체 호스팅을 허용하면서 Workflows, Sandbox, Connect를 선택적으로 제공하면 프레임워크의 개방성과 관리형 배포의 편의성을 함께 얻을 수 있다.
8. 범용 Snowflake 에이전트가 기본 쿼리는 처리해도, 어떤 데이터를 언제 조회할지 결정하는 회사 고유 지식까지 대체하지는 못한다.
9. 에이전트 도입의 가장 큰 효과는 사람을 모두 대체하는 것이 아니라 반복 쿼리와 초안 작성에서 사람을 해방해 성능 개선, 새 데이터 소스, 전략적 판단에 집중하게 하는 것이다.
10. AI 에이전트의 경쟁력은 모델 이름 하나보다 조직의 지식, 실행 가능한 파일 시스템, 안전한 샌드박스, 내구성, 관찰 가능성을 얼마나 잘 결합하느냐에서 나온다.

핵심 요약 (20줄)

1. Vercel은 웹 인프라 회사에서 에이전트형 애플리케이션을 위한 인프라와 프레임워크를 만드는 회사로 확장했다.
2. AI SDK는 모델 공급자별 300~400줄의 코드를 한 줄 교체로 줄여 다양한 모델을 같은 인터페이스로 사용하게 한다.
3. Vercel은 모든 책상에 컴퓨터가 놓인 것처럼 모든 책상에 에이전트가 놓일 수 있는지를 실험했다.
4. 여러 직무의 불편을 조사한 결과, 급성장하는 Vercel의 린한 데이터 팀이 반복 쿼리 요청으로 가장 큰 생산성 손실을 겪고 있었다.
5. 첫 데이터 에이전트는 Snowflake 스키마를 거대한 시스템 프롬프트에 넣고 생성된 SQL을 사람이 복사해 실행하는 수준이었다.
6. 데이터 과학자의 업무는 질문 해석, 시맨틱 레이어 탐색, 조인 결정, SQL 실행, 오류 재실행, 결과 보고로 세분화됐다.
7. D0는 Query, Planning, Execution, SQL, Reporting 역할을 가진 에이전트를 체인으로 연결해 질문부터 답변까지 자동화했다.
8. 체인형 구조는 단계 사이에 요약과 작은 스니펫만 전달해 전체 과정의 맥락과 작업 기억을 잃는 한계가 있었다.
9. 단일 Mega Agent는 최대 100단계 안에서 계획, 구축, 실행, 보고 상태를 스스로 관리하고 오류가 나면 다시 탐색했다.
10. 내부 평가에서 잘 작동한다고 생각한 D0는 실제 사용자의 예상 밖 질문을 만나자 신뢰된 소수에게도 끔찍한 결과를 보였다.
11. Claude Code와 Opus 4.5는 목록, 읽기, Bash 실행 같은 최소한의 파일 시스템 도구만으로 훨씬 폭넓은 질문을 처리했다.
12. Vercel은 전체 시맨틱 레이어를 샌드박스에 넣고 grep, Bash, 파일 읽기와 쓰기를 허용하는 파일 시스템 에이전트를 재구축했다.
13. 파일 시스템 접근으로 전환한 뒤 D0의 평가 점수는 대략 두 배가 됐고 구현도 Bash 도구와 샌드박스 연결만큼 단순해졌다.
14. 이 경험을 설명한 블로그 글은 작성된 주에 Vercel 웹사이트 전체 트래픽의 70%를 차지했다.
15. 사내에서 하루 수천 건의 질문이 쌓이자 Vercel은 반복되는 집계, 제품 조회, 청구 조회 패턴을 약 100개의 스킬로 추출했다.
16. 스킬 폴더는 새 실행에 회사 고유의 과거 지식과 해결 절차를 미리 제공해 매번 처음부터 탐색하는 비용을 줄였다.
17. Vercel은 Next.js처럼 폴더 규칙만으로 에이전트를 조립하는 프레임워크 Eve를 공개하고 skills, tools, channels 구조를 제시했다.
18. Eve는 Workflows, Sandbox, Connect와 오픈소스 Postgres, OpenAI Responses API, Docker 어댑터를 함께 사용할 수 있다.
19. Aura는 Eve로 웹사이트를 설치하고 사용해 보는 에이전트를 만들어 오프더셸프 Claude Code보다 적은 단계와 높은 성공률을 얻었다.
20. 가장 강력한 에이전트는 범용 제품이 아니라 회사의 데이터 의미와 업무 규칙을 깊이 아는 자체 에이전트이며, Vercel에는 약 20개가 운영되고 있다.