함수 정의가 30개만 넘어가도 에이전트 성능보다 먼저 무너지는 것이 컨텍스트 비용입니다. 도구를 많이 붙일수록 “모델이 할 수 있는 일”은 늘어나지만, 동시에 프롬프트 앞부분에 거대한 스키마를 밀어 넣게 되고 캐시 효율, 지연 시간, 토큰 비용이 같이 나빠집니다. OpenAI가 문서로 공개한 tool search는 이 문제를 정면으로 다룹니다. 필요한 도구만 런타임에 검색해서 불러오고, 처음부터 모든 함수 파라미터를 넣지 않는 방식입니다.
핵심은 단순한 최적화 트릭이 아니라 도구 표면 설계 자체를 바꾸는 데 있습니다. tool search를 잘 쓰면 함수 100개를 한 번에 모델에게 떠먹이지 않아도 됩니다. 반대로 잘못 쓰면 도구 탐색 단계가 늘어나서 오히려 느려지고, 찾기 쉬운 이름의 함수만 과도하게 호출되는 부작용이 생깁니다. 그래서 이 기능은 켜는 것보다 구조를 다시 짜는 일이 더 중요합니다.
모든 팀이 이 기능을 바로 도입할 필요는 없습니다. 함수가 5개 이하이고, 도구 호출 패턴이 거의 고정돼 있다면 그냥 명시적으로 넣는 편이 더 단순합니다. 반대로 아래 조건 중 두세 개 이상에 해당하면 tool search 검토 가치가 큽니다.
문서에서 특히 중요한 표현은 “cache를 보존하도록 설계되었다”는 부분입니다. 실무에서는 이 한 줄이 큽니다. 대규모 시스템 프롬프트를 자주 재사용하는 팀은, 도구 추가 때문에 캐시가 깨져 비용이 올라가는 경험을 많이 합니다. tool search는 새 도구를 컨텍스트 뒤쪽에 주입하는 방식이라 이 손실을 줄이려는 의도가 분명합니다.
OpenAI 문서가 namespace나 MCP server 사용을 권장하는 이유가 있습니다. 함수 하나하나를 전부 defer_loading 처리하면 절감폭이 생각보다 작습니다. 모델은 여전히 함수 이름과 설명을 많이 보게 되고, 어떤 함수들이 한 묶음인지도 파악하기 어려워집니다.
실전에서는 “도구 카탈로그”를 먼저 다시 묶는 편이 낫습니다. 예를 들어 아래처럼 나누면 모델이 검색할 때 훨씬 유리합니다.
crm: 고객 조회, 주문 확인, 환불 상태billing: 청구서, 결제 실패, 크레딧 잔액workspace_admin: 멤버 초대, 권한 변경, 팀 설정analytics: 이벤트 조회, 기간 비교, 리포트 생성이렇게 하면 모델은 문제를 읽고 “고객 주문 문제니까 crm 쪽부터 찾자”는 고수준 판단을 할 수 있습니다. 반대로 get_customer_order_status_v2_final 같은 이름이 줄줄이 나열되면 검색 정확도가 떨어집니다.
tool search는 검색 문제입니다. 검색 문제에서는 함수명보다 설명문 품질이 더 자주 승부를 가릅니다. 설명문이 모호하면 모델은 엉뚱한 함수를 로드하거나, 비슷한 함수 여러 개를 불필요하게 불러옵니다.
좋은 설명문은 세 가지를 담아야 합니다.
예를 들어 “고객 주문을 조회합니다”보다 “고객 ID 기준으로 아직 완료되지 않은 주문만 조회합니다. 이미 종료된 주문 이력은 list_order_history를 사용하세요”가 훨씬 낫습니다. 모델이 함수 선택을 사람처럼 추론할 수 있게 힌트를 주는 셈입니다.
모든 도구를 지연 로드하면 안 됩니다. 거의 모든 대화에서 쓰이는 핵심 도구는 처음부터 바로 호출 가능해야 합니다. 예를 들면 사용자 식별, 현재 세션 읽기, 기본 검색, 간단한 계산 같은 것들입니다. 반면 특정 상황에서만 쓰이는 무거운 도구는 defer_loading 처리하는 편이 좋습니다.
실무에서는 보통 다음 기준으로 나눕니다.
즉시 호출 도구:
지연 로드 도구:
이 구분이 없으면 tool search를 켜도 체감 개선이 작습니다. 오히려 매번 검색 단계를 거치느라 왕복이 늘어날 수 있습니다.
tool search는 도입 순간보다 도입 후 관찰이 중요합니다. 최소한 네 가지는 잡아야 합니다.
여기서 특히 중요한 것은 “로드는 했지만 호출하지 않은 도구”입니다. 이 수치가 높으면 검색 품질이 나쁘다는 뜻입니다. 보통은 네임스페이스 설명을 손보거나, 너무 큰 묶음을 쪼개는 것으로 개선됩니다.
가장 안전한 순서는 전체 이관이 아니라 일부 네임스페이스부터 시범 적용하는 것입니다. 예를 들어 기존에 함수 25개를 모두 넣던 CRM 도메인만 먼저 tool search로 바꿔 보시면 됩니다. 그다음 캐시 적중률, 입력 토큰, 호출 정확도, 응답 시간을 비교합니다. 여기서 성능 이득이 확인되면 다른 도메인으로 확장하는 편이 좋습니다.
그리고 반드시 실제 사용자 질문 로그로 평가해야 합니다. 내부 데모 프롬프트는 보통 너무 깔끔해서 검색 난도가 낮습니다. 실제 운영 로그는 모호한 표현, 줄임말, 불완전한 요구가 많아서 함수 탐색 품질 차이가 더 분명하게 드러납니다.