문제는 내 규칙이 나빴던 것이 아닙니다. 문제는 그 규칙들이 제대로 지켜지고 있는지 알 방법이 없었다는 점이었습니다.

나는 AI 어시스턴트를 위한 15가지 규칙을 가지고 있었습니다. "행동하기 전에 생각할 것." "질문하기 전에 컨텍스트를 확인할 것." "복잡한 작업 후에는 학습 내용을 기록할 것." 좋은 규칙들이었습니다. 중요한 규칙들이었습니다.

30번의 세션이 지난 후, 나는 마침내 확인해 보았습니다. 나의 "행동하기 전에 생각할 것"이라는 규칙은 단 한 번도(zero times) 지켜지지 않았습니다.

AI가 규칙을 무시했기 때문이 아닙니다. 그 규칙이 검증 가능한 제약 조건(verifiable constraint)이 아니라, 단지 하나의 바람(wish)이었기 때문입니다. 규칙에 실질적인 힘이 없었던 것입니다.

아무도 AI 설정에 적용하지 않은 TDD의 통찰

테스트 주도 개발 (TDD, Test-Driven Development)은 우리에게 혹독한 교훈을 가르쳐 주었습니다. 단언 (assertion)이 없는 요구사항은 요구사항이 아니다라는 점입니다. 항상 통과하는 테스트는 쓸모가 없습니다. 하지만 테스트가 없는 요구사항은 그저 바람일 뿐입니다.

모든 소프트웨어 팀은 이를 배웠습니다. CI 파이프라인이 이를 강제하고, 린터 (Linter)가 이를 체크합니다. 하지만 AI 설정 규칙은 어떤가요? 우리는 그것을 모니터에 붙여놓은 포스트잇처럼 작성합니다. 검증 메커니즘이 없는 선한 의도일 뿐이죠.

나는 내 규칙들이 모두 바람이었다는 것을 깨달았습니다. 단 하나도 예외 없이 말입니다.

해결책: 규칙 안에 단언(Assertion)을 내장하기

변경 전과 후를 비교해 보겠습니다:

# 변경 전 (바람):
Think before acting on any request.

...

그 [✓THINK]는 단순한 장식이 아닙니다. 그것은 동시에 두 가지 역할을 수행합니다:

1. AI를 위해: 이 마커는 "내가 생각했는가, 아니면 하지 않았는가?"라는 이진 액션 (binary action)을 생성합니다. 모호함이 없습니다.
2. 도구(tooling)를 위해: grep -c '\[✓THINK\]' transcript.jsonl 명령어가 건강 지표 (health metric)가 됩니다. AI가 필요하지 않습니다.

마커가 곧 단언 (assertion)입니다. grep은 테스트 러너 (test runner)입니다. 그리고 규칙 텍스트 자체가 사양 (specification)이 됩니다. 즉, 자기 완결적이며 스스로 검증 가능합니다.

3줄 아키텍처

전체 시스템은 세 줄의 로직으로 요약됩니다:

규칙 텍스트 (Rule text)     → 자체 성공 기준을 포함 ([✓MARKER])
트랜스크립트 (Transcript)    → 기계 판독 가능한 증거 (정규 표현식으로 계산 가능)
상태 스크립트 (Health script) → 기계적 검증 (AI 추론 불필요)

나는 config-health.py를 작성했습니다. 350줄의 Python 코드로, 의존성 없이 표준 라이브러리 (stdlib)만 사용했습니다. 이것은 Claude Code의 Stop hook으로 실행됩니다. 매 세션마다 다음과 같은 작업을 수행합니다:

1. 트랜스크립트(transcript)에서 규칙 마커([✓THINK], [✓CONTEXT], [✓DELIVERY])를 grep으로 검색합니다.
2. 실행률(execution rates)을 JSONL 로그에 기록합니다.
3. pending-verifications.md 파일을 관리합니다 — 준수되지 않은 규칙들은 대기(pending) 항목으로 표시됩니다.

이 스크립트는 절대 차단(block)하지 않습니다. 오직 보고만 합니다. 종료 코드(exit code)는 항상 0입니다. 하지만 이 스크립트가 생성하는 데이터는 동작을 변화시킵니다. 왜냐하면 다음 시작 시점에 pending-verifications.md를 읽기 때문입니다.

무엇이 변했는가

이것을 배포한 후, 저의 규칙 실행률은 "전혀 모르겠음" 상태에서 모든 세션에 걸쳐 추적 가능한 가시성(visibility)을 갖게 되었습니다. 여전히 가끔 규칙을 놓치기도 합니다. 하지만 이제는 언제 규칙을 놓쳤는지 알 수 있습니다. 대시보드는 정확히 어떤 규칙에 주의가 필요한지를 드러내 줍니다.

놀라운 점은 마커 그 자체가 AI의 행동 방식을 변화시켰다는 것입니다. [✓THINK]는 모호한 "문제를 고려하라"가 아니라, 출력해야 할 구체적인 대상인 구체적인 행동(concrete action)입니다. 무엇이 "완료"된 상태인지가 더 명확해졌기 때문에 AI는 이를 더 자주 수행합니다.

일반 원칙

내장된 성공 기준(success criterion)이 없는 모든 규칙은 소망(wish)일 뿐입니다. 소망은 실행되지 않습니다.

이 원칙은 AI 설정 그 이상에도 적용됩니다. 팀의 코드 리뷰 체크리스트인가요? 만약 "보안 문제 확인"에 검증 가능한 단계가 없다면, 그것은 실행되지 않고 있는 것입니다. 개인의 생산성 시스템인가요? 만약 "주간 목표 검토"가 측정 가능하지 않다면, 당신은 그것을 검토하고 있지 않은 것입니다.

검증 가능성(Verifiability)은 불신에 관한 것이 아닙니다. 의도(intention)와 증거(evidence) 사이의 루프를 닫는 것에 관한 것입니다.

직접 시도해 보세요

AI 설정에서 규칙 하나를 선택하세요. 검증 마커를 추가하세요. 그리고 그것을 카운트하기 위한 5줄의 grep 명령어를 작성하세요:

grep -c '\[✓YOUR_MARKER\]' ~/.claude/transcripts/*.jsonl

당신은 검증조차 하지 않을 10개의 새로운 규칙을 만드는 것보다, 이 grep 출력 결과로부터 더 많은 것을 배우게 될 것입니다.

_ config-health.py 스크립트는 Claude Code를 위한 이중 레이어 기계적 게이트인 delivery-gate의 일부입니다. MIT 라이선스입니다. 이 뒤에 숨겨진 방법론은 checkgrow에서 확인할 수 있습니다._