멀티 에이전트 패턴과 MCP

시험 가이드 v1.1은 도메인 2에 에이전틱 AI 개념을 넣으면서 이름 여섯을 적어 두었습니다 — 멀티 에이전트 패턴, 에이전트끼리의 통신, 메모리 관리, 도구 사용, 워크플로 오케스트레이션, 그리고 MCP입니다. 이 여섯은 따로 떨어진 기술이 아니라 에이전트 하나가 일하는 방식에서 출발해 여럿이 함께 일하는 방식으로 넓어지는 한 줄입니다. 그래서 이 편은 에이전트 하나가 도구를 쓰는 데서 시작합니다.

에이전트와 도구 사용

에이전트

에이전트는 목표를 받으면 스스로 다음 할 일을 정하고, 도구를 불러 결과를 보고, 다시 다음 할 일을 정하는 되풀이를 목표에 닿을 때까지 이어 가는 애플리케이션입니다. 이 되풀이에서 판단은 LLM이 맡고, 실제 행동은 도구가 맡습니다. 한 번 묻고 한 번 답하는 챗봇과 가르는 기준이 이 되풀이입니다.

도구 사용

도구 사용(tool usage)은 모델이 외부 기능을 부르는 방식입니다. 오해하기 쉬운 점이 하나 있습니다 — 모델이 도구를 직접 실행하지 않습니다. 애플리케이션이 도구의 이름·설명·입력 형식을 모델에 알려 주면, 모델은 「이 도구를 이 값으로 불러 달라」는 요청을 답으로 내놓고, 애플리케이션이 그 요청대로 실행해 결과를 다시 모델에 돌려줍니다. Bedrock의 Converse API로는 이렇게 씁니다.

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "amazon.nova-lite-v1:0"  # 리전에 따라 추론 프로파일 ID를 써야 할 수 있다
tool_config = {"tools": [{"toolSpec": {
    "name": "get_order_status",
    "description": "주문 번호로 배송 상태를 조회한다",
    "inputSchema": {"json": {"type": "object",
                             "properties": {"order_id": {"type": "string"}},
                             "required": ["order_id"]}},
}}]}
resp = client.converse(
    modelId=MODEL_ID,
    messages=[{"role": "user", "content": [{"text": "A-1024 주문 어디쯤 왔어?"}]}],
    toolConfig=tool_config,
)
if resp["stopReason"] == "tool_use":
    for block in resp["output"]["message"]["content"]:
        if "toolUse" in block:
            print(block["toolUse"]["name"], block["toolUse"]["input"])

stopReason이 tool_use이면 모델이 도구를 불러 달라는 뜻이고, 애플리케이션은 실행 결과를 toolResult 블록에 담아 다음 호출에 넣습니다. 앞 편에서 본 대로 도구 설명은 호출마다 컨텍스트에 실리므로, 설명은 모델이 언제 쓸지 알 만큼 분명하되 길 필요는 없습니다.

멀티 에이전트 패턴

나누는 이유

에이전트 하나에 도구 서른 개와 긴 지시를 몰아 주면 도구 설명이 컨텍스트를 채우고 어느 도구를 써야 할지 헷갈리기 시작합니다. 멀티 에이전트 시스템은 일을 역할별로 쪼개 에이전트마다 좁은 지시와 몇 개의 도구만 주는 구성입니다. 에이전트마다 따로 시험하고 고칠 수 있다는 점도 이점입니다. 대신 에이전트가 늘수록 모델 호출이 늘어 비용과 지연이 커지므로, 한 에이전트로 되는 일을 굳이 나누는 것은 답이 아닙니다.

감독자 패턴

가장 흔한 모양은 감독자(supervisor) 에이전트 하나가 요청을 받아 쪼개고, 전문 에이전트들에게 나눠 맡긴 뒤 결과를 모아 답하는 구성입니다. Amazon Bedrock Agents의 멀티 에이전트 협업이 이 모양이고, 감독자가 요청을 그대로 알맞은 협업 에이전트 하나에 넘기기만 하는 라우팅 방식도 고를 수 있습니다. 여행 예약이라면 감독자 아래에 항공·숙소·결제 에이전트가 섭니다.

그 밖의 모양

에이전트 사이의 통신

도구로 부르기

한 에이전트가 다른 에이전트를 도구처럼 부르는 방식입니다. 부르는 쪽은 질문을 넘기고 결과만 받으며, 불린 쪽의 중간 과정은 보지 않습니다. 감독자 패턴이 대개 이 방식으로 이어집니다. 오픈소스 SDK인 Strands Agents로 쓰면 에이전트를 감싼 함수를 도구로 등록하는 모양이 됩니다.

from strands import Agent, tool

@tool
def refund_policy_agent(question: str) -> str:
    """환불·반품 규정에 관한 질문에 답한다."""
    agent = Agent(system_prompt="너는 환불 규정 담당이다. 규정 문서에 있는 것만 답한다.")
    return str(agent(question))

supervisor = Agent(
    system_prompt="고객 문의를 읽고 알맞은 담당 에이전트에게 넘긴 뒤 답을 정리한다.",
    tools=[refund_policy_agent],
)
supervisor("지난주에 산 신발을 반품할 수 있나요?")

넘기기와 공유 상태

넘기기(handoff)는 일의 주도권 자체를 다른 에이전트에 옮기는 방식입니다. 상담 에이전트가 결제 문제를 만나면 결제 에이전트가 대화를 이어받습니다. 공유 상태는 에이전트들이 같은 저장소에 쓰고 읽으며 서로의 결과를 보는 방식으로, 병렬 패턴에서 각자 조사한 내용을 한곳에 모을 때 씁니다. 문항은 「중간 과정 없이 결과만 필요하다」면 도구로 부르기, 「대화를 통째로 맡긴다」면 넘기기를 고르게 합니다.

메모리와 오케스트레이션

메모리 관리

모델은 호출 사이에 아무것도 기억하지 않으므로 기억은 애플리케이션이 따로 관리합니다. 단기 메모리는 한 세션 안의 대화와 중간 결과이고, 장기 메모리는 세션을 넘어 남는 사용자 선호·과거 결정·요약된 사실입니다. 장기 메모리를 매번 전부 싣지 않고 이번 요청에 관련된 것만 찾아 넣는 것이 앞 편 컨텍스트 엔지니어링의 선별입니다. Amazon Bedrock AgentCore Memory가 이 두 층을 관리형으로 제공합니다.

워크플로 오케스트레이션

워크플로 오케스트레이션은 여러 단계와 에이전트를 어떤 차례로, 어떤 조건에서 실행할지 정하고 실패했을 때 어떻게 할지까지 관리하는 일입니다. 차례를 사람이 미리 그려 두는 방식과 모델이 그때그때 정하는 방식이 있습니다. 규정상 반드시 승인 단계를 거쳐야 하거나 결과를 매번 똑같이 재현해야 하면 앞쪽이 맞고, AWS Step Functions나 Amazon Bedrock Flows로 흐름을 고정합니다. 다음 할 일을 미리 알 수 없는 조사·문제 해결에는 뒤쪽이 맞습니다.

MCP

잇는 방식

MCP(Model Context Protocol)는 에이전트가 외부 시스템의 도구와 데이터에 닿는 방식을 하나로 맞춘 공개 표준입니다. 에이전트 쪽 프로그램을 호스트, 그 안에서 연결을 맡는 부분을 클라이언트, 외부 시스템을 감싸 기능을 내놓는 쪽을 서버라 부릅니다. 서버가 내놓는 것은 부를 수 있는 도구, 읽을 수 있는 리소스, 미리 짠 프롬프트 셋입니다. 클라이언트는 먼저 도구 목록을 묻고, 모델이 도구를 고르면 그 도구를 부릅니다. 메시지는 JSON-RPC 형식이고, 같은 컴퓨터 안에서는 표준 입출력으로, 원격이면 HTTP로 주고받습니다.

{"jsonrpc": "2.0", "id": 2, "method": "tools/call",
 "params": {"name": "get_order_status", "arguments": {"order_id": "A-1024"}}}

앞 절의 도구 사용과 겹쳐 보이지만 층이 다릅니다. 도구 사용은 모델과 애플리케이션 사이의 약속이고, MCP는 애플리케이션과 외부 시스템 사이의 약속입니다.

연결 수

MCP가 푸는 문제는 연결의 수입니다. 에이전트 애플리케이션이 N개, 붙일 시스템이 M개일 때 저마다 전용 연결을 만들면 N × M개가 필요합니다. 모두가 MCP를 따르면 애플리케이션마다 클라이언트 하나, 시스템마다 서버 하나로 N + M개면 됩니다. 애플리케이션 4개와 시스템 6개라면 24개가 10개로 줄어듭니다. Amazon Bedrock AgentCore Gateway는 기존 API나 AWS Lambda 함수를 MCP 도구로 바꿔 내놓는 자리이고, Strands Agents는 MCP 서버의 도구를 그대로 받아 쓸 수 있습니다.

연습 문제

1. 에이전트 애플리케이션 5개가 사내 시스템 8개에 붙어야 합니다. 저마다 전용 연결을 만들 때와 모두 MCP를 따를 때 필요한 연결 수는 각각 몇 개입니까?
   ① 13개와 40개
   ② 40개와 13개
   ③ 40개와 8개
   ④ 13개와 5개

   ②. 전용 연결은 $5 \times 8 = 40$ 개, MCP는 클라이언트 5개와 서버 8개로 $5 + 8 = 13$ 개입니다.
2. Converse API로 도구를 정의해 모델을 불렀더니 stopReason이 tool_use로 돌아왔습니다. 다음에 일어나는 일을 순서대로 배열하시오.
   (가) 애플리케이션이 요청받은 도구를 실제로 실행한다
   (나) 응답에서 도구 이름과 입력값을 꺼낸다
   (다) 모델이 결과를 읽고 사용자에게 줄 답을 쓴다
   (라) 실행 결과를 toolResult에 담아 모델을 다시 부른다

   (나) → (가) → (라) → (다). 도구를 실행하는 것은 모델이 아니라 애플리케이션입니다.
3. MCP에 대한 설명으로 옳은 것을 둘 고르시오.
   ① 에이전트가 외부 시스템의 도구와 데이터에 닿는 방식을 맞춘 공개 표준이다
   ② 모델의 가중치를 외부 시스템과 주고받는 형식이다
   ③ 서버는 도구·리소스·프롬프트를 내놓는다
   ④ AWS 안에서만 쓸 수 있는 전용 프로토콜이다
   ⑤ 모델이 도구를 직접 실행하게 해 애플리케이션을 없앤다

   ①과 ③. MCP는 특정 회사 전용이 아니고, 가중치가 아니라 도구와 데이터 접근을 다루며, 실행은 여전히 애플리케이션 쪽 클라이언트와 서버가 맡습니다.
4. 대출 심사 흐름은 규정상 서류 확인 → 신용 평가 → 담당자 승인 차례를 반드시 지켜야 하고, 같은 입력이면 같은 경로를 밟아야 합니다. 알맞은 오케스트레이션은?
   ① 감독자 에이전트가 매번 다음 단계를 자유롭게 정한다
   ② 차례를 미리 정해 둔 워크플로로 고정한다
   ③ 동료 에이전트들이 중앙 없이 일을 넘긴다
   ④ 에이전트 하나에 모든 도구를 주고 알아서 하게 한다

   ②. 차례와 재현성이 요구되면 사람이 미리 그린 흐름이 맞습니다. Step Functions나 Bedrock Flows가 그 자리입니다.
5. 설명과 용어를 짝지으시오.
   (가) 한 세션 안의 대화와 중간 결과
   (나) 세션을 넘어 남는 사용자 선호와 과거 결정
   (다) 일의 주도권을 다른 에이전트에 통째로 옮김
   (라) 다른 에이전트를 부르고 결과만 받음
   ⓐ 넘기기 ⓑ 장기 메모리 ⓒ 도구로 부르기 ⓓ 단기 메모리

   (가)-ⓓ, (나)-ⓑ, (다)-ⓐ, (라)-ⓒ.
6. 고객 지원 에이전트 하나에 도구 35개를 줬더니 엉뚱한 도구를 고르는 일이 잦고 입력 토큰도 많이 듭니다. 가장 알맞은 개선은?
   ① 도구 설명을 모두 지운다
   ② 감독자 아래 주문·결제·배송 에이전트를 두고 각자에게 관련 도구만 준다
   ③ 도구를 70개로 늘린다
   ④ 대화 이력을 전부 싣는다

   ②. 멀티 에이전트로 나누면 에이전트마다 도구가 줄어 고르기가 쉬워지고 호출마다 실리는 도구 설명도 줄어듭니다.

여섯 문항이 겨누는 것은 셋입니다. 도구를 실행하는 주체가 모델이 아니라는 것, 패턴과 통신 방식을 상황에 맞춰 고르는 것, 그리고 MCP가 어느 층의 약속인지입니다. 보기에 「모델이 직접」이 나오면 한 번 멈추고 읽으면 됩니다.