Claude Code의 /goal: 2026년 자율 모드와 Agent View

Ailoot 참고 문서: ailoot.ai/docs/.

Claude Code의 /goal이란?#

이전에는 Claude Code가 각 응답 뒤에 멈춰 다음 프롬프트를 기다렸습니다. 짧은 작업에는 문제가 없었지만 긴 작업에서는 한계가 있었습니다. API 마이그레이션, 실패한 테스트 12개 수정, 800줄 파일 리팩터링 같은 작업에는 20~30회 반복이 필요하고, 매번 사용자가 터미널로 돌아가야 했습니다.

/goal은 간단한 아이디어로 이 문제를 해결합니다. “일을 하는 쪽”과 “완료 여부를 판단하는 쪽”을 분리하는 것입니다. 주 에이전트가 코드를 작성합니다. 별도의 평가자(빠른 Haiku 모델)가 매 턴이 끝난 뒤 대화를 읽고 한 가지 질문에 답합니다. “조건을 충족했는가?” 아니라면 에이전트가 다음 턴을 시작합니다. 그렇다면 제어권이 사용자에게 돌아옵니다.

Anthropic의 공식 문서에서는 이를 다음과 같이 정의합니다.

휴대전화로 밤새 에이전트 수천 개를 돌리는 것은 마케팅 문구가 아니라 Anthropic 엔지니어의 현재 작업 방식입니다. 이를 가능하게 하는 메커니즘은 2026년 5월 11일 같은 릴리스에서 도입된 /goal + Agent View의 조합입니다.

자율 모드는 왜 필요한가: 2026년 5월 11일 전후로 무엇이 달라졌나?#

“AI가 밤새 작업하게 두기”라는 아이디어는 Cursor Composer와 Cline 자동 모드가 이미 백그라운드에서 실행될 수 있었던 2025년 가을부터 있었습니다. 하지만 2026년 5월 11일 전까지 Claude Code에서 이를 사용하려면 수동 래퍼가 필요했습니다. N분마다 claude -p를 호출하는 cron 작업이나 git status를 감시해 다음 프롬프트를 실행하는 래퍼가 그 예입니다.

이런 DIY 방식은 반복해서 사고를 일으켰습니다. 2026년 5월 22일 한 개발자는 밤새 스크립트를 실행해 두었다가 6,000달러 청구서를 받고 깨어났습니다. 근본 원인은 Anthropic이 알림 없이 Claude Code의 캐시 TTL을 1시간에서 5분으로 바꾼 것이었습니다. Cron은 30분마다 프로덕션을 호출했고, 각 실행 사이에 캐시가 만료될 시간이 있었습니다. 실행할 때마다 800,000토큰의 기록을 처음부터 다시 만들었습니다. 새 데이터를 캐시에 쓰는 비용은 활성 캐시에서 읽는 비용보다 훨씬 높습니다.

그 개발자는 특별한 일을 한 것이 아니었습니다. Anthropic이 안내한 그대로 도구를 사용했을 뿐입니다.

/goal은 내장 아키텍처로 이 문제를 해결합니다.

1. 감독자 프로세스가 세션을 터미널 밖에서 유지하고, 창을 닫거나 노트북이 잠자기 상태가 되어도 계속 실행합니다.
2. Haiku 평가자는 저렴한 모델로 각 턴을 확인하며, 평가자 토큰 비용은 몇 센트에 불과합니다.
3. 조건에 설정하는 엄격한 턴 제한을 통해 or stop after 20 turns라고 명시할 수 있으며, 세션은 반드시 멈춥니다.
4. 백그라운드 세션의 worktree 격리를 사용하면 변경 사항이 별도 브랜치에 적용되어 작업 중인 사본에 영향을 주지 않습니다.

“bash 스크립트를 직접 작성하는” 방식과의 차이는 Anthropic이 이 모든 메커니즘을 서드파티의 임시방편이 아니라 도구의 기본 기능으로 제공한다는 점입니다.

3단계로 /goal 활성화하기#

1단계. Claude Code를 2.1.139 이상으로 업데이트합니다.

버전을 확인합니다.

claude --version

버전이 2.1.139보다 낮으면 업데이트합니다.

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

2026년 5월 12일부터 19일까지의 릴리스에서는 첫 버전의 중요한 버그가 수정되었습니다. 2.1.140에서는 disableAllHooks가 평가자를 차단하던 무응답 멈춤 문제가 수정되었습니다. 2.1.143에서는 worktree.bgIsolation: "none"과 stop hook 반복 실행에 대한 수정이 추가되었습니다. 2.1.144(5월 19일)에서는 백그라운드 세션의 --resume과 스크립팅을 위한 에이전트 --json이 추가되었습니다. 최소 버전은 2.1.143입니다.

2단계. 조건과 함께 /goal을 입력합니다.

일반 Claude Code 세션을 열고 다음 명령을 입력합니다.

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

이후 별도의 프롬프트를 보낼 필요가 없습니다. 명령이 첫 턴을 즉시 시작합니다. 조건은 러시아어, 영어 또는 두 언어를 섞어서 작성할 수 있으며 모델은 두 언어를 모두 이해합니다. 길이는 최대 4,000자입니다.

3단계. 실시간 오버레이로 모니터링합니다.

/goal이 시작되면 터미널 하단에 실시간 패널이 표시됩니다.

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

표시되는 정보:

• Turns: 완료된 턴 수
• Elapsed: 시작 후 경과 시간
• Tokens: 사용한 총 토큰(예산 모니터링의 주요 수치)
• Last: 평가자가 마지막으로 “아직”이라고 답한 이유

유용한 요령이 하나 있습니다. 평가자가 같은 이유를 세 턴 연속으로 반환하면 반복 상태에 빠졌다는 신호입니다. Ctrl+C를 누르거나 /goal clear(동의어: stop, off, reset, cancel)를 입력하고, 조건을 다시 표현한 뒤 다시 시작하세요. 커뮤니티의 /goal 가이드에서는 이 규칙을 반복 실행의 주요 신호로 꼽습니다. “같은 이유로 세 번 막혔다면 반복 상태이니 빠져나오세요.”

좋은 조건을 작성하는 법: 규칙 5가지와 예시 5가지#

Anthropic 문서는 좋은 조건에 필요한 세 가지 요소를 설명합니다.

바로 사용할 수 있는 템플릿은 세 요소를 한 줄에 모두 담습니다.

/goal [작업 수행] [측정 가능한 최종 상태]가 될 때까지, [준수해야 하는 제약]은 지키면서

대부분의 사람이 놓치는 규칙 5가지:

규칙 1. 최종 상태는 취향이 아니라 명령어로 검증할 수 있어야 합니다.

“보기 좋게 만들어”가 아니라 npm test exits 0이라고 하세요. “UX를 개선해”가 아니라 Lighthouse Performance score above 90이라고 하세요. 평가자는 대화 기록만 읽습니다. 명령을 실행하거나 스크린샷을 보지 않습니다. 결과를 텍스트로 기록할 수 없다면 평가자는 절대 “예”라고 답하지 않습니다.

규칙 2. 제약은 명시적이고 범위가 좁아야 합니다.

제약이 없으면 Claude는 테스트를 삭제하거나 실패하는 단언문을 주석 처리해 테스트를 고칠 수도 있습니다. without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies라고 지정하세요.

규칙 3. 엄격한 턴 제한은 필수입니다.

모든 조건에 or stop after N turns를 추가하세요. 끝없는 반복을 막는 안전망입니다. 제한을 두지 않으면 한 시간 동안 실행되는 반복 작업은 같은 일을 수동으로 하는 것보다 더 많은 토큰을 소모할 수 있습니다. 이를 예산에 반영하세요.

규칙 4. 방법만이 아니라 원하는 결과를 설명하세요.

조건에 시각적 요소를 언급하지 않았다면 Claude는 이를 만들지 않습니다. 조건이 “테스트 통과”만 요구하면 Claude가 복잡한 테스트를 주석 처리할 수도 있습니다. 검증 방법뿐 아니라 원하는 결과를 설명하세요.

규칙 5. Claude가 채팅에 증거를 보여주도록 하세요.

평가자는 명령을 실행하지 않습니다. Claude가 이미 보여준 내용만 읽습니다. 조건에 “npm test 통과”가 포함되어 있어도 Claude가 대화 기록에 npm test 출력을 보여주지 않았다면 평가자는 영원히 “아직”이라고 답할 수 있습니다. 조건에 “대화에 <command>의 출력을 보여줘”라는 문구를 추가하세요.

일반적인 작업에 바로 쓸 수 있는 예시 5가지:

1. API 마이그레이션:
/goal getUser() 호출이 모두 fetchUser()로 바뀌고, npm test가 통과하며, npm run build가 성공하고, 다른 API 이름은 건드리지 않았거나, 30턴 후 중지

2. 테스트 수정:
/goal test/auth의 실패한 테스트가 모두 통과하고 (npm test 결과 0 failures가 채팅에 표시됨), 단언문을 변경하거나 테스트를 삭제하지 않았거나, 20턴 후 중지

3. 코드 품질(파일 크기):
/goal src/legacy/UserService.ts를 각각 200줄 미만인 파일로 나누고, 모든 import를 업데이트하고, npm run build가 성공했거나, 25턴 후 중지

4. 백로그 처리:
/goal 'good-first-issue' 레이블이 붙은 모든 이슈를 처리: 설명을 읽고, worktree 브랜치에서 수정 사항을 구현하고, PR을 엽니다. 대기열이 비거나 이슈 6개를 처리할 때까지 계속

5. 보안 감사:
/goal 심각도가 >= high인 모든 npm audit 취약점을 수정하고, 모든 기존 테스트가 통과하며, 호환성을 깨는 API 변경이 없거나, 15턴 후 중지

단순히 /goal을 실행하는 것을 넘어 자율 모드가 프로젝트에서 제대로 작동하는 환경을 만들고 싶으신가요? /goal은 마지막 연결 고리일 뿐입니다. 그 전에 세 가지 기반이 필요합니다. AI 클론(Skills와 Subagents에 담긴 방법론), 두 번째 두뇌(CLAUDE.md와 plans/ 폴더), 그리고 컨텍스트 엔지니어링(Plan Mode와 /compact)입니다. 세 구성 요소를 함께 설계해야 컨텍스트를 활용한 작업을 뒷받침할 수 있습니다.

/goal이 실제로 잘 작동하는 예시 5가지#

Anthropic 문서는 /goal에 적합한 작업 유형을 네 가지로 제시합니다.

바로 사용할 수 있는 조건이 포함된 예시 5가지입니다. 복사해 프로젝트에 맞게 조정하세요.

예시 1. 모듈을 새 API로 마이그레이션하기.

상황: REST에서 GraphQL로 옮기거나 기존 getUser() 함수를 새 fetchUser() 함수로 바꾸려고 합니다. 기계적인 작업이지만 파일 30~50개를 수정해야 합니다.

조건:

/goal src/의 모든 getUser()를 fetchUser()로 바꾸고, 모든 호출을 새 인터페이스(userId 대신 id)에 맞게 업데이트하고, npm test를 통과시키고, src/ 외부 파일은 건드리지 않았거나, 30턴 후 중지

효과가 있는 이유: grep -r getUser src/ | wc -l(결과는 0이어야 함)과 npm test exits 0으로 최종 상태를 확인할 수 있습니다. 제약은 테스트 파일을 보호합니다.

예시 2. 실패하는 테스트 수정하기.

상황: 라이브러리 업데이트 뒤 테스트 15개가 실패했습니다. mock을 업데이트하고 단언문을 새 형식에 맞추는 기계적인 수정임을 알고 있습니다. 직접 처리하고 싶지는 않습니다.

조건:

/goal test/의 실패한 테스트가 모두 통과하고, npm test 결과 0 failures가 채팅에 표시되며, 테스트를 삭제하거나 단언문을 주석 처리하지 않았거나, 25턴 후 중지

같은 유형의 조건을 보여 주는 또 다른 예시입니다.

/auth 디렉터리 밖의 파일은 하나도 수정하지 않고, npm test 결과가 0이 될 때까지 실패한 테스트를 모두 수정하기

예시 3. 거대 클래스 분할하기.

상황: 1,200줄짜리 파일 하나에 모델, 서비스, 유틸리티, API 클라이언트가 모두 들어 있습니다. “파일 하나에 책임 하나” 원칙에 따라 분할하고, 모든 import를 업데이트하며, 테스트를 통과시키고 싶습니다.

조건:

/goal src/legacy/UserService.ts를 200줄 미만인 파일로 나누고, 각 파일이 모델, 리포지토리, api-client, validator 중 하나의 책임만 맡게 하고, 모든 import를 업데이트하고, npm run build를 성공시키고, 기존 테스트를 통과시키거나, 25턴 후 중지

예시 4. 밤새 이슈 백로그 처리하기.

상황: good-first-issue 레이블이 붙은 이슈 20개가 있는 오픈 소스 저장소가 있습니다. Claude가 밤새 이슈를 처리하길 원합니다.

조건:

/goal 'good-first-issue' 레이블이 붙은 모든 이슈를 처리: 설명을 읽고, 별도의 worktree 브랜치 worktree-issue-N에서 수정 사항을 구현하고, 설명을 포함한 PR을 엽니다. 대기열이 비거나 이슈 6개가 처리될 때까지 계속하거나, 80턴 후 중지

숫자 6은 임의로 고른 것이 아닙니다. Pro 요금제로 하룻밤에 처리하기에 현실적인 상한입니다.

예시 5. 보안 감사.

상황: npm audit에서 심각도가 높은 취약점 8개가 나옵니다. 메이저 버전을 업데이트하지 않고 Claude가 문제를 수정하길 원합니다.

조건:

/goal 심각도가 high+인 모든 npm audit 취약점을 수정하고, npm audit 결과 0 high가 채팅에 표시되고, 모든 기존 테스트를 통과시키고, 호환성을 깨는 API 변경이나 패키지 메이저 버전 업데이트는 하지 않았거나, 15턴 후 중지

/goal로 하지 말아야 할 작업:

Croucher는 현장 가이드에서 실용적인 기준을 강하게 강조합니다. “완료”가 “보기 좋다”, “느낌이 맞다”, “잘 설계됐다” 또는 “재밌다”를 뜻하는 작업에는 /goal을 사용하지 마세요. 평가자는 대화 기록만 읽고, 도구를 실행하거나 결과물이 어떻게 작동하는지 평가할 수 없습니다. 이 기준에 따르면 유용한 결과 없이 /goal이 반복 실행되는 주관적 작업의 80%는 제외됩니다.

/goal이 돈만 낭비하는 경우: 안티패턴 3가지#

안티패턴 1. 엄격한 턴 제한이 없는 모호한 조건.

가장 흔한 실수는 “코드를 개선해”, “좋게 만들어”, “최적화해” 같은 조건입니다. 턴 제한이 없으면 에이전트는 할당량을 다 쓸 때까지 계속 실행됩니다.

Findskill은 실제 사례를 소개했습니다.

한 개발자는 모호한 조건으로 14시간 세션을 진행하며 200달러를 썼다고 보고했습니다. 평가자가 계속 “아직”이라고 답하도록 하는 약한 조건은 알아차리기 전에 50회, 100회 또는 500회까지 실행될 수 있습니다.

모호한 조건에 14시간 동안 쓴 200달러는 Max 요금제의 주간 한도 전체에 해당합니다. 아침에 일어나면 할당량은 없고 쓸 만한 결과도 없습니다.

예방책: 모든 조건을 or stop after N turns로 끝내세요(쉬운 작업은 15회, 어려운 작업은 50회, 밤샘 실행은 최대 100회).

안티패턴 2. 캐싱이 깨진 재귀적 반복 실행.

2026년 5월 22일 한 개발자는 캐시 TTL이 1시간에서 5분으로 조용히 변경된 뒤 하룻밤 사이 6,000달러가 청구됐다고 보고했습니다. 해당 개발자가 /goal을 직접 사용한 것은 아니지만, 30분 cron 타이머를 사용하는 자율 반복 실행이 매번 800,000토큰 기록을 처음부터 다시 만든다는 점에서 같은 논리였습니다.

근본적인 문제는 외부 자동화가 제공자의 내부 변경 사항을 알지 못했다는 것입니다. 감독 없이 /goal을 8시간 동안 실행하면 같은 일이 생길 수 있습니다. 토큰 사용량이 비선형적으로 증가하고 프롬프트 캐시가 예상한 대로 작동하지 않을 수 있습니다.

예방책:

1. 중간 점검 없이 /goal을 8시간 이상 실행하지 마세요.
2. Settings → Usage에서 사용량 제한을 활성화하세요(6,000달러 사고 뒤 추가된 안전장치).
3. 밤사이에 claude agents를 두 번 여세요. Space를 눌러 살펴보고 턴 수가 예상보다 빠르게 늘고 있지 않은지 확인하세요.
4. 비용이 많이 드는 모델 체인(Opus 4.7)의 경우 더 엄격한 턴 제한을 설정하세요. 최대 30회입니다.

안티패턴 3. /goal로 창작하기.

Croucher는 게임을 만들기 위해 /goal을 실행했습니다. 조건에는 결정성, 불변 조건, 레벨을 클리어할 수 있는지 확인하는 항목이 포함되어 있었습니다. 게임이 만들어지고 테스트가 통과하자 평가자는 “달성”이라고 판단했습니다. 하지만 게임에 시각적 요소는 없었습니다. 조건에 그래픽이 언급되지 않았기 때문입니다.

이는 일반적인 규칙을 보여줍니다. 평가자는 측정하는 항목을 정확히 최적화합니다. 조건에 시각적 요소가 없다면 그런 요소도 없습니다. 테스트만 언급하면 단언문을 주석 처리할 수도 있습니다.

예방책: 취향에 좌우되는 작업(디자인, 카피, UX)에는 /goal을 사용하지 마세요. 일반 세션이나 Plan Mode로 돌아가세요. 두 방식은 결정 과정에 계속 참여할 수 있게 합니다.

Agent View란 무엇이며 대시보드를 여는 방법#

/goal이 “끝날 때까지 작업하라”는 명령이라면 Agent View는 여러 명령을 한 번에 확인할 수 있는 관제실입니다. Anthropic은 이를 다음과 같이 설명합니다.

여는 명령:

claude agents

터미널 안에 텍스트 대시보드인 TUI가 열립니다. 왼쪽에는 세션 목록이 있고, 오른쪽에는 선택한 행의 최신 메시지를 보여주는 peek 패널이 있습니다.

세션 상태 6가지:

주요 단축키:

↑ / ↓             세션 목록 이동
Space             peek 패널(연결 없이 보기)
Enter / →         세션에 연결(진입)
←                 연결 해제(세션을 종료하지 않고 나가기)
Ctrl+T            고정(자동 중지로부터 세션 보호)
Ctrl+X            세션 중지; 2초 안에 다시 누르면 삭제
Ctrl+R            이름 변경
Ctrl+S            그룹화 전환(상태 ↔ 디렉터리)

백그라운드 세션 시작 방법:

대화형 Claude Code에서:

/bg fix the failing test test/auth/login.test.ts

또는 셸에서 직접:

claude --bg "fix the failing test test/auth/login.test.ts"

또는 Agent View에 알아보기 쉬운 이름으로 표시되도록 이름을 지정할 수 있습니다.

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

백그라운드 세션은 Agent View에 자동으로 추가됩니다. --bg로 실행하고 claude agents를 열면 목록에서 확인할 수 있습니다.

주요 기능: 노트북이 잠자기 상태가 되거나 창을 닫아도 세션이 유지됩니다.

하지만 노트북을 종료하거나 수동으로 재부팅하면 백그라운드 세션은 Failed 상태로 끝납니다. 밤새 여러 백그라운드 에이전트를 실행하려면 노트북을 켜 두어야 합니다.

Worktree: Claude가 병렬 세션을 격리하는 방법#

Worktree는 병렬 자율 작업의 가장 큰 문제를 해결합니다. 두 세션이 동시에 src/auth.ts를 수정하려 하면 어떻게 될까요? 2.1.139 이전에는 세션들이 서로의 변경 사항을 실제로 덮어쓸 수 있었습니다. Agent View와 함께 Anthropic은 자동 격리를 도입했습니다.

실제 작동 방식:

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

각 세션은 자체 사본에서 작업합니다. 작업이 끝나면 필요한 브랜치를 main에 병합합니다.

주의할 함정: 세션을 삭제하면 worktree도 삭제됩니다.

Agent View에서 세션을 종료하면(Ctrl+X를 두 번 누름) 해당 worktree가 사라집니다. 커밋하지 않은 변경 사항은 모두 손실됩니다. Agent View에서 세션을 삭제하기 전에 반드시 commit 또는 push를 하세요.

비활성화(드문 경우):

심볼릭 링크가 있거나 checkout이 느린 대규모 모노레포처럼 git worktree가 작동하지 않는 저장소에서는 격리를 비활성화할 수 있습니다.

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

그러면 백그라운드 세션이 작업 중인 사본을 직접 편집합니다. 이 비활성화 옵션은 대규모 모노레포를 사용하는 팀의 요청을 반영해 2.1.143에 추가되었습니다.

병렬 실행은 할당량을 소모합니다.

즉, Pro 요금제(월 20달러)는 밤새 병렬 세션 1~2개를 실행하기에는 충분하지만 10개에는 부족합니다. 병렬로 여러 에이전트를 실행하려면 Max 또는 Enterprise가 필요합니다.

긴 작업을 위해 /goal + Plan Mode + subagents 결합하기#

흔히 발생하는 실패는 곧바로 /goal build a new feature라고 입력하는 것입니다. 평가자는 “완성된 기능”이 어떤 모습인지 모르므로 작동하지 않습니다. 평가자가 하나씩 확인할 수 있는 체크박스가 있는 계획이 필요합니다.

계층 1. Plan Mode가 단계별 계획을 작성합니다.

Plan Mode에서 Claude에게 검증 가능한 체크박스가 있는 상세 변경 계획을 57단계로 나누어 작성해 달라고 요청합니다. plans/2026-05-24-google-oauth.md로 저장합니다. 각 단계에는 구체적인 작업이 37개 포함됩니다.

계층 2. Subagents가 단계별로 작업을 나눕니다.

계획을 병렬화할 수 있다면(예를 들어 백엔드 엔드포인트, 프런트엔드 양식, DB 마이그레이션 단계가 서로 독립적이라면) claude --bg --name "<phase>"를 통해 각 단계를 별도의 백그라운드 세션으로 시작할 수 있습니다. 각 세션에는 자체 worktree가 제공됩니다.

계층 3. /goal이 체크박스가 완료될 때까지 주기를 실행합니다.

/goal plans/2026-05-24-google-oauth.md의 1~7단계가 모두 완료되고 [x]로 표시되었으며, test/auth의 모든 테스트가 통과하고 (npm test에서 0 failures 표시), npm run build가 성공했거나, 50턴 후 중지

각 턴이 끝나면 평가자가 계획을 읽고 완료된 항목을 확인합니다. 남은 항목이 있으면 에이전트가 계속합니다.

이 조합은 세 가지 구성 요소를 바탕으로 합니다.

• 컨텍스트 엔지니어링: 평가자가 읽는 plans/의 적절한 컨텍스트
• 두 번째 두뇌: 세션이 바뀌어도 계획을 보관하는 plans/ 폴더
• AI 클론: 에이전트가 따르는 규칙을 설정하는 CLAUDE.md

CLAUDE.md가 없으면 /goal은 아키텍처를 망가뜨리는 해결책을 제안할 수 있습니다. plans/에 계획이 없으면 평가자는 성공 기준을 알 수 없습니다. Subagents가 없으면 병렬 단계가 없어 모든 작업이 순차적으로 진행됩니다.

/goal을 Codex, Cursor 및 다른 에이전트 모드와 비교하는 방법#

/goal은 각 턴 뒤 별도의 완료 검사를 추가합니다. 다른 제품에는 서로 다른 모드가 있으며 로컬 CLI, 호스팅 클라우드 작업, 감독하는 편집기 세션은 같은 비교 단위가 아닙니다. 모든 Codex CLI 작업을 클라우드 컨테이너로 설명하거나 모든 실행에 하나의 검증 모델과 결제 방식이 적용된다고 가정하지 마세요.

같은 저장소 상태와 작업에 같은 승인 검사를 적용하고 각 후보에서 다음을 기록하세요.

고정 배수의 토큰을 쓴다는 주장에는 같은 성공 결과의 조건과 측정 수치가 필요합니다. 벤치마크 비율도 버전, 모델, 실행 도구, 설정이 필요하며 그 조건이 없는 Terminal-Bench 비율만으로는 증거를 대신하지 못합니다. 이 글은 독립적인 도구 간 벤치마크를 제공하지 않습니다.

감독하는 수정, 범위가 정해진 백그라운드 작업, 명시적 완료 조건이 있는 여러 턴 작업 중 필요한 방식으로 선택하세요. 경쟁 제품 전체에 자율 실행이 없다고 가정하지 말고 설치된 제품이 지원하는 모드를 시험하세요. 도구 호출 자동 승인과 작업의 지속을 구분하세요. 호출을 자동 승인해도 사용자의 목표 달성이 입증되지는 않습니다.

/goal과 /loop 비교:

/loop는 같은 릴리스에 추가된 또 다른 명령으로, 일정한 시간 간격(매 N분)으로 작업을 실행합니다. /goal은 조건을 기반으로 작동하며 조건이 충족될 때까지 진행합니다. Cron과 비슷한 작업에는 /loop를, 특정 목표 달성에는 /goal을 사용하세요.

Anthropic 문서에서:

/goal 실행 전 체크리스트: 7가지#

/goal을 실행하기 전 체크리스트:

1. Claude Code 버전 2.1.139 이상: claude --version으로 확인하고 낮으면 업데이트하세요. 권장 최소 버전은 stop hook 반복 실행을 수정한 2.1.143(2026년 5월 15일)입니다.

2. 조건에 검증 가능한 최종 상태 포함: “개선해” 대신 npm test exits 0이라고 지정하세요. 결과를 확인하는 bash 명령을 정할 수 없다면 /goal은 이 작업에 적합하지 않습니다.

3. 엄격한 턴 제한 설정: 모든 조건에 or stop after N turns를 지정하세요. 쉬운 작업은 15회, 어려운 작업은 50회, 밤샘 실행은 최대 100회로 설정하세요.

4. 명시적이고 범위가 좁은 제약 설정: without modifying files outside /auth, without removing existing assertions, without bumping major versions 등입니다. 제약이 없으면 Claude가 테스트를 삭제해서 수정할 수 있습니다.

5. 중요한 변경 사항을 모두 commit 또는 push: worktree에서 작업하지 않는다면(예: worktree.bgIsolation: "none") Claude가 작업 중인 사본을 수정합니다. 실수하면 저장하지 않은 작업을 잃을 수 있습니다.

6. Settings → Usage에서 사용량 제한 활성화: 6,000달러 사고 이후 추가된 안전장치입니다. 일별, 세션별, 월별 한도를 설정하세요.

7. 별도 창에서 Agent View claude agents 열기: 장기 작업에서는 한 시간에 한 번 Space를 눌러 확인하세요. 턴 수가 예상보다 빠르게 증가하거나 평가자가 같은 이유를 세 턴 연속 반복하면 Ctrl+C를 누르고 조건을 다시 표현하세요.

추가 사항 하나: 다른 사람의 코드나 익숙하지 않은 코드에서 /goal과 --dangerously-skip-permissions를 함께 사용하지 마세요. 이 조합은 모든 검사를 비활성화하고 에이전트가 프로젝트에서 원하는 대로 작업하게 합니다. 이 분석의 작성자는 잃을 것이 없는 새 worktree에서만 이를 사용합니다.

/goal은 강력한 기능이지만 마법은 아닙니다. 조건을 얼마나 잘 작성하느냐에 따라 성능이 달라집니다. 명령으로 검증할 수 있는 말로 “완료”를 설명할 수 있다면 나머지는 /goal이 처리합니다. 설명할 수 없다면 일반 세션이나 Plan Mode로 돌아가세요.

Ailoot에서 더 많은 내용을 계속 살펴볼 수 있습니다.