AI Agent가 JSON 없이는 안 되는 이유: Tool Calling·Function Calling에서 MCP까지 데이터 흐름

이전 기사AI Agent가 JSON Schema, Function Calling 및 MCP를 사용하는 이유설명했다이 세 가지 층이 존재하는 이유. 이 작품은실제로 이동하는 바이트한 번의 실제 호출로 거의 모든 것이 JSON입니다.

사용자는 자연어를 봅니다. Agent는 인텐트를 JSON 매개변수로 인코딩하고 도구 결과를 JSON 메시지로 인코딩하며 크로스 프로세스 프로토콜을 JSON-RPC로 인코딩하여 작업을 수행합니다. JSON은 장식이 아닙니다. 이는 모델, 호스트 및 MCP 서버 간에 상호 검증 가능한 유일한 언어입니다.

세 개의 이름, 하나의 JSON 페이로드

문서에는 세 가지 용어가 혼합되어 있습니다. 서로 다른 레이어에 위치하지만 페이로드 모양은 거의 동일합니다.

One sentence: the model side uses JSON to pick a tool and fill parameters; the MCP side uses JSON to discover and execute tools. The host is the translator: MCP tools/list becomes the model tools array; model tool_calls become tools/call.

JSON이어야 하는 이유

Agent는 동시에 세 당사자를 만족시켜야 합니다.

• 모델: 훈련 데이터는 JSON로 가득 차 있습니다. 유효한 객체를 내보내는 것이 protobuf 바이트보다 훨씬 쉽습니다.
• 프로그램: 성숙한 구문 분석, 스키마 검증, Diff 및 JSONPath 도구
• 프로토콜: OpenAPI, JSON-RPC 및 MCP inputSchema는 이미 하나의 유형 설명을 공유합니다.

일반 언어는 실패할 수 없습니다. 대괄호, 따옴표 및 혼합 언어는 정규식 파서를 중단합니다. YAML은 들여쓰기가 쉽습니다. 바이너리 프로토콜은 인간과 LLM 모두에게 적대적입니다. JSON은 감사, 검증 및 버전 지정이 가능한 기본 와이어 형식이 됩니다. 이것이 바로 이 사이트의 도구가 모두 JSON을 중심으로 돌아가는 이유입니다. 즉, 해당 와이어를 디버깅하는 것입니다.

홉 1: 도구 정의의 스키마

The flow starts by telling the model which tools exist. Whether you use OpenAI-style tools or MCP tools/list, the core is a JSON Schema (or a subset):

{
  "name": "get_weather",
  "description": "Look up current weather for a city, read-only",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. Shanghai" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["city"]
  }
}

In MCP the same constraint lives in inputSchema. Schema feeds two paths: the validator rejects illegal parameters; model context uses description to decide when to call. The more the field text reads like a product spec, the fewer mistaken calls.

홉 2: 함수 호출 / 도구 호출

호스트가 메시지와 함께 도구 목록을 보낸 후 모델코드를 실행하지 않습니다. 구조화된 호출을 반환합니다. 일반적인 형태(필드 이름은 공급업체에 따라 다름):

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_01",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"Shanghai\",\"unit\":\"celsius\"}"
      }
    }
  ]
}

Note that arguments is often a stringified JSON object: JSON.parse first, validate against Schema, then execute. Results flow back as a tool-role message:

{
  "role": "tool",
  "tool_call_id": "call_01",
  "content": "{\"city\":\"Shanghai\",\"temp_c\":31,\"condition\":\"sunny\"}"
}

This hop is how the model reaches out. With parallel tools, the array holds multiple tool_calls; the host may run them concurrently and match results by id.

홉 3: MCP JSON-RPC

도구가 호스트 프로세스가 아닌 MCP 서버(파일 시스템, GitHub, 내부 주문)에 있는 경우 호스트와 서버는 JSON-RPC 2.0을 사용합니다. 읽기 전용 쿼리는 대략 다음 세 단계로 구성됩니다.

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"host","version":"1.0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_weather","arguments":{"city":"Shanghai"}}}

A successful Server response is JSON too: content often has type: "text" whose text is another JSON string. That is JSON wrapping JSON — outer envelope vs inner business payload. When debugging MCP, split those layers, then Schema-validate the inner one.

전송은 stdio 또는 Streamable HTTP일 수 있습니다.페이로드는 여전히 JSON 줄이거나 JSON 본문입니다.. 2026 전송 및 서버 코드를 변경해야 하는지 여부는 다음을 참조하세요.MCP 2026 마이그레이션 가이드.

한 번의 호출에 대한 엔드투엔드 추적

사용자가 "오늘 상하이는 얼마나 따뜻합니까?"라고 묻습니다. 끝에서 끝까지:

1. Host → MCP Server: tools/list returns tools with inputSchema (JSON)
2. Host → model API: mapped to tools[].parameters (still JSON Schema)
3. Model → Host: tool_calls with arguments {"city":"Shanghai"}
4. 호스트는 다음을 확인합니다.스키마에 반대; 누락된 필드 또는 잘못된 유형이 실행을 거부하고 오류 JSON를 모델로 되돌림
5. Host → MCP: tools/call with params.arguments as an object (not a string)
6. MCP → 호스트:날씨 결과 JSON
7. Host → model: role: tool content string
8. 모델 → 사용자:자연어; 다운스트림 시스템이 구조만 원하는 경우 출력 스키마로 최종 JSON를 제한하세요.

User natural language
    │
    ▼
Host orchestration ──JSON Schema──► LLM Tool Calling
    │                                  │
    │                                  ▼
    │                             arguments JSON
    │                                  │
    ▼                                  ▼
MCP JSON-RPC ◄──────────── validate, then execute
    │
    ▼
Result JSON ──► tool message ──► model final reply

작은 스크립트는 MCP를 건너뛰고 호스트에서 로컬 함수를 호출할 수 있습니다. 엔터프라이즈 에이전트는 거의 항상 Tool Calling + MCP로 스택됩니다. 생태계 선택에 대해서는 다음을 참조하세요.2026년 MCP 서버 순위.

유효성 검사 실패가 다시 발생하는 방식

JSON은 실패도 구조화될 수 있으므로 Agent의 유형 시스템 역할을 할 수 있습니다. 게이트를 두 개 이상 사용하세요.

개발 중에는 Schema와 2~3개의 유효한/잘못된 페이로드를 git에 유지하고 JSON 도구 상자에서 로컬로 유효성을 검사합니다. 이는 소비자가 모델이라는 점을 제외하면 REST 계약 테스트와 동일한 아이디어입니다.

FAQ

요약

AI Agent는 JSON 없이는 살 수 없습니다. 왜냐하면모든 홉은 기계에서 읽을 수 있어야 합니다.: 스키마는 도구를 설명하고, Tool Calling는 호출을 전달하고, MCP는 JSON-RPC로 프로세스 외부로 전달합니다. 자연어는 사용자가 향하는 끝에서만 나타납니다. 중간은 유효성을 검사할 수 있는 개체입니다.

Start with one real tool: write the Schema → print and parse the model's arguments string → if the tool lives on an MCP Server, capture one tools/call. When those three JSON documents line up, the Agent is actually working. For the evolution story see 기술적 타임라인. Validate Schema samples locally in JSON Toolbox before you ship.