소프트웨어 공학의 법칙들

3 hours ago 2

소프트웨어 시스템, 팀, 의사결정에 영향을 미치는 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가 이 이름을 붙임
오픈소스 커뮤니티에서 문서화나 지식 공유에 활용 가능한 통찰

Read Entire Article