출처 https://www.youtube.com/watch?v=scnU1ON5wBY · 채널 Tech Bridge (원본: AI Engineer World’s Fair, 2026-09-14) · 길이 00:17:06 포맷 발표자 1인의 슬라이드 강연. 검은 배경의 코드·다이어그램 슬라이드가 뼈대고, 아키텍처 진화도·Eve 구조도·관측가능성 대시보드 데모가 하이라이트. 원본 자막:
raw/transcripts/2026-09-20-vercel-eve-file-system-agent.en.srt(YouTube 영어 자동자막 — 한국어 자막은 API 429로 수집 실패)
한눈에 보는 요약
- 출발점은 사내 병목이었다. Vercel 데이터 팀은 린(lean)한 조직인데 전사 질문(고객 지표·매출·분석)이 쏟아지자 매번 수작업 쿼리로 대응하느라 병목이 됐고, Andrew Qu는 VP of data와 함께 데이터 사이언스 에이전트 D0를 만들기 시작했다.
- D0는 세 번 진화했다. ① Snowflake 스키마+질문을 한 프롬프트에 때려넣는 메가 프롬프트 → ② 질의·계획·실행·보고 에이전트를 체인으로 잇고 도구까지 역할별로 고정한 서브에이전트 구조 → ③ 메가 컨텍스트를 통째로 가진 단일 에이전트가 스스로 상태를 관리하며 계획·실행·보고 모드를 오가는 구조.
- 서브에이전트 체인의 한계는 명확했다. 다음 에이전트가 받는 것은 이전 단계의 짧은 요약과 조각뿐이라, 실행 에러가 나면 돌아가 탐색하고 고치는 일이 안 됐다. 공유 컨텍스트·같은 루프(shared context / same loop)로 바꾼 버전 3이 그 해법이었다.
- 내부 평가 30%의 함정. 내부 eval을 30%나 통과했다고 자축했지만 첫 실무 배포 반응은 “awful”이었다. 실제 질문의 분포를 미리 매핑하는 방식으론 확장할 수 없다는 쓰라린 교훈.
- 결정적 돌파구는 Claude Code + Opus 4.5가 보여준 파일 시스템 에이전트였다. 복잡한 전용 도구 대신
list/read file, grep, bash같은 최소 도구 + 샌드박스에 통째로 넣은 시맨틱 레이어 + 소수의 Vercel 전용 도구. eval 점수가 두 배로 뛰었다. - 반복 질의는 스킬로 자산화한다. 전사 배포 후 하루 수천 건 질의가 오자, 모양이 같은 질의(집계·제품 조회·빌링 등)를 주기적 배치 작업으로 스킬 폴더에 증류 — 현재 약 100개 스킬. 매 실행이 빈손에서 시작하는 문제를 완화한다.
skills.sh도 함께 소개. - 마지막 통찰이 Eve다. 매 단계마다 누군가 D0를 포크해 처음부터 시행착오를 반복하자, “마지막 통찰부터 시작하게 하자”는 생각으로 파일 시스템 컨벤션(skills·tools·channels 폴더 선언 → 프레임워크가 에이전트로 조립)의 에이전트를 위한 Next.js Eve를 출시.
eve.dev에서 시작 가능.
핵심 한 줄: 메가 프롬프트도 서브에이전트 체인도 실전에선 무너졌고, 파일 시스템+최소 도구+사내 지식(스킬)이 D0를 살렸으며, 그 조립법을 프레임워크로 굳힌 것이 Eve다.
장면별 상세 설명
[00:20] 1. 오프닝 — We Solved Agent Building
발표자는 Vercel 소프트웨어 총괄 Andrew Qu. “how we solved agent building at Vercel”이 주제다. 자기 역할은 내부 엔지니어링과 외부 실험을 오가며 새로운 라이브러리·프레임워크·기술의 최전선에 있는 것이라고 소개한다. Vercel은 “agentic infrastructure so people can build what’s next” — 웹 시절엔 인프라 걱정 없이 배포하게 했다면, 지금은 사람들이 만들고 싶어 하는 것이 바뀌는 중이다.
[01:30] 2. 배경 — 내부 실험이 에이전트 폭발로 이어졌다
슬라이드에는 Vercel이 깔아둔 인프라 6종이 뜬다. AI SDK(통합 모델 접근 툴킷), AI Gateway(수백 모델, API 키 불필요), Fluid Compute(실사용 CPU 과금), Sandbox(빠르고 안전한 코드 실행), Workflow(TypeScript 함수를 durable하게), Chat SDK(하나의 코드베이스로 모든 채팅 플랫폼). 모델 폴백·안전한 코드 실행을 쉽게 하는 도구들을 직접 만들었고, 이 실험이 사내 에이전트 폭발과 오늘 발표할 “최근에 만든 멋진 것”으로 이어졌다는 것이 서사의 출발점이다.
[02:45] 3. 문제 — 데이터 팀이 사내 병목이 된 이유
1980년 빌 게이츠의 “every desk and in every home”을 빌려 “could we have an agent on every desk?”라는 질문을 던진다. 코딩·기술 workloads에만 쓰던 에이전트가 디자인·PM 등 버티컬로 확장되던 시점(약 1년 전)의 이야기다. 가장 설득력 있던 유스케이스는 데이터 팀이었다. Vercel이 팀보다 빨리 성장하면서 고객·분석·메트릭·매출 데이터가 쏟아졌고, 마케팅·세일즈가 뭘 물을 때마다 데이터팀이 하던 일을 멈추고 쿼리를 짜서 분석·추천까지 돌려줘야 했다. 쿼리만 종일 짜고 싶지 않은 데이터팀과 VP of data가 함께 “더 나은 운영 방식”을 만들기로 한 것이 D0의 시작이다. 2026-09-16-ai-engineer-3-tier-skills의 “DB 조회·시각화까지 하는 에이전트” 수요 관측과 같은 결이다.
[03:50] 4. 버전 1 — 거대한 메가 프롬프트
AI로 문제를 풀 때 누구나 처음 하는 것 — 질문을 LM에 던지는 거대 프롬프트 한 방. 화면의 코드는 d0/agent.ts로, generateText({ model, prompt: 'You are an expert data scientist, write a valid SQL query given the user question and schemas <Schemas>${getSchemas()}...' }) 구조다. Snowflake 스키마 덤프를 시스템 프롬프트에 붙여넣고, 생성된 SQL은 직접 복사해 실행해봤다. “모델이 되긴 되는가”를 확인하는 단계였고, 당연히 가드레일·반복·검증이 없어 실전과는 거리가 멀었다.
[05:20] 5. 버전 2 — 역할별 에이전트 체인 D0
데이터 사이언티스트의 실제 단계를 매핑했다. 질문 처리 → 시맨틱 레이어 탐색·조인 패턴 파악 → SQL 실행(실패·고비용이면 재시도) → 리포트(시각화·문단·회고). 각 단계를 전용 시스템 프롬프트+역할 고정 도구(agent-scoped tools)를 가진 에이전트로 나눠 체인으로 이었다. 화면 코드의 도구 배분이 그대로 드러난다 — query는 ReadEntityYaml, SearchSchemas, planning은 AssessEntityCoverage, BuildPlan, SQL은 BuildSQL, SyntaxValidator, reporting은 ExecuteSQL, FormatResults, VisualizeData. 슬라이드 제목은 “More agents, more problems”로, 에이전트를 늘릴수록 문제도 늘어난다는 복선이다.
[06:05] 6. 버전 3 — One agent, many modes
체인 구조의 벽에 부딪혀 내린 결론 — “메가 컨텍스트를 통째로 가진 하나의 에이전트가 스스로 메모리를 관리해야 한다”. 다이어그램의 핵심은 Shared context / same loop 박스다. 사용자 질문이 들어오면 같은 루프 안에서 Query·Execution·Planning·Reporting 모드를 오가고, Execution 실패 시 retry로 Planning으로 돌아간다. 이전 모델에선 다음 에이전트가 이전 작업의 짧은 요약과 조각만 받았지만, 이제 에이전트는 자신이 실행 여정의 어디에 있는지 돌아보고(reflect), 에러가 나면 탐색으로 돌아가 더 읽고 고칠 수 있다. 도구 모양은 비슷하지만 상태 관리의 주체가 프레임워크(체인)에서 에이전트 자신으로 넘어간 것이 차이점이다. moc-ai-agents의 루프·하네스 논의와 직접 연결되는 대목이다.
[07:10] 7. 쓰라린 첫 배포 — 내부 평가 30%의 함정
“nailing 30% of our evals”라 생각하며 요리 중이라 믿었지만, 몇 명의 손에 쥐여주자 반응은 즉각 “awful”이었다. 예상 못 한 질문들이 쏟아졌고, 시나리오를 일일이 손으로 매핑하는 방식으론 확장 불가능하다는 것이 드러났다. 화면에는 모드별 시스템 프롬프트·활성 도구를 고르는 prepareStep/getMode 코드(d0/activeTools.ts)가 뜬다 — 체인에서 단일 에이전트로 넘어가는 과도기의 복잡성이 코드에 그대로 남아 있다. 2026-09-09-cursor-poteto-agent-trust의 eval·검증 스킬 교훈과 대조해서 볼 장면이다.
[08:35] 8. 돌파구 — You can just use a File System
전환점은 Claude Code와 Opus 4.5였다. “우리가 손으로 키운 에이전트와 비교하면 basically AGI” — 묻는 것마다 놓치지 않고 답했다. 핵심 깨달음은 파일 시스템이었다. 최소 도구(list/read file, grep, bash 실행)에 시맨틱 레이어 전체를 덤프한 샌드박스, 그 위에 Vercel 전용 소수 도구만 얹는다. 에이전트가 이미 잘 학습된 도구로 로컬에서 실행하니 강력했다. 단일 에이전트→Claude Code SDK→용도에 맞춘 파일 시스템 에이전트의 도약이 “biggest unlock ever”였고, 이때 eval 점수가 사실상 두 배가 됐다. moc-claude-code의 파일 시스템 에이전트 패턴과 같은 이야기다.
[10:05] 9. 반복 질의의 자산화 — Patterns show up
전사에 풀자 하루 수천 건 질의(고객·매출·수치·NPM 다운로드 등)가 쏟아졌다. 그런데 질의 모양은 생각보다 한정적이다 — 집계·제품 조회·빌링 조회는 패턴이 몇 가지 안 된다. 그래서 최신 질의를 가져와 스킬로 증류하는 반복 배치를 돌린다. 슬라이드는 다섯 가지 대표 질의(“which table has revenue”, “what was product X growth like MoM”, “why did this metric spike” 등)가 Data agent→Distill→Skill로 모이는 구조다. 현재 약 100개 스킬이 집계부터 특정 인물·데이터 조회까지 커버한다. 매 실행이 빈손(사전 컨텍스트 없음)에서 시작하는 문제를 스킬 폴더가 메워주는 셈이다. 에이전트 스킬 탐색·실행 플랫폼 skills.sh도 “가장 인기 있는 방법”으로 함께 언급된다. moc-ai-agents-memory의 스킬·컨텍스트 논의와 이어진다.
[11:10] 10. 여정의 지도 — Simple Prompt에서 ???까지
여정을 한 장에 압축한 사다리. Simple Prompt → Subagents → One agent, many modes → Claude Code → File System → Skills → ???. 발표 시점 자막은 skills.sh 얘기지만, 슬라이드 자체가 “매 단계가 이전엔 알려지지 않았던 더 나은 방법이었다”는 서사를 시각화한다. 다음 장면의 Eve가 바로 ??? 칸의 답이다.
[11:55] 11. Eve의 발상 — 에이전트를 위한 Next.js
D0를 만드는 매 단계마다 사내의 “agent curious”한 누군가가 포크해서 자기 에이전트를 만들었고, 매번 처음부터 베스트 프랙티스를 재발명해야 했다. “오늘 시작하는 사람이 마지막 통찰부터 출발하면 어떨까?” — 그래서 “에이전트를 위한 Next.js”를 만들기로 했다. Next.js가 파일 시스템 규칙(framework-defined infrastructure)으로 배포 위치 고민을 없앤 것처럼, 에이전트도 그래야 한다는 발상이다. 화면 우측엔 next-app/의 proxy.ts, app/page.tsx·layout.tsx, api/route.ts, components/Button.tsx·Card.tsx 트리가 예시로 뜬다 — 폴더에 두면 프레임워크가 알아서 인프라로 엮어준다는 Next.js 철학의 시각적 인용이다.
[12:05] 12. 외부 검증 — Aura의 mini claw 사례
런던 이벤트 2주 전 공개 후 파트너 Aura가 올린 X 게시물(@oradotai, 2026-06-22)을 인용한다. Aura는 웹사이트를 방문해 제품을 설치·직접 써보는 “mini claw” 에이전트를 Eve로 처음부터 다시 만들고 Claude Code 기반과 벤치마크했다. 막대 그래프 3종 — Fewer steps(적은 단계), More native success(높은 네이티브 성공률), Real endpoints(실제 엔드포인트 적중) — 가 Eve 우위를 가리킨다. 발표자의 표현대로 “off-the-shelf Claude Code 대비 fewer steps, better successes, better insights”다. 사내 실험을 벗어난 첫 외부 증거로 배치된 장면이다.
[13:10] 13. Eve의 구조 — 런타임과 채널
“에이전트는 실제로 이렇게 생겼다”는 구조도. Runtime — Durable execution·state persistence·event streaming 위에 Durable Workflow(체크포인트 단계, 메시지 사이 대기·도착 시 재개, Postgres), AI SDK(모델 호출·스트리밍, GPT-5.4 API), Sandbox(격리 실행, Docker), Connection(MCP/HTTP 엔드포인트, Snowflake API), Tools & Subagents(함수·자식 에이전트). Channel — 에이전트가 노출되는 면으로 Chat SDK, Slack, Discord, Web Chat, Google Chat, Microsoft Teams, WhatsApp, API, Cron, Twilio, Linear, GitHub, Telegram. 오픈소스 어댑터(Postgres, OpenAI Responses API, Docker, 커넥터)를 끼우게 설계했고, Vercel에 올리면 자사 제품(Durable Workflow·Sandbox 등)으로 그대로 돌아간다는 이중 전략이다. mcp의 MCP/HTTP 연결 논의와 겹치는 지점이다.
[14:10] 14. 데모 — Vercel 배포 = 관측가능성이 기본값
Eve를 Vercel에 배포하면 observability가 out of the box로 따라온다는 시연. 화면은 vercel.com/eve-demo/.../agent-runs 대시보드로, Agent Runs 목록·턴별 Tool Calls·각 단계·예상 비용·최적화 제안까지 보인다. 데모 속 에이전트는 Linear 이슈 3건(VER-32/33/34, Confetti animation 관련)을 병렬 생성하고 Salesforce Opportunity 레코드를 업데이트한다. Approve tool call: update_salesforce_opportunity 같은 승인 게이트와 create_linear_issue 호출 결과가 그대로 노출된다. 에이전트를 “배포 가능한 것”으로 만드는 마무리가 관측가능성이라는 주장이다.
[14:35] 15. 클로징 — eve.dev와 직접 만들라는 권유
마지막 슬라이드는 https://eve.dev 한 줄. 클론해서 템플릿으로 시작하고, 쉽게 배포하고, 필요하면 셀프호스트하라는 안내다. 결론 메시지는 두 가지다. 첫째, 기성 버티컬 에이전트(Snowflake용 전용 에이전트 등 스타트업 제품들)와 겨뤄본 결과, 에이전트를 좋게 만드는 것은 회사 고유 지식(company-specific knowledge) — 어떤 테이블에 무엇이 있고 무엇이 무엇과 연결되는지였다. 둘째, 그래서 “juice를 짜내려면 직접 에이전트를 만들고 사내 지식을 듬뿍 넣어라”. Vercel 사내엔 마케팅 회고·법무 계약 초안(redline)·데이터 질의까지 약 20개의 제법 PMF인 에이전트가 돌고 있고, 데이터팀은 다시는 예전으로 돌아가지 않았다는 말로 닫는다. 2026-08-13-agent-development-what-not-to-do의 “컨텍스트가 성패를 가른다”는 교훈과 같은 결론이다.
부록 — 실전 체크리스트
- 내 에이전트의 첫 버전을 “메가 프롬프트 한 방”으로 만들고, 어디서 무너지는지 직접 확인하기 (D0 v1)
- 역할별 체인으로 쪼갤 때 각 단계의 입출력을 명시하고, 다음 단계가 받는 정보가 요약 조각뿐인지 점검하기 (D0 v2의 함정)
- 상태를 에이전트 자신이 들고 에러 시 탐색으로 복귀할 수 있는지 확인하기 — 공유 컨텍스트·같은 루프가 있는가 (D0 v3)
- 내부 eval 점수와 실사용 반응을 분리해서 보기 — eval 30% 같은 숫자에 속지 않기
- 복잡한 전용 도구부터 만들지 말고, 파일 읽기·grep·bash + 샌드박스 + 최소 전용 도구로 시작해보기 (파일 시스템 에이전트)
- 반복 질의 상위 N개를 모아 스킬로 증류하는 배치를 돌려보기 — 스킬 폴더가 매 실행의 빈손 출발을 메워주는지 확인
- 폴더 컨벤션(skills·tools·channels 선언 → 프레임워크 조립)으로 새 에이전트를 처음부터 만들어보고
eve.dev템플릿과 비교하기 - 배포 시 에이전트 실행·도구 호출·비용이 보이는 관측가능성 화면을 기본값으로 붙이기
원문 인용 모음
- [00:08] “I’m here to talk to you about how we solved agent building at Vercel.”
- [01:22] “could we potentially have an agent on every desk?”
- [03:26] “if you want to try to use AI to solve a problem, you may just build like a huge mega prompt.”
- [04:38] “each agent has a very dedicated system prompt focused to what that does with tools scoped to exactly that function.”
- [05:45] “you need one agent with all the mega contacts within it and for it to sort of manage its own memory.”
- [07:04] “We thought we were cooking. We thought this was, you know, nailing 30% of our evals, but … the immediate response was it was awful.”
- [08:35] “Claude Code and Opus 4.5 is basically AGI compared to what we had before.”
- [08:35] “You can really just use a file system.”
- [10:01] “there’s only so many ways you can do an aggregation … we actually have a recurring job that takes the most recent queries and tries to distill them into a skill.”
- [11:51] “what if we built the Next.js for agents?”
- [13:10] “we built Eve so you can plug in your own open source adapters for Postgres, OpenAI’s responses API, Docker, other connectors.”
- [14:10] “when you deploy Eve to Vercel, you get observability out of the box.”
- [14:35] “if you really want to get the most juice out of a squeeze, you should really try to build your own agent and add in as much company-specific knowledge as you can.”