AI 에이전트를 만들 때 우리는 본능적으로 더 많은 도구를 추가합니다. 스키마 검색, 쿼리 검증, 에러 복구… 모델을 “보호”하려는 의도죠. 그런데 Vercel은 정반대로 했습니다. 12개가 넘는 전문 도구를 2개로 줄였더니 성능이 3.5배 빨라지고 성공률은 100%가 됐습니다.

Vercel이 자연어로 데이터를 질의하는 내부 AI 에이전트 ‘d0’를 개발하면서 겪은 역설적 최적화 경험을 공유한 글입니다. 복잡한 아키텍처를 대부분 제거하고 bash 명령어만 실행하는 단순한 구조로 바꿨더니 오히려 모든 지표가 개선됐다는 이야기죠.

출처: We removed 80% of our agent’s tools – Vercel

무엇이 문제였나

d0는 Slack에서 자연어 질문을 받아 SQL로 변환해 답변하는 에이전트입니다. v0가 UI를 만드는 AI라면 d0는 데이터를 이해하는 AI죠. 처음 버전은 이렇게 만들어졌습니다:

• 12개 이상의 전문 도구 (스키마 조회, 쿼리 검증, 에러 복구 등)
• 무거운 프롬프트 엔지니어링으로 추론 제약
• 복잡한 컨텍스트 관리
• 수작업으로 만든 검색 로직으로 “관련있는” 스키마만 제공

팀은 모델이 복잡한 스키마에서 길을 잃거나 잘못된 조인을 하거나 테이블 이름을 환각할 거라 가정했습니다. 그래서 가드레일을 쌓았죠. 모델 대신 생각해주려 했습니다.

결과는요? 성공률 80%, 평균 12단계 소요, 102k 토큰 사용. 작동은 했지만 느리고 깨지기 쉬웠습니다. 엣지 케이스가 생길 때마다 패치를 더하고, 모델이 업데이트될 때마다 제약을 재조정해야 했어요. 에이전트 개선보다 스캐폴딩 유지보수에 더 많은 시간을 쓰게 됐습니다.

그냥… 멈추면 어떨까?

팀은 깨달았습니다. 모델의 추론을 제약하고, 모델이 스스로 읽을 수 있는 정보를 요약하고, 모델이 처리할 수 있는 복잡성으로부터 보호하려 한다는 걸요. 중력과 싸우고 있었던 거죠.

그래서 멈췄습니다. “Claude에게 Cube DSL 파일을 그냥 주고 알아서 하게 하면 어떨까?” 새로운 가설은 단순했습니다. bash만 있으면 충분하지 않을까? 모델은 똑똑해지고 컨텍스트 윈도우는 커지는데, 최고의 에이전트 아키텍처는 아키텍처가 거의 없는 것일지도 모른다고요.

새 버전의 구성:

• Claude Opus 4.5
• Vercel Sandbox에서 bash 명령 실행
• 도구는 단 2개: ExecuteCommand (bash), ExecuteSQL

파일시스템 에이전트는 이제 인간 분석가처럼 시맨틱 레이어를 탐색합니다. 파일을 읽고, 패턴을 grep하고, 멘탈 모델을 만들고, grep, cat, find, ls 같은 표준 Unix 도구로 SQL을 작성하죠.

이게 작동한 이유는 시맨틱 레이어 자체가 이미 훌륭한 문서였기 때문입니다. YAML 파일에 차원 정의, 측정값 계산, 조인 관계가 다 들어있었어요. 팀은 이미 읽기 좋은 내용을 요약하는 도구를 만들고 있었던 겁니다. Claude는 그냥 직접 읽기만 하면 됐죠.

숫자로 보는 변화

5개 대표 쿼리로 구버전과 신버전을 비교한 결과:

• 실행 시간: 274.8초 → 77.4초 (3.5배 빠름)
• 성공률: 80% → 100% (+20%p)
• 토큰 사용: 102k → 61k (37% 절감)
• 평균 단계: 12 → 7 (42% 감소)

구버전의 최악 사례였던 Query 2는 724초, 100단계, 145,463 토큰을 쓰고도 실패했습니다. 신버전은 같은 쿼리를 141초, 19단계, 67,483 토큰으로 완료했고 성공했습니다.

정성적 변화도 중요합니다. 에이전트는 예상하지 못한 엣지 케이스를 잡아내고, 추론 과정을 따라갈 수 있게 설명합니다.

무엇을 배웠나

중력과 싸우지 마세요. 파일시스템은 엄청나게 강력한 추상화입니다. grep은 50년 됐지만 여전히 우리가 필요한 걸 정확히 해내죠. Unix가 이미 해결한 문제를 위해 커스텀 도구를 만들고 있었던 겁니다.

모델의 추론을 신뢰하지 않아서 제약했습니다. Opus 4.5에서는 그 제약이 오히려 방해가 됐어요. 우리가 선택을 대신해주지 않을 때 모델이 더 나은 선택을 합니다.

좋은 문서가 전제조건입니다. 이 방식은 시맨틱 레이어가 이미 훌륭한 문서였기 때문에 작동했습니다. YAML 파일이 잘 구조화돼 있고 일관된 네이밍에 명확한 정의를 담고 있었죠. 데이터 레이어가 레거시 네이밍과 문서화되지 않은 조인으로 엉망이라면, Claude에게 파일 접근권을 줘도 구원받지 못합니다. 그냥 나쁜 쿼리를 더 빨리 얻을 뿐이에요.

덜어낼수록 좋아진다는 건 진짜입니다. 최고의 에이전트는 도구가 가장 적은 에이전트일지 모릅니다. 모든 도구는 당신이 모델 대신 내리는 선택입니다. 때로는 모델이 더 나은 선택을 하죠.

단순함의 조건

Vercel은 이 경험을 통해 “가장 단순한 아키텍처로 시작하고, 필요가 증명된 후에만 복잡성을 더하라”고 말합니다. 모델은 도구보다 빠르게 발전하니 지금이 아니라 6개월 후의 모델을 위해 설계하라는 거죠.

하지만 이 접근에는 중요한 전제조건이 있습니다. Vercel의 성공은 시맨틱 레이어가 이미 잘 정리된 YAML 문서였기 때문입니다. 구조화된 파일, 일관된 네이밍, 명확한 정의가 있었죠. 데이터 레이어가 레거시 네이밍과 문서화되지 않은 조인으로 엉망이라면, 도구를 줄인다고 해결되지 않습니다. 그냥 나쁜 결과를 더 빨리 얻을 뿐이에요.

결국 단순화는 좋은 기반 위에서만 작동합니다. 영리한 도구를 만들기 전에 문서화와 구조화에 먼저 투자해야 한다는 게 진짜 교훈입니다.