서론 — 복사가 통하지 않는 2가지 이유

Claude Code에게 "멋대로 진행하지 마세요", "삭제하기 전에 확인해 주세요"라고 CLAUDE.md에 적어두었는데도, 지켜지지 않았던 경험이 있으신가요? 그렇다면 잘 만들어진 타인의 CLAUDE.md를 복사하면 해결될까요? —— 이번에는 자신의 작업 흐름과 맞지 않게 됩니다.

이 두 가지는 서로 다른 실패입니다. 전자는 규칙이 지켜질 수 있는 구조로 되어 있지 않은 문제이고, 후자는 무엇을 승인제로 만들고 싶은지에 대한 리스크 감각이 사람마다 다른 문제입니다. 그리고 타인의 규칙 본체를 복사하는 것은 두 문제 모두 해결하지 못합니다.

전용할 수 있는 것은 내용이 아니라 **설계의 패턴 (Design Pattern)**입니다. 구체적으로는,

• "언제"를 기준으로 삼는 트리거 구조 (지켜지는 형태로 만들기)
• 리스크에 비례하는 승인 입도 (자신의 감각에 맞추는 차원)
• 규칙이 부패하지 않게 하는 운용 절차 (만들기 → 검증하기 → 기록하기)

이 3가지입니다. 이 기사에서는 체크리스트형 규칙으로 한 번 실패했던 필자가, 다시 만들면서 도달한 이 패턴을 공유합니다. 규칙의 내용은 필자의 환경 예시로서 인용하지만, 가져가야 할 것은 패턴입니다.

참고로 본 기사는 시리즈의 첫 번째(규칙 설계 편)입니다. 후속편으로 ②토큰 절감 편(지연 로딩과 hook 주입) · ③리뷰 위임 편(서브 에이전트 리뷰)을 예정하고 있으나, 집필은 이제부터 시작입니다.

1. 실패한 구 방식 — 체크리스트형의 모든 규칙 상주

처음 만든 규칙 세트는 "액션 전 체크리스트" 방식이었습니다. 지켜줬으면 하는 사항을 전부 나열하고, "행동하기 전에 이 체크리스트를 확인할 것"이라고 CLAUDE.md에 상주시키는 형태입니다.

결과는 부분적으로만 기능했습니다. 어떤 장면에서는 확인해 주지만, 다른 장면에서는 그냥 지나칩니다. 규칙의 내용을 충실히 채워도 개선되지 않았고, 오히려 길어질수록 개별 항목의 존재감이 옅어져 갔습니다.

돌이켜보면 원인은 내용이 아니라 구조에 있었습니다. 체크리스트는 "언제 적용할지"를 읽는 이의 판단에 통째로 맡기고 있습니다. 모델은 작업이 한창 진행 중인 상황에서, 지금 직면한 상황이 리스트 내의 어떤 항목에 대응하는지를 매번 스스로 대조해야 합니다. 이 대조가 일어날지 여부가 운에 맡겨져 있었던 것입니다.

인간 신입 사원에게 주는 작업 매뉴얼에서도 같은 일이 일어납니다. "주의사항 100연발"은 읽히지 않지만, "삭제하기 전에 이 페이지를 열 것"은 읽힙니다. 규칙에 필요한 것은 내용의 망라성보다 먼저, 발화 조건의 명확성이었습니다.

2. 지켜지는 형태로 만들기 — "언제"로 장을 나누기

그래서 다시 만든 규칙 세트는, 트리거(~하기 전 / ~했을 때)를 그대로 장절의 제목으로 만드는 구조로 했습니다. 현재의 장 구성은 다음과 같습니다.

0. 규칙을 정의·변경하려고 할 때
1. 작업의 선언·준비
1.1 다단계 작업을 시작하기 전
...

제목을 훑어보는 것만으로 "어느 순간에 어떤 규칙이 작동하는가"를 알 수 있습니다. 작업의 라이프사이클(준비 → 판단 → 조작 → 문제 → 완료)에 따라 나열되어 있으므로, 모델에게도 인간에게도 상황과 규칙의 대응이 대조가 아닌 **참조 (Reference)**가 됩니다.

또 다른 요소는 이층 구조입니다. CLAUDE.md 본체에는 각 절의 "요점(트리거 시의 행동과 승인의 무게)"을 2~4줄만 적고, 경계 판단·예외·출력 포맷 같은 상세 내용은 rules/X.Y-xxx.md라는 개별 파일로 나누어, 트리거에 해당했을 때 Read 한 다음에 행동한다는 규약으로 하고 있습니다. 예를 들어 CLAUDE.md 측의 1절은 이 정도 분량입니다.

4.3 작업 중에 스코프 외의 문제·궁금한 점을 발견했을 때

"발견·보고는 하되 수정은 하지 않는다"를 기본으로 한다. 중대도에 따라 보고 타이밍을 바꾼다 (중대: 즉시 중단·보고, 중등도: 발견 시점에서 보고, 경미: 완료 후 한꺼번에 보고. 망설여질 경우 중등도로 처리).

→ rules/4.3-out-of-scope.md

상주하는 것은 제목과 요점뿐이므로 컨텍스트를 압박하지 않으며, 상세 내용은 필요한 순간에 필요한 1개 파일만 읽힙니다 (이 지연 로딩화와 토큰 절감의 경위, 그리고 "Read 해 주는 것" 자체를 hook으로 보강하는 메커니즘은 시리즈 ②에서 다룰 예정입니다).

3. 자신에게 맞추는 차원 — 승인의 입도 3종

"언제"를 고정했다면, 다음은 "어느 정도로 멈출 것인가"입니다. 이 부분이 서두에서 언급한 자신의 리스크 감각에 맞추는 차원입니다.

모든 규칙의 공통 어휘로서, 승인의 무게를 3종류로만 정의하고 있습니다.

각 규칙은 요점 안에서 "이 상황은 명시적 승인", "이것은 방향 수정 대기"와 같이 입도를 지정합니다. 포인트는 리스크와 승인의 무게를 비례시키는 것입니다. 모든 것을 명시적 승인으로 설정하면 확인 지옥에 빠져 작업이 진행되지 않고, 사용자 측의 승인도 대충 이루어져 형식화됩니다. 그래서 각 규칙에 예외·간략화 규정을 분산하여 심어두었습니다.

• 되돌리는 작업(rework)이 경미한 가정(기준: 1개 파일 이내 및 10행 이내)은 승인이 불필요하지만, 가정에 대한 명시는 한다.
• 읽기 전용 명령에 대한 사전 설명은 1문장으로 간략화해도 된다.
• 스코프 축소 방향은 방향 수정 대기로 충분하다 (확대 방향은 명시적 승인).
• 동일 파일 내의 여러 편집은, 전체를 열거한 "편집 세트"를 일괄 제시하여 승인을 1회로 통합할 수 있다.

어떤 조작을 명시적 승인으로 둘지, "경미함"의 기준을 어디에 설정할지는 바로 사람마다 다른 부분입니다. 입도의 어휘를 3종으로 고정해 두면, 이 조정은 "이 규칙의 승인을 명시적 승인에서 방향 수정 대기로 낮춘다"라는 단 한 단어의 교체만으로 끝납니다. 타인의 규칙 세트가 맞지 않는 정체는 대개 이 감각의 차이이므로, 어휘만 가져와서 자신의 값을 넣는 것이 지름길입니다.

4. 규칙 1개의 실례

상세 파일 측의 작성법도 1개만 실례를 보여드리겠습니다. 모든 규칙은 공통 템플릿(목적 → 적용 범위 → 상세 규칙 → 예시 → 관련 규칙)을 따릅니다. 앞서 언급한 4.3(스코프 외 발견)의 상세 파일 골격은 다음과 같습니다.

목적: 작업 범위를 멋대로 넓히지 않는 것과, 발견한 문제를 묵살하지 않는 것의 양립. "덤으로 고치기"도 "모른 척 넘어가기"도 방지 -
적용 범위: 스코프 외의 버그·개선 여지·불일치·보안 리스크 발견 시. 오타(typo) 등 1행 수정은 대상 외 (수정 후 완료 보고 시 한마디 언급) -
상세 규칙: "발견·보고하되 수정하지 않는다"를 원칙으로 하며, 중요도에 따라 보고 타이밍을 변경한다 (경미=완료 후 모아서／중간=발견 시점／중대=즉시 중단. 망설여지면 중간). 보고 포맷도 고정:

【스코프 외 발견】
- 위치: <파일 경로:행 번호>
- 내용: <무엇이 문제인가>
...

예시: 좋은 예(완료 보고에 모아서 열거)와 나쁜 예("덤으로 null 체크도 추가해 두었습니다"／묵살)를 쌍으로 기재 -
관련 규칙: 보고 후 사용자가 수정을 지시하면, 그것은 스코프 변경이므로 2.3으로 연결한다——라는 규칙 간의 인계를 명기

"멋대로 고치지 마"라는 한마디로 끝날 법한 규범이라도, 보고 타이밍·포맷·경계(어디부터가 "경미"인가)·다음 규칙으로의 연결까지 구체화하면 동작이 안정적으로 재현됩니다. 예시(좋은 예·나쁜 예)는 특히 효과적입니다.

5. 운용 편 — 규칙을 부패시키지 않기

여기까지가 "만드는" 틀입니다. 하지만 규칙 세트는 만들고 끝나는 것이 아니라, 운용 과정에서 늘어나고 변하며, 방치하면 모순과 진부화로 인해 부패합니다. 필자의 환경에서는 "만들기 → 검증하기 → 기록하기" 사이클을 틀로 삼고 있습니다. 스스로 규칙을 책정하고 계속 운용하기 위한 부분이며, 복사만으로는 결코 얻을 수 없는 것이 바로 이 부분입니다.

5.1 규칙의 규칙 (메타 룰)

장 구성의 서두에 "0. 규칙을 정의·변경하려고 할 때"라는 메타 룰을 배치합니다. 신규 규칙은 목적·트리거·상세·통제 관점의 명시와 템플릿 준수를 필수 사항으로 하며, 추가하기 전에 기존 규칙과의 중복·충돌·우선순위의 모호함·상호 참조 누락을 체크합니다.

또 하나 중요한 것은, 규칙·hook·permissions와 같은 통제 기구 자체의 변경에는 통상적인 경우보다 더 무거운 승인을 부과한다는 규칙(3.6)입니다. 변경을 완화 방향(허가 추가·체크 삭제 등)과 강화 방향으로 분류하며, 완화는 반드시 명시적 승인을 거치고 망설여지면 완화로 취급합니다. AI 스스로가 "작업을 원활하게 하기 위해 자신의 제약을 완화한다"라는 제안을 하는 경우에는 그 동기까지 명시하도록 의무화하고 있습니다. 규칙 세트의 실효성은 이 자기참조적인 단계에서 담보됩니다.

5.2 허점 찾는 법 — 통제 관점 8축

규칙을 추가하다 보면 "이 세트에 어디 구멍이 있지 않을까?"라는 생각이 들기 시작합니다. 포괄성(Comprehensiveness)을 단순히 직관이 아닌 검증을 통해 확보하기 위해, 저는 평가 축을 도출하여 사용하고 있습니다. AI에게 위임하는 구성 요소는 "행위(Action)", "정보(Information)", "통제계(Control System, 규칙이나 기록이라는 메커니즘 자체)"의 3가지로 수렴된다는 분해를 바탕으로 8가지 관점을 도출합니다.

검증은 세 가지 축으로 이루어집니다. 첫째, 모든 규칙을 관점에 매핑하여 "어떤 관점에도 포함되지 않는 규칙"과 "규칙이 하나도 없는 관점"을 찾는 양방향 매핑(Bidirectional Mapping), 둘째, 실제로 발생한 아찔한 상황(Near-miss)을 "어떤 관점의 결여 때문인가"로 설명하는 인시던트 드리븐(Incident-driven) 방식, 셋째, STRIDE 등 기존 분류 체계와의 대조입니다. 8가지 관점으로 설명할 수 없는 실패가 발생하면 관점 자체를 재검토합니다.

축은 직접 만들지 않아도 상관없습니다. 중요한 것은 "규칙을 추가하는 근거"와 "충분하다는 것을 확인하는 방법"을 그때그때의 직관으로부터 분리하는 것입니다.

5.3 대장(Ledger)으로 기록하기

마지막은 기록입니다. 규칙의 실체(~/.claude/ 하위 디렉토리)와는 별개로, 기록용 리포지토리에서 3가지 대장을 관리하고 있습니다.

• Catalog — 현재 무엇이 있는가 (규칙, hook, 스킬 등의 현황 목록)
• CoverageMatrix — 8가지 관점과 구현의 매핑 (구멍에 대한 검증 결과)
• WorkLog — 무엇을, 왜 변경했는가 (경위)

규칙을 변경할 때마다 대장을 동기화해야 하는 의무 또한 그 자체로 하나의 규칙이 됩니다. 몇 달 후의 내가 "왜 이 규칙은 이렇게 되어 있는가"를 추적할 수 있을지는 이 경위의 기록에 달려 있습니다. 또한, 글로벌 설정 측에서 특정 프로젝트를 참조하지 않는다(참조는 항상 기록 측 $\rightarrow$ 설정 측의 단방향)는 원칙을 지키면 설정의 이식성(Portability)을 유지할 수 있습니다.

이 3가지 대장과 리뷰 기록의 실물(집필 시점의 스냅샷)은 부록 리포지토리에 공개되어 있습니다.

마치며 — 가져가야 할 것은 패턴(Pattern)

이 구조로 바꾼 뒤로, "승인 없이 파괴적인 작업이 실행된다"거나 "요청했던 판단이 무시된다"는 상황은 눈에 띄게 줄었습니다. 반면, 텍스트 규약만으로는 "상세 파일을 읽지 않고 동작한다"거나 "긴 세션에서 규칙의 존재감이 희미해진다"는 리스크가 원리적으로 남습니다. 그 부분은 hook을 통한 메커니즘 측면의 보강(시리즈 ②)과, 결과물을 다른 시각으로 검증하는 서브 에이전트 리뷰(Sub-agent Review, 시리즈 ③)로 메우고 있습니다.

반복해서 말씀드리지만, 이 글의 규칙 본문을 그대로 복사하지 마십시오. 가져가야 할 것은 3가지 패턴입니다.

• 트리거로 장(Chapter)을 구성하라 — "언제"를 소제목으로 삼고, 요점 상주 + 상세 내용 지연(Detail Latency)의 2층 구조로 만든다.
• 승인 단위를 3단어로 고정하라 — 리스크와의 비례 관계는 자신의 감각에 따라 조정한다.
• 운용 절차를 가져라 — 메타 규칙(Meta-rule)으로 증축에 절차를 부여하고(만들기), 구멍은 검증 축으로 찾으며(검증하기), 경위는 대장에 남겨 미래의 내가 추적할 수 있게 한다(기록하기).

참고로, 공개된 규칙 및 hook 세트(설정 스냅샷)는 집필 시점의 스냅샷입니다(저자의 현재 환경은 그 이후에도 업데이트되었으며, 공개물에는 반영되지 않았습니다). 이는 어디까지나 패턴을 검토하기 위한 베이스라인이며, 보안과 관련된 부분(hook의 탐지 패턴, permissions)은 각자의 환경과 프로젝트 리스크에 맞춰 정교하게 다듬어야 합니다.

첫 번째 규칙은 자신이 실제로 아찔했던 순간 — "그때 멋대로 삭제되었다", "그 확인이 필요했다" — 에서부터 쓰기 시작하는 것이 가장 빠릅니다. 그것이 서두에서 언급한 "자신에게 맞는 규칙"의 출발점이 됩니다.

Discussion