우리는 goose를 사용해 goose를 유지합니다
I’m happy to translate the article for you, but I need the full text of the post in order to do so. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the article text, I’ll translate it into Korean while preserving the original formatting, markdown, and any code blocks.
거위 🦆 백로그‑솔버
AI 에이전트의 역량이 커짐에 따라, 더 많은 사람들이 코딩과 오픈 소스 기여에 자신감을 느낍니다. 한계가 그 어느 때보다 높아진 듯합니다. 이는 생태계에 전반적으로 긍정적인 효과이지만, 동시에 유지보수자들의 일상 현실도 바뀝니다.
Maintainers like the goose team face a growing volume of pull requests and issues—often faster than they can realistically process.
We embraced this reality and put goose to work on its own backlog.
Note: 우리는 실제로 goose pre‑1.0을 사용해 goose 1.0을 만들었습니다. 원래 goose는 Python CLI였지만, Rust, Electron, 그리고 MCP‑native 아키텍처로 빠르게 전환해야 했습니다. Goose는 그 전환을 도와주었습니다. 이슈를 분류하고 변경 사항을 검토하는 데 사용한 것은 자연스러운 확장처럼 느껴졌기에, 우리는 goose를 직접 **GitHub Action**에 내장했습니다.
Credit: GitHub Action 워크플로우는 **Tyler Longwell**이 구축했으며, 우리가 수동으로 탐색하던 아이디어를 유지보수자가 단 한 줄의 댓글로 트리거할 수 있는 것으로 바꾸었습니다.
GitHub 액션 이전
액션이 존재하기 전에도, goose 팀은 이미 goose를 사용해 이슈 워크플로를 가속화하고 있었습니다. 실제 예시를 들어보세요.
- 사용자가 Discord에서 Ollama 모델이 채팅 모드에서 오류를 발생시키는 이유를 물었습니다.
- 코드를 직접 파고들기보다, 저는 goose에게 코드를 탐색하고, 근본 원인을 파악한 뒤 저에게 설명해 달라고 요청했습니다.
- 그 다음 저는 goose에게 issue 를 열도록 GitHub CLI를 사용하도록 요청했습니다.
같은 세션 동안, goose는 문제를 해결할 방법을 95 % 확신하고 있다고 보고했습니다. 변경 사항이 작았기 때문에, 저는 goose에게 PR 을 열도록 요청했고, 그 PR은 같은 날 머지되었습니다.
goose 이전의 워크플로
- 단편적인 단계 – 저는 명확한 질문을 하고, 관련 이슈를 찾기 위해 GitHub를 검색하고, 최신 코드를 받아와 파일을 grep하고, 로직을 읽고, 가설을 세웠습니다.
- 두 가지 가능한 결과
- 자세한 이슈를 작성해 개발자의 백로그에 추가 (다른 사람이 나중에 컨텍스트 전환을 해야 함).
- 직접 수정을 시도하지만, 보통 더 많은 시간을 소비하고 코드 리뷰 과정에서 왕왕 오고 가는 상황이 발생합니다.
두 경로 모두 몇 시간 혹은 며칠에 걸쳐 진행되었습니다. 우선순위가 낮은 문제는 Discord나 GitHub 댓글에 남아 있다가 결국 잊혀질 수 있었습니다.
goose를 사용하면, 전체 과정이 하나의 대화로 압축됩니다.
로컬 워크플로는 작동하지만, 저는 여전히 로컬에서 문제를 해결할 때 직접 주도합니다: 현재 작업을 멈추고 세션을 열어 이슈 컨텍스트를 붙여넣고, goose에게 수정을 안내하고, 테스트를 실행하고, PR을 엽니다.
GitHub Action을 활용한 확장
GitHub Action은 전체 과정을 하나의 댓글로 압축합니다.
- 팀원이 이슈를 보고
/goose라고 댓글을 남깁니다. - Goose가 컨테이너에서 실행되어 이슈를 읽고, 코드베이스를 탐색하고, 검증을 수행한 뒤 draft PR을 엽니다.
- 유지보수자는 빈 캔버스가 아닌 제안된 해결책을 검토합니다.
실제 사례 – Issue #6066
- 사용자들은 Goose가 올바른 날짜‑시간이 컨텍스트에 있음에도 불구하고 계속 2024 로 기본값을 사용한다는 보고를 했습니다.
- 이슈는 이틀 동안 방치되었습니다.
- Tyler가 이를 보고 새벽 1:59 AM에
/goose solve this minimally라고 댓글을 남긴 뒤 (아마도 잠을) 돌아갔습니다. - 14 분 후, Goose가 PR #6101 을 열었습니다.
유지보수자의 역할은 구현에서 리뷰로 전환됩니다. 오픈소스에서 병목 현상은 드물게 “누군가가 코드를 작성할 수 있느냐”가 아니라 “충분한 컨텍스트를 가진 누군가가 시간을 내어 코드를 작성할 수 있느냐”입니다. Action은 이 두 제약을 분리합니다: 유지보수자는 코드베이스에 대한 깊은 이해 없이도 수정 시도를 트리거할 수 있습니다.
장점
| 장점 | 설명 |
|---|---|
| 속도 | 백로그에는 기능 요청, 복잡한 버그, 빠른 수정이 섞여 있습니다. Action을 사용하면 이슈를 가리키며 “이거 시도해줘” 라고 말할 수 있어 오후 전체를 할애하지 않아도 됩니다. |
| 비용 | Goose가 실패하면 몇 분의 컴퓨팅 비용만 손해입니다. 성공하면 몇 시간은 절약됩니다. |
| 반응성 | 사용자가 issue #6232 에서 슬래시 명령이 선택적 파라미터를 처리하지 못한다는 보고를 했을 때, 유지보수자는 빠르게 /goose can you fix this 라고 댓글을 달았습니다. 한 시간 이내에 수정이 포함된 draft PR과 네 개의 새로운 테스트가 올라왔습니다. PR에 조정이 필요하더라도 기여자들은 진행 중인 흐름을 확인할 수 있습니다. |
내부 동작
Maintainers는 이슈에 댓글로 /goose 뒤에 프롬프트를 달아 거위를 소환합니다. GitHub Actions는 거위가 설치된 컨테이너를 실행하고, 이슈 메타데이터를 전달한 뒤 거위가 작업을 수행하도록 합니다. 거위가 변경을 만들고 검증을 통과하면 워크플로는 draft pull request를 엽니다.
워크플로는 recipe 를 사용해 여러 단계를 정의합니다. 이를 통해 거위가 실제로 작업을 수행하고 우리가 요구한 것보다 더 많이 하지 않도록 보장합니다.
| 단계 | 거위가 하는 일 | 이유 |
|---|---|---|
| Understand (이해) | 이슈를 읽고 모든 요구사항을 파일에 추출 | 코드를 작성하기 전에 “완료”가 어떤 모습인지 AI가 식별하도록 강제 |
| Research (조사) | 검색 및 분석 도구로 코드베이스 탐색 | 익숙하지 않은 코드에 대한 무분별한 수정을 방지 |
| Plan (계획) | 접근 방식을 결정 | 구현 전에 아키텍처 오류를 잡아냄 |
| Implement (구현) | 최소한의 변경만 수행 | diff를 작게 유지하고 검토하기 쉬움 |
| Verify (검증) | 테스트 / 린터 실행 | 변경 사항이 기존 기능을 깨뜨리지 않도록 보장 |
| Report (보고) | 요약을 게시하고 draft PR을 엶 | 유지보수자가 명확한 인계 지점을 가짐 |
TL;DR
- 이전: 이슈 → 수동 트라이에이지 → 파편화된 디버깅 → 느린 PR.
- 현재: 이슈 → 댓글
/goose→ 자동 트라이에이지, 수정, draft PR → 유지보수자가 검토.
거위 기반 GitHub Action은 오픈소스 프로젝트가 품질이나 응답성을 희생하지 않고도 유지보수 워크플로를 확장할 수 있게 해줍니다. 🚀
개요
아래에 설명된 워크플로우는 goose 가 이슈를 해결할 때 안전하고 투명하게 동작하도록 도와줍니다.
주요 단계
| 단계 | 목적 |
|---|---|
| Verify | 테스트와 린터를 실행해 사람이 PR을 보기 전에 명백한 실패를 잡아냅니다. |
| Confirm | 원래 이슈와 요구사항을 다시 읽어, 작업의 절반을 놓친 채 승리를 선언하는 일을 방지합니다. |
작동 방식
- 워크플로 파일은 goose 에게 TODO 확장(
https://block.github.io/goose/docs/mcp/todo-mcp)에 접근할 수 있는 권한을 부여합니다. - 단계는 goose 에게 무엇을 해야 하는지 알려줍니다.
- TODO는 goose 가 무엇을 하고 있는지 기억하도록 도와줍니다. goose 가 코드베이스를 읽고 해결책을 구축하면서 컨텍스트 윈도우가 채워지고 초기 지시가 압축되거나 사라질 수 있습니다. TODO는 지속되므로 goose 는 언제든지 완료된 작업과 남은 작업을 확인할 수 있습니다.
가드레일
- 인증된 사용자만
/goose를 호출할 수 있습니다. - 워크플로는 goose 가 수정할 수 있는 파일을 제한합니다.
- 모든 PR은 병합 전에 유지관리자의 검토와 승인을 받아야 합니다.
Goose 로 Goose 를 유지하는 이유
- 도구의 역량에 대해 솔직해질 수 있게 합니다.
- 에이전트가 여기서 병합 가능한 PR 을 만들지 못하면 즉시 알 수 있습니다.
비전
AI 가 유지관리자를 대체하는 것이 목표가 아닙니다. 대신 유지관리자가 다음과 같은 워크플로를 가질 수 있기를 바랍니다:
- 문제를 지정한다.
- “이걸 시도해봐.” 라고 말한다.
- 구체적인 제안을 받는다 (빈 편집기가 아니라).
이 방식이 표준이 된다면, 오픈소스 프로젝트는 근본적으로 다른 방식으로 확장될 수 있습니다.
공개 접근
GitHub Action 워크플로는 공개되어 있어, 누구든지 자신의 CI 파이프라인에서 이 패턴을 탐색할 수 있습니다.