Tool Use는 에이전트가 모델 내부 추론만으로 얻기 어려운 정보를 외부에서 가져오거나, 모델이 직접 수행할 수 없는 작업을 외부 기능에 위임하는 메커니즘이다. 계획이 방향을 정하고 실행이 결과를 만들어낸다면, 도구 사용은 그 사이에서 "실제로 확인하고 처리하는" 단계를 담당한다. 도구 없이는 에이전트의 실행이 모델 내부 지식에 갇힌다.
Tool Use는 에이전트가 모델 내부 추론만으로 얻기 어려운 정보를 외부에서 가져오거나, 모델이 직접 수행할 수 없는 작업을 외부 기능에 위임하는 메커니즘이다. 계획이 방향을 정하고 실행이 결과를 만들어낸다면, 도구 사용은 그 사이에서 "실제로 확인하고 처리하는" 단계를 담당한다. 도구 없이는 에이전트의 실행이 모델 내부 지식에 갇힌다.
이 글에서는 에이전트 시스템에서 Tool Use의 개념과 역할을 설명한다. 특정 API, 플러그인, 보안 설정, 구현 방식은 다루지 않는다.
LLM은 학습 데이터에 없는 최신 정보를 알 수 없다. 수식 계산을 항상 정확하게 처리한다고 보장할 수 없다. 사내 시스템에 직접 접근할 수도 없다. 도구를 통해 이 세 가지 한계를 외부 기능으로 보완한다.
도구가 없는 에이전트는 학습 당시의 내부 지식과 추론만으로 답을 만든다. 최신성이나 정확성을 보장하기 어렵고, 결과의 근거를 추적하기 어렵다. 도구가 있으면 외부에서 정보를 가져오거나 계산을 실행해 근거가 남는 결과를 만들고, 도구 결과에 이상이 있으면 재호출하거나 다른 도구로 전환할 수 있다.
에이전트는 작업 유형에 따라 어떤 도구를 쓸지 판단한다. 계약서 조항을 검토할 때 법령의 최신 시행 일자는 법령 DB API로 조회하고, 과거 계약 선례는 사내 문서 저장소에서 검색하고, 계약 금액의 환율 환산은 코드로 계산한다. 모델이 직접 처리하는 부분과 도구에 맡기는 부분이 구분된다.
도구 결과를 받으면 그냥 쓰는 것이 아니라 관찰(Observation)한다. 조회 결과가 비어 있거나 불완전하면, 다른 출처로 전환하거나 쿼리를 바꿔 재호출한다. 결과가 맥락에 맞지 않으면 다음 단계 계획을 조정한다.
도구 접근은 필요한 범위로 제한하는 것이 기본이다. 고객 데이터를 조회하는 에이전트에게 데이터를 수정할 권한까지 줄 필요는 없다. 필요한 도구에만, 필요한 범위만큼 열어두는 설계가 운영 안전성과 직결된다.
관점Tool Use 미사용Tool Use 활용정보 출처학습 시점의 모델 내부 지식외부 최신·정확 정보실행 범위텍스트 추론·생성 중심조회·계산·시스템 처리까지 확장결과 검증근거 추적이 어려움도구 결과를 관찰·검증 가능오류 대응단일 응답 내 수정에 제한재호출·다른 도구로 전환 가능
"도구가 있으면 곧 에이전트다"
도구 호출은 에이전트의 중요한 요소지만, 계획·상태 관리·다회 실행과 결합될 때 에이전트 시스템으로서의 의미가 커진다. 도구 하나를 단발적으로 호출하는 것은 에이전트라고 보기 어렵다.
"도구 호출 결과는 항상 정확하다"
도구도 오류가 날 수 있다. API 응답이 비어 있거나, 검색 결과가 맥락에 맞지 않거나, 계산 코드에 버그가 있을 수 있다. 결과를 무비판적으로 신뢰하지 않는 설계가 필요하다.
"도구가 많을수록 에이전트가 강력해진다"
도구가 많아지면 어떤 도구를 쓸지 선택하는 복잡도가 증가하고 관리 부담도 늘어난다. 목적에 맞는 최소한의 도구를 잘 설계하는 것이 중요하다.
Q1. Tool Use는 모든 에이전트에 필요한가?
아니다. 내부 지식과 추론만으로 처리 가능한 작업에서는 필요하지 않을 수 있다.
Q2. 도구 호출과 API 연동은 같은 개념인가?
API 연동은 도구 구현 방식의 하나다. 도구 호출은 코드 실행, 웹 검색, 파일 읽기 등 더 넓은 범위를 포함하는 개념이다.
Q3. 도구 결과는 어떻게 활용되는가?
관찰 정보로 저장되어 다음 추론이나 계획 조정의 근거로 사용된다. ReAct 패턴에서는 매 단계의 도구 결과가 즉시 다음 추론에 반영된다.
Q4. Tool Use는 보안 문제를 일으킬 수 있는가?
가능하다. 에이전트가 실행하는 도구 범위와 접근 권한이 넓을수록 의도치 않은 시스템 변경이 발생할 수 있다. 최소 권한 원칙과 접근 범위 제한이 함께 설계되어야 한다.
