AI 에이전트를 만들 때 우리는 보통 이렇게 생각합니다.
“더 많은 도구가 필요하다”, “모델이 실수하지 않도록 가드레일을 쳐야 한다”, “복잡한 로직으로 보호해야 한다”.
하지만 Vercel은 정반대의 선택을 했습니다.
수개월 동안 공들여 만든 내부 텍스트-to-SQL 에이전트에서 도구의 80%를 과감히 삭제했고, 그 결과 에이전트는 더 빠르고, 정확하고, 신뢰할 수 있게 동작하기 시작했습니다.
이 글에서는 Vercel의 데이터 분석 AI 에이전트 d0 사례를 통해,
왜 “덜 만드는 것(Addition by Subtraction)”이 더 나은 에이전트 설계가 될 수 있는지 살펴봅니다.
d0란 무엇인가: 데이터 이해를 위한 AI 에이전트
Vercel에는 UI 생성을 돕는 AI v0가 있다면,
d0는 데이터를 이해하는 AI 에이전트입니다.
d0의 목적은 명확합니다.
- Slack에서 자연어로 질문하면
- SQL을 직접 작성하지 않아도
- 회사의 분석 인프라에서 바로 답을 얻을 수 있도록 하는 것
즉, 데이터 팀을 거치지 않고도 누구나 데이터 기반 의사결정을 할 수 있게 만드는 것이 목표입니다.
하지만 한 가지 문제가 있었습니다.
d0가 완벽하게 동작하지 않으면, 사람들은 다시 Slack에서 분석가를 호출하게 됩니다.
그래서 d0는 반드시 빠르고, 정확하고, 안정적이어야 했습니다.
기존 접근 방식의 문제: 모델 대신 너무 많이 생각해줬다
초기 d0는 굉장히 “똑똑해 보이는” 구조였습니다.
모델이 실수할 것을 가정하고, 이를 막기 위해 다음과 같은 장치를 붙였습니다.
- 스키마 조회, 조인 탐색, 쿼리 검증 등 여러 개의 특화 도구
- 모델의 사고를 제한하는 강한 프롬프트 엔지니어링
- 컨텍스트 과부하를 막기 위한 복잡한 컨텍스트 관리
- “관련 있어 보이는” 정보만 골라주는 수동 검색 로직
문제는 이 모든 것이 모델의 사고를 돕는 게 아니라 대신해 주고 있었다는 점입니다.
- 엣지 케이스가 생길 때마다 패치를 추가해야 했고
- 모델이 업데이트될 때마다 제약 조건을 다시 조정해야 했으며
- 결국 에이전트를 개선하는 것보다 에이전트 구조를 유지하는 데 더 많은 시간을 쓰게 됐습니다.
새로운 발상: 그냥… 멈춰보면 어떨까?
Vercel 팀은 한 가지 질문을 던졌습니다.
“우리가 중력을 거스르고 있는 건 아닐까?”
모델은 이미 충분히 똑똑해졌고, 컨텍스트 윈도우도 커졌습니다.
그렇다면 굳이 요약해 주고, 제한하고, 보호할 필요가 있을까요?
그래서 과감한 실험을 했습니다.
- 복잡한 도구를 대부분 제거하고
- 단 하나의 도구, 임의의 bash 명령을 실행할 수 있는 권한만 제공
- 모델이 직접 파일을 읽고, 검색하고, 이해하도록 맡김
이렇게 탄생한 것이 파일 시스템 에이전트(File System Agent) 입니다.
v2 아키텍처: 파일 시스템 자체가 에이전트가 되다
새로운 d0의 구조는 놀라울 정도로 단순합니다.
핵심 구성
- 모델: Claude Opus 4.5
- 실행 환경: Vercel Sandbox
- 라우팅: Vercel Gateway
- 서버: Next.js API + Slack Bolt
- 데이터 레이어: Cube 시맨틱 레이어 (YAML, Markdown, JSON 파일)
에이전트는 이제 사람처럼 행동합니다.
- ls로 파일을 둘러보고
- grep으로 필요한 정의를 찾고
- cat으로 내용을 읽으며
- 머릿속에서 스키마와 관계를 구성한 뒤
- SQL을 작성합니다
중요한 점은, 시맨틱 레이어 자체가 이미 훌륭한 문서였다는 사실입니다.
기존에는 이를 다시 요약하고 가공하는 도구를 만들고 있었지만,
모델은 그냥 “읽기만 하면” 충분했습니다.
성능 비교 결과: 단순해졌는데 더 강력해졌다
새로운 파일 시스템 에이전트는 모든 지표에서 기존 구조를 압도했습니다.
| 지표 | 기본 구 | 파일 시스템 에이전트 | 변화 |
| 평균 실행 시간 | 274.8초 | 77.4초 | 3.5배 빠름 |
| 성공률 | 80% | 100% | +20% |
| 평균 토큰 사용량 | 약 102k | 약 61k | 37% 감소 |
| 평균 단계 수 | 약 12단계 | 약 7단계 | 42% 감소 |
특히 인상적인 점은 실패하던 쿼리까지 성공했다는 것입니다.
이전 구조에서는 수백 초, 수십 단계, 수십만 토큰을 쓰고도 실패했지만,
파일 시스템 에이전트는 더 적은 비용으로 정확한 결과를 냈습니다.
여기서 얻은 교훈
1. 중력을 거스르지 말 것
파일 시스템은 이미 강력한 추상화입니다.
50년 된 grep은 여전히 문제를 해결합니다.
2. 모델을 믿지 못해 만든 제약이 오히려 발목을 잡는다
Claude Opus 4.5 수준에서는
모델이 직접 판단하게 두는 편이 더 낫습니다.
3. 좋은 에이전트는 좋은 문서에서 시작된다
이 접근이 가능했던 이유는
시맨틱 레이어가 잘 정리돼 있었기 때문입니다.
이름이 엉망이고, 조인이 불분명한 데이터라면
파일 접근을 준다고 해결되지는 않습니다.
4. 도구는 많을수록 좋은 게 아니다
도구 하나하나는 “모델 대신 인간이 내리는 선택”입니다.
때로는 그 선택을 하지 않는 것이 더 나은 결과를 만듭니다.
에이전트 빌더에게 주는 시사점
에이전트를 만들 때 모든 경우의 수를 대비하고 싶어집니다.
하지만 이 사례는 이렇게 말합니다.
- 가장 단순한 구조에서 시작하라
- 모델 + 파일 시스템 + 목표면 충분할 수 있다
- 복잡함은 필요하다는 게 증명됐을 때만 추가하라
또 하나 중요한 메시지가 있습니다.
모델의 발전 속도는, 당신의 툴링이 따라가는 속도보다 빠르다.
지금의 모델이 아니라,
6개월 뒤의 모델을 기준으로 설계하라는 이야기입니다.
Vercel의 d0 사례는 “더 많이 만드는 것”이 항상 정답은 아니라는 점을 분명히 보여줍니다.
오히려 덜 만들었을 때, 에이전트는 더 빠르고, 더 똑똑해졌습니다.
AI 에이전트를 설계하고 있다면,
지금 한 번쯤 이렇게 자문해 볼 필요가 있습니다.
“이 도구, 정말 필요한 걸까?”
어쩌면 답은
삭제 버튼일지도 모릅니다.
https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools
We removed 80% of our agent’s tools - Vercel
We spent months building a sophisticated text-to-sql agent, but as it turns out, sometimes simpler is better. Giving it the ability to execute arbitrary bash commands outperformed everything we built. We call this a file system agent.
vercel.com
'인공지능' 카테고리의 다른 글
| Grok Collections API란? - 대규모 문서를 위한 차세대 RAG 검색 API 완전 정리 (0) | 2025.12.24 |
|---|---|
| Magentic UI란 무엇인가? - 사람처럼 상호작용하는 웹 에이전트를 만드는 새로운 접근 (0) | 2025.12.24 |
| Qwen-Image-Edit-2511 공개: 오픈소스 이미지 편집 모델의 새로운 기준 (0) | 2025.12.24 |
| ARC-AGI의 50% 벽을 넘다 - Poetiq과 GPT-5.2가 보여준 테스트 시점 추론의 진짜 힘 (0) | 2025.12.24 |
| 엔비디아 범용 게임 에이전트 ‘나이트로젠(NitroGen)’ 공개 - 게임을 넘어 로봇 공학까지 확장되는 체화 AI의 가능성 (0) | 2025.12.23 |
