산업 표준

Gen AI / LLM 분야에서 두 가지 표준이 각 영역의 사실상 표준(de facto)으로 부상했습니다:

• A2A (v1.0, Linux Foundation)는 에이전트가 동료들과 어떻게 통합하고 통신하는지를 정의합니다. 이는 에이전트의 *인터페이스(interface)*를 정의하지만, 에이전트 자체를 정의하지는 않습니다.
• MCP (2026-07-28 스펙, 오늘 최종 확정)는 에이전트가 도구(tools)를 어떻게 사용하는지를 정의합니다. 이는 에이전트의 *내부 배관(internal plumbing)*을 정의하지만, 에이전트 자체를 정의하지는 않습니다.

두 표준 모두를 공정하게 평가하기 위한 한 가지 미묘한 차이점은, 에이전트가 단일 신뢰 도메인(trust domain) 내에서 MCP 서버로 노출될 때 MCP가 에이전트의 공개 인터페이스 역할을 할 수도 있다는 점입니다. 따라서 A2A는 조직 간의 계약을 다루고, MCP는 그 내부의 모든 것을 다룹니다. 어느 쪽이든 결론은 동일합니다: 두 프로토콜 모두 에이전트가 무엇인지를 정의하지는 않습니다.

제가 보기에는 '에이전트(agent)'와 '에이전틱(agentic)'이라는 용어가 여전히 명확하게 정의되지 않은 것 같으며, 이 글은 이에 대한 운영적 정의(operational definition)를 내리려는 시도입니다. 즉, 이를 기반으로 호스트(host)를 구축할 수 있을 만큼 정밀한 정의를 목표로 합니다. 이 주장은 가설이 아닙니다. 저는 현재 MCP 호스트를 구축하고 있으며, 이 정의는 그 작업 과정에서 도출된 결과물입니다.

기존 연구 (그리고 그것이 충분하지 않은 이유)

"에이전트는 루프 내에서 도구를 사용하는 LLM이다" (Anthropic의 프레임워크)라는 설명은 방향성 측면에서는 맞지만, 운영적이지는 않습니다. 즉, agents.json에 무엇이 포함되어야 하는지를 알려주지 않습니다. 학술적 정의(합리적 에이전트(rational agents), BDI, FIPA)는 LLM 이전에 등장했으며, 컨텍스트 윈도우(context windows), 토큰 예산(token budgets) 또는 MCP 서버와 매핑되지 않습니다. 저는 그 중간 단계, 즉 직렬화(serialize)할 수 있는 정의를 원합니다.

범위: 이 정의는 MCP 호스트 내에 존재하는 에이전트를 위한 정의입니다. LangGraph와 같은 프레임워크는 사물을 다르게 구성하지만, 저는 동일한 구성 요소들이 다른 이름으로 나타난다고 믿습니다.

정의

저는 이 개념을 클래스(class)와 그 인스턴스(instances)처럼 두 부분으로 나누었습니다. 둘 다 MCP 호스트 내에 존재합니다. 여기서부터 **에이전트 정의(agent definition)**는 클래스이며, **에이전트(agent)**는 인스턴스입니다.

에이전트 정의는 다음으로 구성됩니다:

• 호스트 루프 (the host loop) — 핵심 요소입니다. 행동을 결정하고, 결과를 관찰하며, 반복(iterate)하는 LLM입니다. 루프가 없다면 그것은 도구를 사용하는 챗봇(chatbot)일 뿐, 에이전트(agent)가 아닙니다.
• 시스템 컨텍스트 (system context) — 페르소나(persona), 지침(instructions). 정적(static)이며 작성된(authored) 내용입니다.
• MCP 서버 세트 (MCP server set)
• 역량 경계 / 도구 정책 (capability boundary / tool policy) — 이 에이전트가 사용할 수 있는 서버와 도구는 무엇인지, 그리고 무엇에 승인이 필요한지를 정의합니다. 이는 로그인(login)이 아닌 역할(role)입니다.
• LLM — 우리가 실제로 사용 중인 모델
• 종료 제한 (termination limits) — 최대 반복 횟수, 토큰 예산(token budget), 중단 조건(stop conditions)
• 태스크 계약 (task contract) — 이 에이전트가 무엇을 수락하고 무엇을 반환해야 하는지에 대한 스키마(schema)
• 컨텍스트 크기 전략 (context-size strategy) — 압축(compaction) 대 top-x

에이전트는 해당 클래스의 인스턴스(instance)입니다. C# 용어로 표현하면 다음과 같습니다:

record AgentDefinition(
    HostLoop Loop,
    SystemContext Context,
...

• 목표 (goal) — 사용자가 실제로 요청한 것
• 작업 컨텍스트 윈도우 (working context window) — 대화 기록(conversation history), 도구 결과(tool results)
• 자격 증명 (credentials) — 주체(principal): 누구의 OAuth 토큰인지, 누구를 대신하여 수행하는지. 동일한 정의를 가진 두 인스턴스가 서로 다른 두 사용자를 위해 실행될 때, 이 부분에서만 차이가 발생합니다.
• 소비된 예산 (consumed budget) — 경과된 반복 횟수, 사용된 토큰

이 대칭성에 주목하십시오: 정의(definition)는 제한, 계약, 역량을 보유하며, 인스턴스(instance)는 카운터, 목표, 자격 증명을 보유합니다. 클래스에서는 정적(static)이고, 인스턴스에서는 동적(dynamic)입니다.

2026-07-28 스펙의 등장, 더 정확하게는: 상태 비저장 코어 (stateless core)

새로운 MCP 스펙은 프로토콜 세션(protocol sessions)을 완전히 제거합니다. 서버는 더 이상 호출 사이의 사용자를 기억하지 않습니다. 이제 모든 상태(state)는 모델 자체가 볼 수 있는 명시적인 핸들(handles)을 통해 전달됩니다: 장기 실행 작업을 위한 태스크 핸들(task handles), 워크플로우 ID(workflow ids), 그리고 일시 중지된 호출이 반환하는 requestState 블롭(blob) 등이 그것입니다.

이는 위에서 정의한 저의 '작업 컨텍스트 윈도우 (working context window)'를 깨뜨립니다. 이러한 핸들(handles)들이 컨텍스트 윈도우에 들어오게 되면, 압축(compacting) — 또는 더 나쁜 경우, top-x 방식의 처리 — 가 비용(cost)의 문제가 아닌 정확성(correctness)의 문제가 됩니다. 태스크 핸들(task handle)을 요약해 버리면, 에이전트는 다시는 재개할 수 없는 고립된 원격 작업(orphaned remote work)을 갖게 됩니다. 상태가 없는(stateless) 서버에는 에이전트에게 이를 상기시켜 줄 세션(session)이 없기 때문입니다.

따라서 인스턴스(instance)는 다음과 같이 분리되어야 합니다:

• 압축 가능한 컨텍스트 (compressible context) — 대화 기록, 압축해도 안전함
• 부하를 견디는 컨텍스트 (load-bearing context) — 미결 핸들(outstanding handles) 및 요청 상태(request state), 절대 압축하지 않음

호스트 루프(host loop) 또한 자유로운 형식을 벗어나게 됩니다. 이제 다음 사항들을 지원해야 합니다:

• 다회 왕복 일시 중지 (multi-round-trip pause) — 도구 호출(tool call)이 입력 필요(input-required) 상태와 요청 상태(request state)를 반환하면, 루프는 질문을 표면화하고 답변과 함께 호출을 재발행합니다.
• 태스크 폴링 (task polling, tasks/get)
• 결과에 포함되어 들어오는 요청되지 않은 태스크 핸들 (unsolicited task handles)

직렬화 가능한 에이전트 (Serializable Agents)

이 지점이 바로 상태가 없는 코어(stateless core)가 가리키는 방향입니다. 만약 인스턴스 상태가 정확히 {목표(goal), 컨텍스트(context), 핸들(handles), 자격 증명(credentials), 소비된 예산(consumed budget)}이고, 프로토콜이 사용자를 대신하여 숨겨진 세션을 유지하지 않는다면, 에이전트는 하나의 *직렬화 가능한 값 (serializable value)*입니다. 에이전트를 일시 중지하고, 영구 저장하며, 다른 호스트 프로세스에서 재개할 수 있습니다. 계속 살려두어야 하는 실행 중인 프로세스가 아니라, 저장할 수 있는 기록(record)인 것입니다.

실제 운영 환경(production reality)이 이를 따라잡는 데는 시간이 걸리겠지만(연결 재사용, 서버 캐시 등...), 방향은 스펙(spec) 자체에 의해 정해져 있습니다.

이에 대한 피드백을 기다립니다. 특히 MCP 호스트를 운영 환경에서 실행하는 분들께 묻고 싶습니다. 이 정의에서 놓치고 있는 에이전트 설정(agent config) 항목이 무엇인가요?