Tool Use

Beyond text: letting models act through tools.

— LLM과 AI 에이전트 생태계에서 통용되는 개념적 설명

모델에게 손발을 달아주는 순간, 개발자는 그 손발이 사고 치지 않게 감시하는 보호자가 된다. 말로만 똑똑하던 놈에게 터미널을 쥐여줬더니 이제 진짜로 사고를 칠 수 있게 됐다.

1. 개요

Tool Use는 LLM이나 AI 에이전트가 텍스트를 생성하는 수준을 넘어, 외부 도구를 호출해 모델 혼자서는 할 수 없는 작업을 수행하는 개념이다. 사람이 계산기, 검색 엔진, 터미널, 데이터베이스 클라이언트를 꺼내 쓰듯이 모델도 API, 웹 검색, 코드 실행 환경, 데이터베이스, 파일 시스템 같은 도구를 호출해 결과를 다시 추론에 사용한다. 과거의 LLM은 내부 학습 지식에만 기대다 보니 최신 정보, 정확한 계산, 외부 시스템 제어에서 쉽게 한계를 드러냈지만, Tool Use는 이 약점을 도구 호출이라는 우회로로 돌파한다. 덕분에 LLM은 그럴듯한 말만 늘어놓는 챗봇에서 실제 작업을 처리하는 실행 주체에 가까워졌고, 동시에 개발자는 도구 권한과 예외 처리를 챙겨야 하는 새로운 고통을 얻었다.(...)

2. 핵심 원리

Tool Use의 기본 흐름은 단순하다. 모델이 사용자의 프롬프트를 읽고, 현재 답변만으로는 부족하다고 판단하면 미리 정의된 도구 목록에서 적절한 도구를 고른다. 이후 도구 이름과 인자(arguments)를 구조화된 형식, 보통 JSON 형태로 생성하고, 런타임은 그 호출을 실제 API나 함수 실행으로 연결한다. 실행 결과는 다시 모델에게 입력되어 다음 답변이나 다음 도구 호출의 근거가 된다. 이 과정을 잘 묶으면 AI 에이전트가 검색하고, 계산하고, 파일을 읽고, 코드를 실행한 뒤 최종 결과까지 정리하는 루프를 만들 수 있다. 물론 루프라는 말이 들어가는 순간 무한 루프와 과금 폭탄도 같이 따라온다.1

3. Function Calling과의 관계

Function Calling은 Tool Use를 구현하는 대표적인 인터페이스다. 개발자가 get_weather, run_query, send_email 같은 함수의 이름, 설명, 입력 스키마를 모델에게 알려주면, 모델은 자연어 요청을 해당 함수 호출 형태로 바꿔준다. 즉 Tool Use가 큰 개념이라면 Function Calling은 그 도구를 어떤 이름과 인자 구조로 호출할지 정하는 계약서에 가깝다. 최근에는 여기에 Model Context Protocol 같은 표준화 흐름이 붙으면서, 각 서비스마다 따로 도구 연결 코드를 짜던 방식에서 조금 더 공통된 인터페이스로 넘어가려는 움직임도 생겼다.

4. 대표적인 도구 유형

Tool Use에서 자주 쓰이는 도구는 크게 몇 가지로 나뉜다. 첫째, 최신 정보를 가져오기 위한 검색 도구가 있다. 이는 RAG나 웹 검색과 결합해 할루시네이션을 줄이는 데 쓰인다. 둘째, 파이썬이나 자바스크립트를 실행하는 코드 실행기가 있다. 모델이 암산으로 틀릴 법한 계산이나 데이터 처리를 실제 런타임에 맡기는 방식이다. 셋째, SQL, NoSQL, 사내 API처럼 외부 시스템에 접근하는 업무용 도구가 있다. 이 단계부터는 단순한 챗봇이 아니라 회사 내부 데이터를 읽고 쓰는 자동화 시스템에 가까워지므로, 권한과 감사 로그가 없으면 꽤 빠르게 위험해진다.(...)

5. 실무에서의 위험 요소

Tool Use가 강력한 이유는 모델이 외부 세계에 영향을 줄 수 있기 때문이고, 위험한 이유도 정확히 같다. 모델이 엉뚱한 도구를 고르거나, 잘못된 인자를 만들어내거나, 도구 실행 결과를 오해하면 전체 작업이 이상한 방향으로 굴러간다. 특히 파일 삭제, 배포, 결제, 데이터 수정처럼 되돌리기 어려운 작업을 도구로 열어두면 프롬프트 엔지니어링만으로는 충분하지 않다. 실무에서는 스키마 검증, 권한 분리, 휴먼 컨펌, 재시도 제한, 비용 제한, 감사 로그를 함께 둬야 한다. 안 그러면 AI가 똑똑해진 것이 아니라 사고 칠 수 있는 표면적만 넓어진 자동화 스크립트가 된다.

6. 관련 밈 및 드립

6.1. 도구는 줬지만 믿음은 못 줌

Tool Use가 실무에 들어오면 개발자는 모델에게 도구를 쥐여주면서도 정작 그 선택을 끝까지 믿지 못한다. 그래서 함수 호출 결과를 다시 검증하고, 위험한 액션 앞에는 확인 버튼을 넣고, 실패하면 재시도 횟수를 제한한다. 겉으로는 자율형 AI 에이전트인데 속을 까보면 if, try/catch, 스키마 검증, 권한 체크가 빽빽한 전통적 백엔드 코드인 경우가 많다. 결국 AI가 자유를 얻은 만큼 개발자는 감시 업무를 얻는다는 점에서 묘한 등가교환이다.(...)

6.2. 계산기 줬더니 검색을 함

간단한 산술 계산에는 코드 실행기를 쓰면 되는데, 모델이 갑자기 웹 검색 도구를 부르거나 반대로 최신 문서가 필요한데 내부 지식으로 우겨버리는 식의 도구 선택 실패를 비꼬는 말이다. Tool Use의 난점은 도구 목록을 주는 데서 끝나지 않고, 언제 어떤 도구를 써야 하는지를 모델이 안정적으로 판단하게 만드는 데 있다. 이 판단이 흔들리면 고급 에이전트 시스템도 순식간에 비싼 자동 클릭봇으로 전락한다.

7. 여담

  • Toolformer의 영향: 2023년에 공개된 Toolformer 계열 연구는 모델이 외부 API를 사용하는 법을 학습할 수 있다는 방향을 보여주며 Tool Use 논의를 대중화하는 데 큰 역할을 했다.
  • Toolus 이름의 유래: Toolus는 Tool Use에서 따온 이름이며, 복잡한 소프트웨어 학습을 보는 강의에서 실제 작업 화면 위에서 직접 따라 완성하는 AI 기반 인터랙티브 실습으로 바꾸려는 서비스다.
  • ReAct 패턴과의 궁합: 추론(Reasoning)과 행동(Acting)을 번갈아 수행하는 ReAct 계열 접근은 모델이 생각하고, 도구를 쓰고, 결과를 보고 다시 생각하는 Tool Use 루프와 잘 맞는다.
  • 에이전트 프레임워크의 핵심 부품: LangChain이나 LangGraph 같은 프레임워크에서 Tool Use는 단순 부가 기능이 아니라 에이전트를 에이전트답게 만드는 핵심 구성 요소에 가깝다.

8. 관련 문서

각주

  1. 도구 호출 실패를 보고 모델이 다시 호출하고, 그 실패를 또 보고 다시 호출하는 식의 루프가 생기면 사용자는 결과 대신 API 사용량 그래프가 치솟는 광경을 보게 된다. ↩

이 문서를 가리키는 문서