AI 에이전트 도구 호출 원리: 선택부터 검증까지

AI 에이전트의 도구 호출(Tool Calling)은 LLM이 직접 API를 실행하는 기능이 아니라, 필요한 도구 이름과 입력값을 구조화해 제안하면 애플리케이션이 이를 검증·실행하고 결과를 다시 모델에 전달하는 제어 구조입니다. 따라서 핵심은 모델의 답변 능력만이 아니라 도구 정의, 실행 권한, 오류 처리, 완료 검증을 함께 설계하는 데 있습니다.

예를 들어 “다음 주 김 연구원과 30분 회의를 잡아줘”라는 요청을 처리하려면 이름 검색, 공통 빈 시간 조회, 일정 등록, 초대 발송 여부 확인이 차례로 필요합니다. 이 과정에서 AI 에이전트는 상황에 따라 다음 행동을 고르지만, 실제 캘린더 변경은 허용된 시스템만 수행해야 합니다.

도구 호출은 AI의 ‘행동 요청’입니다

LLM은 실행자가 아니라 판단과 형식화 담당입니다

대규모 언어 모델(LLM)은 사용자의 문장을 해석해 답변할지, 추가 질문을 할지, 도구를 요청할지 판단합니다. 도구가 필요하면 calendar_find_slots처럼 사전에 등록된 이름과 참석자·기간 같은 인자를 JSON 형태의 구조화된 출력으로 만듭니다. 모델이 그 요청을 냈다고 해서 일정이 즉시 생성되는 것은 아닙니다.

에이전트 프로그램이 실행·검증·재시도를 담당합니다

오케스트레이터(orchestrator)는 모델 출력에서 도구 이름과 인자를 읽어 허용 목록, 입력 형식, 사용자 권한을 검사합니다. 통과한 요청만 API나 데이터베이스에 전달하고, 실행 결과를 다시 모델에 제공합니다. 모델은 결과를 바탕으로 다음 도구를 선택하거나 사용자에게 최종 결과를 설명합니다. 이 반복 구조가 단순 챗봇과 실행형 에이전트를 가르는 핵심입니다.

일정 예약으로 보는 도구 호출 6단계

일정 예약은 여러 도구 결과에 따라 경로가 바뀌므로 도구 호출 원리를 이해하기 좋은 사례입니다. 동명이인이 있거나 가능한 시간이 여러 개라면 에이전트는 추측해 등록하기보다 멈추고 확인해야 합니다.

1. 앱이 사용자 요청, 현재 대화 맥락, 사용 가능한 도구 설명을 모델에 전달합니다.
2. 모델이 연락처 검색 도구와 이름 인자를 제안합니다.
3. 실행기가 검색 결과를 받아 동명이인 여부와 접근 권한을 확인합니다.
4. 모델이 확정된 참석자를 바탕으로 공통 빈 시간 조회를 요청합니다.
5. 후보가 여러 개면 사용자 선택 또는 정해진 정책에 따른 승인 단계를 거칩니다.
6. 일정 등록 뒤 캘린더를 다시 조회해 시간·참석자·회의실이 맞는지 검증합니다.

도구 호출의 성공 기준은 “JSON을 만들었다”가 아니라, 허용된 변경이 정확히 반영됐고 완료 조건을 다시 확인했는지입니다.

도구 정의와 JSON 스키마가 중요한 이유

설명이 모호하면 잘못된 도구를 고를 수 있습니다

도구 정의에는 이름뿐 아니라 용도, 사용하면 안 되는 상황, 필수 입력값, 값의 형식을 담아야 합니다. 예를 들어 일정 등록 도구는 참석자 식별자와 시작·종료 시각을 필수값으로 두고, 자연어 이름만으로는 실행하지 않도록 설계할 수 있습니다. 설명이 겹치는 도구가 많으면 모델의 선택 정확도와 운영 추적성이 함께 떨어집니다.

스키마 검증은 모델 출력 신뢰와 별개입니다

JSON 스키마는 입력값의 타입·필수 여부·허용 범위를 기계적으로 검사하는 규칙입니다. 모델이 형식에 맞는 값을 냈더라도 존재하지 않는 주문 번호, 허용되지 않은 날짜, 다른 사용자의 고객 정보일 수 있습니다. 따라서 스키마 검증 뒤에도 업무 규칙과 권한 검사를 별도로 거쳐야 합니다.

계층	주요 책임	대표 점검
LLM	의도 해석·도구 선택	질문이 필요한지 판단
실행기	호출 검증·API 실행	스키마와 권한 확인
업무 시스템	실제 조회·변경 처리	감사 로그와 실패 응답
검증 단계	결과 재확인·중단 결정	완료 조건 충족 여부

도구 호출, RAG, MCP는 무엇이 다를까

RAG는 ‘찾아 읽기’, 도구 호출은 ‘실행 요청’에 가깝습니다

RAG(검색 증강 생성)는 관련 문서 조각을 찾아 모델의 문맥에 넣어 답변 근거를 보강하는 방식입니다. 반면 도구 호출은 검색, 계산, 파일 생성, 주문 상태 변경처럼 외부 기능을 사용하도록 요청하는 방식입니다. 검색 도구를 호출해 문서를 가져온 뒤 RAG 방식으로 답변하는 것처럼 두 기술은 함께 쓸 수 있습니다.

MCP는 도구를 연결하는 공통 규약입니다

MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구·리소스와 연결될 때 사용할 수 있는 표준화된 방식입니다. MCP를 쓴다고 권한 문제가 자동으로 해결되지는 않습니다. 어떤 도구를 노출할지, 어떤 사용자에게 어떤 작업을 허용할지, 민감한 결과를 어디까지 모델에 전달할지는 서비스 운영자가 정해야 합니다. 도구 호출의 기본 구조는 OpenAI Function Calling 가이드에서도 확인할 수 있습니다.

안전한 에이전트는 권한과 승인선을 분리합니다

조회와 변경 도구를 같은 위험도로 다루지 마세요

배송 상태 조회와 환불 처리, 문서 읽기와 삭제는 결과의 되돌릴 수 있는 정도가 다릅니다. 읽기 전용 도구는 필요한 범위에서 자동 실행할 수 있지만, 외부 이메일 발송·결제·권한 변경·파일 삭제처럼 영향이 큰 작업은 명시적 승인 단계를 두는 편이 안전합니다.

비밀키와 민감 정보는 모델 문맥 밖에서 관리합니다

API 키, 데이터베이스 비밀번호, 개인식별정보는 프롬프트나 도구 설명에 넣지 않습니다. 실행기가 안전한 저장소에서 자격 증명을 사용하고, 모델에는 성공·실패 판단에 필요한 최소 결과만 전달합니다. 도구 결과에 포함된 외부 텍스트가 “이전 지시를 무시하라”는 식의 명령을 담을 수 있으므로, 검색 결과나 첨부 문서는 명령이 아니라 데이터로 취급해야 합니다.

• 도구별로 읽기·쓰기·삭제 권한을 분리합니다.
• 최대 호출 횟수, 실행 시간, 비용 한도를 설정합니다.
• 고위험 작업은 실행 전 사용자에게 변경 내용을 보여 줍니다.
• 도구 요청·실행 결과·승인 여부를 감사 로그로 남깁니다.

환불, 삭제, 대외 발송처럼 되돌리기 어려운 작업은 모델의 판단만으로 실행하지 말고, 대상·금액·범위를 보여 주는 사람 승인 단계를 두는 것이 기본입니다.

도입 전 확인할 실전 체크리스트

처음부터 모든 업무를 자율 실행하게 만들기보다, 반복적이고 결과를 확인하기 쉬운 조회 업무부터 시작하는 편이 운영 위험을 낮춥니다. 특히 완료 조건을 문장으로 명확히 정의하지 않으면 에이전트가 불필요하게 도구를 반복 호출하거나, 중간 결과를 완료로 오인할 수 있습니다.

• 사용자의 최종 목표와 중단 조건이 문서화돼 있는지 확인합니다.
• 각 도구의 입력값, 실패 응답, 권한 범위를 정의합니다.
• 동명이인·누락 정보·복수 후보가 있을 때 질문하도록 정합니다.
• 실행 후 원본 시스템을 재조회해 결과를 검증합니다.
• 실패 시 재시도 횟수와 사람 이관 기준을 정합니다.

사내 업무에 적용한다면 모델 선택보다 먼저 데이터 접근 범위와 책임 주체를 합의해야 합니다. 구축 방식과 운영 역량을 함께 검토해야 하는 경우 AI 시스템 사내 구축 vs 외주의 판단 기준도 실제 도구 연결 범위를 정하는 데 활용할 수 있습니다.

자주 묻는 질문

Q. AI 에이전트가 도구를 직접 실행하나요?

일반적인 구조에서는 모델이 도구 이름과 인자를 제안하고, 애플리케이션의 실행 계층이 검증 후 실제 API나 함수를 실행합니다. 실행 권한과 비밀키를 모델에 직접 맡기지 않는 이유입니다.

Q. 도구 호출과 함수 호출은 같은 말인가요?

함수 호출은 미리 정의한 함수를 모델이 선택하도록 하는 대표적 방식이며, 도구 호출은 함수 외에도 검색, 코드 실행, 파일 접근 등 더 넓은 외부 기능 연결을 포괄하는 표현으로 쓰입니다.

Q. 도구를 많이 연결하면 에이전트가 더 똑똑해지나요?

반드시 그렇지는 않습니다. 용도가 겹치거나 설명이 불명확한 도구가 많으면 잘못 선택할 가능성이 커집니다. 목표 업무에 필요한 최소 도구부터 제공하고, 실행 기록을 바탕으로 확장하는 편이 좋습니다.

Q. RAG만으로 주문 취소나 일정 등록을 할 수 있나요?

RAG는 문서와 지식을 찾아 답변에 활용하는 방식이므로, 실제 주문 취소나 일정 등록에는 해당 업무 시스템을 호출할 도구와 권한 검증 절차가 추가로 필요합니다.