
Claude Code의 /goal 명령어로 AI를 자율 주행시키기 — 완료 조건을 한 줄 쓰고 방치하는 새로운 개발 스타일
요약
Claude Code v2.1.139에 추가된 /goal 명령어를 통해 AI를 자율적으로 동작시키는 방법을 소개합니다. 완료 조건을 설정하면 경량 모델이 달성 여부를 스스로 판정하여 작업이 완료될 때까지 루프를 지속합니다.
핵심 포인트
- /goal 명령어로 반복적인 '계속해' 입력 없이 자율 작업 가능
- Haiku 모델이 대화 내용을 바탕으로 완료 조건을 판정하는 메커니즘
- 기계적으로 판정 가능한 명확한 완료 조건 작성법의 중요성
- 자율 주행에 따른 토큰 소비 비용 증가 주의 필요
이 기사의 요점 (2026-05-25 작성 시점): Claude Code v2.1.139 (2026년 5월 출시)에서 추가된 /goal 명령은 완료 조건을 한 줄 쓰는 것만으로 AI가 조건 달성까지 자율적으로 지속하는 메커니즘이다. 본 기사에서는 '완료 조건 작성법'이라는 실전 스킬에 초점을 맞추어, 좋은 조건과 나쁜 조건의 대비, 그리고 매니지먼트형 사용자가 '지시를 내리는 사람'에서 '업무를 설계하는 사람'으로 전환하는 관점을 정리한다. 또한, /goal 명령은 안정 기능으로 제공되지만, 후술할 Agent View (claude agents)는 연구 프리뷰 (Research Preview) 단계이므로 불안정함이 남아 있다.
"계속해"라고 몇 번이나 타이핑했는지 기억나지 않는다.
테스트가 통과할 때까지 디버깅해 주길 바랄 때, Claude Code에 지시를 내려도 1턴 분량만 움직인다. "계속해". 또 멈춘다. "계속해". 또 에러. 이 반복에서 과거의 배치 잡 (Batch Job) 모니터링과 같은 피로감을 느낀 사람은 적지 않을 것이다.
Claude Code v2.1.139 (2026년 5월 출시, 출처: Claude Code 공식 문서)에서 등장한 /goal 명령은 이 "계속해"의 연타로부터 해방시켜 준다. 완료 조건을 한 줄 쓰면, 나머지는 Claude가 자율 주행한다.
/goal이란 무엇인가 — 메커니즘을 30초 만에 이해하기
/goal의 메커니즘은 심플하다.
/goal [완료 조건]
이 명령을 입력하면, Claude는 해당 조건을 '판정 기준'으로 가지면서 작업을 계속한다. 각 턴의 끝에, 별도의 소형 모델 (기본값은 Haiku)이 '조건을 충족했는가'를 판정한다. '아직'이라고 판정되면 다음 턴으로 자동 진행된다. '달성'이라고 판정되는 순간 멈춘다.
도식화하면 다음과 같다.
사용자가 /goal [조건] 을 입력
↓
Claude가 작업을 실행 (1턴)
...
사용자가 아무것도 하지 않아도 이 루프가 계속 돌아간다.
비용 감각: 판정을 담당하는 Haiku는 경량 모델이므로, 판정 비용 자체는 주요 턴에 비해 무시할 수 있는 수준이다 (출처: 공식 문서). 다만 자율 지속에 의해 턴 수가 늘어나면, 주요 턴의 소비는 당연히 늘어난다. "방치하면 끝난다"의 이면에는 "방치한 만큼 소비한다"가 있다는 점을 잊지 말아야 한다.
완료 조건 작성법이 '업무 설계 스킬'이 된다
/goal을 능숙하게 다루는 핵심은 완료 조건을 어떻게 쓰는가에 있다.
이것은 단순한 프롬프트 테크닉이 아니다. "Claude에게 무엇을 어디까지 시킬 것인가"를 언어화하는 행위 그 자체다. SE로서 팀 멤버에게 업무를 할당할 때, "완료 정의가 모호한 지시는 목표에 도달하지 못한다"는 것을 몇 번이고 경험해 왔다. /goal은 그 감각을 그대로 AI와의 업무 설계에 가져온 것이다.
좋은 조건: 기계적으로 판정할 수 있는 것
Haiku는 "대화에 나타난 텍스트"를 통해 판정을 수행한다. 파일을 독립적으로 읽으러 가거나 명령어를 독자적으로 실행하지는 않는다. 따라서 Claude 스스로가 작업 결과를 아웃풋으로서 대화에 내놓을 수 있는 형태로 조건을 써야 한다.
좋은 예:
/goal npm test의 종료 코드가 0이 될 것
/goal git status가 클린하고, lint 에러 건수가 0일 것
/goal README에 "설치 방법", "사용법", "라이선스" 3개 섹션이 작성되고, 코드 블록이 1개 이상 포함될 것
이것들은 Claude가 테스트를 실행하고 결과를 대화에 내놓으면 → Haiku가 그것을 읽고 "0이다, 달성"이라고 판정할 수 있는 플로우가 성립한다.
조건의 요소를 정리하면 다음과 같다 (출처: Claude Code 공식 문서를 바탕으로 필자 정리):
| 요소 | 설명 | 예 |
|---|---|---|
| 측정 가능한 종단 상태 | 수치·건수·존재 여부로 확인 가능 | 테스트 합격 건수, 에러 건수 제로 |
| 확인 수단 | Claude가 어떻게 증명해야 하는가 | npm test가 0으로 종료됨 |
| 제약 | 변경해서는 안 되는 것을 명시 | 다른 테스트 파일은 변경하지 않음 |
| 중단 문구 (임의) | 무한 루프 방지 | 또는 20턴에서 정지 |
나쁜 조건: 주관적·모호함·판정 불가능한 것
나쁜 예:
/goal 테스트를 깔끔하게 해주세요
/goal 코드가 좋은 상태가 되는 것
/goal 파일이 완성되는 것
「깔끔하게」, 「좋은 상태」, 「완성」은 Haiku가 판정할 수 없다. 어느 타이밍에 달성되었다고 선언해야 할지 모르는 상태에서, Claude가 멈추지 못하고 루프 (Loop)를 계속 돌거나, 도중에 잘못 판정하여 조기 종료되는 경우 중 하나가 된다.
모호한 조건의 리스크는 예산 초과다. 멈추지 못하는 Claude는 턴 (Turn)을 계속 거듭하며, 정신을 차려보면 예상치 못한 토큰 (Token)을 소비하고 있다. 중단 문구(or stop after 20 turns)를 붙여두는 것은 비용 관리 측면에서도 합리적이다.
「지시를 내리는 사람」에서 「업무를 설계하는 사람」으로
여기서부터는 SE (System Engineer) 관점의 이야기다. 기술적인 절차보다는 매니지먼트 (Management)에 가까운 이야기이므로, 「구현 예시만 있으면 된다」는 분은 다음 장으로 넘어가도 무방하다.
기술적인 이야기를 잠시 떠나, SE로서의 실감을 적어보고 싶다.
SE 경력 26년의 커리어 동안, 매니지먼트에 무게 중심을 옮긴 후 강하게 의식하게 된 것이 있다. 우수한 담당자일수록, 모호한 지시에는 움직이지 않는다는 점이다. 「알아서 잘 해줘」가 통하는 것은 담당자와 사이에 긴 맥락 (Context)이 쌓여 있을 때뿐이다.
Claude Code의 /goal도 마찬가지다. 「알아서」는 통하지 않는다. 무엇을 완료로 볼 것인지를 자신의 언어로 정의할 필요가 있다.
이는 제약이 아니라, 스킬 업 (Skill-up)의 기회라고 생각한다.
「테스트가 통과할 때까지 수정해줘」라고 구두로 전달할 때, SE적인 머릿속에는 「어떤 테스트 스위트 (Test Suite)를 어떤 상태로 만들 것인가」라는 이미지가 있을 것이다. /goal은 그 이미지를 언어화하는 훈련이 된다. 직접 써보면서 「이 조건, 나조차도 모호하네」라고 깨닫는 경험이 업무 설계의 해상도를 높인다.
Agent View와의 조합으로 「복수 태스크의 병렬 관리」로
동일한 v2.1.139에서 추가된 claude agents (연구 프리뷰 (Research Preview))를 사용하면, 여러 세션을 목록으로 모니터링하는 Agent View를 사용할 수 있게 된다 (출처: 공식 문서).
/goal과 Agent View의 조합으로 현실적이 되는 시나리오가 있다.
시나리오 예: 아침에 설정하고 저녁에 확인
- 아침 세션 A에서 「모든 테스트가 그린 (Green) 상태가 될 것」을
/goal로 설정 - 다른 세션 B에서 「문서의 오타 체크와 README 업데이트」를
/goal로 설정 - Agent View로 두 세션의 상태를 보면서 다른 업무를 수행
- 저녁에 두 세션이 모두 완료되었는지 확인
이것은 「명령을 내리는 사람」이 아니라, 「여러 업무가 병행하여 진행되는 상태를 관리하는 사람」의 일하는 방식이다. 프로젝트 매니저 (Project Manager)가 여러 담당자의 태스크를 병행시키는 구조와 유사하다.
단, 현 시점(2026-05-25)의 주의사항으로서, claude agents (Agent View)는 연구 프리뷰 (Research Preview) 단계에 있다 (출처: 공식 문서). /goal 명령어 자체는 안정적인 기능이지만, 이를 묶어서 보는 Agent View가 불안정하기 때문에, 「완전히 방치하고 아침에 확인하면 끝나 있다」는 단계에는 아직 이르지 않았다. 「멈춰 있다면 수동으로 재시작한다」는 하프 오토 (Half-auto) 운용이 현실적이라고 생각한다 (필자의 현 시점 판단).
에이전트 (Agent)가 병렬로 자율적으로 움직이는 설계를 한 단계 더 발전시킨 사례로서, 자기 개선형 멀티 에이전트 (Multi-agent) 조직을 만드는 방법도 참고가 된다.
요구사항: /goal이 작동하지 않는 환경에 주의
/goal에는 전제 조건이 있다.
- Claude Code v2.1.139 이후 버전이 필요함 (출처: 공식 문서)
- 훅 (Hook) 시스템이 활성화된 환경에서만 동작함:
disableAllHooks가 설정되어 있거나,allowManagedHooksOnly가 관리 설정으로 지정되어 있는 경우/goal은 사용할 수 없다 (출처: 공식 문서) /goal은/loop와는 별개임:/loop는 시간 간격으로 반복하는 정기 실행형이며,/goal은 조건 달성 시 종료되는 완료 구동형이다 (출처: 공식 문서)
작동하지 않을 때는 먼저 버전과 설정 플래그 (Flag)를 확인하는 것이 좋다.
Claude Code를 더욱 깊이 배우기 위한 서적
/goal과 같은 에이전트적인 활용까지 파고든 Claude Code 사용법을 체계적으로 배우고 싶다면, 서적도 선택지가 될 수 있다.
- Claude Code를 이용한 AI 주도 개발 입문 (히라카와 토모히데 저) — 기초부터 실전까지 망라
- 실전 Claude Code 입문 —— 현장에서 활용하기 위한 AI 코딩 사고법 (니시미 키미히로, 요시다 신고, 오시마 유키 저) — 현장에서의 사고법에 초점
요약: 완료 조건을 쓰는 연습부터 시작하기
/goal의 사용법은 어렵지 않다. /goal을 입력하고, 완료 상태를 한 문장으로 작성하기만 하면 된다.
어려운 점은, 그 한 문장을 "기계적으로 판정할 수 있는 형태"로 작성하는 것이다.
처음에는 실패해도 괜찮다. "조건이 모호해서 멈추지 못했다", "생각보다 빨리 오판정되었다"와 같은 경험이 업무 설계의 해상도를 높여준다.
오늘의 한 걸음:
- 지금 바로 곁에서 "계속해"를 반복하고 있는 태스크를 하나 떠올려 본다
- 그 "완료 상태"를 한 문장으로 써 본다
- 다 썼다면
/goal에 전달해 본다
완료 조건을 쓸 수 있는 사람이 AI를 자율 주행(Self-driving)시킬 수 있는 사람이 된다고 생각한다.
참고 링크
- Claude Code
/goal공식 문서 (영어): https://code.claude.com/docs/en/goal - DevelopersIO: Claude Code
/goal명령어 해설: https://dev.classmethod.jp/articles/claude-code-goal-command/ - Claude Code 주간 업데이트 요약 (2026/05/23 주) —
/goal명령어를 포함한 최신 업데이트 해설 - Claude Code의
/goal로 기사를 써보게 했다 —— AI가 자율 주행한 1세션의 실록 —/goal을 실제 기사 작성에 사용한 체험기
이 기사는 はてなブログ (Hatena Blog) 에서의 크로스 포스트입니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기