JSON Schema가 AI Agent의 표준 Contract가 될까?

이 시리즈의 이전 글 — JSON Schema, Function Calling, MCP의 진화, 실전 Structured Output, Agent 호출 체인의 JSON 데이터 흐름 — 을 읽었다면 한 가지 패턴이 눈에 띕니다. 모델 벤더든 프로토콜 레이어든, 「어떤 형태의 데이터를 주고받을지」를 설명할 때 답은 거의 항상 JSON Schema(또는 그 subset)입니다.

자연스럽게 이런 질문이 생깁니다. JSON Schema가 AI Agent의 표준 Contract — 팀, IDE, 클라우드 벤더 간 기본 handshake 언어, REST의 OpenAPI나 gRPC의 Protobuf처럼 — 가 될까요?

「Contract」가 실제로 무엇을 의미하는지에서 출발해, 이 글은 2026년 adoption, 남은 gap, 엔지니어링 선택을 정리합니다. 스포일러: JSON Schema는 이미 Agent I/O 경계의 de facto 표준이지만, 유일한 contract layer는 아닙니다 — transport, auth, orchestration은 여전히 MCP, OpenAPI, Agent SDKs의 영역입니다.

Agent에게 「Contract」란

소프트웨어 엔지니어링에서 contract는 교환 데이터의 형태, 의미, 오류 처리를 규정합니다. AI Agent는 일반 API보다 어렵습니다. 「호출자」에 비결정적 대형 모델이 포함되어 필드를 빠뜨리거나, 파라미터를 지어내거나, 자연어와 structured output 사이에서 drift할 수 있기 때문입니다.

Agent stack에는 여러 contract layer가 있으며, JSON Schema는 주로 payload shape를 담당합니다:

「JSON Schema가 표준 Contract가 된다」는 말은 실무에서 이렇게 의미합니다. 모델과 프로그램 — 또는 프로그램과 tool — 이 structured JSON을 교환하는 모든 곳에서 JSON Schema가 기본 설명입니다. 연결 방법과 권한은 그 위 layer입니다.

JSON Schema가 이미 장악한 세 front

1. Tool / Function Calling parameters

OpenAI, Google Gemini, Anthropic Claude Tools API는 모두 parameters(또는 동등 항목)에 JSON Schema를 사용합니다. 모델은 description으로 semantics를 읽고, Host는 실행 전 같은 Schema로 arguments를 검증합니다 — 데이터 흐름 글에서 분해한 chain과 일치합니다.

{
  "name": "create_ticket",
  "description": "Create a record in the ticketing system",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "description": "Ticket title" },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] }
    },
    "required": ["title"],
    "additionalProperties": false
  }
}

2. Structured Output (모델 최종 응답)

비즈니스가 자연어 대신 JSON이 필요할 때, vendor Structured Output / JSON Schema mode는 decode time에 token을 제약합니다. Structured Output 가이드를, Gemini는 structured JSON 튜토리얼을 참고하세요.

3. MCP Tool inputSchema

MCP spec은 각 Tool이 inputSchema를 JSON Schema로 노출하도록 요구합니다. Cursor, Claude Desktop 등 Host가 MCP tool을 model Function Calling에 매핑할 때 Schema는 그대로 전달되거나 가볍게 subset됩니다 — 「Schema를 한 번 작성해 IDE와 cloud model에서 재사용」의 기반입니다.

이 세 front는 Agent lifecycle의 거의 모든 structured JSON boundary를 커버합니다 — 「표준 Contract」 논지의 핵심 근거입니다.

대안과 경쟁자

핵심 insight: 「model-readable」과 「고성능 RPC」를 모두 최적으로 만족하는 단일 format은 없습니다. JSON Schema는 model ↔ program link에서 이깁니다. OpenAPI와 Protobuf는 각 domain을 유지하고 conversion layer로 연결됩니다.

JSON Schema가 이기는 이유

1. LLM training distribution과 정렬: pretraining에 JSON이 풍부; Schema type, enum, description은 soft type hint 역할.
2. Human·machine readable: PM, backend, prompt engineer가 같은 Schema를 review — binary Protobuf보다 협업에 유리.
3. 성숙한 validation ecosystem: ajv, jsonschema (Python), cloud API built-in — Structured Output 후 semantics용 second-pass validation은 여전히 권장.
4. Vendor convergence: 2023에는 custom tool format; 2024–2026 mainstream API doc은 parameters·responses에 JSON Schema subset 표준화.
5. MCP·OpenAPI 「downward compatibility」: MCP는 새 DSL 대신 JSON Schema 선택; OpenAPI 3 Schema component 직접 재사용.

아직 통일되지 않은 것

「De facto standard」≠「fully unified」. Production Agent는 여전히 다음을 겪습니다:

• Schema dialects: OpenAI strict: true는 additionalProperties와 full required coverage에 엄격; Gemini·Anthropic은 union, $ref depth 등에서 다름. 복잡한 Schema는 target API로 테스트.
• Draft versions: draft-07, 2019-09, 2020-12 공존; $defs vs definitions가 codegen tool을 걸림.
• Syntax vs semantics: Schema는 「priority가 있고 string」까지 보장, 「priority=high가 SLA policy 충족」은 아님 — business rule은 code 또는 JSON Logic 같은 extension 필요.
• Non-JSON payloads: images, audio, file URI — Schema는 metadata wrapper, blob storage contract 아님.
• Orchestration and state: multi-step Agent, human-in-the-loop, sub-Agent delegation — JSON Schema는 state machine을 설명하지 않음; LangGraph, Temporal 등은 자체 DSL.

「하나의 Schema가 전체 Agent stack을 지배」를 기대하기는 비현실적; 「모든 structured JSON boundary가 Schema를 default로 쓴다」는 이미 대체로 사실입니다.

2026 생태계 신호

Tech debt를 평가한다면: 지금 JSON Schema skill·tooling에 투자하는 것이 private JSON format 위에 prompt를 쌓는 것보다 안전 — 미래 「Agent Schema 2027」 profile도 새 언어보다 JSON Schema superset·subset일 가능성이 큽니다.

「유일한」 표준이 될까?

두 단계 답변:

Yes (높은 확신) — Agent structured I/O의 default Contract로: tool parameters, Structured Output, MCP inputSchema, OpenAPI request/response body. JSON Schema description 없는 새 tool·model API는 불완전해 보입니다.

No (동등하게 중요) — sole full-stack Agent contract로는: transport(stdio/SSE/HTTP), auth, tool discovery, multi-Agent orchestration, SLA·quota는 MCP, OpenAPI, platform policy 영역. JSON Schema는 「type layer」이지 「network」·「governance」 layer가 아닙니다.

┌──────────────────────────────────────────────────┐
│  Governance / auth / audit (OAuth, RBAC, logs)   │
├──────────────────────────────────────────────────┤
│  Orchestration / state (Agent frameworks, flows) │
├──────────────────────────────────────────────────┤
│  Connection / discovery (MCP, OpenAPI, gRPC GW)  │
├──────────────────────────────────────────────────┤
│  ★ JSON Schema: tool args · output · payloads ★  │
├──────────────────────────────────────────────────┤
│  Executors (HTTP, DB, files, browser automation) │
└──────────────────────────────────────────────────┘

실무 권장사항

• Single Schema source: domain model을 Pydantic / Zod에 정의, OpenAI·MCP·docs용 JSON Schema 생성 — 세 정의 drift 방지.
• Subset per target API: OpenAI strict, Gemini 등용 「compatible Schema」 유지, 또는 CI로 unsupported keyword 탐지.
• Treat description as Prompt: description이 mis-fire 유발; field naming처럼 review.
• Structured Output + server re-validation: decoding은 syntax error 감소; business rule은 같은 Schema + custom validator.
• Version and changelog: Schema 변경 = breaking API change; Schema version pin 또는 backward compatible 유지.
• Validate locally first: integration 전 JSON Toolbox로 schema syntax·sample payload 검증.

FAQ

요약과 다음 단계

JSON Schema는 AI Agent structured I/O의 표준 Contract가 되고 있습니다 — 예측이 아니라 OpenAI, Google, Anthropic, MCP, mainstream Agent SDKs가 함께 깔아 둔 track입니다. OpenAPI·Protobuf 전체를 대체하지는 않지만, model ↔ program handshake에서는 대안 여지가 적습니다.

다음: 실제 business path 하나(예: user intent → structured extraction → ticket API)를 고르고, 하나의 JSON Schema에서 Structured Output·tool parameters를 구동, JSON Toolbox로 로컬 검증 후 MCP 연결. 권장 시리즈 순서: evolution overview → Structured Output → data flow → 이 글(Contract verdict).