우리 에이전트의 툴을 80% 제거했다

Vercel d0 팀이 에이전트의 도구를 15개 이상에서 단일 bash 명령 실행 도구로 줄였더니 3.5배 빨라지고 성공률이 80%에서 100%로 올랐다. "모델이 혼자 해결할 수 있는 문제를 우리가 대신 해결하고 있었다"는 핵심 인사이트다. 도구를 잘 만드는 것보다 모델이 읽는 데이터를 잘 구조화하는 것이 더 효과적이라는 결론도 함께 제시한다.

핵심 포인트

**15개 도구 → 1개**: 스키마 조회·오류 복구·컨텍스트 관리·쿼리 플래닝 등 전부 제거, bash 실행 하나로 교체
**3.5배 빠름·토큰 37% 감소**: 실행 시간 274.8초 → 77.4초, 토큰 102k → 61k, 성공률 80% → 100%
**모델을 신뢰하라**: Claude Opus 4.5에게 원시 YAML/JSON 파일 + 표준 Unix 유틸리티 직접 접근 부여

상세 정리

기존 아키텍처의 문제d0 팀의 원래 에이전트는 15개 이상의 특화 도구를 갖고 있었다: 스키마 조회·검증, 오류 복구 메커니즘, 컨텍스트 관리 유틸리티, 직접 구현한 검색 시스템, 쿼리 플래닝·완료 도구. 설계 의도는 좋았지만 결과적으로 모델의 추론 능력을 제약하는 과도한 가이드레일이 됐다. 팀의 표현대로 "우리는 모델이 혼자 처리할 수 있는 문제를 대신 해결하고 있었다."

단순화 실험팀은 "빼기" 접근법을 택했다. 모든 특화 도구를 제거하고 Claude Opus 4.5에게 샌드박스 파일 시스템에서 bash 명령을 직접 실행할 수 있는 단일 도구를 줬다. 원시 Cube DSL 파일(YAML, Markdown, JSON)과 표준 Unix 유틸리티(`grep`, `cat`, `ls`, `find`)에 직접 접근하게 한 것이다. 가설: 더 큰 컨텍스트 창을 가진 개선된 모델은 제약된 특화 도구보다 원시 데이터를 더 잘 탐색할 수 있다.

측정 결과 (5개 대표 쿼리)

| 지표 | 기존 | 신규 | 개선 | |---|---|---|---| | 실행 시간 | 274.8초 | 77.4초 | 3.5배 빠름 | | 성공률 | 80% | 100% | +20%p | | 토큰 사용량 | ~102k | ~61k | 37% 감소 | | 필요 스텝 | ~12 | ~7 | 42% 감소 |

최악의 경우도 724초 → 141초로 개선됐고, 이전엔 실패하던 케이스가 성공했다.

핵심 교훈1. **도구가 많을수록 더 나쁠 수 있다**: 특화 도구가 오히려 모델의 의사결정을 방해한다2. **개선된 모델을 신뢰하라**: 현재 모델의 한계 기준으로 설계한 제약이 최신 모델에선 짐이 된다3. **데이터 레이어 품질이 핵심**: 도구를 잘 만드는 것보다 모델이 읽는 데이터를 잘 구조화하는 게 더 효과적4. **미래 지향적 설계**: 현재가 아닌 예상되는 모델 성능 기준으로 아키텍처를 짜라

왜 읽나AI 에이전트를 설계하거나 개선하려는 모든 엔지니어에게 직접적으로 유용한 글이다. "도구를 더 잘 만들어라"가 아니라 "도구를 없애라"는 반직관적 결론이 실측 데이터로 뒷받침된다. 에이전트가 느리거나 실패율이 높다면, 먼저 도구 수를 줄이는 실험을 해볼 수 있다.

Vercel Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

우리 에이전트의 툴을 80% 제거했다

이 글과 비슷한

DS와 MLE가 함께 일하는 법

AI와 개발하기: 숨은 결정을 드러내기

Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기