AI 모델을 새것으로 바꾸면, 그동안 만들어 둔 검사 장치가 새 모델에서도 그대로 작동하는지 알 수 없다는 문제가 있었다. 여기서 검사 장치란 하네스(harness)다. AI가 '다 끝냈다'고 말만 하고 넘어가지 못하도록 빌드·테스트 같은 증거를 강제하는 감시 장치 묶음이다. 이 글은 같은 하네스를 다른 회사 AI인 Codex(GPT-5.5)에서 Claude의 Opus 4.7 → 4.8 이라는 더 새 모델로 옮겼을 때 무엇이 바뀌고 무엇을 그대로 적용했는지를 먼저 다룬다. 이어서 좋은 AI 코딩 하네스라면 갖춰야 할 8가지 조건에 비추어, /init-project · /team 라는 명령으로 짜 놓은 이 하네스가 품질 검문소(게이트)와 스스로 고치는 순환을 실제로 강제하는지 를 실행 증거로 검증한다. 말로 하는 검증은 인정하지 않는다. 아래 네 숫자는 순서대로 전체 게이트 수, 실제로 막는 게이트 수, /init-project 가 프로젝트마다 설치하는 게이트 수, 연결만 되어 권고만 하는 게이트(wired advisory) 수다.
WIRED advisory하네스의 바탕(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 라는 훅(hook — 작업 전후에 자동으로 끼어드는 검사 프로그램. 이 훅은 반복 중 '계속할까요?' 질문을 잡아낸다)과 맞물린다 |
| 반복 입력을 재사용하는 캐시(같은 입력을 다시 계산하지 않고 재사용하는 저장소)의 최소 크기 | 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가 바깥에서 검토 | 역할 나눔 유지. 업로드 전 다른 AI가 검토하게 강제하는 게이트(git-push-adversarial-review-gate)가 그대로 남는다 |
| 작업 도중 교정 | 프롬프트(AI에게 주는 지시문)로 처리 | 모델이 자체 지원(대화 도중 넣는 system message) | 옮긴 뒤 오히려 더 강해진다. 별도 코드가 필요 없다 |
| self-improve · memory-bank | 파일로 된 바탕 | 동일 | 그대로 재사용 — 변경 없음 |
핵심: Codex로 옮긴 버전(/codex-harness-system)와 Opus 4.8 은 같은 바탕을 공유한다. 그래서 하네스가 기준에 맞는지 보는 같은 검증이 그대로 적용된다. 옮긴다는 건 'AI 엔진만 교체'일 뿐이다. 검문소·순환·검증은 손대지 않았다.
게이트 13개(실제로 막는 강제 11 + 연결만 된 권고 2), 자가개선 명령 self-improve 가 한 바퀴 도는 왕복 순환, 5개 축(전역·프로젝트·플러그인·MCP·트렌드)의 존재 여부는 어떤 엔진을 쓰든 똑같다. 그래서 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 으로 셋업한 진짜 프로젝트다. 그런 프로젝트에서는 게이트가 설치되어 실제로 막는다.
또한 업로드 전에 다른 AI의 검토를 강제하는 게이트 git-push-adversarial-review-gate 는 이번 작업에서만 5번이나 실제로 push(코드 업로드)를 막았다. '확인 안 됨'일 리가 없다. 실제로 막는 게이트다.
그래서 이 검증은 게이트 스크립트(hook — 작업 전후에 자동으로 끼어들어 검사하는 작은 프로그램)에 일부러 규칙 위반 입력을 넣어 직접 돌려보고, block(exit 2)·감지(상태 파일 기록)·권고(메시지 출력) 가 실제로 발동하는지 확인한다. 파일이 있나 단순 검색으로 때우지는 않는다. 발동 방식은 세 가지다. 규칙을 어기면 작업을 실제로 멈추는 '강제'는 차단(block) 또는 감지(detect)로 동작한다. 멈추지는 않고 메시지로 권고만 하는 '권고'(advisory)도 있다. 권고 게이트는 자가개선 신호를 남기는 훅(trigger)과 다음 세션에서 그 신호를 읽어 넣는 훅(check)이 짝을 이루며, 그 왕복(round-trip)이 실제로 도는 것까지 확인했다. 세어 보면 이렇다. 내 PC 전역(user-scope)의 강제 게이트는 6 ENFORCED(block/detect) + 2 advisory(self-improve trigger→check, round-trip VERIFIED) + /init-project 가 설치한 프로젝트별 강제 게이트 5 ENFORCED = 실제로 막는 게이트 11 · 전체 13개. 권고 2개는 막지 않고 메시지만 넣으므로 '강제' 수에서 뺐다. 아래 표의 상태 칸에 적힌 대문자 코드 표기는 이 강제·연결됨·확인됨 구분을 그대로 옮긴 것이다.
내 PC 전역에 항상 켜져 있는 게이트는 8개다. 6개는 규칙을 어기면 실제로 작업을 멈추는 '강제'다. 다른 AI인 Codex로 교차검증하는 게이트도 여기 들어가며, 이번 작업에서 5번 막았다. 나머지 2개는 멈추진 않지만 다음 세션에 교훈을 자동으로 넣어 주는 '권고'다. 작동은 확인했다.
PROJECT SCOPE · Project-Scope Gates · /init-project프로젝트에서 /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(품질 검증) 없는 업로드·타입 검사 우회·portless(포트 번호를 직접 정하지 않고 개발 서버를 띄우게 해 주는 도구) 없이 포트를 고정해 띄우는 개발 서버 | ENFORCED (/init-project 설치) |
task-quality-gate | project | UI 변경 시 브라우저 증거 | ENFORCED (/init-project 설치) |
앞에서 본 전역 게이트와 프로젝트 게이트는 따로 놀지 않고 한 방향씩 맞물린다 . 설치는 전역에서 프로젝트로 내려가고, 학습은 프로젝트에서 전역으로 올라간다. 실행할 때는 한 번의 동작이 양쪽 게이트를 동시에 거친다.
INSTALL · RUN · LEARN
그림의 세 기둥은 왼쪽부터 설치(Install)·실행(Run)·학습(Learn)이다. 설치(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 |
하위 에이전트(큰 작업을 나눠 맡는 보조 AI) · 작업 완료 검증 |
일부 게이트(no-env-commit · mid-loop · premature-completion)은 전역·프로젝트 양쪽에 동시 설치되어 이중으로 막는다. 전역이 놓쳐도 프로젝트가 잡고, 프로젝트가 놓쳐도 전역이 잡는다. 프로젝트 게이트 묶음은 설치 스크립트 install-project-hooks.sh 안의 분류 함수 classify() 가 프로젝트 종류에 맞춰 필요한 것만 골라 설치한다.
/init-project(프로젝트 셋업) → /team(작업 지휘) → /self-improve(자가개선) → /trend-harvester(바깥 트렌드 수집) 네 부품 아래에 memory-bank(세션이 바뀌어도 기억을 저장·검색하는 토대)가 바탕으로 깔린다. 이 중 self-improve 만 실제로 돌려서 동작을 확인했다. 나머지는 '있다·등록됐다'까지만 정직하게 표시한다.
문제가 생기면 사람이 안 껴도 한 바퀴가 돈다. 잘못된 커밋이나 사용자 불만이 '신호'다. 자가개선이 '수정', 게이트·QA가 '검증', 규칙 적용 또는 되돌림이 '반영'이다.
이번 작업 자체가 산 증거다. 사이트 배포(실제 주소에 올리는 일) 버그가 '신호'였다. 자가개선 규칙 2건과 생성기 v2(두 번째 판)가 '수정'이었다. 데이터 손실 없이 다시 배포하고 게이트를 통과한 것이 '검증'이었다. 실제 사이트에 반영된 것이 '반영'이다. 한 바퀴가 실제로 돌아 닫혔다.
L0–L2 · L3 · L4 · L5 · L6 · L7
오른쪽으로 갈수록 성숙한 단계다. 그림 속 L 뒤의 숫자가 곧 단계 번호다. 0~4단계(프롬프트→증거 확인→실수 기억)는 이미 갖췄다. 지금은 5단계, '하세요' 권고를 '멈춰 세우는' 강제로 바꾸는 단계다. 6단계(스스로 고치는 순환)는 거의 닫혔고, 7단계(모든 도구를 하나로 통합 운영)가 다음 목표다.
L7 Work OS7단계는 이 5개 축(전역 설정·프로젝트 설정·플러그인·MCP·트렌드 수집)이 하나의 개인 운영체계처럼 저절로 맞물려 도는 상태다. MCP는 외부 도구를 AI에 연결하는 표준 규약이다. 5개 축이 모두 존재하긴 한다. 그러나 '저절로 통합됨'은 실제 실행 중에만 확인되는 것이라 정적인 문서로는 증명할 수 없다. 아직은 목표 지점이다.
| # | 쉽게 말하면 | 충족 |
|---|---|---|
| 1 | 완료 = 증거. “AI가 됐다고 말함”이 아니라 빌드·테스트·스크린샷 같은 재현 증거로만 완료 인정 | 충족 |
| 2 | 권고를 강제로. 중요 규칙은 “하세요” 안내에 그치지 않고 위반 시 작업을 멈추는 게이트로 | 충족 |
| 3 | 실수가 다음을 바꾼다. 한 번 틀린 건 규칙으로 남아 다음 세션에 자동 차단 | 충족 · 실제로 확인됨 |
| 4 | 스스로 고치는 순환. 감지→수정→검증→반영이 사람 개입 없이 한 바퀴 | 충족 · 순환 완성도 1.0 |
| 5 | 도구가 하나로. 에이전트(자율적으로 일을 처리하는 AI)·게이트·메모리·자가개선이 따로 놀지 않고 한 시스템 | presence 5/5 |
| 6 | 최소 목표는 닫힌 순환(6단계). 조직 확장(7단계)은 그 다음 | 근접 |
| 7 | 다른 모델로 교차검증. 같은 모델의 맹점을 외부 모델(Codex)이 다시 본다 | 충족 · 업로드 전 교차검증 게이트가 실제로 강제(이번에 5회 차단) |
| 8 | 화면은 띄워봐야 완료. 코드 검사 통과가 화면 정상을 뜻하지는 않으니 브라우저 캡처가 필수 | 충족 · UI 증거 게이트(/init-project 설치) |
정직한 한계. 7·8번(다른 AI 교차검증·화면 캡처 증거)은 측정 기준을 바로잡은 뒤 충족으로 확인됐다. 각각 전역에서 실제로 막는 강제(차단 증거 있음)와 /init-project 설치로 작동한다.
7단계의 '저절로 통합됨'만은 실제 실행 중에만 드러나는 것이라, 5개 축이 다 있다는 것만으로 '달성'이라 말하지 않는다. 표의 숫자는 실제로 잰 값이다. 'Codex에서 Opus 4.8로 옮기면 이렇다'는 해석은 추정 분석임을 구분해 둔다.