같은 Claude Code 하네스를 Codex(GPT-5.5)에서 Opus 4.7 → 4.8 런타임으로 옮기며 무엇이 바뀌고 적용됐는지 먼저 다룬다. 이어서 좋은 AI 코딩 하네스가 갖춰야 할 8가지 기준으로, /init-project · /team 으로 구성한 하네스가 품질 게이트와 자가개선 순환을 실제로 강제하는지 증거로 검증한다.
하네스 substrate 는 모델 비종속(shell·markdown). Codex(GPT-5.5)와 Claude Code(Opus 4.8)가 같은 게이트 substrate 를 공유 — 런타임 이전은 추론 엔진만 바꾼 것.
표 1 · Opus 4.7 → 4.8 하네스 구조 비교
| 하네스 항목 | Opus 4.7 | Opus 4.8 | 하네스에 미친 영향 |
|---|---|---|---|
| 게이트 substrate shell·markdown hook | 동일 | 동일 | 모델 비종속 — 변화 없음 |
| 루프 중간 개입 | 턴 종료 후에만 교정 | 대화 중간 system message 주입 | 루프 중간 교정이 자연스러워짐 = mid-loop-question-detector 정합 |
| prompt cache 최소 토큰 | 4,096 | 1,024 | 게이트·rule 반복 주입 캐시 적중 ↑ → 토큰 비용 ↓ |
| 불확실성 정직성 | 보통 | 과신 감소 | 거짓 “완료” 보고 ↓ → 증거 기반 완료(1번 기준) 강화 |
| 컨텍스트 윈도우 | 1M | 1M | 대규모 rules/scaffold 주입 여유 동일 |
| self-improve 신호 품질 | 동작 | 정직성↑로 오탐 ↓ | 잘못된 fix 신호 감소 → 폐루프 안정 |
핵심: 하네스 골격(게이트·폐루프·메모리)은 4.7과 4.8이 동일하다 — 모델 비종속 substrate 라서. 바뀐 건 모델 능력 4가지(중간 개입·캐시 임계·정직성·신호 품질)이고, 각각 기존 hook/원칙을 강화하는 방향이다.
표 2 · Codex(GPT-5.5) → Opus 4.8 이전 — 변경/적용
| 항목 | Codex · GPT-5.5 | Claude Code · Opus 4.8 | 이전 시 처리 |
|---|---|---|---|
| 추론 엔진 | GPT-5.5 | Opus 4.8 | 엔진만 교체 · substrate 불변 |
| 13 게이트 shell / exit-code | 동일 | 동일 | 그대로 적용 — 이식 비용 0 |
| 교차검증 구조 | Codex가 reviewer | Opus 구현 + Codex 외부 reviewer | 역할 분담 유지 (git-push-adversarial-review-gate) |
| 루프 중간 교정 | 프롬프트 기반 | 네이티브 system message | 이전 후 강화 — 별도 코드 불필요 |
| self-improve · memory-bank | 파일 기반 substrate | 동일 | 재사용 — 변경 없음 |
핵심: Codex 포트(/codex-harness-system)와 Opus 4.8 은 같은 substrate 를 공유하므로 같은 conformance 평가가 그대로 적용된다. 이전은 “추론 엔진 교체”일 뿐, 게이트·폐루프·평가는 손대지 않았다.
13 게이트(11 ENFORCED + 2 WIRED), self-improve round-trip, 5축 presence 는 런타임과 무관하게 동일. 그래서 Codex 포트(/codex-harness-system)와 Claude Code 에 같은 평가가 적용된다.
mid-conversation system messages → 루프 중간 교정 주입 = mid-loop-question-detector 와 정합. improved honesty → 거짓 “완료” 보고 감소 = 증거 기반 완료. prompt cache 최소 1,024(4.7=4,096) → 게이트·컨텍스트 반복 주입 캐시 적중 = 토큰 효율.
기준선 정정. 초판은 게이트 강제를 맨 cc-sync 레포에서 측정해
project-scope 게이트를 미검증으로 표기했다. 이는 틀렸다 — cc-sync 는 dotfiles 동기화 레포라 /init-project 를 돌린 적이 없다.
올바른 baseline 은 /init-project · /team 으로 구성된 프로젝트이며, 거기서는 project 게이트가 설치·강제된다.
또한 git-push-adversarial-review-gate 는 이 세션에서만 5회 실제로 push 를 차단한 강제 게이트다 — 미검증이 아니다.
그래서 이 평가는 hook 을 위반 픽스처로 직접 호출해 block(exit 2)·detect(state 파일)·advisory(출력) 발동을 확인한다(파일·grep LINT 아님).
user-scope 6 ENFORCED(block/detect) + advisory 2(self-improve trigger→check, round-trip VERIFIED) + /init-project 설치 project-scope 5 ENFORCED = 강제 11 · 총 13. (advisory 2 는 출력 주입형이라 강제 집계에서 제외)
내 PC 전역에 항상 켜진 게이트 8개 — 6개는 실제로 작업을 멈추는 강제(ENFORCED, Codex 교차검증 게이트 포함·이 세션에서 5번 차단), 2개는 멈추진 않지만 교훈을 다음 세션에 주입하는 권고(검증 완료).
프로젝트에서 /init-project 를 한 번 돌리면 이 5개 게이트가 그 프로젝트에 설치되어 강제된다. 그래서 평가도 맨 폴더가 아니라 /init-project 를 돌린 프로젝트 기준이어야 한다.
| 게이트 | 범위 | 무엇을 막나 | 상태 |
|---|---|---|---|
no-env-commit · no-localstorage · agent-browser-security | user | 시크릿·localStorage·브라우저 보안 | ENFORCED ×3 |
premature-completion · mid-loop-question | user | 성급한 완료·반복 중 질문 감지 | ENFORCED ×2 |
git-push-adversarial-review-gate | user | push 전 Codex 교차검증 | ENFORCED (세션 5회 차단) |
self-improve-trigger · check | user | 잘못된 커밋 → 다음 세션 주입 | WIRED · VERIFIED |
scaffold-violation · qa-gate-before-push · code-quality · portless | project | 금지 패턴·QA·코드 품질 | ENFORCED (/init-project 설치) |
task-quality-gate | project | UI 변경 시 브라우저 증거 | ENFORCED (/init-project 설치) |
위 user-scope·project-scope 게이트는 따로 노는 게 아니라 한 방향씩 맞물린다 — 설치는 user→project(위→아래), 학습은 project→user(아래→위), 실행 시엔 한 이벤트가 양쪽 훅을 동시에 거친다.
INSTALL 은 아래로(user→project), LEARN 은 위로(project→user), RUN 은 가운데서 한 이벤트가 양쪽 훅을 동시에 거쳐 게이트 판정을 받는다.
표 · 이벤트별 layered enforcement — 양 스코프가 어떻게 겹치나
| 이벤트 | USER scope 훅 | PROJECT scope 훅 | 결합 판정 |
|---|---|---|---|
| PreToolUse Edit · Write |
no-env-commit · no-localstorage · agent-browser-security |
scaffold-violation · code-quality · no-localstorage |
둘 중 하나라도 exit 2 → 차단 |
| PreToolUse Bash · git push |
git-push-adversarial-review-gate · qa-inventory-gate |
qa-gate-before-push · codex-review-gate · no-verify-ban |
전부 통과해야 push 허용 |
| Stop | mid-loop · premature-completion · self-improve-trigger |
mid-loop · premature-completion |
루프 규율 감지 + self-improve 신호 |
| UserPromptSubmit | self-improve-check · prompt-enhancer · reminders |
mid-loop · premature 알림 |
다음 세션에 교훈 주입 |
| SubagentStop TaskCompleted |
— | subagent-verify · claim-done-gate |
서브에이전트 · 태스크 완료 검증 |
일부 훅(no-env-commit · mid-loop · premature-completion)은 양 스코프에 동시 설치되어 이중으로 막는다 — user 가 빠져도 project 가, project 가 빠져도 user 가 잡도록. project-scope 게이트 집합은 install-project-hooks.sh 의 classify() 가 프로젝트 타입에 맞춰 부분 설치한다.
/init-project → /team → /self-improve → /trend-harvester 위에 memory-bank 가 substrate 로 깔린다. self-improve hook 만 결정론적 행동검증(VERIFIED), 나머지는 존재·등록을 정직하게 노출.
문제가 생기면 사람 개입 없이 한 바퀴가 돈다 — 잘못된 커밋·사용자 불만이 ‘신호’, self-improve 가 ‘수정’, 게이트·QA 가 ‘검증’, 적용 또는 되돌림으로 ‘반영’.
이번 세션이 산 증거다 — 사이트 배포 버그(신호) → self-improve 룰 2건·생성기 v2(패치) → 무손실 재배포·게이트 통과(검증) → 라이브 반영(ack). 한 바퀴가 실제로 닫혔다.
아래로 갈수록 성숙. L0~L4(프롬프트→증거→기억)는 갖췄고, 지금은 L5 — 권고를 강제로 바꾸는 단계. L6(스스로 고치는 순환)은 거의 닫혔고, L7(전 도구 통합 운영)은 다음 목표.
L7 은 5축이 하나의 개인 운영체계로 자동 연동되는 상태. 5/5 요소 존재(presence)하나 ‘자동 통합’은 런타임 동작이라 정적 입증 밖 — 지향점.
| # | 쉽게 말하면 | 충족 |
|---|---|---|
| 1 | 완료 = 증거. “AI가 됐다고 말함”이 아니라 빌드·테스트·스크린샷 같은 재현 증거로만 완료 인정 | 충족 |
| 2 | 권고를 강제로. 중요 규칙은 “하세요” 안내가 아니라 위반 시 작업을 멈추는 게이트 | 충족 |
| 3 | 실수가 다음을 바꾼다. 한 번 틀린 건 규칙으로 남아 다음 세션에 자동 차단 | 충족 · VERIFIED |
| 4 | 스스로 고치는 순환. 감지→수정→검증→반영이 사람 개입 없이 한 바퀴 | 충족 · active 1.0 |
| 5 | 도구가 하나로. 에이전트·게이트·메모리·자가개선이 따로 놀지 않고 한 시스템 | presence 5/5 |
| 6 | 최소 목표는 닫힌 순환(L6). 조직 확장(L7)은 그 다음 | 근접 |
| 7 | 다른 모델로 교차검증. 같은 모델의 맹점을 외부 모델(Codex)이 다시 본다 | 충족 · git-push-adversarial ENFORCED (세션 5회 차단) |
| 8 | 화면은 띄워봐야 완료. 코드 통과 ≠ 화면 정상, 브라우저 캡처 필수 | 충족 · task-quality-gate (/init-project) |
정직한 한계. 7·8번(Codex 교차검증·UI 브라우저 증거)은 기준선 정정 후 충족이다 — 각각 전역 강제(실제 차단 증거 있음)와 /init-project 설치로 작동한다.
L7 ‘자동 통합’만 런타임 동작이라 presence(5/5)로 ‘달성’을 선언하지 않는다. 수치는 측정값, Codex→Opus 4.8 이전 해석은 합성 분석임을 구분한다.