A2A에서의 에이전트 발견

AI 에이전트가 Agent2Agent(A2A) 프로토콜을 사용하여 협업하려면, 먼저 서로를 찾고 다른 에이전트가 제공하는 기능을 이해해야 합니다. A2A는 에이전트 카드를 통해 에이전트의 자체 설명 형식을 표준화합니다. 그러나 이러한 에이전트 카드를 발견하는 방법은 환경 및 요구 사항에 따라 다를 수 있습니다.

에이전트 카드의 역할

에이전트 카드는 A2A 서버(원격 에이전트)의 디지털 "명함" 역할을 하는 JSON 문서입니다. 이는 발견 및 상호 작용 시작에 매우 중요합니다. 일반적으로 에이전트 카드에 포함되는 주요 정보는 다음과 같습니다.

• ID: name, description, provider 정보.
• 서비스 엔드포인트: A2A 서비스에 도달할 수 있는 url.
• A2A 기능: streaming 또는 pushNotifications와 같이 지원되는 프로토콜 기능.
• 인증: 에이전트와 상호 작용하는 데 필요한 인증 schemes (예: "Bearer", "OAuth2").
• 기술: 에이전트가 수행할 수 있는 특정 작업 또는 기능 목록 (AgentSkill 객체), id, name, description, inputModes, outputModes, examples 포함.

클라이언트 에이전트는 에이전트 카드를 구문 분석하여 원격 에이전트가 특정 작업에 적합한지, 해당 기술에 대한 요청을 어떻게 구성해야 하는지, 그리고 안전하게 통신하는 방법을 결정합니다.

발견 전략

클라이언트 에이전트가 원격 에이전트의 에이전트 카드를 발견할 수 있는 일반적인 전략은 다음과 같습니다.

1. 잘 알려진 URI (Well-Known URI)

이는 공개 에이전트 또는 특정 도메인 내에서 광범위한 발견 가능성을 목적으로 하는 에이전트에 권장되는 접근 방식입니다.

• 메커니즘: A2A 서버는 자신의 도메인에서 표준화된 "잘 알려진" 경로에 에이전트 카드를 호스팅합니다.
• 표준 경로: https://{agent-server-domain}/.well-known/agent.json (잘 알려진 URI에 대한 RFC 8615 원칙을 따름).
• 프로세스:
  1. 클라이언트 에이전트는 잠재적인 A2A 서버의 도메인을 알거나 프로그래밍 방식으로 발견합니다 (예: smart-thermostat.example.com).
  2. 클라이언트는 https://smart-thermostat.example.com/.well-known/agent.json으로 HTTP GET 요청을 수행합니다.
  3. 에이전트 카드가 존재하고 접근 가능하면 서버는 이를 JSON 응답으로 반환합니다.
• 장점: 간단하고 표준화되었으며, 도메인을 확인할 수 있는 크롤러나 시스템에 의한 자동 발견을 가능하게 합니다. 발견 문제를 효과적으로 "에이전트의 도메인 찾기"로 축소합니다.
• 고려 사항: 공개 발견 또는 도메인을 제어하는 조직 내 발견을 목적으로 하는 에이전트에 가장 적합합니다. 카드에 민감한 정보가 포함된 경우 에이전트 카드를 제공하는 엔드포인트 자체에 인증이 필요할 수 있습니다.

2. 큐레이션된 레지스트리 (카탈로그 기반 발견)

엔터프라이즈 환경, 마켓플레이스 또는 특수 생태계의 경우, 에이전트 카드는 중앙 레지스트리 또는 카탈로그를 통해 게시되고 발견될 수 있습니다.

• 메커니즘: 중개 서비스(레지스트리)가 에이전트 카드 모음을 유지 관리합니다. 클라이언트는 이 레지스트리를 쿼리하여 다양한 기준(예: 제공되는 기술, 태그, 공급자 이름, 원하는 기능)에 따라 에이전트를 찾습니다.
• 프로세스:
  1. A2A 서버(또는 해당 관리자)는 레지스트리 서비스에 에이전트 카드를 등록합니다. 이 등록 메커니즘은 A2A 프로토콜 자체의 범위를 벗어납니다.
  2. 클라이언트 에이전트는 레지스트리의 API를 쿼리합니다 (예: "스트리밍을 지원하는 '이미지 생성' 기술을 가진 에이전트 찾기").
  3. 레지스트리는 일치하는 에이전트 카드 목록 또는 해당 참조를 반환합니다.
• 장점:
  • 사용 가능한 에이전트의 중앙 집중식 관리, 큐레이션 및 거버넌스.
  • 도메인 이름뿐만 아니라 기능적 역량에 기반한 발견을 용이하게 합니다.
  • 레지스트리 수준에서 접근 제어, 정책 및 신뢰 메커니즘을 구현할 수 있습니다.
  • 회사별 또는 팀별 에이전트 카탈로그, 또는 A2A 호환 에이전트의 공개 마켓플레이스와 같은 시나리오를 가능하게 합니다.
• 고려 사항: 추가적인 레지스트리 서비스가 필요합니다. A2A 프로토콜은 현재 이러한 레지스트리에 대한 표준 API를 정의하지 않지만, 이는 잠재적인 향후 탐색 및 커뮤니티 표준화 영역입니다.

3. 직접 구성 / 비공개 발견

많은 시나리오, 특히 긴밀하게 결합된 시스템 내, 비공개 에이전트의 경우, 또는 개발 및 테스트 중에 클라이언트는 에이전트 카드 정보 또는 이를 가져올 URL로 직접 구성될 수 있습니다.

• 메커니즘: 클라이언트 애플리케이션은 하드코딩된 에이전트 카드 세부 정보를 가지거나, 로컬 구성 파일에서 읽거나, 환경 변수를 통해 수신하거나, 클라이언트에 알려진 비공개 독점 API 엔드포인트에서 가져옵니다.
• 프로세스: 이는 애플리케이션의 배포 및 구성 전략에 따라 매우 구체적입니다.
• 장점: 에이전트 간의 알려진 정적 관계 또는 동적 발견이 요구 사항이 아닌 경우 간단하고 효과적입니다.
• 고려 사항: 새롭거나 업데이트된 에이전트를 동적으로 발견하는 데 유연성이 떨어집니다. 원격 에이전트 카드가 변경되면 클라이언트 재구성이 필요할 수 있습니다. 독점 API 기반 발견은 A2A에 의해 표준화되지 않았습니다.

에이전트 카드 보안

에이전트 카드 자체에는 다음과 같이 보호해야 하는 정보가 포함될 수 있습니다.

• 내부 전용 또는 접근이 제한된 에이전트의 url.
• 체계별, 비보안 정보(예: OAuth 토큰 URL)에 사용되는 경우 authentication.credentials 필드의 세부 정보. 에이전트 카드에 실제 일반 텍스트 비밀을 저장하는 것은 매우 권장되지 않습니다.
• 민감하거나 내부적인 기술에 대한 설명.

보호 메커니즘:

• 엔드포인트 접근 제어: 에이전트 카드를 제공하는 HTTP 엔드포인트(/.well-known/agent.json 경로, 레지스트리 API 또는 사용자 지정 URL)는 카드가 공개적이고 인증되지 않은 접근을 위한 것이 아니라면 표준 웹 관행을 사용하여 보안되어야 합니다.
  • mTLS: 신뢰 모델에 적합한 경우 클라이언트 인증을 위해 상호 TLS를 요구합니다.
  • 네트워크 제한: 특정 IP 범위, VPC 또는 사설 네트워크로 접근을 제한합니다.
  • 인증: 에이전트 카드 자체에 접근하려면 표준 HTTP 인증(예: OAuth 2.0 Bearer 토큰, API 키)을 요구합니다.
• 레지스트리에 의한 선택적 공개: 에이전트 레지스트리는 인증된 클라이언트의 ID 및 권한에 따라 다른 에이전트 카드 또는 다양한 수준의 세부 정보를 반환하는 논리를 구현할 수 있습니다. 예를 들어, 공개 쿼리는 제한된 카드를 반환할 수 있지만 인증된 파트너 쿼리는 더 많은 세부 정보가 있는 카드를 받을 수 있습니다.

에이전트 카드에 민감한 데이터가 포함된 경우(다시 말하지만, 비밀에는 권장되지 않음), 카드 자체는 강력한 인증 및 권한 부여 없이는 절대 사용할 수 없다는 점을 기억하는 것이 중요합니다. A2A 프로토콜은 클라이언트가 에이전트 카드에 포함된 정적 비밀에 의존하기보다는 대역 외(out-of-band)로 동적 자격 증명을 얻는 인증 체계를 권장합니다.

향후 고려 사항

A2A 커뮤니티는 향후 레지스트리 상호 작용 또는 더 발전된 의미론적 발견 프로토콜의 표준화 측면을 탐색할 수 있습니다. 이 분야의 피드백과 기여는 A2A 에이전트의 발견 가능성과 상호 운용성을 향상시키는 데 도움이 될 것입니다.