혼자에서 팀으로 — 멀티 에이전트 대출 처리 실습

Hierarchical agent architectures

위계형 아키텍처 — 회사의 팀을 닮은 구조

멀티 에이전트 시스템은 분산 스웜이나 P2P 네트워크 등 여러 위상으로 조직할 수 있다. 그것들은 열린 결말의 창의적 과업에 어울린다. 그러나 규제받는 기업 워크플로는 더 엄격한 통제를 요구한다. 감사 가능성과 정해진 단계의 준수가 협상 불가한 대출 처리 파이프라인에는 위계형 아키텍처, 곧 감독자·오케스트레이터 패턴이 가장 효과적이다.

이 패턴은 에이전트를 회사의 팀을 닮은 구조로 조직한다. 관리자 하나가 전문가 무리를 감독한다. 단일체 에이전트가 모든 것을 하려 드는 대신, 책임이 분명히 나뉜 시스템을 만드는 것이다.

〈그림 14.1〉 위계형 에이전트 아키텍처의 단순 모델

Role 01 · Parent

감독자 에이전트

관리자 노릇을 한다. 전체 워크플로를 계획하고, 적절한 전문가에게 하위 과업을 위임하고, 진행을 감시하고, 전문가들의 발견에서 최종 결과를 종합한다.

Role 02 · Sub-agent

전문 에이전트

개별 전문가다. 서류 검증이나 위험 점수 계산처럼 한 가지를 탁월하게 하도록 설계된다. 과업을 받아 전용 도구로 실행하고 결과를 감독자에게 돌려준다.

이 구조를 가능하게 하는 세 패턴

Pattern 01

에이전트가 에이전트에 위임한다

핵심 패턴이다. 감독자는 일을 직접 하지 않고 다른 자율 에이전트에 위임한다. ADK의 AgentTool 클래스가 그 직접 구현이다. 자기 LLM·지시·도구를 온전히 갖춘 독립 에이전트를 표준 도구 인터페이스 뒤에 캡슐화해, 감독자가 일반 함수처럼 동기적으로 호출하게 한다. 다만 중첩된 지연과 토큰 비용이라는 대가가 따른다.

Pattern 02

내결함성과 격리

워크플로를 독립 에이전트로 쪼갬으로써 실패를 고립시킨다. CreditCheckAgent가 실패해도 시스템 전체가 죽지 않는다. 감독자가 오류를 잡아 절차를 중단하거나 사람에게 에스컬레이션하는 행동 방침을 결정할 수 있다. 단일체 설계에 비하면 유의미한 개선이다.

Pattern 03

모듈성

각 전문 에이전트는 자족적인 전문성 모듈이다. RiskAssessmentAgent를 시스템의 다른 어떤 부분도 건드리지 않고 갱신하고 개선하고 심지어 교체할 수 있다. 훨씬 유지보수하기 쉽고 확장 가능한 아키텍처가 된다.

단일체와 멀티 에이전트의 대비

Chapter 13 · Monolithic

하나의 복잡한 실체

거대한 단일 FCoT 프롬프트에 모든 업무 로직이 담긴다
하나의 추론 루프에 전 과정이 걸려 있다
에이전트 자신이 서류·신용·위험·준수의 제너럴리스트여야 한다
한 부분의 작은 논리 오류가 워크플로 전체에 의도치 않은 결과를 낳는다

Chapter 14 · Multi-agent

단순하고 상호운용 가능한 부품들

각 전문가가 짧고 집중된 지시를 갖는다
실패가 전문가 안에 봉쇄되고 감독자가 우아하게 처리한다
각자 한 가지를 탁월하게 한다
위험 평가 로직을 신용 조회에 아무 영향 없이 갱신할 수 있다

〈그림 14.2〉 단일체와 멀티 에이전트 아키텍처의 대비

Building the multi-agent system

전문가 팀을 짓는다 — 도구에서 에이전트로

이제 노트북을 리팩터링한다. 진짜로 전문화된 에이전트들을 만드는 작업이며, 각각이 자기 모델과 자기 지시와 단 하나의 전용 도구를 갖는다.

document_validator

들어온 대출 신청 서류의 파싱을 흉내 낸다. JSON 구조가 유효하고 필수 필드가 모두 존재하는지 확인한다.

validate_document_fields

credit_checker

외부 데이터로 가는 인터페이스 노릇을 한다. 주어진 고객 ID의 신용점수를 가져온다.

query_credit_bureau_api

risk_assessor

대출 금액·소득·신용점수를 종합해 위험 점수를 산출한다.

calculate_risk_score

compliance_checker

신용 이력과 위험 점수를 받아 대출 정책 준수 여부를 판정한다.

check_lending_compliance

각 함수는 이제 자기 과업에 필요한 정확한 업무 로직을 담는다. “불행한 경로” 시나리오를 위한 구체적 규칙도 여기 들어간다. 예컨대 신용점수 600 미만은 즉시 고위험 실패 조건으로 표시하는 식이다.

Production note · 엄격한 스키마

예제는 단순함을 위해 표준 파이썬 타입 힌트를 쓰지만, 운영 등급 시스템은 엄격한 입출력 스키마를 강제해야 한다. Pydantic 같은 라이브러리로 에이전트 사이의 데이터 무결성을 보장하라.

전문가를 AgentTool로 감싼다

각 전문가는 이제 독립된 LlmAgent 인스턴스다. 모델과, 고도로 집중된 지시 집합과, 단 하나의 전용 도구를 갖는다. 지시는 훨씬 단순해졌다. 자기 도구를 쓰라는 것과 특정 입력을 기대하라는 것뿐이다. 이것이 에이전트 사이에 명확한 “데이터 계약”을 강제한다.

그리고 가장 결정적인 단계가 남았다. 각 전문 에이전트를 AgentTool로 감싸는 것이다. 이것이 어댑터 노릇을 해 한 에이전트를 다른 에이전트가 호출할 수 있게 만들고, 「에이전트가 에이전트에 위임한다」 패턴을 실현한다.

A production strategy

이종 모델 선택이 열린다

결합이 끊기면서 워크플로 전체를 하나의 모델에 묶을 필요가 사라진다. 빠른 추출이 필요한 document_validator에는 가볍고 저지연인 모델(예: Gemini Flash)을, 미묘한 정책 해석을 다루는 compliance_checker에는 더 유능한 추론 모델(예: Gemini Pro)을 배정할 수 있다.

다만 모델을 섞으면 행동에 미묘한 변이가 생길 수 있다. 여기서처럼 엄격한 FunctionTool 정의에 기대는 것이 다양한 에이전트 팀에서 일관성을 지키는 최선의 방법이다.

구현 예시 · 전문가 팀과 AgentTool

from google.adk.agents.llm_agent import LlmAgent
from google.adk.tools import FunctionTool, AgentTool
import json

# --- 1. 도구가 될 파이썬 함수를 정의한다 ---
def validate_document_fields(application_data: str) -> str: ...
def query_credit_bureau_api(customer_id: str) -> str: ...
def calculate_risk_score(loan_amount: int, income: str, credit_score: int) -> str: ...
def check_lending_compliance(credit_history: str, risk_score: int) -> str: ...

# --- 2. 함수를 ADK FunctionTool로 감싼다 ---
validation_tool = FunctionTool(func=validate_document_fields)
credit_tool     = FunctionTool(func=query_credit_bureau_api)
risk_tool       = FunctionTool(func=calculate_risk_score)
compliance_tool = FunctionTool(func=check_lending_compliance)

# --- 3. 전문가 에이전트를 만든다 (각자 모델·지시·전용 도구) ---
document_validation_agent = LlmAgent(
    name="document_validator",
    # model=..., instruction=..., tools=[validation_tool]
)

# --- 4. 가장 결정적인 단계: AgentTool로 감싼다 ---
#     자율 하위 에이전트를 오케스트레이터가 호출 가능한 도구로 바꾼다
validator_agent_tool          = AgentTool(agent=document_validation_agent)
credit_checker_agent_tool     = AgentTool(agent=credit_check_agent)
risk_assessor_agent_tool      = AgentTool(agent=risk_assessment_agent)
compliance_checker_agent_tool = AgentTool(agent=compliance_agent)

운영 가드레일 — 실제 환경의 소음을 견딘다

아키텍처가 에이전트끼리 어떻게 말하는가를 정의한다면, 운영 등급 시스템은 실제 환경의 소음도 감당해야 한다. 그래서 실행 로직을 견고한 러너로 감싼다.

속도 제한

@limits 데코레이터로 요청을 선제적으로 조절해 제공자의 할당량 안에 머문다(예: 분당 15회).

지수 백오프

tenacity 라이브러리를 써서 RESOURCE_EXHAUSTED (429) 오류를 만나면 지능적으로 재시도한다. 대출 신청을 실패시키는 대신, 간격을 늘려가며 기다렸다 다시 시도한다.

사고 예산

ThinkingConfig에 thinking_budget을 설정한다. 오케스트레이터가 내부 추론에 더 많은 연산 주기를 쓸 수 있게 해, 하위 에이전트가 반환하는 중첩된 JSON을 파싱하는 데 결정적이다.

구현 예시 · 견고한 러너

# 1. 사고 예산 설정
ThinkingConfig(
    include_thoughts=True,
    thinking_budget=1024
)

# 2. 재시도와 조절을 갖춘 견고한 러너
@sleep_and_retry
@limits(calls=15, period=60)
@retry(
    stop=stop_after_attempt(5),
    wait=wait_exponential(multiplier=2, min=4, max=30),
    retry=retry_if_exception(is_rate_limit_error)
)
def start_agent_run(runner, user_id, session_id, content):
    return runner.run(user_id=user_id, session_id=session_id,
                      new_message=content)

Revising the orchestrator's mind

실행자에서 관리자로 — 오케스트레이터의 사고를 고쳐 쓴다

주 에이전트의 역할이 이제 실행자(doer)에서 관리자(manager)로 옮겨간다.

Architectural note · 맥락적 상태 관리

단계 사이에 구조화된 파이썬 딕셔너리(예: state = {'id': 123})를 넘기는 워크플로 엔진과 달리, 우리 오케스트레이터는 맥락적 상태에 기댄다. 여기서 “상태”란 전문 에이전트들이 낸 JSON 출력의 누적된 이력이다.

예컨대 서류 검증기가 {"status": "valid", "extracted_data": {"customer_id": "CUST-123", "income": "5000"}}를 반환하면, 오케스트레이터는 이것을 자기 컨텍스트 창에서 읽어 다음 위임 호출의 페이로드를 동적으로 구성한다. credit_checker_tool(customer_id="CUST-123")

그래서 오케스트레이터는 어느 필드를 추출해 넘길지 명시적으로 지시받아야 하며, 사실상 의미적 데이터 매퍼 노릇을 한다.

주 에이전트의 FCoT 프롬프트를 이에 맞춰 갱신한다. 도구 목록 대신 이제 전문가 팀을 가리킨다. 그리고 프롬프트는 오케스트레이터에게 한 에이전트에서 다음 에이전트로 올바른 데이터 맥락을 넘길 책임을 명시적으로 지운다. 마지막 디버깅 세션에서 확인한 “맥락 유실” 문제를 푸는 대목이다.

구현 예시 · 오케스트레이터 지시

orchestrator_instructions = """
당신은 전문 에이전트 팀을 관리하는 FCoT 기반 오케스트레이터 에이전트다…
당신의 일차적 역할은 워크플로를 계획하고, 과업을 위임하고,
예외를 지능적으로 처리하는 것이다.

**실패 처리 정책(Failure Handling Policy):**
  1. **Reflect** — 전문 에이전트가 오류를 반환하면, 먼저 오류 메시지를 분석한다.
  2. **Resolve** — 정보 누락으로 인한 오류라면 원래 요청을 다시 살핀다…
  3. **Escalate** — 스스로 해결할 수 없을 때에만 에스컬레이션한다…

**당신의 전문가 팀(위임 가능한 에이전트):**
  * `document_validator` — … 검증된 데이터를 반환한다.
  * `credit_checker`     — … 검증된 데이터에서 `customer_id`를 넘겨야 한다.
  * `risk_assessor`      — … `loan_amount`, `income`, `credit_score`를 넘겨야 한다.
  * `compliance_checker` — … `credit_history`와 `risk_score`를 함께 넘겨야 한다.
"""

이 지시가 감독자의 운영 원칙을 정의한다. 실패 처리 정책과 엄격한 입력 요구사항을 명시한 전문가 명부를 분명히 규정함으로써, 오케스트레이터가 모든 단계를 스스로 실행하려 들지 않고 워크플로를 관리하도록 보장한다.

Execution and analysis

실행과 분석 — 관리자의 사고를 들여다본다

call_agent 함수가 에이전트의 마음으로 난 창 노릇을 한다. 실행 루프에서 생성되는 원시 이벤트 — 생각, 도구 호출, 출력 — 을 걸러 보여줌으로써 관찰 가능성 패턴을 구현한다.

결정적으로 이 함수는 출력을 파싱해 생각(FCoT 지시가 이끄는 내부 독백)과 도구 호출(취해진 행동)을 분리한다. 이 세밀한 로깅이 있어야 오케스트레이터가 우리가 설계한 패턴대로 계획하고 위임하는지 검증할 수 있다.

Scenario 1 · Happy path

CUST-12345 — 승인

자격을 잘 갖춘 신청인의 유효한 신청서를 준다. 목표는 멀티 에이전트 협업의 완벽하고 끊김 없는 흐름과 오케스트레이터의 추론을 관찰하는 것이다.

>>>> USER REQUEST "customer_id": "CUST-12345" "income": "USD 5000 a month" "loan_amount": 50000 "credit_history": "Very Solid" "loan_documents": [4건] 🧠 THOUGHT (Iteration 1: Planning) RECAP: 대출 신청을 받았다… 고객 ID, 소득, 요청 금액, 신용 이력을 모두 확인했다. 내 전문 에이전트 팀이 각 단계를 처리하도록 준비돼 있다… REASON: 첫 에이전트인 document_validator는 전체 신청 데이터를 단일 JSON 문자열로 요구한다… 검증되면 고객 ID를 추출해 credit_checker에 넘긴다… 그다음 그 점수와 대출 금액·소득을 risk_assessor에… 마지막으로 위험 점수와 원래 신용 이력을 compliance_checker가 분석한다… VERIFY: 각 에이전트의 입력이 기대되는 데이터 계약과 일치함을 확인했다. 이제 계획을 실행할 시간이다… 🛠 TOOL CALL: document_validator(...) ↩ TOOL OUTPUT: {"status": "validated", ...} 🧠 THOUGHT (Iteration 2: Synthesis) REASON: 서류 검증은 깔끔한 통과… 신용 조회는 견고한 점수 810… 위험 평가는 위험 점수 6으로 허용 범위 안… 준수 점검? 청신호다. VERIFY: 최종 요약과 권고를 낼 모든 것을 갖췄다. ✅ FINAL RESPONSE: Loan Decision — Approved

Scenario 2 · Denied path

CUST-55555 — 거절

시스템이 결정적 업무 규칙을 관찰하고 조정하고 집행하는 능력을 시험한다. 흔히 정책 준수라 부른다. 부정적이되 예상된 결과 앞에서의 추론이 견고성의 핵심 시험이다.

>>>> USER REQUEST "customer_id": "CUST-55555" "income": "USD 1000 a month" "loan_amount": 1000000 "credit_history": "Presenting Gaps" "loan_documents": ["drivers_license.pdf"] 🧠 THOUGHT (Iteration 1: Planning) RECAP: 고객 ID "CUST-55555", 월 소득 1,000달러, 무려 1,000,000의 대출 금액… REASON: 전체 신청 데이터를 document_validator에 넣는 것으로 시작한다… 다음 customer_id를 추출해 credit_checker에 넘기고… 이런 식으로. VERIFY: 데이터 의존성은 견고하다. … (검증기·신용조회·위험평가 호출이 차례로 성공) … ↩ TOOL OUTPUT from risk_assessor: {"risk_score": 8} ↩ TOOL OUTPUT from compliance_checker: {"is_compliant": false, "reason": "Policy violation: Risk score of 8 is too high for approval."} 🧠 THOUGHT (Iteration 2: Synthesis) REASON: 먼저 서류는 좋아 보였다… 신용 조회는 점수 680… 그런데 위험 평가가 뭔가를 표시했다. 위험 점수 8이 돌아왔다. 좀 높고, 바로 거기가 문제다. 준수 점검이 즉시 표시했다. 위험 점수 8은 정책 위반이다. 명백한 정책 위반. 그것이 결론이다. VERIFY: 거절의 주된 이유는 위험 점수 8이며, 내부 정책상 승인 가능한 임계를 초과한다. ✅ FINAL RESPONSE: Rejected — 정책 위반

이 로그가 보여주는 것

Consistency

일관된 계획

오케스트레이터의 초기 FCoT 계획 루프가 행복 경로와 완전히 동일하다. 신청서 내용과 무관하게 RECAP–REASON–VERIFY의 같은 엄정한 절차를 따른다. 절차적 일관성이 곧 시스템의 신뢰성이다.

Synthesis

모순된 증거의 종합

이 로그에서 가장 통찰적인 대목은 마지막 생각이다. 앞의 몇 단계는 성공했는데(서류 양호, 점수 680) 마지막 단계는 확고한 실패였다. 에이전트는 준수 실패가 가장 중요하고 결정적인 요인이라고 올바로 추론한다.

The capability

증거를 저울질하고 우선순위를 매긴다

초기의 성공들보다 결정적 실패 하나를 올바로 앞세우는 능력은 정교한 추론 역량이다. FCoT 틀이 그 분석을 안정적으로 수행할 구조를 제공한다. 워크플로를 실행할 뿐 아니라, 결과에 근거해 건전하고 감사 가능한 판단을 내리는 에이전트를 지을 수 있음을 보여준다.

Examining the patterns in practice

패턴의 실제 — 에이전트의 독백을 안내자 삼아

우리의 멀티 에이전트 대출 처리기는 에이전트 하나를 돌리는 코드 조각이 아니다. 여러 패턴이 한데 모여 업무와 도메인의 필요를 반영하는 지능을 갖추고, 엄정한 평가로 검증되고, 안전 가드레일로 보호되는 동적 에이전틱 생태계다. 그 결과는 부분의 합보다 훨씬 크다.

Pattern 01

감독자 구조 — AI 오케스트레이터 또는 메타 에이전트

전체 시스템의 마스터 청사진이다. 명확한 통제 위계를 세움으로써 압도적 복잡성을 관리하는 문제를 다룬다. 모든 것에 정통해야 하는 단일체 에이전트 대신 “관리자와 팀” 구조를 주장한다.

감독자의 역할은 과업을 수행하는 것이 아니라, 상위 목표를 이해하고 논리적 단계로 쪼개고 적절한 전문가에게 위임하고 그들의 발견을 하나의 일관된 결과로 종합하는 것이다.

우리 사례에서 오케스트레이터는 전형적인 감독자다. 그 FCoT 프롬프트에는 서류 검증이나 위험 평가를 위한 업무 로직이 전혀 없다. 인지 과정 전체가 워크플로 관리에 바쳐진다.

“거절 경로”의 마지막 생각에서 이 패턴이 선명하다. 모든 전문가의 보고를 받은 뒤 그 추론은 순수하게 관리자적이다. 위험을 직접 계산하거나 준수를 직접 점검하지 않는다. 팀의 보고를 받아 해석하고 우선순위를 매겨 최종 결정을 내린다. 이 관심사의 분리가 감독자 패턴의 핵심 이익이다.

또 다른 예 — 자동화된 공급망 관리
감독자 에이전트가 전체 재고 수준을 감시한다. 특정 제품의 재고 부족을 감지하면 SupplierContactAgent에 가용성 확인을, LogisticsAgent에 배송 비용과 시간 계산을, PurchaseOrderAgent에 발주서 작성과 제출을 위임한다. 어느 단계의 세부도 직접 관리하지 않으면서 조달 과정 전체를 조율한다.

Pattern 02

에이전트가 에이전트에 위임한다

감독자 구조를 실현하는 일차 기제다. 한 에이전트가 다른 자율 에이전트의 역량을 호출하는 표준적 방법을 제공한다.

이것이 작동하려면 호출하는 에이전트가 상대가 어떻게 작동하는지 알 필요가 없다. 상대가 무엇을 하는지와 어떤 입력을 요구하는지만 알면 된다. 모듈적이고 상호운용 가능한 에이전틱 시스템을 만드는 강력한 추상화다.

우리는 ADK의 AgentTool로 이 패턴을 직접 구현했다. 각 전문가를 AgentTool로 감싸 오케스트레이터가 도구벨트의 다른 도구처럼 다룰 수 있는 호출 가능한 부품으로 만들었다.

이 캡슐화가 열쇠다. 전문가의 지시, 전용 파이썬 도구, 쓰는 LLM까지 모든 복잡한 로직이 전문 에이전트 자신 안에 완전히 담긴다. 덕분에 오케스트레이터를 전혀 수정하지 않고 전문 에이전트를 개발하고 시험하고 심지어 교체할 수 있다.

또 다른 예 — 스마트홈
중앙 HomeManager 에이전트가 “영화 시간”이라는 명령을 받으면, LightingAgent에 조명을 낮추도록, BlindsAgent에 블라인드를 내리도록, MediaAgent에 TV와 음향을 켜도록 위임한다. 모두 이 패턴을 통해서다.

Pattern 03

FCoT — 감독자의 인지 운영체제

감독자의 마음을 다스리는 패턴이며 인지 운영체제 노릇을 한다. 에이전트의 추론이 의도적이고 감사 가능하며 핵심 지시와 정렬되도록 보장하는 결정적 과제를 다루고, 복잡한 다단계 과업에서 “목표 표류”를 막는다.

계획과 최종 답 종합 양쪽 모두에 대해 적응적이고 재귀적인 RECAP → REASON → VERIFY 루프를 강제함으로써 그것을 이룬다. 그리고 맥락 조리개를 좁혀 가면서 각 반복을 이중 목적함수로 최적화한다.

이 구조화된 추론이 우리 오케스트레이터를 믿을 만한 관리자로 만든다. 충동적으로 행동하지 않는다. 작동의 모든 주요 국면이 구조화된 성찰과 자기교정의 순간으로 시작한다.

“거절 경로”에서 FCoT의 종합 루프는 결정적이었다. 모순된 증거(성공한 초기 단계 대 마지막 준수 실패)를 저울질해, 정책 위반이 결정적 요인이라고 올바르게 추론하게 했다.

또 다른 예 — 논문 요약 연구 에이전트
과학 논문을 요약하는 과업을 받은 에이전트도 같은 FCoT 계획 루프를 밟는다. 이것은 단순한 계획이 아니라 구조화되고 자기 비평된 전략이며, 이후 행동에 높은 확신을 주고 행동을 예측 가능하게, 감사 추적을 명료하게 만든다.

Mapping to the Agentic AI Levels

성숙도 매핑 — 실행자에서 관리자로

두 장에 걸친 이 사례는 에이전틱 AI 성숙도의 높은 단계들을 지나는 여정을 명확하고 실무적으로 보여준다. 각 단계가 무엇인지뿐 아니라 왜 그 진행이 기업의 성공에 그토록 결정적인지까지 드러낸다.

Previous chapter

유능하지만 부서지기 쉬운 단일체

신용을 조회하고 위험을 평가하고 준수를 보장하며 실질적 사업 가치를 낸다.

그러나 모든 인지 부하와 업무 로직과 워크플로 통제가 거대한 단일 프롬프트에 집중돼 있다. 이 중앙화가 시스템을 본질적으로 부서지기 쉽게 만든다. 프롬프트 한 부분의 작은 논리 오류가 워크플로 전체에 의도치 않은 결과를 낳는다. 업무 프로세스가 진화할수록 이 복잡한 “뇌” 하나를 유지·갱신하는 일이 점점 어렵고 위험해져 장기적 확장성을 제한한다.

This chapter

회복력 있는 협업 팀

이 도약은 단지 에이전트를 더 붙이는 일이 아니다. 문제 분해라는 원칙을 중심에 둔 근본적 아키텍처 전환이다.

하나의 복잡한 문제를 더 작고 단순한 과업의 연쇄로 쪼갰고, 각자 한 가지만 탁월하게 하도록 설계된 고도로 전문화된 전문가 팀을 지었다. 뛰어난 제너럴리스트 하나에서 조율된 전문가 팀으로 옮겨가는 에이전틱 등가물이다.

이 아키텍처적 진화가 진정한 기업 등급 역량을 연다. 시스템은 극적으로 더 회복력 있게 된다. 전문 에이전트 하나의 실패가 고립되어 감독자가 우아하게 처리할 수 있고, 전체 절차를 무너뜨리지 않는다.

더 유지보수 가능해진다. 위험 평가의 업무 로직을 신용 조회 절차에 아무 위험도 주지 않고 전용 에이전트 안에서 갱신할 수 있다.

무엇보다 더 확장 가능해진다. 기술적 의미에서만이 아니라 인지적 의미에서 그렇다. 인지 부하를 분산함으로써 훨씬 높은 차원의 복잡성을 가진 문제를 다룰 수 있고, 어떤 단일 에이전트도 홀로 이룰 수 없는 시스템을 짓게 된다.

The defining characteristic

실행자에서 전문 인력의 관리자로

이 전환이야말로 이 단계를 규정하는 특징이며, 우리가 밟아 온 에이전틱 성숙도의 정점이다.

그 너머 — 에이전틱 협업의 미래

Emergent swarms

창발적 스웜

고정된 감독자가 없다. 전문 에이전트들의 집합이 복잡하고 새로운 문제를 받아 자율적으로 임시 팀을 구성해 푼다. 복잡한 기업 대출 구조조정 시나리오라면, 계획 에이전트가 일시적으로 주도권을 잡고 현금흐름 예측을 모델링할 데이터 분석 에이전트와 법적 위험을 요약할 보고 에이전트를 영입해 임시 위계를 이루고, 구조조정 계획이 끝나면 그 위계는 해체된다.

Self-improving systems

자기개선 시스템

대출 처리기가 신청을 처리할 뿐 아니라 자기 성능을 분석한다. risk_assessor 전문가가 잦은 병목임을 알아내 개선을 제안하거나, 심지어 더 효율적인 도구 코드를 스스로 다시 쓰려 시도할 수 있다. 정확도와 비용을 최적화하려 여러 프롬프트 판본으로 스스로 A/B 테스트를 돌릴 수도 있다.

A2A · 상호운용의 공인 표준

이 미래 단계들은 유동적이고 신뢰할 만한 상호작용을 가능하게 할 업계 표준 통신 프로토콜에 기댈 것이다. A2A(Agent-to-Agent) 프로토콜은 이제 리눅스 재단의 공식 프로젝트로서 이 상호운용성의 공인 표준을 제공한다. 범산업 운영위원회가 관장하며, 기반 프레임워크와 무관하게 에이전트가 서로를 발견하고 협상하고 협업하게 한다.

이 형식적 표준화가 에이전트들이 서로를 발견하고 영입하고 협업해 문제를 푸는 진정한 “에이전트 경제”를 가능하게 할 것이다. 우리가 이제 겨우 상상하기 시작한 규모에서 말이다.