툴 호출(함수 호출)이란? AI가 진짜 도구를 쓰는 법, 초보자 가이드 (2026)

짧은 답부터

툴 호출(tool calling), 다른 말로 함수 호출(function calling)은 AI가 대화 밖으로 손을 뻗어 진짜 도구 — 웹 검색, 계산기, 내 캘린더, 회사 데이터베이스 — 를 직접 쓰게 해 주는 방식이에요. 기억에만 의존해 답하지 않고요. 거대 언어 모델은 혼자서는 글은 정말 잘 쓰지만, 세상에 실시간으로 접속할 수단이 없어요. 오늘 환율을 진짜로 조회하거나 내 최신 주문을 읽어 올 수 없죠. 툴 호출은 이 빈틈을 메웁니다. 모델이 정해진 형식으로 “런던 *get_weather* 도구를 실행해 줘”라고 요청하고, 그 도구가 돌아가는 동안 기다렸다가, 돌려받은 진짜 결과를 가지고 답을 쓰게 해 주는 거예요. 똑똑한 동료가 머릿속 기억으로만 답하는 것과, 잠깐 전화를 걸어 확인하고 답하는 것의 차이라고 보면 됩니다. 이 한 가지 능력 — 잠깐 멈춰 진짜 도구를 쓰고 다시 이어서 답하는 것 — 이 바로 요즘 들어 본 거의 모든 AI 에이전트의 숨은 엔진이에요.

핵심 요약

툴 호출은 챗봇이 학습한 내용에만 기대지 않고 검색, 계산기, API, 내 파일 같은 진짜 도구를 쓰게 해 줘요.
모델이 도구를 직접 실행하지는 않아요. 도구 이름과 입력값을 담아 ‘요청’하면, 내 소프트웨어가 실제로 실행하고, 진짜 결과가 돌아오면 모델이 이어서 답합니다.
‘함수 호출’과 ‘툴 호출’은 같은 말이에요. 모델이 개발자가 열어 둔 특정 함수 — `get_weather`, `search_orders`, `add_to_calendar` — 를 불러 달라고 요청하는 거죠.
AI 에이전트의 엔진이 바로 이거예요. ‘행동하는’ 비서는 거의 다 도구를 반복해서 호출하며 일을 끝내는 모델입니다.
믿음직하지만 완벽하진 않아요. 엉뚱한 도구를 부르거나, 잘못된 입력을 넘기거나, 결과를 오독할 수 있어서 위험한 일은 사람이 한 번 확인하는 게 좋습니다.

툴 호출이 정확히 뭔가요

먼저 이게 없애 주는 한계부터 봐요. 평범한 언어 모델은 전화도, 인터넷도, 서류함도 없는 방에 갇힌 박학다식한 사람과 같아요. 한 번 읽은 건 거의 다 이야기할 수 있고 글도 술술 쓰지만, ‘지금’ 벌어지는 일은 아무것도 못 봅니다. 오늘 주가, 내 계좌 잔액, 긴 곱셈의 결과를 물으면 기껏해야 그럴듯한 추측을 내놓아요. 이 ‘자신만만한 추측’이야말로 사람들이 사실 확인이 필요한 일에 AI를 못 믿게 만드는 지점이죠.

툴 호출은 그 닫힌 방에 작고 통제된 쪽문을 하나 냅니다. 개발자가 모델에게 쓸 수 있는 도구 목록을 짧게 건네줘요. 각 도구가 무슨 일을 하고, 실행하려면 어떤 정보가 필요한지를 쉬운 말로 적어서요. 기억보다 도구가 더 잘 답할 질문이 오면, 모델은 답을 지어내려 하지 않아요. 대신 “`customer_id = 4821`로 *search_orders*를 실행해 줘” 같은 구조화된 요청을 내놓고 기다립니다. 내 소프트웨어가 그 요청을 읽어 도구를 실제로 실행하고, 진짜 결과를 대화 안으로 돌려줘요. 그제야 모델이 사실에 근거한 답을 씁니다.

꼭 기억할 점은, 모델이 직접 무언가를 실행하지는 않는다는 거예요. 모델에겐 손이 없어요. 정해진 형식으로 도구 실행을 ‘요청’할 수 있을 뿐이고, 그 요청을 들어줄지 말지, 어떻게 들어줄지는 둘러싼 소프트웨어가 정합니다. 이건 피해 가야 할 약점이 아니라 안전 설계예요. 모델은 제안하고, 내 코드가 결정합니다.

어떻게 돌아가는지, 단계별로

기술 배경이 없어도 흐름은 따라올 수 있어요. 동작은 네 단계이고, 이게 반복됩니다.

**도구를 건넨다.** 대화 전에 개발자가 모델에게 쓸 수 있는 도구 목록을 줘요. 각 도구에는 이름, 짧은 설명, 필요한 입력값(예: 도시 이름이 필요한 `get_weather`)이 적혀 있죠. 이 목록은 질문 옆에 함께 모델의 컨텍스트 윈도우에 실립니다.
**모델이 판단하고 요청한다.** 도구로 답할 질문이 오면, 모델은 글이 아니라 도구 이름과 입력값을 채운 구조화된 요청으로 답해요. 이 요청은 소프트웨어가 추측 없이 읽을 수 있도록 엄격한 형식 — 보통 JSON 형태의 작은 데이터 — 을 따릅니다.
**내 소프트웨어가 도구를 실행한다.** 애플리케이션이 그 요청을 받아 실제 함수나 서비스를 호출하고, 구체적인 결과를 받아 와요. 실시간 기온, 일치하는 주문, 계산된 합계 같은 것들요.
**모델이 결과로 답한다.** 그 진짜 결과를 모델에게 돌려주면, 모델은 추측이 아니라 그 결과에 기반한 평범한 답 — “지금 런던은 14도이고 비가 와요” — 을 씁니다.

이게 전부예요. 요청하고, 실행하고, 돌려받고, 답한다. 어려운 일이면 이 고리가 여러 번 돌 뿐이에요. 모델이 검색 도구를 부르고, 결과를 읽고, 계산기를 부르고, 그다음 답하는 식이죠. ‘에이전트’가 해내는 인상적인 일들은 대부분 이 작은 고리가 반복되는 모습입니다.

일상 비유로 보면

첫 출근한 똑똑한 비서를 떠올려 봐요. 말도 잘하고 아는 것도 많지만, 우리 고객 명단을 외우지 못했고, 실시간 재고도 볼 수 없고, 급여 계산을 암산으로 맡기고 싶지도 않죠. 그래서 분명히 이름표가 붙은 도구를 몇 개 줍니다. 주문 검색창, 계산기, 공용 캘린더요. 그리고 규칙을 하나 정해요. *찾아볼 수 있는 건 지어내지 말 것.*

이제 고객이 “제 주문 언제 도착하나요?”라고 물으면, 비서는 추측하지 않아요. 주문 검색 도구를 켜고 고객 번호를 넣어 화면에 뜬 진짜 답을 읽은 뒤에야 대답합니다. 툴 호출이 바로 이 구도예요. 모델은 말 잘하는 비서, 도구는 책상 위 이름표 붙은 기구들, 구조화된 요청은 비서가 말하기 전에 알맞은 도구로 손을 뻗는 동작입니다. 비서가 더 똑똑해진 건 아니지만, 답이 갑자기 도구가 실제로 돌려준 것에 단단히 묶이게 돼요.

한 장면으로 그려 보는 예시

여행 비서에게 “이번 주말 리스본 날씨 어때? 여기 베를린보다 따뜻해?”라고 물었다고 해 봐요.

평범한 챗봇에는 실시간 날씨 정보가 없어요. “리스본은 봄에 보통 온화해요” 정도로 답할 수 있는데, 그럴듯하지만 두루뭉술하고 이번 주말엔 틀릴 수도 있죠. 툴 호출 비서는 다르게 움직여요. 진짜 데이터가 필요하다고 판단해서 리스본에 대해 `get_weather` 도구를 실행하라는 요청을 내보내고, 실제 예보가 올 때까지 기다린 뒤, 베를린에 대해 두 번째 요청을 내보내요. 두 실제 결과를 손에 쥔 다음 비교해서 답합니다. “이번 주말 리스본은 22도쯤에 맑고, 베를린은 15도쯤이에요. 네, 리스본이 눈에 띄게 따뜻하네요.” 같은 질문이지만 한쪽은 추측, 다른 쪽은 실제로 수행한 두 번의 조회로 쌓아 올린 답이에요. 게다가 각 단계가 분리된 요청으로 기록되니, 개발자는 어떤 도구가 어떤 입력으로 불렸는지 그대로 확인할 수 있습니다.

툴 호출이 중요한 이유

가장 큰 이점은, 글은 잘 쓰지만 앞을 못 보는 모델이 현실을 만질 수 있게 된다는 거예요. 실시간이거나 개인적이거나 정밀한 정보 — 현재 가격, 내 계좌, 정확한 계산 — 가 ‘자신만만한 추측’에서 ‘확인된 사실’로 바뀝니다. 답이 모델의 흐릿한 기억이 아니라 도구의 실제 출력으로 만들어지니까요.

두 번째 이점은, 이게 바로 AI 에이전트의 작동 원리라는 점이에요. 식당을 예약하고, 경비를 처리하고, 기록을 갱신하는 비서를 말할 때, 사람들은 사실 고리 안에서 도는 툴 호출을 묘사하고 있는 거예요. 세상에서 행동하는 에이전트 — AI가 대신 일해 주는 에이전트에서 다룬 종류 — 는 속을 보면 다음에 어떤 도구를 부를지 정하며 일을 끝내는 모델입니다. 툴 호출을 이해하는 게 곧 에이전트의 작동 방식을 이해하는 거예요.

세 번째 이점은, 들여다보고 검증할 수 있다는 점이에요. 모든 도구 호출이 명시적이고 구조화된 요청이라, 둘러싼 소프트웨어가 무엇을 요청했는지 기록하고, 규칙과 대조하고, 민감한 건 승인을 받게 하고, 선을 넘는 호출은 거절할 수 있어요. 모델이 ‘하고 싶어 하는 것’과 ‘실제로 하는 것’이 두 개의 분리된 사건이라는 점 — 바로 거기에 안전장치를 끼워 넣을 수 있습니다.

도구, 함수, 그리고 ‘MCP’ — 자주 듣게 될 말들

비슷한 말들이 섞여 쓰이니 한 번 정리하면 편해요.

**툴 호출 vs 함수 호출.** 이름만 둘인 같은 개념이에요. ‘함수 호출’은 각 도구가 코드 속 함수이기 때문에 붙은 좀 더 개발자스러운 옛 용어이고, ‘툴 호출’은 에이전트가 대중화되며 흔해진 친근한 표현입니다. 제품에서 둘 중 무엇을 말하든 같은 ‘요청-실행-반환-답변’ 고리를 떠올리면 돼요.
**도구 정의.** 각 도구는 이름, 쉬운 말로 적은 용도, 입력값 스키마 — “이 도구는 도시 이름을 텍스트로 받는다” 같은 작은 규격 — 로 모델에게 설명돼요. 이 설명이 모델이 언제 어떻게 그 도구를 쓸지 아는 근거입니다. 설명이 흐릿하면 엉뚱한 호출이 나오고, 명확하면 절반은 성공이에요.
**MCP.** 앞으로 MCP(모델 컨텍스트 프로토콜)를 점점 자주 보게 될 거예요. AI 비서를 도구·데이터와 잇는 공용 표준입니다. 만능 어댑터라고 보면 돼요. 앱마다 제각각 도구 연결 방식을 만드는 대신, MCP라는 공통 플러그를 쓰면 같은 캘린더·데이터베이스 도구를 여러 비서에서 그대로 쓸 수 있죠.

이 가운데 무엇도 핵심 그림을 바꾸지는 않아요. 이름이 뭐든 모델은 여전히 도구 이름과 입력값을 ‘요청’할 뿐이고, 실제로 실행하는 건 여전히 내 소프트웨어입니다.

그래도 툴 호출이 어긋나는 곳

툴 호출은 튼튼한 개념이지만, 초보자라면 실패하는 방식을 알아 둬야 결과에 놀라지 않아요.

**엉뚱한 도구, 잘못된 입력.** 모델이 요청을 잘못 짜서 엉뚱한 도구를 부르거나, 맞는 도구에 틀린 입력 — 잘못된 주문 번호, 형식이 어긋난 날짜 — 을 넘길 수 있어요. 도구는 받은 그대로 충실히 실행하니, 그럴듯해 보이는 답이 잘못된 호출 위에 서 있을 수 있죠.
**결과 오독.** 올바른 결과가 돌아와도, 모델이 최종 답을 쓰며 그 값을 잘못 요약하거나 어림할 때가 있어요. 진짜 데이터를 받으면 지어낼 확률은 줄지만, 완벽이 보장되진 않습니다.
**너무 적극적인 행동.** 에이전트 고리에서 모델은 여러 도구 호출을 빠르게 이어 갈 수 있는데, 그중 하나가 무언가를 ‘바꾸는’ 도구(메시지 발송, 주문)라면 작은 오판이 틀린 문장이 아니라 진짜 행동이 돼요. 그래서 돈이 들거나 되돌리기 어려운 일은 사람의 승인을 거치게 해야 합니다.
**건넨 도구만큼만.** 모델은 도구 목록이 허락한 일만 할 수 있어요. 필요한 도구가 빠져 있으면, 허술한 설정에서는 “그건 쓸 도구가 없어요”라고 말하는 대신 슬그머니 추측으로 돌아가기도 합니다.

실전 교훈은 이래요. 명확한 도구 설명, ‘읽기’가 아니라 ‘행동’하는 도구의 신중한 처리, 비용이 드는 단계의 사람 확인 — 이게 더 똑똑한 모델을 좇는 것보다 중요합니다.

다른 AI 개념과 어떻게 이어지나

툴 호출은 초보자가 따로따로 만나는 여러 개념을 한데 묶어요. 쓸 수 있는 도구 목록과 돌려받은 결과는 질문 옆에서 모델의 컨텍스트 윈도우에 들어가야 하고, 모든 텍스트가 그렇듯 토큰으로 측정돼요. 그래서 많은 도구를 다루는 모델은 한정된 공간도 더 쓰는 셈이죠. 모델이 ‘어떤’ 도구를 쓸지, 요청을 어떻게 쓸지 정하는 판단은 바탕에 깔린 프롬프트와 AI 추론 모델에서 다룬 추론 능력에 좌우됩니다. 또 툴 호출은 검색 증강 생성(RAG) 바로 옆에 있어요. RAG가 모델을 위해 조용히 문서를 가져다준다면, 툴 호출은 모델이 ‘스스로’ 가져오거나 행동하기로 정하는 거예요. 둘은 사촌 사이입니다. 답하기 전에 모델에게 진짜를 먹인다는 점에서요.

흔한 실수, 이건 피하세요

모델이 도구를 직접 실행한다고 생각하는 것. 아니에요. 모델은 요청만 하고, 실행은 내 소프트웨어가 합니다. 그 틈에 모든 안전장치가 들어가요.
‘함수 호출’과 ‘툴 호출’을 다른 기능으로 보는 것. 이름만 둘인 한 개념이에요. 용어에 헷갈리지 마세요.
도구로 뒷받침된 답을 무턱대고 믿는 것. 툴 호출은 답을 훨씬 믿음직하게 하지만, 모델은 여전히 엉뚱한 도구를 부르거나 결과를 오독할 수 있어요. 중요한 건 확인하세요.
승인 단계 없이 ‘행동하는’ 도구를 에이전트에 주는 것. 읽기 전용 도구는 위험이 낮지만, 보내거나 사거나 지우는 도구는 믿음이 쌓이기 전까지 사람을 거치게 하세요.
툴 호출과 RAG를 혼동하는 것. RAG는 뒤에서 문서를 가져오고, 툴 호출은 모델이 스스로 도구를 부르고 행동하게 합니다. 겹치고 함께 쓰이기도 하지만 같은 게 아니에요.

자주 묻는 질문

**툴 호출이 함수 호출과 같은 건가요?** 네. 한 개념의 두 이름이에요. 모델이 개발자가 열어 둔 특정 도구(함수)를 실행하라는 구조화된 요청을 내놓고, 진짜 결과가 오면 이어서 답하는 것입니다. ‘함수 호출’은 더 오래된 개발자 용어이고, ‘툴 호출’은 AI 에이전트가 대중화되며 흔해진 표현이에요.

**AI가 도구를 스스로 실행하나요?** 아니에요. 이게 중요합니다. 모델은 도구 이름과 입력값으로 ‘요청’만 할 수 있어요. 그 요청을 실제로 실행할지는 애플리케이션이 정합니다. 이 분리 덕분에 개발자가 호출을 기록하고, 민감한 건 승인을 받게 하고, 선을 넘는 건 막을 수 있어요.

**툴 호출이 AI의 거짓말을 막아 주나요?** 도구로 확인할 수 있는 것 — 실시간 데이터, 내 기록, 정확한 계산 — 에는 큰 도움이 돼요. 답이 기억이 아니라 진짜 결과로 만들어지니까요. 다만 완전한 해결책은 아니에요. 모델이 엉뚱한 도구를 부르거나, 잘못된 입력을 넘기거나, 결과를 오독할 수 있어서 중요한 단계는 한 번 살펴보는 게 좋습니다.

**AI는 어떤 도구를 부를 수 있나요?** 함수로 감쌀 수 있는 건 거의 다요. 웹 검색, 계산기, 날씨·지도 서비스, 회사 데이터베이스, 내 캘린더나 메일, 다른 앱의 API 등이죠. 어떤 도구를 열어 줄지는 개발자가 고르고, 모델이 언제 쓸지 알도록 각 도구를 설명해 둡니다.

**툴 호출은 AI 에이전트와 어떤 관계인가요?** 아주 가까워요. 행동하는 AI 에이전트는 본질적으로 도구를 고리처럼 부르는 모델이에요. 도구를 고르고, 결과를 읽고, 다음 도구를 고르며 일을 끝내죠. 툴 호출을 이해하면 에이전트를 가능하게 하는 핵심 장치를 이해한 겁니다.

출처

Anthropic: 도구 사용(함수 호출): 모델이 도구를 요청하고, 결과를 기다렸다가, 이어서 답하는 방식을 다룬 Anthropic의 개발자 가이드. 여기서 설명한 ‘요청-실행-반환-답변’ 고리의 명확한 1차 자료입니다.
OpenAI: 함수 호출 가이드: 모델이 개발자가 정의한 함수에 대한 구조화된 호출을 내놓는 방식을 설명한 OpenAI 문서. 같은 장치를 ‘함수 호출’이라는 이름으로 다룬 독립적인 설명이에요.
Model Context Protocol: 소개: AI 비서를 도구·데이터와 잇는 공개 표준인 MCP의 공식 개요. 위에서 말한 ‘만능 어댑터’의 출처입니다.
Google: Gemini API의 함수 호출: 모델이 함수를 불러 실시간 데이터를 가져오거나 행동하게 하는 법을 초보자 눈높이로 다룬 Google 가이드. 세 번째 제공사에서 같은 패턴을 확인하기에 좋아요.