ECC
제 설정의 상류 레포를 뜯었습니다. 가져올 건 기능이 아니라 측정 하나였고, 그 측정 도구는 제 환경에서 안 돌았습니다.
스킬 285개짜리 레포에서 실제로 채택한 건 하나입니다. 간판으로 내세우는 QA·루프 기법은 제가 이미 독립적으로, 대부분 더 강한 형태로 갖고 있었습니다. 유일하게 못 가진 축이 “내가 쓴 규칙을 에이전트가 실제로 따랐는가”를 재는 도구였는데 — 그 도구가 제 환경에서 안 돌았습니다. 그리고 안 돈 이유의 유력 가설이 이 레포 자신이 경고한 붕괴 모드였습니다.
무엇을 하는 레포인가
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로 대봤다 — 일곱 중 하나
- 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순위다.