실행 통제

하네스는 우회가 어디서 시작되는지 식별한다. 실행 통제는 그 우회를 실제 실패로 바꾼다.

하네스 파트에서 우회 패턴을 식별했다. 어떤 경로가 열려 있는지, 어디서 우회가 발생하는지를 봤다.

하지만 식별만으로는 경로가 닫히지 않는다. 규칙을 문서에 적어두는 것도, 패턴을 이름 붙이는 것도 경로를 막지 않는다. 경로는 여전히 열려 있다.

강제는 그 경로를 실제로 닫는다. 허용되지 않은 방식으로 코드를 작성하면 빌드가 실패하고, 허용되지 않은 방식으로 실행하면 즉시 중단되고, 테스트에서도 같은 경계가 작동한다.

강제의 네 원칙

이 파트 전체를 관통하는 원칙은 네 가지다.

합법 경로를 먼저 만든다. 막기 전에 대안이 있어야 한다. 합법 경로가 우회보다 짧고 쉬워야 한다. 그래야 AI도, 사람도 합법 경로를 선택한다.

실패를 늦추지 않는다. 문제가 발생한 시점과 실패가 발생하는 시점 사이의 간격이 길수록 수정 비용이 높아진다. 빌드 타임에서 잡을 수 있으면 런타임까지 미루지 않는다.

모든 환경에서 같은 경계가 작동한다. 개발 환경에서는 통과되고 CI에서만 실패하거나, 테스트에서는 우회가 허용되고 운영에서만 막히는 강제는 강제가 아니다.

경고는 강제가 아니다. warning은 무시된다. 특히 AI는 warning을 통과로 해석한다. 위반은 error로 처리해서 빌드 자체를 실패시킨다.

두 환경의 강제 도구

하네스 파트에서 Atlas와 Glif 두 환경을 분리했다. 강제 도구도 환경에 따라 다르다.

두 환경의 강제 방식은 구체적인 도구가 다르지만, 작동하는 원리는 같다. 위반이 감지되면 빌드가 실패하고, 합법 경로를 가리키는 오류 메시지가 출력된다.

각 문서에서 두 환경의 구현을 함께 보여준다.

이 파트의 구성

enforcement/
├── 적용 전략          ← 어디서부터 시작할 것인가
├── 빌드 타임 강제      ← Roslyn + ESLint: 코드 작성 시점에 차단
├── 런타임 강제         ← Guard + Assertion: 실행 시점에 차단
├── 전이 통제           ← 상태 전이 경로 강제
├── Planner 통제        ← AI 실행 흐름 통제
├── 경계 강제 패턴      ← 반복 강제 구현의 공통 패턴
├── 테스트 하네스 강제  ← 테스트 환경에서도 같은 경계
└── 패턴 요약           ← 전체 강제를 한눈에 (마지막에 읽는다)

권장 읽기 순서:

처음 시작한다면: 적용 전략 → 빌드 타임 → 런타임 → 패턴 요약

상태/흐름 통제가 목적이라면: 전이 통제 → Planner 통제

AI 작업 흐름에 강제를 적용한다면: Planner 통제 → 경계 강제 패턴

테스트 환경 정렬이 목적이라면: 테스트 하네스 강제

패턴 요약은 마지막에 읽는다. 개별 강제 방식을 먼저 이해한 뒤에야 전체 조망이 의미 있다.

설계는 문서로 시작하지만, 시스템은 실패 강제로 유지된다.