“직접 만들래, 남의 거 쓸래?” — 에이전트 세상의 딜레마다.

이 질문을 1년째 붙잡고 산다. Drewgent는 opencode라는 플랫폼 위에서 돌아가고, opencode는 점점 더 많은 MCP 서버를 연결하고, 나는 점점 더 “이거 내가 직접 만들어야 하나?”라는 질문과 마주한다.

그러다 발견한 게 goose다. Block (옛 Square)에서 만든 오픈소스 AI 에이전트인데, 깃헙 스타 17K+ 받은 프로젝트다.

goose의 접근법: MCP first

goose가 재미있는 점은 도구 시스템 전체를 MCP로 추상화한 것이다. 보면 볼수록 opencode의 철학과 닮아 있다. 확장성의 기준을 “플러그인을 몇 개나 만들 수 있느냐”가 아니라 “MCP 서버를 몇 개나 연결할 수 있느냐”로 잡은 셈이다.

Shell 도구, 파일 편집, 코드 분석 — 다 MCP 서버로 구현되어 있다. 각각 독립적인 서버로 떠 있고, goose는 그저 클라이언트일 뿐이다. 이게 주는 유연성은 엄청나다. 새 도구를 추가하고 싶으면 MCP 서버 하나 띄우면 끝이다.

Rust로 쓴 ACP: 속도가 다르다

goose가 가진 또 하나의 강점은 ACP (Agent Client Protocol) 구현이 Rust로 되어 있다는 점이다. Goose의 ACP provider는 Rust로 작성되어 있어서, 에이전트 간 통신 지연이 현저히 낮다. 나도 Drewgent에서 goose의 ACP 구현을 리버스 엔지니어링해서 goosedmcp-acp-integration 스킬을 만들었을 정도다.

재미있는 사실: goose의 ACP 구현은 GitHub Actions에서도 돌아간다. CI/CD 파이프라인에서 에이전트가 다른 에이전트를 호출하는 구조를 이미 상용화한 셈이다. 나는 아직 launchd cron + tmux로 때우고 있는데, 이 부분에서 goose가 한수 위다.

opencode랑 비교하면?

솔직히 말하면 opencode가 goose보다 내 워크플로에 더 잘 맞는다. opencode는 CLI-first + subagent 패턴이 이미 내 운영 방식에 깊이 박혀 있다. opencode의 task()와 GJC coordinator가 goose의 ACP보다 내 상황에선 더 실용적이다.

하지만 goose가 잘하는 영역이 있다. 확장성의 순수함이다. goose는 에이전트 그 자체로 최소한의 기능만 가지고 있고, 모든 건 MCP로 확장한다. opencode는 MCP를 지원하면서도 자체 plugin 시스템(tools/)을 유지하는 하이브리드인데, 이게 오히려 복잡성을 키운다. opencode 1.17.13에서 tools/ 플러그인이 깨졌을 때 plugins/로 급히 마이그레이션한 경험이 아직 생생하다.

내 결론

goose는 배울 점이 많은 프로젝트다. 특히 ACP의 Rust 구현과 MCP-first 철학은 앞으로 에이전트 생태계의 표준이 될 가능성이 높다. 지금 당장 opencode를 버리고 goose로 갈아탈 생각은 없지만, goose의 설계 결정들을 계속 지켜보면서 Drewgent에 적용할 수 있는 건 적용할 생각이다.

“직접 만드는 게 좋냐, 남의 걸 쓰는 게 좋냐”는 질문에 대한 내 답변은 여전히 “상황에 따라 다르다”다. 그래도 goose 하나쯤은 툴박스에 넣어두면 언젠가 쓸모 있을 거다.