A-1. 법칙을 휴리스틱으로 읽기
한 줄 요약: 실무에서 인용되는 법칙과 원칙을 결론이 아니라 상황을 더 잘 질문하기 위한 휴리스틱(heuristic)으로 사용할 수 있다.
학습 목표
- 법칙, 원칙, 이론, 풍자적 관찰, 물리적 제약의 강도 차이를 설명할 수 있다.
- All Models Are Wrong, Occam's Razor, Chesterton's Fence처럼 서로 다른 방향의 법칙을 같은 의사결정 안에서 비교할 수 있다.
- 법칙을 근거로 결론을 닫지 않고, 반례와 경계 조건을 함께 제시할 수 있다.
- 설계 리뷰, 일정 회의, 장애 회고, AI 도구 도입 논의에서 법칙을 판단 질문으로 변환할 수 있다.
배경: 왜 이것이 존재하는가
경력 개발자의 회의에는 자주 짧은 이름들이 등장한다. "Brooks' Law 때문에 인력 추가는 안 된다", "YAGNI다", "DRY를 지켜야 한다", "Goodhart's Law를 조심해야 한다" 같은 문장은 빠르고 편하다. 문제는 빠른 언어가 빠른 결론으로 바뀌는 순간이다. 법칙의 이름은 대화를 압축하지만, 압축은 맥락 손실을 동반한다.
<dwmkerr/hacker-laws>에 모인 항목은 같은 종류의 명제가 아니다. Amdahl's Law처럼 수식 모델에 가까운 것도 있고, Kerckhoffs's principle처럼 보안 설계 원칙에 가까운 것도 있으며, Murphy's Law나 The Dilbert Principle처럼 풍자적 관찰에 가까운 것도 있다. 이들을 같은 강도의 규칙처럼 다루면 판단이 거칠어진다.
부록 A의 기본 전제는 단순하다. 법칙은 현실을 대신하지 않는다. 법칙은 현실을 보는 렌즈다. 렌즈는 어떤 것을 선명하게 만들지만 다른 것은 흐리게 만든다. 따라서 좋은 사용법은 "이 법칙이 맞으니 이렇게 한다"가 아니라 "이 법칙이 보이게 하는 비용은 무엇이고, 보이지 않게 하는 비용은 무엇인가"를 묻는 것이다.
이 문서에서 다루는 원문 항목명은 All Models Are Wrong, Occam's Razor, The Law of the Instrument, Chesterton's Fence, Hanlon's Razor, Murphy's Law / Sod's Law, The Dunning-Kruger Effect, Clarke's three laws다.
핵심 개념
법칙의 강도는 서로 다르다
실무에서 "법칙"이라고 부르는 것들은 다음처럼 강도가 다르다.
| 종류 | 예 | 다루는 법 |
|---|---|---|
| 수식 모델 | Amdahl's Law | 전제와 변수 범위를 확인하고 계산의 상한으로 사용한다. |
| 설계 원칙 | Kerckhoffs's principle, SOLID | 특정 문제 영역에서 좋은 실패 모드를 만들기 위한 지침으로 사용한다. |
| 경험 법칙 | Brooks' Law, Hyrum's Law | 반복 관찰된 위험을 조기에 묻는 체크포인트로 사용한다. |
| 인지적 경향 | Dunning-Kruger Effect, Hanlon's Razor | 사람의 판단 오류를 가정하되 개인 공격으로 쓰지 않는다. |
| 풍자적 관찰 | Murphy's Law, Dilbert Principle | 냉소가 아니라 위험 신호를 읽는 언어로 제한한다. |
강도가 다른 명제를 같은 방식으로 적용하면 오류가 생긴다. Amdahl's Law는 병렬화 가능한 구간이라는 전제가 맞을 때 성능 향상의 상한을 계산하는 데 쓸 수 있다. 반면 Hanlon's Razor는 "악의보다 실수나 정보 부족을 먼저 가정하라"는 태도에 가깝다. 후자를 수학 법칙처럼 쓰면 반복되는 구조적 문제를 선의로 덮어 버린다.
모델은 틀리기 때문에 유용하다
All Models Are Wrong은 모델이 현실의 일부를 버려야 쓸모가 생긴다는 관찰이다. 프론트엔드에서도 마찬가지다. "클라이언트 상태, 서버 상태, URL 상태"라는 구분은 실제 애플리케이션의 모든 상태를 완벽히 설명하지 않는다. 그러나 이 모델은 상태 소유권을 토론하게 해 준다.
모델의 위험은 버린 부분이 현재 문제의 핵심일 때 생긴다. 예를 들어 서버 상태를 캐시 키와 무효화로만 설명하면, 사용자가 오프라인 상태에서 편집한 낙관적 업데이트와 충돌 해결의 문제를 놓친다. 이때 모델은 단순해서 좋은 것이 아니라, 중요한 실패 모드를 숨겨서 위험해진다.
Occam's Razor는 단순한 설명을 우선하라는 원칙으로 자주 쓰인다. 하지만 단순성은 복잡도를 제거한 결과일 수도 있고, 다른 계층으로 밀어낸 결과일 수도 있다. "상태 관리 라이브러리를 제거하고 props로만 전달하자"는 선택은 작은 화면에서는 단순할 수 있다. 그러나 라우트, 서버 캐시, 권한, optimistic UI가 얽히면 단순성은 컴포넌트 트리 전체의 결합으로 바뀔 수 있다.
도구는 문제 정의를 바꾼다
The Law of the Instrument는 익숙한 도구가 문제를 그 도구에 맞게 보이게 만든다는 경고다. React Query에 익숙한 팀은 모든 비동기 상태를 서버 상태 캐시 문제로 볼 수 있고, Redux에 익숙한 팀은 지역 UI 상태까지 전역 이벤트 흐름으로 설명하려 할 수 있다. AI 에이전트에 익숙해진 팀은 요구사항을 도구가 처리하기 쉬운 형태로 쪼개는 대신, 도구가 놓치는 제품 판단까지 자동화하려 할 수 있다.
이 법칙이 유용한 지점은 도구 선택 이전이다. "이 문제는 도구가 필요한 문제인가, 경계가 모호한 문제인가, 정책 결정이 필요한 문제인가"를 묻는다. 하지만 이 법칙도 절대적이지 않다. 도구에 익숙하기 때문에 더 빨리 실패를 발견하는 경우도 있다. 익숙함 자체가 문제가 아니라, 익숙함이 관찰을 줄이는 순간이 문제다.
레거시는 제거 대상이기 전에 증거다
Chesterton's Fence는 어떤 울타리를 치운다면 먼저 왜 세워졌는지 이해하라는 관점이다. 오래된 브라우저 분기, 이상한 CSS reset, 중복된 API client, 불필요해 보이는 feature flag는 단순한 잔재일 수도 있지만 과거 장애, 계약, 배포 제약의 흔적일 수도 있다.
이 원칙은 레거시를 보호하라는 뜻이 아니다. 오히려 안전하게 제거하기 위한 절차를 요구한다. 관련 이슈와 ADR을 찾고, 현재 트래픽과 지원 브라우저를 확인하고, 삭제 후 관찰할 지표를 정한다. 반례도 있다. 아무도 이유를 모르고 관찰 가능한 의존도 없으며 테스트가 보호하는 경계라면, 오래되었다는 사실만으로 보존할 이유는 약하다.
악의보다 구조를 먼저 본다
Hanlon's Razor는 악의로 설명하기 전에 실수, 정보 부족, 제약을 고려하라는 태도다. 코드 리뷰에서 이상한 구현을 봤을 때 "왜 이렇게 했지"보다 "어떤 제약이 있었을까"를 먼저 묻는 것은 협업 비용을 낮춘다.
그러나 반복되는 장애를 개인의 실수로만 설명하면 시스템은 나아지지 않는다. 같은 종류의 XSS 위험이 여러 PR에서 반복된다면 문제는 개인의 부주의가 아니라 검증 경계, 리뷰 체크리스트, 보안 교육, 정적 분석의 부재일 수 있다. Hanlon's Razor는 비난을 늦추는 데 유용하지만, 구조적 원인을 찾는 일을 멈추게 해서는 안 된다.
실패 가능성은 설계 입력이다
Murphy's Law와 Sod's Law는 실패 가능한 일이 언젠가 드러난다는 냉소처럼 보인다. 실무에서는 실패를 예언하는 문장이 아니라 실패 경로를 설계에 포함하라는 신호로 쓴다. 네트워크 요청은 실패하고, 배포 캐시는 꼬이며, 사용자는 중복 제출하고, 환경 변수는 빠질 수 있다.
이 관찰은 테스트, 모니터링, 롤백, feature flag, idempotency, 접근성 fallback으로 연결될 때 가치가 있다. "어차피 터진다"는 말로 아무것도 하지 않는다면 법칙은 책임 회피가 된다.
자신감은 증거가 아니다
The Dunning-Kruger Effect는 역량이 낮은 사람이 자신의 역량을 과대평가할 수 있다는 관찰로 자주 인용된다. 팀에서 더 유용한 질문은 "누가 무지한가"가 아니라 "우리 판단의 자신감은 어떤 증거에서 왔는가"다. 신기술 도입, 일정 추정, 성능 최적화, 보안 리뷰에서는 자신감과 검증 증거를 분리해야 한다.
Clarke's three laws는 기술 전망을 다룰 때 도움을 준다. 가능해 보이지 않는 기술이 충분한 시간과 기반 기술을 얻으면 현실화될 수 있다. 동시에 이 관찰은 모든 과장을 믿으라는 뜻이 아니다. 가능성과 현재 제품에 도입할 준비 사이에는 검증, 운영, 보안, 비용이라는 거리가 있다.
실무 관점
법칙을 실무에서 쓰려면 문장을 질문으로 바꾸는 습관이 필요하다.
| 인용 문장 | 질문으로 바꾼 형태 |
|---|---|
| "YAGNI다" | 지금 만들지 않으면 나중에 되돌릴 수 없는 결정인가, 아니면 안전하게 미룰 수 있는가? |
| "Occam's Razor상 단순한 쪽이 맞다" | 단순해진 것이 사용자, 운영자, 다른 팀에게 복잡도를 넘긴 것은 아닌가? |
| "Chesterton's Fence다" | 이 구조가 생긴 이유를 어디서 확인할 수 있고, 지금도 그 이유가 유효한가? |
| "Murphy's Law다" | 실패했을 때 감지, 완화, 복구, 사용자 안내는 어떻게 되는가? |
| "Dunning-Kruger다" | 이 판단의 자신감은 계측, 실험, 리뷰, 운영 경험 중 무엇에 근거하는가? |
법칙은 ADR에도 잘 맞는다. 결론 아래에 "관련 법칙"을 적는 방식보다, 대안 비교의 질문으로 녹이는 편이 낫다. 예를 들어 "단일 상태 저장소를 선택한다"는 ADR에서는 The Law of Conservation of Complexity, The Law of the Instrument, YAGNI가 서로 다른 질문을 제공한다. 상태 흐름은 단순해지는가, 도구가 문제를 과장하는가, 미래 확장을 미리 사고 있는가를 따로 검토한다.
더 깊이
법칙은 서로 충돌할 때 더 유용해진다. Occam's Razor는 단순한 설명과 설계를 선호하게 만들지만, Chesterton's Fence는 오래된 복잡성의 이유를 먼저 찾게 만든다. YAGNI는 미래 확장을 미루게 하지만, Open/Closed Principle은 변경에 닫히고 확장에 열려 있는 구조를 요구한다. Brooks' Law는 늦은 프로젝트에 인력 추가를 경계하지만, Linus's Law는 충분한 눈이 결함 발견에 도움을 줄 수 있다고 말한다.
충돌은 모순이 아니라 현재 상황에서 무엇을 더 크게 봐야 하는지 드러내는 장치다. 유지보수자가 적고 배포 위험이 큰 레거시라면 Chesterton's Fence의 가중치가 커진다. 빠르게 검증해야 하는 실험 기능이라면 YAGNI와 단순한 삭제 가능성이 더 중요하다. 오픈소스 라이브러리처럼 관찰자가 많고 테스트 재현이 쉬운 경우 Linus's Law의 효과를 기대할 수 있지만, 도메인 맥락이 폐쇄적인 내부 시스템에서는 Brooks' Law의 커뮤니케이션 비용이 더 크게 작동할 수 있다.
회고 질문
- 이 법칙이 현재 상황에서 틀릴 수 있는 조건은 무엇인가?
- 이 법칙이 강조하는 비용은 무엇이고, 숨기는 비용은 무엇인가?
- 이 법칙과 반대 방향으로 작동하는 다른 법칙은 무엇인가?
- 지금 판단에서 관찰 가능한 증거와 추측은 어떻게 구분되는가?
- 이 법칙을 적용하지 않기로 해도 남겨야 하는 안전장치는 무엇인가?
정리
- 법칙은 결론이 아니라 질문 생성기다.
- 법칙마다 강도가 다르며, 수식 모델과 풍자적 관찰을 같은 방식으로 적용하면 위험하다.
- 좋은 법칙 사용은 반례, 경계 조건, 관찰 가능한 증거를 함께 둔다.
- 서로 충돌하는 법칙은 판단을 방해하는 것이 아니라 현재 비용 구조를 드러낸다.
- 부록 A의 모든 문서는 법칙을 절대화하지 않고 상황별 렌즈로 다룬다.
확인 문제
- 팀원이 "Occam's Razor상 상태 관리 라이브러리를 제거해야 한다"고 주장한다. 어떤 질문을 추가해야 하는가?
정답과 해설
단순해지는 계층과 복잡해지는 계층을 나누어 확인해야 한다. 전역 저장소 제거가 bundle과 학습 비용을 줄일 수는 있지만, props 전달, URL 상태, 서버 캐시, optimistic UI, 테스트 경계에 복잡도를 옮길 수 있다. 따라서 현재 상태의 변경 빈도, 소유권, 디버깅 경로, 삭제 후 실패 모드를 함께 본다.
- 레거시 코드를 삭제하려 할 때 Chesterton's Fence를 적용한다는 말은 무엇을 의미하는가?
정답과 해설
삭제를 금지한다는 뜻이 아니다. 그 구조가 생긴 이유, 현재도 남은 의존, 제거 후 관찰할 지표와 롤백 경로를 확인하라는 뜻이다. 이유를 찾을 수 없고 관찰 가능한 의존도 없으며 테스트가 보호한다면 제거가 합리적일 수 있다.
- Hanlon's Razor를 팀 회고에서 오용하면 어떤 문제가 생기는가?
정답과 해설
악의를 늦게 가정하는 태도는 협업에 도움이 된다. 그러나 반복되는 장애를 개인 실수나 선의로만 설명하면 검증 체계, 리뷰 구조, 권한 모델, 배포 절차 같은 시스템 원인을 놓친다.
참고 자료
- <dwmkerr/hacker-laws>: 부록 A에서 재분류한 법칙과 원칙의 원문 목록이다.
- Phase 10-1. 프로젝트 가이드: ADR과 기술 의사결정을 문서화하는 기준을 연결해 읽는다.
- Phase 11-1. AI 에이전트와 챗봇/자동완성의 차이: AI 도구 판단에서 법칙을 절대화하지 않는 태도를 연결해 읽는다.