MCP는 당신의 에이전트에게 도구를 제공합니다. Pilot Protocol은 당신의 에이전트에게 동료를 제공합니다. 왜 두 가지가 모두 필요한지 여기 있습니다.

발행: 2일 전 (2026년 5월 9일 AM 09:11 GMT+9)

14 분 소요

Source: Dev.to

The Conversation Is Framed Wrong

People keep asking whether MCP, Pilot Protocol, or A2A is the standard.
Which one “wins”? Which one should we build on? As if picking one means the others disappear.

I’ve been running production agent systems for about eight months and I use all three—not because I couldn’t choose, but because they solve completely different problems and sit on different layers of the stack.

Below is how I actually think about it.

대화가 잘못 구성되었습니다

사람들은 MCP, Pilot Protocol, 혹은 A2A가 표준인지 계속 묻습니다.
어느 것이 “우승”인가? 어느 것을 기반으로 구축해야 할까? 마치 하나를 선택하면 다른 것들은 사라지는 듯이.

저는 약 8개월 동안 프로덕션 에이전트 시스템을 운영해 왔으며 세 가지 모두를 사용합니다—선택을 못해서가 아니라, 각각이 완전히 다른 문제를 해결하고 스택의 다른 계층에 위치하기 때문입니다.

아래는 제가 실제로 생각하는 방식입니다.

What MCP Actually Does

Model Context Protocol (MCP) 은 Anthropic이 만든 모델을 도구에 연결하기 위한 오픈 표준입니다. 에이전트가 다음과 같은 작업이 필요할 때:

파일 읽기
데이터베이스 조회
함수 호출
외부 서비스 이용

MCP는 이러한 작업을 구조화된 방식으로 가능하게 하는 인터페이스입니다.

핵심 단어: model.
MCP는 모델과 도구 사이의 상호작용을 중심으로 설계되었습니다. 도구가 어떻게 설명되고, 모델이 어떻게 호출하며, 결과가 어떻게 반환되는지를 정의하는 도구‑호출 계약입니다.

이는 실제로 매우 유용합니다. MCP가 나오기 전에는 각 프레임워크마다 도구를 정의하는 방식이 달랐습니다 (LangChain, AutoGPT, CrewAI 등). MCP는 클라이언트와 호스트 전반에 걸쳐 작동하는 공통 스키마를 제공합니다.

What MCP Does Not Do

에이전트가 다른 에이전트를 찾는 방법을 알려주지는 않습니다.
NAT 트래버설, 암호화된 터널, 피어 탐색, 주소 지정 등을 처리하지 않습니다.

이러한 문제들은 스택의 다른 계층에 해당합니다.

파일럿이 실제로 하는 일

Pilot Protocol 은 AI 에이전트를 위한 피어‑투‑피어 오버레이 네트워크입니다. 각 에이전트에 영구적인 48‑비트 가상 주소를 부여하고, NAT 트래버설을 자동으로 처리하며, 모든 트래픽을 X25519와 AES‑256‑GCM으로 암호화하고, 실시간 데이터를 조회할 수 있는 350개 이상의 전문 에이전트 디렉터리를 유지합니다.

Key word: peer.
Pilot은 agent‑to‑agent 통신을 중심으로 설계되었습니다: 에이전트 A가 에이전트 B를 어떻게 찾을까요? 어떻게 신뢰를 구축할까요? 중간에 브로커 없이 서로 다른 네트워크와 클라우드 제공자 간에 메시지를 어떻게 교환할까요?

Pilot은 agnostic(무관)하게 여러분이 실행하는 모델이나 에이전트가 가진 도구에 대해 동작합니다. 단순히 에이전트를 연결 가능하게 하고, 통신을 암호화하며, 신뢰할 수 있게 합니다.

OSI‑계층 비유

OSI 모델을 생각해 보세요:

레이어	예시
7 – Application	HTTP
6 – Presentation	TLS
4 – Transport	TCP

이 레이어들은 경쟁하는 것이 아니라 서로 겹쳐서 작동합니다.

Pilot은 대략 5계층 (Session) 에 해당합니다 – 피어 간 주소 지정, 암호화, 세션 관리를 담당합니다.
MCP는 7계층 (Application) 에 해당합니다 – 연결이 성립된 후 애플리케이션이 수행할 일을 정의합니다.

“MCP를 써야 할까, Pilot을 써야 할까?” 라는 질문은 “HTTPS를 써야 할까, TCP를 써야 할까?”와 같은 질문입니다. 답은 두 가지 모두, 올바른 순서대로 사용하는 것입니다.

Pilot이 에이전트를 연결하고, MCP가 연결된 후에 그들이 무엇을 할지 정의합니다.

How I Use Them Together

연구 파이프라인에서 실제로 사용하는 구체적인 예시:

Coordinator agent가 연구 브리프를 받아 하위 작업으로 나눕니다.
Pilot을 통해 전문 에이전트(학술 논문, 규제 서류, 재무 데이터)를 발견합니다.
작업을 Pilot의 암호화된 터널을 통해 전송합니다.
전문 에이전트는 MCP 도구 호출을 사용해 데이터베이스를 조회하고, 문서를 읽으며, API를 호출합니다.
결과가 Pilot을 통해 다시 코디네이터에게 전달됩니다.

Coordinator agent
    |
    | (Pilot: peer discovery + encrypted tunnel)
    v
Academic specialist agent
    |
    | (MCP: tool calls to Crossref, OpenAlex, PubMed)
    v
Results back to coordinator via Pilot

Pilot은 신경계와 같습니다.
MCP는 손과 같습니다. 두 가지가 모두 필요합니다.

Why Both Matter

Pilot이 없으면 코디네이터는 머신이나 클라우드 제공자 전반에 걸쳐 전문 에이전트를 찾거나 연결할 신뢰할 수 있는 방법이 없습니다.
MCP가 없으면 전문 에이전트는 외부 도구를 호출할 수 있는 깔끔한 인터페이스가 부족합니다.

코드 측면

두 에이전트 간 Pilot 연결 설정

# 에이전트 A (코디네이터)에서
pilotctl daemon start --hostname coordinator-agent

# 전문가와 신뢰 관계 수립
pilotctl handshake academic-specialist
pilotctl send-message academic-specialist \
    --data '{"task":"cite","query":"transformer attention"}'

전문가 에이전트가 작업을 처리하고 MCP 사용

# academic-specialist 에이전트 내부
# Crossref에 대한 MCP 툴 호출
result = await mcp_client.call_tool(
    "crossref_search",
    {
        "query": task["query"],
        "limit": 5
    }
)

# Pilot을 통해 결과를 코디네이터에게 전송
pilot_client.send_message(
    "coordinator-agent",
    {"result": result, "task_id": task["id"]}
)

Pilot은 인바운드/아웃바운드 메시지를 처리하고, MCP는 그 사이의 툴 호출을 담당합니다.

A2A는 어떨까?

Google의 Agent‑to‑Agent (A2A) protocol 은 Pilot보다 애플리케이션 레이어에 가깝지만 MCP 아래에 위치합니다. 에이전트 간의 고수준 상호작용 계약을 정의합니다:

에이전트가 기능을 광고하는 방법
작업을 넘겨주는 방식
장기 실행 작업을 관리하는 방법

스택에서 A2A는 Pilot(전송) 위, MCP(툴‑콜링) 아래에 위치하는 서비스‑디스커버리 / 오케스트레이션 레이어로 생각할 수 있습니다. 이는 두 레이어와 경쟁하기보다 서로를 보완합니다.

TL;DR

Pilot = 피어‑투‑피어 연결, 주소 지정, 암호화 (세션 계층).
A2A = 기능 광고 및 작업 오케스트레이션 (애플리케이션‑레벨 계약).
MCP = 모델‑툴 상호작용 (툴‑콜 계약, 애플리케이션 계층).

필요한 곳에 세 가지 모두를 사용하세요. 웹에서 TCP, TLS, HTTP를 함께 사용하는 것과 같은 원리입니다.

개요

Pilot은 전송을 담당합니다.
A2A는 작업 계약을 담당합니다.
MCP는 도구 호출을 담당합니다.

A2A가 필요한지는 에이전트 간 계약이 얼마나 형식적이어야 하는지에 따라 달라집니다.

제가 제어하는 내부 파이프라인에서는 필요하지 않았습니다.
서로 다른 팀이나 조직의 에이전트가 상호 운용해야 하는 시스템에서는 A2A가 제공하는 기능 광고와 작업 인계 계약이 필수적이 됩니다.

핵심은 이 프로토콜들이 같은 영역을 놓고 경쟁하는 것이 아니라는 점입니다. “어느 것이 이긴다”는 식으로 질문을 구성하는 것은 잘못된 접근이며, 이들은 조합됩니다.

실용 체크리스트

새로운 에이전트 시스템을 구축할 때, 나는 순서대로 세 가지 질문을 합니다:

에이전트들이 서로를 어떻게 찾고 통신할 것인가?
Pilot 질문 – 데몬을 설정하고, 주소를 얻으며, 신뢰 연결을 구축합니다.
에이전트들이 작업을 어떻게 넘기고 장기 실행 작업을 추적할 것인가?
팀 간 에이전트가 있다면 A2A 질문일 수 있고, 모든 것을 직접 제어한다면 단순한 메시지 스키마일 수 있습니다.
각 에이전트가 작업을 수행하기 위해 필요한 도구는 무엇인가?
MCP 질문 – 도구를 정의하고, 호스트를 연결하며, 모델이 이를 호출하도록 합니다.

에이전트 개발에서 내가 보는 대부분의 혼란은 사람들이 질문 3에 답하려고 할 때 질문 1에 아직 답하지 않은 경우에서 비롯됩니다. 그들은 단일 에이전트 내부에서 MCP를 아름답게 작동시키지만, 네트워크 경계 너머 두 에이전트가 실제로 서로 통신하도록 하려 할 때 벽에 부딪힙니다.

MCP는 그 문제를 해결하지 못합니다.
Pilot은 해결합니다.

시작하기

Pilot 프로토콜:

curl -fsSL https://pilotprotocol.network/install.sh | sh

MCP 문서:
A2A 사양:
Pilot GitHub:
실시간 네트워크:

Pilot의 무료 티어는 AGPL‑3.0 오픈 소스로, 가입이 필요 없습니다. MCP는 MIT 라이선스의 오픈 소스입니다. 둘 다 사용해 보는 데 비용이 들지 않습니다.

핵심 요약

멀티‑에이전트 시스템을 구축하면서 어떤 프로토콜에 베팅할지 고민하고 있다면, 질문 자체를 잘못 설정한 것일 가능성이 높습니다. 각 계층에 맞는 올바른 도구를 선택하고 넘어가세요.