AI 에이전트에게 매번 같은 작업을 처음부터 다시 지시하고 계시지는 않나요? "이 리포지토리의 의존성을 감사해줘", "릴리스 노트를 생성해줘"와 같은 정형화된 태스크는 프롬프트를 다시 쓸 때마다 미묘하게 어긋나기도 하고, 팀에서 공유하기도 번거롭습니다.

Goose는 Block이 개발하여 2025년에 Apache 2.0으로 OSS(Open Source Software)화한 터미널/데스크톱 양쪽 대응 AI 에이전트입니다. 본 기사에서는 Goose의 Recipes 기능에 초점을 맞춥니다. Recipes는 에이전트에 대한 지시, 사용하는 도구, 파라미터를 정리한 **재사용 가능한 YAML 워크플로 (Workflow)**로, 명령어 하나로 실행할 수 있으며 팀 공유 및 CI/CD에 통합할 수 있습니다.

• Goose CLI의 셋업 및 프로바이더(Provider) 설정

• 실행 중인 세션에서 Recipe를 생성하는 방법 (/recipe)

• Recipe YAML을 직접 작성하기 위한 스키마(Schema) 읽는 법

• 파라미터화 (--params)하여 템플릿으로 재사용하는 방법

• sub_recipes로 여러 태스크를 병렬 실행하는 방법

• GitHub Actions에서 Recipe를 CI로서 실행하는 방법

• AI 에이전트의 정형 작업을 재사용 및 표준화하고 싶은 엔지니어

• Claude Code나 Codex CLI 이외의 OSS 에이전트 선택지를 찾고 있는 분

• OS: macOS / Linux (Windows는 PowerShell 스크립트 있음)

• LLM 프로바이더 API 키 (Anthropic / OpenAI / Google 등)

• 확인에 사용한 버전: Goose CLI (stable 채널 · 2026년 6월 시점)

• Recipe는 「지시 · 도구 · 파라미터」를 한 파일에 담은 포터블(Portable)한 YAML 워크플로.

• 실행 중인 세션에서 /recipe로 생성할 수 있어 처음부터 작성할 필요가 없음.

• 실행은 goose run --recipe foo.yaml, 값 삽입은 --params key=value.

• {{ variable }} 템플릿 변수로 파라미터를 본문에 삽입 가능.

• sub_recipes를 통해 Lead 에이전트가 Worker를 병렬로 기동할 수 있어 배치(Batch) 처리에 적합.

• response를 통해 구조화된 JSON을 반환할 수 있어 CI/CD에서 결과를 기계적으로 처리 가능.

Goose는 2025년 12월, Linux Foundation 산하에 신설된 **Agentic AI Foundation (AAIF)**에 Anthropic의 Model Context Protocol (MCP) 및 OpenAI의 AGENTS.md와 함께 기증되는 것이 발표되었습니다1. 그 후 2026년 4월에 리포지토리도 block/goose에서 aaif-goose/goose로 정식 이관되었습니다. 특정 벤더에 얽매이지 않는 중립적인 거버넌스 하에 놓이게 됨으로써, 장기적으로 사용할 도구로서의 신뢰성이 높아졌습니다.

Goose 자체는 MCP를 네이티브하게 다룰 수 있는 에이전트이며, 그 입문 과정은 별도의 기사에서 다루고 있습니다. 본 기사는 그 한 단계 더 나아가, **「한 번 만든 워크플로를 어떻게 자산화할 것인가」**라는 관점에서 Recipes를 깊이 있게 살펴봅니다.

macOS / Linux에서는 공식 설치 스크립트를 실행합니다2.

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

대화형 셋업을 건너뛰고 싶다면 CONFIGURE=false를 전달합니다.

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash

LLM 프로바이더와 API 키를 설정합니다.

goose configure

「Configure Providers」를 선택하고, 프로바이더(Anthropic / OpenAI 등)와 API 키를 입력합니다. 키체인(Keychain)을 사용하고 싶지 않은 환경에서는 환경 변수로 전달할 수도 있습니다.

export OPENAI_API_KEY=your_api_key

대화 세션(session)을 시작해 보겠습니다.

goose session

세션이 시작되고 자연어(natural language)로 지시를 내릴 수 있다면 준비 완료입니다.

Recipe를 처음부터 YAML로 작성할 수도 있지만, 처음에는 실행 중인 세션으로부터 생성하는 것이 간편합니다. 평소처럼 세션에서 일련의 작업을 수행한 후, 세션 내에서 다음 슬래시 명령(slash command)을 실행합니다.

/recipe

이렇게 하면 세션 기록을 바탕으로 recipe.yaml이 생성됩니다3. 생성된 YAML은 다음과 같은 형태를 띱니다.

version: "1.0.0"
title: "Dependency Audit"
description: "프로젝트의 의존성을 감사하고 알려진 취약점을 보고한다"
...

title과 description은 필수이며, instructions(에이전트에 대한 지시) 또는 prompt(헤드리스(headless) 실행 시의 첫 지시) 중 하나가 반드시 포함되어야 합니다.

생성 및 저장된 Recipe는 명령어 하나로 실행할 수 있습니다.

goose run --recipe recipe.yaml

헤드리스(비대화형)로 실행되므로 셸 스크립트(shell script)나 cron에서도 호출할 수 있습니다. 이것만으로도 '의존성 감사'를 매번 동일한 절차로 재현할 수 있게 됩니다.

Recipe의 진가는 **파라미터화 (parameterization)**에 있습니다. parameters에서 플레이스홀더(placeholder)를 정의하고, 본문에서는 {{ variable }} 표기법으로 참조합니다.

version: "1.0.0"
title: "Trip Planner"
description: "목적지와 일수를 지정하여 여행 일정을 작성한다"
...

실행 시 --params로 값을 전달합니다 (여러 개를 지정할 때는 플래그를 반복합니다).

goose run --recipe trip.yaml --params destination=Africa --params duration=14

이렇게 하면 '14일간의 아프리카 여행 일정'이 생성됩니다3. 값만 바꾸면 동일한 Recipe를 다른 문맥에서 몇 번이고 재사용할 수 있습니다.

parameters의 각 엔트리(entry)에서 지정할 수 있는 주요 항목은 다음과 같습니다4.

input_type: select를 사용하면 출력 포맷 등을 선택식으로 만들 수 있습니다.

- key: output_format
  input_type: select
  requirement: required
...

Recipe에는 사용하는 MCP 확장(extension)이나 모델 설정도 포함할 수 있습니다. 이를 통해 '이 작업은 이 도구와 이 모델로 수행한다'는 구성 자체를 공유할 수 있습니다.

extensions:
- type: stdio
  name: codesearch
...

extensions는 Recipe 실행 시 자동으로 로드되므로, 사용자가 직접 MCP 서버를 설정해야 하는 번거로움을 줄여줍니다.

큰 작업은 sub_recipes로 분할할 수 있습니다. 부모(Lead) Recipe가 자식(Worker) Recipe를 호출하며, 각각 독립된 워커 프로세스에서 **병렬 실행 (parallel execution)**할 수 있습니다4. 배치 처리(batch processing)나 여러 대상을 대상으로 하는 동일 작업에 적합합니다.

version: "1.0.0"
title: "Multi-Repo Auditor"
description: "여러 리포지토리를 병렬로 감사한다"
...

자식 Recipe 측에서는 전달받은 파라미터를 {{ repo }}

본문에서 {{ repo }}와 같이 참조할 수 있습니다. Lead가 여러 Worker를 동시에 실행하기 때문에, 대상 수가 늘어나더라도 완료까지 걸리는 시간을 억제할 수 있습니다.

sub_recipes의 병렬 실행은 각각 독립된 프로세스로 동작합니다. 공유 리소스(동일한 파일에 대한 쓰기 등)가 충돌하지 않도록, 자식 태스크의 출력 경로를 분리해 두는 것이 안전합니다.

Recipe는 헤드리스 (Headless)로 실행할 수 있으므로, GitHub Actions에 통합하면 '정형 작업의 자동화'를 그대로 CI화할 수 있습니다. 다음은 의존성 감사 (Dependency Audit) Recipe를 매일 실행하는 예시입니다.

name: Daily Dependency Audit
on:
  schedule:
...

API 키는 Actions의 Secrets에 등록하고, 환경 변수로 전달합니다. CONFIGURE=false로 대화형 설정을 억제하는 것이 포인트입니다.

설치 경로(Path)는 환경에 따라 달라집니다.

goose가 PATH에 등록되지 않은 경우에는, 잡 (Job) 내에서 which goose를 확인하거나 절대 경로로 호출하십시오.

CI에서 결과를 기계적으로 판정하고 싶을 때는, response에서 **JSON 스키마 (JSON Schema)**를 지정하면 에이전트의 출력을 구조화된 JSON으로 받을 수 있습니다4.

response:
  json_schema:
    type: object
...

또한 retry를 사용하면 출력이 조건을 만족하지 않을 때 자동으로 재시도 (Retry)를 수행할 수 있습니다.

retry:
  max_retries: 2
  timeout_seconds: 30
...

checks의 쉘 명령어가 성공할 때까지 (상한 횟수까지) 재시도하므로, '파일이 생성되지 않았다면 다시 실행한다'와 같은 검증 기능이 포함된 실행을 작성할 수 있습니다.

instructions는 에이전트의 행동을 정의하는 시스템 지시 (System Instruction)이며, prompt는 헤드리스 실행 시 던지는 첫 번째 메시지라는 위치를 가집니다. 대화형으로 사용한다면 instructions를, goose run으로 단발 실행한다면 prompt를 중심으로 설계하는 것이 의도대로 동작하기 쉽습니다. 최소한 둘 중 하나는 필수이므로, 빈 상태로 저장하지 않도록 주의하십시오.

requirement: optional 파라미터에 default를 빠뜨리면, 값을 해결하지 못해 실행이 중단될 수 있습니다. 선택 사항(Optional)으로 만들려면 반드시 기본값 (Default value)을 함께 제공해야 합니다.

block/goose 유래의 오래된 URL을 참조하고 있는 스크립트나 북마크는 aaif-goose/goose를 향하도록 수정해 두어야 릴리스 획득 등에서 막히지 않습니다.

• Goose의 Recipe는 AI 에이전트의 정형 작업을 YAML 파일 1개에 응축하여 재사용, 공유, CI화하기 위한 메커니즘입니다.
• 우선은 /recipe를 통해 세션에서 생성하고, parameters와 {{ variable }}로 템플릿화하는 것이 실전적인 입문 방법입니다.
• sub_recipes의 병렬 실행과 response의 구조화된 출력을 사용하면, 단발성 편리 명령어를 넘어 팀 자동화 파이프라인의 부품으로 발전시킬 수 있습니다.

'매번 AI에게 똑같은 일을 부탁하고 있다'고 느껴진다면, 그 지시 사항을 Recipe로 분리하는 것부터 시작해 보세요.

• aaif-goose/goose (GitHub) — Recipe 소스 및 릴리스

• Recipe Reference Guide — YAML 스키마의 모든 항목

• Recipes Tutorial — goose run --recipe --params 실행 예시

• goose Installation — CLI 설치 및 설정

• Linux Foundation: AAIF 설립 발표 — goose의 AAIF 기증

• Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF) (MCP, goose, AGENTS.md 기증 발표) ↩