제조사가 없어서 좋은 것 — Goose와 리서피의 공정함

제조사가 없어서 좋은 것 — Goose와 리서피의 공정함

r/LocalLLaMA의 질문: "Block의 Goose를 쓰는 분 있나? 소셜에서 Block 직원 말고는 별로 안 보인다. Aider·Claude Code·gemini-cli와 비교하면?"

답글 첫 문장: "좋아한다. 목적 특화 코더가 아니라 AI-유틸리티 은유의 MCP 클라이언트다."

두 번째 답글, 2개월 사용 후 이탈: "유용했지만 지금은 더 나은 도구가 있다."

세 번째 답글, MCP 서버 실행용으로 쓰다 떠남: "서버가..." (사유는 스레드가 끊긴다).

이 글은 Goose를 제공사 중립이라는 단 하나의 축으로 평가하고, 그 축이 어디서 힘을 발휘하고 어디서 무너지는지 정리한다.

1. Goose가 무엇을 파나

MCP 확장. Goose의 핵심은 코드 하네스라기보다 MCP 호스트다. 표준 MCP 서버를 붙여 도구 생태계를 확장한다.

리서피. 세션이 "대화"라면, 리서피는 "반복 가능한 절차"다. 파라미터화된 저장 프롬프트+구성. 한 실사용기: "까다로운 다단계 작업을 리서피로 바꾸고 매번 재설명하는 걸 그만뒀다. 팀에서 한 엔지니어의 영리한 워크플로를 모두가 동일하게 실행할 수 있는 메커니즘이다."

제공사 중립 + 로컬 우선. Ollama 같은 로컬 런타임에 붙이면 핵심 추론 루프가 외부 API를 건드리지 않는다. 에어갭·규제 업종의 실질적 선택지.

거버넌스. Linux Foundation 이양. "공급업체가 거래 조건을 바꿀 때 무엇이 일어나나"에 대한, 단일 벤더 에이전트가 줄 수 없는 답.

2. 무엇을 지불하나

모델 품질 전가. 리뷰의 핵심 문장: "Goose는 가공하는 모델만큼만 좋다. 하우스 모델이 에이전트를 빛내주지 않는다. 약한 모델을 대면, CLI만 예쁜 약한 에이전트가 있다. 이건 Goose의 잘못이 아니라 Goose의 현실이다."

확장 설정의 마찰. "확장 발견이 큐레이션 앱 스토어만큼 매끈하지 않다. README를 읽고 환경 변수를 찾아 config를 편집해야 한다. 키가 없어서 아무것도 안 하는 확장에 시간을 태웠다."

폴리싱의 격차. "출력 포맷, 컨펌 프롬프트, 내부 루프 속도가 가장 정제된 상용 에이전트보다 한 단계 아래다." 투자 규모의 차이가 체감으로 온다.

초기 이탈. "2개월 쓰고 더 나은 도구로"라는 이탈은 기능 부족이라기보다, 모델 선택과 설정 비용이 커뮤니티가 기대하는 것보다 높았다는 기록으로 읽힌다.

3. Goose가 이기는 자리

리뷰의 처방은 명확하다. 중립이 선호가 아니라 제약일 때.

• 규제 산업·엄격한 데이터 취급 규칙
• 가격·라이선스가 발 아래에서 바뀐 경험
• 완전히 사내에 남겨야 하는 워크로드
• 팀 전체가 동일하게 실행해야 하는 워크플로(리서피)

반대로, "오늘 밤 터미널에서 훌륭한 에이전트만 원하고 락인은 신경 안 쓴다면" 단일 벤더의 코-튜닝된 도구가 1일차에 더 매끄럽다.

4. 결론 — 중립의 정당화

Goose의 사용자 기록은 하나의 문장으로 압축된다. 하네스는 훌륭하고, 지능은 모델에게 맡긴다.

MCP 확장·리서피·Linux Foundation은 Goose 고유의 지분이다. 그 지분은 "더 좋은 코더"가 아니라 "더 안전한 선택"의 시장에서 가치가 있다. 반면 설정 마찰과 폴리싱 격차는 투자 규모의 한계로, 하루아침에 사라지지 않는다.

Goose를 선택하는 이유는 기능 목록이 아니라 거버넌스와 이식성이다. 그 이유가 당신에게 필요하다면, Goose는 지금까지 나온 터미널 에이전트 중 가장 방어 가능한 선택지다.

관련 글: OpenCode 사용자 리뷰 · browser-use 사용자 리뷰 · Goose 에이전트 허브 항목

출처

• 커뮤니티: Anyone using Block's goose? (r/LocalLLaMA, 2025-10)
• 실사용 리뷰: Goose CLI Review after Linux Foundation handoff (Pickuma, 2026-06)
• 공식: block/goose GitHub