ChatGPT에게 “오늘 날씨 어때?”라고 물으면 실시간 정보를 알려주죠. “이 데이터 분석해줘”라고 하면 Python 코드를 돌려서 그래프까지 그려줍니다. 하지만 대부분의 사용자는 이 순간 뒤에서 무슨 일이 벌어지는지 모릅니다. ChatGPT는 단순히 학습된 지식으로 답하는 게 아니라 실제로 외부 도구를 ‘호출’하고 있거든요. 이게 바로 Tool Calling입니다.

Tool Calling은 대형 언어모델(LLM)이 외부 함수나 API를 실행할 수 있게 해주는 메커니즘입니다. 학습 데이터에만 의존하는 챗봇과 실제로 일을 처리하는 에이전트의 차이가 바로 여기에 있죠. ChatGPT는 미리 설치된 도구들을 사용하지만, 여러분이 직접 에이전트를 만든다면 어떤 도구를 연결할지 선택할 수 있습니다. 회사 데이터베이스를 조회하게 할 수도 있고, Slack 메시지를 보내게 할 수도 있습니다.

Machine Learning Mastery의 Vinod Chugani가 LLM을 실제 작동하는 에이전트로 만드는 3단계 프레임워크를 소개했습니다. 핵심은 모든 도구를 데이터 접근(Data Access), 계산(Computation), 행동(Actions)이라는 세 가지 기둥으로 분류하고, 이들의 균형을 맞추는 것입니다.

출처: Mastering LLM Tool Calling: The Complete Framework for Connecting Models to the Real World – MachineLearningMastery

3가지 기둥으로 에이전트 설계하기

Tool Calling을 구현할 때 가장 먼저 필요한 건 도구를 정리하는 사고 체계입니다. 원문에서 제시하는 3-Pillar Framework는 모든 도구를 역할에 따라 세 가지로 나눕니다.

첫 번째 기둥: 데이터 접근 (읽기 전용)

정보를 가져오는 도구들입니다. 읽기 전용이라 반복 호출해도 부작용이 없어서 안전하죠. 벡터 데이터베이스는 의미 검색에 사용됩니다. “Q3 전략 문서 찾아줘” 같은 개념적 질문에 적합합니다. SQL과 NoSQL 데이터베이스는 정확한 데이터 조회에 쓰입니다. 고객 정보나 거래 기록처럼 정형화된 데이터를 다룰 때 효과적이죠.

그래프 데이터베이스는 관계가 중요할 때 빛을 발합니다. 소셜 네트워크나 조직도처럼 연결 구조를 탐색해야 하는 경우에 사용합니다. 외부 API는 실시간 변동 데이터를 가져옵니다. 날씨, 주가, 뉴스처럼 자주 바뀌는 정보들이죠.

여기서 흥미로운 통찰이 하나 있습니다. RAG(Retrieval-Augmented Generation)도 사실 Tool Calling입니다. RAG는 벡터 데이터베이스 검색 도구를 호출하는 것일 뿐이에요. 이렇게 보면 RAG가 더 큰 에이전트 시스템 안에서 어떤 위치에 있는지 명확해집니다. 여러 도구 중 하나일 뿐이죠.

두 번째 기둥: 계산 (처리와 변환)

데이터는 가져온 그대로 쓰기 어려운 경우가 많습니다. 계산 도구는 정보를 분석하고 변환해서 의사결정에 쓸 수 있는 형태로 만듭니다.

코드 실행 도구(Python, JavaScript)는 복잡한 로직이나 맞춤 계산을 처리합니다. Wolfram Alpha 같은 수학 연산 도구는 고급 계산이나 통계 분석을 담당하죠. 데이터 변환 도구는 형식을 바꿉니다. CSV를 JSON으로, XML을 파싱하는 식입니다.

머신러닝 모델 추론 도구는 특화된 AI 기능을 제공합니다. 이미지 인식이나 감정 분석 같은 작업이죠. 미디어 처리 도구는 이미지 크기 조정, 동영상 프레임 추출, 오디오 변환 등을 맡습니다.

왜 계산이 중요할까요? 판단하기 전에 가공이 필요하기 때문입니다. 매출 데이터를 가져왔다면 성장률을 계산해야 다음 행동을 정할 수 있습니다. 고객 피드백을 수집했다면 감정 분석을 해야 적절한 답변을 만들 수 있죠.

세 번째 기둥: 행동 (쓰기와 실행)

행동 도구는 상태를 바꿉니다. 외부와 소통하거나 데이터를 수정하거나 워크플로우를 시작합니다. 여기서부터는 실제 영향이 발생하기 때문에 위험도가 올라갑니다.

커뮤니케이션 도구는 이메일, Slack, SMS를 보냅니다. 고객 서비스 에이전트나 알림 시스템에서 자주 쓰이죠. 워크플로우 자동화 도구는 Jira 티켓을 만들거나 CI/CD 파이프라인을 실행합니다. 데이터 조작 도구는 데이터베이스를 업데이트하거나 레코드를 삭제합니다.

외부 서비스 통합 도구는 결제 처리나 CRM 작업처럼 비즈니스에 직접적 영향을 주는 기능을 담당합니다.

여기서 핵심은 행동에는 결과가 따른다는 점입니다. 보낸 이메일은 취소할 수 없습니다. 처리한 결제는 되돌리기 어렵습니다. 삭제한 데이터는 영구히 사라질 수 있습니다. 그래서 행동 도구는 데이터 접근이나 계산과는 다른 수준의 안전장치가 필요합니다.

실전 사례: 배송 지연 처리하는 고객 서비스 에이전트

세 가지 기둥이 실제로 어떻게 작동하는지 구체적인 시나리오로 살펴보겠습니다. 고객이 “주문한 물건이 늦어지고 있어요, 도와주세요”라고 문의했다고 해봅시다.

데이터 접근 단계: 에이전트는 먼저 벡터 검색으로 지식 베이스에서 환불 정책을 찾습니다. 그런 다음 SQL로 주문 데이터베이스에서 배송 정보를 조회하죠. 택배사 API를 호출해서 현재 추적 상태도 확인합니다. 이 모든 게 맥락을 수집하는 과정입니다.

계산 단계: 이제 에이전트는 배송이 며칠 지연됐는지 계산합니다. 앞서 찾은 정책을 기준으로 환불 자격 여부를 판단하죠. 주문 금액과 규칙을 적용해서 환불액을 결정합니다. 원시 데이터를 실행 가능한 인사이트로 변환하는 겁니다.

행동 단계: 에이전트는 결제 시스템을 통해 환불을 처리합니다. 고객에게 확인 이메일을 보내죠. CRM에 처리 내역을 기록하고, 물류팀이 지연 원인을 조사하도록 내부 티켓을 생성합니다.

주목할 점은 이 흐름이 완전히 일직선이 아니라는 겁니다. 환불을 처리한 후 에이전트는 데이터 접근으로 돌아가서 환불이 제대로 완료됐는지 확인합니다. 그리고 나서 다시 행동 단계로 가서 확인 메시지를 보내죠. 이런 반복 패턴은 프로덕션 시스템에서 흔합니다.

세 기둥은 서로 의존합니다. 데이터 접근만 있으면 정보는 줄 수 있지만 행동할 수 없습니다. 행동만 있으면 맥락 없이 맹목적으로 작동하죠. 하지만 셋을 결합하면? 정보를 모으고, 판단하고, 작업을 실행하는 완전한 시스템이 됩니다.

에이전트를 설계할 때 이렇게 물어보세요. 세 기둥의 균형이 맞나? 데이터 접근은 강하지만 행동이 약하면 질문에는 답할 수 있어도 문제를 해결할 수는 없습니다. 행동은 강하지만 계산이 약하면 가공되지 않은 데이터로 잘못된 행동을 할 수 있죠.

프로덕션 운영 시 챙겨야 할 것들

데모용 에이전트를 만드는 것과 실제로 운영하는 것은 차원이 다릅니다. 원문에서 강조하는 실전 고려사항들을 정리했습니다.

보안과 인증: 모든 도구에 적절한 인증이 필요합니다. API 키, OAuth, 서비스 계정 등 상황에 맞게 선택하세요. 최소 권한 원칙을 따라야 합니다. 에이전트에게 꼭 필요한 최소한의 권한만 주세요. 뭔가 잘못됐을 때 피해를 제한할 수 있습니다.

Human-in-the-Loop: 모든 행동이 완전 자동화돼야 하는 건 아닙니다. 특정 금액 이상의 금융 거래는 승인을 받게 하세요. 데이터 삭제는 확인을 요구하고, 고객 대면 커뮤니케이션은 검토 과정을 거치게 합니다. 목표는 자동화를 없애는 게 아니라 자동화 혜택과 리스크 관리 사이의 균형을 맞추는 겁니다.

에러 처리: 도구는 실패합니다. API가 다운되고, 속도 제한에 걸리고, 타임아웃이 발생하죠. 지수 백오프와 재시도 로직을 구현하세요. 가능하면 대체 도구를 준비하세요. 주요 날씨 API가 다운되면 보조 API를 쓸 수 있나요? 도구가 실패했을 때 제공할 수 있는 최선의 부분 결과가 뭔가요?

도구 선택 전략: 처음엔 3~5개의 필수 도구로 시작하세요. 너무 많으면 에이전트가 올바른 선택을 하기 어렵습니다. 관찰된 필요에 따라 점진적으로 추가하세요. 에이전트가 특정 작업에서 어려움을 겪는다면 그때 도구를 추가하는 겁니다. 세 기둥의 균형을 맞추세요. 데이터 접근 도구만 잔뜩 쌓아두고 계산과 행동을 소홀히 하지 마세요.

LLM을 언어 생성기에서 실제 작동하는 에이전트로 바꾸는 열쇠는 Tool Calling입니다. 3-Pillar Framework는 균형 잡힌 프로덕션 시스템을 만드는 사고의 틀을 제공합니다. 간단하게 시작하고, 면밀히 모니터링하고, 실제 필요에 따라 기능을 확장하세요. 완벽한 설계는 처음부터 나오는 게 아니라 테스트와 개선을 거쳐 나옵니다.

참고자료:

• Function Calling with LLMs – Prompt Engineering Guide
• Achieving Tool Calling Functionality in LLMs Using Only Prompt Engineering Without Fine-Tuning – arXiv