강제 준비도
개요
아키텍처가 아무리 깔끔해 보여도, validator와 enforcement를 붙일 수 없으면 하네스 친화적이라고 보기 어렵다.
이 문서는 예쁜 설계와 강제 가능한 설계를 구분하는 기준을 다룬다.
1. rule을 검사 가능한 단위로 떨어뜨릴 수 있어야 한다
좋은 구조는 설계 결정을 rule로 번역하기 쉽다. 반대로 나쁜 구조는 의도는 있어도 위반 기준이 흐리다.
검사 가능한 구조의 특징:
- 위반 대상을 특정 import, 생성, 호출, 상태 전이로 좁힐 수 있다
- 어떤 모듈이 어떤 책임을 가지는지 분명하다
- 허용 경로와 금지 경로를 구조적으로 구분할 수 있다
검사 기준이 흐리면 validator도 약해진다.
2. 정적 강제를 붙일 지점이 있어야 한다
하네스는 가능하면 이른 단계에서 실패시키는 편이 좋다. 그래서 구조는 정적 강제를 붙이기 좋은 형태를 가져야 한다.
예:
- import boundary를 검사할 수 있다
- 프로젝트 참조 방향을 고정할 수 있다
- 특정 API 사용을 analyzer나 lint로 막을 수 있다
- 타입 수준에서 잘못된 생성 경로를 닫을 수 있다
정적 강제가 어려운 구조는 런타임 강제에 과도하게 의존하게 된다.
3. runtime guard를 둘 entry point가 있어야 한다
모든 것을 정적으로 막을 수는 없다. 그래서 runtime guard도 필요하다. 하지만 runtime guard는 아무 데나 두면 효과가 약하다.
좋은 구조:
- side effect 이전에 공통 entry point가 있다
- provider, command handler, facade처럼 guard를 둘 위치가 분명하다
- 상태 전이가 특정 함수나 타입으로 수렴된다
나쁜 구조:
- side effect가 여러 군데 흩어져 있다
- 누구나 내부 상태를 직접 바꾼다
- 공통 진입점이 없다
entry point가 없으면 runtime enforcement는 누수된다.
4. 테스트로 위반을 고정할 수 있어야 한다
강제는 구현만으로 끝나지 않는다. 반복되는 우회는 테스트로 고정되어야 한다.
그런데 어떤 구조는 이 작업이 지나치게 어렵다.
좋은 구조:
- 위반 시나리오를 독립적으로 재현할 수 있다
- fixture가 실제 계약을 존중한다
- 허용 경로와 금지 경로를 테스트로 구분할 수 있다
나쁜 구조:
- 테스트가 내부 구현에 과도하게 의존한다
- 위반 시나리오를 재현하려면 시스템 전체를 올려야 한다
- test double이 production 구조를 대체한다
5. 관찰 가능성이 있어야 강화가 가능하다
우회를 막으려면 먼저 우회가 보여야 한다. 관찰 가능성이 낮은 시스템은 하네스를 점진적으로 키우기 어렵다.
필요한 조건:
- 어떤 경로가 호출됐는지 추적 가능
- 어떤 상태 전이가 발생했는지 관찰 가능
- 어느 단계에서 실패했는지 식별 가능
- 로그, 테스트, 진단 메시지가 구조 위반을 드러냄
통제는 항상 관찰 가능성 위에 세워진다.
6. 환경 간 구조 차이가 적어야 한다
운영 환경에서만 강한 구조는 오래 못 간다. 테스트, 개발, story, fixture가 다른 구조를 가지면 enforcement가 약해진다.
좋은 구조:
- 환경별 adapter는 달라도 계약은 같다
- guard 위치와 진입점이 유지된다
- validator가 여러 환경에서 같은 기준으로 동작한다
나쁜 구조:
- dev에서는 직접 접근을 허용한다
- test에서는 validation을 끈다
- story에서는 provider를 건너뛴다
7. enforcement readiness를 보는 실무 질문
- 이 규칙을 lint, analyzer, type check 중 하나로 막을 수 있는가
- 정적으로 못 막으면 runtime guard를 둘 공통 entry point가 있는가
- 위반 시나리오를 테스트로 고정할 수 있는가
- 어느 단계에서 실패해야 가장 비용이 낮은가
- 지금 구조는 위반을 관찰할 수 있는가
이 질문에 답이 빈약하면, 문제는 enforcement 기법 부족보다 architecture readiness 부족일 가능성이 크다.
요약
enforcement를 붙이기 좋은 구조는 다음 조건을 가진다.
- rule을 검사 가능한 단위로 쪼갤 수 있다
- 정적 강제를 붙일 지점이 있다
- runtime guard를 둘 entry point가 있다
- 테스트로 위반을 고정할 수 있다
- 관찰 가능성이 충분하다
- 환경 간 구조 편차가 적다
즉 enforcement readiness는 구현 기술의 문제가 아니라, 강제를 걸 수 있는 구조적 표면이 존재하느냐의 문제다.