[기고] 에이전틱 AI 재단에 프로젝트를 제안하기 전 알아 두면 좋은 것들

글로벌 AI 재단은 새 프로젝트를 어떤 과정을 거쳐 받아들일까?

조훈(Hoon Jo), KubernetesLab, CNCF & AAIF 앰버서더

A2A(Agent2Agent, 에이전트끼리 작업을 주고받는 방식을 정한 규약) 프로토콜이 2026년 8월 17일부로 에이전틱 AI 재단(AAIF, Agentic AI Foundation)의 호스티드 프로젝트가 되었습니다[1].

그럼 호스티드 프로젝트란 무엇일까요? 호스티드 프로젝트는 특정 회사가 아니라 재단이 중립적인 위치에서 관리하는 프로젝트를 말합니다. 프로젝트의 상표와 자산을 AAIF의 상위 재단인 리눅스 재단(Linux Foundation)에 넘기고 프로젝트의 운영 규칙을 정한 기술 헌장(Technical Charter)을 따르는 대신 재단이 제공하는 인프라를 사용하고 프로젝트의 성숙도에 따라 멘토링, 자금, 홍보 그리고 보안 점검 같은 지원을 받게 됩니다. 그래서 한 회사가 만든 프로젝트라도 재단 프로젝트가 되면 여러 회사가 같은 조건에서 함께 참여할 수 있습니다.

그런데 이 소식을 보다가 문득 어떤 과정을 거쳐야 AAIF의 호스티드 프로젝트가 되는지를 한국어로 자세히 설명한 자료가 없다는 것을 알게 되었습니다. 이 절차는 지금 한국에서도 관심이 많은 AI와 관련된 중요한 내용이라고 생각했고 정리해 두면 오픈업과 함께하는 기관을 비롯해 국내의 많은 오픈 소스 협의체에 큰 도움이 될 것이라고 판단해서 이 기고를 쓰게 되었습니다. 한국어 자료는 없었지만 실제로 찾아보니 누가 결정하는지, 어떤 기준으로 심사하는지 그리고 지금 어떤 프로젝트가 심사 중인지까지 대부분이 공개되어 있었습니다. 절차는 문서로 있고 제안서는 누구나 읽을 수 있는 GitHub 이슈로 올라오며 각 제안이 어디까지 진행되었는지는 재단이 GitHub에 공개한 프로젝트 보드에 나옵니다. 그래서 이 글에서는 그 기록을 바탕으로 에이전틱 AI 재단에 프로젝트를 제안하기 전에 알아 두면 좋을 것을 정리해 보겠습니다.

먼저 A2A가 실제로 거친 과정을 살펴보고 제안 절차와 수명주기 단계, 새로 생긴 Sandbox 단계 그리고 제안의 진행 상태를 확인하는 방법을 차례로 본 뒤 마지막에 제안을 준비하실 때 확인할 것을 정리하겠습니다.

다만 한 가지를 먼저 말씀드리는 게 좋겠습니다. 제안과 관련된 기록은 계속 갱신되기 때문에 제가 이 글을 작성하는 동안에도 여러 번 바뀌었습니다. 8월에 처음 정리한 내용과 9월, 10월에 다시 확인한 내용이 여러 곳에서 달랐고 그 차이 자체가 이러한 절차를 이해하는 데 큰 도움이 되었습니다. 이런 이유로 본문에 나오는 제안 건수는 2026년 10월 12일에 확인한 값으로 적었고 각 제안의 날짜와 진행 상태는 10월 26일 기준으로 반영했습니다. 그리고 날짜는 GitHub 기록의 기준인 협정 세계시(UTC, Coordinated Universal Time)를 따랐는데 GitHub 화면은 보는 사람의 시간대로 날짜를 표시해서 한국에서 이슈를 열면 하루 늦은 날짜로 보이는 경우가 있습니다.

A2A가 재단 프로젝트가 되기까지

우선 A2A부터 보겠습니다. 구글(Google)이 만든 A2A의 제안서는 2026년 6월 18일에 GitHub 이슈 #37로 올라왔습니다[2]. 7월 15일에 기술위원회(TC, Technical Committee) 표결을 통과했고 8월 4일에 이사회(GB, Governing Board)가 최종 승인했으며 공개 발표는 8월 17일이었습니다. 접수부터 발표까지 2개월이 걸렸고 그 사이의 주요 결정은 그 이슈에 그때그때 기록되었습니다

여기서 눈에 띄는 것이 2가지 있는데 먼저 서류 절차가 생각보다 간단했습니다. 재단 직원이 이슈에 “A2A는 이미 리눅스 재단 프로젝트라 추가 서류가 필요 없다”고 적었고 기여 계약(Contribution Agreement, 앞에서 말한 상표와 자산 이전을 약속하는 계약)의 서명이 끝나지 않았다는 라벨도 붙은 적이 없으니 A2A는 기존 리눅스 재단 프로젝트로서 이미 갖춘 서류를 그대로 활용한 것 같습니다. 그리고 A2A가 처음 받은 수명주기 단계(재단이 프로젝트의 성숙도에 따라 나눈 단계로 아래 노트에서 설명합니다)도 제 예상과 달랐습니다. A2A는 150곳이 넘는 조직의 지지를 받으며 재단 프로젝트가 되었는데도 최상위 단계가 아니라 Growth 단계로 시작했습니다. 이슈의 라벨 이력을 보면 6월 25일에 Impact 라벨이 붙었다가 7월 9일에 제거되었고 7월 15일에 Growth로 승인되었습니다. Impact 라벨은 AAIF 재단 CTO(공동 창립자인 마닉 서타니, Manik Surtani)가 붙였으니 재단이 처음에 Impact로 분류했다가 심사 과정에서 한 단계 낮춘 것으로 추정됩니다. 재단 프로젝트가 되는 것과 어느 단계로 시작하는지는 별개라는 것을 알 수 있습니다.

앞에서 본 2개월이 보통인지 비교해 보기 위해 그보다 먼저 재단 프로젝트가 된 agentgateway (Solo.io가 기부한 에이전트용 게이트웨이)를 보면 제안은 4월 9일에 올라왔고 기술위원회 표결을 거쳐 5월 21일에 이사회가 승인했으며 발표는 6월 4일이었습니다[3]. 접수부터 승인까지 42일이 걸렸으니 A2A의 47일과 비슷하고 승인에서 발표까지도 각각 14일과 13일로 약 2주였습니다. 그 뒤에는 블룸버그(Bloomberg)와 Tetrate가 함께 시작한 게이트웨이인 Agent Router가 재단 프로젝트가 되었습니다[4]. 프록시 소프트웨어인 Envoy를 기반으로 만든 이 프로젝트는 접수부터 승인까지 116일이 걸려 앞의 둘과 달랐지만 이사회 승인(8월 18일)에서 발표(9월 9일)까지는 22일로 조금 더 길었을 뿐입니다. 발표 시점을 정한 규정은 없지만 이 프로젝트들은 승인 뒤 13~22일 사이에 발표되었습니다.

  [그림 1] AAIF 수명주기 단계와 단계별 채택 기준[5]

제안 절차를 정한 문서와 6개 과정

앞에서 본 A2A의 진행을 정한 문서는 기술위원회 저장소(aaif/technical-committee)에 있는 프로젝트 제안 절차 문서(project_proposal_process.md)[6]와프로젝트 수명주기 정책 문서(project-lifecycle-policy.md)[7]입니다. 이 가운데 수명주기 정책 문서는 제안을 올리는 제안 저장소(aaif/project-proposals)[8]에도 원래 같은 이름으로 하나 더 있었고 그 내용이 서로 달랐는데, 재단이 10월 15일에 문서를 정리하면서 제안 저장소 쪽 문서에는 기술위원회 저장소로 옮겼다는 안내와 그 저장소 문서들의 링크만 남겼습니다[9]. 따라서 제안을 생각하신다면 기술위원회 저장소의 절차 문서와 정책 문서부터 읽어 보시는 게 좋을 것 같습니다.

[그림 2] AAIF 프로젝트 제안 절차와 관련 저장소

이 문서들에 따르면 제안서는 GitHub 이슈 1개로 올라오고 접수부터 종결까지 모든 과정이 그 이슈에 기록된다고 합니다. 즉 공식적인 진행 상황은 그 이슈 하나에서 확인할 수 있습니다. 다만 표결은 리눅스 재단의 투표 도구인 LFX에서 이루어져 이슈에는 결과만 남고 기여 계약 서류 작업도 이슈 밖에서 진행됩니다. 이렇게 회의 없이 이슈와 투표 도구로 진행하는 데는 이유가 있습니다. 기술위원회 위원들이 여러 지역에 있어 시간대가 다르고 제안이 많아서 제안마다 회의를 열기도 어렵기 때문에, 절차는 의도적으로 비동기로 진행하도록 설계되어 있습니다. 이 절차는 전체 6개 과정으로 되어 있는데, 순서대로 표로 정리하면 다음과 같습니다.

이 6개 과정과 함께 챙겨야 할 것이 기여 계약 서류입니다. 앞에서 설명한 기여 계약서와 기술 헌장을 말하는데 첫 번째 과정을 통과하면 리눅스 재단 법무팀이 초안을 만들어 제안자 측 법무 담당자와 검토하기 시작합니다. 이 서류 작업은 위 과정과 함께 진행되는데 절차 문서상으로는 이사회 표결이 시작되기 전에 서명할 수 있는 상태가 되어야 합니다. 지금까지의 운영을 보면 5월의 Agent Client Protocol(#1, Zed가 만든 코드 에디터와 코딩 에이전트 사이의 통신 규약)과 Agent Router(#18)부터 최근 오픈AI(OpenAI)의 Open Responses(#41)와 앤트로픽(Anthropic)의 Agent Skills(#47)까지 기술위원회 승인 뒤에 서류를 마무리하고 그다음에 이사회에 올리겠다는 안내가 붙었으니 실제로도 이 시점을 지키고 있는 것으로 보입니다. 그래서 기여 계약서와 기술 헌장은 이사회 표결 전까지 법무 검토를 마치고 서명할 수 있게 준비해 두시기 바랍니다.

서류 말고 하나 더 챙겨야 할 중요한 부분이 있는데, 기술위원회 회의에서 진행하는 프로젝트에 관련한 실제 프레젠테이션입니다. 질의응답 기간 중에 위원 1명이라도 해당 프로젝트에 대한 설명을 요청한다면 제안자는 다음 기술위원회 정기 회의에 참석해 10분 동안 프로젝트를 소개하고 10~15분 동안 질문을 받아야 합니다. 위원들은 질문으로 재단의 사명에 맞는지, 거버넌스가 얼마나 성숙했는지, 커뮤니티가 활발히 활동하는지 그리고 희망하는 단계가 적절한지를 검토하고 나서 기술위원회 내부에서 표결을 통해 제안을 받아들일지와 어느 단계로 시작하게 할지를 정합니다. 이처럼 프레젠테이션은 위원의 요청이 있을 때만 일정이 잡히므로 자료는 미리 준비하시되 요청이 없으면 하지 않게 될 수도 있습니다.

다시 6개 과정 가운데 두 번째인 질의응답 기간을 보면 놓치기 쉬운 기준이 있습니다. 제안이 표결 과정으로 진행되려면 위원 4명의 확인이 필요하고 침묵은 동의로 보지 않는다고 되어 있습니다. 즉 위원이 이슈에 질문을 남기거나, 검토했고 질문은 없다는 코멘트를 남기거나, 제안 요약 코멘트에 승인 반응을 눌러야 확인 1건으로 세고 아무 반응이 없는 위원은 반대가 없더라도 4명으로 세지 않습니다. 이 기준을 못 채우면 의장단이 그 프로젝트를 지지해 줄 위원을 찾고 그 위원이 지지하는 형태로 기간을 다시 시작합니다. 기간이 끝나도록 지지하는 위원이 없으면 제안은 반려로 처리됩니다. 절차 문서에는 질의응답 기간을 다 거치고도 지지하겠다는 위원이 1명도 없다면 그 자체가 프로젝트가 아직 재단 프로젝트가 될 준비가 되지 않았거나 재단과 맞지 않는다는 분명한 근거라고 적혀 있습니다. 결국 다른 준비는 제안자가 직접 진행하는 부분이지만 위원의 지지는 기술위원회 위원들이 이슈에서 프로젝트를 살펴본 뒤 보내 주는 응답을 받아야 하는 부분입니다.

앞에서 발표 시점을 정한 규정은 없다고 했지만 발표의 전제 조건은 정해져 있습니다. 승인, 서류, 자산 이전 그리고 온보딩이 모두 끝나기 전에는 재단이 아무것도 발표하지 않도록 되어 있어서 발표가 승인보다 늦게 나옵니다.
표의 세 번째 과정에서 기술위원회가 시작 단계도 함께 권고한다고 했는데 그럼 지금까지 이 절차를 통과한 프로젝트들은 어느 수명주기 단계에서 시작했을까요? 발표까지 마친 프로젝트는 7개인데 시작 단계는 서로 다릅니다. 구체적으로 보면 agentgateway, A2A, Agent Router 그리고 허깅페이스(Hugging Face)와 메타(Meta)가 함께 만든 OpenEnv는 Growth 단계로 승인되었고 오픈AI의 Open Responses와 앤트로픽의 Agent Skills는 Impact 단계를 받았습니다. 그리고 알리바바(Alibaba)의 OpenSandbox는 Sandbox 단계로 시작한 첫 프로젝트입니다. 그런데 단계는 재단 웹사이트의 프로젝트 목록에 표시되지 않고 발표문마다 단계를 적은 것과 적지 않은 것이 섞여 있습니다. agentgateway의 경우 발표와 같은 날 올라온 설계 소개 글에[10] Growth 단계로 승인되었다고 적혀 있지만 A2A와 Agent Router의 발표문에는 단계가 없어서 저는 처음에 A2A의 단계를 제안 이슈의 라벨에서 읽었습니다. 지금은 기술위원회 저장소의 README에도 프로젝트별 단계가 표로 정리되어 있지만[11] 10월 22일에 발표된 프로젝트 4개는 10월 26일까지 아직 반영되지 않아서 이 프로젝트들의 단계는 제안 이슈의 라벨로 확인했습니다. 그러니 단계를 확인하실 때는 README와 라벨을 함께 보시는 게 정확할 것 같습니다.

새로 생긴 Sandbox 단계

이 글을 정리하기 시작한 8월까지만 해도 정책 문서상 새 프로젝트가 처음 시작할 수 있는 단계는 Growth와 Impact 2개 뿐이었습니다. 그런데 9월 1일에 AAIF 블로그에 “Catch Them Early”라는 문구로 시작하는 글이 올라왔습니다[12]. Growth보다 낮은 Sandbox 단계를 새로 둔다는 발표였고 새 프로젝트를 받는 기존 기준에서는 “대규모 프로덕션 사용”이 필요해서 이제 막 만들어진 프로젝트가 통과할 수 없었다는 문제 제기로 시작했습니다. 그 발표를 반영한 기술위원회 저장소의 정책 문서를 보면 Sandbox의 요건은 오픈 소스 이니셔티브(OSI, Open Source Initiative)가 승인한 허용형 라이선스(permissive license), 동작하는 구현, 꾸준히 커밋하는 메인테이너 1명 그리고 1~2쪽 분량의 문서입니다. OSI는 어떤 라이선스를 오픈소스로 인정할지 심사해 승인하는 비영리 단체입니다[13]. 허용형 라이선스는 MIT나 Apache 2.0처럼 가져다 이용한 쪽이 자기 코드까지 같은 라이선스로 공개할 의무가 없는 라이선스를 말합니다. 그리고 요건의 1~2쪽 문서에는 누가 사용할 것인지와 함께 외부에서 처음 보인 관심이나 그 프로젝트가 왜 필요한지를 설득력 있게 설명한 내용을 담아야 합니다.

요건이 가벼운 만큼 Sandbox 프로젝트가 재단에서 받는 지원도 빌드와 테스트를 자동으로 돌리는 CI(Continuous Integration) 같은 기본 인프라 정도이고 기술위원회 위원의 멘토링, 재단의 자금 지원, 재단 차원의 홍보 그리고 재단이 제공하는 보안 점검은 이 단계에서 받을 수 없습니다. 재단의 지원은 Growth 단계부터 본격적으로 시작되는데 Growth 프로젝트는 기술위원회의 멘토링을 받고 이사회 승인에 따라 재단 자원도 사용할 수 있습니다. 그 대신 Sandbox 프로젝트는 6개월 뒤에 점검을 받고 12개월 안에 Growth를 신청해야 하며 그 기한을 넘기면 기술위원회가 존속 여부를 논의합니다.

같은 발표에서 Growth의 요건도 수정해서 “대규모”라는 조건은 이제 Impact 단계에만 남기고 Growth는 서로 관계없는 조직 2곳 이상의 프로덕션 사용이 있으면 되도록 바뀌었습니다.

단계가 늘었지만 신청 방법은 기존과 같습니다. 발표 글의 신청 링크를 누르면 재단 웹사이트의 프로젝트 제출 안내 페이지[14]로 가는데 그 페이지의 신청 버튼도 제안 저장소의 GitHub 이슈 양식으로 이어집니다. 그래서 Sandbox도 Growth나 Impact와 같은 이슈 양식으로 신청하고 원하는 단계는 10월 15일에 새로 생긴 희망 단계(Preferred Lifecycle Stage) 칸에서 지정하시면 됩니다. 이 칸은 선택 항목이라 비워 두셔도 되지만 같은 날 필수 항목으로 추가된 단계 근거(Lifecycle Stage Evidence) 칸에는 단계별로 필요한 근거 문서를 연결하셔야 합니다. 또 희망 단계를 지정하지 않으셨다면 지금 어느 단계의 기준을 충족하는지도 이 칸에 적으셔야 합니다.

제안의 진행 상태를 확인하는 방법

이번에는 제안이 어디까지 진행되었는지를 보드와 라벨로 확인하는 방법을 보겠습니다. 우선 이슈가 열려 있는지 닫혔는지만 보고는 진행 상황을 알 수 없습니다. 닫힌 이슈가 모두 반려된 것은 아니고(승인되어 종결된 것도 있습니다) 열려 있는 이슈 중에도 이미 결론이 난 것이 있으므로 진행 상황은 라벨로 확인해야 합니다. 대표적인 진행 라벨은 New, Under Review, TC Vote, TC Approved, GB Vote그리고 Approved이고 기여 계약의 서명 여부는 별도 라벨로 표시됩니다. 이 중 GB Vote는 이사회를 통과했다는 뜻이 아니라 이사회 표결을 앞두고 있거나 진행 중이라는 뜻이라서 잘못 읽기 쉽습니다. 그리고 붙는 순서가 늘 이대로인 것도 아니어서 Agent Client Protocol(#1)은 GB Vote가 5월 5일에, TC Approved가 5월 21일에 붙었습니다.

공개 보드[15]에서는 제안이 재단 직원 검토, 기술위원회 표결, 이사회 표결, 기여 계약 서명 대기, 온보딩 진행 그리고 완료 같은 열로 나뉘어 표시되는데 라벨과 열이 다른 경우가 있습니다. 앞에서 본 #1이 그렇습니다. 이벤트(이슈 타임라인에 남는 라벨 변경 기록)상 이 이슈의 라벨은 5월 21일 이후 바뀐 적이 없어서 TC Approved와 GB Vote만 보면 이사회 표결이 진행 중인 것처럼 보이고 Paperwork-in-review와 서명 미완료 라벨을 보면 서류를 기다리는 것처럼 보입니다. 그런데 보드에서는 기술위원회나 이사회가 요청한 정보를 기다리는 상태(Waiting) 열에 놓여 있습니다. 그래서 제안이 지금 어느 과정에 있는지는 라벨과 열을 함께 보셔야 정확하게 알 수 있습니다.

[그림 3] 2026년 10월 26일 시점의 AAIF 제안 공개 보드(일부)

* https://github.com/orgs/aaif/projects/1

다만 라벨과 공개 보드를 함께 보아도 지금 상태를 파악하기 어려운 경우가 있는데 10월 22일에 재단 프로젝트로 발표된 4개가 그렇습니다. 그림 3에서 보듯이 10월 26일 현재 이 4개는 아직 완료(Done) 열에 없고 OpenSandbox(#26)는 온보딩 진행 중(Onboarding in Progress), Open Responses(#41)와 Agent Skills(#47)는 기여 계약 서명 대기(Contributor Agreement Unsigned) 그리고 OpenEnv(#50)는 이사회 표결(GB Voting) 열에 있습니다. 라벨도 OpenSandbox를 빼면 이사회 표결과 서명 미완료 상태로 남아 있어서 공개 기록만으로는 이사회 승인과 서명이 언제 끝났는지 알 수 없습니다. 이처럼 재단이 발표한 뒤에도 보드와 라벨이 바로 갱신되지 않을 수 있으니 재단의 발표문과 코멘트 스레드까지 읽어 보시는 게 좋겠습니다. 또 라벨의 이름이 바뀌면 그 라벨이 붙어 있던 이슈의 표시도 함께 바뀌어서 지금 붙어 있는 라벨만으로는 과거에 어떤 상태였는지 알기 어려울 수 있습니다.

이런 점을 감안해 라벨 이벤트와 코멘트를 함께 보면 각 제안이 언제 어느 표결을 통과했는지 날짜를 확인할 수 있습니다. 그 날짜로 기술위원회 승인을 받은 제안들의 실제 처리 기간을 표로 정리하면 다음과 같습니다

기술위원회 승인일은 승인 라벨이 붙은 날과 재단 직원이 승인을 알린 코멘트 중 이른 날로 적었습니다. 그래서 #1은 라벨이 붙은 5월 21일이 아니라 승인 코멘트가 달린 5월 5일로 적었습니다. 또 #41, #47 그리고 #50은 10월 22일에 발표되었지만 10월 26일까지 이슈에 최종 승인 라벨이 붙지 않아서 처리 기간을 최종 승인일 대신 발표일까지로 계산했고 #1의 경과 일수도 10월 26일을 기준으로 세어 확인했습니다. 표를 다시 보면 같은 절차인데도 기술위원회 승인까지 걸린 기간이 앤트로픽의 Agent Skills는 7일, 알리바바의 OpenSandbox는 78일로 크게 다릅니다. 게다가 Agent Router처럼 기술위원회 승인 뒤 최종 승인까지 3개월 가까이 걸리거나 Agent Client Protocol처럼 5개월이 넘도록 최종 승인이 나지 않은 제안도 있으니 일정을 잡으실 때는 여유를 두시는 게 좋을 것 같습니다.

표에는 없는 변화도 있습니다. 심사 중에 이름이 바뀐 사례도 있는데 Agent Router는 7월 23일에 Envoy AI Gateway에서 지금 이름으로 바뀌었고 8월 18일에 최종 승인되었습니다. 분산 애플리케이션 런타임인 Dapr 쪽에서 올린 #34도 8월 26일에 이슈 제목이 Dapr Agents에서 Durable Agents로 바뀌었는데 실제 이름 변경은 승인을 조건으로 한 것이었습니다. 그런데 이 제안은 9월 3일에 끝난 기술위원회 표결을 통과하지 못해 9월 11일에 반려되었고 바뀐 이름도 확정되지 않았습니다. 이름뿐 아니라 단계가 바뀐 사례도 있는데 앞서 본 A2A(Impact에서 Growth로)와 OpenSandbox(5월에 Growth로 분류되었다가 Sandbox가 공식 발표되기 전인 7월에 Sandbox로 다시 분류됨)가 그렇습니다.

진행된 제안과 반려된 제안의 차이

진행된 제안과 반려된 제안이 어떻게 다른지는 제가 가장 궁금했던 부분입니다. 먼저 전체 규모를 보면 2026년 10월 12일 기준으로 제안 저장소에는 풀 리퀘스트를 뺀 이슈가 47건 있습니다. 그 가운데 반려 라벨이 붙은 것이 27건, 승인이 3건, 심사 중이 14건이며 나머지 3건은 보류, 중복 그리고 라벨 없이 닫힌 것이 1건씩이라 반려가 절반을 넘습니다. 9월 9일에 세어 확인했을 때는 33건 중 17건이었으니 한 달 사이에 이슈 14건이 새로 올라왔고 반려도 10건이 늘어 반려 비율은 52%에서 57%로 오히려 높아졌습니다.  

[그림 4] AAIF 프로젝트 제안의 진행 상태와 주요 반려 이유

그렇다면 무엇이 진행 여부를 나누었을까요? 10월 12일까지 기술위원회 승인을 받은 제안 8건은 예외 없이 회사나 단체가 뒷받침하고 있습니다. Solo.io, 구글, Tetrate, Zed, 알리바바, 오픈AI 그리고 앤트로픽이 그렇고 10월 6일에 기술위원회 승인을 받은 OpenEnv(#50)도 허깅페이스와 메타가 함께 만든 프로젝트입니다. 누가 올렸는지를 보아도 비슷한데 제안자를 확인할 수 있었던 Agent Client Protocol, OpenSandbox 그리고 Agent Router는 제안자가 그 프로젝트의 메인테이너였고 agentgateway는 그 프로젝트를 시작한 Solo.io에서 올렸습니다.

그에 반해 진행되지 못한 제안 중에는 제안자가 직접 작성한 명세를 개인 계정이나 그 명세만을 위해 만든 조직 계정에 올린 경우가 많습니다. 내용이 꼼꼼한 것이 많고 수만 자에 이르는 것도 있으니 분량이 모자라서 반려된 것은 아니고 그보다는 그 명세를 제안자 말고 구현하거나 사용하는 곳이 있는지가 중요했던 것 같습니다. 명세는 다른 사람들이 실제로 구현해서 활용해야 표준이 되는데 절차상 채택 증거가 필요하므로 그 근거를 함께 보여 주시면 심사에서 유리할 것으로 보입니다.

다만 회사나 단체가 뒷받침한다고 해서 모두 통과하는 것은 아닙니다. 앞에서 이름이 바뀐 사례로 본 Dapr 쪽 제안(#34)은 Dapr를 함께 만든 사람이 올렸고 메인테이너 조직과 관계없는 프로덕션 사용처도 있었지만 기술위원회 표결을 통과하지 못했습니다[16]. 반려 코멘트를 보면 제안자는 이 프로젝트를 여러 에이전트 프레임워크가 공통으로 사용하는 기반으로 소개했습니다. 하지만 이 프로젝트가 보장하려던 기능, 곧 작업이 중간에 멈춰도 저장된 상태에서 이어서 실행되는 기능은 당시 Dapr Workflow 1개에서만 확인되었습니다. 특히 같은 기능을 만드는 다른 프로젝트들의 커뮤니티가 이것을 쓰겠다는 증거가 없었던 점이 결정적이었다고 적혀 있습니다. 이 내용을 보면 기술위원회는 한 조직만 사용하는 해결책인지 여러 곳이 함께 사용하는 해결책인지를 확인한 것으로 보이고 앞에서 본 개인 계정에 올라온 명세 제안들에도 같은 기준이 적용되었을 것 같습니다.

반려 코멘트에 적힌 이유를 보면 여러 조직의 참여와 실제 사용 증거가 부족하다는 이유가 가장 많았고 공개 이력이 짧거나 구현 없이 명세만 있는 경우가 그 뒤를 이었습니다(그림 4). 이런 코멘트는 5월부터 AAIF 재단 CTO가 반려 이유와 함께 무엇을 준비하면 좋을지를 적어 달아 왔고 그 코멘트를 읽어 보시면 무엇이 부족했는지를 구체적으로 확인하실 수 있습니다. 그 형식은 이 글을 작성하는 사이에 조금 달라져서 9월 26일부터는 “다시 제출하려면 다음이 필요하다(To resubmit, we’d want to see)”는 제목 아래 요구 사항을 정리하고 Too Early 라벨을 함께 붙이기도 합니다. 이 라벨은 프로젝트가 아직 재단 프로젝트가 되기에는 이르다는 뜻이라 단순한 반려보다는 피드백을 받아 더 준비한 뒤 다시 신청하라는 안내에 가깝습니다.

그 코멘트에서 하나 더 볼 것이 재신청 조건인데 이 부분은 문서에 적힌 내용과 실제 운영에 차이가 있습니다. 절차 문서에는 반려된 제안을 충분히 개선한 뒤 3개월이 지나야 다시 제출할 수 있다고 적혀 있습니다. 그런데 9월 이후의 반려 코멘트 8건에는 다시 신청하기까지 기다려야 하는 대기 기간이 없고 다시 신청하면 처음부터 새로 검토하겠다는 안내가 있었습니다. 대신 9월 말 이후 반려된 막 시작한 프로젝트 여러 건(#31, #32, #40, #44, #45, #49)에는 약 3개월 동안 꾸준히 쌓인 공개 커밋 이력을 보고 싶다는 안내가 함께 붙었습니다. 그래서 언제든 다시 신청할 수는 있지만 실제로는 3개월 정도 공개 이력을 쌓은 뒤에 신청하시는 게 좋을 것 같습니다.

제안을 준비하실 때 확인할 것

여기까지 읽은 기록을 바탕으로 제안을 준비하실 때 확인할 것을 정리해 보겠습니다. 제안서를 바로 쓰기보다는 다음 몇 가지를 먼저 알아 두시면 준비가 훨씬 수월할 것 같습니다.

첫 번째로 이미 올라온 제안 읽어 보기

지금 심사 중이거나 반려된 제안은 누구나 읽을 수 있으니 한 시간만 들여 읽어 보셔도 이 글보다 많은 것을 확인하실 수 있습니다. 특히 앞에서 본 반려 코멘트에는 다시 신청하려면 무엇을 갖춰야 하는지까지 적혀 있어서 준비하실 때 도움이 될 것 같습니다.

두 번째로 제출 요건에 프로젝트를 맞춰 보기

제출 요건은 OSI가 승인한 허용형 라이선스나 공개 명세, 문서화된 거버넌스 모델과 이름을 밝힌 메인테이너, 공개 이슈 트래커 그리고 채택 증거이고 원하는 단계는 정해져 있을 때만 지정하시면 됩니다(단계 근거 칸은 단계를 지정하지 않아도 채우셔야 합니다). 절차 문서에 따르면 접수 검토에서는 자동화된 에이전트가 이 항목이 갖춰졌는지를 확인해 그 결과를 이슈에 남기고 AAIF 재단 CTO가 재단의 사명에 맞는지와 원하는 단계가 타당해 보이는지도 함께 살펴본다고 합니다. 따라서 항목을 형식만 채우기보다 각 항목의 근거까지 갖춰 두시기 바랍니다.

세 번째로 제안하려는 프로젝트의 사용자 확인하기

제안자 말고도 이 프로젝트를 실제로 사용하고 있는 조직이나 개인이 있는지 그리고 그 이름을 밝힐 수 있는지를 먼저 확인해 보시는 게 좋겠습니다. 앞에서 본 진행된 제안과 반려된 제안의 차이도 결국 이 부분에서 나온 것으로 보이기 때문입니다. 아직 그런 사용자가 없다면 제안보다 실제로 이용하는 곳을 늘리시는 게 먼저일 것 같습니다. Sandbox가 생겼다고 해서 이 확인이 필요 없어진 것은 아닙니다. 물론 Sandbox 요건에는 아직 사용처가 없어도 그 프로젝트가 왜 필요한지를 설득력 있게 설명하면 신청할 수 있다고 되어 있습니다. 그래도 앞에서 본 것처럼 3개월 공개 커밋 이력을 요구한 반려가 여러 건 있었으니 그 설명과 함께 꾸준한 공개 커밋 이력을 갖추시는 편이 안전하겠습니다.

마지막으로 프로젝트와 워킹그룹 중 제안할 트랙 정하기

프로젝트 제안은 제안 저장소(aaif/project-proposals)에 올리시면 됩니다. 만들려는 것이 프로젝트가 아니라 워킹그룹(Working Group, 특정 주제를 함께 논의하는 재단 안의 모임)이라면 트랙이 다른데 워킹그룹 제안은 워킹그룹 제안 저장소(aaif/working-group-proposals)[17]에 올리고 AAIF 회원 조직만 제안할 수 있습니다. 그 저장소에는 10월 15일과 20일에 처음으로 워킹그룹 제안 2건이 접수되었지만 제안 저장소에 올라왔던 워킹그룹 제안(#38)은 9월 28일에 기존 워킹그룹에 참여해 달라는 안내와 함께 반려되었습니다. 재단 웹사이트의 워킹그룹 안내 페이지에[18] 워킹그룹 제안 방법도 나와 있고 10월 11일에는 기술위원회 저장소에 워킹그룹 수명주기 정책 문서도 새로 올라왔으니[19]함께 확인해 보시면 됩니다.

지금 AAIF가 호스팅하는 프로젝트

지금 AAIF가 호스팅하는 프로젝트는 10개입니다[20]. 이 가운데 재단을 만들 때 기부된 프로젝트는 에이전트가 도구를 호출하는 방식을 정한 MCP(Model Context Protocol), 블록(Block)이 만든 에이전트 goose 그리고 코딩 에이전트에 주는 지침 파일 형식인 AGENTS.md이고 나머지 7개는 위의 절차를 거쳐 호스티드 프로젝트가 되었습니다. 그중 3개는 앞에서 본 agentgateway, A2A 그리고 Agent Router이고 다른 4개는 재단이 10월 22일에 미국 산호세의 AGNTCon+MCPCon North America 행사에서 한꺼번에 발표한 Open Responses, Agent Skills, OpenEnv 그리고 OpenSandbox입니다[21]. 이 목록이 중요한 이유는 무엇보다 MCP, A2A 그리고 그 둘 앞에 두는 게이트웨이처럼 에이전트에 필요한 기반이 한곳에서 함께 발전하기 때문입니다. 여기에 스킬과 MCP 설정을 묶어 배포하는 플러그인 형식인 Agent Plugins(#56)도 10월 20일에 기술위원회를 통과해 이 목록은 앞으로도 늘어날 것으로 보입니다.

그러니 직접 메인테이너로 관리하고 있는 오픈 소스 프로젝트를 이미 다른 회사나 조직에서 사용하고 있다면 이 절차가 생각보다 길지 않다고 느끼실 수도 있을 것 같습니다. 절차 문서와 제안의 주요 기록이 공개되어 있어 미리 준비할 수 있고 기간이 길어지는 경우도 있지만 순조로운 경우에는 접수부터 발표까지 A2A는 2개월 만에 절차를 마쳤고 Agent Skills와 OpenEnv는 한 달도 걸리지 않았습니다.

보다 상세한 내용은 아래 참고 자료에 정리한 문서와 기록에 남아 있으니 참고하시기 바랍니다.

이 글이 AAIF에 프로젝트를 제안하려는 국내 기관과 오픈소스 협의체 그리고 재단이 프로젝트를 받아들이는 방식을 이해하려는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

※ AAIF가 제안 절차와 관련 문서를 계속 정리하고 있어서 이 글을 작성한 뒤에도 내용이 달라질 수 있습니다. 제안을 준비하실 때는 기술위원회 저장소의 최신 문서를 다시 확인해 보시는 게 정확할 것 같습니다.

조훈(Hoon Jo) KubernetesLab (kuberneteslab.dev) 클라우드 네이티브 컴퓨팅 재단(CNCF) 앰버서더 에이전틱 AI 재단 (AAIF) 앰버서더 클라우드 네이티브 교육 앰버서더 (kubestronaut) 『AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드』(길벗) 외 4권의 주요 저자