Claude Code /goal 완벽 정리 — 약한 goal vs 강한 goal 6가지 차이

Claude Code /goal은 완료 조건이 충족될 때까지 클로드가 매 턴 알아서 작업을 이어가는 자율 실행 명령어입니다. Anthropic이 2026-05 공식 docs에 추가했고, OpenAI Codex도 같은 시기에 /goal 워크플로우를 정식 출시했습니다.

흥미로운 점은 이 기능이 "더 똑똑한 모델"의 산물이 아니라는 것입니다. 작년부터 커뮤니티에서 돌던 Ralph Wiggum 루프 — bash 무한 루프에서 같은 repo 컨텍스트를 매번 다시 로드시키는 패턴 — 을 두 회사가 거의 동시에 제품화한 결과입니다.

이 글은 nurijanian의 원본 글을 기반으로 합니다. 단순한 명령어 사용법이 아니라, /goal이 PM과 개발자의 일을 어떻게 바꾸는지, 그리고 약한 goal과 강한 goal의 6가지 차이를 한국 시장 맥락에서 정리합니다.

이 글을 읽으면 얻는 것

/goal이 단순한 자동화가 아니라 "doing vs judging 분리" 구조라는 점을 이해합니다.
약한 goal과 강한 goal의 차이를 6가지 항목으로 비교한 표를 확보합니다.
바로 복붙해서 쓸 수 있는 강한 goal 템플릿을 가져갈 수 있습니다.
/goal이 잘 작동하는 5가지 영역과 위험한 영역을 구분할 수 있습니다.
PM이 요구사항 작성을 어떻게 바꿔야 하는지 실전 변환 예시를 확인합니다.

준비물

Claude Code v2.1.80+ 또는 Codex CLI 0.128.0+
작업 대상 레포지토리(테스트가 돌아가는 상태가 이상적)
완료 조건을 검증할 수 있는 명령어(테스트, 린트, 타입체크 등)
변경 범위를 정의할 수 있는 디렉토리/파일 경로

/goal 명령어가 뭔가요?

/goal은 한 번의 프롬프트에 완료 조건을 걸어두면, 클로드가 그 조건이 충족될 때까지 매 턴 다음 작업을 알아서 이어가는 슬래시 명령어입니다.

핵심은 매 턴이 끝날 때마다 별도의 빠른 모델(평가자)이 "이 조건이 만족되었는가?"를 판정하는 구조라는 점입니다. 단순히 길게 일하는 것이 아니라, 검증 가능한 완료 상태를 향해 움직입니다.

# 기본 형태
/goal [완료 조건을 자연어로 명확히 기술]

기본 사용 예시는 다음과 같습니다.

/goal --tokens 250K test/auth 폴더의 모든 테스트가 통과하고 lint도 깨끗할 것

평가자는 도구를 직접 쓸 수 없고, Claude가 대화에 표시한 출력만 봅니다. 따라서 작업하는 에이전트가 테스트 결과·린트 출력·diff·상태 보고서를 명시적으로 대화에 표시해야 평가자가 판단할 수 있습니다. doing(작업)과 judging(완료 판단)이 완전히 분리된 구조입니다.

Ralph Wiggum 루프 — /goal의 원형

/goal 이전에 커뮤니티에서 먼저 돌던 패턴이 Ralph Wiggum 루프입니다. 심슨의 라프 위검에서 따온 이름으로, "끈질기게 같은 일을 반복하는" 캐릭터에서 영감을 받았습니다.

핵심 동작은 단순합니다.

bash 무한 루프(while true)에 에이전트를 넣습니다.
매 반복마다 같은 repo 컨텍스트(spec, plan, task list, test suite, status notes)를 다시 로드합니다.
에이전트는 spec과 plan을 읽고, 다음 미완료 작업을 선택하고, 구현하고, 테스트를 돌리고, 통과하면 task를 완료 처리한 뒤 다시 시작합니다.

여기서 핵심은 모델이 더 똑똑해진 것이 아니라 fresh context의 힘이라는 점입니다. 60,000 토큰까지 부풀어 오른 채팅 메모리 대신, 매 턴 외부 파일(spec.md, plan.md, status.md)을 다시 읽기 때문에 컨텍스트 로트(Context Rot)에서 자유롭습니다.

/goal은 이 패턴에 제품 디자인을 입힌 것입니다. 평가자를 분리하고, 토큰 한도와 턴 한도를 기본으로 두고, 평가 결과에 따라 자동 종료하는 구조까지 들어왔습니다.

약한 /goal vs 강한 /goal — 6가지 차이

여기가 이 글의 핵심입니다. 같은 /goal 명령어라도 작성 방식에 따라 결과가 극명하게 갈립니다.

약한 goal 예시:

/goal improve onboarding

에이전트는 무엇이든 할 수 있습니다. 버튼 이름을 바꾸고, 체크리스트를 추가하고, 카피를 다듬고, 화면을 단순화하고, 테스트를 만들고, 그럴듯한 PR을 올립니다. 하지만 온보딩이 실제로 개선되었는지 판정할 방법이 없습니다. 그래서 에이전트는 "증명하기 쉬운 것"을 최적화하기 시작합니다. 스크린샷이 깔끔해 보이게, 테스트가 통과하게, 단계가 줄어들게 — 제품이 진짜 좋아졌는지와 무관합니다.

강한 goal 예시:

/goal docs/onboarding-spec.md에 정의된 새 온보딩 체크리스트 구현.
spec의 모든 acceptance criteria 통과.
npm test -- onboarding 종료 코드 0.
npm run lint 종료 코드 0.
app/onboarding, components/onboarding, test/onboarding 외 파일 수정 금지.
20턴 후 어떤 criterion이 차단되면 status report와 함께 정지.

이 둘의 차이를 6가지 항목으로 정리하면 다음과 같습니다.

항목

약한 goal

강한 goal

목표 상태

"더 좋게 만들어줘"(주관적 형용사)

"X 동작이 가능하고 Y 테스트가 통과"(관찰 가능한 상태)

진실의 원천

채팅 메모리에 의존

외부 파일(spec.md, plan.md, status.md)을 매 턴 reload

수락 기준

없음

객관적으로 확인 가능한 항목 리스트(긍정/부정/회귀 케이스 포함)

검증 방법

"있어 보이게"

테스트 명령, 린트, 타입체크, 브라우저 스모크 등 명령어로 증명

범위 경계

모든 파일 건드릴 수 있음

수정 가능 경로/금지 시스템/보존할 계약 명시

종료 조건

모델이 알아서 끝낼 때까지

"20턴 후 차단되면 상태 보고 후 정지" 같은 명시적 stop 조건

약한 goal은 짧고 편하지만 루프가 40턴 동안 잘못된 것을 더 일관되게 만드는 위험이 있습니다. 강한 goal은 작성하는 데 5분이 더 들지만 unattended 실행 시 사고율이 급격히 낮아집니다.

Step 1: 목표 상태(target state)를 관찰 가능한 형태로 정의합니다

요구사항을 "make activation easier" 같은 형용사로 두지 않습니다. 대신 다음과 같은 관찰 가능한 행동으로 풀어 적습니다.

가입 직후 사용자는 3단계 셋업 체크리스트를 봅니다.
각 단계에는 "완료/미완료" 상태가 시각적으로 표시됩니다.
완료한 단계는 새로고침 후에도 유지됩니다.
사용자는 체크리스트를 건너뛰고 나중에 다시 돌아올 수 있습니다.
기존 사용자는 완료한 셋업 단계가 0개일 때만 체크리스트를 봅니다.

이렇게 적으면 에이전트가 "이건 만족했다, 이건 아직이다"를 매 턴 self-check할 수 있습니다.

Step 2: source of truth가 될 파일을 별도로 둡니다

채팅 안에 모든 맥락을 욱여넣는 대신, durable file을 분리합니다.

docs/onboarding-spec.md       # 목표 동작 명세
docs/onboarding-plan.md        # 구현 단계 순서
docs/onboarding-status.md      # 진행 상태 기록(에이전트가 매 턴 업데이트)
test/onboarding/*.spec.ts      # 검증 테스트

/goal이 매 턴 reload하는 대상은 spec과 plan과 status입니다. 채팅이 썩어도 source of truth는 외부에 남아 있습니다.

이 구조는 Thin Harness, Fat Skills 아키텍처와 정확히 같은 원리입니다. Garry Tan(YC CEO)이 정리한 "하네스는 얇게, 스킬은 두껍게" 슬로건의 실전 적용판이 /goal이라고 봐도 무방합니다.

Step 3: acceptance criteria와 validation evidence를 명시합니다

수락 기준은 객관적으로 확인 가능한 항목으로만 적습니다. 각 항목에 대해 어떻게 증명할지도 같이 적어둡니다.

## Acceptance criteria
- 첫 사용자에게 3단계 셋업이 가입 후 보임
- 각 단계에 완료/미완료 상태가 시각적으로 표시됨
- 완료 상태가 새로고침 후 유지됨
- 사용자는 체크리스트를 dismiss하고 다시 돌아올 수 있음
- 기존 사용자는 완료 단계가 0개일 때만 노출됨
- analytics가 onboarding_checklist_viewed, onboarding_step_completed,
  onboarding_checklist_dismissed 이벤트를 발행함

## Validation evidence required
- persisted step state에 대한 유닛 테스트
- 첫 사용자 노출 시나리오에 대한 통합 테스트
- 기존 사용자 회귀 테스트
- 완료/새로고침/dismiss 시나리오에 대한 브라우저 스모크
- empty state 링크에 대한 스크린샷 또는 DOM 증거
- 각 이벤트에 대한 캡처 테스트 또는 mocked analytics assertion

이렇게 적으면 평가자가 transcript에 표시된 증거만 보고도 "통과/실패"를 판정할 수 있습니다.

Step 4: 변경 경계(boundaries)와 stop 조건을 명시합니다

장시간 실행되는 루프에서 가장 위험한 것은 에이전트가 무관한 파일을 건드리는 것입니다. 명시적으로 경계를 그어둡니다.

- 수정 가능 경로: app/onboarding/, components/onboarding/, test/onboarding/
- 변경 금지: 결제, 인증, 알림 시스템 관련 모든 모듈
- 보존: 기존 사용자의 settings.notification 동작은 그대로 유지
- 정지 조건: 20턴 또는 30분 후 acceptance criteria 1개라도 미충족이면
  status.md에 차단 사유를 적고 정지

/goal이 잘못된 방향으로 가는 것을 막는 가장 강력한 방법이 경계와 stop 조건입니다. 토큰을 무한히 쓰지 않으려면 --tokens 250K 같은 한도도 같이 적어둡니다.

Step 5: 첫 루프를 반드시 지켜봅니다

/goal을 시작하고 노트북을 닫으면 안 됩니다. 첫 몇 턴은 캘리브레이션입니다.

spec을 잘못 해석하면 → 멈추고 spec을 고친 뒤 재시작합니다.
잘못된 동작을 검증하는 나쁜 테스트를 쓰면 → 멈추고 validation 프로토콜을 수정합니다.
무관한 파일을 건드리면 → 멈추고 경계를 더 명확히 합니다.
같은 질문을 반복하면 → spec에 모호한 부분이 있다는 신호입니다. 멈추고 명확화합니다.

이 단계가 귀찮아 보이지만, 첫 루프가 spec과 맞아떨어지면 그 다음 unattended 실행은 훨씬 안정적입니다. 첫 5턴을 지켜보는 것이 50턴짜리 잘못된 작업을 막는 가장 빠른 길입니다.

/goal이 잘 작동하는 5가지 영역

/goal은 만능이 아닙니다. 검증이 싸고 목표가 구체적인 영역에서 압도적으로 강합니다.

1. 코드 마이그레이션

/goal app/auth 내 legacyAuth 모든 import를 authClient로 마이그레이션.
app/auth에 legacyAuth import가 0건 남음.
npm test -- auth 종료 코드 0.
npm run typecheck 종료 코드 0.
모호한 사용처가 있으면 15턴 후 정지.

레거시 → 신규 API 전환, 호출 지점이 모두 컴파일되고 테스트가 통과한다는 완료 조건이 명확합니다.

2. 백로그 정리

/goal @auth-regression 라벨이 붙은 실패 테스트를 모두 해결.
각 수정은 가장 작은 production 변경을 동반.
테스트를 삭제하지 말 것.
수정마다 docs/status-auth-regressions.md에 원인·변경 파일·검증 출력 기록.

라벨 X가 붙은 미해결 이슈를 0건으로 만드는 반복 작업에 최적입니다.

3. 파일 분할/리팩토링

/goal app/components/AccountSettings.tsx를 250줄 미만 모듈로 분할.
동작은 그대로 유지. 기존 테스트 통과.
billing, profile, notification 관심사를 하나의 컴포넌트에 섞지 말 것.

행동은 그대로, 구조만 바꾸는 작업에서 정확히 들어맞습니다.

4. Brute-force 테스팅

공격 벡터, 결제 경로, 로그인 플로우, 검색 케이스, 폼, 권한, 엣지 케이스, unhappy path를 큐가 빌 때까지 시도하는 작업에 적합합니다. Ralph 루프의 끈질김이 그대로 장점이 됩니다.

5. 탐색 모드 (단, 결과를 production code가 아닌 문서로 한정)

/goal 프로젝트 검색 속도 개선을 위한 viable한 접근 3가지 탐색.
각 접근에 대해 예상 복잡도·리스크·건드릴 파일·검증 방법 노트 생성.
production code 수정 금지.
docs/search-speed-options.md 생성 후 정지.

탐색이 조용히 production 코드로 변질되지 않도록 경계를 미리 그어두는 것이 핵심입니다.

/goal이 위험한 영역

다음 상황에서는 /goal이 오히려 손해입니다.

모호한 PM 요구사항: 형용사로 적힌 ticket("매끄럽게", "더 똑똑하게")은 루프 안에서 더 큰 사고로 자랍니다.
검증이 비싼 작업: 시각 디자인, 카피, 톤 — 평가자가 보고 판정하기 어려운 영역입니다.
부수효과가 큰 시스템: 결제, 인증, 데이터 마이그레이션처럼 1턴 실수가 복구 불가능한 영역은 사람 승인 게이트가 필요합니다.
첫 캘리브레이션 없이 unattended 실행: spec이 모델과 만나기 전이라면 무인 실행은 시간 낭비입니다.

⚠️ 주의할 점

평가자(기본 Haiku)는 도구를 못 씁니다. 작업 에이전트가 대화에 명시적으로 증거를 출력해야 합니다.
상태 파일(status.md)에 매 턴 변경 파일·검증 결과·남은 리스크를 기록하지 않으면 다음 턴 reload가 무의미해집니다.
--tokens 한도와 turn 한도를 항상 명시합니다. 무한 루프는 비용으로 돌아옵니다.
spec이 6,000자를 넘으면 plan.md로 분리하고 spec에는 포인터만 둡니다. 컨텍스트 비대화는 평가자 정확도를 떨어뜨립니다.

강한 /goal 작성 템플릿

바로 복붙해서 쓸 수 있는 템플릿입니다.

/goal [목표 상태를 관찰 가능한 동작으로]

Source of truth:
  - read docs/[spec 파일]
  - follow docs/[implementation plan]
  - update docs/[status 파일]

Acceptance criteria:
  - [관찰 가능한 동작 1]
  - [관찰 가능한 동작 2]
  - [negative case]
  - [non-regression condition]

Validation:
  - [test command]
  - [lint/typecheck/build command]
  - [브라우저/시각/수동 증거 필요시]

Boundaries:
  - only edit [paths]
  - do not change [systems]
  - preserve [contract/data/API behavior]

Loop behavior:
  - 의미 있는 변경마다 관련 validation 실행
  - status 파일에 변경 파일·결과·남은 리스크 기록
  - [N턴/M분] 후 차단되면 차단 사유 보고 후 정지

이 템플릿이 PM이 새 ticket을 쓸 때마다 떠올려야 할 executable definition of done 그 자체입니다.

PM 요구사항이 prose에서 target state로 바뀝니다

원본 글에서 가장 강한 주장이 이 부분입니다. 에이전트 코딩은 product thinking을 없애는 것이 아니라, 모호한 product thinking을 더 빠르게 처벌합니다.

약한 PM 요구사항:

사용자가 알림을 더 쉽게 관리할 수 있어야 함.

강한, 에이전트 친화적 버전:

사용자는 제품 업데이트, 결제 알림, 리서치 알림을 독립적으로 켜고 끌 수 있습니다.
각 설정은 새로고침 후에도 유지됩니다.
기본값은 기존 사용자의 알림 동작과 일치합니다.
결제 알림을 끄려는 사용자는 법적/계정 보안 이유로 비활성화할 수 없는
이메일에 대한 경고를 봅니다.
설정 페이지는 기존 접근성 검사를 통과합니다.
작업은 알림 설정 테스트 통과, 새로고침 후 유지를 보여주는 브라우저 스모크,
문서화된 preference gate 외 결제 이메일 로직 미수정으로 완료됩니다.

이게 여전히 product work입니다. "알림 관리"의 의미를 정의하고, 결제 알림이라는 엣지 케이스를 명시하고, 기존 사용자에 대한 backward compat를 보존하고, 증명 방법을 명명하고, 에이전트가 무관한 이메일 로직으로 떠도는 것을 막습니다.

한국 시장 맥락에서 의미가 큽니다. "하네스 엔지니어링"이 패스트캠퍼스 강의가 될 정도로 한국 개발자들의 관심이 높지만, 정작 PM 요구사항 작성 쪽은 여전히 prose에 머물러 있습니다. /goal 시대의 경쟁력은 모델 선택이 아니라 요구사항을 얼마나 실행 가능한 형태로 적느냐에서 갈립니다.

자주 묻는 질문

Claude Code /goal은 무료인가요?

/goal 명령어 자체는 Claude Code의 슬래시 명령어로 추가 비용 없이 사용할 수 있습니다. 다만 자율 실행 특성상 토큰 사용량이 일반 대화보다 많기 때문에, 토큰 한도(--tokens 250K 등)를 명시하는 것이 안전합니다. Codex /goal도 ChatGPT 플랜에 따라 사용 가능하며, 별도 과금 없이 기존 토큰 한도 안에서 동작합니다.

Codex /goal과 Claude Code /goal의 차이는 무엇인가요?

두 명령어 모두 Ralph Wiggum 루프를 제품화한 것으로 구조는 거의 같습니다. Codex /goal은 ChatGPT 모바일 앱에서도 트리거 가능하다는 점, Claude Code /goal은 Skill·Hook 시스템과 자연스럽게 결합된다는 점이 차이입니다. 실무에서는 반복 작업은 Claude Code Skill로 만들고, 즉석에서 발명해야 하는 작업은 Codex /goal로 나누는 분업 패턴이 늘어나고 있습니다.

/goal로 어떤 작업을 시키면 안 되나요?

검증이 비싸거나 부수효과가 큰 작업은 피하는 게 좋습니다. 구체적으로 시각 디자인, 카피 톤 다듬기, 결제·인증 시스템 수정, 데이터 마이그레이션 등은 평가자가 정확히 판정하기 어렵거나 1턴 실수의 복구 비용이 너무 큽니다. 이런 작업은 사람 승인 게이트를 두거나, /goal 대신 일반 대화로 단계별 승인을 받으며 진행하는 것이 안전합니다.

Ralph Wiggum 루프를 직접 구현해도 되나요?

/goal 출시 전에는 bash while true 루프로 직접 구현하는 사례가 많았습니다. 다만 /goal은 평가자 분리·토큰 한도·자동 종료까지 내장되어 있어, 직접 구현보다 안전합니다. 기능을 확장하고 싶다면 Claude Code Hook과 결합해 /goal 종료 후 후속 작업(예: PR 생성, Slack 알림)을 이어가는 패턴을 추천합니다.

PM이 /goal 시대에 가장 먼저 배워야 할 스킬은 무엇인가요?

Acceptance criteria를 관찰 가능한 동작으로 적는 능력입니다. 형용사("매끄럽게", "쉽게")를 행동("3단계로 보임", "새로고침 후 유지됨")으로 풀어내는 훈련이 핵심입니다. 외부에서 참고할 만한 도구로는 Matt Pocock의 /grill-me 스킬과 Ryan Singer(전 Basecamp)의 /shaping 스킬이 있으며, PM OS v2는 이 패턴을 워크플로우로 패키징한 형태입니다.

참고 자료

원문: https://x.com/nurijanian/status/2055927283991654775