규칙 설계

규칙 설계

개요

설계 결정을 그대로 시스템에 넣을 수는 없다. 그 결정은 rule이라는 중간 형태를 거쳐야 검사와 강제로 이어질 수 있다.

이 문서는 좋은 rule을 어떻게 설계해야 하는지 설명한다.

rule의 역할은 단순하다.

설계 결정을 기계가 판단 가능한 문장으로 바꾸는 것

여기서 rule은 취향이나 코드 스타일이 아니다. 무엇이 합법 경로이고 무엇이 위반인지, 어떤 표면을 닫아야 하는지를 명확히 하는 장치다.

rule은 이름이나 code로 식별 가능해야 한다. 그래야 validator, runtime guard, review, 문서가 같은 대상을 가리킬 수 있다.

무엇에 적용되는 rule인지 분명해야 한다.

무엇이 금지되는지 분명해야 한다. 추상적인 금지는 해석 차이를 키운다.

무엇을 써야 하는지도 같이 드러나야 한다. 금지만 있는 rule은 shortcut 추측을 부른다.

예외가 최소인지, 어떤 조건에서만 허용되는지 드러나야 한다. 예외가 불명확하면 rule은 바로 약해진다.

이런 rule은 문장으로는 그럴듯해도 validator와 enforcement로 이어지기 어렵다.

좋은 rule은 종종 결과보다 경로를 다룬다.

이런 rule이 중요한 이유는 결과가 맞아 보여도 잘못된 경로가 구조를 무너뜨리기 때문이다.

모든 policy가 rule이 되는 것은 아니다.

예를 들어 “UI는 의미 계층을 보존해야 한다"는 policy는 중요하다. 하지만 이것만으로는 검사할 수 없다. 이를 특정 렌더 경로, 특정 contract, 특정 금지 표면으로 좁혀야 rule이 된다.

harness는 어떤 우회 표면이 반복되는지 보여준다. rule design은 그 우회 표면을 검사 가능한 문장으로 압축하는 단계다.

즉 harness가 케이스를 식별한다면, rule design은 그 케이스를 시스템 언어로 바꾼다.

AI는 추상 policy보다 가까운 rule에 더 잘 반응한다.

그래서 AI 시대에는 좋은 rule design이 좋은 문서 스타일보다 더 중요해진다.

좋은 rule design은 다음을 만족한다.

rule은 설계 문장의 요약이 아니라, 설계를 시스템이 판정할 수 있게 만드는 중간 형식이다.