AI 개발

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

JSONSort 게시 2026-09-05 업데이트 2026-09-05 약 16분

2026년 AI 제품 페이지는 거의 모두 「Agent」라고 쓴다. 대부분은 챗봇, 함수를 호출하는 모델, 다단계 워크플로를 끝까지 도는 런타임을 한 단어로 접는다. 정의부터 간다: AI Agent가 무엇인지, 루프가 어떻게 도는지, Tool Calling과 Function Calling이 어떻게 다른지, 왜 모든 층이 JSON에 착지하는지. 읽고 나면 더 긴 prompt가 아니라 디버그 가능한 호출 사슬을 그릴 수 있어야 한다.

읽기 전 요약

개념	한 줄	JSON 착지점
AI Agent	계획하고 도구를 호출한 뒤 결과를 다음 단계로 넘기는 런타임	워크플로 상태 / handoff
Tool Calling	모델이 「외부 능력이 필요하다」고 표현하는 총칭	`tool_calls`
Function Calling	벤더 API 안의 구현	`tools[]` / `arguments`
JSON	단계 사이에서 유일하게 안정적이고 검증 가능한 객체	Schema / payload

층을 기억하라: Agent는 런타임, Tool Calling은 능력, Function Calling은 API 프레임, JSON은 공유 계약.

AI Agent란 무엇인가?

AI Agent는 「더 잘 말하는 모델」이 아니다. 모델은 텍스트(또는 구조화 객체)만 생성한다. Agent는 모델을 루프에 넣는 런타임이다: 상태를 관찰하고, 다음을 계획하고, 외부 도구를 호출하고, 결과를 소화한 뒤 계속·인계·종료를 고른다.

2026년에 출시 가능한 Agent는 보통 세 조각이다:

모델: 추론, 도구 선택, Structured Outputs.
호스트: 호출 의도 파싱, 실제 API / DB / 파일 실행, 결과 반환, 불량 JSON 차단.
계약: 도구 인자, 반환값, handoff, 워크플로 상태—거의 전부 JSON.

호스트가 없으면 모델은 「제안」만 한다. 계약이 없으면 다단계 흐름은 반쯤 맞는 객체를 사실로 넘긴다. 제품 경계는 모델 카드가 아니라 호스트에 있다.

챗봇·일반 LLM과 무엇이 다른가

세 단어가 한 기능에 붙는다. 프로덕션에서는 쪼개야 한다:

일반 LLM: 텍스트 입력, 텍스트 출력. 도구도 없고 단계 간 상태도 없다.
챗봇: LLM을 대화 UI에 연결. 출력은 사람용. 실패하면 사용자가 재시도한다.
AI Agent: 출력을 프로그램이 실행한다. 도구 결과, 라우팅, 평가 점수는 산문이 아니라 객체다.

기준은 단순하다. 다음 단계를 사람이 읽는 게 아니라 코드가 실행해야 하면, 똑똑한 대화창이 아니라 Agent가 필요하다. 실행권은 호스트에 있고, 모델은 호출 의도만 낸다.

2026년 AI Agent는 어떻게 동작하는가

루프는 여전히 observe → plan → act → observe다. 달라진 점은 각 홉에 타입이 있다는 것이다. 「환불을 말했다」로는 부족하다.

Observe: 사용자 메시지, 직전 도구 결과, 현재 JSON 상태를 컨텍스트에 넣는다.
Plan: 모델이 직접 답할지, 도구를 부를지, 다른 Agent에 handoff할지 고른다.
Act: 호스트가 tool_calls를 실행하거나 handoff JSON으로 Agent를 바꾼다.
Observe again: 결과는 role: tool로 돌아오고, 상태 객체를 갱신한 뒤 다음 턴으로 간다.

호스트는 모델이 대신 해 주지 않는 네 가지를 한다. tools[] 주입, arguments 재파싱, Schema 검증, 실패 시 숏서킷(더 긴 prompt 재시도가 아님).

프로덕션 스택은 이미 수렴했다. Assistants API는 2026년 8월 26일 종료됐고, 새 코드는 Responses API + Agents SDK다. DevDay 2026 예측는 같은 흐름을 세 층으로 썼다: Structured Outputs가 객체를 만들고, Function Calling이 호출을 표현하고, Agent 런타임이 둘을 엮는다.

다단계 진행을 대화 기록에 「기억」시키지 말라. 현재 스텝을 복원 가능한 JSON으로 쓴다:

{
  "step": 2,
  "agent": "billing",
  "last_tool": "lookup_order",
  "state": {
    "order_id": "A-1042",
    "status": "paid",
    "amount": 99.00
  },
  "next": "create_refund"
}

먼저 로컬에서 포맷과 문법 검사하고, 지난주 동작하던 정의와 JSON Diff하라. 사용자 데이터나 비밀이 든 도구 응답을 공개 JSON 사이트에 붙이지 말라.

Tool Calling이란?

Tool Calling은 능력 층 총칭이다. 모델이 적절한 순간에 「외부 능력이 필요하다」를 기계가 읽게 낸다. 자연어로 이미 DB를 조회한 척하지 않는다. 특정 벤더 필드명에 묶이지 않는다.

2026년 적어도 세 구현이 Tool Calling으로 불린다: OpenAI 호환 API의 Function Calling, Anthropic 등의 Tool Use, MCP의 tools/list + tools/call. MCP Tool Schema vs Function Calling가 경계를 그렸다: MCP는 호스트 너머로 도구를 공급하고, API 프레임이 이번 홉의 의도를 표현한다.

개발자에게 Tool Calling이 답하는 질문은 「모델이 손을 뻗을 수 있는가」다. 「뻗은 뒤 인자와 결과를 누가 검증하는가」는 Schema와 호스트의 일이다.

Function Calling이란?

Function Calling(OpenAI 문서는 이제 대부분 tools)은 Tool Calling의 벤더 Chat / Responses API 안 구체 형태다. 함수 정의를 넣고, 모델이 호출하면 응답에 tool_calls가 온다.

전형적인 OpenAI 스타일 정의는 이렇다. parameters는 이미 JSON Schema 부분집합이다:

{
  "type": "function",
  "function": {
    "name": "lookup_order",
    "description": "Look up an order by ID",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {
          "type": "string",
          "description": "Order ID, e.g. A-1042"
        }
      },
      "required": ["order_id"],
      "additionalProperties": false
    }
  }
}

호출 의도는 보통 이렇게 돌아온다:

{
  "tool_calls": [{
    "id": "call_3c91",
    "type": "function",
    "function": {
      "name": "lookup_order",
      "arguments": "{\"order_id\":\"A-1042\"}"
    }
  }]
}

arguments는 여전히 문자열화된 JSON이다. 호스트는 다시 JSON.parse하고 order_id를 Schema로 검증해야 한다. 이 단계를 건너뛰는 것이 2026년 가장 흔한 프로덕션 사고다. 중첩이 깨지면 먼저 포맷과 문법 검사로 괄호와 이스케이프를 본다.

Tool Calling과 Function Calling을 어떻게 구분하고 겹치나

대체재가 아니다. 층이 다르다:

Tool Calling: 개념. 「모델이 의도를 내고 호스트가 실행」이면 해당.
Function Calling: API 프레임. 필드는 tools[], tool_calls, role: tool.
MCP Tool Schema: 공급 프로토콜. 필드는 inputSchema. stdio / SSE로 MCP Server에 전달.

올바른 겹침: 저장소에 Schema 하나, Function Calling parameters와 MCP inputSchema로보내낸다. prompt 산문에 「거의 같은」 세 번째 인자 설명을 두지 말라. 세부사항은 MCP Tool Schema vs Function Calling와 AI Agent가 JSON Schema를 필요로 하기 시작한 이유.

왜 2026 Agent는 모두 JSON에 착지하는가

자연어는 사용자에게 말하는 용도다. 기계 사이 각 홉은 검증·Diff·재생이 가능해야 한다. JSON은 다섯 종류의 객체를 나른다:

도구 정의: tools[] 또는 MCP inputSchema.
호출 의도: tool_calls 안의 함수명 + 인자.
도구 결과: 조회·쓰기·외부 API 반환 객체. 가장 자주 빠지는 층.
Agent handoff: 의도, 신뢰도, 라우팅 대상. Agents SDK는 「billing을 말했다」가 아니라 이 객체로 라우팅한다.
워크플로 상태와 평가: checkpoint, trace, eval fixture. 긴 작업은 JSON에서 재개한다. 채팅 기록으로 진행을 추측하지 않는다.

JSON Schema가 그 구경이다. 구경이 없으면 Function Calling, MCP, A2A가 각자 「비슷해 보이는」 정의로 표류한다. AI Agent가 JSON Schema를 필요로 하기 시작한 이유는 Schema를 문서에서 런타임 게이트로 바꿨다. 문법 입문은 JSON Schema 튜토리얼.

한 번의 완전한 JSON 파이프라인

「주문 조회 → 환불」을 예로 든다. 2026년의 보수적이고 테스트 가능한 사슬은 이렇다:

호스트가 lookup_order / create_refund Schema를 tools[]에 넣고 strict: true를 켠다.
모델이 tool_calls를 반환한다. arguments는 아직 문자열.
호스트가 JSON.parse하고 같은 Schema로 검증한다. 실패하면 숏서킷하고 결제 시스템에 손대지 않는다.
실제 조회를 실행해 주문 객체를 얻는다.
role: tool로 반환한다. 산문이 아니라 Schema에 맞는 JSON이 좋다.
모델은 다음 도구를 부르거나 사용자 / 하류 Agent용 Structured Output을 낸다.
Agent를 바꾸려면 handoff 객체를 쓴다. 「billing 동료에게 물어보라」고 쓰지 않는다.

handoff 객체는 이 정도로 안정적이어야 한다:

{
  "handoff": {
    "from": "triage",
    "to": "billing_agent",
    "intent": "refund",
    "order_id": "A-1042",
    "confidence": 0.91
  }
}

여러 Agent가 서로를 발견해야 할 때 A2A Extensions는 능력을 Agent Card에 쓰고 확장 헤더로 협상한다. 위 파이프라인을 대체하지 않고, Agent 사이 배송만 맡는다.

2026년에 무엇을 고를까

단일 앱, 닫힌 내부 루프, 도구 10개 미만: Function Calling으로 충분. 먼저 Schema와 strict: true를 CI에 넣는다.
IDE / 플랫폼 / 꽂았다 빼는 타사 도구: 공급은 MCP, 이번 홉 의도는 Function Calling.
이종 Agent가 발견·확장 협상을 해야 함: 사설 봉투를 만들지 말고 A2A를 더한다.
어떤 길이든: 도구 인자·결과·handoff를 먼저 JSON Schema로 쓰고 어댑터를 보낸다.

키노트가 「프로토콜을 통일」하기를 기다리지 말라. 2026년의 안정 전략은 층 나누기지, 승자 맞히기가 아니다.

흔한 실수

Agent를 더 잘 말하는 ChatGPT로 본다. 대화창은 데모가 된다. 프로덕션은 복원 가능한 상태 기계가 필요하다.
Tool Calling과 Function Calling을 경쟁 제품으로 본다. 하나는 개념, 하나는 API 프레임. MCP는 세 번째 공급 층이다.
arguments를 검증하지 않는다. 문자열화 JSON, 숫자 문자열, 결제에 끼어든 여분 필드는 모두 이 홉에서 생긴다.
도구 결과가 자유 텍스트. 다음 홉은 「성공한 것 같다」를 주문 상태로 취급한다.
한 요청에 도구 50개. 큰 Schema는 비싸고 오선택이 는다. 10개를 넘으면 라우팅이나 검색을 넣는다.

FAQ

Agent는 반드시 Function Calling을 써야 하나?

아니다. Function Calling은 가장 흔한 API 프레임이지만 MCP Tool Use와 벤더 Tool Use도 Tool Calling이다. 핵심은 호스트 실행 + Schema 검증이지, 필드 이름이 tools인지 inputSchema인지가 아니다.

Tool Calling은 Function Calling의 새 이름인가?

어떤 문서는 둘을 섞는다. 더 깨끗한 구분: Tool Calling은 총칭, Function Calling은 OpenAI 호환 tools / tool_calls 모양. 아키 그림에서 상자를 나누면 논쟁의 대부분이 사라진다.

JSON mode만으로 Schema 없이 충분한가?

JSON mode는 「JSON처럼 보인다」만 보장하고 필드·타입·enum의 적법성은 보장하지 않는다. 2026 Structured Outputs는 json_schema + strict로 구경을 고정한다. 다단계 Agent에서 JSON mode는 평가 세트를 통과하지 못한다.

DevDay 2026까지 기다려야 하나?

아니다. 9월 29일이 Structured Outputs와 호출 계획을 깊게 할 수는 있어도 「먼저 Schema를 쓴다」는 바뀌지 않는다. 지금 도구와 handoff를 git에 넣고, 키노트 뒤에는 어댑터만 갈아끼운다.

도구와 handoff JSON은 어떻게 디버그하나?

브라우저에서 포맷하고, 빠진 required를 확인한 뒤 이전 버전과 Diff한다. JSONSort는 로컬 실행이며 업로드하지 않는다. 비밀이 든 도구 응답을 공개 사이트에 붙이지 말라.

결론

AI Agent는 도구와 상태를 가진 런타임이지, 더 잘 말하는 모델이 아니다. Tool Calling이 손을 뻗게 하고, Function Calling은 그 손의 가장 흔한 API 모양이며, JSON은 매 홉에서 맞아야 하는 객체다.

오늘부터 schemas/tools/lookup_order.json을 먼저 쓰고, 더 긴 prompt는 나중에 써라. 모델은 바뀌고 프로토콜은 늘어난다. 구경을 먼저 안정시켜라.

더 읽기

AI Agent가 JSON Schema를 필요로 하기 시작한 이유 Tool Calling에서 구조화 워크플로까지
MCP Tool Schema vs Function Calling 도구 JSON의 프로토콜 경계
A2A Extensions와 JSON 프로토콜 멀티 Agent 상호운용 세 번째 층
OpenAI DevDay 2026 핵심 예측 세 층이 하나의 JSON 관이 되는 과정
JSONSort 로컬 도구상자 포맷, 검증, Diff
모든 글 JSON과 AI 개발 노트

변경 기록: 2026-09-05 최초 게시