도구 사용(Tool use)은 동작을 설명하는 모델과 실제로 동작을 수행하는 모델을 구분 짓는 요소입니다. 그 메커니즘은 한 단락으로 설명할 수 있을 만큼 충분히 간단합니다. 하지만 그 주변의 엔지니어링(Engineering)이야말로 프로덕션 에이전트(Production agents)의 생사를 결정짓는 지점입니다.

실제로 무엇이 고장 나는지, 여러분이 마주하게 될 대략적인 순서대로 설명하겠습니다.

도구 호출(Tool Calls)이 실패하는 네 가지 단계

모든 도구 호출은 네 가지 단계를 거치며, 각 단계마다 고유한 실패 모드(Failure mode)가 존재합니다.

정의(Definition) 단계는 모델에게 이름, 설명, 그리고 파라미터(Parameters)를 위한 JSON 스키마(JSON schema)를 전달하는 단계입니다. 호출(Invocation)은 모델이 텍스트 대신 구조화된 호출을 생성하는 단계이며, 이 호출은 산문(Prose)에서 파싱해내는 것이 아니라 응답 내에서 그 자체로 하나의 메시지 유형이 됩니다. 실행(Execution)은 여러분의 코드 단계입니다. 이름을 함수에 매핑하고, 인자(Arguments)를 신뢰하기 전에 검증하며, 타임아웃(Timeout)을 적용하고, 실패를 모델이 실제로 행동할 수 있는 텍스트 데이터로 캡처하는 과정입니다. 결과 처리(Result handling)는 모델이 계속 진행할 수 있도록 출력을 다시 피드백하는 단계입니다. 이때 보내는 데이터의 형태가 중요한데, 깊게 중첩된 객체(Deeply nested object)를 가공 없이 그대로 던져주는 것은 신입 엔지니어를 혼란스럽게 하는 것과 마찬가지로 모델을 혼란스럽게 합니다.

네 단계 중 세 단계가 여러분의 몫이라는 점에 주목하십시오. 제공자(Provider)는 호출(Invocation)을 처리합니다. 정의(Definition), 실행(Execution), 그리고 다시 돌아가는 데이터의 품질은 여러분이 책임져야 합니다.

스키마 설계(Schema Design)는 가장 레버리지가 높은 작업입니다

잘 설계된 스키마는 대다수의 경우 첫 번째 시도에서 호출을 정확하게 수행합니다. 모호한 스키마는 재시도(Retries), 지연 시간(Latency), 비용, 그리고 기다리는 사용자의 경험 악화를 초래합니다.

신중한 스키마 설계와 부주의한 스키마 설계 사이의 격차는 대략 첫 번째 시도 성공률 95%와 70%의 차이와 같으며, 이 차이는 다단계 워크플로(Multi step workflow) 전반에 걸쳐 가혹하게 복리로 작용합니다. 각각 95%의 성공률을 가진 5개의 종속적 호출(Dependent calls)은 약 77%의 확률로 깔끔하게 완료됩니다. 반면 70%의 성공률일 경우, 그 확률은 17%로 떨어집니다.

이 수치를 높여주는 네 가지 규칙은 다음과 같습니다:

도구의 이름을 그것이 수행하는 일을 나타내는 동사구(verb phrase)로 명명하세요. get_customer_profile이나 create_support_ticket은 모델에게 언제 해당 도구를 호출해야 하는지 알려줍니다. 반면 process, handle_request, utility_function과 같은 이름은 모델이 설명만 보고 추측하도록 강요합니다.

설명(description)은 문서화용이 아니라 선택(selection)을 위해 작성하세요. 도구가 무엇을 반환하는지, 언제 사용해야 하는지, 그리고 부수 효과(side effects)가 무엇인지 명시하세요. "지원 티켓을 생성하고 고객에게 확인 이메일을 보냅니다"라는 설명은 모델에게 이 호출이 멱등적(idempotent)이지 않다는 것을 알려주며, 이는 모델이 실행 전 확인 절차를 거칠지 여부를 결정하는 데 영향을 미칩니다.

사용 가능한 가장 엄격한 타입(types)을 사용하세요. 자유 형식의 문자열 대신 열거형(Enums)을 사용하고, 날짜와 이메일에 대한 형식 힌트(format hints)를 제공하며, 숫자의 경우 실제 범위를 기반으로 최소값과 최대값을 설정하세요. 그리고 모델이 읽게 될 파라미터 설명(parameter description)에 해당 제약 조건을 다시 한번 반복하세요.

필수 파라미터(required parameters)를 최소한으로 유지하세요. 대화 내용에 해당 값이 포함되지 않았을 경우, 모든 필수 필드는 호출이 실패할 수 있는 지점이 됩니다. 정말로 필요한 것만 필수(require)로 지정하고 나머지는 기본값(default)을 설정하세요.

20개가 넘는 도구의 라우팅 (Routing)

도구가 3개일 때 선택은 사소한 문제지만, 15개 또는 20개가 넘어가면 진정한 엔지니어링 문제가 됩니다. 모든 정의는 컨텍스트(context)를 소모하며, 유사한 도구들은 모호함을 유발하고, 여러 도구의 시퀀스(sequence)는 조합론적으로 증가합니다.

명확하게 구분되는 도구가 약 10개 미만일 때는 모델에게 모든 것을 넘겨주고 직접 선택하게 하세요. 그 이상일 경우에는 앞에 라우팅 레이어(routing layer)를 두고, 키워드, 소규모 의도 분류기(intent classifier), 또는 도구 설명에 대한 임베딩 유사도(embedding similarity)를 통해 현재 메시지와 관련이 있을 법한 5~10개의 도구를 선택하세요. 수백 개의 도구가 있는 경우에는 계층적으로 라우팅하세요. 카테고리를 먼저 선택하고 그 다음 특정 도구를 선택함으로써, 단일 호출이 전체 도구 세트를 한꺼번에 보지 않도록 해야 합니다.

시스템이 무엇이 효과적이었는지 기억할 때 라우팅 성능도 향상됩니다. 특정 유형의 질문이 역사적으로 지식 베이스 검색(knowledge base search) 후에 티켓 생성(ticket creation)을 필요로 했다면, 유사한 상황이 발생했을 때 해당 조합을 미리 선택해 두는 것이 가치가 있습니다.

순차적 또는 병렬적, 그리고 사용자가 이를 느끼는 이유

호출(calls)이 서로 의존적일 때는 순차적 실행 (Sequential execution)이 불가피하며, 이는 지연 시간 (latency) 비용을 발생시킵니다. 예를 들어, 각각 500ms가 소요되는 세 개의 의존적인 호출이 있다면, 매 단계 사이의 모델 추론 (model inference) 시간을 포함하여 총 1.5초의 도구 실행 시간이 소요됩니다.

병렬 실행 (Parallel execution)은 독립적인 호출들을 가장 느린 호출의 실행 시간만큼 단축시킵니다. 현재 모델들은 이미 단일 응답 턴 (response turn) 내에서 여러 개의 도구 호출을 생성할 수 있으므로, 이러한 능력은 이미 갖춰져 있습니다. 이제 여러분의 몫은 호출을 동시에 전달 (dispatching)하고, 결과를 다시 전달하기 전에 수집하는 것입니다.

요점 (The Takeaway)

에이전트가 제대로 작동하지 않을 때, 본능적으로 모델을 탓하거나 더 큰 모델을 찾으려 합니다. 하지만 대부분의 경우 해결책은 여러분이 관리하는 단계에 있습니다. 더 명확한 스키마 (schema), 선택지를 좁혀주는 라우터 (router), 그리고 모델이 동일한 호출을 재시도하는 대신 복구할 수 있도록 작성된 에러 메시지 등이 그 예입니다.

이것들은 일반적인 엔지니어링 문제이며, 이는 좋은 소식입니다. 왜냐하면 일반적인 엔지니어링 문제는 해결되면 고정되기 때문입니다.

에러 복구 (error recovery), 검증 (validation) 및 보안 측면을 포함한 전체 가이드: https://www.adaptiverecall.com/ai-tool-use/