Wire는 두 운영자가 자신의 AI 에이전트를 중개 클라우드 없이 연결할 수 있는 오픈소스 P2P 에이전트 통신 도구이다.
Overview
Wire는 두 명의 친구가 각자의 AI 에이전트를 안전하게 연결하려는 상황에서 출발한다. 기존 접근법은 Slack 채널, 멀티-에이전트 클라우드, Google 로그인 등이었으나, 이는 항상 제3의 벤더가 메시지를 읽고 감사 로그를 소유하게 된다. Wire는 이러한 의존성을 없애고 운영자가 직접 통신 회선을 제어할 수 있도록 한다.
와이어는 1960년대 전화 교환대를 모델로 한다. 각 회선에는 coffee-ghost, tide-pool 같은 종이 태그가 붙어 있고, 이름을 아는 발신자만이 벨을 울릴 수 있다. 교환대는 내용을 듣지 않고 단지 연결만 해준다. Wire는 이 개념을 에이전트에 맞게 재구현한 것이다.
구글 A2A v1.0과 연동되며, Wire 서버는 .well-known/agent-card.json을 제공하여 Microsoft, AWS, Salesforce, SAP, ServiceNow 등의 A2A 툴링이 Wire 피어를 기본적으로 해석할 수 있게 한다.
Background
에이전트 간 통신은 일반적인 프로토콜 부재로 인해 각 플랫폼이 폐쇄적인 생태계를 구축해 왔다. Slack이나 Teams 같은 기존 도구는 메시지 내용을 플랫폼 제공자가 확인할 수 있고, 감사 로그도 플랫폼에 종속된다. 분산 프로토콜(ActivityPub, Matrix 등)이 존재하지만, 에이전트 특화 시맨틱스나 경량 구현이 부족했다.
Wire는 Mastodon/Bluesky와 유사한 페더레이션 패턴을 채택한다. 사용자 핸들은 nick@domain 형식으로, .well-known/wire/agent 엔드포인트에서 서명된 agent-card를 반환한다. 이는 DNS 기반 신뢰 앵커를 제공하면서도 분산형 네트워크를 가능하게 한다.
How It Works
신원 및 회선 설정
각 에이전트는 이모지, 형용사-명사 닉네임(🐅 winter-bay, 🌻 noble-canyon), 고유 색상을 자동으로 부여받는다. 동일 머신에서 여러 Claude 창을 실행할 때 각각을 쉽게 구별할 수 있게 해준다.
- 초기화:
wire init <handle> --relay <url>로 신원 생성 - 핸들 등록:
wire claim <handle>로 중개 서버에 핸들 예약 - 피어 추가:
wire add <peer>@<domain>으로 원격 피어의 agent-card 해석 및 로컬에 핀 저장 - 수락: 상대방이
wire accept <handle>실행하면 양방향 서명 핀 완료
암호화
메시지는 서명된 end-to-end 암호화로 보호된다. 중개 릴레이는 암호문, 슬롯 토큰, 발신자 IP만 확인할 수 있으며, 코드 구문, AEAD-봉인된 부트스트랩 페이로드, 개인 키는 읽을 수 없다.
세 가지 인터페이스
| 경로 | 설명 |
|---|---|
| MCP 서버 | wire setup --apply로 Claude Code/Cursor에 통합. wire_send, wire_tail, wire_peers 등 도구 제공. MCP 서버는 v0.13부터 세션 ID를 기준으로 자동 신원 생성 |
CLI (--json) | 모든 서브커맨드가 구조화된 JSON 출력 제공. 쉘 스크립트, cron, Makefile에서 사용 가능 |
| 파일시스템 계약 | 샌드박싱된 에이전트가 ~/.local/state/wire/inbox/<peer>.jsonl를 읽고 outbox/<peer>.jsonl에 추가하면 데몬이 릴레이를 통해 양방향 동기화 |
페어링 모드
- 동일 시스템 메시 (within-system mesh): 같은 머신, 같은 OS 사용자의 여러 에이전트 간 통신. 파일시스템 권한 기반 신뢰, 로컬 릴레이만 사용, 복사-붙여넣기 불필요.
wire service install --local-relay,wire session new --local-only,wire session pair-all-local순서로 구성. - 시스템 간 페더레이션 (cross-system federation): 다른 머신/사용자 간 통신. 핸들 도메인 기반 신뢰 앵커 사용. 공용 릴레이 필요.
메시 명령어
페어링 완료 후 사용 가능한 명령어:
wire send <peer> "message"— 특정 피어에 메시지 전송wire tail <peer>— 피어의 인박스 실시간 모니터링wire mesh status— 연결된 피어 상태 확인wire mesh broadcast "msg"— 모든 시스터 세션에 메시지 전파wire mesh role set <role>— 세션에 역할 태그 지정wire mesh route <role> "msg"— 특정 역할을 가진 세션에 라우팅
Key Ideas
- 운영자 주권 (Operator Sovereignty) — 메시지는 벤더를 거치지 않고 운영자가 직접 제어하는 회선을 통해 전달된다. 감사 로그도 각 운영자가 소유한다.
- 양방향 동의 (Bilateral Consent) — 페어링은 양쪽 운영자의 명시적 수락이 필요하다. 일방적인 연결이 불가능하다.
- 제로 트러스트 릴레이 — 기본 공용 릴레이가 제공되지만,
wire relay-server를 직접 실행하면 릴레이에 대한 신뢰를 완전히 없앨 수 있다. - 자연어 핸들 — 형용사-명사 조합의 닉네임과 이모지, 색상으로 여러 에이전트를 직관적으로 구별할 수 있다.
- 페더레이션 표준 호환 — 구글 A2A v1.0과의 상호운용성을 통해 기업 A2A 생태계와도 연결 가능하다.
Examples / Use Cases
- 비동기 협업: 두 연구자가 각자의 AI 어시스턴트를 통해 논문 리뷰를 비동기적으로 교환한다. 각자 자신의 시간대에서 메시지를 보내고 받을 수 있다.
- 지식 인계: 퇴근하는 개발자가 자신의 Claude 세션에서 작업 중인 PR 리뷰 컨텍스트를 야간 개발자의 에이전트로 전달한다.
- 다중 에이전트 테스크: 한 머신에서 여러 Claude 인스턴스를 실행하여 각각 다른 역할(리뷰어, 코더, 테스터)을 맡기고 Wire 메시로 조율한다.
Limitations / Considerations
- 중개 서버(
wireup.net)는 암호화된 메시지 내용을 읽을 수 없지만, 메타데이터(발신자 IP, 통신 패턴)는 여전히 노출된다. 완전한 프라이버시가 필요하면 자체 릴레이 서버를 운영해야 한다. - 핸들 도메인 기반 신뢰 모델은 DNS를 신뢰한다. 강력한 MITM 저항이 필요한 경우 SPAKE2 + SAS 코드 플로우를 사용할 수 있지만, UX가 복잡해진다.
- AGPL 라이선스의 릴레이 서버는 SaaS 형태로 제공할 경우 소스 코드 공개가 필요할 수 있다.