Claude Code의 사고를 제로로 만들기──ID 기반의 규칙 관리 설계

「금지입니다」라고 써도 사고가 줄어들지 않는 이유

CLAUDE.md에 금지 사항을 작성했다고 가정해 보자.

## 금지 작업
- 운영 DB의 drop 작업은 금지
- 사용자 개인정보를 로그에 출력하지 말 것
...

이렇게 하면 사고가 제로가 될까? 되지 않는다.

이유는 두 가지가 있다.

첫 번째는, 예외가 반드시 발생하기 때문이다.

「운영 DB의 drop 금지」라고 써 놓아도, 마이그레이션 (Migration) 작업에서 반드시 drop이 필요한 상황이 발생한다. 그때 어떻게 할 것인가? 채팅으로 「이번만 허가합니다」라고 전달한다. Claude는 그 대화 속에서는 따른다. 하지만 그 주고받은 내용은 남지 않는다.

다음 세션에서 Claude는 「drop 금지」만을 읽는다. 왜 지난번에 drop이 허가되었는지, 그 문맥을 알지 못한다.

두 번째는, 예외 기록이 없으면 「왜 허가했는지」를 나중에 추적할 수 없기 때문이다.

3개월 후, 로그를 보고 「여기서 drop 작업이 실행되었다」는 것을 깨달았을 때, 그것이 의도적인 예외였는지, 규칙 무시로 인한 사고였는지 판단할 수 없다. 기록이 없다면 구별할 방법이 없다.

이 문제를 해결하는 것이 「ID 기반의 규칙 관리」다.

훅 (Hook)을 통해 기계적으로 조작을 차단하는 설계와는 달리, 이것은 CLAUDE.md의 규칙 자체를 구조화하는 설계다.

TL;DR

• 금지 규칙에 ID를 부여하고, 카테고리별로 관리한다
• 예외 승인은 「D001을 예외로 허가 (이유)」와 같은 형태로 반드시 ID와 세트로 기록한다
• 「ID 기록이 없는 조작 = 사고」라는 등식이 성립함으로써, 사고와 의도적인 조작을 나중에 판별할 수 있다

ID 기반 관리의 메커니즘

규칙에 ID를 붙이는 설계다. ID 형식은 카테고리 + 번호로 한다.

카테고리를 나누는 이유

금지 규칙을 「무조건 하나의 리스트에 넣는」 접근 방식의 문제는, 규칙의 성질이 혼재된다는 점이다.

예를 들어 다음 세 가지를 같은 리스트에 나열하면, 우선순위도 예외 조건도 다른데 동일하게 취급된다:

• 「운영 DB의 drop 금지」── 실행하면 되돌릴 수 없는 조작
• 「개인정보를 로그에 출력 금지」── 외부로 나가는 순간 문제가 되는 정보
• 「PR 리뷰 없는 main 머지 금지」── 프로세스 품질 규칙

이것들은 카테고리가 다르다. 카테고리를 나눔으로써 「왜 이 규칙이 존재하는가」를 한눈에 알 수 있고, 예외 승인의 판단 기준도 달라진다.

카테고리 설계 예시

카테고리	대상	예
D (Destructive)	파괴적·비가역적 조작	운영 DB의 drop, 파일 강제 삭제
...

• D계열: 실행하면 되돌릴 수 없는 조작. 예외 승인은 「왜 이번에만 필요한가」에 대한 기술적 이유가 요구된다.
• P계열: 외부로 나가는 순간 문제가 되는 정보. 예외 승인은 원칙적으로 인정하지 않는다 (또는 인정할 경우 명확한 업무상의 근거가 필요하다).
• H계열: 품질과 속도의 트레이드오프 (Trade-off). 예외 승인은 「이번 스코프에서는 왜 생략 가능한가」에 대한 설명이 필요하다.

CLAUDE.md에 쓰는 법

각 카테고리의 규칙은 테이블 형식으로 ID와 조작과 이유를 관리한다.

## 파괴적 조작 안전 규칙 (Destructive)
| ID | 조작 | 이유 |
|----|------|------|
...

## 공개 콘텐츠 안전 규칙 (Publication)
| ID | 금지 사항 | 이유 |
|----|---------|------|
...

## 하네스 적용 규칙 (Harness)
| ID | 규칙 | 적용 조건 |
|----|-------|---------|
...

각 카테고리의 끝에 「예외를 인정할 경우에는 ○○와 같이 ID로 명시한다」라는 한 줄을 반드시 넣는 것이 포인트다. 이 한 줄이 없으면, Claude는 예외 승인을 받았을 때 「이 규칙의 오버라이드 (Override)로 해석해도 되는가」를 판단할 수 없다.

예외 승인 패턴

ID가 있음으로써 예외를 구조화할 수 있다.

패턴 1: 채팅 지시로서 예외를 전달

「D001을 예외로 허가. 마이그레이션 작업을 위해 test 스키마의 drop이 필요함.」

Claude는 이 지시를 규칙의 오버라이드로 인식한다. 왜 오버라이드되었는지에 대한 문맥이 「마이그레이션 작업, test 스키마 한정」으로서 대화에 남는다.

패턴 2: 커밋 메시지에 기록

[chore] D001 예외 적용: test 스키마를 drop (v2 마이그레이션 준비)

git 로그를 보면 어떤 규칙이, 왜, 언제 예외로 처리되었는지 알 수 있다.

패턴 3: CLAUDE.md 자체에 임시 예외를 작성

## 임시 예외 (2025-06-01까지)
- D001을 예외로 허용 (스테이징 환경에서의 마이그레이션 테스트를 위해)

기한을 명시함으로써 예외가 영구화되는 것을 방지한다.

「ID 기록이 없는 조작 = 사고」라는 등식

역설적으로 들릴 수도 있지만, 「예외 승인 기록이 있다」는 사실 덕분에 통상 규칙의 신뢰성이 올라간다.

예외 승인 기록이 없는 경우:

• Claude가 규칙을 위반했다 → 사고
• 인간이 예외를 승인했다 → 기록 없음, 나중에 구별 불가능

예외 승인을 ID로 기록하는 경우:

• Claude가 규칙을 위반했다 → 사고 (ID 기록이 없으므로 판별 가능)
• 인간이 예외를 승인했다 → ID와 함께 기록되어, 나중에 의도를 확인할 수 있음

「ID 기록이 없는 조작 = 사고」라는 등식이 성립한다. 이것이 ID 기반 관리의 본질이다. 후크(Hook)가 물리적으로 차단하는 레이어라면, ID 기반 관리는 「차단을 통과한 조작의 의도를 기록하는 레이어」다. 이 둘은 보완 관계에 있다.

ID가 너무 많아졌을 때의 리팩터링 (Refactoring)

운영을 지속하다 보면 ID가 비대해진다. D001D015, P001P010... 식으로 늘어나면 Claude가 전체를 파악하기 어려워진다.

비대화의 징후:

• 동일한 의도의 규칙이 여러 ID에 분산되어 있다
• 지난 3개월 동안 한 번도 참조되지 않은 ID가 있다
• 예외 승인 로그에 해당 ID가 한 번도 등장하지 않는다

통합 기준: 「같은 이유로 예외 승인을 받는가」

# ❌ 비대해진 상태 (동일한 의도가 3개의 ID로 분산)
| D007 | 운영 DB의 drop 실행 | 데이터 소실 |
| D008 | 운영 DB의 truncate 실행 | 데이터 소실 |
...

같은 이유로 예외를 인정한다면 하나의 ID로 묶을 수 있다. 이유가 다르다면 별도의 ID를 유지하는 것이 정당하다.

또한, 한 번도 사용되지 않은 ID는 삭제를 검토한다. 「나중에 필요할지도 모른다」는 이유로 남겨두면, 실제 리스크와 가공의 리스크가 혼재된 규칙 세트가 된다.

정기 리뷰 타이밍:

• 월간: 예외 승인 로그를 확인하고, 예외가 자주 인정되는 ID는 규칙 자체를 재검토한다
• 분기별: 사용되지 않는 ID를 정리(Inventory)한다

요약

• 금지 규칙은 ID를 부여하고, 카테고리(D/P/H)로 분류하여 관리한다
• 예외 승인은 「ID를 명시하고 이유와 함께 기록하는 것」을 필수화한다
• 「ID 기록이 없는 조작 = 사고」라는 등식을 성립시켜 나중에 판별할 수 있게 한다
• ID가 너무 많아지면 「같은 이유로 예외가 인정되는가」를 기준으로 통합한다

후크로 조작을 물리적으로 차단하는 설계와 이 ID 기반의 규칙 명문화 설계는 보완 관계에 있다. 후크가 막지 못한 조작의 의도를 ID가 기록한다.

하네스 설계의 전체 모습은 Claude Code 하네스 엔지니어링 실전 Playbook에서 해설하고 있다.

감상이나 「이 케이스는 어떻게 하나요?」와 같은 질문은 댓글로 편하게 남겨주시면 감사하겠습니다. '좋아요'도 큰 힘이 됩니다.

필자 코멘트

Discussion