에이전트 설계 ② — 도구 설계: 도구 정의는 곧 프롬프트다

에이전트 품질의 절반은 도구 정의에서 결정된다. 2026년의 정설: 도구의 이름·설명·파라미터·에러 메시지·결과 형식은 전부 모델을 위한 텍스트다 — 유료 프롬프트라 생각하고 토큰 단위로 다듬어라.

좋은 도구 정의의 원칙

Anthropic의 가이드: 설명은 신입사원 온보딩 문서처럼, 관련 도구는 공통 접두사로 네임스페이스(asana_search, jira_search), 파라미터명은 모호함 제거(user 말고 user_id), 결과는 고신호 정보만 — 실측: 장황한 Slack 도구 응답 206토큰을 72토큰으로 압축(-65%)해도 능력 손실 없음. 에러 메시지는 스택 트레이스가 아니라 모델을 조향하는 문장("더 좁은 쿼리로 재시도하세요")으로. 그리고 도구 설명 개선만으로 오류율이 급감해 SWE-bench SOTA에 기여했다 — 설명은 평가셋으로 A/B 하는 대상이다. OpenAI 가이드도 교차 확인된 원칙: 한 턴에 도구 20개 미만, enum과 strict 모드로 잘못된 상태를 표현 불가능하게, 코드가 이미 아는 값은 모델에게 채우게 하지 말 것.

도구가 많아지면 — 2026년의 해법

Claude의 선택 정확도는 로드된 도구 30~50개를 넘으면 무너지고, 전형적인 MCP 5서버 구성은 작업 전에 정의만 ~55K 토큰을 태운다. Advanced tool use의 처방 세 가지: ① Tool Search + 지연 로딩 — 정의 토큰 85% 절감, MCP 평가 정확도 49%→74%(도구 선택 오류는 모델 문제가 아니라 컨텍스트 문제였다), 10개/10k 토큰 초과 시 전환 권장. ② input_examples 추가로 복잡한 파라미터 정확도 72%→90%. ③ 프로그래매틱 도구 호출 — 개별 JSON 호출 대신 코드로 여러 도구를 조합(리서치 태스크 토큰 -37%).

겸손을 강요하는 벤치마크

τ-bench: 시뮬레이션 고객과 대화하며 정책을 지켜 API를 쓰는 과제에서 최상위 모델도 성공률 50% 미만, 같은 태스크 8회 전부 성공(pass^8)은 25% 미만 — 에이전트는 약한 게 아니라 비일관적이다. 처방: 정책은 프롬프트 산문이 아니라 도구 스키마(enum, 검증)에 박고, 재시도가 트랜잭션을 반쯤 실행하지 못하게 설계하라. BFCL v3의 실패 3분류도 체크리스트로 유용: 전제 단계 추론 실패 / 상태 확인 없이 행동 / 불필요한 재인증 같은 과잉 행동.

코드 실행을 만능 도구로 쓰는 흐름(CodeAct)과 MCP 생태계는 다음 편에서.

한 줄 요약: 더 많은 도구가 아니라 더 적고 더 잘 쓰인 도구 — 그리고 pass^k로 재라.

— 에이전트 설계 시리즈 ② / 다음 글: MCP와 코드 실행 — 도구의 표준과 그 공격면