5/07/2026

Goose 소개: 개발자와 함께 일하는 범용 AI 에이전트

요즘 AI 도구들이 정말 많다. 코드를 작성해주는 도구도 있고, 문서를 요약해주는 도구도 있고, 브라우저를 대신 조작해주는 도구도 있다. 그런데 실제 일을 하다 보면 '답변을 잘하는 AI'보다 더 필요한 것이 있다.

바로 작업을 이해하고, 필요한 도구를 사용하고, 절차에 따라 일을 진행하는 AI 에이전트다.

Goose는 그런 목적에 가까운 도구라고 생각한다. 단순한 챗봇이라기보다는 사용자의 요청을 받아서 파일을 읽고, 코드를 분석하고, 명령어를 실행하고, 필요한 경우 여러 작업 단계를 나눠서 처리하는 범용 AI 에이전트라고 볼 수 있다.

본 글에서는 Goose가 무엇인지, 어떤 일을 할 수 있는지, 일반적인 AI 도구와는 무엇이 다른지 그리고 어떤 상황에서 유용한지 정리해보려고 한다.

Goose란 무엇인가

Goose는 AAIF(Agentic AI Foundation)에서 개발 중인 오픈소스 AI 에이전트 프로젝트이다. 특정 회사에서 제공하는 것이 아닌 오픈소스 프로젝트로 개발되고 있기에 구조와 동작 방식이 공개되며 개발자들이 직접 살펴보고 확장할 수 있는 형태를 지향한다.

또한 AI 에이전트 개념이기에 단순히 질문에 답하는 것보다 더 나아간 개념을 제공한다. 사용자의 목표를 이해하고 그 목표를 이루기 위해 필요한 작업을 계획하고 도구를 사용해서 실제 작업을 수행한다.

예를 들어 일반적으로 챗봇에게 아래와 같이 질문 할 수 있다.

"이 코드에서 버그가 뭔지 알려줘."

그러면 챗봇은 코드를 보고 설명해준다. 반면 AI 에이전트를 조금 더 넓은 범위의 일을 할 수 있다.

"이 프로젝트에서 로그인 관련 버그를 찾아보고, 원인을 분석한 다음 수정 방향을 제안해줘."

위 요청을 받으면 프로젝트 파일을 살펴보고, 관련 코드를 찾고, 구조를 분석하고, 필요한 경우 테스트나 명령어 실행까지 포함해서 문제를 해결하려고 시도할 수 있다.

Goose는 이런 방식의 작업을 목표로 하는 범용 AI 에이전트이다. 이 글을 읽는 대부분의 사람들은 Claude Code, Codex, Gemini CLI, Opencode에 익숙할 것이다. 비슷한 개념이다. 그럼에도 잘 모르는 분들을 위해 상세히 설명하려 하니 이미 알고 계신분들께는 양해 부탁드립니다.

일반적인 AI 챗봇과 무엇이 다른가

Goose를 이해하려면 일반 챗봇과의 차이를 먼저 아는 것이 필요하다.

일반적인 챗봇은 주로 대화 중심이다. 사용자가 질문하면 답변하고, 설명을 요청하면 설명하고, 글을 써달라고 하면 글을 작성한다. 그러나 실제 개발에서는 대화만으로 끝나지 않는 일들이 있다.

  • 프로젝트 디렉토리 구조 확인하기
  • 특정 파일의 코드 읽기
  • 함수나 클래스가 어디에서 사용되는지 추적하기
  • 테스트 명령어 실행하기
  • 빌드 오류 확인하기
  • 문서 파일 수정하기
  • 여러 대안을 비교하고 설계안 작성하기
  • 브라우저를 열어 동작 여부 확인하기
이런 작업들은 단순한 답변보다는 도구 사용 능력이 필요하다. Goose는 대화형 이면서 여러 도구를 사용할 수 있다. 파일 시스템을 탐색하고, Shell 명령을 실행하고, 코드를 분석하고 필요하다면 브라우저 기반 테스트 도구나 특정 워크플로우 스킬을 불러와 사용할 수 있다.

따라서 Goose는 '질문에 답하는 AI'라기 보다는 '작업을 함께 처리하는 AI 동료'에 가깝다.

Goose가 할 수 있는 일

Goose가 할 수 있는 일은 Extensions 및 환경과 연결된 도구에 따라 달라질 수 있지만 기본적으로는 아래의 작업을 수행할 수 있다.

코드베이스 분석

프로젝트내의 파일과 디렉토리를 살펴볼 수 있다. 예를 들어 아래와 같은 요청이 가능하다.

"이 프로젝트 구조를 설명해줘."
"인증 로직이 어디에 있는지 찾아줘."
"이 함수가 어디에서 호출되는지 알려줘."
"전체적으로 어떤 아키텍처인지 파악해줘."

개발자가 처음 보는 프로젝트에 참여했을 때 가장 어려운 것 중 하나가 구조 파악이다. 파일은 많고, 폴더 이름은 낯설고, 어떤 코드가 핵심인지 바로 알기 어렵다.

이런 상황에서 디렉토리 구조 및 주요 파일을 분석하고, 함수나 클래스의 관계를 추적하는 식으로 코드베이스에 대한 이래를 도와줄 수 있다. 특히 큰 프로젝트에서는 어디부터 봐야 할지를 알려주는 것만으로도 큰 도움이 된다.

코드 수정과 리팩토링

Goose는 단순히 코드를 읽는 것만 아니라 필요한 경우 파일을 수정할 수도 있다.

"이 함수 이름을 더 명확하게 바꿔줘."
"중복된 로직을 분리해줘."
"에러 처리를 추가해줘."
"타입 오류를 고쳐줘."
"이 컴포넌트를 더 읽기 쉽게 정리해줘."

물론 코드 수정은 항상 조심해야 한다. AI가 수정한 코드가 의도와 다를 수 있고, 잘 동작되는 것에 영향을 줄 수 있기 때문이다. 그래서 AI 에이전트를 사용할 때는 수정 결과를 확인하고, 테스트 하고, 변경 내용을 리뷰하는 과정이 중요하다.

명령어 실행과 결과 확인

Shell 명령어를 실행할 수 있는 환경에서는 테스트, 빌드, 린트 같은 명령을 실행하고 그 결과를 해석할 수 있다.

"테스트를 실행해보고 실패 원인을 분석해줘."
"빌드가 왜 실패하는지 확인해줘."
"타입 체크 결과를 보고 수정 방향을 알려줘."
"패키지 설치 상태를 확인해줘."

개발 중 자주 마주치는 문제인 테스트 실패, 에러 로그, 핵심 원인 등에 대해서 문제 원인을 찾는데 도움을 받을 수 있다.

즉, 코드 생성외에 개발 과정에서 발생하는 피드백 루프에도 참여할 수 있다.

스킬 기반 작업 방식


Goose도 스킬을 사용할 수 있다. 스킬은 특정 목적을 위해 정리된 작업 방식이라고 볼 수 있고 일반적인 AI 답변보다 더 일관된 절차를 따르게 해주는 일종의 워크플로우다.

Goose를 설치하면 여러가지 스킬들을 제공한다. /brainstorm, /gstack 등 각각의 스킬은 목적이 다르기에 상황에 맞게 사용해야 한다.

워크플로우

단순히 하나의 기능만 수행하는 도구가 아니라, 개발 워크플로우의 여러 단계를 이용할 수 있다. 예를 들어 소프트웨어 개발 과정은 대략적으로 아래처럼 흘러간다.

  1. 아이디어를 정리
  2. 요구사항을 구체화
  3. 설계
  4. 구현
  5. 테스트
  6. 리뷰
  7. 배포
  8. 문서화
  9. 회고
Goose는 여러 단계에서 도움을 줄 수 있다. 아이디어 단계에서는 브레인스토밍을 도와줄 수 있다. 설계 단계에서는 아키텍처나 접근 방식을 비교할 수 있다. 구현 단계에서는 코드 작성과 수정에 참여할 수 있다. 테스트 단계에서는 테스트 실행이나 브라우저 기반 QC를 도울 수 있다.

즉, 특정 한 순간에만 쓰는 도구라기보다, 개발 과정 전반에서 함께 사용할 수 있는 에이전트에 가깝다.

다양한 AI 모델을 사용

중요한 특징 중 하나는 특정 하나의 AI 모델에만 묶여 있지 않다는 점이다. 시장에 나온 AI 도구는 특정 서비스나 모델을 사용하게끔 되어 있다. 물론 제공 회사의 전략이기에 당연한 것이다.

반면, Goose와 같은 오픈소스는 여러 AI 모델을 함께 사용할 수 있는 방향을 지향한다. 즉, 사용자의 상황에 따라 적합한 모델을 선택해 사용할 수 있다.

예를 들어 어떤 작업에는 추론 능력이 좋은 모델을 사용할 수 있다. 복잡한 아키텍처를 분석하거나, 긴 코드를 읽고 원인을 추적하거나, 여러 대안을 비교해야 하는 작업이 그렇다.

반대로 어떤 작업은 빠른 응답 속도나 비용 효율이 더 중요할 수 있다. 간단한 코드 수정, 문서 초안 작성, 로그 요약, 반복적인 파일 정리 같은 작업은 비싼 모델을 사용할 필요가 없기 때문이다.

여러 모델을 사용할 수 있는 구조는 다양한 선택지를 제공한다. 즉, 작업의 성격에 따라 적절한 AI 모델을 골라 쓸 수 있는 유연성이 생긴다.

모델 선택이 중요한 이유

AI 모델마다 강정과 약점이 있다.

어떤 모델은 긴 문맥을 잘 처리하고, 어떤 모델은 추론이나 계획 수립에 강하다.
어떤 모델은 빠르고 저렴하게 사용할 수 있다.

그래서 AI 에이전트를 사용할 때는 '어떤 모델이 최고인가' 보다 '이 작업에는 어떤 모델이 적합한가'가 더 중요하다.

오픈소스 에이전트와 모델 유연성의 조합

오픈소스 도구는 사용자가 도구의 동작 방식을 이해하고, 필요하면 직접 수정하거나 확장할 수 있다는 장점이 있다.

여기에 모델 선택의 유연성이 더해지면, 사용자는 자신의 환경과 비용 구조, 보안 요구사항에 맞게 구성할 수 있다.

즉, 사용자가 원하는 모델과 워크플로우를 조합해 사용 할 수 있는 에이전트 환경이다.

확장 구조: Recipes, Skills, Apps, Extensions

Goose를 이해할 때 아래의 4가지 개념이 중요하다.

  • Recipes
  • Skills
  • Apps
  • Extensions

위 4가지는 Goose가 더 다양한 일을 할 수 있게 해주는 구성 요소라고 볼 수 있다.

Recipes: 반복 가능한 작업 절차

이름 그대로 정해진 반복 작업 절차다. 작업을 하다 보면 매번 비슷한 방식으로 처리하는 일들이 있다. 이런 작업들은 매번 새롭게 하는 것보다. 어느 정도 정해진 순서와 체크리스트를 따라가는 것이 효율적이다.

Recipe는 이런 반복적인 작업을 구조화하는데 유용하다. 즉 작업을 할 때 '어떤 순서로 무엇을 확인해야 하는지'를 알려주는 실행 절차라고 볼 수 있다.

Skills: 특정 목적에 맞춘 능력

Skill은 특정 분야 혹은 작업을 더 잘 수행하도록 도와주는 능력 묶음이다. 스킬은 단순한 명령어 하나가 아니라, 특정 목적에 맞는 지침과 도구 사용 방식, 작업 흐름을 포함할 수 있다.

앞에서 잠시 언급한 /brainstorm 스킬은 아이디어 정리와 설계에 초점을 둔다. 바로 구현을 시작하기보다 사용자의 의도, 제약 조건, 목표, 접근 방식을 먼저 정리하도록 돕는다.

즉, Skill은 특정 분야의 작업 방식을 더 잘할 수 있게 능력을 입혀주는 역할을 한다.

일반적으로 "테스트 해줘"라고 하면 결과가 들쭉날쭉할 수 있다. 하지만 QA 전용 스킬을 사용하면 페이지 로딩, 상호 작용, 콘솔 에러, 네트워크 요청, 스크린샷 같은 요소를 체계적으로 확인할 수 있게된다.

그래서 Skill은 더 전문적인 작업 도우미로 만들어주는 장치라고 볼 수 있다.

Apps: 앱 기능


Apps는 Goose 환경 안에서 사용할 수 있는 앱 단위의 기능으로 이해할 수 있다. Apps는 단순히 텍스트 응답만 하는 것이 아니라, 특정 형태의 결과물이나 인터페이스를 만들고 다룰 수 있게 해주는 확장 영역에 가깝다.

채팅을 통해 앱을 생성하게 되면, 생성된 앱은 Apps에 담긴다.

Extensions: 외부 도구와 기능을 연결하는 장치


Extension은 Goose의 기능을 확장하는 연결 장치라고 볼 수 있다. AI 에이전트가 유용하려면 혼자 일만 잘해서는 부족하다. 외부 시스템과 연결해야 하고, 때로는 데이터베이스나 API 등과도 상호작용해야 한다.

Extension은 이런 외부 기능을 Goose에 연결하는 방식이다.

위에서 언급한 Recipes, Skills, Apps, Extensions에 대해 쉽게 설명을 하면,
  • Recipe는 요리 순서가 적힌 레시피
  • Skill은 요리사의 전문 기술
  • App은 완성된 요리를 담아내는 도구나 작은 서비스
  • Extension은 새로운 조리도구나 외부 재료 공급망

이라고 이해하면 쉽다. 위 4가지가 함께 작동하면서 Goose는 더 유연한 AI 에이전트가 된다.

마무리

AI 도구는 점점 '말을 잘하는 도구'에서 '일을 함께하는 도구'로 발전하고 있다. Goose는 그 흐름에 있는 AI 에이전트이다.

코드를 설명하는 것에서 끝나지 않고, 실제 프로젝트를 살펴보고 필요한 명령을 실행하고, 브라우저 테스트를 도와주고 스킬 기반 워크플로우를 통해 작업을 구조화할 수 있다.

Goose의 특징은 3가지로 정리될 수 있다.

첫째, 모델 선택의 자유다.
하나의 모델에 묶이지 않고, 상황에 따라 다양한 모델을 사용할 수 있다는 점은 앞으로 점점 더 중요해질 것이다. (Harness) 모든 작업에 같은 모델이 최선일 수는 없다.

둘째, 확장 가능한 구조다.
Recipes, Skills, Apps, Extensions 같은 개념은 Goose를 조립 가능한 에이전트 환경으로 만든다. 이 구조는 사용자가 자신의 업무 방식에 맞게 AI를 구성할 수 있게 해준다.

셋째, 워크플로우와의 결합
AI가 아무리 똑똑해도 실제 개발 흐름과 연결되지 않으면 생산성 향성에는 한계가 있다. 워크플로우로 인해 단발성 답변 도구가 아니라 함께 일하는 작업 파트너에 가까워진다.

한번 경험해보세요.