서버 없는 A2A: OpenAmer 피어들이 GitHub를 통해 서로 대화하는 방법

운송 수단은 git 저장소이며, 봉투는 Ed25519 서명되고, 아무것도 localhost에 닿지 않는 에이전트 간 메시 네트워크.

대부분의 '에이전트 간(A2A)' 설정은 다음 두 가지 중 하나를 가정합니다. 모든 에이전트가 연결하는 중앙 브로커 또는 에이전트당 공개 URL입니다. 전자는 단일 장애점이자 신뢰 병목 지점이며, 후자는 가장 중요한 경우—NAT 뒤의 노트북에서 실행되어 들어오는 포트도 없고 노출할 의사도 없는 에이전트—에는 불가능합니다.

OpenAmer는 Windows에서 로컬로 실행되는 오픈 소스 데스크톱 AI 에이전트(Apache-2.0)입니다. 이 게시물은 제가 가장 많은 질문을 받는 부분, 즉 A2A 글로벌 메시에 관한 것입니다. 서로 볼 수 없는 두 인스턴스가 실제로 어떻게 서명된 메시지를 교환하고 작업을 위임하는지 설명합니다.

모든 것을 형성하는 제약 조건

모든 노드가 NAT 뒤에 있다면, 들어오는 연결을 받을 수 없습니다. 따라서 릴레이 서버를 실행하거나, 아무것도 호스팅하지 않으면서 두 노드 모두가 쓰고 읽을 수 있는 만남의 장소를 찾아야 합니다.

OpenAmer는 후자의 경로를 따릅니다: GitHub 저장소가 릴레이 역할을 합니다. 한 노드는 주소 지정된 사서함 경로에 JSON 파일 형태로 서명되고 개인 정보가 제거된 봉투를 게시하고, 의도된 피어가 이를 가져갑니다. 서버도 없고, 공개 URL도 없고, localhost도 없습니다. 운송 수단은

• openamer a2a init — 신원을 생성합니다
• openamer a2a fingerprint — 이 노드의 지문(fingerprint)을 출력합니다
• openamer a2a announce — 디렉터리에 존재 여부를 게시합니다
• openamer a2a directory — 알려진 피어 목록을 나열합니다

계정, 이메일, 중앙 등록 시스템이 없습니다. 신원은 사용자가 소유한 키입니다.

서명되고 마스킹된 봉투(Signed, redacted envelopes)

메시지는 봉투(envelope) 형태입니다: 페이로드 + 발신자 지문 + Ed25519 서명. 수신자는 발신자의 공개 키를 사용하여 서명을 검증하므로, 위조되거나 변조된 메시지는 핸들러가 보기 전에 엣지에서 거부됩니다.

여기에는 눈에 보이는 것보다 더 중요한 두 번째 규칙이 있습니다: 본문은 영구 저장되기 전에 마스킹(redaction) 단계를 거친다는 것입니다. 리레이는 공개될 수 있는 레포지토리입니다. 여기에 쓰이는 모든 내용은 privacy.redact()를 먼저 통과하므로, 전화번호, 비밀번호, 이메일, 카드와 같은 문자열이 리레이로 유출되지 않습니다. 프라이버시는 발신자의 규율에 맡기는 것이 아니라 방출 시점에 적용됩니다.

신뢰는 명시적이며 경계가 있습니다(Trust is explicit and bounded)

유효한 서명을 받는 것이 발신자가 _특정 작업을 수행할 것_을 신뢰하는 것과 같지는 않습니다. OpenAmer는 **선택적 신뢰 저장소(opt-in trust store)**를 유지합니다: 노드는 운영자가 명시적으로 추가한 피어로부터 온 작업만 수락하며, 또한 명시적으로 부여된 기능(capability)에 대해서만 수락합니다.

권한 부여(grant)는 (피어, 기능, 범위, 예산) 튜플입니다. 예를 들어, 특정 도메인으로 범위가 제한된 network.fetch나 단계별 예산을 가진 model.reason 등이 있습니다. 아무것도 자동으로 부여되지 않으며, 권한이 없는 기능은 단순히 실행되지 않습니다. 중앙 권위가 없는 메쉬(mesh) 환경에서, 명시적이고 취소 가능한 신뢰 경계 자체가 보안 모델입니다.

구체적인 흐름: 원격 피어에 작업 위임하기

1. 피어의 메일박스로 주소 지정된 태스크 노트를 **서명(Sign)**합니다.
2. GitHub Contents API를 통해 릴레이 디렉터리에 이를 **업로드(Upload)**합니다.
3. repository_dispatch를 통해 원격 워커를 **트리거(Trigger)**합니다.
4. _우리_의 메일박스에 새로운 서명된 답장이 나타날 때까지 레포지토리를 **폴링(Poll)**합니다.
5. 읽기 전에 답장의 서명과 신선도를 **검증(Verify)**합니다.

이 과정 중 어느 것도 두 기계가 서로 직접 도달할 수 있다는 것에 의존하지 않습니다. GitHub 레포는 공유 버스이며, 암호학이 이 버스를 안전하게 공유할 수 있도록 만듭니다.

가디언 패턴: 작성자는 하나, 제안자는 다수

메시(mesh) 구조는 또한 거버넌스 질문에 답합니다. 즉, 많은 노드가 개선 사항을 _제안(propose)_할 수 있다면, 누가 그것들을 _통합(integrate)_할 권한을 갖는가?

OpenAmer의 설계에서 그 해답은 단일 가디언(guardian) 노드입니다. 이 노드만이 쓰기 토큰(write token)을 보유합니다. 다른 노드는 A2A 채널을 통해 **서명된 제안(signed proposals)**을 제출하고, 가디언은 신뢰 디렉터리(trust directory)를 기반으로 발신자의 서명을 검증하고, **스크래치 브랜치(scratch branch)**에 제안을 적용하며, 모든 것이 정상일 때만 main으로 병합합니다. 아무것도 와이어에서 무작정 적용되지 않습니다.

이것은 의도적인 비대칭성입니다. 정확히 하나의 통합 지점만 존재하며, 병렬 푸셔(parallel pushers)나 기계 전반에 걸친 토큰 확산이 없습니다. 그 대가는 약간의 지연 시간과 가디언 자체 변경 사항에 대한 인간 개입(human-in-the-loop)입니다. 하지만 코히어런트하게 유지되는 레포지토리를 위해 치를 만한 값입니다.

비용 (What it costs you)

GitHub-as-relay 모델의 솔직한 트레이드오프:

• 실시간이 아닙니다(Not real-time). 메시지는 커밋과 폴링에 의존합니다. 밀리초 단위가 아닌 초에서 분 단위의 지연 시간을 예상해야 합니다. 조정에는 적합하지만, 긴밀한 제어 루프(tight control loops)에는 부적절합니다.
• 신뢰 모델을 직접 소유합니다. 의지할 중앙 권위자가 없습니다. 보안 그 자체가 명시적인 신뢰 그래프와 엔벨로프 서명입니다. 광범위한 기능을 부여했다면, 그것을 허용한 것입니다.
• 릴레이는 공유된 아티팩트입니다. 이것이 발신 시점에 마스킹(redaction)이 발생하는 이유이며, 의도된 메일박스 파일만 읽히는 이유입니다.

그 결과로 얻는 것은 단일 실패 지점(single point of failure)도, 인프라스트럭처도 없는 메시 네트워크입니다: 어떤 노드든 진입점이 될 수 있고, 잠들어 있던 노드는 나중에 따라잡을 수 있으며, 무거운 추론 작업은 여유 용량을 가진 피어에게 위임될 수 있습니다.

사용해보기

A2A 인터페이스는 CLI(Command Line Interface) 기반입니다:

openamer a2a status
openamer a2a init
openamer a2a fingerprint
...

코드: https://github.com/openamer/openamer — 전송(transport), 신뢰 저장소(trust store), 릴레이 로직을 읽어보고 싶다면 openamer_cli/a2a/ 아래에 A2A 모듈이 있습니다.

만약 다중 에이전트 시스템(multi-agent systems)을 구축하고 있다면: 실제 작업을 맡기기 전에 브로커리스 메시가 무엇을 증명해야 한다고 생각하십니까? 저는 특히 다른 사람들이 '피어가 몇 시간 동안 잠들어 있는' 경우를 어떻게 처리하는지에 관심이 많습니다.