강도 조정
개요
하네스 도입은 보통 두 극단 사이에서 흔들린다.
- 규칙이 너무 약해서 사실상 권고문에 그친다
- 규칙이 너무 빨리 강해져서 disable과 반발만 늘어난다
그래서 adoption에서는 strictness calibration이 필요하다.
문제는 강하게 할지 말지가 아니라,
언제 어떤 층에서 얼마나 강하게 할지다.
너무 약할 때 생기는 문제
- 리뷰에서만 지적되고 코드에는 남지 않는다
- AI가 같은 패턴을 계속 재생산한다
- helper와 util이 비공식 경로로 굳어진다
- 규칙이 존재하지만 행동을 바꾸지 못한다
이 상태는 안전해 보이지만, 실제로는 구조 붕괴를 더 천천히 축적할 뿐이다.
너무 이르게 강할 때 생기는 문제
- 합법 경로가 부족한데 금지만 늘어난다
- 테스트와 fixture가 대거 깨진다
- 대량 disable이 생긴다
- 규칙을 피하기 위한 더 교묘한 우회가 나온다
이 상태는 강해 보이지만, 실제로는 규칙의 신뢰를 빠르게 깎는다.
강도는 층마다 다르게 잡아야 한다
모든 규칙을 같은 강도로 다루면 안 된다.
예를 들면 다음이 자연스럽다.
- critical boundary 위반 -> 빠르게 hard fail
- 새 코드에서의 direct access -> build-time 차단
- 기존 레거시 경로 -> 경고와 migration marker 후 점진 전환
- 탐색적 실험 코드 -> 범위를 분리한 제한적 허용
강도 조절은 일관성 부족이 아니라, 도입 현실을 반영한 설계일 수 있다.
calibration의 기준
- 위반 시 피해 크기
- 합법 경로 준비 정도
- 자동 검출 가능성
- 수정 비용의 크기
- 반복 발생 빈도
- 팀과 AI가 그 규칙을 오해할 가능성
이 기준을 섞어야 지금 hard fail할지,
먼저 경고로 둘지,
범위를 좁혀 선도입할지가 보인다.
soft rule에서 hard rule로 가는 전형적 흐름
- 문서와 예제에서 canonical path를 고정한다.
- 리뷰와 validator에서 위반을 눈에 띄게 만든다.
- 새 코드나 특정 폴더부터 build-time 차단을 건다.
- 핵심 경로에는 runtime guard를 붙인다.
- 예외를 줄이면서 hard fail 범위를 넓힌다.
이 흐름은 느슨함을 옹호하는 것이 아니라, 구조를 실제로 정착시키는 경로다.
AI 코딩에서는 왜 calibration이 더 중요해지는가
AI는 soft rule을 쉽게 무시하고, 너무 강한 rule 앞에서는 더 넓은 우회로 도망가기도 한다.
그래서 AI 환경에서는 다음이 중요하다.
- soft stage라도 validator message는 충분히 명확해야 한다
- hard fail로 갈 영역은 public path가 먼저 준비되어 있어야 한다
- 새 코드와 legacy 코드를 같은 잣대로 바로 묶지 않아야 한다
즉 calibration은 사람 설득만이 아니라, AI가 잘못 학습할 표면을 줄이는 문제이기도 하다.
실무 질문
- 지금 규칙은 약해서 무시되는가, 강해서 반발을 부르는가
- hard fail을 걸기 전에 합법 경로가 준비되어 있는가
- critical boundary와 주변부를 같은 강도로 다루고 있지 않은가
- legacy와 new code를 같은 타이밍에 묶으려 하고 있지 않은가
- soft stage에서도 메시지는 충분히 구체적인가
요약
좋은 strictness calibration은 다음을 만족한다.
- 피해가 큰 곳은 빠르게 강하게 묶고
- 준비되지 않은 곳은 단계적으로 수렴시키며
- rule 신뢰를 잃지 않도록 강도를 조절한다
강한 규칙이 항상 좋은 것이 아니라, 구조를 실제로 정착시키는 강도가 좋은 것이다.