규칙 생명주기
개요
좋은 시스템은 규칙을 많이 갖는 시스템이 아니라, 규칙이 설계에서 실행까지 끊기지 않고 연결되는 시스템이다.
이 문서는 그 연결을 rule lifecycle이라는 관점에서 설명한다.
1. ADR: 설계 결정을 고정한다
출발점은 설계 결정이다. 중요한 것은 암묵적 합의가 아니라 외부화된 결정이다.
ADR은 다음을 분명히 해야 한다.
- 왜 이 경계가 필요한가
- 무엇을 허용하고 무엇을 금지하는가
- 어떤 예외를 인정하지 않는가
ADR이 약하면 이후 모든 단계가 흔들린다.
2. Rule: 결정을 검사 가능한 문장으로 바꾼다
설계 결정은 그대로는 검사하기 어렵다. 그래서 기계가 판단할 수 있는 규칙으로 변환해야 한다.
좋은 Rule의 조건:
- 대상이 명확하다
- 위반 조건이 분명하다
- 통과 조건이 명확하다
- 예외가 최소화되어 있다
3. Validator: 규칙을 실제로 검사한다
Rule이 문서에만 남아 있으면 다시 설명으로 퇴행한다. Validator가 있어야 규칙이 시스템에 참여한다.
Validator는 다음 질문에 답해야 한다.
- 지금 위반이 발생했는가
- 어디서 발생했는가
- 어떤 경로를 통해 발생했는가
4. Enforcement: 위반을 실패로 만든다
검사만으로는 부족하다. 위반이 실제로 실패하지 않으면 규칙은 다시 참고사항이 된다.
Enforcement는 다음 역할을 맡는다.
- 잘못된 경로 자체를 제거한다
- 남은 우회를 즉시 실패시킨다
- 환경별 편차를 줄인다
5. 피드백 루프: 실패를 수정 경로로 연결한다
좋은 통제는 막고 끝나지 않는다. 실패를 다음 수정 행동으로 연결해야 한다.
한 단계라도 빠지면 어떻게 되는가
ADR이 없으면
규칙은 산발적인 취향이 된다.
Rule이 약하면
검사기가 있어도 실질적 통제가 생기지 않는다.
Validator가 없으면
규칙은 문서에만 남는다.
Enforcement가 없으면
위반은 감지되지만 계속 실행된다.
피드백 루프가 없으면
실패는 불편한 장애로만 남고, 시스템은 다시 예외와 우회로 기운다.
책임 분리
이 생명주기는 역할을 분리한다.
- 사람 설계를 결정하고 경계를 정의한다
- 시스템 규칙을 검사하고 위반을 실패로 만든다
- 사람과 AI 허용된 경로 안에서 수정과 구현을 수행한다
핵심은 누구도 단독으로 전체 구조를 떠받치지 않는다는 점이다.
이 프로젝트에서의 위치
- failure mechanics와 continuity는 왜 이 흐름이 필요한지 설명한다
- rule design과 validator design은 이 생명주기의 가운데 두 단계를 더 구체적으로 푼다
- harness는 어떤 우회 표면이 반복되는지 식별한다
- enforcement는 그 우회를 어떤 방식으로 실패로 바꾸는지 다룬다
즉 rule lifecycle은 이 프로젝트 전체의 연결축이고, 뒤의 문서들은 이 흐름의 각 단계를 더 세밀하게 분해한다.
요약
설계가 실행에 참여하려면 다음 흐름이 필요하다.
