Block이 공개한 오픈소스 AI 에이전트 Goose를 직접 살펴봤습니다. Apache 2.0 라이선스로 회사에서 쓸 때 체크할 점, MCP 연동과 권한 설정, Claude Code·Cursor와의 차이까지 정리했어요.
드디어 올 것이 왔습니다. ✨ AI에게 코드 한 조각을 물어보던 시대는 이미 지났죠. 요즘은 "이 저장소 분석해서 버그 고치고, 테스트 돌린 다음 PR 설명까지 써줘"라고 통째로 맡기고 싶습니다. 문제는 SaaS 기반 AI agent를 회사 업무에 붙이려고 하면 데이터 반출, 벤더 종속(vendor lock-in), 팀별 커스터마이징 문제가 늘 발목을 잡는다는 겁니다.
그래서 오늘은 Goose 리뷰입니다. Block(Square와 Cash App을 운영하는 회사)이 공개한 오픈소스 AI 에이전트 Goose는 단순한 챗봇이 아닙니다. 원하는 LLM과 도구를 연결해서 실제 작업 흐름을 돌리도록 설계된 agent입니다. 게다가 라이선스가 Apache 2.0이에요. Wow, 내부 환경에 맞춘 AI agent를 고민하는 팀이라면 이건 진짜 눈여겨볼 만합니다. 이 글에서는 "그래서 회사에서 써도 되나?", "어떻게 시작하나?", "Claude Code나 Cursor랑 뭐가 다른가?"라는 세 가지 질문에 차례로 답해 보겠습니다.
Goose 리뷰 ① 오픈소스 AI 에이전트 Goose는 뭐가 다를까? 답변보다 '작업 루프'
Goose의 핵심은 LLM을 새로 만드는 게 아닙니다. 이미 쓰고 있는 모델을 고르고, 필요한 도구를 붙여서 계획 → 실행 → 결과 확인 → 다음 행동 루프를 돌리는 데 있습니다. 모델이 두뇌라면 Goose는 손발과 작업대 역할을 하는 셈입니다.
- CLI + Desktop 앱 🖥️: 터미널 중심 워크플로를 좋아하는 개발자도, GUI에서 extension을 관리하고 싶은 사람도 접근할 수 있습니다.
- 여러 LLM provider 지원: 특정 모델에 묶이지 않고 클라우드 API 모델이나 로컬 모델(예: Ollama 기반)을 골라 연결하는 구조입니다.
- MCP 기반 extension 🔌: Model Context Protocol(MCP) 서버를 붙여 파일 시스템, Git, 데이터베이스, 사내 API까지 agent의 행동 범위를 넓힐 수 있습니다.
- 코드를 직접 볼 수 있다는 것: 사내 승인 절차, 인증 방식, 보안 정책에 맞춰 코드를 읽고 고칠 수 있습니다. 블랙박스가 아니라는 점이 가장 큰 차이입니다.
개발자 입장에서 체감되는 포인트는 이겁니다. "이번 배포에서 바뀐 API를 찾아 문서 초안을 만들고, 빠진 테스트 후보를 정리해줘"라고 요청해 볼게요. 일반 챗봇에서는 코드를 일일이 복사해 붙여 넣어야 합니다. agent는 허용된 권한 안에서 저장소를 직접 탐색하고, 도구를 호출하고, 문맥을 쌓아 갑니다. 한마디로 컨텍스트 스위칭을 줄여 주는 워크플로 레이어입니다. 이게 익숙해지면 다시 복붙 모드로 돌아가기가 꽤 힘듭니다. 😅
Apache 2.0 라이선스, 회사 업무에 써도 될까? 도입 전 체크리스트
"오픈소스니까 그냥 공짜로 막 써도 되죠?"라는 생각은 반만 맞습니다. Apache 2.0은 상업적 이용, 수정, 재배포를 비교적 폭넓게 허용하는 permissive 라이선스입니다. 여기에 기여자의 특허 사용 허락(patent grant) 조항이 들어 있어서 기업 법무팀이 선호하는 편이기도 합니다. 그렇다고 아무 조건이 없는 건 아닙니다.
| 확인 항목 | Goose 도입 시 체크 포인트 |
|---|---|
| 소스 수정 | 사내 인증, 승인 워크플로, 전용 도구를 연결하도록 코드를 고칠 수 있습니다. |
| 상업적 활용 | 내부 업무 도구나 자사 제품의 일부로 쓰는 시나리오가 허용됩니다. |
| 고지 의무 | 수정본을 배포할 때는 LICENSE·NOTICE 파일을 유지하고, 변경 사실을 표시해야 합니다. |
| 모델 비용 | Goose 자체는 무료지만, 연결한 LLM API의 토큰 비용은 따로 발생합니다. |
| 데이터 경로 | 클라우드 모델을 쓰면 코드와 프롬프트가 해당 provider로 전송됩니다. 사내 데이터 정책을 반드시 확인하세요. |
여기서 중요한 한 가지가 있습니다. Apache 2.0은 "법적으로 써도 된다"는 뜻이지, "안전하다"는 뜻이 아닙니다. agent에게 셸 실행, 파일 쓰기, 외부 API 접근 권한을 주는 순간 보안 리스크의 성격이 완전히 달라집니다. 최소 권한 원칙, 비밀값(API 키·토큰) 분리, 위험한 명령에 대한 승인 단계, 로그 관리를 먼저 설계해야 합니다. AI가 똑똑해질수록 권한 설계는 기능만큼 중요해집니다. 실제 도입 전에는 사내 법무·보안 담당자와 최종 확인하는 걸 권장합니다.
설치부터 첫 세션까지: 작게 시작하는 Goose 사용법
설치 방법은 OS와 배포 채널에 따라 조금씩 다르고 업데이트도 잦습니다. 그래서 설치 명령어는 반드시 공식 문서의 최신 안내를 확인하세요. 설치가 끝난 뒤의 기본 흐름은 대략 이렇습니다.
# 1) provider(LLM)와 API 키 등 기본 설정
goose configure
# 2) 프로젝트 폴더에서 대화형 세션 시작
cd ~/sandbox/my-test-repo
goose session
# 3) 첫 요청은 '읽기 + 요약' 위주로
> 이 저장소의 디렉터리 구조와 주요 모듈 역할을 요약해줘
> 최근 커밋 diff를 보고 테스트가 부족해 보이는 부분을 목록으로 정리해줘팁 하나 드리면, 프로젝트 루트에 .goosehints 같은 힌트 파일을 두는 방법이 있습니다. 코딩 컨벤션, 테스트 명령, "절대 건드리지 말 것" 같은 규칙을 적어 두면 agent가 매번 같은 실수를 반복하는 일이 줄어듭니다. 처음부터 운영 서버나 고객 데이터에 연결하는 건 비추천입니다. 추천 순서는 이렇습니다. 🚀
- Step 1: 테스트용 저장소에서 코드 구조 요약과 문서 초안 생성하기
- Step 2: Git diff 분석, 테스트 실패 원인 정리처럼 사람이 결과를 검토할 수 있는 작업 맡기기
- Step 3: 도구별 권한을 분리하고, 삭제·배포 같은 파괴적 명령은 수동 승인 필수로 두기
- Step 4: 사용 모델, 토큰 비용, 실패한 tool call을 기록해서 ROI 측정하기
Goose vs Claude Code vs Cursor: 완성도냐, 통제권이냐
솔직하게 말하면, Goose를 Claude Code나 Cursor의 완벽한 대체재로 보는 건 성급합니다. 셋은 출발점이 다릅니다.
| 구분 | Goose | Claude Code | Cursor |
|---|---|---|---|
| 형태 | CLI + Desktop agent | 터미널 중심 코딩 agent | AI 코드 에디터 |
| 라이선스 | 오픈소스 (Apache 2.0) | 상용 | 상용 |
| 모델 선택 | 여러 provider와 로컬 모델 | Anthropic Claude 중심 | 여러 모델 중 선택 |
| 강점 | 도구 체인과 권한을 직접 설계하는 통제권 | 모델 품질과 코드베이스 작업 경험의 결합 | 에디터에 녹아든 매끄러운 UX |
| 아쉬운 점 | 초기 세팅과 튜닝에 손이 감 | 서비스·요금 정책 의존 | 사내 도구를 깊게 엮으려면 별도 설계 필요 |
정리하면, 혼자서 당장 코딩 속도를 올리고 싶다면 Cursor나 Claude Code가 더 편할 가능성이 큽니다. 세팅 없이 바로 쓸 수 있는 완성도는 확실히 그쪽이 앞섭니다. 반대로 "우리 회사의 Git, 이슈 트래커, 사내 문서, 배포 시스템을 안전하게 묶은 전용 agent가 필요하다"면 이야기가 달라집니다. 이때는 Goose의 오픈소스 구조가 훨씬 매력적입니다. 참고로 Goose의 결과물 품질은 결국 연결한 모델 성능에 크게 좌우됩니다. 저렴한 모델을 붙이면 tool call 실패나 엉뚱한 계획이 늘어날 수 있다는 점도 감안하세요.
⚡ Tech Summary
- ✨ Goose는 Block이 공개한 오픈소스 AI 에이전트로, LLM과 로컬·외부 도구(MCP)를 연결해 실제 작업 루프를 수행합니다.
- 📜 Apache 2.0이라 상업적 활용과 수정은 자유로운 편이지만, 고지 의무·데이터 경로·보안 검토는 별개입니다.
- 🔐 핵심 경쟁력은 매끈한 채팅 UX보다 모델·도구·권한을 직접 설계하는 통제권입니다.
- 🚀 읽기 전용 저장소와 사람이 검토하는 작업부터 작게 시작하는 게 정석입니다.
미래 전망: AI 에이전트 경쟁은 '누가 더 잘 연결하느냐'로 간다
Goose는 당장 모든 개발 도구를 갈아엎을 제품은 아닙니다. 대신 AI agent를 우리 조직의 인프라로 만들 수 있다는 가능성을 보여 줍니다. MCP 같은 표준 프로토콜이 자리 잡을수록 모델과 도구는 점점 갈아 끼울 수 있는 부품이 됩니다. 그러면 경쟁 포인트도 모델 성능 하나에서 안전하게, 유연하게, 싸게 현실의 도구를 연결하는 능력으로 옮겨 갈 가능성이 큽니다. 비싼 상용 서비스와 오픈소스 스택을 섞어 쓰는 하이브리드 전략이 늘어나는 흐름을 보면, Goose 같은 오픈소스 agent가 그 전략의 뼈대 역할을 맡을 수도 있겠네요.
개인적으로는 이 흐름이 진짜 Game Changer가 될 거라고 봅니다. 🚀 여러분이라면 Goose에게 가장 먼저 어떤 업무를 맡겨 보고 싶으신가요? 댓글로 여러분의 첫 번째 agent 시나리오를 공유해 주세요!