objective-loop

name	objective-loop
description	verify 점수를 올리거나 수치 목표 달성이 필요할 때 반드시 이 스킬을 사용할 것. 'REJECTED를 APPROVED로', 'improve score', 'raise score', 'fix REJECTED', 'optimize to pass', 'SCORE 80 이상', 'meet the threshold', 'get to APPROVED'가 포함된 요청 모두 해당. 코드와 하네스(rubric)를 동시에 진화시키며 Goodhart's Law 방어 내장.

objective-loop 스킬

"가능한 모든 문제를 탐색 문제로 치환하라. 목표와 평가 함수를 정의하면, 반복이 수치를 올린다."

execution-loop과의 차이

	execution-loop	objective-loop
목표	합격 기준 충족	수치 목표 달성
진화 대상	코드	코드 + 하네스(rubric)
종료 조건	APPROVED 판정	목표 수치 달성
Goodhart's Law	방어 없음	루브릭 건강 검사 내장
철학	규칙 준수	탐색 → 최적화

교수평기 구조와 동형:

교수평기:  가르침(Teach)  →  평가(Assess)  →  피드백(Feedback)
objective: 실행(Execute)  →  검증(Verify)  →  하네스 업데이트
           ↑                  ↑                  ↑
           execution-loop     verify 스킬         이 스킬이 추가하는 것

평가 함수(rubric)가 잘 정의되면 → 사람의 개입 없이 반복이 목표를 향해 수렴. 단, rubric 진화는 반드시 사람이 승인한다.

---

사용 방법

/objective-loop [목표 설명]

예:
/objective-loop verify 점수를 REJECTED → APPROVED로 올려줘.
/objective-loop Pedagogy Reviewer 🔴 0개, 🟡 2개 이하 달성해줘.
/objective-loop 접근성 차원 HIGH 3/5 → 5/5로 올려줘.
/objective-loop LCP를 3.2초 → 2.5초 이하로 낮춰줘.

---

실행 구조

┌──────────────────────────────────────────────────────────┐
│                    objective-loop                         │
└──────────────────────┬───────────────────────────────────┘
                       │
              ┌────────▼────────┐
              │  0. 목표 수치화  │  "좋게"❌ → "HIGH 5/5"✅
              └────────┬────────┘
                       │
              ┌────────▼────────┐
              │  1. 탐색 공간   │  무엇을 바꿀 수 있는가 명시
              └────────┬────────┘
                       │
              ┌────────▼────────┐
              │  2. 기준점 측정  │  현재 점수 기록 → baseline
              └────────┬────────┘
                       │
         ┌─────────────▼──────────────────┐
         │        반복 루프 (최대 5회)      │
         │                                 │
         │  execution-loop 1사이클 실행     │
         │           ↓                     │
         │  verify 스킬 → 점수 측정         │
         │           ↓                     │
         │  delta 계산 + 기록               │
         │           ↓                     │
         │  [3회 연속 delta=0]              │
         │     → 탐색 공간 확장 시도        │
         │           ↓                     │
         │  [5회마다] 루브릭 건강 검사 ◀── Goodhart's Law 방어
         └──┬──────────────────────┬───────┘
            │ 목표 미달성           │ 달성
            ▼                      ▼
     5회 초과 → 보고 후        하네스 업데이트
     사용자 방향 결정          + 완료 보고서

---

단계 0 — 목표 수치화 (필수)

루프를 시작하기 전에 반드시 측정 가능한 수치로 변환하세요.

모호한 목표 ❌	수치 목표 ✅
"UI를 더 좋게"	verify 차원 4 HIGH 5/5 달성
"빠른 앱"	LCP 2.5초 이하 (차원 6)
"안전한 코드"	CRITICAL 항목 0개 (차원 2, 5)
"교육적으로 올바르게"	Pedagogy Reviewer 🔴 0개
"테스트 강화"	커버리지 80% 이상 (차원 1)

수치화가 안 되면 루프를 시작하지 마세요. 수치화가 첫 번째 작업입니다.

---

단계 1 — 탐색 공간 정의

"무엇을 바꿀 수 있는가"를 명시합니다. 탐색 공간이 클수록 최적화 가능성이 높습니다.

탐색 공간 예시 (퀴즈 완료율 개선 목표):

UI 계층:
- 재시도 버튼 위치, 크기, 레이블 텍스트
- 오답 피드백 메시지 톤 (격려형 / 힌트형 / 중립형)
- 진도 표시 방식 (숫자 / 프로그레스바 / 아이콘)

로직 계층:
- 문항 제출 후 즉시 피드백 vs 모두 제출 후 일괄
- 힌트 제공 시점 (1회 오답 후 / 2회 오답 후)
- 세션 저장 간격

기술 계층:
- API 응답 시간 최적화
- 이미지 최적화 (CDN 경유)

---

단계 2 — 기준점(Baseline) 측정

루프 시작 전 반드시 현재 상태를 기록합니다.

# 기준점 저장 (처음 한 번)
bash .claude/skills/objective-loop/measure.sh baseline "루프 시작"
# 출력 예: 기준점 저장 완료: SCORE=20 VERDICT=REJECTED
# 생성 파일: .objective-baseline, objective-loop-log.md

# 루프 N 완료 후 측정
bash .claude/skills/objective-loop/measure.sh check "루프 N: [이번 시도 내용]"
# 출력 예: 현재: SCORE=75 | 기준점: 20 | delta: +55 | VERDICT=CONDITIONAL

delta = 0이 3회 연속이면 탐색 공간을 전환하세요. objective-loop-log.md에 모든 측정 이력이 자동 기록됩니다.

---

반복 루프 상세

1사이클 = execution-loop + 점수 측정 + 기록

사이클 N:

1. 탐색 공간에서 개선 시도 선택
   → /execution-loop [이번 시도 내용]

2. 점수 측정
   → /verify [대상 기능]

3. delta 계산
   이전 점수: [N-1회 결과]
   현재 점수: [N회 결과]
   delta:     [변화량] (양수이면 하네스에 이번 접근법 기록)

4. 기록
   echo "루프 N: [점수] (delta: [변화량])" >> objective-loop-log.md

탈출 조건

목표 달성          → 루프 종료 → 하네스 업데이트 실행
최대 5회 도달      → 현재 상태 보고 → 사용자에게 방향 결정 요청
delta = 0이 3회 연속 → 탐색 공간 확장 시도:
                       1. 다른 계층(UI → 로직 → 기술) 전환
                       2. 여전히 0이면 사용자 질문:
                          "현재 최적점에 도달했습니다.
                           목표 수치를 조정하거나 탐색 공간을 확장할까요?"

---

루브릭 건강 검사 — Goodhart's Law 방어

5회 반복마다 또는 루프 종료 시 반드시 실행:

Goodhart's Law: "측정값이 목표가 되는 순간, 그것은 좋은 측정값이기를 멈춘다." rubric 항목이 grep 기반일 때, AI는 grep은 통과하지만 실제로는 나쁜 코드를 만들 수 있습니다.

루브릭 건강 검사 체크리스트:

□ 1. 우회 가능성 검사
     점수가 오른 방식이 rubric의 의도를 실제로 달성했는가?
     예: "틀렸습니다 없음" 항목 →
         "아쉽게도 맞지 않았네요"로 grep 우회하지 않았는가?

□ 2. 역효과 검사
     점수는 올랐지만 다른 차원이 나빠지지 않았는가?
     예: 접근성 점수 올리려다 UI 복잡도 증가 → 학생 사용성 저하

□ 3. proxy 타당성 검사
     이 rubric 항목이 실제 교육 효과를 반영하는가?
     예: "재시도 버튼 DOM 존재" → 실제로 클릭 가능하고 작동하는가?

□ 4. 새 패턴 발견 여부
     이번 루프에서 rubric에 추가해야 할 새로운 규칙이 발견됐는가?

건강 검사 결과 처리:

이상 없음    → 루프 계속 또는 완료

이상 발견    →
  1. 발견된 우회 패턴 또는 미반영 규칙을 문서화
  2. rubric 항목 수정/추가 제안 작성
  3. ⚠️ 사용자에게 확인 요청 (rubric 변경은 사람이 승인)
  4. 승인 후: docs/verification-rubric.md 업데이트
  5. git commit "harness-evolve: rubric [항목명] 강화"
  6. 다음 루프부터 새 기준 적용

핵심 원칙: 코드 변경은 AI가 자율 결정합니다. rubric 변경은 반드시 사람이 승인합니다. 이것이 "교사를 없애는 것"이 아니라 "교사의 판단을 rubric 진화에 집중시키는 것"입니다.

하네스 컴포넌트 Stress-test (새 모델 출시 시 필수)

Claude 새 버전 출시마다 실행. 어제의 최적 하네스가 오늘의 병목이 될 수 있습니다.

하네스 컴포넌트 Stress-test 체크리스트:

□ 1. verify.sh grep 패턴이 새 모델이 생성하는 코드 스타일을 여전히 잡아내는가?
      예: 새 모델이 'isCorrect' 대신 'correct' 또는 'answer.correct' 패턴을 쓴다면?

□ 2. pre-commit 훅이 새 모델의 코드 속도에서도 타임아웃 없이 작동하는가?

□ 3. Sprint Contract 조건이 새 모델의 출력 수준에서 여전히 도전적인가?
      (너무 쉽게 통과하면 기준 상향 필요)

□ 4. 새 모델이 이미 자동으로 해결하는 체크 항목이 있는가?
      → 중복 제거하여 루프 속도 개선

□ 5. Goodhart's Law 우회 패턴이 새 모델에서 새로운 형태로 등장했는가?

처리 방법: 변화 발견 → rubric 수정 제안 작성 → 사용자 승인 후 반영 → harness-evolve: model stress-test 커밋

With/Without 효과 측정 (revfactory 패턴)

하네스가 실제로 품질 차이를 만드는지 측정한다.

# edu-harness 사용 전 기준점 (새 기능 구현 전)
bash .claude/skills/objective-loop/measure.sh baseline "edu-harness 적용 전"

# edu-harness로 구현 완료 후
bash .claude/skills/objective-loop/measure.sh check "edu-harness 적용 후"

# 결과 예시:
# 현재: SCORE=87 | 기준점: 20 | delta: +67 | VERDICT=CONDITIONAL

delta가 크면 하네스 효과가 입증된 것. HARNESS_CHANGELOG.md에 기록하라.

---

하네스 업데이트 — 목표 달성 후 필수

목표 달성 시 코드만 아니라 하네스도 진화합니다.

하네스 업데이트 체크리스트:

□ CLAUDE.md — 효과 있었던 패턴을 규칙으로 추가
  예: "오답 피드백은 반드시 힌트 + 격려 문장 포함"
      (이번 루프에서 완료율 +18% 효과 확인)

□ CLAUDE.md — 반복된 문제를 금지 행동으로 추가
  예: "재시도 버튼을 모달 하단에 배치하지 말 것"
      (매 루프에서 접근성 문제로 지적됨)

□ docs/verification-rubric.md — 새 항목 제안 (사람 승인 필요)
  예: "재시도 버튼: DOM 존재 + aria-label + 클릭 핸들러 동시 확인"

□ progress.md 업데이트

# 하네스 진화 커밋
git add CLAUDE.md progress.md
git commit -m "harness-evolve: [루프 결과 한 줄 요약]

objective-loop 결과:
- 목표: [목표]
- 달성: [결과]
- 반복 횟수: N회
- 하네스 업데이트: [CLAUDE.md 추가 규칙]
- rubric 변화 제안: [있으면 기재 / 없으면 '없음']"

이 커밋이 다음 루프의 더 나은 출발점이 됩니다. 시간이 흐를수록 하네스가 고도화되는 구조입니다.

---

루프 보고서 형식

objective-loop 보고: [목표]
날짜: YYYY-MM-DD

기준점:    [초기 점수]
최종 점수: [달성 점수]
반복 횟수: N회
목표 달성: ✅ 달성 / ⚠️ 부분 달성 / ❌ 미달성

루프별 delta:
  루프 1: [점수] (delta: +[N])  ← [이번에 시도한 것]
  루프 2: [점수] (delta: +[N])  ← [이번에 시도한 것]
  루프 3: [점수] (delta:  0  )  ← 탐색 공간 전환 시도
  ...

루브릭 건강 검사:
  우회 패턴 발견:      있음 / 없음
  rubric 업데이트 제안: [있으면 내용 / 없으면 '없음']
  사용자 승인 필요:    있음 / 없음

하네스 업데이트:
  CLAUDE.md 추가 규칙: [내용]
  rubric 제안:         [내용 또는 '없음']

다음 루프 권장 탐색 공간:
  [이번에 다루지 못한 개선 영역]

---

실전 예시

예시 1 — verify 점수 개선

/objective-loop 퀴즈 응시 기능의 verify 점수를 REJECTED → APPROVED로 올려줘.

루프 1: CRITICAL 2개 발견 → execution-loop으로 수정 → CRITICAL 0개 (delta: +2) 루프 2: HIGH 3개 미통과 → 접근성·피드백 메시지 수정 → HIGH 5/5 (delta: +3) 루브릭 건강 검사: "틀렸습니다" grep → "아쉽게도" 우회 패턴 발견 → rubric 수정 제안: 부정적 표현 패턴 목록 확장 → 사용자 승인 후 반영 루프 3: APPROVED → 하네스 업데이트 CLAUDE.md에 "피드백 메시지: 힌트 포함 필수" 규칙 추가

예시 2 — 교육 효과 지표 개선

/objective-loop Pedagogy Reviewer 결과에서 🔴 0개, 🟡 2개 이하 달성해줘.

루프 1: 재시도 버튼 없음(🔴) → 버튼 추가 → 🔴 0개 (delta: +1) 루프 2: 진도 표시 결핍 중심(🟡) → 성장 중심으로 변경 → 🟡 2개 (delta: +1) 루브릭 건강 검사: "재시도 버튼 DOM 존재" → 실제 form submit 연결 없는 경우 발견 → rubric 강화 제안: "재시도 버튼 + onClick 핸들러 동시 확인" 달성 → CLAUDE.md에 "재시도 버튼은 반드시 실제 form reset과 연결" 규칙 추가

---

상세 참조

• 보상 함수(rubric): docs/verification-rubric.md
• 실행 루프: .claude/skills/execution-loop/SKILL.md
• 검증 스킬: .claude/skills/verify/SKILL.md
• 교육학적 검토: AGENTS.md Pedagogy Reviewer
• 하네스 진화 가이드: docs/customization-guide.ko.md