클로드 코드(Claude Code)에 자율 실행 명령어 /goal이 새로 들어왔습니다. 한 번의 프롬프트로 완료 조건을 걸어두면, 클로드가 그 조건이 충족될 때까지 매 턴 알아서 다음 작업을 이어갑니다. 매 턴이 끝날 때마다 별도의 빠른 모델이 “이 조건이 만족되었는가”를 평가하는 구조라, 단순히 길게 일하는 것이 아니라 검증 가능한 완료 상태를 향해 움직인다는 점이 핵심입니다. 이 글에서는 /goal이 정확히 무엇이고 언제·어떻게 써야 효과적인지, 그리고 어떤 작업에는 오히려 쓰지 않는 게 좋은지까지 정리해 드립니다.
목차
/goal 한 줄 정리
| 항목 | 내용 |
|---|---|
| 역할 | 완료 조건이 충족될 때까지 클로드가 자율적으로 여러 턴을 이어가는 자동 루프 |
| 입력 | /goal <자연어로 쓴 완료 조건> |
| 평가 주체 | 매 턴 종료 후 별도의 작은 모델이 “조건 충족 여부”를 판정 |
| 활성 표시 | 상태창에 ◎ /goal active와 누적 실행 시간이 표시됨 |
| 종료 | /goal clear(또는 stop·off·reset·none·cancel) / /clear로 새 대화 시작 |
왜 새로 생겼을까
지금까지 클로드 코드로 큰 작업을 시키려면 사용자가 매 단계마다 “계속해”, “다음 단계”, “에러 났으니 다시” 같은 지시를 직접 내려야 했습니다. 마이그레이션이나 백로그 정리처럼 같은 사이클을 수십 번 반복해야 하는 작업에서는 이 핸드오프 비용이 결과 품질을 깎아내리는 가장 큰 원인이었습니다.
/goal은 이 핸드오프를 명령어 한 줄로 줄이는 장치입니다. 사용자는 “어떤 상태가 되면 끝인지”만 정의하고, 다음부터는 클로드가 직접 다음 턴을 호출합니다. 그리고 실제로 끝났는지는 또 다른 모델이 판단하기 때문에, 일하는 모델이 “다 했어요”라고 자평하는 구조의 약점이 어느 정도 보완됩니다.
기본 사용법
1) 조건을 거는 법
슬래시 명령어 뒤에 자연어로 완료 조건을 적으면 됩니다. 조건은 가능하면 객관적으로 확인 가능한 형태로 적는 것이 좋습니다.
| 좋은 조건 예시 | 왜 좋은가 |
|---|---|
/goal test/auth 폴더의 모든 테스트가 통과하고 lint도 깨끗할 것 | 테스트 통과·lint 결과는 명령어로 검증 가능 |
/goal 결제 모듈을 새 API로 마이그레이션, 모든 호출 지점 컴파일 + 기존 테스트 통과 | “호출 지점이 남았는가”가 grep으로 확인됨 |
/goal 이번 주 머지된 PR이 모두 CHANGELOG.md에 한 줄씩 들어갈 것 | 전수 대조가 가능 |
이미 활성화된 목표가 있는 상태에서 새 /goal을 입력하면, 기존 목표를 대체하고 새 목표로 즉시 첫 턴이 실행됩니다.
2) 진행 상태 확인
목표가 활성화되면 상태창에 ◎ /goal active 인디케이터가 뜨고, 그 옆에 해당 목표가 몇 분째 돌고 있는지가 누적 표시됩니다. 매 턴이 끝나면 평가 모델이 “왜 아직 안 끝났는지” 또는 “왜 끝났다고 판정했는지”에 대한 짧은 사유를 트랜스크립트에 남기기 때문에, 중간 점검만으로도 진행 상태를 따라가기 쉽습니다.
3) 중간에 멈추는 법
도중에 멈추고 싶을 때는 /goal clear를 입력하면 됩니다. 다음 별칭도 모두 같은 동작을 합니다.
/goal stop/goal off/goal reset/goal none/goal cancel
/clear로 대화 자체를 새로 시작하는 경우에도 활성 목표는 함께 해제됩니다.
감사 모드(audit mode) 세 가지
“끝났다”는 판정을 누가 내릴지를 사용자가 직접 고를 수 있습니다. 설정 명령은 /goal config set audit.mode <값> 형태입니다.
| 모드 | 판정 주체 | 장점 | 단점 |
|---|---|---|---|
adversarial(기본) | 일하는 세션과 분리된 별도 클로드 세션 | 자평의 약점이 가장 적어 신뢰성이 높음 | 추가 호출이 들어가 비용이 더 들 수 있음 |
self | 일하는 모델 본인 | 판정 호출이 추가되지 않아 빠르고 저렴 | “다 했다”고 잘못 단정할 위험이 있음 |
off | 판정 없음 | 가장 단순, 무한 루프 직전까지 직진 | 완료 조건 자체가 무력화되므로 권장 X |
중요한 마이그레이션·리팩토링은 기본값인 adversarial로 두고, 빠르게 한 사이클만 돌려보고 싶은 탐색·프로토타이핑은 self로 잠깐 바꿔보는 정도가 무난합니다.
토큰 예산 옵션
자율 루프인 만큼 토큰이 무한정 빠지는 게 가장 큰 걱정거리입니다. 이를 위해 --tokens 옵션으로 소프트 토큰 예산을 걸 수 있습니다.
/goal --tokens 250K test/auth 폴더의 모든 테스트가 통과하고 lint도 깨끗할 것이렇게 설정하면 클로드는 약 250K 토큰 안에서 작업을 마무리하려고 시도합니다. 예산을 초과하기 전에 멈추거나, 남은 예산에 맞춰 작업 순서를 조정하는 식으로 행동이 바뀝니다. 큰 작업을 처음 맡겨볼 때는 예산을 명시적으로 걸어두는 편이 안전합니다.
이런 작업에 잘 맞습니다
- 코드 마이그레이션 — 기존 API에서 새 API로 옮겨가는 작업. “호출 지점이 모두 컴파일되고 테스트가 통과한다”가 명확한 완료 조건이 됩니다.
- 리팩토링 — 한 모듈을 통째로 재구성한 뒤 기존 테스트가 모두 그린이어야 하는 경우.
- 디자인 문서 기반 기능 구현 — 수락 기준(acceptance criteria)이 항목으로 적혀 있다면 그 항목들을 그대로 조건으로 옮겨 적을 수 있습니다.
- 이슈 백로그 정리 — “라벨 X가 붙은 미해결 이슈가 0건이 될 때까지” 같은 단순 반복 작업에 강합니다.
- 긴 연구·프로토타이핑 세션 — 한 가설을 검증할 때까지 계속 돌려두고, 결과만 받아보고 싶을 때.
이런 작업에는 권장하지 않습니다
| 작업 유형 | 이유 |
|---|---|
| 완료 기준이 주관적인 작업 | “코드를 더 예쁘게” 같은 조건은 평가 모델이 판정할 수 없음 |
| 되돌리기 어려운 사이드이펙트가 큰 작업 | 외부 시스템에 영향이 가는 명령은 자율 루프와 궁합이 나쁨 |
| 매 단계마다 사용자 판단이 필요한 작업 | 핸드오프 횟수를 줄이는 명령인데 핸드오프가 본질인 작업에 쓰면 충돌 |
| 탐색이 핵심인 초기 설계 단계 | “무엇을 만들 것인가”가 정해지지 않은 단계에는 자율 루프가 길을 잃기 쉬움 |
시작 전 체크리스트
- 완료 조건이 객관적으로 검증 가능한 형태로 적혔는가? (테스트 통과·grep 0건·파일 존재 등)
- 중요한 작업이라면
audit.mode가adversarial로 되어 있는가? - 처음 돌리는 작업이라면
--tokens로 소프트 예산을 걸어 두었는가? - 되돌리기 어려운 변경(브랜치 강제 푸시, 외부 호출 등)이 포함되지는 않는가?
- 중간 점검을 위해 트랜스크립트의 평가자 사유를 확인할 시점이 정해져 있는가?
자주 묻는 질문
Q. 일반 슬래시 명령과 뭐가 다른가요?
일반 슬래시 명령은 그 턴 한 번만 영향을 주지만, /goal은 다음 턴들까지 영향을 미치는 상태를 만듭니다. 활성 인디케이터가 뜨는 동안에는 사용자가 추가 입력을 하지 않아도 클로드가 스스로 다음 턴을 호출합니다.
Q. 무한 루프에 빠질 위험은 없나요?
토큰 소프트 예산(--tokens)을 걸어두면 그 한도 안에서 작업을 마무리하려고 합니다. 또한 평가 모델이 “이 조건은 현 코드 상태에서 만족 불가능”이라고 판정하면 그 사유를 남기고 멈추므로, 진행이 막혔을 때 트랜스크립트만 확인해도 원인 분석이 빠릅니다.
Q. self 모드는 언제 쓰면 좋나요?
실패해도 부담이 적은 가벼운 작업, 또는 한두 사이클 안에 끝날 것이 거의 확실한 작업에 적합합니다. 마이그레이션·리팩토링 같이 한 번 잘못 “끝”으로 판정되면 손해가 큰 작업은 기본값인 adversarial을 유지하는 편이 안전합니다.
Q. 끝났는데 결과가 미흡하면 어떻게 다시 시키나요?
새로운 /goal <더 구체적인 조건>을 입력하면 됩니다. 이전 목표는 자동으로 교체됩니다. 같은 작업을 더 엄격하게 다시 돌리고 싶다면, 조건 문장을 더 측정 가능한 형태로 다듬는 것이 가장 효과적입니다.
마무리
/goal은 “프롬프트 한 번에 큰 작업을 맡기고 결과만 받아본다”는 사용 패턴을 클로드 코드에서 정식으로 지원하게 해주는 명령어입니다. 좋은 자율 루프의 출발점은 결국 완료 조건을 얼마나 정확하게 적느냐이므로, 처음에는 작은 작업으로 조건 작성 감을 잡은 뒤 점점 큰 작업으로 확장해 보시기를 권해 드립니다. 마이그레이션·테스트 그린·백로그 0건처럼 명확히 닫히는 작업부터 한 번 걸어보면, 핸드오프에 들이던 시간을 어떻게 줄일 수 있는지 바로 체감하실 수 있습니다.