Goose, 51k 스타 범용 AI 에이전트가 Linux Foundation으로 간 이유

AI 에이전트가 전문화되는 시대는 끝났다. 이제 문제는 “하나의 에이전트로 얼마나 많은 일을 할 수 있는가”가 아니라, “얼마나 많은 도구를 에이전트가 스스로 찾아 쓸 수 있는가”가 되고 있다.

올해 4월, Block(Square)이 Goose를 Linux Foundation의 Agentic AI Foundation(AAIF)에 기증했다. 같은 날 Anthropic의 MCP와 OpenAI의 AGENTS.md도 같은 재단으로 이전됐다. 이 세 프로젝트가 같은 조직 아래 모였다는 사실 자체가 업계의 큰 방향성을 보여준다. AI 에이전트 생태계가 “만들기”에서 “연결하기”로 축을 이동하고 있다.

Goose를 처음 본 건 작년 말. 당시엔 “또 하나의 코딩 에이전트” 정도로 봤다. Claude Code가 있고, Cursor가 있고, Codex가 있는 마당에. 하지만 시간이 지나면서 Goose의 포지셔닝이 조금 다르다는 걸 알게 됐다. Goose는 코딩 에이전트가 아니라, 범용 에이전트다.

범용 에이전트가 필요한 이유

대부분의 AI 에이전트는 특정 도메인에 최적화돼 있다. Claude Code는 터미널과 코드 리뷰에 특화됐고, ChatGPT Codex는 에디터와의 통합에 강하다. Cursor는 IDE 안에서의 경험에 집중한다. 각자의 영역에서는 훌륭하지만, 경계를 넘어서면 약해진다.

Goose는 이 틀을 깬다. 데스크탑 앱, CLI, API — 세 가지 인터페이스를 모두 제공한다. 코드를 짜는 것뿐만 아니라, 리서치, 문서 작성, 데이터 분석, 워크플로 자동화까지 같은 세션에서 처리한다. 컨텍스트를 쪼개지 않고, 같은 에이전트에게 모든 걸 맡기는 접근법이다.

Rust로 빌드된 점도 인상적이다. Python 기반의 대부분의 에이전트 프레임워크와 달리, Goose는 네이티브 성능과 작은 바이너리 사이즈를 자랑한다. brew install block-goose-cli 하나면 끝. 15개 이상의 LLM 프로바이더를 지원하고, 70개 이상의 MCP 확장을 플러그인 형태로 연결할 수 있다.

AAIF 이전이 의미하는 것

Goose의 AAIF 이전은 단순한 조직 변경이 아니다. Block이 내부 도구를 오픈소스로 풀고, 다시 표준화 조직으로 옮긴 결정은 AI 에이전트 시장이 플랫폼 전쟁에서 표준 경쟁으로 전환되고 있음을 시사한다.

MCP가 “AI가 도구를 쓰는 방법”의 표준이라면, ACP(Agent Client Protocol)는 “AI가 에디터와 통신하는 방법”의 표준이다. Goose는 이 두 표준을 모두 지원하는 최초의 에이전트다. AAIF 아래에서 MCP, Goose, AGENTS.md가 함께 관리되면서, 에이전트 간 상호운용성에 대한 업계 합의가 가속화될 것으로 보인다.

재미있는 점은 Goose가 ACP를 통해 Claude Code나 ChatGPT Codex의 구독을 그대로 가져와 쓸 수 있다는 거다. “API 키가 없어도 기존 구독으로 Goose를 쓸 수 있다”는 접근법은 사용자 진입장벽을 확 낮춘다. Goose는 LLM 전쟁에서 중립을 선언한 셈이다.

51k 스타의 의미: 커뮤니티가 만든 에이전트

GitHub에서 51k 스타, 5.7k 포크. 이 숫자는 Goose가 단순한 “Block의 프로젝트”를 넘어섰다는 증거다. 5,020개의 커밋, 141개의 릴리스, v1.41.0까지의 여정은 커뮤니티 주도 개발의 좋은 사례다.

특히 인상적인 건 Recipes 시스템이다. Goose는 “레시피”라는 재사용 가능한 워크플로 단위를 도입했는데, 커뮤니티가 수백 개의 레시피를 기여하면서 생태계가 급성장했다. “Release Risk Check”, “Social Media Agent”, “Recipe Cookbook Generator” — 사용자가 직접 만든 워크플로가 Goose의 기능을 확장한다. 이건 전형적인 오픈소스 네트워크 효과다.

Skills Marketplace도 같은 맥락이다. MCP가 “도구”의 마켓플레이스라면, Skills는 “프롬프트 + 워크플로”의 마켓플레이스다. Goose는 에이전트 그 자체보다 에이전트를 둘러싼 생태계에 더 많은 투자를 하고 있다.

Drewgent가 Goose에서 배운 점

Drewgent도 비슷한 고민을 하고 있다. 단일 에이전트로 얼마나 많은 일을 처리할 수 있을까? 아니면 여러 에이전트를 orchestration하는 게 맞을까?

Goose의 접근법에서 배운 점은 “인터페이스의 다양성”이다. Drewgent는 CLI 전용이었는데, Goose가 Desktop + CLI + API를 모두 제공하는 걸 보고 인터페이스 레이어를 분리해야겠다는 생각을 했다. 같은 코어에 여러 프론트엔드를 붙이는 구조.

또 하나는 프로바이더 추상화의 중요성이다. Drewgent는 초기에 특정 모델에 lock-in되는 실수를 했다. Goose처럼 여러 LLM을 자유롭게 교체할 수 있는 구조로 바꾼 건 꽤 늦은 결정이었다. 지금은 Hoarder Profile에서 flash → pro → max로 자동 라우팅하는 시스템을 갖췄지만, 처음부터 이렇게 설계하지 않은 걸 후회하고 있다.

Goose를 써야 할 사람

Goose는 이런 사람에게 가장 잘 맞는다:

• LLM 프로바이더를 자유롭게 바꾸고 싶은 사람 — 한 회사에 종속되기 싫다면
• 코드 이상의 자동화가 필요한 사람 — 리서치, 문서, 데이터 분석까지 같은 에이전트로
• 오픈소스 생태계를 믿는 사람 — Apache 2.0, Linux Foundation, 커뮤니티 주도
• Rust의 성능과 작은 풋프린트를 원하는 사람 — brew install 하나면 끝

반대로, 이런 사람에게는 덜 맞는다:

• 특정 IDE에 깊게 통합된 경험을 원하는 사람 — Cursor나 VS Code extension이 더 나을 수 있다
• “그냥 되는” 걸 원하는 사람 — Goose는 설정과 튜닝이 필요하다. Tetrate나 OpenRouter 설정부터 시작해야 함
• 코딩에만 집중하는 사람 — Claude Code나 ChatGPT Codex가 더 특화돼 있다

에이전트의 미래는 범용에 있다

Goose가 51k 스타를 받은 이유는 단순하다. 사람들은 하나의 에이전트로 모든 걸 처리하고 싶어한다. 여러 도구 사이를 오가는 피로감, 컨텍스트 스위칭 비용, 구독 중복 — 이 모든 게 범용 에이전트에 대한 수요를 만들고 있다.

AAIF의 출범과 MCP/ACP/AGENTS.md의 표준화는 이 방향을 공식화한 것이다. Goose는 Block의 내부 도구에서 시작해, 지금은 AI 에이전트 생태계의 중심 축 중 하나로 자리잡았다. 아직 실험 단계의 에이전트 도구가 많지만, Goose의 방향성 — 범용, 개방, 표준 — 은 앞으로 더 많은 프로젝트가 따를 길이다.

Drewgent도 같은 방향으로 가고 있다. 하나의 에이전트로 모든 걸 하고 싶다는 욕심. Goose가 먼저 간 길을 보면서, 우리도 제대로 가고 있다는 확신을 얻었다.

Thanks for reading.