다중 턴 작업의 정상 비용
여러 턴이 필요한 작업에는 매 턴 사이마다 “계속해줘”를 누르거나 다음 지시를 다시 주는 시간이 끼어 있습니다. 검증 가능한 종료 상태가 있는 작업이라면 이 사이 시간은 사실상 낭비입니다. 코드를 마이그레이션해서 모든 호출 지점이 컴파일되고 테스트가 통과하기, 큰 파일을 사이즈 예산 안으로 쪼개기, 라벨이 붙은 이슈 백로그를 비우기 — 이런 작업은 사람이 사이에 끼지 않아도 됩니다.
/goal은 이 사이 시간을 없앱니다. 한 줄로 완료 조건을 입력하면 매 턴 후 평가기가 충족 여부를 판단하고, 충족 전까지 Claude가 자동으로 다음 턴을 시작합니다. 조건이 만족되면 goal은 자동 해제됩니다.
대신 사람이 매 턴 끼지 않는 만큼, 조건이 잘못 적혀 있을 때 비용이 사용자 모르게 누적되는 것이 핵심 위험입니다. 이 가이드는 명령 사용법보다 조건 작성에서 자주 빠지는 함정과 회피법을 정리합니다.
3가지 자동 진행 메커니즘 — 무엇을 언제 쓰나
다음 턴이 언제 시작되는가가 결정 기준입니다.
| 접근 | 다음 턴이 시작되는 시점 | 멈추는 조건 | 적용 범위 |
|---|---|---|---|
/goal | 이전 턴이 끝나는 즉시 | 평가 모델이 조건 충족을 판단 | 현재 세션 한정 |
/loop | 일정 시간 간격마다 | 사용자 중단 또는 Claude가 작업 종료 판단 | 현재 세션 한정 |
| Stop hook | 이전 턴이 끝나는 즉시 | 사용자가 짠 스크립트·프롬프트가 결정 | settings 적용 범위 전체 |
/goal은 한 줄짜리 입력만으로 현재 세션에 들어가는 단축 경로입니다. 평가 로직을 더 정교하게 짜고 싶으면 Stop hook을 직접 정의하고, 단순히 시간 기반으로 같은 프롬프트를 반복하고 싶으면 /loop 쪽이 맞습니다. Auto mode는 턴 안의 툴 호출만 자동 승인하고 새 턴을 시작하지는 않으므로, /goal과 조합하면 턴 내·턴 사이 프롬프트가 모두 사라집니다 (= 완전 무인 운영).
사용법
/goal test/auth 폴더의 모든 테스트가 통과하고 lint가 깨끗할 때까지입력과 동시에 첫 턴이 시작됩니다 — 별도 프롬프트를 보낼 필요가 없습니다. 활성화된 동안 ◎ /goal active 인디케이터가 경과 시간을 함께 보여주고, 매 턴 후 평가기의 짧은 사유가 상태·트랜스크립트에 남습니다.
상세 명령 표:
| 명령 | 동작 |
|---|---|
/goal (인자 없이) | 현재 또는 가장 최근에 달성된 goal의 조건·경과 시간·턴 수·토큰 사용량·평가기 사유 표시 |
/goal clear | 조건 충족 전 조기 해제 (stop·off·reset·none·cancel 도 동일) |
/clear | 새 대화 시작 — 활성 goal도 함께 제거 |
세션이 끝났을 때 활성 상태였던 goal은 --resume·--continue로 같은 세션을 다시 열면 조건이 복원됩니다(단 카운터는 0부터 재시작).
조건 작성에서 자주 빠지는 함정 4가지
/goal이 잘못 돌아가는 사례는 거의 모두 조건이 잘못 적혀 있어서 발생합니다.
함정 1 — 평가기는 대화에 드러난 것만 본다
평가기는 별도로 명령을 실행하거나 파일을 읽지 않습니다. Claude가 트랜스크립트에 내놓은 텍스트만 보고 판단합니다.
❌
/goal 모든 단위 테스트가 통과할 때까지
이 조건은 위험합니다. Claude가 테스트를 실제로 돌리지 않고 “테스트를 점검한 결과 모두 통과합니다”라고 자체 보고만 해도 평가기가 그 문장을 보고 “조건 충족”이라 판단할 수 있습니다.
✅
/goal npm test가 exit 0으로 종료되고 그 출력이 트랜스크립트에 보일 때까지
증거의 형태를 조건에 박아두면 우회가 어려워집니다. “어떤 명령을 돌렸고 그 결과 화면이 보인다”까지 조건에 포함해야 평가기가 그 증거를 보고 판단합니다.
함정 2 — 조건이 추상적
❌
/goal 코드 품질이 개선될 때까지
“품질 개선”은 측정 가능한 종료 상태가 아닙니다. 평가기는 매 턴 “아직 미흡함”이라 판단하기 쉽고, Claude는 끝없이 리팩터를 시도하게 됩니다.
✅
/goal src/utils/format.ts 파일이 200줄 이하가 되고 외부에서 import하는 export가 모두 보존되어 있을 때까지
종료 조건은 하나의 측정 가능한 상태 + 유지되어야 하는 제약으로 적습니다.
함정 3 — 종료 안전장치가 없다
평가기가 yes를 못 내면 goal은 계속 돕니다. 이때 사용자가 잠시 자리를 비우면 토큰만 누적될 수 있습니다.
조건 자체에 turn·time 절을 박아 안전장치를 둡니다.
/goal test/auth의 모든 테스트가 통과하고 lint가 깨끗할 때까지,
또는 20턴이 지나면 진행 상황을 요약하고 멈출 것Claude는 매 턴 그 절에 대한 진행도를 보고하고, 평가기는 대화에서 그 절의 충족 여부를 판단합니다.
함정 4 — “변경되면 안 되는 것”이 빠져 있다
❌
/goal users 테이블에 created_at 컬럼이 추가되고 마이그레이션이 통과할 때까지
조건이 통과하더라도 그 사이에 다른 마이그레이션 파일이 임의로 수정될 수 있습니다.
✅
/goal users 테이블에 created_at 컬럼이 추가되고 새 마이그레이션 한 개로만 적용되며, 기존 마이그레이션 파일은 수정되지 않은 상태에서 npm run migrate가 통과할 때까지
영향 범위가 큰 작업일수록 “건드리지 말 것”을 조건에 같이 박아둡니다.
헤드리스 운영
-p 플래그와 결합하면 한 호출에서 조건 충족까지 자동으로 돕니다. 백그라운드 잡이나 cron에서 쓰기 좋습니다.
claude -p "/goal CHANGELOG.md에 이번 주 머지된 모든 PR 항목이 있을 때까지" \
--permission-mode auto--permission-mode auto(또는 세션 안에서 auto mode)를 같이 두면 매 툴 승인 프롬프트도 사라져 완전 무인 운영이 됩니다. 중단은 Ctrl+C로 즉시 가능. 대시보드를 보면서 띄우려면 claude agents 디스패치 쪽으로도 같은 조합을 그대로 가져갈 수 있습니다.
/goal이 어울리지 않는 작업
- 탐색·디자인 결정 — 종료 상태가 합의로만 정해지는 작업은
/goal에 맞지 않습니다. Plan mode + 사용자 검토가 낫습니다. - 사용자 확인이 끼어야 하는 다단계 작업 — 매 턴 자동 진행이 오히려 위험합니다.
- 검증 출력이 없는 작업 — UI 변경처럼 평가기가 결과를 텍스트로 확인할 수 없는 작업은 안전장치(turn 제한)를 강하게 두지 않으면 무한 진행 위험이 큽니다.
평가가 실제로 어떻게 도는가
/goal은 내부적으로 session-scoped prompt-based Stop hook의 래퍼입니다. Claude가 턴을 마칠 때마다 조건과 지금까지의 대화가 small fast model (기본 Haiku)에 전달되어 예·아니오 결정과 짧은 사유를 반환받습니다.
- 아니오 — Claude에게 “계속 진행”이 전달되고 사유가 다음 턴의 가이드로 들어갑니다.
- 예 — goal이 해제되고 트랜스크립트에 달성 기록이 남습니다.
평가기는 사용 중인 프로바이더의 small fast 모델 위에서 동작합니다. 평가 토큰 비용은 메인 턴에 비해 보통 무시할 만한 수준입니다.
사용 요건
- Claude Code v2.1.139 이상
- 작업 디렉터리에서 workspace trust 다이얼로그 수락
- settings의
disableAllHooks가 어느 레벨에라도 설정돼 있으면 비활성 - managed settings의
allowManagedHooksOnly가 설정된 환경에서도 비활성 - 비활성 환경에서는 사유 메시지가 명시적으로 표시됩니다 (조용히 무시되지 않음)
참고
- 공식 문서: Keep Claude working toward a goal
- 평가 로직을 직접 짜고 싶을 때: prompt-based hooks
- 시간 기반 반복이 더 맞는 경우:
/loop