LLM을 외부 시스템에 연결하는 방식은 자율 에이전트(autonomous agents)와 기업 인프라 간의 통신을 표준화하는 확립된 오픈 프로토콜 세트로 수렴되었습니다. 하지만 조직이 채팅 인터페이스를 넘어 다중 사용자 프로덕션 에이전트(multi-user production agents)를 배포함에 따라 새로운 병목 현상이 나타났습니다.

프로토콜 연결성은 MCP가 사실상의 연결 표준(de facto connectivity standard)으로 자리 잡고 Claude Code, Cursor, Windsurf와 같은 클라이언트에서 네이티브 지원을 제공함에 따라 상당 부분 해결되었습니다. 현재 에이전트 확장을 제한하는 것은 컨텍스트 효율성(context efficiency), 다중 사용자 권한 부여(multi-user authorization), 감사(audits) 부족, 실행 신뢰성(execution reliability)을 포함한 도구의 품질입니다.

AI 아키텍처를 구축할 때는 프로토콜 계층(원시 함수 호출(raw function calling), Model Context Protocol (MCP), 그리고 에이전트 간 협업(agent-to-agent coordination)의 상호 보완적 역할)을 반드시 평가해야 합니다. 이와 함께 도구 소싱(tool sourcing)이 뒤따르며, 이는 여러분의 역량이 어디에서 오는지, 그리고 그것이 결정론적 소프트웨어(deterministic software) 또는 자율적 추론(autonomous reasoning)에 최적화되어 있는지를 결정합니다.

요약 (TL;DR)

• **함수 호출 (Function calling)**은 도구를 위해 구조화된 JSON을 생성하는 LLM의 네이티브 능력입니다.
• MCP는 도구가 프롬프트나 앱에 하드코딩되지 않도록 도구 발견 및 실행 전송(JSON-RPC)을 표준화합니다.
• A2A는 에이전트 간 위임(agent-to-agent delegation) 및 컨텍스트 전달을 조정합니다. 이는 MCP의 도구 호출 역할을 대체하는 것이 아니라 보완합니다.
• 2026년에는 프로토콜 연결성이 대체로 해결되었습니다. 확장의 병목 현상은 컨텍스트 효율성(토큰 팽창 방지), 다중 사용자 권한 부여(프롬프트 이후 단계), 감사 부족, 실행 신뢰성(의도 수준 설계)을 포함한 도구의 품질입니다.
• 프로덕션용 다중 사용자 에이전트의 경우, 컨텍스트 비용을 줄이기 위해 **동적 도구 로딩 (dynamic tool loading)**을 사용하고, 안전하고 책임 있는 실행을 위해 **위임된 OAuth 및 감사 로그 (delegated OAuth and audit logs)**를 구현하십시오.

AI 에이전트 도구 호출(tool calling)이란 무엇인가?

AI 에이전트 도구 호출(tool calling)은 대규모 언어 모델(Large Language Models, LLMs)이 실제 세계의 동작을 수행하기 위해 외부 시스템, API 또는 데이터베이스와 상호작용하는 메커니즘입니다. 이는 AI 에이전트가 사전 정의된 프로그래밍 함수(programmatic functions)를 트리거하는 구조화된 페이로드(structured payloads)를 생성함으로써, 레코드 업데이트나 실시간 데이터 검색과 같은 작업을 실행할 수 있도록 돕습니다.

단순한 API 요청과 달리, AI 모델은 자연어 의도(natural language intent)를 바탕으로 어떤 도구를 사용할지, 언제 호출할지, 그리고 어떤 인자(arguments)를 전달할지를 자율적으로 결정합니다.

엔지니어링 팀의 업데이트 업무를 맡은 에이전트를 생각해 보십시오. 사용자가 "PR 요약 초안을 작성해줘"라고 프롬프트를 입력합니다. 에이전트는 GitHub 도구를 호출하여 최신 커밋(commits)을 가져오고, 데이터를 보고서로 합성한 다음, Slack 도구를 호출하여 지정된 채널에 업데이트 내용을 게시합니다.

표준 실행 루프(execution loop)는 다음과 같은 엄격한 순서를 따릅니다:

1. 프롬프트 조립 (Prompt assembly): 시스템이 모델에 사용자의 의도와 사용 가능한 도구 스키마(tool schemas)를 제공합니다.
2. 모델 추론 (Model reasoning): 모델이 요청을 분석하고 외부 동작이 필요하다고 판단합니다.
3. 함수 방출 (Function emission): 모델이 텍스트 생성을 중단하고 특정 도구를 대상으로 하는 구조화된 JSON 페이로드를 방출합니다.
4. 실행 (Execution): 런타임(runtime)이 페이로드를 가로채 외부 프로그래밍 함수를 실행하고 결과를 캡처합니다.
5. 컨텍스트 반환 (Context return): 런타임이 실행 결과를 다시 프롬프트 창에 추가하여, 모델이 해당 동작을 요약하거나 다음 단계로 넘어갈 수 있도록 합니다.

2026년 프로덕션 에이전트에게 신뢰할 수 있는 도구 호출이 중요한 이유

분석 및 단일 사용자 챗봇에 국한된 에이전트는 점진적인 가치만을 제공합니다. 실제 동작을 수행하는 자율적인 멀티 유저 프로덕션 에이전트로 나아가기 위해서는 도구 관리(tool management)에 대한 다른 접근 방식이 필요합니다. 스크립트에 몇 개의 API 래퍼(wrappers)를 하드코딩하는 방식은 프로토타입에는 적합하지만, 스키마 설계, 사용자 권한 부여(user authorization), 자격 증명 격리(credential isolation), 재시도(retries) 및 감사 가능성(auditability)이 모두 애플리케이션 코드의 영역으로 들어오는 엔터프라이즈 제약 조건 하에서는 한계에 부딪힙니다.

1. 컨텍스트 효율성 (Context efficiency): 컨텍스트 윈도우(context-window) 사용 최소화

가공되지 않은 복잡한 도구 스키마(tool schemas)를 시스템 프롬프트(system prompt)에 주입하는 것은 컨텍스트 윈도우를 팽창시키고 모델의 추론 능력을 저하시킵니다. 개발자들은 이러한 성능 저하를 컨텍스트 세금(context tax)이라고 부릅니다. 최근 데이터에 따르면, 40개의 도구를 가진 GitHub MCP 서버는 대화 턴당 10-15 KB의 스키마 팽창을 추가합니다. 대량의 도구 스키마를 주입하는 것은 도구 선택(tool-selection) 정확도도 떨어뜨리므로, 카탈로그가 커질수록 에이전트가 잘못된 도구를 선택할 확률이 높아집니다. 런타임(runtime) 솔루션은 실행 시점에 필요한 스키마만 주입하는 동적 도구 로딩(dynamic tool loading)입니다.

2. 다중 사용자 권한 부여 및 보안 (Multi-user authorization and security)

핵심적인 다중 사용자 간극(multi-user gap)은 에이전트가 확장됨에 따라 모든 에이전트에 걸쳐 일관된 정책 집행이 이루어지지 않는다는 점입니다. 다중 사용자 환경에서 작동하는 에이전트는 프롬프트 이후의 위임된 권한 부여(post-prompt delegated authorization)가 필요합니다. 가공되지 않은 API 토큰을 시스템 프롬프트에 주입하는 것은 컨텍스트 내 자격 증명 노출(credential-in-context exposure)을 야기하며, 이를 통해 적대적인 프롬프트 인젝션 (prompt injection)을 통해 비밀 정보가 유출될 수 있습니다. 유용한 보안 프레임워크는 네 가지 표준 엔터프라이즈 통제 항목을 다룹니다: 신원 확인(identity verification), 권한 범위 제한(authorization scope limits), 민감한 작업에 대한 대역 외 확인(out-of-band confirmation), 그리고 감사 로깅(audit logging)입니다. 액션 런타임(action runtime)은 자격 증명을 모델로부터 격리하고, 대역 외(out of band)로 권한 부여 프로토콜을 중개함으로써 이 문제를 네이티브하게 해결합니다.

3. 실행 신뢰성 및 도구 정확도 (Execution reliability and tool accuracy)

LLM은 너무 많은 매개변수(parameters)를 제공하는 고카디널리티(high-cardinality) API 래퍼(wrapper)를 다루는 데 어려움을 겪습니다. 에이전트가 루프 재시도(looping retries)와 매개변수 환각(hallucinated parameters)을 방지하려면, 단순한 시스템 접근 권한보다는 의도(intent)에 최적화된 도구가 필요합니다. 해결책은 제약된 매개변수를 가진 단일 자연어 의도에 맞게 설계된, 에이전트 최적화 도구 카탈로그를 제공하는 것입니다.

도구 품질 벤치마크: ToolBench가 밝혀낸 것

현대적인 에이전트 아키텍처(Agent Architectures)의 핵심 문제는 기존의 API를 LLM에 그냥 전달하면 된다는 가정입니다. 실제로는 그렇게 작동하지 않습니다.

API는 에이전트를 위해 설계되지 않았습니다. API는 너무 넓은 노출 면적(Surface Area)과 너무 높은 카디널리티(Cardinality)를 가지고 있으며, 완벽하게 형성된 입력값(Inputs)을 가정합니다. 이러한 가공되지 않은 엔드포인트(Endpoints)를 그대로 감싸서 에이전트에게 전달하면, 에이전트는 실패합니다.

저희의 ToolBench 품질 벤치마크는 이 문제가 얼마나 광범위한지를 보여줍니다. 현재 기준으로 이 벤치마크는 43,467개의 Model Context Protocol (MCP) 서버에 걸쳐 약 219,444개의 도구를 분석했으며, 정의의 완전성(Definition Completeness), 프로토콜 준수 여부(Protocol Compliance), 보안(Security), 그리고 지원 가능성(Supportability)을 평가했습니다.

결과는 놀랍습니다. 도구의 약 0.5%만이 'A' 또는 그 이상의 등급을 받았으며, 76% 이상(167,333개)이 'F'를 받았습니다. 가장 빈번한 실패 모드(Failure Modes)는 기능 설명(Functional Descriptions)의 누락과 오류 처리(Error-handling) 지침의 부재였습니다.

도구에 엄격한 정의와 실패 시의 지침이 부족하면, LLM은 구조를 추론하고, 파라미터(Parameters)를 환각(Hallucinate)하며, 실패한 실행 루프 속에서 토큰(Tokens)을 낭비하게 됩니다.

이를 해결하려면 API 형태의 래퍼(Wrappers)에서 에이전트 최적화 도구(Agent-optimized tools)로 전환해야 합니다. 에이전트 최적화 도구는 몇 가지 핵심 설계 원칙을 따릅니다:

1. 도구당 단일 자연어 의도(Single natural-language intent).
2. 자유 형식의 텍스트 필드 대신 열거형(Enums) 사용.
3. 가능한 모든 곳에 기본값(Defaults) 적용.
4. 안전한 실행을 강제하기 위한 사전 검증된 파라미터(Pre-validated parameters).
5. 모델에게 다음 단계를 지시하기 위한 내장된 실패 지침(Built-in failure guidance).
6. 명확하게 문서화된 부작용(Side effects).

MCP vs Function Calling vs A2A: 프로토콜 스택이 결합되는 방식

개발자들은 종종 프로토콜을 서로 경쟁하는 선택지로 잘못 파악하곤 합니다. 2026년 현재, OpenAI의 Function Calling, Anthropic의 MCP, 그리고 Google의 Agent-to-Agent (A2A) 프로토콜은 상호 배타적이지 않습니다. 이들은 상호 보완적인 계층형 아키텍처(Layered Architecture)를 형성합니다.

Function Calling: 도구 호출 메커니즘

Function calling (함수 호출)은 기초적인 LLM (Large Language Model)의 기본 역량입니다. 이는 모델이 자연어 대신 구조화된 JSON 페이로드를 생성하는 원시 메커니즘 (raw mechanism)입니다.

Function calling은 출력을 검증하기 위한 엄격한 스키마 (schema)를 요구하지만, 실제 함수가 어떻게 실행되거나 발견되는지에 대해서는 아무것도 규정하지 않습니다.

MCP (Model Context Protocol): 도구 발견 및 전송

MCP는 전송 및 발견 표준 (transport and discovery standard) 역할을 합니다. 이는 도구 정의를 클라이언트 애플리케이션으로부터 분리(decouple)합니다.

에이전트 코드베이스에 스키마를 하드코딩하는 대신, 에이전트는 MCP 서버에 연결하여 사용 가능한 기능을 동적으로 발견하고, 표준화된 JSON-RPC 인터페이스를 통해 이를 실행합니다.

에이전트는 네이티브 함수 호출을 다음과 같이 MCP 실행 페이로드로 변환합니다:

원시 함수 호출 스키마 (LLM 관점):

{
  "name": "get_weather",
  "description": "Fetch current weather for a location",
...

MCP 서버 실행 페이로드 (전송 관점):

{
  "jsonrpc": "2.0",
  "id": 1,
...

A2A 프로토콜: 에이전트 간 협업 (agent-to-agent coordination)

MCP가 에이전트를 도구와 연결한다면, A2A 프로토콜은 에이전트를 다른 에이전트와 연결합니다.

A2A는 오케스트레이션 계층 (orchestration layer) 역할을 하며, 자율 에이전트가 동료의 기능을 발견하고, 복잡한 작업을 위임하며, 분산 시스템 전반에 걸쳐 컨텍스트 (context)를 전달하는 방식을 규정합니다. LangChain, LlamaIndex, CrewAI, AutoGen, 그리고 OpenAI Agents SDK와 같은 현대적인 에이전트 프레임워크들은 이미 MCP와 function calling을 추상화하고 있습니다. A2A 지원은 더 최신 기술이며, 프레임워크마다 채택 수준이 다릅니다. 기업용 오케스트레이션의 경우, 이는 아키텍처 측면의 트레이드오프 (trade-off) 문제입니다. MCP는 다운스트림 (downstream) 기능을 발견하고 실행하는 데 이상적이며, A2A 프로토콜은 MCP가 설계되지 않은 측면 상태 전달 (lateral state passing) 및 분산 조정 (distributed coordination)을 처리합니다.

에이전트 도구를 확보하는 방법: 네이티브 함수 호출 vs MCP 서버 vs iPaaS vs 런타임 관리형

프로토콜이 연결성을 표준화하는 동안, 도구를 획득하고 실행하는 데 사용하는 방식은 에이전트의 실제 신뢰성, 보안 및 컨텍스트 효율성(context efficiency)을 결정합니다.

네이티브 함수 호출 (Native function calling): 직접 도구를 구축 및 유지 관리

정의: 애플리케이션 코드에 직접 커스텀 도구 스키마(tool schemas)를 작성하고, 실행 로직, API 인증 및 전송 계층(transport layers)을 수동으로 유지 관리하는 방식입니다.

장점:

• 코드베이스와 실행 흐름에 대한 완전한 제어권을 가집니다.
• 외부 의존성이나 인프라 요구 사항이 전혀 없습니다.

단점:

• 상위 API 스키마 드리프트(schema drift)로 인해 지속적인 유지 관리 부담이 높습니다.
• 보안을 유지하며 확장하기가 어렵습니다. 대규모로 에이전트를 안전하게 배포하려면 커스텀 다중 사용자 권한 부여(multi-user authorization) 및 토큰 금고(token vaults)를 처음부터 직접 구축해야 합니다.

셀프 호스팅 MCP 서버 (Self-hosted MCP servers): 내부 도구 게이트웨이

정의: 내부 오픈 소스 MCP 서버를 배포하여 커스텀 에이전트와 기업 시스템 간의 인터페이스를 표준화하는 방식입니다.

장점:

• 현대적인 클라이언트 및 에이전트 프레임워크 전반에 걸쳐 표준화된 탐색(discovery) 및 통합을 제공합니다.
• 추론 로직(reasoning logic)과 도구 실행 사이의 깔끔한 아키텍처 경계를 생성합니다.

단점:

• 스키마 최적화를 전적으로 팀의 역량에 맡겨야 합니다.
• 도구가 동적으로 로드되지 않고 정적으로 주입될 경우 컨텍스트 세금(context tax)이 발생하기 쉽습니다.
• 다중 사용자 배포 환경에서 자격 증명을 관리하고 엄격한 사용자 격리를 보장해야 하는 보안 부담은 여전히 사용자에게 있습니다.

iPaaS 플랫폼 및 통합 래퍼 (Integration wrappers)

정의: 인간이 트리거하는 워크플로우를 위해 설계된 커넥터를 제공하는 Zapier나 Make와 같은 iPaaS 플랫폼을 사용하는 방식입니다. 또는 Composio와 같이 광범위한 앱 커버리지, 위임된 인증(delegated auth), 빠른 도구 통합을 제공하는 MCP 게이트웨이 및 통합 래퍼를 사용하는 방식입니다. 어떤 방식이든, 에이전트에게 이미 구축된 커넥터를 노출하는 형태가 됩니다.

장점:

• 수천 개의 지원되는 SaaS 애플리케이션을 포함하는 방대한 카탈로그에 접근할 수 있습니다.
• 단일 사용자 개념 증명(PoC)을 위한 빠른 프로토타이핑 속도를 제공합니다.

단점:

• 도구들은 일반적으로 에이전트에 최적화되어 있기보다는 API 형태를 띠고 있으며, 이는 대부분의 셀프 호스팅(self-hosted) MCP 서버가 공유하는 문제입니다. Zapier나 Make와 같이 사람이 트리거하는 iPaaS 커넥터의 경우, 원래 결정론적 워크플로(deterministic workflows)를 위해 구축되었고, 매개변수 환각(parameter hallucinations), 결정 루프(decision looping), 실행 실패를 자주 유발하는 높은 카디널리티(high-cardinality)의 API 표면을 노출하기 때문에 이 문제가 더욱 심각합니다.

Action runtime: 에이전트 최적화 도구 실행

정의: 목적에 맞게 구축된 도구 카탈로그를 제공하는 중앙 집중식 인프라 계층입니다. 이 런타임(runtime)은 도구 실행을 모델로부터 분리하므로, 주요 LLM, 프레임워크 및 MCP 클라이언트 전반에서 작동합니다. 컨텍스트 팽창(context bloat)을 방지하기 위해 도구를 동적으로 로드하여 에이전트가 필요로 하는 스키마(schema)만을 주입하며, LLM 프롬프트와 독립적인 사용자별 내장 OAuth를 사용하여 에이전트가 사용자의 권한 범위 내에서만 동작하도록 합니다.

장점: