AI Agent란 무엇인가? 2026 동작 원리, Tool Calling, Function Calling과 JSON 완전 가이드

AI Agent란: 채팅·워크플로와의 차이

최소 정의는 셋이다. 목표(무엇을 끝낼지), 지각(문맥과 도구 회신), 행동(어느 도구, 어떤 인자, 또는 최종 답). 매 단계 행동은 모델이 고르고, 실행과 관찰 기록은 런타임이 한다. 루프도 도구도 검증 가능한 인자 모양도 없으면 채팅일 뿐이다.

챗봇과의 차이는 상표가 아니라 정지 조건이다. 채팅은 한 턴에 끝나도 된다. Agent는 도구 결과 전에 완료를 선언하면 안 된다. 청구서를 찾고 요약한 뒤 확인을 물을 수 있다. 고전 워크플로와의 차이는 누가 간선을 그리는가다. n8n / Temporal의 다음 홉은 사람이 미리 잇는다. Agent의 다음 홉은 모델이 현재 JSON 관찰에서 고른다. 워크플로는 예측·재생이 쉽다. Agent는 유연하고 「인자 오류」를 일등 장애로 만든다.

2026년 흔한 형태: 코딩 Agent(파일, 테스트, 패치), 고객·운영 Agent(주문, 티켓), 다중 Agent 편성(기획자가 전문 Agent에 위임). 계약은 같다. 경계는 JSON Schema, arguments와 result는 parse 가능한 JSON. Apple은 같은 함수를 App Intent와 모델 도구에 동시에 노출할 수 있다. Apple AI Agent와 JSON.

2026 동작 원리: 관찰 → 결정 → 호출 → 재관찰

데모 영상의 「지능」을 벗기면 전형적인 루프는 다섯 단계다.

1. 사용자 목표가 문맥에 들어간다(자연어 + 선택적 시스템 제약).
2. 런타임이 도구 목록을 주입한다. name, description, JSON Schema(parameters / inputSchema).
3. 모델이 tool_calls(함수와 arguments) 또는 최종 텍스트 / Structured Output을 반환한다.
4. 런타임이 arguments를 JSON.parse하고 로컬 함수, HTTP 또는 MCP tools/call을 실행한 뒤 result JSON을 메시지에 쓴다.
5. 모델이 결과를 보고 다음 도구 또는 종료를 고른다. maxSteps, 사용자 취소, Schema 실패도 멈춘다.

루프 모양 자체를 설정으로 둘 수 있다. 아래 JSON은 hops와 정지 조건만 적는다. 업무 필드는 각 도구 Schema에 둔다.

{
  "loop": "agent",
  "maxSteps": 8,
  "stopWhen": ["final_answer", "max_steps", "user_cancel", "schema_fail"],
  "hops": [
    { "kind": "model", "emits": "tool_calls | text" },
    { "kind": "runtime", "emits": "tool_result JSON" },
    { "kind": "model", "emits": "next_tool | final JSON" }
  ]
}

고장은 거의 3→4단계에서 난다. arguments가 문자열인데 객체로 다루거나, 숫자가 문자열이고, required가 빠지고, 캐시된 목록과 도구 이름이 어긋난다. 「더 똑똑한 모델」은 계약 드리프트를 고치지 않는다. 무상태 MCP는 요청마다 프로토콜 메타를 붙이지만 모양은 모델에 준 Schema에 달렸다.

Tool Calling과 Function Calling: 같은 메커니즘의 두 이름

공학적으로는 같다. 모델은 데이터베이스를 건드리지 않고 「이 함수를 이 인자로 호출하라」는 구조화 요청을 내고 런타임이 실행한다. 2023–2026 제품명 대조:

OpenAI는 이후 functions를 tools에 넣고 strict를 붙였다. Anthropic은 tool_use / input_schema. Gemini는 function declarations. MCP는 JSON-RPC tools/call. 이름은 달라도 arguments는 JSON object다. 「Function Calling은 낡았다」를 이전 이유로 쓰면 대개 틀린다. 낡은 것은 필드 이름이지 메커니즘이 아니다.

같은 청구서 검색을 OpenAI strict tool로 쓴다. strict에서는 모든 property가 required에 있어야 한다. 아니면 기본값이 있다고 생각한 필드를 모델이 합법적으로 생략한다.

{
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "description": "Search invoices by date range and status",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "startDate": { "type": "string", "format": "date" },
        "endDate": { "type": "string", "format": "date" },
        "status": {
          "type": "string",
          "enum": ["draft", "sent", "paid", "void"]
        }
      },
      "required": ["startDate", "endDate", "status"],
      "additionalProperties": false
    }
  }
}

호출 시 전형적인 tool_calls는 아래와 같다. arguments는 여전히 문자열이다. 먼저 parse, 다음 검증. JSON.parse 실패를 곧바로 「모델 고장」으로 두지 마라. 문법 파괴와 Schema 불일치를 가른다. 분류는 AI JSON 오류 가이드.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

JSON이 Agent 계약 언어인 이유

파이프라인에는 최소 세 JSON이 있고 하나의 canonical Schema에서 와야 한다.

1. 도구 정의: name / description / parameters(또는 MCP inputSchema).
2. 모델 arguments: 선택된 키. tool_calls 안에서는 문자열인 경우가 많다.
3. 도구 결과: 런타임이 돌려주는 ok / result 또는 오류 봉투. 다음 홉의 재료.

네 번째는 선택. 최종 답 Structured Output. 사용자나 하류 시스템의 답 모양이지 searchInvoices 입력이 아니다. 문법은 같고 의미는 다르다. 파일과 버전을 나눠라. AI Structured Output 튜토리얼.

성공 후에는 하류 HTTP 원문을 모델에 그대로 던지지 마라. 안정된 봉투를 돌려라. 아래 result는 업무에 필요한 키만. 원문은 로그로. 모양이 안정되면 재시도와 요약이 예측 가능하다.

{
  "toolCallId": "call_8f3a",
  "name": "searchInvoices",
  "ok": true,
  "result": {
    "count": 2,
    "items": [
      { "id": "INV-1042", "total": 1280.5, "currency": "USD" },
      { "id": "INV-1048", "total": 640.0, "currency": "USD" }
    ]
  }
}

2026 스택: OpenAI, Anthropic, Gemini, MCP

만능 Schema는 없다. 다만 Tool Calling 데이터는 모인다. arguments는 JSON object, 계약은 JSON Schema 부분집합.

MCP는 발견과 전송이지 타입 시스템이 아니다. inputSchema는 모양 선언. Server는 여전히 parse + Schema 검증을 해야 한다. 필드 대응과 한 Schema의 세 면 재사용은 MCP와 JSON Schema. 다중 Agent 전달은 A2A message/send. 스킬 목록에도 Schema가 걸린다. 그것은 Agent 대 Agent이지 모델 대 도구가 아니다. 대조 A2A vs MCP.

무상태 MCP는 Session을 뺀 뒤 수평 확장에 더 맞다. arguments는 자동으로 고치지 않는다. 낡은 tools/list 캐시는 잘못된 모양을 쓴다. 프로토콜은 Stateless MCP 해설.

현장 검증과 JSONVue

각 홉은 세 단계. parse → Schema → 업무 규칙. 똑똑한 모델도 이 셋을 대체하지 않는다.

1. arguments 문자열 JSON.parse. 실패면 raw와 tool_call id를 남기고 재시도 가능한 오류 봉투를 반환.
2. parameters / inputSchema로 Draft 2020-12 검증. path와 keyword를 낸다.
3. 업무 게이트: 날짜 범위, 열거와 권한, 외래 키. 통과한 뒤에만 하류 API.

세 JSON을 나란히 둔다. 모델 arguments, MCP 또는 HTTP로 보낸 body, Server가 실제로 쓴 객체. 모양이 다르면 거의 어댑터 층. 브라우저에서 JSON 포맷터로 parse 확인, JSON Schema 검증으로 arguments와 Schema, JSON Diff로 모델 arguments와 하류 body를 비교. valid / missing-field / wrong-enum 픽스처를 CI와 수동 점검이 공유한다.

더 읽기: MCP와 JSON Schema, Structured Output, AI JSON 오류, A2A vs MCP.

자주 묻는 질문

요약과 다음 단계

2026 AI Agent는 한 줄이다. 모델이 루프에서 행동을 고르고, 런타임이 도구를 실행하며, JSON Schema가 각 홉의 모양을 적는다. Tool Calling과 Function Calling은 같은 메커니즘의 제품명이다. MCP, A2A, Structured Output은 다른 홉을 맡는다. 한 파일을 억지로 공유하지 마라.

다음은 구체적이다. 시스템의 세 JSON(정의, arguments, result)이 같은 Schema인지 확인하고 JSONVue에서 valid / 필드 누락 / 잘못된 열거를 재생한다. 프로토콜은 MCP 글, 최종 모양은 Structured Output, 실패 층은 JSON 오류 가이드.