클로덱스 루프: 짠 모델이 자기 계획을 검수하지 못하게 막기

클로드 코드에 기능 하나를 맡기면, 계획도 클로드가 짜고 그 계획의 검수도 클로드가 한다. 자기 숙제를 자기가 채점하는 구조라 리뷰가 “괜찮습니다”로 끝나기 쉽다.

클로덱스 루프(Claudex Loop)는 이걸 사람의 주의력이 아니라 구조로 막는 스킬이다. 계획을 짠 모델과 검수하는 모델을 서로 다른 회사 것으로 갈라놓고, 승인에 계획 파일의 해시를 묶어둔다.

chaseai-ytclaudex-loopRepository

2026년 9월 23일 기준 별 2,433개, 포크 241개, MIT 라이선스, v2.1.0.

무엇이 달라지나

핵심은 역할 배치다. 어느 CLI에서 시작하느냐에 따라 검수자가 자동으로 반대쪽이 된다.

시작한 곳	요구사항·계획	계획 검수	기본 빌더	최종 점검
클로드 코드	현재 클로드 세션	코덱스	클로드	새 코덱스 세션
코덱스	현재 코덱스 세션	클로드	코덱스	새 클로드 세션

빌더는 builder=claude 또는 builder=codex로 직접 고를 수 있고, 점검자는 항상 빌더의 반대쪽이 된다. 최종 점검이 “새 세션”인 것도 의도적이다 — 만드는 동안 쌓인 맥락이 점검에 섞이지 않게 한다.

네 단계

1. 정찰(Recon) — 추측으로 시작하지 않는다. 기존 코드와 관련 문서를 읽고, 신규 프로젝트면 가정을 조사한다. 결과는 출처가 붙은 가정 목록으로 나온다.

2. 요구사항(Requirements) — 결과를 바꾸는 결정만 묻는다. 독립적인 질문은 묶어서 한 번에 묻고, 관찰 가능한 통과 기준과 그걸 확인할 명령어를 계획에 같이 적는다.

3. 계획 검수(Plan review) — 여기가 이 도구의 존재 이유다. 반대쪽 제공자가 계획과 관련 코드를 읽고 근거가 붙은 지적을 돌려준다. 판정은 APPROVED, REVISE, BLOCKED 셋 중 하나이고, 기본 5회 안에서 끝난다. 라운드가 소진돼도 억지로 승인으로 바뀌지 않는다.

4. 빌드와 점검(Build and inspect) — 구현이 승인된 뒤에야 빌더가 계획대로 작업한다. 합의된 검증 명령을 실제로 돌리고, 반대쪽 제공자가 새 세션에서 최종 변경분을 점검한다.

기록은 두 파일로 남는다. PLAN.md가 무엇을 만들지, PLAN-REVIEW-LOG.md가 지적·처리·사용 모델·증거·남은 불확실성을 담는다.

승인이 뜻하는 것

승인은 “모델이 OK라고 말했다”가 아니다. 러너가 확인하는 것은 CLI 턴이 정상 종료했고 구조화된 검수 결과가 있다는 사실이며, 빈 출력 파일이나 세션 시작 이벤트는 승인으로 치지 않는다.

승인 기록에는 계획의 경로와 SHA256이 들어간다. 계획을 한 줄만 고쳐도 그 승인은 무효가 된다. 점검 기록도 빌드 이전 커밋과 점검한 변경분의 지문(스테이징·미추적 파일 포함)을 남기므로, 이후 코드가 바뀌면 다시 점검해야 한다.

다만 착각하면 안 되는 것이 있다. 깨끗한 결과가 모델이 옳다는 증명은 아니다. 지적 0건도 정상이고, 지적이 많은 것이 품질 점수도 아니다. BLOCKED와 실행 실패, 라운드 소진은 감춰지지 않고 그대로 드러난다.

설치

두 CLI가 모두 설치·로그인돼 있어야 전체 흐름이 돈다. 파이썬 3.10 이상이 공용 어댑터를 돌리며, 별도 pip 패키지나 API 키는 필요 없다.

먼저 준비 상태부터 확인한다.

codex --version
codex login status
claude --version
claude auth status
python3 --version

클로드 코드 플러그인

/plugin marketplace add chaseai-yt/claudex-loop
/plugin install claudex-loop@claudex-loop

코덱스 또는 수동 설치

레포를 클론하고 스킬 디렉터리를 통째로 복사한다. 호환 명령들이 claudex-loop 안의 런타임을 공유하므로 별칭만 복사하면 동작하지 않는다.

chaseai-yt/claudex-loopREADME.mdmainMarkdown

# macOS / Linux — 레포 안에서 실행
mkdir -p ~/.agents/skills ~/.claude/skills
cp -R skills/. ~/.agents/skills/
cp -R skills/. ~/.claude/skills/

# Windows PowerShell — 레포 안에서 실행
New-Item -ItemType Directory -Force "$env:USERPROFILE\.agents\skills", "$env:USERPROFILE\.claude\skills" | Out-Null
Copy-Item -Recurse -Force skills\* "$env:USERPROFILE\.agents\skills\"
Copy-Item -Recurse -Force skills\* "$env:USERPROFILE\.claude\skills\"

복사한 뒤 새 세션을 열어야 스킬이 잡힌다. 업데이트는 git pull 후 다시 복사.

라우팅만 쓰고 싶다면 skills/claudex-route/ 하나만 복사해도 된다. 이건 파이썬 의존성이 없는 독립 스킬이고, 누가 이 작업을 맡는 게 좋을지 추천만 해준다.

쓰는 법

claudex this feature — plan and implement it
claudex this plan, mode=review, plan=docs/migration.md, rounds=3
claudex this feature, builder=codex, reviewer_model=gpt-6-astra
claudex this feature, builder=claude, reviewer_model=claude-fable-5-1

처음이라면 세 번째 줄 형태 말고 두 번째 줄을 권한다. mode=review는 이미 있는 계획서 하나만 검수시키므로, 전체 흐름을 돌리지 않고도 “다른 회사 모델이 내 계획을 뜯어본다”가 무엇인지 가장 빨리 확인할 수 있다.

조절할 수 있는 것

인자	기본값	용도
mode	full	review는 기존 계획에서 시작
plan	PLAN.md	계획 파일 경로
log	PLAN-REVIEW-LOG.md	추가 전용 결정 기록
builder	현재 호스트	claude 또는 codex
reviewer_model / builder_model / inspector_model	각 CLI 설정	역할별 모델 지정
rounds	5	계획 검수 라운드 상한
MAX_FIX_ROUNDS	2	빌드 수정 시도 상한
MAX_INSPECTION_ROUNDS	2	최초 점검 + 재점검 1회
research	작업에 비례	none / web / 명시 승인된 deep
inspect	on	off는 명시적이고 기록되는 선택
PROOF_CMD	계획·레포에서	산출물을 검증할 합의된 명령

걸려 넘어지기 쉬운 곳

모델 이름은 자동으로 안 바뀐다. 호스트 UI에서 고른 모델이 반대쪽 CLI의 설정을 바꾸지 않는다. 요청한 모델과 실제로 관찰된 모델은 따로 기록되고, 조용한 폴백은 없다. 특정 모델을 쓰고 싶으면 reviewer_model 같은 인자로 역할별로 직접 지정해야 한다.

계정마다 쓸 수 있는 모델이 다르다. 예를 들어 ChatGPT 계정으로 코덱스를 쓰면 일부 모델이 거부된다(The '<모델>' model is not supported when using Codex with a ChatGPT account). 문서에 예시로 나온 모델명을 그대로 넣기 전에 본인 계정에서 한 번 호출해 보는 게 빠르다.

검수 샌드박스가 양쪽이 다르다. 코덱스 검수는 읽기 전용 셸 샌드박스에서 돌고, 클로드 검수는 파일 읽기·검색만 노출되며 커스터마이징이 꺼지고 MCP 도구도 쓰지 않는다. 기존에 코덱스 MCP 설정을 해뒀다면 특히 확인할 것.

워크트리는 보안 샌드박스가 아니다. 위임 빌드는 깨끗한 체크아웃을 요구하고 워크트리가 관련 없는 작업을 보호해 주지만, 그것이 격리 보장을 뜻하지는 않는다.

코디네이터가 직접 고치면 다시 점검해야 한다. 조율하던 쪽이 수정에 손대면 그 변경은 아직 아무도 독립적으로 보지 않은 코드다.

이 도구가 해결하지 않는 것

교차 검수가 두 모델의 합의를 만들어 주지는 않는다. 반대쪽 모델도 틀릴 수 있고, 두 모델이 같은 맹점을 공유할 수도 있다. 이 스킬이 보장하는 것은 하나뿐이다 — 만든 쪽이 자기 것을 채점하지 않는다.

그리고 계획 검수는 계획이 있어야 의미가 있다. 무엇을 만들지 한 문장으로도 못 적는 상태라면, 검수를 붙이기 전에 요구사항 단계에서 시간을 더 쓰는 쪽이 맞다.