Dr. Milan Milanović의 뉴스레터 글 **“The 20 Software Engineering Laws”(2026-04-23)**는 소프트웨어 실패를 “예외"가 아니라 “반복 가능한 패턴"으로 보게 해주는 체크리스트입니다. 아래는 원문의 20개 법칙을 빠르게 의사결정에 쓸 수 있도록 압축한 정리입니다.
원문: The 20 Software Engineering Laws
1) 시스템이 만들어지는 방식
- Gall’s Law: 동작하는 복잡계는 항상 먼저 동작한 단순계에서 진화한다.
- KISS: 단순함을 유지하라. 불필요한 복잡성은 미래 장애 비용이다.
- Conway’s Law: 조직의 커뮤니케이션 구조가 시스템 구조를 복제한다.
- Hyrum’s Law: API의 관측 가능한 모든 동작은 결국 누군가의 의존성이 된다.
- CAP Theorem: 분산 시스템은 일관성·가용성·분할 허용성 중 2개만 강하게 보장 가능하다.
- Zawinski’s Law: 소프트웨어는 기능 팽창 경향을 가진다.
실무 해석: 리라이트/플랫폼 전환 시 “완벽 설계"보다 “작은 성공 루프"를 먼저 만든다.
2) 팀이 느려지는 방식
- Brooks’s Law: 늦어진 프로젝트에 인력을 추가하면 더 늦어진다.
- Ringelmann Effect: 팀 규모가 커질수록 개인 기여 효율은 낮아진다.
- Price’s Law: 성과의 큰 비중은 소수 인력이 만든다.
- Dunning-Kruger Effect: 지식이 부족할수록 과신하기 쉽다.
실무 해석: 인력 증원은 구조적 병목(의사결정, 온보딩, 모듈 경계) 해결 없이 효과가 제한적이다.
3) 시간·일정이 무너지는 방식
- Hofstadter’s Law: 예측보다 항상 더 오래 걸린다(이 법칙을 감안해도).
- Parkinson’s Law: 일은 주어진 시간을 채울 때까지 팽창한다.
실무 해석: 낙관 추정보다 버퍼·마일스톤·범위 축소 옵션을 먼저 설계해야 한다.
4) 지표가 일을 왜곡하는 방식
- Goodhart’s Law: 측정값이 목표가 되는 순간, 좋은 지표가 아니다.
- Gilb’s Law: 측정이 어려워도, 측정하지 않는 것보다 나은 방식은 항상 있다.
실무 해석: 단일 KPI 보상보다 균형 지표(품질·속도·신뢰성)를 함께 운영한다.
5) 성능·신뢰성의 현실
- Knuth의 최적화 원칙: 성급한 최적화는 해롭다.
- Amdahl’s Law: 병렬화 효과는 순차 구간이 상한을 만든다.
- Murphy’s Law: 고장날 수 있는 것은 결국 고장난다.
- Postel’s Law: 송신은 보수적으로, 수신은 관대하게.
실무 해석: 성능보다 먼저 정확성·관측성·복구성(rollback, retry, timeout)을 확보한다.
6) 품질·지식 생태계의 현실
- Sturgeon’s Law: 대부분은 평범하거나 좋지 않다.
- Cunningham’s Law: 온라인에서 정답을 빨리 얻는 방법은 틀린 답을 먼저 올리는 것.
실무 해석: 정보/코드 품질을 기본 불신하고, 리뷰·검증 루프를 시스템화해야 한다.
이 20개 법칙을 실제로 쓰는 방법 (체크리스트)
- 아키텍처 의사결정 전: “이 선택이 KISS/Gall/Conway에 어긋나는가?”
- 일정 수립 전: “Hofstadter 버퍼와 범위 축소 플랜이 있는가?”
- 조직 운영 중: “Brooks/Ringelmann 리스크를 줄일 협업 구조가 있는가?”
- KPI 설계 시: “Goodhart 왜곡을 막는 보조 지표가 있는가?”
- 배포 전: “Murphy 가정 하에 장애 대응(runbook/rollback) 준비가 되었는가?”
결국 이 법칙들은 “새로운 이론"이라기보다, 반복되는 실패의 압축 기록입니다. 프로젝트가 꼬일 때마다 원인을 사람 탓으로만 보지 말고, 어떤 법칙이 이미 작동 중인지부터 점검하면 의사결정 품질이 크게 올라갑니다.