/goal을 효율적으로 사용하는 방법: 자율 에이전트는 마법 버튼이 아니라 운영 계약이다 (2026)
/goal은 에이전트를 더 똑똑하게 만들지 않아요. 그저 더 끈질기게 만들 뿐이에요. 올바른 방향으로 끈질긴 건 훌륭하지만, 잘못된 방향으로 끈질기면 괴로워요. 잘 쓰면 /goal은 운영 계약이 돼요. 즉 성과 + 범위 + 제약 + 검증 + 중단 규칙이지, "한 번 누르면 앱이 알아서 만들어지는" 마법의 버튼이 아니에요. 이 글은 실전에서 얻은 세 가지 교훈(과 그 해결책), 그리고 마침내 저에게 효과가 있었던 "낮에 계획하고 밤에 실행하는" 워크플로예요.
- /goal은 Codex 기능으로, 현재 기능 플래그가 걸려 있고 빠르게 바뀌고 있어요. 여기 나온 문법과 동작은 작성 시점에 공식 문서와 대조했지만, 의존하기 전에 최신 문서를 확인하세요.
/goal이 무엇인가 (그리고 무엇이 아닌가)
/goal은 Codex의 goal mode(OpenAI Codex CLI)로, 검증 가능한 중단 조건을 가진 길고 기계적인 목표를 위한 기능이에요. /experimental을 통해, 또는 config.toml의 [features] 아래에 goals = true를 추가해 활성화한 다음 /goal <objective>를 실행해요. 실행 중에는 /goal을 입력해 상태를 확인하고, /goal pause, /goal resume, /goal clear로 제어해요.
그리고 가장 중요한 부분은 이거예요. /goal은 안전 경계가 아니고, 제품 결정을 대신하지도 않으며, 무제한 백로그를 돌리는 곳도 아니에요. 그저 끈질긴 루프일 뿐이에요. (참고: /goal은 Codex 기능이지 Claude Code의 네이티브 명령이 아니에요. 둘을 혼동하지 마세요.) 문법은 공식 goal-mode 가이드를 참고하세요.
냉정한 진실: /goal은 에이전트를 더 똑똑하게가 아니라 더 끈질기게 만들 뿐
사람들은 /goal을 "한 번 누르면 앱이 알아서 만들어지는" 버튼처럼 띄워요. 저는 일주일 동안 남용하다가 매번 제대로 한 방 맞았어요. 결론은 간단해요. /goal은 에이전트를 더 똑똑하게 만들지 않고, 더 끈질기게 만들어요. 올바른 방향으로 끈질긴 건 훌륭하지만, 잘못된 방향으로 끈질기면 괴로워요. 스스로를 되묻지도 않고 잘못된 길을 그냥 내달려 버리거든요.
아래 세 번의 "한 방"은 가장 흔한 실패 유형과 각각에서 얻은 교훈이에요.
한 방 #1 - 오토 컴팩트 이후의 경계 이탈 (프로덕션 배포)
저는 목표를 아주 명확하게 적었어요. 스테이징에만 배포하라고요. 하지만 오토 컴팩트가 몇 번 지나자 에이전트는 컨텍스트를 벗어나 경계를 잊고 곧장 프로덕션에 배포해 버렸어요. 컴팩트할 때마다 작업을 상기시키는 훅이 있었는데도요.
뼈아픈 교훈이에요. 에이전트에게 프로덕션에 대한 특권 접근을 절대 주지 마세요. "기억하겠지"를 믿지 마세요. 아니에요. 생각만큼 확실하게 기억하지 못해요. 바로 이것이 goal mode가 안전 경계가 아닌 이유예요. 안전선은 프롬프트 속 메모가 아니라 권한 안에 있어야 해요. 접근을 조이는 방법은 Claude Code 권한과 AI 코딩 보안 모범 사례를 참고하세요.
한 방 #2 - 모호한 목표는 헤매도 좋다는 허가증
"더 예쁘게 해줘." "UX를 개선해줘." 사람에게는 그럴듯하게 들려요. 하지만 에이전트에게는 헤매도 좋다는 허가증이에요. 하나를 바꾸고, 다른 하나를 망가뜨리고, 조금 환각을 일으키고, 때로는 아무것도 뚜렷이 나아지지 않았는데 일찍 멈추기도 했어요.
교훈이에요. 목표는 "더 낫다"가 무엇인지 정의해야 해요. 어떻게 예쁘게요?
- 여백을 더 촘촘하게?
- 더 읽기 쉬운 대비?
- 더 나은 모바일 반응형?
- 체크아웃 단계 줄이기?
- 완료율 높이기?
무엇을 원하는지 모른다면, 그것을 에이전트에 던지고 /goal을 실행하지 마세요. 먼저 브레인스토밍하고, 계획하고, 수용 기준을 쓰세요. 요구사항이 아직 불명확할 때는 자율성을 켜기보다 어드바이저에게 명확화를 요청하는 것(advisor/kongming)이 나아요. 구체적인 점검이 담긴 계획을 쓰는 법은 Claude Code를 위한 프로젝트 계획을 참고하세요.
한 방 #3 - 검증 누락 (자신만만한 가짜 "완료")
저는 새 프론트엔드 페이지에 목표를 설정했지만, 시각적 검증을 위해 agent-browser를 쓰라고 에이전트에게 말하는 걸 깜빡했어요. 결과는요? 진짜 검증을 건너뛰고 자신만만하게 "성공적으로 완료했습니다"라고 보고했어요. 그리고 열어 보고, 인생은 동화가 아니라는 걸 다시 떠올렸죠.
교훈이에요. 아무도 믿지 마세요. 적절한 도구를 제공하고, 끝내기 전에 그 도구를 쓰라고 에이전트에게 명시적으로 요구하세요. 테스트가 초록불인 것만으로는 부족해요.
- 프론트엔드는 직접 봐야 해요(스크린샷/agent-browser).
- 워크플로는 클릭해서 통과시켜야 해요.
- 배포는 환경을 확인해야 해요.
- PR은 diff를 리뷰해야 해요.
운영 계약 - 좋은 /goal을 위한 공식
요컨대 좋은 /goal은 영리한 프롬프트가 아니에요. 다섯 부분으로 이루어진 운영 계약이에요.
| 부분 | 답하는 질문 |
|---|---|
| 성과(Outcome) | "완료"란 무엇을 뜻하는가? (구체적이고 측정 가능한 결과) |
| 범위(Scope) | 무엇을 건드려도 되고, 무엇을 건드리면 안 되는가? |
| 제약(Constraints) | 어떤 경계를 깨면 안 되는가(프로덕션 금지, 공개 API 변경 금지…)? |
| 검증(Verification) | "완료"는 어떻게 증명되는가(테스트, 빌드, 스크린샷, 클릭 확인)? |
| 중단 규칙(Stop rules) | 언제 멈추고, 언제 사람에게 물어보는가? |
이것은 goal mode의 "사용 테스트"와 맞아떨어져요. 즉 작업이 (1) 한 턴보다 길고 대체로 기계적이며, (2) 검증 가능한 중단 조건을 갖고, (3) 각 체크포인트마다 제품 결정을 필요로 하지 않고 진행할 만큼 명확하게 범위가 정해졌을 때만 쓰세요. 탐색적 작업, 모호한 개선 요청, 프로덕션 자격 증명 변경, 파괴적인 공유 인프라, 뒤섞인 백로그에는 /goal을 쓰지 마세요.
제가 /goal을 쓰는 법: 낮의 계획과 밤의 실행을 분리하기
지금 제가 가장 좋아하는 방식은 낮의 사고와 밤의 실행을 분리하는 거예요.
낮 (사고)
- 각 버그 / 기능 / 개선마다 GitHub 이슈를 만들어요.
- 브레인스토밍과 계획 스킬로 각 이슈를 명확히 해요.
- 구현 요약 +
plan.md링크를 이슈에 댓글로 달아요. ready to implement라벨을 추가해요.- 모든 이슈가 준비될 때까지 반복해요.
밤 (실행)
쉬면서 가족과 시간을 보내기 전에, 저는 /goal을 돌려요. "미리 정한 계획에 따라 ready-to-implement 태그가 붙은 모든 이슈를 구현하라." 이슈당 루프는 이래요.
- 이슈를 우선순위로 정렬해요.
- 한 번에 하나의 이슈를 구현해요.
- 이슈마다 별도의 worktree와 브랜치를 만들어요.
ak:cook --auto(계획에 대한 연속 실행).ak:code-review.ak:ship beta.ak:review-pr --fix.ready to ship라벨을 추가하고, 다음 이슈로 넘어가요.
이 편이 훨씬 잘 돼요. 에이전트는 더 이상 "뭘 원하세요?"라고 넘겨짚지 않아요. 명확해진 계획에 대해 자기 브랜치, 리뷰, 베타 배포, PR, 라벨과 함께 실행해요. 일어나서 커피를 내리고 컴퓨터를 열면 PR 더미가 기다리고 있어요. 제 일은 더 이상 마이크로매니징하는 광대처럼 "continue"를 치는 게 아니에요. 사람 눈으로 리뷰하고, 다시 테스트하고, 그다음 머지하는 거예요. worktree/PR을 병렬로 돌리는 법은 서브에이전트 오케스트레이션을 참고하고, 이 루프를 브레인스토밍 → 계획 → cook → ship 워크플로 안에 두세요.
게이트 루프를 미리 만들어 두고 싶다면? (AgentKit)
밤 루프가 강력한 건 품질 게이트 덕분이에요. ak:cook, ak:code-review, ak:ship, ak:review-pr. AgentKit은 이 게이트들을 제공하고 Claude Code와 Codex 양쪽에서 돌아가요. 그래서 Codex의 /goal에도 잘 맞아요. 솔직히 말하면 /goal은 Codex 것이고 무료예요. 키트는 미리 만들어진 프로세스 + 리뷰를 더해줄 뿐이라, 직접 조립할 필요가 없어요. 자세한 건 AgentKit 리뷰나 Engineer Kit 리뷰를 읽어보세요.
/goal의 진짜 가치
그게 /goal의 진짜 가치예요. 에이전트가 당신을 대신해 사고하게 하는 게 아니라, 당신이 이미 사고를 끝낸 뒤의 반복 실행을 맡기는 거예요. 사고는 당신이 하고(사양, 계획, 수용 기준), 그다음 묵묵히 갈게 하세요. 당신의 일은 사람 눈으로 리뷰하고, 다시 테스트하고, 그다음 머지하는 거예요.
자주 묻는 질문 (FAQ)
/goal은 무엇이고, 어느 도구의 것인가요?
/goal은 Codex의 goal mode(OpenAI Codex CLI)로, 현재 기능 플래그가 걸려 있어요. /experimental을 통해, 또는 config.toml의 [features] 아래에 goals = true를 추가해 활성화해요. 이것은 Claude Code의 네이티브 명령이 아니에요. 둘을 혼동하지 마세요.
/goal을 쓰면 안 되는 때는 언제인가요?
탐색적 작업, 모호한 요구사항, 프로덕션 자격 증명 변경, 파괴적인 공유 인프라 작업, 범위가 불명확한 뒤섞인 백로그일 때예요. /goal은 검증 가능한 중단 조건을 가진, 기계적이고 오래 걸리는 작업에 잘 맞아요.
좋은 목표는 어떻게 쓰나요?
다섯 부분으로 이루어진 운영 계약으로 다루세요. 성과("완료"의 의미), 범위(건드려도/안 되는 것), 제약(깨면 안 되는 경계), 검증("완료"를 어떻게 증명하는가), 중단 규칙(언제 멈추고 언제 사람에게 물을지)이에요.
/goal이 프로덕션에 안전하게 배포할 수 있나요?
그러면 안 돼요. 에이전트에게 프로덕션 접근을 주지 마세요. goal mode는 안전 경계가 아니에요. 안전선은 프롬프트 메모가 아니라 권한(최소 권한) 안에 있어요. 오토 컴팩트가 몇 번 지나면 에이전트가 경계를 잊을 수 있어요.
에이전트가 "완료"라고 보고하는 데 초록불 테스트만으로 충분한가요?
아니에요. 프론트엔드는 직접 보고(스크린샷/agent-browser), 워크플로는 클릭해서 통과시키고, 배포 환경은 확인하고, PR diff는 리뷰해야 해요. 적절한 도구를 제공하고, 끝내기 전에 그것을 쓰라고 에이전트에게 요구하세요.
/goal을 쓰려면 AgentKit이 필요한가요?
아니에요. /goal은 Codex 것이고 무료예요. AgentKit은 ak:cook / ak:code-review / ak:ship / ak:review-pr 게이트를 루프 안에서 돌리도록 더해줄 뿐이에요. 직접 조립하는 대신 미리 만들어진 프로세스를 원할 때 유용해요.
결론
/goal을 신화로 만들지 마세요. 그것은 고집스러운 루프이고, 당신이 사고를 끝낸 뒤 반복 실행만 필요할 때 유용해요. 목표를 운영 계약으로 쓰고, 프로덕션 접근을 잠그고, 검증을 요구하고, 낮의 계획과 밤의 실행을 분리하세요. 실행 전에 요구사항을 명확히 해야 하나요? advisor 대 kongming을 참고하세요. 수용 기준이 담긴 계획이 필요하나요? Claude Code를 위한 프로젝트 계획을 참고하세요.
당신의 /goal 루프에 미리 만들어진 품질 게이트를 원하세요? AgentKit Engineer Kit은 ak:cook, ak:code-review, ak:ship, ak:review-pr을 Claude Code와 Codex용으로 제공해요. 프로세스를 직접 조립할 필요가 없어요. 가격은 $99이고, 반복 요금 표시는 없어요.