당신의 AI 에이전트는 계획이 필요합니까?
I’m sorry, but I can’t retrieve the content from the link you provided. Could you please paste the text you’d like translated here? Once you do, I’ll translate it into Korean while preserving the original formatting and markdown.
Planning: A Spectrum, Not a Binary Choice
실제 질문은 계획을 할지 말지가 아니라, 현재 작업과 작업 스타일에 맞게 어떻게 계획하느냐입니다.
- 개발자마다 다른 접근 방식 – 어떤 사람은 상세한 의사코드를 작성하고, 다른 사람은 테스트‑주도 개발을 실천하며 아키텍처를 자연스럽게 형성합니다.
- 팀마다 습관이 다름 – 어떤 팀은 화이트보드에 복잡한 다이어그램을 스케치하고, 다른 팀은 빠른 프로토타입을 만들어 “빠르게 실패”하고 나중에 리팩터링합니다.
수동으로 코딩할 때 계획이 스펙트럼이라면, AI 코딩 에이전트를 사용할 때도 왜 스펙트럼이어야 할까요?
The Debate on “Plan Mode” for AI Agents
전용 Plan Mode가 필수인지, 아니면 불필요한 오버헤드인지에 대한 활발한 업계 논의가 있습니다.
- 언제든지 에이전트에게 “먼저 계획을 세워라” 라고 지시할 수 있습니다.
- 일부는 내구성 있는 계획이 코드와 함께 보고, 편집하고, 버전 관리할 수 있는 파일에 있어야 한다고 주장합니다.
실제 가치가 중요한 것은 계획 자체가 아니라, 개발자에게 제공되는 정신 모델과 워크플로우입니다. 때로는 에이전트가 즉시 실행하기를 원하고, 때로는 코드 변경이 일어나기 전에 에이전트의 사고 과정을 보고 피드백을 주며 협업하고 싶을 때가 있습니다.
goose는 상황에 따라 서로 다른 방법이 필요하다는 점을 인식하고 두 철학을 모두 수용합니다.
Source:
전략 선택
설계자를 위한 – /plan 모드
Goose CLI에서 plan mode를 실행하면, Goose는 즉시 실행하는 대신 대화형 인터랙션으로 전환됩니다. 다음과 같은 항목에 대해 명확히 하기 위한 질문을 합니다:
- 기술 스택 선호도
- 인증 요구 사항
- 배포 대상
- 오류 처리 전략
이러한 질문과 답변을 주고받으며 Goose가 충분한 컨텍스트를 확보하면, 포괄적이고 실행 가능한 계획을 생성합니다.
- 맞춤 플래너 설정 – 환경 변수를 통해
GOOSE_PLANNER_PROVIDER와GOOSE_PLANNER_MODEL을 지정하여 전략적 계획에 사용할 모델과 실행에 사용할 모델을 각각 지정할 수 있습니다. - 체크포인트 – 계획을 승인하면 Goose가 메시지 히스토리를 정리하고 실행에 들어가, 코드 변경 전 깨끗한 상태에서 시작할 수 있습니다.
예시: 정적 Vite/React 프로젝트를 Next.js로 마이그레이션할 때 이 방식을 사용했습니다. Goose는 의존성 업데이트, 라우팅 변경, 컴포넌트 경계 등 각 단계에 체크박스를 포함한 11단계 마이그레이션 계획을 제시했습니다. “yes start”라고 하면 단계별로 체계적으로 실행하고, 각 단계가 끝날 때마다 커밋했습니다.
감독자를 위한 – Instruction Files
구체적으로 해야 할 작업이 이미 정해져 있다면, 직접 플랜 파일을 작성해 Goose에 전달할 수 있습니다.
-
Markdown 파일(예:
plan.md)을 만들고 다음 내용을 포함합니다:- 코드베이스에 대한 컨텍스트
- 수정할 구체적인 파일
- 기대 결과 및 검증 단계
-
실행합니다:
goose run -i plan.md- 이미 아키텍처를 스케치했거나 설계 문서를 작성했거나, 혹은 Goose가 추가 질문을 할 필요 없이 코드베이스를 충분히 이해하고 있는 경우에 유용합니다.
- Instruction Files는 headless mode에서도 실행할 수 있어 CI/CD 파이프라인이나 자동화에 활용할 수 있습니다(튜토리얼 보기).
핵심 아이디어: 플랜은 당신이 소유하고, 실행은 Goose가 담당합니다.
탐험가를 위한 – 대화형 컨텍스트 구축
이 접근법은 세 가지 Goose 기능을 결합합니다:
-
대화형 플래닝 – Goose를 페어링 파트너처럼 활용합니다. 분석, 설명, 탐색을 요청하고, 실행에 앞서 공유된 정신 모델을 구축합니다.
-
Todo 확장 – todo extension은 복잡성을 감지합니다. 작업에 여러 단계, 파일, 혹은 불확실한 범위가 포함될 경우 자동으로 체크리스트를 생성하고 진행 상황을 업데이트하며 완료된 항목을 체크합니다.
-
프로젝트 규칙 –
goosehints이나agents.md와 같은 파일을 사용해 지속적인 선호도, 커밋 정책, 테스트 요구사항, 프로젝트 컨벤션 등을 인코딩합니다. 이러한 규칙은 매번 반복해서 지정하지 않아도 에이전트를 안내합니다.
이 기능들을 함께 사용하면 구조적인 기반 위에 캐주얼하고 탐색적인 대화를 진행할 수 있습니다:
- 프롬프트를 의도적으로 제한 – 대화를 집중시킵니다.
- Todo 확장이 복잡성을 조직 – 필요할 때 자동으로 정리됩니다.
- 프로젝트 규칙이 보이지 않는 골격 제공 – 더 나은 의사결정을 지원합니다.
어떤 상황에도 딱 맞는 단일 철학은 없습니다. 현재 워크플로에 가장 적합한 모드를 선택하고, Goose가 여러분에게 맞게 적응하도록 하세요.
# Your preferences are always in play
This is typically how I work. When I migrated a legacy LLM credit‑provisioning app to **Next.js**, many cringed at my approach. However, in context, I was returning to a codebase I'd built eight months earlier and didn't remember well. The app was split across two repositories and I didn't know which one handled what. Writing a `plan.md` file upfront would have been guessing.
So I asked **goose** to analyze both projects and expl그들이 어떻게 소통했는지. 나는 프롬프트를 의도적으로 제한했다: “프론트엔드만, API 호출은 하지 않음.” 나는 todo 확장을 활성화했는데, 범위가 명확해지면 구조를 만들 것이라는 것을 알고 있었다. 또한 커밋을 자동으로 처리하도록 프로젝트 규칙을 구성해 두었다.
이 접근 방식은 사전 계획보다 더 많은 왕복을 필요로 했지만, 그 프롬프트들은 헛된 노력이 아니었다. 실제 마이그레이션을 가능하게 만든 컨텍스트를 구축했다. goose가 체크리스트를 만들 때쯤 우리는 무엇을 해야 하는지 서로 이해하고 있었다.
## 당신의 스타일은?
Goose는 개발자들이 한 가지 모드만으로 일하지 않기 때문에 여러 계획 철학을 지원합니다:
- **건축가**는 코드 전에 명확성을 원합니다.
- **감독**은 제어를 원합니다.
- **탐험가**는 작업을 통해 계획을 발견합니다.
이 접근 방식 중 어느 것이 우월한 것은 아니며, 각각 다른 상황에 맞습니다. 같은 개발자가 월요일에 잘 정의된 마이그레이션을 위해 `/plan` 모드를 사용하고, 화요일에는 익숙하지 않은 코드베이스에 대해 대화형 컨텍스트 구축을 사용할 수 있습니다.
문제는 계획을 세워야 하는가가 아니라 **오늘 당신의 상황에 맞는 계획 유형**입니다.
> **Goose와 함께 다양한 계획 접근 방식을 시도해 보시겠습니까?**
> 우리의 [quickstart guide](https://block.github.io/goose/docs/quickstart)부터 시작하거나 [context engineering documentation](https://block.github.io/goose/docs/guides/context-engineering)을 탐색하여 스캐폴딩을 설정하세요.