The 20 Software Engineering Laws 핵심 정리
Dr. Milan Milanović의 뉴스레터 글 **“The 20 Software Engineering Laws”(2026-04-23)**는 소프트웨어 실패를 “예외"가 아니라 “반복 가능한 패턴"으로 보게 해주는 체크리스트입니다. 아래는 원문의 20개 법칙을 빠르게 의사결정에 쓸 수 있도록 압축한 정리입니다. 원문: The 20 Software Engineering Laws 20 Laws 핵심 정리 이 글의 본질: 법칙은 “무엇을 해야 하는가"보다 “이미 어떤 일이 벌어지고 있는가"를 설명하는 진단 프레임이다. 실무 고빈도 함정: 늦은 프로젝트에 인원 추가(Brooks), KPI를 목표화해 왜곡 유도(Goodhart), 낙관 일정 산정(Hofstadter)이 반복된다. 설계 원칙: 작게 시작해 점진 진화(Gall), 단순성 우선(KISS), 장애를 기본값으로 설계(Murphy·Postel·CAP). 팀 운영 원칙: 팀이 커질수록 개인 생산성 저하(Ringelmann), 소수 핵심 인력 집중(Price), 과잉 자신감 리스크(Dunning-Kruger) 관리가 필요하다. 결론: 20개 법칙은 아키텍처·조직·일정·품질·스케일링 의사결정에서 “미리 실패 비용을 줄이는 안전장치"로 써야 한다. 1) 시스템이 만들어지는 방식 Gall’s Law: 동작하는 복잡계는 항상 먼저 동작한 단순계에서 진화한다. KISS: 단순함을 유지하라. 불필요한 복잡성은 미래 장애 비용이다. Conway’s Law: 조직의 커뮤니케이션 구조가 시스템 구조를 복제한다. Hyrum’s Law: API의 관측 가능한 모든 동작은 결국 누군가의 의존성이 된다. CAP Theorem: 분산 시스템은 일관성·가용성·분할 허용성 중 2개만 강하게 보장 가능하다. Zawinski’s Law: 소프트웨어는 기능 팽창 경향을 가진다. 실무 해석: 리라이트/플랫폼 전환 시 “완벽 설계"보다 “작은 성공 루프"를 먼저 만든다. ...