소프트웨어 공학의 법칙들

• 소프트웨어 시스템, 팀, 의사결정에 영향을 미치는 56가지 원칙과 패턴을 한곳에 모은 컬렉션으로, 팀 운영부터 아키텍처, 품질, 설계, 의사결정까지 폭넓은 영역을 포괄
• Conway의 법칙, Brooks의 법칙, Dunbar의 수 등 팀 관련 법칙들은 조직 구조가 시스템 설계와 생산성에 직접적으로 영향을 미침
• 아키텍처 영역에서는 Hyrum의 법칙, CAP 정리, Gall의 법칙 등 복잡한 시스템 설계 시 반드시 고려해야 할 제약과 원칙을 정리
• 품질 관련 법칙들은 기술 부채, 테스팅 피라미드, Kernighan의 법칙 등 코드 품질 유지와 디버깅의 현실적 어려움을 다룸
• 의사결정 영역에서는 Dunning-Kruger 효과, 매몰 비용 오류, 파레토 원칙 등 개발 과정에서 빠지기 쉬운 인지 편향과 판단 기준을 포괄

---

팀(Teams)

1. Conway의 법칙 (Conway's Law)

조직은 자신의 커뮤니케이션 구조를 그대로 반영하는 시스템을 설계한다

• 소프트웨어 아키텍처는 그것을 만든 조직의 소통 구조를 자연스럽게 따라가는 현상
• 팀이 3개로 나뉘어 있으면 시스템도 3개의 큰 모듈로 나뉘는 경향이 있음
• 이를 역으로 활용하는 "역 Conway 전략"(Inverse Conway Maneuver)도 존재: 원하는 아키텍처에 맞춰 팀 구조를 먼저 재편하는 접근
• 마이크로서비스 도입 시 팀 경계와 서비스 경계를 일치시키는 것이 효과적

2. Brooks의 법칙 (Brooks's Law)

지연된 소프트웨어 프로젝트에 인력을 추가하면 오히려 더 늦어진다

• 신규 인력이 합류하면 기존 팀원이 교육과 조율에 시간을 소모하여 전체 생산성이 일시 저하
• 팀원이 늘어나면 커뮤니케이션 경로가 기하급수적으로 증가 (n명일 때 n(n-1)/2개)
• Frederick Brooks가 IBM OS/360 프로젝트 경험을 바탕으로 1975년 저서 The Mythical Man-Month에서 정립
• Little의 법칙(L = λ × W)으로 정량적 설명 가능: 인력 추가 시 WIP(작업 중인 항목)는 증가하지만 처리량(throughput)은 정체되어 리드 타임이 오히려 증가
• 해결책은 인력 추가가 아닌 범위 조정 또는 일정 변경

3. Dunbar의 수 (Dunbar's Number)

한 사람이 안정적으로 유지할 수 있는 관계의 인지적 한계는 약 150명

• Robin Dunbar가 영장류 뇌 크기와 사회 집단 규모의 상관관계에서 도출한 수치
• Dunbar의 사회적 계층 구조: ~5명(친밀한 관계), ~15명(신뢰할 수 있는 협력자), ~50명(가까운 업무 관계), ~150명(안정적 사회적 연결)
• 엔지니어링 조직이 150명을 넘으면 비공식적 소통이 한계에 도달하여 공식적 계층과 프로세스 필요
• Amazon의 "Two-Pizza Team"(5~10명)은 150명 내에서도 실질적 협업은 더 작은 단위에서 일어남을 반영

4. Ringelmann 효과 (The Ringelmann Effect)

그룹 규모가 커질수록 개인의 생산성은 감소한다

• 그룹 구성원이 많아질수록 각 개인의 기여도가 줄어드는 "사회적 태만"(social loafing) 현상
• 소프트웨어 팀에서도 팀 크기가 커지면 개별 책임감이 희석되고 조율 비용이 증가
• 소규모 팀이 1인당 더 높은 산출물을 내는 이유를 설명

5. Price의 법칙 (Price's Law)

전체 참여자 수의 제곱근에 해당하는 인원이 전체 작업의 50%를 수행한다

• 100명의 조직에서는 약 10명이 전체 작업의 절반을 담당
• 조직이 커질수록 소수의 고성과자에 대한 의존도가 심화
• 팀 확장 시 생산성이 선형으로 증가하지 않는 이유를 설명

6. Putt의 법칙 (Putt's Law)

기술을 이해하는 사람은 관리하지 않고, 관리하는 사람은 기술을 이해하지 못한다

• 기술 조직에서 관리 역할과 기술 전문성의 괴리를 풍자적으로 표현
• 기술 리더십 구조를 설계할 때 이 간극을 인식하고 보완 장치를 마련해야 함

7. Peter 원칙 (Peter Principle)

조직 내에서 모든 직원은 자신의 무능력 수준까지 승진하는 경향이 있다

• 특정 역할에서 유능한 사람이 승진하여 새로운 역할에서는 무능력해지는 패턴
• 뛰어난 개발자가 반드시 좋은 매니저가 되지는 않는 현실을 반영
• IC(Individual Contributor) 트랙과 매니지먼트 트랙을 분리하는 듀얼 래더 체계의 필요성

8. Bus Factor

프로젝트가 심각한 위험에 처할 수 있는 최소 팀원 이탈 수

• Bus Factor가 1이면 단일 장애점(Single Point of Failure)이 존재하는 상태
• 지식 공유, 페어 프로그래밍, 문서화를 통해 Bus Factor를 높이는 것이 중요
• 코드 리뷰와 크로스 트레이닝이 Bus Factor를 개선하는 실질적 방법

9. Dilbert 원칙 (Dilbert Principle)

기업은 무능한 직원을 관리직으로 승진시켜 피해를 제한하는 경향이 있다

• Scott Adams가 제안한 풍자적 관찰로, Peter 원칙의 변형
• 관리직이 실무에서 가장 적은 피해를 주는 자리로 여겨지는 역설적 조직 현상

---

계획(Planning)

10. 조기 최적화 / Knuth의 최적화 원칙 (Premature Optimization)

조기 최적화는 모든 악의 근원이다

• Donald Knuth가 1974년 논문에서 제시: "약 97%의 경우에서 작은 효율성은 무시해야 한다"
• 코드의 약 20%가 실행 시간의 80%를 차지하므로, 나머지 80% 코드를 최적화하는 것은 낭비
• 올바른 순서: 먼저 동작하게 만들고 → 올바르게 만들고 → 필요하면 빠르게 만들 것
• 최적화된 코드는 복잡성이 높아지므로, 프로파일링을 통해 실제 병목 지점을 확인한 후 수행해야 함

11. Parkinson의 법칙 (Parkinson's Law)

업무는 주어진 시간을 모두 채울 때까지 확장한다

• 데드라인이 2주면 2주, 4주면 4주 동안 일이 늘어나는 현상
• 소프트웨어 프로젝트에서 짧고 명확한 마일스톤 설정이 중요한 이유
• 스프린트 기반 애자일이 이 법칙에 대한 실질적 대응 방법

12. 90-90 법칙 (The Ninety-Ninety Rule)

코드의 처음 90%가 개발 시간의 90%를 차지하고, 나머지 10%가 또 다른 90%의 시간을 차지한다

• 소프트웨어 프로젝트의 마지막 10%(엣지 케이스, 폴리싱, 버그 수정)가 예상보다 훨씬 오래 걸림을 경고
• "거의 완성"이라는 말이 실제로는 전체 일정의 절반 지점일 수 있음

13. Hofstadter의 법칙 (Hofstadter's Law)

Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸린다

• 재귀적 자기 참조 구조를 가진 법칙으로, 소프트웨어 일정 추정의 본질적 어려움을 표현
• 버퍼를 추가해도 여전히 일정이 초과되는 현실
• Douglas Hofstadter가 1979년 저서 Gödel, Escher, Bach에서 소개

14. Goodhart의 법칙 (Goodhart's Law)

측정 지표가 목표가 되면 더 이상 좋은 측정 지표가 아니다

• 코드 커버리지를 KPI로 설정하면 의미 없는 테스트를 양산하는 현상이 대표적 사례
• 코드 라인 수(LOC)로 생산성을 측정하면 불필요하게 장황한 코드가 생산됨
• 지표 최적화가 아닌 본질적 가치 달성에 집중해야 함

15. Gilb의 법칙 (Gilb's Law)

정량화가 필요한 것은 측정하지 않는 것보다 어떤 방식으로든 측정하는 것이 나다

• 완벽한 측정이 불가능하더라도 대략적 측정이 무측정보다 항상 유익
• 소프트웨어 품질, 사용자 만족도 등 정량화가 어려운 항목에도 적용

---

아키텍처(Architecture)

16. Hyrum의 법칙 (Hyrum's Law)

API 사용자가 충분히 많으면, 시스템의 모든 관찰 가능한 동작에 누군가 의존한다

• 공식 API 명세뿐 아니라 타이밍, 에러 메시지 형식, 정렬 순서 등 비공식적 동작도 의존 대상이 됨
• Microsoft Windows가 과거 문서화되지 않은 동작과 버그에 의존하는 서드파티 앱 호환을 위해 구버전 동작을 유지한 사례
• Google의 Hyrum Wright가 2011-2012년경 Google 내부 라이브러리 변경 경험에서 관찰
• 동료 Titus Winters가 "Hyrum's Law"라는 이름을 붙임 (Software Engineering at Google 수록)
• 실질적 계약은 공식 API가 아니라 실제 관찰되는 동작 전체

17. Gall의 법칙 (Gall's Law)

작동하는 복잡한 시스템은 반드시 작동하는 단순한 시스템에서 진화한 결과이다

• 처음부터 복잡한 시스템을 설계하면 검증되지 않은 미지의 변수가 너무 많아 실패 확률이 높음
• MVP(Minimum Viable Product) 접근의 이론적 근거
• Facebook이 2004년 Harvard 학생용 단순 프로필 시스템에서 시작하여 점진적으로 확장한 사례
• 마이크로서비스 전환 시에도 모놀리스에서 시작하여 점진적으로 분리하는 것이 유리
• John Gall이 1975년 저서 Systemantics에서 제시 (30개 출판사가 거절 후 출간된 컬트 클래식)

18. 누수 추상화의 법칙 (The Law of Leaky Abstractions)

모든 비자명(non-trivial) 추상화는 어느 정도 누수가 발생한다

• ORM이 SQL을 숨기지만 성능 문제가 발생하면 결국 생성되는 쿼리를 확인해야 하는 상황이 대표 사례
• Java/Python의 가비지 컬렉션도 추상화이지만 GC 일시정지 같은 내부 동작이 성능에 영향을 미침
• 추상화 자체가 나쁜 것이 아니라, 추상화가 깨질 때를 대비해야 한다는 교훈
• Joel Spolsky가 2002년 블로그 포스트에서 TCP, 가상 메모리 등의 사례와 함께 소개
• George Box의 "모든 모델은 틀렸지만, 일부는 유용하다"와도 맥락 연결

19. Tesler의 법칙 / 복잡성 보존 법칙 (Tesler's Law)

모든 애플리케이션에는 제거할 수 없는 고유 복잡성이 있으며, 이동만 가능하고 제거는 불가능하다

• 핵심 질문: 복잡성을 누가 감당할 것인가 (사용자 vs 시스템)
• Calendly는 일정 조율의 복잡성을 시스템이 흡수하고, 이메일 스레드는 사용자에게 전가하는 차이
• 좋은 설계는 복잡성을 사용자 경험에서 시스템 내부로 이동시킴
• Larry Tesler가 Apple Lisa 및 초기 GUI 작업 중 1980년대에 정립

20. CAP 정리 (CAP Theorem)

분산 시스템은 일관성(C), 가용성(A), 분할 내성(P) 중 두 가지만 보장 가능하다

• 네트워크 파티션은 현실에서 불가피하므로, 실질적 선택은 일관성 vs 가용성
• CP 시스템 (예: MongoDB): 파티션 발생 시 쓰기를 차단하여 모든 레플리카 동기화 유지
• AP 시스템 (예: Cassandra, DNS): 파티션 중에도 요청 응답 유지, 레플리카 간 일시적 불일치 허용
• Eric Brewer가 2000년에 웹 서비스 맥락에서 제안, Gilbert & Lynch가 2002년에 공식 증명

21. Second-System 효과 (Second-System Effect)

작고 성공적인 시스템 다음에는 과도하게 설계된 비대한 후속 시스템이 뒤따르는 경향

• 첫 번째 시스템의 성공에 자신감을 얻어 두 번째 시스템에 모든 아이디어를 쏟아붓는 패턴
• 기능 과잉(feature creep)과 과도한 일반화(over-generalization)가 주된 원인
• Frederick Brooks가 The Mythical Man-Month에서 식별

22. 분산 컴퓨팅의 오류 (Fallacies of Distributed Computing)

분산 시스템을 처음 설계하는 사람들이 흔히 갖는 8가지 잘못된 가정

• 8가지 오류: (1) 네트워크는 신뢰할 수 있다, (2) 지연 시간은 0이다, (3) 대역폭은 무한하다, (4) 네트워크는 안전하다, (5) 토폴로지는 변하지 않는다, (6) 관리자가 한 명이다, (7) 전송 비용은 0이다, (8) 네트워크는 균일하다
• 이 가정들을 기반으로 설계하면 프로덕션에서 예기치 않은 장애와 성능 문제가 발생

23. 의도하지 않은 결과의 법칙 (Law of Unintended Consequences)

복잡한 시스템을 변경하면 예기치 않은 결과를 예상해야 한다

• 시스템 하나의 컴포넌트를 변경하면 예측하지 못한 곳에서 부작용이 발생
• 카오스 엔지니어링과 포괄적 테스팅의 필요성을 뒷받침하는 원칙

24. Zawinski의 법칙 (Zawinski's Law)

모든 프로그램은 메일을 읽을 수 있을 때까지 확장을 시도한다

• 소프트웨어가 성공하면 점점 더 많은 기능을 추가하려는 기능 팽창(feature bloat) 현상을 풍자
• Jamie Zawinski(Netscape 초기 개발자)가 관찰
• 단순한 도구가 시간이 지나면 만능 플랫폼이 되려 하는 경향에 대한 경고

---

품질(Quality)

25. Boy Scout 규칙 (The Boy Scout Rule)

코드를 발견한 것보다 더 나은 상태로 남겨야 한다

• 대규모 리팩토링이 아닌 지속적이고 점진적인 개선이 핵심
• 혼란스러운 함수명 수정, 중복 코드 제거, 누락된 테스트 추가 등 매번 작은 개선을 실천
• Robert C. Martin(Uncle Bob)이 Clean Code(2008)에서 소프트웨어 개발에 적용
• Google 엔지니어들의 원칙 "If you touch it, you own it" — 코드를 수정하면 그 품질에 대한 책임도 함께 가져감
• 이 규칙을 실천하면 깨진 유리창 효과(Broken Windows)를 예방하고 기술 부채 축적을 방지

26. Murphy의 법칙 (Murphy's Law)

잘못될 수 있는 것은 반드시 잘못된다

• 방어적 프로그래밍, 예외 처리, 장애 대비 설계의 근거
• 소프트웨어에서는 "일어날 수 있는 에러는 반드시 일어난다"는 자세로 에러 핸들링과 폴백을 설계해야 함

27. Postel의 법칙 / 견고성 원칙 (Postel's Law)

자신이 하는 일에는 보수적으로, 타인으로부터 받는 것에는 관대하게

• API 설계 시 출력은 엄격하게 스펙을 준수하되, 입력은 다양한 형식을 유연하게 수용하는 원칙
• Jon Postel이 TCP/IP 프로토콜 설계 시 수립한 견고성 원칙(Robustness Principle)
• 시스템 간 상호운용성을 높이는 실질적 가이드라인

28. 깨진 유리창 이론 (Broken Windows Theory)

나쁜 설계, 잘못된 결정, 저품질 코드를 방치하지 말 것

• 하나의 "깨진 유리창"(나쁜 코드)이 방치되면 추가적인 품질 저하를 유발
• 코드베이스에 TODO 주석, 죽은 코드, 미해결 경고가 쌓이면 새로운 코드도 낮은 수준으로 작성되는 경향
• 발견 즉시 작은 문제라도 수정하는 문화가 중요

29. 기술 부채 (Technical Debt)

소프트웨어 개발 속도를 저하시키는 모든 요소

• Ward Cunningham이 1992년 OOPSLA에서 금융 메타포로 처음 사용: 코드 지름길을 택하면 미래에서 시간을 빌리는 것
• 원금(수정 비용) + 이자(지저분한 코드로 인한 지속적 생산성 저하)
• 의도적 기술 부채는 때로 합리적 (시장 출시 타이밍, 프로토타이핑)이지만 상환 계획이 필수
• 자동화 테스트 생략이 대표적 사례: 릴리스는 성공하지만 이후 변경 시마다 예상치 못한 버그 발생
• 해결 방법: 리팩토링, 누락 테스트 추가, 설계 개선

30. Linus의 법칙 (Linus's Law)

충분한 수의 검토자가 있으면 모든 버그는 쉽게 발견된다

• 오픈소스 개발의 핵심 원리: 다수의 눈이 코드를 검토하면 버그가 사소한 문제가 됨
• Eric Raymond가 The Cathedral and the Bazaar에서 Linus Torvalds의 이름을 따 명명
• 코드 리뷰 문화의 중요성을 뒷받침

31. Kernighan의 법칙 (Kernighan's Law)

디버깅은 코드를 처음 작성하는 것보다 두 배 어렵다

• 따라서 최대한 영리하게 코드를 작성하면, 디버깅할 때 충분히 영리하지 못하게 됨
• 가독성 높은 단순한 코드를 작성해야 하는 이유
• Brian Kernighan이 The Elements of Programming Style에서 제시

32. 테스팅 피라미드 (Testing Pyramid)

프로젝트는 빠른 단위 테스트를 많이, 통합 테스트는 적게, UI 테스트는 소수만 보유해야 한다

• 단위 테스트(하단): 빠르고 저비용, 가장 많이 작성
• 통합 테스트(중간): 컴포넌트 간 상호작용 검증
• UI/E2E 테스트(상단): 느리고 깨지기 쉬우므로 최소화
• Mike Cohn이 Succeeding with Agile에서 소개한 테스트 전략 모델

33. 살충제 역설 (Pesticide Paradox)

동일한 테스트를 반복 실행하면 시간이 지남에 따라 효과가 감소한다

• 기존 테스트가 이미 잡을 수 있는 버그는 다 잡았으므로, 새로운 테스트 케이스를 지속적으로 추가해야 함
• 테스트 세트를 정기적으로 검토하고 업데이트하는 것이 필수

34. Lehman의 소프트웨어 진화 법칙 (Lehman's Laws of Software Evolution)

현실 세계를 반영하는 소프트웨어는 반드시 진화해야 하며, 그 진화에는 예측 가능한 한계가 존재한다

• E-type(현실 세계를 반영하는) 소프트웨어는 사용되려면 지속적 변경이 불가피
• 변경 시마다 복잡성이 증가하며, 이를 적극적으로 관리하지 않으면 품질이 저하

35. Sturgeon의 법칙 (Sturgeon's Law)

모든 것의 90%는 쓸모없다

• Theodore Sturgeon이 SF 문학 비평에 대응하여 제시
• 소프트웨어에도 적용: 대부분의 코드, 도구, 프레임워크 중 진정으로 훌륭한 것은 소수
• 품질에 대한 높은 기준을 유지하고, 가치 있는 10%에 집중하는 자세 필요

---

스케일(Scale)

36. Amdahl의 법칙 (Amdahl's Law)

병렬화로 인한 속도 향상은 병렬화할 수 없는 작업 비율에 의해 제한된다

• 프로그램의 5%가 순차적이면 아무리 많은 프로세서를 투입해도 이론적 최대 속도 향상은 20배
• 병렬화의 한계를 인식하고 순차적 병목 구간을 줄이는 것이 더 효과적
• Gene Amdahl이 1967년에 제시

37. Gustafson의 법칙 (Gustafson's Law)

문제 크기를 늘림으로써 병렬 처리에서 상당한 속도 향상을 달성할 수 있다

• Amdahl의 법칙에 대한 보완적 관점: 고정된 문제가 아닌 확장 가능한 문제에서는 프로세서 추가가 효과적
• 빅데이터 처리, 과학 시뮬레이션 등에서 더 많은 리소스로 더 큰 문제를 풀 수 있음

38. Metcalfe의 법칙 (Metcalfe's Law)

네트워크의 가치는 사용자 수의 제곱에 비례한다

• 사용자가 10명이면 가치는 100 단위, 100명이면 10,000 단위로 증가
• 소셜 네트워크, 메신저, 마켓플레이스 등 네트워크 효과의 이론적 기반
• Robert Metcalfe가 이더넷 기술의 가치를 설명하기 위해 제시

---

설계(Design)

39. DRY 원칙 (Don't Repeat Yourself)

모든 지식은 단일하고 명확하며 권위 있는 하나의 표현만 가져야 한다

• 코드 중복뿐 아니라 지식, 로직, 데이터의 중복도 포함
• 중복은 변경 시 여러 곳을 동시에 수정해야 하므로 버그와 불일치의 원인
• Andy Hunt와 Dave Thomas가 The Pragmatic Programmer에서 정립

40. KISS 원칙 (Keep It Simple, Stupid)

설계와 시스템은 가능한 한 단순해야 한다

• 복잡성은 이해, 유지보수, 디버깅의 비용을 증가시킴
• 단순한 해결책이 대부분의 경우 더 효과적이며 결함 가능성도 낮음
• 미국 해군이 1960년대에 제시한 설계 원칙에서 유래

41. SOLID 원칙 (SOLID Principles)

소프트웨어 설계를 향상시키는 5가지 핵심 가이드라인

• S — 단일 책임 원칙(Single Responsibility): 클래스는 하나의 이유로만 변경
• O — 개방-폐쇄 원칙(Open-Closed): 확장에 열려 있고 수정에 닫혀 있어야 함
• L — Liskov 치환 원칙: 하위 타입은 상위 타입을 대체할 수 있어야 함
• I — 인터페이스 분리 원칙: 클라이언트는 사용하지 않는 인터페이스에 의존하지 않아야 함
• D — 의존성 역전 원칙: 상위 모듈이 하위 모듈에 의존하지 않고 추상화에 의존
• Robert C. Martin이 정립하고 Michael Feathers가 SOLID라는 약어를 명명

42. 디미터 법칙 (Law of Demeter)

객체는 직접적인 친구와만 상호작용해야 하며, 낯선 객체와의 직접 소통은 지양해야 한다

• a.getB().getC().doSomething() 같은 체인 호출을 피해야 한다는 원칙
• 결합도를 낮추고 캡슐화를 강화하여 변경 영향 범위를 줄임
• "최소 지식의 원칙"이라고도 불림

43. 최소 놀라움의 원칙 (Principle of Least Astonishment)

소프트웨어와 인터페이스는 사용자와 다른 개발자를 가장 적게 놀라게 하는 방식으로 동작해야 한다

• 함수, API, UI가 이름과 컨벤션에서 예측 가능한 동작을 해야 함
• delete() 함수가 실제로는 아카이브만 한다면 놀라움을 유발 → 설계 결함
• 직관적이지 않은 동작은 버그와 사용자 실수를 초래

44. YAGNI (You Aren't Gonna Need It)

필요하기 전까지 기능을 추가하지 말 것

• Extreme Programming(XP)의 핵심 원칙으로 1990년대 후반 Ron Jeffries가 제시
• "미래에 필요할지 모른다"는 이유로 코드를 작성하면 과잉 설계와 유지보수 부담 발생
• 리팩토링에 대한 자신감(좋은 테스트 커버리지, CI)이 있어야 YAGNI를 실천 가능
• 현재 JSON 내보내기만 필요하면 JSON만 구현, XML/YAML 등은 요구될 때 추가

---

의사결정(Decisions)

45. Dunning-Kruger 효과 (Dunning-Kruger Effect)

어떤 것에 대해 적게 알수록 더 자신감을 갖는 경향이 있다

• 초보 개발자가 복잡한 시스템의 난이도를 과소평가하거나, 전문가가 오히려 자신의 지식에 겸손한 현상
• 코드 리뷰, 멘토링, 지속 학습을 통해 자기 인식의 정확성을 높이는 것이 중요

46. Hanlon의 면도날 (Hanlon's Razor)

어리석음이나 부주의로 충분히 설명되는 것을 악의로 돌리지 말 것

• 동료의 나쁜 코드나 잘못된 결정을 의도적 방해로 해석하기 전에 무지, 실수, 시간 부족을 먼저 고려
• 팀 내 신뢰와 건설적 커뮤니케이션의 기반

47. Occam의 면도날 (Occam's Razor)

가장 단순한 설명이 가장 정확한 경우가 많다

• 디버깅 시 복잡한 원인보다 가장 단순한 가능성부터 먼저 확인
• 아키텍처 설계에서도 불필요한 추상화 레이어를 추가하기 전에 단순한 해결책을 우선 탐색

48. 매몰 비용 오류 (Sunk Cost Fallacy)

시간이나 에너지를 투자했다는 이유만으로 손해가 되는 선택을 계속 유지하는 현상

• 6개월 동안 개발한 기능이 잘못된 방향이었더라도 투자한 시간 때문에 버리지 못하는 심리
• 올바른 결정은 과거 투자가 아닌 미래 가치를 기준으로 해야 함

49. 지도는 영토가 아니다 (The Map Is Not the Territory)

현실에 대한 표현(모델)은 현실 자체와 동일하지 않다

• UML 다이어그램, 아키텍처 문서, 데이터 모델 등은 현실의 근사치일 뿐
• 모델을 맹신하지 말고, 실제 시스템의 동작을 관찰하며 모델을 갱신해야 함

50. 확증 편향 (Confirmation Bias)

기존 믿음이나 아이디어를 지지하는 정보를 선호하는 경향

• 자신이 선택한 기술 스택이나 설계 결정에 유리한 정보만 선별적으로 수집하는 함정
• 반대 증거를 적극적으로 탐색하고 다양한 관점을 수용하는 것이 균형 잡힌 의사결정의 핵심

51. Hype Cycle과 Amara의 법칙 (The Hype Cycle & Amara's Law)

기술의 단기 효과는 과대평가하고, 장기 영향은 과소평가하는 경향이 있다

• Gartner의 Hype Cycle: 기술 촉발 → 과도한 기대의 정점 → 환멸의 골짜기 → 계몽의 경사 → 생산성 안정기
• 새 기술(블록체인, AI 등)을 도입할 때 단기 과열에 휩쓸리지 말고 장기적 실용성을 평가해야 함

52. Lindy 효과 (The Lindy Effect)

오래 사용된 것일수록 앞으로도 계속 사용될 가능성이 높다

• UNIX, SQL, C 언어처럼 수십 년간 사용된 기술은 앞으로도 오래 생존할 가능성이 높음
• 새로운 프레임워크보다 검증된 기술을 선택할 때의 이론적 근거
• Nassim Nicholas Taleb이 Antifragile에서 대중화

53. 제1원리 사고 (First Principles Thinking)

복잡한 문제를 가장 기본적인 구성 요소로 분해한 후 그로부터 재구축하는 사고법

• 기존 관행과 가정을 제거하고 근본적 진실에서 출발하여 해결책을 도출
• Elon Musk가 SpaceX 로켓 비용 절감에 적용한 사례로 유명
• 복잡한 시스템 설계 시 "원래 다 그렇게 하니까"라는 사고를 경계

54. 역전 사고 (Inversion)

반대 결과를 상정하고 거꾸로 추론하여 문제를 해결하는 방법

• "어떻게 성공할까" 대신 "어떻게 하면 실패할까" 를 먼저 생각하여 위험 요소를 식별
• 장애 모드 분석(Failure Mode Analysis)과 프리모템(Pre-mortem)의 이론적 근거
• Charlie Munger가 자주 활용하는 멘탈 모델

55. 파레토 원칙 / 80/20 법칙 (Pareto Principle)

문제의 80%는 원인의 20%에서 발생한다

• 전체 버그의 80%가 코드의 20%에 집중되어 있는 경향
• 가장 영향력이 큰 20%에 리소스를 집중하는 것이 효율적 자원 배분 전략
• Vilfredo Pareto가 이탈리아 토지 소유 분포에서 관찰한 원리에서 유래

56. Cunningham의 법칙 (Cunningham's Law)

인터넷에서 정확한 답을 얻는 가장 좋은 방법은 질문이 아니라 틀린 답을 게시하는 것이다

• 사람들은 질문에 답하는 것보다 잘못된 정보를 교정하는 데 더 적극적으로 참여
• Ward Cunningham(Wiki 발명자)의 이름을 딴 법칙이지만, 실제로는 Steven McGeady가 이 이름을 붙임
• 오픈소스 커뮤니티에서 문서화나 지식 공유에 활용 가능한 통찰

[GN⁺]

Hacker News 의견들

• 나는 "조기 최적화는 모든 악의 근원"이라는 말을 특히 싫어함. 이 문장은 1974년 맥락에서 나온 말이라 지금과는 전제가 다름. 그때 최적화는 어셈블리와 사이클 계산에 가까웠지만, 지금 성능은 주로 아키텍처 선택의 문제라 시작부터 고려해야 함. 프로파일링으로 우발적 O(n²) 같은 성능 버그를 잡는 조언은 여전히 유효하지만, 추상화 비용이 병목이 된 뒤에는 캐시와 병렬성만 덧대며 더 복잡하고 더 느린 시스템이 되기 쉬움. 지금은 늦은 최적화도 조기 최적화만큼, 어쩌면 더 나쁘다고 봄

  • 이 말은 프로그래밍에서 가장 자주 오해되는 문장 중 하나라고 봄. Donald Knuth의 원문을 직접 읽어보면, 요지는 측정도 없이 필요 없는 성능 개선에 힘을 쓰지 말되, 성능이 핵심인 10% 상황은 예외라는 뜻임. 그런데 이를 "아무것도 측정하지 말라"는 이상한 교리로 받아들이는 경우를 자주 봄
  • 내가 생각하는 진짜 나쁜 조기 최적화는 중요하지도 않은 미세 차이에 집착하는 경우임. 예를 들어 Java에서는 나중에 멀티스레드 문맥으로 갈 수도 있어서 ConcurrentHashMap을 자주 쓰는데, 대부분 상황에서 성능 차이는 크지 않음. 그런데 "HashMap이 더 빠르다"는 이유로 PR이 막히고 끝없는 논쟁이 벌어지곤 함. 그런 것보다 PostgreSQL 블로킹 호출 40개나 불필요한 웹 요청 같은, 체감 차이를 만드는 곳에 집중하는 편이 맞다고 봄. 다만 알고리즘 수준의 이른 최적화는 충분히 괜찮다고 생각함
  • 나는 "조기 최적화" 대신 성숙한 최적화만 한다고 농담처럼 말함. 프레임워크를 쌓기 전에 사용 방식, 데이터 접근 패턴, 성능 요구사항을 먼저 생각하는 건 아주 성숙한 접근임. 대부분은 사이클 계산까지 갈 필요는 없지만, bulk load인지 단건 처리인지, 동시성이나 분산을 고려해야 하는지 같은 판단은 초기에 해두면 차이가 큼. 성능은 나중에 생각해도 된다는 진영은 이후 개선에서 자주 막히는 편임
  • 나는 작년에 요청마다 40ms를 더 먹게 만드는 추상화 계층을 걷어내는 데 6개월을 씀. 프로파일링으로 hot path를 찾았지만 재작성 없이는 해결이 안 됐음. "나중에 최적화하자"는 쪽은 그 나중이 사실상 영원히 오지 않을 수 있음을 잘 말해주지 않음
  • 나는 현대 도구들로는 확장 가능한 설계를 비교적 쉽게 만들 수 있다고 봄. 그래서 조기 최적화란 이미 충분히 괜찮은 부분을 굳이 더 깎는 행위이지, 처음부터 엉망인 코드를 써도 된다는 뜻은 아니라고 이해함

• 나는 Curly's Law가 빠진 게 아쉬움. 변수는 한 가지 의미만 가져야 하고, 상황에 따라 다른 도메인의 값을 담거나 두 역할을 동시에 해서는 안 됨. "바닥 광택제이면서 디저트 토핑" 같은 상태가 되지 말아야 한다는 비유가 딱 들어맞음

  • 나는 그 "바닥 광택제이자 디저트 토핑" 비유가 아주 보편적인 법칙은 아닐 수도 있다고 농담하고 싶음. 식당 근처에서 청소 일을 해본 입장에선, 취하게 해준다고 하면 바닥 광택제를 토핑처럼 먹어보려는 사람도 꽤 있을 것 같다는 생각임
  • 나는 이 원칙을 이름으로는 몰랐지만 몸으로 배운 적이 있음. 예를 들어 x가 0이 아니면 y를 0으로 만드는 규칙이 있다면, x가 0인지 알고 싶다고 y를 우회 신호처럼 보면 안 됨. 더 나쁘게는 남는다고 y를 다른 용도로 재활용하면 안 됨
  • 나는 Shellac이 실제로 바닥 광택제이면서 식품 첨가물이기도 했다는 점이 떠오름. 요즘은 더 나은 대체재가 있지만, 예전에는 특히 사탕 쪽에서 쓰였고 지금도 관악기 접착제로는 쓰인다고 알고 있음
  • 나는 Google에서 쓰던 absl::StatusOr를 꽤 좋아했음
  • 나는 이런 상황을 보통 POSIWID라는 이름으로 부름

• 나는 이런 소프트웨어 "법칙"들을 한데 모아두면 서로 내부 모순이 너무 많아서, 결국 자기 주장을 정당화해주는 문장 하나를 골라 쓰기 쉬워진다고 느낌. 진짜 어려운 건 언제 어떤 법칙을 깨야 하는지, 그리고 왜 깨는지 아는 일임

  • 나는 Postel's Law와 Hyrum's Law의 충돌이 대표 사례라고 봄. 입력을 관대하게 받으면 API의 관찰 가능한 모든 동작에 누군가 의존하게 되고, 나중에 엄격하게 바꾸는 순간 문서화되지 않았더라도 호환성 파괴가 됨. 그래서 내가 내린 결론은, 내가 통제하는 내부 경계에서는 엄격하게 받고, 클라이언트 업그레이드를 강제할 수 없는 외부 경계에서만 관대해지는 방식임. 다만 현실에서는 그 경계를 구분하는 일이 가장 어려운 편임
  • 나는 이런 모순의 대표 예시로 DRY를 자주 듦. 비슷한 함수 두 개를 쓰지 않으려다가 개념적 복잡도를 하늘까지 띄우는 경우를 특히 많이 봤음
  • 나는 꽤 오래 일한 SWE로서 지금도 KISS와 YAGNI만으로 엄청난 효용을 얻고 있음. 소프트웨어 엔지니어링의 많은 부분이 과도한 설계라고 느끼고, 솔직히 이 사이트도 그렇다고 봄. 다른 공학 분야에선 자재비와 인건비가 눈에 보이기 때문에 이런 식의 과잉을 오래 못 버팀
  • 나는 Amazon의 Leadership Principles도 비슷했다고 느낌. 대체로 그럴듯한 지침이지만, 실제 논쟁에서는 어떤 원칙을 가장 그럴듯하게 무기화해서 내 주장에 붙일 수 있느냐의 싸움이 되곤 했음. 꼭 나쁘기만 한 건 아닐 수도 있다고도 생각함
  • 나는 형식적인 IT 법칙 전쟁 대신 Dan North의 CUPID 같은 대안을 더 좋아함. joyful coding을 위한 속성들이라는 점에서 SOLID보다 더 실용적으로 느껴짐

• 나는 2026년판 소프트웨어 공학 법칙으로, 모든 웹사이트가 Claude Opus로 vibe coding될 거라고 농담하고 싶음. 그 결과 배경색은 Anthropic을 닮은 크림톤이 되고, 폰트와 두께는 디자인 입문자가 막 타이포그래피를 배운 것처럼 과하게 섞이며, 카드 UI는 넘쳐나고 카드 한쪽 면에만 둥근 컬러 테두리가 들어가는 식의 패턴이 반복될 것 같음

  • 나는 그 사이트를 vibe coding한 사람이 책도 vibe coding했을 가능성이 높다고 보고 바로 패스하고 싶음. 게다가 이 사람의 코딩 이력을 찾아보니 치트시트와 로드맵 위주라, 책 내용에도 신뢰가 거의 생기지 않음
  • 나는 도메인도 분명 긴 제목 그대로 .com이 붙는 형태일 거라고 예상함

• 나는 Boyd's Law of Iteration도 들어가야 한다고 생각함. 복잡성을 다룰 때는 깊이 있는 분석보다 빠른 반복이 더 좋은 결과를 내는 경우가 많다는 말인데, Boyd가 OODA loop를 만든 사람이라는 점까지 생각하면 더 인상적임

  • 나는 이 법칙이 정말 좋고 더 많은 사람이 이해했으면 함. 관리나 비즈니스 쪽은 선행 계획을 원하지만, 소프트웨어는 처음부터 모든 문제를 예측할 수 없음. 처음부터 딱딱한 구조를 설계해 스스로를 가두기보다, 유연한 아키텍처 위에서 리팩터링하며 문제를 해결하는 편이 더 효과적이라고 봄
  • 나는 일반적으로 지나치게 신중한 개발보다 반복적 개발이 더 낫다고 봄. 전투기 조종간 사례도 아주 미묘하고 좋은 예시였음. 이 얘기를 보니 대학 시절 빌드 시간이 10분씩 걸리던 고통스러운 프로젝트가 떠오름. 실제 구현 대신 제공된 mock 컴포넌트로 바꿔 써야 했는데 그걸 늦게 알아채서 마감 전에 끝내지 못했음. 그 뒤로는 항상 빌드 시간을 줄이는 방법을 먼저 찾게 됨
  • 나는 Boyd의 법칙을 너무 극단으로 밀어붙이면 1주 스프린트 이하 같은 형태로 흐르기도 한다고 느낌

• 나는 삭제된 댓글 중에 이 글에 대한 최고의 메타 법칙이 있었다고 생각함. "모든 소프트웨어 공학 법칙은 즉시 오해되고, 원 저자가 경악할 방식으로 무비판적으로 적용된다"는 내용이었는데, 핵심 맥락이 빠진 LLM의 행동을 보면 왜 그런지 더 잘 이해된다고 느낌. 결국 수십 년의 지혜와 경험을 한 줄 명언으로 압축하는 데는 한계가 있음

• 나는 "'소프트웨어 공학의 법칙' 목록 사이트"를 통째로 vibe coding할 바에야 그냥 Wikipedia 페이지를 만들지 않은 건 무슨 법칙을 어긴 거냐고 묻고 싶음

  • 나는 "Wikipedia 페이지를 만들라"는 제안도 좀 이상하게 들림. 2026년의 Wikipedia는 사실상 Wikipedia 문화권의 깊은 전문가가 아니면 새 페이지를 만들기 어려운 곳처럼 느껴짐. 위키 고수들은 137개 지침만 따르면 누구나 만들 수 있다고 하지만, 현실에선 관리자에게 삭제당하기 쉽다는 냉소가 있음
  • 나는 그 법칙 이름을 Slop's Law라고 붙이고 싶음. 대충 만들 수 있으면 결국 대충 만들어진다는 뜻임
  • 나는 2026년판 Sturgeon's Law로 "모든 것의 99%는 crap 또는 slop"이라고 요약하고 싶음

• 나는 이런 내용이 취업 요건일 정도로 기본 교양이었으면 좋겠다고 생각함. 모두가 알아야 할 이야기처럼 느껴짐

• 나는 소프트웨어 전용 법칙은 아니어도 Chesterton's Fence를 인턴과 신입에게 가장 먼저 가르치는 편임

  • 나는 목록에 있는 Law of Unintended Consequences도 같은 현상을 설명한다고 봄. 그래도 개인적으로는 그 법칙보다 울타리 이야기가 더 마음에 듦
  • 나는 이 원칙을 내 핵심 원칙 중 하나로 삼고 있고, 한마디로 하면 생각하고 행동하기라고 봄

• 나는 Tesler의 복잡성 보존 법칙이 문장 자체로는 바로 통찰을 준다고 느낌. 모든 애플리케이션에는 제거할 수 없고 이동만 가능한 고유 복잡성이 있다는 말임. 다만 설명으로 들어가면 결국 사용자를 덜 괴롭히라는 평범한 조언으로 축소되는 것 같아 흥미가 조금 줄어듦. 사용자는 필요한 수준의 복잡성은 결국 가져야 하고, 무턱대고 줄이면 유연성 없는 장난감이 되기 쉬움. 그래서 나는 리팩터링할 때 한 부분을 단순화하면 다른 부분이 더 복잡해질 수 있다는 점을 기억하는 쪽이 더 유용하다고 봄