Google이 에이전트 런타임의 아래층만 CNCF에 제출한 이유

Bro's Sharing
, ,
1

9월 8일, Google 엔지니어들이 Agent Substrate를 CNCF Sandbox에 신청했습니다. Kubernetes 위에서 쉬고 있는 에이전트를 재워 메모리와 파일 상태를 저장하고, 필요할 때 준비된 워커에 복원해 적은 수의 워커로 많은 에이전트를 실행하는 런타임입니다.

그 위에는 Task, Workspace, Gateway, Model을 관리하며 실제 에이전트 작업을 실행하는 Agent Executor,

지금의 AX가 있습니다.

두 저장소 다 Apache-2.0이고 현재 외부 기여를 받고 있습니다. 그런데 CNCF에 신청한 것은 아래층인 Substrate뿐입니다. Substrate는 승인 이후 거버넌스와 로드맵, 상표를 CNCF로 넘기고 Google CLA도 DCO로 전환할 계획이지만 AX는 Google CLA를 유지하고 있습니다.

라이선스는 사실 차이가 없었습니다. 아래는 오픈이고 위는 닫혀 있는 구조도 아니었습니다. 둘 다 오픈소스이고 같은 Apache-2.0인데 한쪽만 재단으로 이동했죠. 그렇다면 두개를 구분지은 결정적인 것은 무엇이었을까요?

TL;DR

  1. CNCF Sandbox 신청 범위는 Agent Substrate입니다. 그 위에서 실제 agent workload를 구성하는 AX는 포함되지 않았습니다.

  2. 신청서에서 Google은 이 프로젝트와 연결된 사업 모델을 strictly infrastructure-centric이라고 설명하고 있습니다. Substrate는 어떤 Kubernetes에서도 돌아가고, Google의 사업은 사용자가 구매하고 관리하는 컴퓨트 인프라에서 성립합니다.

  3. 같은 Apache-2.0 라이선스 입니다. 이번에 갈린 것은 라이선스가 아닌 재단 거버넌스의 범위입니다. 하나의 스택 안에서도 재단에 들어간 저장소와 기업이 실제로 의존하는 저장소가 다를 수 있습니다.

[1] 에이전트가 놀고 있는 시간이 돈이 된다

에이전트는 사용자 입력을 기다리고, 모델 응답을 기다리고, 도구 호출이 끝나기를 기다리는 시간이 많습니다. 그런데 그 시간에도 전용 Pod나 VM을 계속 붙잡고 있으면 컴퓨트는 그대로 사용되죠. Substrate는 이때 에이전트를 재워 메모리와 파일 상태를 저장하고, 필요할 때 준비된 Worker에 복원합니다. 신청서는 이 구조로 30~100배의 density를 목표로 한다고 적었고, 현재 저장소의 데모는 약 250개의 actor를 8개의 physical pod에서 실행합니다.

AX는 그 위에서 실제 에이전트 작업을 구성합니다. 어떤 코드를 실행할지, 어떤 Git 저장소와 MCP 서버를 연결할지, 어떤 네트워크를 허용할지, 어떤 모델을 사용할지…를 Task, Workspace, Gateway, Model 같은 리소스로 명시하고 있습니다. 초기에는 코어 아키텍처를 안정화하는 동안 외부 PR을 일시 중단했지만 현재는 다시 외부 contribution을 받고 있고 Google CLA를 요구합니다. Google 모델뿐 아니라 Anthropic 모델도 지원하고 있죠.

하지만 재단으로 가는 길목에서 갈리게 됩니다. CNCF Sandbox 신청 대상은 Substrate입니다. 승인 이후 프로젝트 거버넌스와 로드맵, 상표를 CNCF로 넘기고 Google CLA도 DCO로 전환한다는 계획입니다. AX에는 같은 계획이 공개돼 있지 않습니다.

같은 라이선스인데 재단의 경계에서 차이가 생기게 된 것이죠.

[2] 신청서에는 사업 모델을 묻는 란이 있다.

CNCF Sandbox 신청서에는 Business product or service to project separation이라는 항목이 있습니다. 회사의 사업과 오픈소스 프로젝트의 관계를 설명하는 란입니다. Agent Substrate 신청서에서는 Google의 사업 모델을 strictly infrastructure-centric이라고 기재했습니다. 사용자는 자신이 구매하고 관리하는 표준 compute VM 위에서 오픈소스를 실행하고, Substrate에는 proprietary hook이 없으며 local kind를 포함해 어떤 Kubernetes에서도 돌아간다는 설명입니다.

Substrate가 만드는 30~100배의 density를 사업 쪽에서 읽으면 좀 다르게 보입니다. GKE 문서는 Agent Substrate의 효과를 더 적은 machine에서 더 많은 agent를 실행하고 compute cost를 줄이는 것으로 설명합니다. Agent Substrate 자체에는 추가 요금이 없고 실제 과금은 생성되는 GKE 리소스에 붙습니다. 런타임을 어느 Kubernetes에서든 실행할 수 있게 풀어도 그 아래의 컴퓨트에서 사업을 하는 틀은 그대로 남습니다.

이것이 Google이 Substrate만 CNCF에 낸 이유라고 단정할 근거는 없습니다. 신청서가 밝힌 이관 목적은 단일 회사 소유가 다른 클라우드와 기업의 채택에 만드는 우려를 줄이고 , vendor-neutral governance를 만드는 것입니다.

다만 한 신청서 안에서 두 문장은 같이 존재합니다. 프로젝트는 특정 벤더에 묶이지 않게 만들고, 회사의 사업은 그 프로젝트가 올라가는 인프라에서 성립합니다. 무료와 유료의 경계라기보다 오픈소스가 넓게 퍼져도 사업이 유지되는 것에 가깝습니다.

[3] AX는 왜 같이 가지 않았을까?

여기부터는 공개된 답이 없습니다. Google은 AX를 함께 CNCF에 신청하지 않은 이유를 밝히지 않았습니다.

대신 두 프로젝트를 어디에서 나눴는지는 확인됩니다. AX 공동창작자 Jaana Dogan은 이번 주 Hacker News에서 Substrate에는 generative feature를 넣지 않고, agentic concept이나 identity가 필요한 integration은 그 위의 별도 layer에서 처리한다고 설명했습니다. 범용 실행 인프라는 Substrate에 남고 실제 agent-specific integration은 AX로 올라갑니다.

현재 CNCF로 이동하고 있는 것은 전자입니다. 어느 Kubernetes에서도 돌아가야 하는 범용 실행층은 vendor-neutral governance로 이동 중이고, 모델과 MCP, Workspace, Task처럼 실제 agentic workload를 구성하는 상위층은 Google 조직에 남아 있습니다.

왜 그렇게 나눴는지는 알 수 없지만 어디에서 나눴는지는 확인이 가능합니다.

같은 Apache-2.0인데 한쪽은 재단으로 가고 다른 한쪽은 회사에 남습니다. 라이선스 파일에서는 보이지 않던 차이가 저장소의 소유와 거버넌스에서 나타납니다.

[4] 재단으로 옮기면 거버넌스도 바로 분산될까?

지난달 CNCF가 72개 프로젝트를 분석한 거버넌스 가이던스에서 가장 큰 차이를 만든 숫자는 메인테이너의 조직 분포였습니다. Sandbox 진입 시점에 여러 조직의 메인테이너가 있던 프로젝트는 59.1%가 graduation까지 갔고, 단일 조직 프로젝트는 28.6%였습니다.

Agent Substrate 신청서도 TOC 사전 검토 이후 MAINTAINERS.md에 multi-org representation을 만들었다고 적었습니다. 9월 22일 기준 실제 파일에는 18명이 있습니다. Google 16명, Solo.io 2명. 여러 조직이 들어온 것은 맞지만 Google 비중은 아직 88.9%입니다.

초기 프로젝트에서 한 회사의 메인테이너가 많은 것 자체는 드문 일이 아닙니다. 중요한 것은 프로젝트가 성장하면서 다른 조직의 사람이 실제 메인테이너가 되고 의사결정에 들어오는 구조가 만들어지는가입니다.

재단으로 프로젝트를 옮기는 것과 실제 의사결정권이 여러 조직으로 이동하는 것은 같은 시점에 일어나지 않습니다.

지난 글에서는 초기 오픈소스를 고를 때 GitHub 스타수보다 메인테이너의 소속을 먼저 봤습니다. 이번에는 같은 질문이 한 계단 더 올라갑니다. Apache-2.0인가, CNCF인가만으로는 스택 전체의 통제 구조가 보이지 않습니다. 어떤 저장소가 재단으로 가는지, 실제로 기업이 운영하는 리소스는 어느 저장소에 속하는지, 그 저장소의 의사결정권은 어디에 있는지를 같이 놓으면 같은 라이선스 안에서도 다른 경계가 나타납니다.

[5] 재단 소속과 실제 도입 범위가 다를 때

기업이 오픈소스를 검토할 때 CNCF 같은 재단 소속은 중립성과 지속성을 판단하는 하나의 신호로 쓰입니다. 그런데 하나의 제품처럼 보이는 스택이 여러 프로젝트로 나뉘기 시작하면 이 기준도 복잡해집니다.

Agent Substrate가 CNCF Sandbox에 들어가더라도 AX까지 CNCF 프로젝트가 되는 것은 아닙니다. AX를 함께 사용한다면 운영자가 직접 다루는 Task, Workspace, Gateway, Model은 다른 거버넌스 아래에 있습니다.

“CNCF 프로젝트인가”라는 한 칸으로 스택 전체를 설명하기 어려워지는 이유입니다.

같은 Apache-2.0 안에서도 재단에 들어간 저장소와 실제 기업이 의존하는 저장소가 다를 수 있습니다. 라이선스는 같지만 프로젝트의 다음 결정을 내리는 주체는 다르고, 재단이 보장하는 중립성의 범위도 스택 전체가 아니라 특정 프로젝트까지입니다.

이 글의 해석은 앞으로 검증될 것입니다. Substrate가 실제 CNCF Sandbox에 수락되는지, Google CLA가 DCO로 전환되는지, Google 밖의 maintainer 비중이 늘어나는지, AX도 언젠가 중립 재단으로 이동하는지. 특히 AX까지 같은 거버넌스로 이동한다면 지금 보이는 층의 경계는 다시 읽어야 하겠죠.

지난 글에서는 라이선스보다 메인테이너의 소속을 먼저 봤습니다. 이번에는 재단에 들어갔는가가 아닌 스택의 어디까지 재단에 들어갔는가를 추가하게 되었습니다.

오픈소스인지 확인하는 데는 LICENSE 파일이면 충분할지 모릅니다. 누가 프로젝트의 다음 결정을 내리는지 보려면 거버넌스를 봐야 합니다. 그리고 하나의 스택이 여러 프로젝트로 나뉘기 시작하면, 그 거버넌스가 실제 기업이 사용하는 범위의 어디까지 이어지는지도 달라집니다.

같은 라이선스라고 같은 거버넌스는 아니고, 같은 스택이라고 같은 재단의 경계 안에 있는 것도 아닙니다.

각자의 역할별로 따져볼 것

에이전트 인프라를 검토하는 아키텍트라면 스택을 프로젝트 단위가 아니라 레이어 단위로 그려보세요. 어떤 층이 Kubernetes이고, 어떤 층이 Substrate이고, 어디부터 AX인지 먼저 나눠야 합니다.

조달이나 보안 담당이라면 “CNCF인가”에서 끝내지 말고 재단 governance가 실제 의존 범위 어디까지 내려오는지 확인할 필요가 있습니다.

오픈소스로 사업을 설계하고 있다면 Sandbox 신청서의 Business product or service to project separation 항목을 한번 읽어볼 만합니다. 프로젝트를 어디까지 중립화해도 회사의 사업이 성립하는지 거꾸로 생각하게 만드는 질문입니다.

참고 자료