LLM의 도구 사용은 언어 모델이 데이터베이스 검색, 계산 실행, 메시지 전송과 같은 외부 작업을 요청하고, 반환된 결과를 응답에 활용할 수 있게 하는 메커니즘입니다. 일반적으로 모델이 도구를 선택하고 입력값을 제안하면, 모델을 둘러싼 소프트웨어가 해당 호출을 실행할지 결정합니다.
이를 도구 호출 또는 함수 호출이라고도 합니다. 이 명칭들은 대개 같은 메커니즘을 가리킵니다. 다만 일부 플랫폼에서는 도구를 개발자가 정의한 함수뿐 아니라 호스팅 검색, 코드 실행, 파일 검색, 컴퓨터 제어까지 포함하는 더 넓은 범주로 사용합니다.
유용한 멘탈 모델
모델을 작업을 수행하는 기계가 아니라 호출자로 생각해 보세요.
모델은 다음과 같은 구조화된 요청을 생성할 수 있습니다. “주문 ID 4821로 get_order_status를 호출해.” 하지만 이 출력도 여전히 모델의 응답입니다. 모델이 스스로 데이터베이스를 조회하는 것은 아닙니다.
주변 애플리케이션은 이 요청을 받아 다음에 일어날 일을 제어합니다. 호출을 거부하거나, 사용자에게 확인을 요청하거나, 권한을 확인하거나, 코드를 실행하거나, 오류를 반환할 수 있습니다. 도구를 실행하는 경우에는 그 결과를 새로운 컨텍스트로 모델에 돌려보냅니다. 그러면 모델은 결과를 설명하거나 다른 도구를 요청할 수 있습니다.
이러한 분리가 도구 사용의 핵심입니다:
User request
↓
Model selects a tool and proposes inputs
↓
Application validates, authorizes, and executes
↓
Tool result returns to the model
↓
Model answers or requests another tool일부 제공업체는 자체 서버에서 실행하는 호스팅 도구도 제공합니다. API가 루프의 일부를 감출 수는 있지만 논리적 단계는 그대로입니다. 모델이 작업을 요청하고, 실행 시스템이 이를 수행하며, 결과가 대화에 들어옵니다.
도구 사용의 작동 방식
1. 애플리케이션이 각 도구를 설명합니다
도구 정의에는 일반적으로 다음이 포함됩니다:
- 이름(예:
get_order_status - 언제 사용해야 하는지에 대한 일반 언어 설명
- 허용되는 입력값
- 각 입력값의 형식과 유형에 대한 규칙
이러한 입력 규칙은 JSON 스키마로 표현되는 경우가 많습니다. 스키마는 order_id가 필수 문자열이라고 지정할 수 있습니다. 설명은 모델에 도구의 의미를 알려주고, 스키마는 호출 형식을 알려줍니다.
2. 모델이 요청과 도구 정의를 받습니다
모델은 사용 가능한 도구 설명과 함께 사용자의 메시지를 고려합니다. 일반적으로 답변하거나, 하나의 도구를 요청하거나, API와 애플리케이션이 허용하는 경우 여러 도구를 요청할 수 있습니다.
도구 선택은 예측이지 보장된 계획이 아닙니다. 모델은 잘못된 도구를 선택하거나, 필요한 호출을 빠뜨리거나, 형식은 올바르지만 적절하지 않은 인수를 제안할 수 있습니다.
3. 모델이 구조화된 도구 호출을 반환합니다
일반적인 자연어 대신 또는 자연어와 함께 응답에 기계 판독 가능한 호출이 포함됩니다. 단순화한 형태는 다음과 같습니다:
{
"name": "get_order_status",
"arguments": {
"order_id": "4821"
}
}제공업체별 API는 이를 서로 다른 메시지 유형으로 인코딩하고, 나중에 반환되는 결과를 올바른 호출과 연결할 수 있도록 식별자를 부여합니다. 정확한 외부 형식은 달라지지만 이름과 입력값이라는 개념은 주요 API 전반에서 일관됩니다.
4. 애플리케이션이 실행 여부를 결정합니다
여기서 제안된 작업이 실제 작업이 될지, 아니면 실행되지 않을지가 결정됩니다.
애플리케이션은 인수를 파싱하고 스키마뿐 아니라 더 많은 기준으로 이를 확인합니다. 로그인한 사용자, 접근 규칙, 값의 범위를 확인하고, 부작용이 있는 작업에 승인을 요구하거나, 사용할 수 없는 도구를 거부할 수 있습니다. 그런 다음에야 도구 실행기가 데이터베이스, API, 계산기, 파일 시스템 또는 다른 시스템을 호출합니다.
엄격한 스키마는 구조적 신뢰성을 높일 수 있지만 권한 부여 시스템은 아닙니다. "order_id": "4821"는 유효한 JSON이면서도 다른 사람의 주문을 가리킬 수 있습니다.
5. 도구 결과가 모델로 돌아갑니다
애플리케이션은 원래 호출과 연결된 결과 메시지로 출력을 보냅니다. 출력에는 데이터, 오류 또는 권한이 거부되었다는 내용이 포함될 수 있습니다.
모델은 이 결과를 추가 컨텍스트로 사용합니다. 최종 답변을 만들거나, 이전 가정을 수정하거나, 또 다른 도구를 호출할 수 있습니다. 여러 단계를 수행하는 AI 에이전트는 중지 조건에 도달할 때까지 이 루프를 반복할 수 있습니다.
예제: 주문 확인
어떤 상점이 읽기 전용 도구 하나를 제공한다고 가정해 보겠습니다:
Name: get_order_status
Purpose: Return shipping information for an order the current user owns
Input: order_id (required string)사용자가 묻습니다:
주문 4821은 어디에 있나요?
모델이 요청합니다:
{
"name": "get_order_status",
"arguments": {
"order_id": "4821"
}
}무언가를 조회하기 전에 애플리케이션은 현재 세션을 확인합니다. 사용자가 주문 4821의 소유자라면 조회를 실행하고 다음을 반환합니다:
{
"status": "shipped",
"estimated_delivery": "Friday"
}이제 모델은 “주문 4821은 발송되었으며 금요일에 도착할 예정입니다.”라고 답할 수 있습니다.
소유권 확인에 실패하면 애플리케이션은 조회를 실행하거나 상태를 공개해서는 안 됩니다. 권한 오류를 반환하면 모델이 개인 데이터를 노출하지 않고 이를 설명할 수 있습니다.
모델의 호출만으로 소유권이 증명된 것은 아닙니다. 도구 스키마는 유효한 요청을 설명했을 뿐이며, 실제 규칙은 애플리케이션이 적용했습니다.
도구 사용이 중요한 이유
도구 사용은 텍스트 생성만으로는 제공할 수 없는 기능에 언어 모델이 통제된 방식으로 접근하게 합니다.
- 최신 또는 비공개 데이터: 도구는 현재 정보나 모델의 학습 자료에 없었던 데이터를 가져올 수 있습니다.
- 정확한 작업: 계산기, 데이터베이스 쿼리 또는 프로그램은 그럴듯한 추정에 의존해서는 안 되는 작업을 수행할 수 있습니다.
- 실제 작업: 도구는 레코드 생성, 메시지 전송, 일정 예약 또는 다른 소프트웨어 조작을 수행할 수 있습니다.
- 기존 시스템: 도구는 자연어 요청을 기존 비즈니스 API 호출로 변환할 수 있습니다.
- 다단계 작업: 한 호출의 결과가 다음 호출을 안내할 수 있습니다.
도구 사용이 모델의 한계를 없애지는 않습니다. 일부 작업을 더 적합한 시스템으로 옮기고, 확률적 의사결정과 결정론적 소프트웨어 사이에 인터페이스를 만듭니다.
신뢰성과 안전성은 주변 시스템에 달려 있습니다
모델의 출력이 스키마와 일치한다는 이유만으로 신뢰할 수 있는 명령의 원천이 되는 것은 아닙니다. 실제 환경에서 도구를 사용하려면 모델 주변에 통제 장치가 필요합니다.
형식뿐 아니라 의미를 검증하세요. 식별자, 범위, 필수 상태 및 비즈니스 규칙을 확인하세요. 구조적 검증만으로는 제안된 트랜잭션이 사용자의 요청과 일치하는지 알 수 없습니다.
실행 시점에 권한을 부여하세요. 애플리케이션이 보유한 신원과 권한을 사용하세요. 모델이 도구 인수에 사용자 ID나 역할을 넣어 스스로 접근 권한을 부여하게 하지 마세요.
각 도구의 권한을 제한하세요. 범위가 좁은 get_order_status 도구는 일반적인 데이터베이스 도구보다 통제하기 쉽습니다. 위험이 서로 다르다면 읽기 전용 도구와 쓰기 도구를 분리해야 합니다.
도구 출력을 신뢰할 수 없는 데이터로 취급하세요. 외부 콘텐츠는 잘못되었거나 모델의 방향을 바꾸도록 설계된 텍스트를 포함할 수 있습니다. 반환된 문서는 검토해야 할 정보이지, 사용자의 요청이나 시스템 규칙을 대체할 새로운 권위가 아닙니다.
부작용을 신중하게 처리하세요. 메시지 전송이나 환불 처리는 상태 조회와 다릅니다. 민감한 작업에는 확인 절차, 중복 실행을 막기 위한 멱등성 보호, 감사 기록이 필요할 수 있습니다.
실패를 명확하게 반환하세요. 시간 초과, 서비스를 사용할 수 없는 상태, 거부된 권한, 잘못된 인수는 명시적인 도구 결과가 되어야 합니다. 그렇지 않으면 모델이 빈틈을 지어낸 성공 결과로 채울 수 있습니다.
흔한 오해
“LLM이 내 API를 호출했다”
대개 LLM은 요청을 생성했고 애플리케이션이 API를 호출한 것입니다. 모델이 도구를 “호출했다”고 말하는 것은 편리한 약칭이지만, 실행 및 보안 경계를 가립니다.
“함수 호출과 도구 호출은 항상 서로 다르다”
개발자가 정의한 함수의 경우 제공업체와 프레임워크는 두 용어를 서로 바꿔 사용하는 경우가 많습니다. 플랫폼이 도구를 함수와 검색 또는 코드 실행 같은 내장 기능을 합친 상위 개념으로 사용할 때 차이가 나타납니다. 보편적인 구분을 가정하지 말고 플랫폼의 분류 체계를 확인하세요.
“유효한 스키마는 올바른 호출을 의미한다”
스키마는 문자열, 숫자, 목록 또는 객체를 요구하고 잘못된 형식의 출력을 거부할 수 있습니다. 하지만 모델이 올바른 도구를 선택했는지, 올바른 값을 추론했는지, 비즈니스 규칙을 준수했는지는 보장할 수 없습니다.
“도구를 추가하면 에이전트가 만들어진다”
도구 사용은 하나의 기능입니다. 에이전트는 결정하고, 행동하고, 결과를 관찰하고, 관련 상태를 유지하고, 루프를 반복하고, 중지할 수 있는 더 큰 시스템입니다. 일회성 구조화 호출도 같은 메커니즘을 사용할 수 있지만 자율적인 워크플로가 되는 것은 아닙니다.
“도구 결과는 반드시 참이어야 한다”
모델은 잘못된 결과도 충실하게 요약할 수 있습니다. 도구의 신뢰성, 데이터 최신성, 접근 제어, 악성 콘텐츠에 대한 내성은 언어 모델 하나가 아니라 전체 시스템의 속성입니다.
AI 시스템에서 도구 사용의 위치
도구 사용은 언어 모델과 모델을 둘러싼 시스템 사이의 경계에 위치합니다.
모델은 언어를 해석하고 구조화된 다음 단계를 제안합니다. 애플리케이션은 도구 정의를 제공하고, 대화 상태를 유지하며, 호출을 검증하고, 권한을 관리하고, 작업을 실행하고, 관찰 결과를 반환합니다. 도구는 제한된 기능을 제공합니다. 에이전트는 이 구성을 반복적으로 사용해 더 큰 작업을 수행할 수 있습니다.
따라서 도구 사용의 품질은 모델만의 속성이 아닙니다. 명확한 도구 설명, 구분되는 스키마, 실행 제어, 유용한 오류 메시지, 합리적인 중지 규칙이 모두 시스템의 작동 여부에 영향을 줍니다.
다음 단계
도구 호출이 상태와 중지 규칙을 갖춘 반복적인 계획-행동-관찰 루프의 일부가 되는 방식을 알아보려면 AI 에이전트란 무엇인가요?를 읽어 보세요. 호출을 검증하고 실행하는 소프트웨어에 대해서는 AI 하네스란 무엇인가요?를 읽은 다음, 더 넓은 시스템에서 도구 사용의 위치를 파악하려면 AI 모델과 챗봇, 하네스, 에이전트의 차이를 사용해 보세요.