AI 에이전트 Tool calling은 에이전트가 단순히 답변하는 단계를 넘어 외부 시스템을 읽고, 계산하고, 변경하게 만드는 지점입니다. 그래서 tool calling을 붙일 때 가장 먼저 해야 할 질문은 “무엇을 할 수 있나”가 아니라 “어디까지 맡겨도 안전한가”입니다.
1편에서는 AI 에이전트를 목표, 도구, 맥락, 상태, 검증, 승인 흐름을 가진 실행 시스템으로 보았습니다. 2편에서는 그중에서도 가장 사고가 자주 나는 부분인 도구 호출 경계를 다룹니다. 먼저 AI 에이전트 실전 설계 시리즈 1편을 읽었다면 이번 글의 위치가 더 분명해집니다.
AI 에이전트 Tool calling은 기능이 아니라 실행 권한이다
도구 호출을 단순 기능 목록으로 보면 위험합니다. 날씨 조회, 문서 검색, 이메일 발송, 결제 취소, 배포 실행을 모두 “tool”이라고 부를 수 있지만 실패 비용은 완전히 다릅니다.
OpenAI Agents SDK의 Tools 문서는 tools를 데이터 가져오기, 코드 실행, 외부 API 호출 같은 action을 수행하게 하는 수단으로 설명합니다. MCP tools 명세도 tools가 데이터베이스 조회, API 호출, 계산처럼 외부 시스템과 상호작용하게 만든다고 설명합니다.
즉, tool calling은 “모델이 더 많은 기능을 쓴다”는 뜻이 아니라 “모델 판단이 외부 세계에 영향을 줄 수 있다”는 뜻입니다.
- 이 도구는 읽기만 하는가, 외부 상태를 바꾸는가
- 잘못 호출했을 때 비용이 생기는가
- 개인정보나 비밀 정보를 노출할 수 있는가
- 호출 결과를 사람이 되돌릴 수 있는가
- 왜 호출했는지 나중에 추적할 수 있는가
도구를 위험도별로 나누기
모든 도구에 같은 승인 규칙을 붙이면 운영이 망가집니다. 너무 엄격하면 자동화의 의미가 사라지고, 너무 느슨하면 작은 판단 실수가 실제 장애로 이어집니다.
- 읽기 도구: 문서 검색, 상품 정보 조회, 이슈 목록 조회처럼 외부 상태를 바꾸지 않는 도구입니다. 기본적으로 자동 호출이 가능하지만 개인정보나 권한 문서가 섞이면 접근 범위를 제한해야 합니다.
- 계산과 변환 도구: CSV 요약, 코드 포맷팅, 텍스트 변환처럼 입력을 처리해 결과를 돌려주는 도구입니다. 자동화할 수 있지만 실행 환경, 입력 크기, timeout을 제한해야 합니다.
- 내부 상태를 바꾸는 도구: 태스크 생성, 티켓 상태 변경, CRM 메모 추가처럼 기록이 남는 도구입니다. 조건부 승인과 audit log가 필요합니다.
- 외부로 메시지를 보내는 도구: 이메일 발송, Slack 공지, 고객 답변 전송처럼 한번 나가면 되돌리기 어려운 도구입니다. 초안 생성은 자동화해도 실제 발송은 승인 대상으로 두는 편이 안전합니다.
- 비용이 발생하는 도구: 유료 API 대량 호출, 광고 집행, 클라우드 리소스 생성처럼 돈이 연결되는 도구입니다. 예산 한도, 호출 횟수, 중단 조건이 필요합니다.
- 권한과 보안에 영향을 주는 도구: 권한 변경, 토큰 발급, 배포, 삭제처럼 실패 비용이 큰 도구입니다. 기본값은 사람 승인 필수입니다.
승인 기준은 되돌릴 수 있는가로 시작한다
사람 승인이 필요한지 판단할 때 가장 쉬운 기준은 되돌릴 수 있는지입니다. 문서 검색은 대부분 되돌릴 필요가 없습니다. 하지만 고객에게 이메일을 보내거나 결제를 취소하거나 운영 DB를 수정하는 일은 다릅니다.
OpenAI Agents SDK의 human-in-the-loop 문서는 민감한 tool call에서 실행을 멈추고, 사람이 승인하거나 거절한 뒤 run state를 이어가는 흐름을 설명합니다. MCP tools 명세도 trust and safety를 위해 사람이 tool invocation을 거부할 수 있는 능력을 두고, 민감한 작업에는 확인 프롬프트를 보여줄 것을 권고합니다.
- 읽기 전용이고 민감 정보가 없다: 자동 실행 가능
- 되돌릴 수 있고 영향 범위가 작다: 조건부 자동 실행 가능
- 외부에 메시지가 나간다: 초안은 자동, 발송은 승인
- 돈, 권한, 삭제, 배포와 연결된다: 실행 전 승인 필수
- 법적/보안 책임이 크다: 에이전트가 직접 실행하지 않게 설계
도구 설명과 결과도 신뢰 경계 안에 둬야 한다
심화해서 보면 위험은 도구 실행 순간에만 생기지 않습니다. 모델은 도구 이름, 설명, 입력 스키마, 실행 결과를 보고 다음 행동을 결정합니다. 따라서 도구 설명이 모호하거나 결과가 검증되지 않으면, 모델은 “그럴듯하지만 위험한 다음 행동”을 선택할 수 있습니다.
MCP tools 명세는 tool annotation을 신뢰된 서버에서 온 것이 아니라면 그대로 믿지 말라고 경고합니다. 또한 서버는 tool input을 검증하고 access control, rate limit, output sanitization을 구현해야 하며, 클라이언트는 민감 작업 확인, tool input 표시, 결과 검증, timeout, audit log를 고려해야 합니다.
쉽게 말하면 도구는 “함수 하나”가 아니라 작은 API 경계입니다. 좋은 tool calling 설계는 함수 이름을 많이 붙이는 일이 아니라, 각 도구가 무엇을 읽고 무엇을 바꿀 수 있는지 좁게 정의하는 일입니다.
Guardrail은 승인 흐름을 대신하지 않는다
Guardrail은 중요합니다. 하지만 guardrail이 있다고 해서 사람 승인이 사라지는 것은 아닙니다. OpenAI Agents SDK의 Guardrails 문서는 input guardrails, output guardrails, tool guardrails를 구분합니다. 특히 tool guardrails는 function tool 호출 전후에 입력과 출력을 검증하거나 차단할 수 있습니다.
다만 guardrail은 주로 “정해진 조건에 걸리는가”를 확인하는 장치입니다. 반면 승인은 “이 상황에서 실제로 실행해도 되는가”를 사람이 판단하는 장치입니다.
- guardrail은 금지어, 개인정보, 잘못된 금액 형식을 잡을 수 있습니다.
- 승인자는 이 고객에게 지금 이 안내를 보내도 되는지 판단합니다.
- 로그는 누가, 어떤 입력으로, 어떤 결과를 승인했는지 남깁니다.
세 가지는 서로 대체 관계가 아닙니다. guardrail, 승인, 로그가 함께 있어야 민감한 tool calling을 운영할 수 있습니다.
Tool calling 로그에는 판단 근거가 남아야 한다
도구 호출은 성공했는지보다 왜 호출했는지가 더 중요할 때가 많습니다. OpenAI Agents SDK의 Tracing 문서는 LLM generation, tool call, handoff, guardrail, custom event 등을 추적 대상으로 설명합니다.
이 말은 운영 관점에서 매우 중요합니다. 에이전트가 틀렸을 때 최종 답변만 보면 원인을 찾기 어렵기 때문입니다.
- 어떤 사용자 요청에서 시작됐는가
- 어떤 도구 후보가 있었고 실제로 어떤 도구를 선택했는가
- 도구에 전달한 입력은 무엇인가
- 호출 전 승인 여부는 어땠는가
- 도구 결과는 성공인가 실패인가
- 최종 답변이나 후속 작업에 어떻게 반영됐는가
민감 데이터가 포함될 수 있으므로 로그에 모든 입력과 출력을 그대로 저장하는 것도 위험합니다. tracing 설정에서 민감 데이터 포함 여부를 조정하거나, 운영 로그에는 필요한 필드만 남기는 설계가 필요합니다.
작은 예시: 고객 지원 에이전트
고객 지원 에이전트를 예로 들어 보겠습니다. 이 에이전트가 쓸 수 있는 도구가 네 개 있다고 가정합니다.
search_policy: 환불 정책 문서를 검색한다get_order: 주문 정보를 조회한다draft_email: 고객 답변 초안을 만든다send_email: 고객에게 답변을 발송한다
여기서 네 도구를 모두 자동 실행하면 안 됩니다. search_policy는 읽기 도구라 자동 호출해도 됩니다. get_order는 개인정보가 포함될 수 있으므로 요청한 사용자와 주문 소유자가 맞는지 확인해야 합니다. draft_email은 초안 생성이므로 자동화할 수 있습니다. 하지만 send_email은 외부 발송이므로 승인 대상입니다.
- 정책 문서를 검색한다.
- 주문 정보를 필요한 범위만 조회한다.
- 답변 초안을 만든다.
- 발송 전 사람에게 초안, 수신자, 근거 문서를 보여준다.
- 승인되면 발송하고, 거절되면 이유를 로그에 남긴다.
이 구조에서는 에이전트가 일을 많이 하되, 책임이 큰 마지막 실행은 사람이 잡고 있습니다.
추가 예시: 배포 도구는 어디까지 맡길까
배포 도구를 에이전트에 붙인다고 해서 “배포 버튼”까지 바로 맡길 필요는 없습니다. 안전한 첫 단계는 변경 파일을 요약하고, 테스트 결과를 확인하고, 위험한 변경을 표시하는 것입니다. 여기까지는 읽기와 판단 보조에 가깝습니다.
반대로 실제 배포 실행, 롤백, 환경 변수 변경은 외부 상태를 크게 바꾸는 작업입니다. 이런 도구는 승인 전 입력을 보여주고, 승인자를 기록하고, 실패 시 어떤 롤백 경로가 있는지까지 함께 설계해야 합니다. 에이전트는 결정을 돕고, 마지막 책임 버튼은 사람이 누르게 하는 방식이 더 안전합니다.
AI 에이전트 Tool calling 설계 체크리스트
- 이 도구는 읽기 도구인가, 쓰기 도구인가
- 호출 실패보다 잘못된 성공이 더 위험한가
- 도구 입력을 사용자가 확인할 수 있는가
- 도구 결과를 모델에 넘기기 전에 검증하는가
- 같은 도구를 너무 많이 호출하지 않도록 rate limit이 있는가
- 민감 정보가 로그에 그대로 남지 않는가
- 사람 승인 없이 실행해도 되는 범위가 문서화되어 있는가
- 승인, 거절, 재시도 결과가 audit log로 남는가
이 질문에 답하지 못한다면 아직 에이전트에게 맡길 준비가 덜 된 것입니다. 더 넓은 MCP 보안 관점은 이전에 정리한 MCP 보안은 왜 중요할까 글과 함께 보면 좋습니다.
정리
AI 에이전트 Tool calling은 에이전트를 실전 업무에 연결하는 강력한 장치입니다. 하지만 도구가 많아질수록 에이전트가 좋아지는 것이 아니라, 책임 경계가 더 복잡해집니다.
핵심은 간단합니다. 읽기 도구는 자동화할 수 있고, 쓰기 도구는 조건을 봐야 하며, 돈, 권한, 삭제, 외부 발송과 연결된 도구는 사람 승인을 거쳐야 합니다. 중요한 tool call은 반드시 나중에 추적할 수 있어야 합니다.
다음 편에서는 MCP가 에이전트 구조 안에서 어떤 역할을 하는지 다룹니다. tools, resources, prompts를 단순 기능 목록이 아니라 에이전트의 연결 계층으로 보는 방법을 정리하겠습니다.
