A2A-commerce: AI 에이전트를 위한 아키텍처

AI 에이전트 상호작용을 위한 인프라 설계: A2A 커머스 아키텍처

현대 웹은 브라우저를 사용하는 인간을 위해 구축되었습니다. 하지만 클라이언트가 자율적인 AI 에이전트로 변모하면, DOM 파싱, OAuth 기반 API 통합, 수동 통합과 같은 표준 솔루션은 규모 확장에 실패합니다. 모든 사용자가 초당 수천 건의 거래를 시작할 수 있는 개인 에이전트를 보유한 세상에서는 주소 지정, 라우팅, 신뢰, 검색 분야에서 근본적인 변화가 필요합니다. 이는 REST이나 GraphQL의 진화가 아니라, 기계 대 기계 상호작용을 위한 새로운 네트워크 시맨틱입니다.

주소 지정: URL에서 3층 식별 체계로

인간 웹은 DNS와 URL—도메인 → IP → 서버—에 의존합니다. 그러나 AI 에이전트에게는 이 모델이 작동하지 않습니다. 에이전트는 NAT 뒤의 모바일 기기, 서비스 제공업체의 클라우드, 또는 사용자의 PC에서 실행될 수 있으며, 엔드포인트를 변경하거나 오프라인 상태가 될 수도 있고, 인프라와 무관한 암호화된 신원을 가질 수 있습니다.

해결책은 3층 모델입니다:

• 인간 핸들 (alice#aigentix.org) — QR 코드와 메시지를 통해 전달되는 읽기 쉬운 식별자;
• DID (did:aip:aigentix.org:alice) — W3C 표준에 따른 탈중앙화된 식별자로, 공개 키를 포함하며 도메인에 묶여 있지 않습니다;
• 엔드포인트 (https://hub.aigentix.org/relay/alice) — 신원을 잃지 않으면서 동적으로 변경될 수 있는 물리적 전달 경로.

주요 기술적 세부사항: 핸들에 사용된 # 기호는 HTTP의 프래그먼트 식별자와 충돌합니다. API에서는 핸들을 항상 URL 인코딩합니다: alice%23aigentix.org. 서버는 GET /api/v1/resolve/alice#aigentix.org를 받지 않고, 오직 GET /api/v1/resolve/alice만 받습니다. 이는 사소한 문제가 아니며, 차세대 프로토콜 설계 시 기존 웹 관행이 실제로 어떤 장애물을 초래하는지 보여주는 예입니다.

해결은 순차적으로 이루어집니다: 핸들 → 레지스트리 조회 → DID → DID 문서(경로 모드와 공개 키 포함) → 엔드포인트. 레지스트리 단계에서 결과를 캐싱하면 성능이 보장되고, 계층 분리 덕분에 식별자의 장기적 안정성이 확보됩니다.

라우팅: 직접 vs. 릴레이 및 엄격한 동등성

엔드포인트만 가지고 있다고 해서 배달 문제가 해결되는 것은 아닙니다. 두 가지 주요 모드—직접과 릴레이—는 서로 다른 유형의 작업을 처리합니다:

• 직접: 수신자의 엔드포인트로 바로 HTTP POST를 보내는 방식. 공개 IP와 보장된 가용성을 갖춘 기업 에이전트에 적합합니다.
• 릴레이: 내구성 있는 스트림(NATS JetStream 등)에 게시하고, 수신자가 WebSocket으로 구독하도록 하는 방식. 오프라인 상태에서도 배달을 보장하지만 지연이 발생합니다.

모드 선택은 알고리즘에 의해 결정됩니다:

• 수신자의 DID를 확인한다;
• 만약 route_mode == "direct"이고 엔드포인트가 이용 가능하다면—직접을 사용한다;
• 그렇지 않다면—릴레이를 사용한다.

릴레이는 최소 한 번 이상의 배달을 의미합니다. 이는 선택 사항이 아니라 필수 요건입니다. 수신자는 message_id를 기반으로 동등성 처리를 구현해야 합니다. 각 메시지는 반드시 다음 필드를 포함합니다:

• id: UUID v4;
• created_at: RFC 3339 형식의 타임스탬프;
• encrypted_body: 암호화된 페이로드(X25519 일회용 키 교환);
• sig: 직렬화된 봉투 위에 적용된 Ed25519 서명.

중복 제거는 슬라이딩 윈도우 방식으로 구현됩니다: 지난 10분간의 메시지 ID를 저장하고, 허용되는 시계 오차는 ±300초입니다. Redis의 간단한 LRU 캐시나 RocksDB의 LSM 트리로 충분합니다.

신뢰: 암호화된 인증서와 신뢰 그래프

사람들은 브랜드, 리뷰, 평점을 신뢰합니다. 기계는 오직 검증 가능한 주장만 신뢰합니다. 우리는 W3C의 검증 가능한 인증서(VC) 표준을 신뢰 모델의 기반으로 삼습니다.

법적 실체를 검증하기 위한 VC 예시:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "OrganizationVerification"],
  "issuer": "did:aip:aigentix.org:trust-anchor",
  "credentialSubject": {
    "id": "did:aip:aigentix.org:etagi",
    "legalName": "Etazhi LLC",
    "inn": "7224052984",
    "verified": true
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:aip:aigentix.org:trust-anchor#key-1",
    "proofValue": "..."
  }
}

이러한 인증서는 트러스트 앵커—네트워크 참여자 모두가 알고 있는 DID와 공개 키를 보유한 신뢰 센터—에 의해 발급됩니다. 검증은 제3자를 동원하지 않고 로컬에서 이루어집니다.

개별 VC는 신뢰 DAG—각 엣지의 가중치가 발급자의 권위에 따라 달라지는 방향성 비순환 그래프—를 형성합니다. 신뢰 점수 계산 알고리즘은 보수적입니다:

• 점수는 느리게 상승합니다: 많은 성공적인 상호작용이 필요합니다;
• 점수는 빠르게 하락합니다: 취소나 검증 오류가 즉시 점수를 낮춥니다;
• 최종 범위는 [0.0, 1.0]입니다.

이 점수는 역방향 순위 융합(RRF)을 통해 검색에 통합됩니다:

final_score = RRF(semantic_rank, fts_rank) × (1 + 0.3 × trust_score)

파라미터 trust_weight = 0.3은 신뢰가 관련성을 강화하지만 이를 대체하지는 않는다는 것을 보장합니다.

검색: 하이브리드 랭킹과 에이전트를 위한 구조화된 응답

사람을 위한 검색은 HTML 페이지를 반환합니다. 에이전트를 위한 검색은 더 많은 데이터를 얻는 방법을 나타내는 구조화된 객체를 반환합니다. 응답에는 데이터뿐만 아니라 에이전트-제공자 주소도 포함되어야 합니다:

{
  "results": [
    {
      "id": "doc_123",
      "name": "2베드룸 아파트, 트베르스카야 거리, 68m²",
      "price": 79,000,
      "available": true,
      "relevance_score": 0.92,
      "trust_score": 0.94,
      "agent": {
        "handle": "etagi%23aigentix.org",
        "name": "Etaji",
        "endpoint": "https://api.etagi.ru/aip"
      }
    }
  ]
}

agent 필드는 웹사이트 링크가 아니라, 추가 A2A 호출을 위한 주소입니다. etagi%23aigentix.org를 해결한 후, 에이전트는 aip.commerce.offer.request 타입과 item_id를 포함한 POST를 보내고, 구조화된 사진, 평면도, 연락처 정보를 받습니다—HTML 렌더링 없이 말입니다.

하이브리드 검색은 순수한 시맨틱 검색만으로는 부족하기 때문에 필요합니다:

• 제품 코드와 정확한 문구(예: iPhone 15 Pro Max 256GB)는 FTS가 필요합니다;
• 새로운 개체(브랜드, 회사, 제품)는 임베딩에서 충분한 시맨틱 컨텍스트를 갖추지 못합니다;
• 숫자 값(가격, 면적, 층)은 임베딩 공간에서 잘 구분되지 않습니다.

RRF는 다음과 같이 구현됩니다:

def rrf(semantic_rank, fts_rank, k=60):
    return 1/(k + semantic_rank) + 1/(k + fts_rank)

이렇게 하면 두 가지 랭킹을 정규화 없이 결합할 수 있어, 상위 순위에 대한 민감성을 유지하면서 혼합 쿼리에서도 꾸준히 품질을 개선할 수 있습니다.

프로토콜은 명세서, 구현은 별도: 상호 운용성보다 구현 우선

핵심 원칙은 프로토콜과 구현을 엄격히 분리하는 것입니다. AIP(Agent Interaction Protocol)은 다음을 정의합니다:

• 봉투 형식: 필수 필드 id, from, to, type, encrypted_body, sig;
• 핸들 → DID → 엔드포인트로의 해결 규칙;
• 검색 요청과 응답의 스키마;
• VC 검증과 신뢰 점수 계산 알고리즘.

구현(Hub)은 어떤 스택을 사용해도 됩니다: Actix를 사용한 Rust, NATS를 사용한 Go, FastAPI를 사용한 Python—이것은 배포 세부사항입니다. 이 아키텍처는 다음을 보장합니다:

• 서로 다른 개발자의 에이전트 간 상호 운용성;
• 기업의 벤더 종속 방지;
• 연합 가능성: 서로 다른 도메인의 Hub들이 서로 메시지를 라우팅할 수 있습니다.

이메일과의 유사점은 적절합니다: SMTP는 개방형 프로토콜이고, Gmail과 Yandex.Mail은 독립적인 구현이지만, 이메일은 서로 간의 조정 없이도 왕래합니다.

무엇이 중요한가

• AI 에이전트의 주소 지정에는 읽기 쉬움과 암호화된 신원, 물리적 라우팅을 분리하는 3층 모델(핸들/DID/엔드포인트)이 필요합니다.
• 릴레이 라우팅은 엄격한 동등성을 요구합니다: 각 메시지에는 UUID v4와 created_at이 반드시 포함되어야 하고, 수신자는 슬라이딩 윈도우 기반 중복 제거를 지원해야 합니다.
• 신뢰는 중앙 집중식 평점이 아니라 W3C 검증 가능한 인증서에 기반합니다: 검증은 외부 서비스 없이 로컬에서 이루어집니다.
• 에이전트를 위한 검색은 URL이 아니라 agent.handle와 agent.endpoint을 포함한 객체를 반환합니다—이것이 차세대 A2A 상호작용의 기반이 됩니다.
• 하이브리드 검색(RRF)은 FTS와 시맨틱 랭킹을 결합합니다: 임베딩이 제품 코드, 숫자, 새로운 개체에 대한 정확한 매칭을 대체하지 못하기 때문입니다.
• 프로토콜은 구현과 분리되어야 합니다: 이것이 상호 운용성, 연합, 그리고 벤더 종속 방지의 조건입니다.

— Editorial Team