Tool Use
tool use는 모델이 외부 함수나 API를 직접 실행할 수 있는 것처럼 호출 의도를 표현하고, 애플리케이션이 그 호출을 실제로 수행하는 패턴입니다. 모델은 무엇을 물어봐야 하는지와 어떤 인자가 필요한지를 정하고, 실제 부작용은 런타임이 통제합니다.
▶아키텍처 다이어그램
🔄 프로세스 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
모델은 파라미터 안에 없는 최신 데이터나 사내 비공개 상태를 스스로 알 수 없고, 결제나 티켓 생성 같은 행동도 직접 실행할 수 없습니다. 이런 한계를 무시하면 그럴듯한 가짜 답을 만들거나, 행동이 필요한 작업을 말로만 설명하고 끝내게 됩니다.
LLM이 텍스트 생성기에서 업무 인터페이스로 확장되면서, 검색과 실행을 모델 밖으로 연결하는 구조가 필수가 됐습니다. 이때 중요한 것은 모델이 모든 것을 직접 하게 만드는 것이 아니라, 어떤 도구를 언제 어떤 조건으로 쓰게 할지를 런타임이 통제하는 설계였습니다.
먼저 애플리케이션은 도구 이름, 인자 스키마, 설명, 허용 범위를 모델에 알려 줍니다. 모델은 현재 목표를 보고 도구 호출이 필요하다고 판단하면 인자를 채운 호출 요청을 냅니다. 런타임은 이를 검증한 뒤 실제 API나 함수를 실행하고, 결과를 observation(실행 결과 요약)으로 다시 모델에 전달해 최종 답을 이어가게 합니다.
모델이 보는 것은 도구 계약
{
"name": "get_order_status",
"description": "주문 상태를 조회한다",
"input_schema": {
"type": "object",
"properties": {
"order_id": { "type": "string" }
},
"required": ["order_id"]
}
}모델은 DB나 API 자체를 보는 것이 아니라, 어떤 이름의 도구가 어떤 인자를 받는지만 계약으로 받습니다.
호출 요청과 실행 결과를 분리
{
"tool_call": {
"name": "get_order_status",
"arguments": { "order_id": "A123" }
},
"tool_result": {
"order_id": "A123",
"status": "shipped"
}
}모델이 호출 의도를 내고, 런타임이 실행한 뒤 결과만 다시 주입한다는 분리가 tool use의 핵심입니다.
structured output, tool use, agent workflow는 모두 모델 출력을 시스템 행동으로 연결하지만 층이 다릅니다. 검증된 객체만 얻으면 충분할 때는 structured output을, 외부 데이터 조회나 행동 한 번이 필요할 때는 tool use를, 결과를 보고 다음 행동을 다시 고를 필요가 있을 때는 agent workflow를 봐야 합니다. 모든 tool call을 agent loop로 키우면 제어 비용만 커질 수 있다는 점이 한계입니다.
실무에서는 검색, DB 조회, CRM 업데이트, 일정 등록, 계산, 규칙 검증처럼 모델 바깥의 정확한 정보나 행동이 필요한 곳에 씁니다. 이때 가장 흔한 운영 문제는 모델이 같은 도구를 반복 호출하거나, 너무 넓은 권한을 가진 도구를 잘못 쓰는 것입니다. 그래서 읽기 도구와 쓰기 도구를 분리하고, 쓰기 동작에는 확인 절차나 같은 요청이 두 번 실행돼도 결과가 중복되지 않게 하는 idempotency 키를 두는 식의 통제가 필요합니다.