Goose: MCP 네이티브로, 내 컴퓨터에서 돌아가며, 서버를 가진 무엇과도 대화하는 AI 에이전트
— 회 조회
Goose는 Apache-2.0 범용 AI 에이전트(CLI, 데스크톱, API)로 내 컴퓨터에서 실행된다. 새 기능은 닫힌 플러그인 스토어가 아니라 Model Context Protocol 확장에서 나오며, 거버넌스는 이제 Linux Foundation에 있다.
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash이것은 무엇인가
Goose는 내 컴퓨터에서 실행되는 범용 온머신 AI 에이전트로, CLI, 네이티브 데스크톱 앱, 그리고 임베드 가능한 API의 형태로 제공된다. 단순한 자동완성이나 채팅 상자가 아니다. 셸 명령을 실행하고, 파일을 편집하고, 코드를 돌리며, 당신이 평범한 언어로 준 목표를 향해 여러 단계의 워크플로를 엮어 나간다. 저장소의 한 줄 태그라인은 이렇다. “your native open source AI agent — desktop app, CLI, and API — for code, workflows, and everything in between.”
이 프로젝트는 Apache-2.0 라이선스로 오픈소스이며, 주로 Rust로 작성되었다. Block(Square／Cash App의 모회사)에서 코드네임 “goose”로 시작되었지만, 주목할 만한 거버넌스 행보로 이후 Linux Foundation 산하의 Agentic AI Foundation(AAIF) 으로 이관되었다 —— 정식 저장소는 이제 aaif-goose/goose에 있다. 이 글을 쓰는 시점에 GitHub 저장소의 스타 수는 약 48,100개이며, 최신 릴리스 v1.37.0은 2026년 6월 3일자 —— 내가 확인하기 며칠 전이니, 이것은 활발히 움직이는 빠른 프로젝트다. 특정 벤더에 묶어두는 대신, 폭넓은 모델 공급자(Anthropic, OpenAI, Google, Ollama, OpenRouter, Bedrock 등)에 연결한다.
이 아키텍처가 흥미로운 이유
핵심 베팅은 능력은 독점적인 플러그인 카탈로그가 아니라 열린 프로토콜에서 와야 한다는 것이다. Goose는 도구와 데이터를 에이전트에 노출하기 위한 개방 표준인 Model Context Protocol(MCP) 의 가장 이르고 가장 깊은 채택자 중 하나였다. 저장소는 MCP를 통해 70개 이상의 확장에 연결할 수 있음을 내세우며, 그 결과는 크다. MCP 서버를 제공하는 어떤 서비스든 —— GitHub, Jira, Slack, 데이터베이스, 모니터링 대시보드 —— 유지보수자가 각각에 맞춤형 통합을 작성하지 않아도 Goose에서 사용할 수 있게 된다. 에이전트가 닿는 범위는 한 회사의 로드맵이 허락하는 만큼이 아니라, 생태계가 자라는 만큼 넓어진다.
두 번째 구조적 선택은 거버넌스다. 프로젝트를 중립적인 재단 아래로 옮긴다는 것은, 그 방향이 더 이상 단일 벤더의 상업적 우선순위에 좌우되지 않음을 뜻한다 —— 어떤 에이전트에 인프라를 거는 거라면 이는 실질적인 고려 사항이다. 두 가지 태도를 비교해 보자.
| 차원 | 닫힌 플러그인／단일 벤더 에이전트 | Goose의 MCP 네이티브 + 재단 모델 |
|---|---|---|
| 새로운 기능 추가 | 공식 플러그인이나 1차 통합을 기다림 | 아무 MCP 서버로 가리킴(이미 70개 이상, 수천 개 존재) |
| 방향을 누가 통제하나 | 한 회사의 로드맵 | 중립 재단(Linux Foundation／AAIF) |
| 도구 생태계 | 벤더 카탈로그에 한정 | 열린 MCP 레지스트리에 한정 |
| 로컬 vs 클라우드 | 흔히 클라우드에 묶임 | 내 컴퓨터에서 실행; 모델 공급자는 직접 선택 |
| 파급 범위 | 검증된 플러그인으로 한정 | 셸 + 임의의 MCP 도구 실행 —— 설계상 더 넓음 |
솔직하게 읽자면, Goose를 강력하게 만드는 그 개방성이 동시에 그 파급 범위도 넓힌다. 셸 명령을 실행하고 임의의 서드파티 MCP 서버에 연결하는 에이전트는 많은 것에 닿을 수 있으며, 바로 그 점이 신뢰 경계를 깊이 생각할 만한 이유다.
설치와 실행
프로젝트 자체 사이트와 README에 제시된 설치 명령은 CLI를 curl로 부트스트랩하는 bash다.
# install the goose CLI (verbatim from goose-docs.ai / the repo README)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash
# then configure a provider + model and start a session
goose configure
goose session모든 curl | bash 설치 프로그램이 그렇듯, 조금이라도 미심쩍다면 셸로 흘려보내기 전에 스크립트를 읽어 보라 —— 이것은 프로젝트의 GitHub 릴리스에서 가져오지만, 그 습관은 지킬 가치가 있다.
실무 노트
내가 실제로 한다면 이렇게 하겠다. 카탈로그 전부가 아니라, 일부러 작은 MCP 확장 묶음부터 Goose를 세운다. 첫날부터 모든 것을 —— GitHub, Slack, 데이터베이스, 클라우드를 —— 배선하고 싶은 유혹을 부른다. 나라면 오히려 일회용 브랜치에서 내장 developer(셸 + 파일 편집) 확장부터 시작해, 에이전트가 어떻게 계획하고 행동하는지 지켜보고, 어떤 원격 MCP 서버가 어떤 자격 증명과 스코프를 요구하는지 이해한 뒤에야 그것을 추가한다. 확장을 하나 켤 때마다 새로운 공격 표면과, 환경 속 새로운 비밀 한 묶음이 더해진다. “MCP 서버를 더한다”는 것을 의존성을 하나 더하는 것과 똑같은 신중함으로 다루라. 중단 가능한 세션은 여기서 도움이 된다 —— 처음 몇 번은 중요한 무언가에 대해 마음껏 달리게 두지 말고 핸들에 손을 얹어 두라.
내가 특히 이런 에이전트에 손을 뻗는 것은 작업이 파일만이 아니라 도구를 가로지를 때다. CI 실패를 재현하고, 진짜 데이터 저장소에 질의하고, PR을 열고, 채널에 알린다. 이 도구를 가로지르는 도달 범위야말로, 순수한 코드 편집 에이전트에 비해 MCP 모델이 제값을 하는 지점이다.
간과된 관점
표제는 “열린 에이전트”지만, 더 조용하고 더 중대한 변화는 락인이 어디로 옮겨가는가에 있다. 에이전트를 어떤 단일 모델 벤더로부터도, 어떤 단일 플러그인 스토어로부터도 분리함으로써, Goose는 의존 위험을 없앤다기보다 그것을 MCP 생태계 자체 로 —— 그 서버들, 그것들의 인증 모델, 그리고 그것들의 유지보수 건전성으로 옮겨 놓는다. 십수 개의 서드파티 MCP 서버를 축으로 워크플로를 짜는 팀은, 벤더 락인을 확산된 공급망 의존성과 맞바꾼 셈이다. 각 서버는 다른 누군가가 내놓는 코드이며, 저마다의 업데이트 주기, 보안 자세, 그리고 유지보수가 끊길 확률을 가진다. 그것은 아마 더 나은 자리다 —— 개방 표준은 닫힌 것을 이긴다 —— 하지만 의존이 없는 것은 아니다. Goose로 이기는 팀은, 활성화한 MCP 서버를 운영 의존성처럼 다룬다. 버전을 고정하고, 검토하고, 어느 것 없이는 살 수 없는지 안다. 재단에 의한 거버넌스는 에이전트의 중립성을 해결한다. 하지만 당신이 거기에 볼트로 죄어 붙이는 확장의 긴 꼬리, 그 수명에 대해서는 아무 말도 하지 않는다.