Rules as Operational Memory
이 문서는 CCAF Domain 3를 이해하기 위한 개념 설명용 노트다.
여기서는 규칙의 “구조”보다, 무엇을 rules로 만들고 왜 그것이 반복 판단을 줄이는가를 다룬다. 즉 rules를 단순한 선호 목록이 아니라, 반복되는 판단과 팀 규약을 외부화한 운영 기억(operational memory) 으로 이해하는 데 초점을 둔다.
왜 rules가 필요한가
Claude Code는 강력하지만, 매번 모든 판단을 처음부터 다시 하게 두면 비효율이 커진다.
예를 들어:
- 테스트를 언제 꼭 돌려야 하는지
- 어떤 파일은 직접 수정하면 안 되는지
- 어떤 변경은 반드시 리뷰가 필요한지
- 어떤 디렉토리는 별도 절차를 따라야 하는지
를 매번 대화에서 다시 설명하는 것은 비효율적이다.
이럴 때 rules가 필요하다.
즉 rules는 단순한 취향 저장소가 아니라,
반복되는 판단을 외부화해 재사용 가능하게 만드는 장치
다.
operational memory란 무엇인가
operational memory라는 말은 거창해 보이지만 뜻은 단순하다.
매번 새로 추론하지 않아도 되는 규칙과 기준을
지속적으로 참조 가능한 형태로 저장해 둔다는 뜻이다. 이 규칙들이 어디에 배치되고 어떤 우선순위로 적용되는지는 CLAUDE.md & Instruction Hierarchy에서 다룬다.
예를 들면:
- “이 저장소에서는 변경 후 반드시 테스트를 돌린다”
- “generated file은 직접 수정하지 않는다”
- “DB migration은 별도 검토 없이는 만들지 않는다”
- “UI 변경 시 스냅샷 테스트를 함께 확인한다”
이런 규칙은 한 번의 채팅으로 끝날 정보가 아니다.
작업이 반복될수록 계속 재사용되는 판단 기준이다.
즉 rules는 메모 보조가 아니라,
작업 운영을 안정화하는 기억 구조
라고 볼 수 있다.
무엇을 rules로 승격해야 하는가
모든 것을 규칙 파일로 만들 필요는 없다.
보통 rules로 승격할 가치가 있는 것은 아래와 같다.
- 자주 반복되는 판단
- 팀 전체가 공유해야 하는 기준
- 실수 비용이 큰 금지사항
- 검증/테스트/리뷰에 관한 루틴
- 특정 디렉토리나 시스템에 대한 주의사항
즉 rule로 만들 가치가 있는 정보는:
한 번의 팁이 아니라, 여러 번 재사용될 운영 기준
이다.
반대로 아래는 굳이 무겁게 rule로 만들지 않아도 되는 경우가 많다.
- 일회성 요청
- 특정 대화에만 해당하는 맥락
- 미묘한 취향 수준의 선호
- 아직 합의되지 않은 실험적 방식
스타일 선호와 운영 규칙은 어떻게 다른가
이 구분이 중요하다.
스타일 선호
- 답변 톤
- 주석 스타일
- 변수 이름 취향
- 문장 길이 선호
이런 것은 있으면 좋지만, 대개 시스템 안정성 자체를 좌우하지는 않는다.
운영 규칙
- 테스트를 언제 실행해야 하는가
- 어떤 파일은 수정 금지인가
- 어떤 작업은 반드시 승인/리뷰가 필요한가
- 어떤 변경은 특정 절차를 따라야 하는가
이런 것은 실제 결과 품질과 위험에 직접 연결된다.
즉 rule 파일이 강해지려면, 선호보다 운영 판단 기준 비중이 높아야 한다.
rules가 너무 커지면 왜 안 좋은가
규칙이 많으면 좋아 보이지만, 너무 비대해지면 오히려 중요한 규칙이 흐려진다.
문제가 되는 경우:
- 실제로 중요한 금지사항이 취향 규칙 속에 묻힘
- 오래된 규칙이 정리되지 않음
- 예외가 누적돼 구조가 불분명해짐
- 자주 쓰지 않는 내용이 핵심 규칙을 덮어버림
즉 rules는 많을수록 좋은 게 아니라,
자주 쓰이고 중요한 판단만 남아 있는 상태
가 더 좋다.
좋은 operational memory는 방대한 위키가 아니라, 실전에서 계속 효력을 가지는 압축된 기억에 가깝다.
왜 이게 harness engineering과 연결되는가
하니스의 목적 중 하나는
모델이 매번 같은 판단을 새로 발명하지 않게 만드는 것이다.
rules는 바로 그 역할을 한다.
- 반복 판단을 외부화하고
- 자주 필요한 제약을 고정하고
- 위험한 행동의 기준선을 만들고 (Hooks & Enforcement로 강제 가능)
- 작업 루프를 더 일관되게 만든다
즉 rules는 단순 문서가 아니라,
작업 하니스가 기억을 갖는 방식
이라고 볼 수 있다.
흔한 오해
“rules는 많을수록 좋다”
아니다. 중요한 규칙이 묻힐 수 있다.
“취향도 다 rules에 넣으면 된다”
그렇지 않다. 취향이 너무 많아지면 운영 규칙이 약해진다.
“rules는 프로젝트 문서의 다른 이름이다”
아니다. 핵심은 설명이 아니라 반복 판단의 외부화다.
한 문장 요약
Rules는 단순한 선호 목록이 아니라, Claude Code의 반복 판단을 외부화해 작업을 안정화하는 operational memory다.