AI가 '다 끝냈다'고 말만 하고 넘어가지 못하도록 빌드·테스트 같은 증거를 강제하는 감시 장치 묶음 — 이걸 하네스(harness)라고 부른다. 같은 하네스를 다른 회사 AI인 Codex(GPT-5.5)에서 Claude의 Opus 4.7 → 4.8 이라는 더 새 모델로 옮겼을 때, 무엇이 바뀌고 무엇을 그대로 적용했는지를 먼저 다룬다. 이어서 좋은 AI 코딩 하네스라면 갖춰야 할 8가지 조건에 비추어, /init-project · /team 라는 명령으로 짜 놓은 이 하네스가 품질 검문소(게이트)와 스스로 고치는 순환을 실제로 강제하는지 를 말이 아니라 실행 증거로 검증한다.
하네스의 바탕(substrate)은 셸 스크립트와 마크다운 문서로만 되어 있어, 어떤 AI 모델을 쓰든 그대로 작동한다. 그래서 Codex(GPT-5.5)와 Claude Code(Opus 4.8)가 똑같은 검문소(게이트)를 공유한다 — '엔진 교체'란 답을 만드는 AI 모델만 바꾼 것이지, 검문소는 손대지 않았다는 뜻이다.
표 1 · 같은 하네스에서 Opus 4.7과 4.8은 무엇이 다른가
| 하네스 구성요소 | Opus 4.7 | Opus 4.8 | 하네스에 미친 영향 |
|---|---|---|---|
| 게이트의 바탕 shell·markdown hook | 동일 | 동일 | 모델 비종속 — 변화 없음 |
| 작업 도중 끼어들어 바로잡기 | 한 번의 응답이 끝난 뒤에만 교정 가능 | 대화 도중에도 지시(system message) 넣기 가능 | 반복 작업 도중 바로잡기가 자연스러워짐 = mid-loop-question-detector 라는 훅(반복 중 '계속할까요?' 질문을 잡아내는 장치)과 맞물림 |
| 반복 입력을 재사용하는 캐시의 최소 크기 | 4,096 | 1,024 | 게이트·규칙을 매번 다시 넣어도 캐시에 더 잘 걸림 → 비용 절감 |
| 모를 때 솔직함 | 보통 | 덜 우겨댐(과신 감소) | 거짓 '완료' 보고 감소 → '완료는 증거로만'(1번 조건) 강화 |
| 한 번에 읽는 분량(컨텍스트 창) | 1M | 1M | 많은 규칙을 한꺼번에 넣을 여유는 그대로 |
| 자가개선 신호의 정확도 | 작동함 | 솔직해져서 헛신호 감소 | 엉뚱한 수정 신호가 줄어 순환이 안정됨 |
핵심: 하네스의 뼈대(검문소·순환·기억)는 4.7이든 4.8이든 똑같다 — 바탕이 AI 모델과 무관하기 때문이다. 달라진 건 모델의 능력 4가지(도중 개입·캐시 최소 크기·솔직함·신호 정확도)뿐이고, 이들은 각각 기존 장치·원칙을 강화하는 방향이다.
표 2 · Codex(GPT-5.5)에서 Opus 4.8로 옮길 때 — 무엇을 바꾸고 무엇을 그대로 뒀나
| 항목 | Codex · GPT-5.5 | Claude Code · Opus 4.8 | 옮길 때 처리 |
|---|---|---|---|
| 답을 만드는 AI 엔진 | GPT-5.5 | Opus 4.8 | 엔진만 교체 · 바탕은 그대로 |
| 게이트 13개 shell / exit-code | 동일 | 동일 | 그대로 적용 — 옮기는 비용 0 |
| 서로 검토하는 구조(교차검증) | Codex가 검토자 역할 | Opus가 구현 + Codex가 바깥에서 검토 | 역할 나눔 유지 (git-push-adversarial-review-gate) |
| 작업 도중 교정 | 프롬프트 지시로 처리 | 모델이 자체 지원(system message) | 옮긴 뒤 오히려 더 강해짐 — 별도 코드 불필요 |
| self-improve · memory-bank | 파일로 된 바탕 | 동일 | 그대로 재사용 — 변경 없음 |
핵심: Codex로 옮긴 버전(/codex-harness-system)와 Opus 4.8 은 같은 바탕을 공유하므로, 하네스가 기준에 맞는지 보는 같은 검증이 그대로 적용된다. 옮긴다는 건 'AI 엔진만 교체'일 뿐, 검문소·순환·검증은 손대지 않았다.
게이트 13개(실제로 막는 강제 11 + 연결만 된 권고 2), self-improve 가 한 바퀴 도는 왕복 순환, 5개 축의 존재 여부는 어떤 엔진을 쓰든 똑같다. 그래서 Codex로 옮긴 버전(/codex-harness-system)과 Claude Code에 똑같은 검증이 적용된다.
mid-conversation system messages → 작업 도중 교정을 끼워 넣음 = mid-loop-question-detector 훅(반복 중 '계속할까요?' 질문 차단)과 맞물림. improved honesty → 거짓 '완료' 보고 감소 = '완료는 증거로만'. 반복 입력 캐시 최소 1,024(4.7은 4,096) → 게이트·맥락을 반복해 넣어도 캐시에 걸림 = 비용 절감.
측정 기준을 바로잡았다. 이 글의 첫 판에서는 게이트가 실제로 막는지를 아무 설정도 안 한 cc-sync 폴더에서 쟀다. 그래서 프로젝트별 게이트를 확인 안 됨이라고 표기했다. 이건 틀렸다 — cc-sync 는 설정 파일을 백업·동기화하는 폴더라서 /init-project 명령을 한 번도 돌린 적이 없다.
올바른 기준선은 /init-project · /team 으로 셋업한 진짜 프로젝트다. 그런 프로젝트에서는 게이트가 설치되어 실제로 막는다.
또한 git-push-adversarial-review-gate 는 이번 작업에서만 5번이나 실제로 push(코드 업로드)를 막았다— '확인 안 됨'이 아니라 실제로 막는 게이트다.
그래서 이 검증은 게이트 스크립트(hook)에 일부러 규칙 위반 입력을 넣어 직접 돌려보고, block(exit 2)·감지(상태 파일 기록)·권고(메시지 출력) 가 실제로 발동하는지 확인한다(파일이 있나 단순 검색으로 때우지 않는다).
user-scope 6 ENFORCED(block/detect) + advisory 2(self-improve trigger→check, round-trip VERIFIED) + /init-project 가 설치한 프로젝트별 5 ENFORCED = 실제로 막는 게이트 11 · 전체 13개. (권고 2개는 막지 않고 메시지만 넣으므로 '강제' 수에서 뺐다)
내 PC 전역에 항상 켜져 있는 게이트 8개다. 6개는 규칙을 어기면 실제로 작업을 멈추는 '강제'(다른 AI 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) 전 다른 AI(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 설치) |
앞에서 본 전역 게이트와 프로젝트 게이트는 따로 노는 게 아니라 한 방향씩 맞물린다 — 설치는 전역에서 프로젝트로(위→아래), 학습은 프로젝트에서 전역으로(아래→위), 실행할 때는 한 번의 동작이 양쪽 게이트를 동시에 거친다.
설치(INSTALL)는 위에서 아래로(전역→프로젝트), 학습(LEARN)은 아래에서 위로(프로젝트→전역), 실행(RUN)은 가운데서 한 동작이 양쪽 게이트를 동시에 거쳐 통과/차단 판정을 받는다.
표 · 동작마다 게이트가 겹겹이 작동 — 전역과 프로젝트가 어떻게 겹치나
| 동작(이벤트) | 전역 게이트 | 프로젝트 게이트 | 합친 판정 |
|---|---|---|---|
| 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 |
전부 통과해야 업로드 허용 |
| Stop | mid-loop · premature-completion · self-improve-trigger |
mid-loop · premature-completion |
반복 규율 감지 + 자가개선 신호 |
| UserPromptSubmit | self-improve-check · prompt-enhancer · reminders |
mid-loop · premature 알림 |
다음 세션에 교훈 주입 |
| SubagentStop TaskCompleted |
— | subagent-verify · claim-done-gate |
하위 에이전트 · 작업 완료 검증 |
일부 게이트(no-env-commit · mid-loop · premature-completion)은 전역·프로젝트 양쪽에 동시 설치되어 이중으로 막는다 — 전역이 놓쳐도 프로젝트가, 프로젝트가 놓쳐도 전역이 잡도록. 프로젝트 게이트 묶음은 install-project-hooks.sh 의 classify() 가 프로젝트 종류에 맞춰 필요한 것만 골라 설치한다.
/init-project → /team → /self-improve → /trend-harvester 네 부품 아래에 memory-bank 가 바탕으로 깔린다. 이 중 self-improve 만 실제로 돌려서 동작을 확인했고(VERIFIED), 나머지는 '있다·등록됐다'까지만 정직하게 표시한다.
문제가 생기면 사람이 안 껴도 한 바퀴가 돈다 — 잘못된 커밋이나 사용자 불만이 '신호', 자가개선이 '수정', 게이트·QA가 '검증', 규칙 적용 또는 되돌림이 '반영'이다.
이번 작업 자체가 산 증거다 — 사이트 배포 버그가 '신호', 자가개선 규칙 2건과 생성기 v2가 '수정', 데이터 손실 없이 다시 배포하고 게이트를 통과한 것이 '검증', 실제 사이트에 반영된 것이 '반영'. 한 바퀴가 실제로 돌아 닫혔다.
오른쪽·아래로 갈수록 성숙한 단계다. L0~L4(프롬프트→증거 확인→실수 기억)는 이미 갖췄고, 지금은 L5 — '하세요' 권고를 '멈춰 세우는' 강제로 바꾸는 단계다. L6(스스로 고치는 순환)은 거의 닫혔고, L7(모든 도구를 하나로 통합 운영)이 다음 목표다.
L7은 이 5개 축(전역·프로젝트·플러그인·MCP·트렌드)이 하나의 개인 운영체계처럼 저절로 맞물려 도는 상태다. 5개 축이 모두 존재하긴 하지만 '저절로 통합됨'은 실제 실행 중에만 확인되는 것이라 정적인 문서로는 증명 밖 — 아직은 목표 지점이다.
| # | 쉽게 말하면 | 충족 |
|---|---|---|
| 1 | 완료 = 증거. “AI가 됐다고 말함”이 아니라 빌드·테스트·스크린샷 같은 재현 증거로만 완료 인정 | 충족 |
| 2 | 권고를 강제로. 중요 규칙은 “하세요” 안내가 아니라 위반 시 작업을 멈추는 게이트 | 충족 |
| 3 | 실수가 다음을 바꾼다. 한 번 틀린 건 규칙으로 남아 다음 세션에 자동 차단 | 충족 · 실제로 확인됨 |
| 4 | 스스로 고치는 순환. 감지→수정→검증→반영이 사람 개입 없이 한 바퀴 | 충족 · 순환 완성도 1.0 |
| 5 | 도구가 하나로. 에이전트·게이트·메모리·자가개선이 따로 놀지 않고 한 시스템 | presence 5/5 |
| 6 | 최소 목표는 닫힌 순환(L6). 조직 확장(L7)은 그 다음 | 근접 |
| 7 | 다른 모델로 교차검증. 같은 모델의 맹점을 외부 모델(Codex)이 다시 본다 | 충족 · 업로드 전 교차검증 게이트가 실제로 강제(이번에 5회 차단) |
| 8 | 화면은 띄워봐야 완료. 코드 통과 ≠ 화면 정상, 브라우저 캡처 필수 | 충족 · UI 증거 게이트(/init-project 설치) |
정직한 한계. 7·8번(다른 AI 교차검증·화면 캡처 증거)은 측정 기준을 바로잡은 뒤 충족으로 확인됐다 — 각각 전역에서 실제로 막는 강제(차단 증거 있음)와 /init-project 설치로 작동한다.
L7의 '저절로 통합됨'만은 실제 실행 중에만 드러나는 것이라, 5개 축이 다 있다는 것만으로 '달성'이라 말하지 않는다. 표의 숫자는 실제로 잰 값이고, 'Codex에서 Opus 4.8로 옮기면 이렇다'는 해석은 추정 분석임을 구분해 둔다.