5 min read

에이전트 툴 80%를 제거했더니 토큰은 줄고 속도와 성공률은 높아졌다

여러분의 AI 에이전트에는 어떤 제약이 걸려있나요? 한번 풀어보시면 어떻게 될까요?

Vercel에서 흥미로운 블로그 글을 발표했습니다.

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에서 몇달동안 d0라는, 슬랙봇으로 작동하는 복잡한 내부용 text-to-sql 에이전트를 개발했다. 신중한 가드레일과 프롬프트 엔지니어링을 동원했고, 특화된 툴 여러 개를 구현해 에이전트에게 쥐어주었다. 모델이 이정도로 어려운 일을 처리하지 못할(복잡한 스키마 처리 못하고, 테이블명에서 환각 일으키고, 잘못된 join 문을 작성하는 등) 거라고 생각했기 때문.
  • 개발하다 보니 엣지케이스가 생기거나 새 모델이 나올 때마다 패치해서 제약조건 등을 업데이트해야 했다. 에이전트 자체를 개선하기보다는 주변 도구를 유지보수하는 데 더 많은 시간이 들었다. 뭔가 이상했다.
  • 그냥 Claude에게 다 맡기면 어떻게 될까? 라는 생각에 다시 만들었다. Claude에게 Cube DSL 파일을 주고, 파일 시스템과 bash에서 돌아가는 표준 유닉스 도구들(grep, cat, find, ls 등)을 이용해 알아서 읽도록 해봤다. 그랬더니 속도는 3.5배 빨라지고, 성공율은 20%p 늘고, 토큰은 37% 적게 썼고, 단계도 42% 줄어들었다.

그래서 이런 교훈을 얻었다고 합니다.

  • 중력과 싸우지 말자(Don’t fight gravity): 파일 시스템은 아주 강력한 추상화 레이어다. grep 은 50년 된 기술이고 여전히 정확히 우리가 원하는 걸 준다. 유닉스가 이미 푼 문제를 다시 푸는 도구를 만들지 말자.
  • 모델이 제대로 추론하지 못할 거라고 여겨서 추론 방식을 제약했었다: Opus 4.5에서는 그러한 제약이 채무로 변했다. 우리가 대신 선택해주는 걸 멈췄더니 더 나은 선택을 하기 시작했다.
  • 이는 우리의 시멘틱 레이어가 이미 좋은 문서였기 때문에 가능했다: 이 YAML 파일은 잘 구조화되어있었고, 일관적인 이름을 썼고, 명확한 정의를 포함하고 있었다. 만약 이 파일이 비일관적인 네이밍 컨벤션과, 비문서화된 조인 등을 포함했다면 당연히 클로드도 뭘 못 했을 것이다. 더 빨리, 안좋은 쿼리를 얻었겠지.
  • 뺐더니 더해졌다(Addition by subtraction is real): 최고의 에이전트는 어쩌면 최소한의 툴로 이루어진 것일 수 있다. 모든 툴은 특정 모델을 위한 것인데, 그 모델이 더 나은 선택을 할 수도 있다.
  • 에이전트 빌더를 위한 제언: 모든 가능성에 대해 책임지려는 욕구에 저항하고 가장 단순한 아키텍처, 즉 "모델 + 파일 시스템 + 목표"로 시작하라. 그러나 이게 동작하려면 훌륭한 문서, 명확한 네이밍, 잘 구조화된 데이터가 필요하다. 이런 '좋은 컨텍스트'를 쌓는 게 복잡한 툴을 만드는 것보다 더 유리한 접근이다.

이 글을 보면서, 몇 년 전 김창준님으로부터 배웠던 '불확실성이 높은 상황에서 아주 잘 써먹을 수 있는 질문'이 떠올랐습니다. 전설적인 프로그래머인 워드 커닝햄과 켄트 벡이 대화하면서 나왔던 마법의 질문, WTSTTCPW입니다.

What's the Simplest Thing that Could Possibly Work?
동작할지도 모르는 가장 단순한 일이 뭘까?
https://www.artima.com/articles/the-simplest-thing-that-could-possibly-work#part3

이 질문은 예전에도 가치가 있었지만 요즘같은 AI 시대에 훨씬 더 가치가 높다고 느낍니다. 본인이 잘 하고 익숙한 방법대로 더 많은 제약을 걸고 명령을 내리는 대신, 명확한 목표만 제시한 채 현존하는 최고의 모델이 어디까지 해낼 수 있는지 확인하는 제 태도 또한 여기서 비롯된 것이라고 볼 수 있겠네요. 물론, '해내려면' 모델이 잘 일할 수 있는 환경(e.g., 높은 품질의 코드베이스)이 필요하지만요.

여러분의 AI 에이전트에는 어떤 제약이 걸려있나요? 한번 풀어보시면 어떻게 될까요?