AI 모델은 문장을 만들 수 있지만, 그 자체로 우리 회사의 캘린더나 데이터베이스를 마음대로 조작하지는 못합니다. 모델이 사용할 수 있는 도구를 알려주고, 필요한 입력값을 구조화해 실행을 요청한 뒤, 애플리케이션이 그 요청을 검증하고 실행해야 합니다.
이 연결 방식이 바로 Tool Calling입니다. 이번 글에서는 모델의 판단이 어떻게 실제 검색·조회·등록 같은 행동으로 이어지는지, 그리고 왜 승인과 검증이 반드시 필요한지 단계별로 살펴보겠습니다.
1. 답변만 만드는 AI에는 한계가 있다
일반적인 대화형 AI는 질문을 이해하고 자연스러운 답변을 만드는 데 강합니다. 하지만 최신 날씨, 사내 문서, 고객 데이터처럼 모델 밖에 있는 정보는 별도의 연결 없이 직접 확인할 수 없습니다. 메일 발송이나 일정 등록처럼 외부 시스템을 바꾸는 행동도 마찬가지입니다.
따라서 “AI가 일을 한다”는 표현은 모델이 모든 것을 직접 처리한다는 뜻이 아닙니다. 모델은 어떤 도구를 어떤 값으로 사용할지 요청하고, 실제 실행은 도구를 연결한 애플리케이션이나 플랫폼이 담당합니다.
2. Tool Calling이란 무엇일까
Tool Calling은 모델에게 사용할 수 있는 도구의 이름, 설명, 입력 형식을 알려주고, 사용자의 목표를 해결하는 데 도구가 필요하면 모델이 구조화된 호출 요청을 만들게 하는 방식입니다. Function Calling이라고 부르는 경우도 있지만, 최근에는 함수뿐 아니라 검색·파일·브라우저 등 더 넓은 실행 수단을 포함해 Tool Calling이라는 표현을 많이 사용합니다.
모델은 “이 도구를 이 입력값으로 호출해 주세요”라는 요청을 만듭니다. 애플리케이션은 그 요청이 허용됐는지 확인한 뒤 실제 함수나 API를 실행하고, 결과를 다시 모델에게 전달합니다.
3. 도구는 이름·설명·입력값으로 정의한다
모델이 도구를 올바르게 고르려면 도구 설명서가 분명해야 합니다. 가장 기본적인 정의에는 도구의 이름, 언제 사용하는지 알려주는 설명, 그리고 어떤 값이 필요한지 정하는 입력 스키마가 포함됩니다.
{
"name": "get_weather",
"description": "지정한 도시의 현재 날씨를 조회합니다.",
"parameters": {
"city": "조회할 도시 이름",
"unit": "celsius 또는 fahrenheit"
}
}위 예시는 이해를 위한 단순화된 형태입니다. 이름이 모호하거나 설명이 너무 짧으면 모델은 비슷한 도구를 혼동할 수 있습니다. 입력 가능한 값의 형식과 필수 여부를 명확히 정하면 잘못된 호출을 줄이고 검증도 쉬워집니다.
모델이 입력 형식에 맞는 호출을 만들었다고 해서 곧바로 실행해도 안전하다는 뜻은 아닙니다. 사용자 권한, 허용 범위, 변경 대상, 승인 여부는 실행 계층에서 다시 확인해야 합니다.
4. Tool Calling은 6단계로 작동한다
Tool Calling의 핵심은 한 번의 답변이 아니라 요청 → 판단 → 실행 → 관찰 → 답변으로 이어지는 왕복 흐름입니다. “서울 날씨를 확인해서 우산이 필요한지 알려줘”라는 요청을 예로 들어보겠습니다.
↓
② 모델이 도구 필요 여부와 종류 판단
↓
③ 모델이 도구 이름과 입력값 생성
↓
④ 애플리케이션이 검증 후 실제 도구 실행
↓
⑤ 실행 결과를 모델에게 다시 전달
↓
⑥ 모델이 결과를 해석해 최종 답변 생성
날씨 조회 결과에 비가 올 확률이 포함되면 모델은 그 데이터를 근거로 우산 필요 여부를 설명합니다. 결과가 없거나 오류가 발생하면 재시도할지, 다른 도구를 사용할지, 사용자에게 추가 정보를 물을지 결정할 수 있습니다.
5. 모델의 선택과 애플리케이션의 책임을 구분하자
도구가 등록되어 있어도 매번 호출할 필요는 없습니다. 시스템은 모델이 답변과 도구 호출 중 하나를 선택하게 하거나, 반드시 도구를 사용하도록 요구하거나, 특정 도구만 선택하게 제한할 수 있습니다. OpenAI API 문서에서는 이런 제어를 none, auto, required, 특정 도구 지정 같은 방식으로 설명합니다.
| 구분 | 모델이 하는 일 | 애플리케이션이 하는 일 |
|---|---|---|
| 도구 선택 | 요청과 설명을 바탕으로 적절한 도구 판단 | 사용 가능한 도구 목록과 범위 결정 |
| 입력값 | 필요한 인수를 구조화해 제안 | 형식, 권한, 허용 값, 민감정보 검증 |
| 실행 | 실행 요청 생성 | 함수·API를 호출하고 오류 처리 |
| 결과 | 결과를 해석해 다음 행동이나 답변 생성 | 결과와 상태를 기록하고 모델에 전달 |
6. 실제 업무에서는 여러 도구 호출이 이어진다
한 번의 도구 호출로 끝나는 업무도 있지만, AI 에이전트는 여러 결과를 확인하며 다음 행동을 이어갈 수 있습니다. 예를 들어 “다음 주 팀 회의 가능한 시간을 찾아 초안을 만들어줘”라는 목표에는 캘린더 조회와 시간 비교, 회의 초안 작성이 순서대로 필요합니다.
여기서 캘린더를 읽는 행동과 새 일정을 등록하는 행동의 위험도는 다릅니다. 조회는 자동으로 허용하더라도 외부 변경은 승인 후 실행하도록 나누면 편의성과 안전을 함께 확보할 수 있습니다.
7. Tool Calling은 어디서 실패할까
모델이 도구를 잘 선택해도 입력값이 틀리거나, 외부 서비스가 응답하지 않거나, 실행 권한이 부족하면 작업은 실패할 수 있습니다. 따라서 정상 흐름뿐 아니라 실패했을 때의 행동도 설계해야 합니다.
| 실패 유형 | 예시 | 대응 방법 |
|---|---|---|
| 잘못된 도구 선택 | 조회 요청에 수정 도구를 선택 | 도구 설명과 역할을 분리하고 허용 목록 적용 |
| 잘못된 입력값 | 없는 날짜나 잘못된 고객 ID | 스키마와 업무 규칙으로 실행 전 검증 |
| 권한 부족 | 허용되지 않은 문서나 계정 접근 | 최소 권한 적용 후 명확한 오류 반환 |
| 외부 서비스 오류 | API 지연, 연결 실패, 호출 한도 초과 | 제한된 재시도, 대체 경로, 사용자 안내 |
| 위험한 변경 | 잘못된 메일 발송이나 일정 삭제 | 실행 전 미리보기와 사용자 승인 |
API가 성공을 반환했더라도 사용자가 원한 대상과 내용이 맞는지 별도 검증이 필요할 수 있습니다. 중요한 변경은 호출 ID, 입력값, 결과, 승인자를 로그로 남기고 되돌릴 방법도 준비하세요.
8. 핵심 정리
모델 = 도구와 입력값 선택 애플리케이션 = 검증과 실행 도구 결과 = 다음 판단의 근거 승인·로그 = 안전장치
Tool Calling은 AI가 외부 도구를 마음대로 조작하게 만드는 기능이 아닙니다. 모델이 구조화된 실행 요청을 만들고, 애플리케이션이 권한과 입력을 검증해 실행한 뒤, 그 결과를 다시 모델에게 전달하는 협업 구조입니다.
이 원리를 이해하면 AI 에이전트가 여러 단계를 어떻게 이어가는지도 보이기 시작합니다. 다음 글에서는 에이전트가 목표를 작은 단계로 나누고, 실행 결과를 관찰하며 계획을 수정하는 과정을 살펴보겠습니다.
🔗 AI 에이전트 입문 시리즈
참고: OpenAI Responses API 도구 문서, OpenAI Chat API Tool Choice 문서