예외 정책
개요
하네스 도입에서 가장 어려운 주제 중 하나는 예외다. 현실적으로 모든 예외를 즉시 없앨 수는 없다. 하지만 예외를 아무 기준 없이 허용하면, 그 예외는 곧 구조 밖의 공식 경로가 된다.
그래서 필요한 것은 예외 허용이 아니라,
예외 정책이다.
왜 예외가 위험한가
예외는 보통 임시로 시작한다. 하지만 다음 조건이 겹치면 빠르게 굳어진다.
- 쓰기 쉽다
- 이유가 문서화되지 않는다
- 종료 시점이 없다
- 대체 경로가 준비되지 않았다
- 테스트나 예제로 재사용된다
이때 예외는 임시 해법이 아니라 새로운 정상 경로가 된다.
좋은 예외 정책의 조건
이유가 명시되어야 한다
왜 이 예외가 필요한지, 어떤 구조적 제약 때문에 당장 제거할 수 없는지 남아야 한다.
범위가 좁아야 한다
파일, 모듈, 기간, 상황이 한정되어야 한다. 막연한 전역 예외는 사실상 규칙 해제다.
종료 조건이 있어야 한다
- 어떤 리팩터링 후 제거되는가
- 어떤 API가 준비되면 닫히는가
- 어떤 날짜나 마일스톤에서 재검토하는가
이 중 하나는 있어야 한다.
관찰 가능해야 한다
예외가 얼마나 남아 있고, 어디에 몰려 있는지 보이지 않으면 줄어들지 않는다.
허용하면 안 되는 예외
다음은 특히 위험하다.
- 이유 없는 permanent disable
- 새 코드에 대한 blanket exception
- 테스트에서만 direct access를 허용하는 예외
- AI 생성 코드라서 봐주자는 예외
- public alternative가 있는데도 유지되는 예외
이런 예외는 adoption 비용을 줄이는 것이 아니라, 규칙 신뢰를 무너뜨린다.
예외를 줄이는 현실적인 방법
- canonical path를 먼저 제공한다
- 예외 코멘트에 rule code와 종료 조건을 붙인다
- 새 코드와 기존 코드의 예외 기준을 분리한다
- 예외 개수를 추적하고 감소 목표를 둔다
- 자주 반복되는 예외는 API나 harness 결핍 신호로 본다
핵심은 예외를 숨기지 않는 것이다.
AI 코딩에서 예외 정책이 더 중요해지는 이유
AI는 예외를 규칙보다 빠르게 학습한다.
주변 코드에 예외가 많이 남아 있으면,
그 예외가 곧 허용된 패턴처럼 재생산된다.
그래서 AI 환경에서는 다음이 더 중요하다.
- 예외는 최대한 좁고 명시적이어야 한다
- 예외 코드가 canonical example처럼 보이지 않아야 한다
- 예외보다 public path 예시가 더 많이 노출되어야 한다
실무 질문
- 예외마다 이유와 종료 조건이 남는가
- 예외 범위가 구체적으로 제한되어 있는가
- 새 코드에 blanket exception이 붙고 있지 않은가
- 반복되는 예외를 구조 결핍 신호로 보고 있는가
- AI가 예외 코드를 정상 패턴으로 학습할 가능성은 없는가
요약
좋은 exception policy는 다음을 만족한다.
- 예외 이유가 보이고
- 범위가 좁고
- 종료 조건이 있으며
- 예외를 구조 개선 후보로 다시 읽는다
예외를 허용하는 것과 예외를 관리하는 것은 다르다. 구조를 지키는 팀은 예외를 숨기지 않고 추적한다.