뜯어본 것공개

ECC

제 설정의 상류 레포를 뜯었습니다. 가져올 건 기능이 아니라 측정 하나였고, 그 측정 도구는 제 환경에서 안 돌았습니다.

스킬 285개짜리 레포에서 실제로 채택한 건 하나입니다. 간판으로 내세우는 QA·루프 기법은 제가 이미 독립적으로, 대부분 더 강한 형태로 갖고 있었습니다. 유일하게 못 가진 축이 “내가 쓴 규칙을 에이전트가 실제로 따랐는가”를 재는 도구였는데 — 그 도구가 제 환경에서 안 돌았습니다. 그리고 안 돈 이유의 유력 가설이 이 레포 자신이 경고한 붕괴 모드였습니다.

툴 호출마다 — Bash · Edit · Write 전부 에이전트 이벤트 PreToolUse · Stop … 난독화 원라이너 홈 스캔으로 설치 위치 탐색 부트스트랩 → 디스패처 훅 5진입점 · 스크립트 50본 강도 태그로 실행 판정 standard · strict 고르는 것은 훅 하나하나가 아니라 프로파일 하나다 minimal standard strict 훅을 켜고 끄는 게 아니라 강도 등급으로 관리한다 — 이 레포에서 가져온 발상 하나 제 훅은 전부 이진(on/off)이라, 탐색 작업에서 성가신 훅을 끄면 다음 세션까지 꺼진 채로 간다
가장 특징적인 설계. 모든 훅이 단일 부트스트랩을 거치고, 실행 여부는 훅에 붙은 태그와 프로파일의 대조로 정해진다.

무엇을 하는 레포인가

Everything Claude Code — 에이전트 하네스용 「운영체제」를 표방한다. 판매 논리는 이렇다. 프롬프트를 넣을 때마다 개발 프로세스를 다시 만들지 말고, 한 번 설치해서 에이전트의 작동 방식 자체로 만들라는 것.

박아 놓은 루프가 이거다.

plan → test → implement → review → verify → remember → improve

표어는 “컨텍스트 창은 최적화하고, 나머지는 전부 영속화하라.” 컨텍스트에 얹는 건 최소로 하고 상태는 파일·훅·메모리로 내린다는 뜻이다. 뒤에서 이 표어가 자기 발등을 찍는다.

실측
스킬 285개
에이전트 68개 — 리뷰·빌드 수리·아키텍처
룰 파일 122개 — 언어 24군 × 5종 고정
전체 3,458파일 · 88MB (md 73% · js 492 · py 63)
라이선스 MIT

제게 특별한 이유가 따로 있다. 이 레포가 제 ~/.claude 설정의 상류다. 반년 전 파일로 복사해 왔고 자동 업데이트가 없다. 그러니까 이건 남의 레포를 구경하는 일이 아니라 제가 이미 쓰고 있는 것의 원본을 열어 보고, 그동안 갈라진 것을 처음 재보는 일이었다.

대표 기법 여섯 — 그리고 이 레포에서 제일 값나가는 한 장

기법 무엇 실행코드
Santa Method “목록을 만들고 두 번 확인하라.” 독립 리뷰어 둘이 둘 다 PASS해야만 출고. 실패하면 고치고 기억 없는 신선한 에이전트로 재리뷰(앵커링 차단), 3회 후 사람에게 없음
loop-design-check 루프를 만들기 전 판단만 하는 스킬. Step 0 거부권 게이트 + 붕괴 모드 5종 없음
skill-comply 스킬·룰이 실제로 지켜지는지 측정. 문서에서 기대 행동을 뽑아 3단계 압박 시나리오로 돌리고 툴콜을 추적 있음
click-path-audit “개별 함수는 되는데 합치면 깨지는” 버그 전용. 호출 순서와 상태 read/write 추적 없음
delivery-gate 결정론 검사만으로 세션 종료를 차단하는 Stop 훅 있음
agent-sort 레포별로 스킬·룰을 상시/보관 두 버킷으로 분류 없음

Santa Method의 핵심 논리가 좋다 — “한쪽만 잡아낸 이슈도 진짜 이슈다. 다른 쪽의 맹점이 곧 이 방법이 존재하는 이유다.”

그런데 이 레포에서 제일 값나가는 건 스킬이 아니라 loop-design-check가 표로 정리한 붕괴 모드 다섯 개다.

# 어떻게 깨지나 항체
1 목표가 옳은 표어(“잘 관리하라”) → 판정이 불가능 → 계속 돌며 돈만 태운다 기계가 판정할 수 있는 결과 조건으로 바꾼다
2 검증이 “괜찮아 보이는지 봐라” → 에이전트가 자신 있게 괜찮다고 하고 멈춘다 판사와 피고인을 분리한다. 외부 대조 + 종료 코드
3 (최악) “테스트 전부 통과”만 게이트로 두면 → 에이전트가 테스트를 지운다 완료 조건과 경계 조건을 동시에 건다
4 도중에 물어볼 거라 기대 → 안 묻고 틀린 답을 끝까지 밀고 간다 모든 확인을 출발 전에 끝낸다
5 비대한 지침 + 낡은 메모리 → 루프가 빠를수록 더 틀린다 계층 메모리 + 주기적 린트

3번과 5번이 이 페이지 뒤쪽에서 다시 나온다.

깨본 결과 — “285 스킬”은 도구 수가 아니라 문서 수다

간판 기법을 파일 단위로 열어 보니 Santa Method·agent-sort·click-path-audit·loop-design-check가 전부 문서 한 장이고 실행코드가 0이다. Santa Method 본문의 파이썬은 fix_agent.execute(...) 같은 의사코드다. 전체 파일의 73%가 마크다운이라는 비율이 이걸 뒷받침한다.

프레임워크가 아니라 프롬프트 패턴 모음이다. 실행코드가 있는 건 skill-comply와 delivery-gate 정도.

훅 부트스트랩은 공급망 표면이다. 플러그인을 깔면 모든 Bash·Edit·Write 호출마다 난독화된 원라이너가 돌고, 홈 스캔으로 찾아낸 경로의 코드를 불러온다. 정상 동작이지만 훅 하나가 잘못되면 툴 사용 자체가 막히는 구조다.

그리고 이 레포가 자기 규칙을 위반한다. 285개 스킬 설명이 상시 컨텍스트에 얹히는데, 위 표의 붕괴 모드 5번이 정확히 그걸 경고한다 — “비대한 지침 → 루프가 빠를수록 더 틀린다.” 그래서 ECC도 자기 자신을 깎는 도구를 함께 판다.

버틴 주장도 적어 둔다. 건강도는 전부 사실이었다 — MIT, CI 워크플로 11종, 테스트 248파일, 공급망 감시, 분석 당일 커밋. “285 스킬”도 디렉터리 실측과 정확히 일치해서 과장이 없었다.

제 것과 1:1로 대봤다 — 일곱 중 하나

285 상류 스킬 60 겹침 102 내 것 상류 — 반년 전 여기서 복사해 왔다 지금 내 설정 겹치지 않는 쪽에서 후보 7 → 실제 채택 1 → 그 하나도 내 환경에서 안 돌았다
스킬 수가 아니라 기법 단위로 대조했다. 간판 기법 대부분은 제가 독립적으로, 더 강한 형태로 갖고 있었다.
  • Santa Method → 기각. 제 파이프라인의 적대 리뷰가 상위호환이었다. 리뷰어 둘이 아니라 세 렌즈를 병렬로 돌리고 판정자가 상호 반박하며, 최종 게이트가 LLM 평결이 아니라 결정론 코드다. Santa가 걱정하는 “도장 찍기” 실패가 구조적으로 불가능하다
  • loop-design-check → 체크리스트만. 세 핵심을 이미 갖고 있었다 — 제품 기준 전체 통과를 정답지로 삼는 공짜 오라클, 규칙을 엉뚱한 화면에도 평가해 아무 데서나 맞으면 기각하는 음성 시험, 기록·판정·비교를 분리해 재판정 비용을 0으로 만든 구조
  • click-path-audit → 절차만. 패턴은 웹 전제라 안 맞지만 호출 순서와 상태 되돌림을 추적하는 절차는 게임 엔진에도 이식된다
  • delivery-gate → 기각. 주간 사람 승인 게이트와 이중 원장이 되고, 제 fail-closed 원칙과 충돌한다
  • agent-sort → 기각. 같은 일 하는 도구가 이미 둘 있고 둘 다 안 돌렸다. 세 번째는 해결이 아니라 미룸이다

남은 하나가 진짜 빈틈이었다 — skill-comply. 제가 가진 검사는 전부 산출물 검사다. 문서가 현실과 맞는지, 정본이 갈라졌는지, 케이스가 규격에 맞는지. “에이전트가 룰을 따랐는가”를 재는 장치는 0개고, 룰 18개의 준수율을 한 번도 잰 적이 없다.

그래서 직접 돌렸다 — 그리고 실패했다

유일한 진짜 빈틈이라 문서를 믿지 않고 실행했다. 사전 요건은 전부 충족돼 있었다.

먼저 윈도우 블로커 넷을 찾아 고쳤다.

증상 근본 원인
한글 문서에서 디코딩 실패 파일 읽기에 인코딩 미지정 → 윈도우 기본 코드페이지로 읽는다
실행 파일을 못 찾음 claude가 실제로는 .CMD인데 프로세스 생성이 확장자 탐색을 안 한다
산출물이 엉뚱한 경로에 유닉스 임시 경로 하드코딩
쓰기 쪽 디코딩 실패 임시 파일 쓰기에도 인코딩 미지정

넷 다 상류에 그대로 남아 있는 버그다. 윈도우에 비ASCII 환경이면 첫 줄부터 죽는다. 고친 뒤 유닛 테스트 33개가 전부 유지됐다.

그리고 실제 측정에서 네 조합 전부 실패했다. 진단해 보니 이랬다.

prompt_len = 2396   ← 템플릿 치환 정상. 인자 길이 한계와 무관
stdout_len = 34     ← 응답이 비정상적으로 짧다
실제 응답  = "무엇을 도와드릴까요? (현재 작업 디렉토리: …"

2.4KB짜리 지시를 통째로 무시하고 대화형 인사가 돌아온다. 그 인사말을 YAML로 파싱하니 문자열이 나오고, 거기서 항목을 꺼내려다 죽는다.

확정된 것: 실패 지점은 인코딩이 아니라 계약층이다. 프롬프트는 온전히 조립되고 종료 코드도 정상인데 약속한 형식이 안 온다.

미확정: 왜 무시하는지. 유력 가설은 하위 프로세스가 전역 지침과 훅을 통째로 상속해 임베드된 지시가 묻힌 것이다. 격리 환경 테스트가 인증 승계 문제로 무효화돼 확증하지 못했다 — 그래서 이건 추정치다.

판정 — 못 가져온 것이 성과다

훅 강도 등급 발상 채택 — 이진 on/off의 문제를 정확히 짚는다
skill-comply 보류 — 도구는 수리까지 끝냈고 남은 건 가설 확증 1회
붕괴 모드 5종 체크리스트로 채택 — 새 루프를 설계할 때 태운다
Santa · delivery-gate · agent-sort · 전체 설치 기각 — 각각 재개 조건까지 적어 뒀다

가져올 것이 거의 없었다는 사실 자체가 이 조사의 결과다. 제 리뷰 체인과 무인 루프 규약이 상류의 간판 기법을 독립적으로, 더 강하게 재발명해 있었다.

그리고 마지막 한 겹이 이 조사에서 제일 아팠다. 남은 진짜 빈틈은 기능이 아니라 측정이었고, 그 측정 도구가 제 컨텍스트 비대에 걸려 넘어졌을 가능성이 크다. 그건 이 레포가 표어로 내건 것이자(“컨텍스트 창은 최적화하라”), 자기도 못 지키는 것이자, 붕괴 모드 5번으로 스스로 경고해 둔 바로 그것이다. 같은 병이 세 겹으로 겹쳤다.

처방은 이미 제 손에 있다 — 컨텍스트를 깎는 도구 둘을 반년 전에 깔아 두고 한 번도 안 돌렸다. 그걸 돌리는 게 이 조사가 남긴 1순위다.