확장 및 프로토콜 바인딩 거버넌스

확장 및 프로토콜 바인딩 거버넌스 (Extension & Binding Governance)

A2A 조직은 확장(Extensions)과 커스텀 프로토콜 바인딩(Custom Protocol Bindings) 모두에 통합 거버넌스 프레임워크를 사용해요. 이 문서는 이 아티팩트들을 A2A 조직 내에서 제안, 개발, 승격, 유지하는 공식 과정을 정의해요. 누구나 확장이나 커스텀 프로토콜 바인딩을 독립적으로 개발하고 게시할 수 있어요. 여기 설명된 계층(tiers)과 수명주기는 a2aproject GitHub 조직 아래 호스팅되는 것들에 구체적으로 적용돼요.

출처: 문서

본문

계층(Tiers)

확장과 커스텀 프로토콜 바인딩 모두 a2aproject 조직 내에서 두 계층 시스템을 사용해요. 저장소 명명과 URI 접두사는 유형에 따라 달라져요. [테이블 생략]

URI 네임스페이스

공식 URI 접두사는 확장과 커스텀 프로토콜 바인딩에 전역 고유 URI를 할당하는 데 사용되는 표준 네임스페이스 식별자예요. 에이전트와 클라이언트는 Agent Card, 헤더, 프로토콜 메시지에서 이러한 URI를 참조해 지원을 선언하고 협상해요. 접두사 아래의 개별 URI는 특정 아티팩트와, 적용 가능할 때 그 버전을 식별해요. 예를 들어 https://a2a-protocol.org/extensions/{name}/v1 또는 https://a2a-protocol.org/bindings/{name}/v1처럼요. 이 URI들은 식별자이며 HTTP 접근이 기대되지 않아요.

공식(Official)

공식 아티팩트는 a2aproject GitHub 조직 아래에서 개발·유지되며, TSC가 공식적으로 권장해요. 각 저장소에는 MAINTAINERS.md에 식별된 지정 유지관리자가 있어요.

요구사항:

  • 스펙은 핵심 스펙과 같은 언어를 사용해야 함 (RFC 2119)
  • Apache 2.0으로 라이선스해야 함
  • 최소한 하나의 참조 구현이 있어야 함
  • A2A 웹사이트에 관련 문서가 있어야 함(SHOULD)

실험(Experimental)

실험 아티팩트는 커뮤니티 기여자가 공식 상태로 승격되기 전에 아이디어를 프로토타입하고 협업할 수 있는 인큐베이션 경로를 제공해요.

생성 요구사항:

  • 실험 저장소는 A2A 유지관리자의 후원이 있을 때만 만들 수 있음
  • 후원 유지관리자는 실험 아티팩트의 초기 감독 책임이 있음
  • 실험 저장소는 README에서 실험적/비공식 상태를 명확히 표시해야 함
  • 게시된 패키지는 실험 상태를 명확히 나타내는 명명을 사용해야 함
  • TSC는 실험 저장소를 보관하거나 제거하는 능력을 포함한 감독을 유지함

수명주기(Lifecycle)

확장과 커스텀 프로토콜 바인딩은 다음 단계를 거쳐 진행돼요.

제안 단계(Proposal Phase)

아무 커뮤니티 멤버나 확장 또는 커스텀 프로토콜 바인딩을 제안할 수 있어요.

  • 이슈 열기(Open an Issue): 메인 a2aproject/A2A 저장소에 다음을 설명하는 이슈를 만들어요.
    • 확장의 목적 또는 바인딩의 전송과 사용 사례를 설명하는 초록
    • 왜 핵심 프로토콜이나 기존 표준 바인딩으로는 달성할 수 없는지 설명하는 동기
    • 초기 기술 접근 또는 스펙 초안
  • 커뮤니티 논의(Community Discussion): 제안은 커뮤니티 피드백과 개선을 위해 열려 있어요.

유지관리자 후원(Maintainer Sponsorship)

제안이 실험 상태로 진행되려면:

  • 후원자 확보(Secure a Sponsor): A2A 유지관리자가 제안을 후원하는 데 동의해야 해요.
  • 저장소 생성(Repository Creation): 후원 유지관리자가 a2aproject 아래 experimental-ext-* 또는 experimental-cpb-* 저장소를 만들어요.
  • 감독(Oversight): 후원 유지관리자가 초기 감독을 제공하고 A2A 설계 원칙과 정렬되도록 해요.

실험 개발(Experimental Development)

실험 상태 동안:

  • 기여자가 스펙과 참조 구현을 반복 개선해요.
  • 실험 아티팩트는 파괴적 변경이 예상된다는 이해와 함께 얼리 어답터가 사용할 수 있어요.
  • 커뮤니티 피드백이 수집되고 반영돼요.
  • 실험 저장소는 비공식 상태를 명확히 표시해야 해요.

공식 상태로 승격(Graduation to Official Status)

실험 확장 또는 바인딩을 공식 상태로 승격하려면:

성숙도 요구사항(Maturity Requirements):

  • 최소한 하나의 프로덕션 품질 참조 구현
  • A2A 표준을 충족하는 문서
  • 커뮤니티 채택 또는 관심의 증거
  • 지속적인 유지에 대한 명확한 유지관리자 약속

승격 제안(Graduation Proposal): a2aproject/A2A에 이슈를 열어 다음을 포함해요.

  • 실험 저장소와 그 구현에 대한 참조
  • 커뮤니티 피드백과 채택 요약
  • 공식 아티팩트의 제안된 유지관리자

TSC 투표(TSC Vote):

  • 제안이 TSC 회의 의제에 추가돼요.
  • 정족수 요구사항(Quorum Requirement): TSC 투표권 멤버의 최소 50%가 참석해야 해요.
  • 승인(Approval): 참석자의 과반수 투표가 필요해요(A2A 거버넌스에 따름).
  • TSC는 최종 투표 전에 수정을 요청할 수 있어요.

수락(Acceptance):

  • (확장) 저장소가 experimental-ext-*에서 ext-*로 이름이 바뀌고, 문서가 A2A 웹사이트의 확장 페이지에 추가돼요.
  • (커스텀 프로토콜 바인딩) 저장소가 experimental-cpb-*에서 cpb-*로 이름이 바뀌고, 문서가 A2A 웹사이트의 커스텀 프로토콜 바인딩 페이지에 추가돼요.

공식 반복(Official Iteration)

공식이 되면 확장과 바인딩을 반복할 수 있어요.

  • 저장소 유지관리자가 일상적인 거버넌스를 책임져요.
  • 변경은 해당 워킹 그룹이 있으면 그를 통해 조정해야 해요(SHOULD).
  • 파괴적 변경은 새 식별자가 필요해요.
  • 파괴적 변경은 TSC 검토가 필요해요.
  • 유지관리자는 구현 업데이트를 위해 SDK 유지관리자와 조정해야 해요(SHOULD).

핵심 프로토콜로 승격(Promotion to Core Protocol)

일부 확장은 결국 핵심 프로토콜 기능으로 전환될 수 있고, 일부 커스텀 프로토콜 바인딩은 핵심 바인딩으로 전환될 수 있어요. 이는 기존 A2A 스펙 개선 과정으로 관리돼요.

  • 표준 스펙 변경 프로세스에 따라 제안이 제출돼요.
  • 제안은 공식 확장 또는 바인딩과 그 채택을 참조해요.
  • 표준 정족수와 과반수 요구사항을 적용한 TSC 투표가 이뤄져요.
  • 모든 확장이나 바인딩이 핵심 포함에 적합한 것은 아니며, 상당수는 무기한 확장 또는 커스텀 바인딩으로 남을 거예요.

SDK 지원

SDK 지원 요구사항은 확장과 공식 커스텀 프로토콜 바인딩 간에 다르며, 이는 프로토콜 생태계에서 서로 다른 역할을 반영해요.

확장(Extensions): A2A SDK는 확장을 구현할 수 있어요(MAY). 구현하는 곳에서:

  • 확장은 기본적으로 비활성화되고 명시적 옵트인이 필요해야 해요.
  • SDK 문서는 지원되는 확장을 나열해야 해요(SHOULD).
  • SDK 유지관리자는 확장 지원 결정에 완전한 자율성을 가져요.
  • 확장 지원은 프로토콜 적합성에 필요하지 않아요.

공식 커스텀 프로토콜 바인딩: A2A SDK는 공식 커스텀 프로토콜 바인딩을 구현해야 해요(SHOULD). 구현하는 곳에서:

  • 커스텀 프로토콜 바인딩은 기본적으로 비활성화되고 명시적 옵트인이 필요해야 해요.
  • SDK 문서는 지원되는 커스텀 프로토콜 바인딩을 나열해야 해요(SHOULD).
  • SDK 유지관리자는 바인딩 지원 결정에 완전한 자율성을 가져요.
  • 커스텀 프로토콜 바인딩 지원은 프로토콜 적합성에 필요하지 않아요.

법적 요구사항(Legal Requirements)

라이선싱(Licensing)

공식 확장과 커스텀 프로토콜 바인딩은 핵심 A2A 프로젝트와 일관되게 Apache 2.0 라이선스로 제공되어야 해요.

기여자 라이선스 허여(Contributor License Grant)

공식 A2A 확장 또는 커스텀 프로토콜 바인딩 저장소에 기여를 제출함으로써, 기여자는 다음을 진술해요.

  • 권리를 허여할 법적 권한이 있음
  • 기여가 원작품이거나 제출할 충분한 권리를 가짐
  • Linux Foundation과 수령인에게 기여를 사용, 복제, 수정, 배포할 영구적, 전 세계적, 비독점적, 로열티 무료 라이선스를 허여함

반독점(Antitrust)

확장 및 커스텀 프로토콜 바인딩 개발자들은 다음을 인정해요.

  • 다른 참여자와 경쟁할 수 있음
  • 어떤 확장이나 바인딩을 구현할 의무가 없음
  • 경쟁하는 확장이나 바인딩을 개발할 자유가 있음
  • 공식 확장 또는 바인딩으로서의 지위가 독점적 관계를 만들지 않음

더 알아보기 (Learn more)