한 페이지로 보는 소프트웨어 엔지니어링 법칙 모음 — Conway, Hyrum부터 Cunningham까지

• HN에 올라온 "Laws of Software Engineering" 모음집 — 소프트웨어 개발하면서 한 번쯤 들어봤거나, 몰랐다면 지금이라도 알아두면 좋은 법칙들을 한 페이지에 정리해둠
  • 팀/아키텍처/품질/계획/설계/의사결정/스케일 7개 카테고리로 분류
  • 각 법칙마다 한 줄 정의만 있어서 훑어보기 좋은 포맷

팀 관련 법칙 — "사람이 제일 어렵다"

• Conway의 법칙 — 조직이 만드는 시스템은 결국 그 조직의 커뮤니케이션 구조를 닮는다
  • 마이크로서비스가 실패하는 이유 대부분이 여기 있음. 팀이 모놀리스로 일하면 코드도 모놀리스가 됨
• Brooks의 법칙 — 지연된 프로젝트에 인력 추가하면 더 지연됨
  • 신규 인력 온보딩 + 커뮤니케이션 오버헤드가 생산성 증가분을 잡아먹는 현상
• Dunbar의 수(150) — 한 사람이 안정적으로 유지할 수 있는 관계는 약 150명
  • 대기업 조직 설계할 때 자주 언급되는 수치
• Price의 법칙 — 참여자 수의 제곱근이 전체 일의 50%를 처리한다
  • 100명짜리 팀에서 10명이 절반을 한다는 얘기. 냉혹하지만 경험적으로 맞는 경우가 많음
• Bus Factor — 그 사람이 사라지면 프로젝트가 망가지는 최소 인원수
  • "이 모듈은 OO만 안다" 상황이면 버스 팩터 = 1. 위험 신호
• Peter Principle — 위계 조직에서 모든 직원은 자신의 무능력 수준까지 승진한다
• Putt의 법칙 — 기술을 이해하는 사람은 관리하지 않고, 관리하는 사람은 이해하지 못한다
• Ringelmann 효과 — 그룹이 커질수록 개인 생산성은 감소한다

아키텍처 — "복잡성은 사라지지 않는다"

• Hyrum의 법칙 — API 사용자가 충분히 많아지면, 시스템의 관찰 가능한 모든 동작은 누군가가 의존하게 된다
  • "이건 스펙에 없는데 왜 믿고 쓰시나요"가 안 먹히는 이유. XKCD의 스페이스바 밈으로 유명해짐
• Tesler의 법칙(복잡성 보존 법칙) — 모든 애플리케이션에는 줄일 수 없는 고유 복잡성이 있으며, 이는 이동만 가능할 뿐 제거할 수 없다
  • UI를 단순하게 하면 백엔드가 복잡해지고, 백엔드를 단순하게 하면 UI가 복잡해짐
• Leaky Abstractions 법칙 — 사소하지 않은 모든 추상화는 어느 정도 새어나간다
  • ORM 쓰다가 결국 SQL 튜닝해야 할 때 떠오르는 법칙
• CAP 정리 — 분산 시스템은 일관성(Consistency), 가용성(Availability), 분할 허용성(Partition tolerance) 중 두 개만 보장할 수 있다
• 분산 컴퓨팅의 8가지 오류 — 초보자가 흔히 빠지는 잘못된 가정들(네트워크가 안정적이다, 지연이 0이다 등)
• Gall의 법칙 — 작동하는 복잡한 시스템은 예외 없이 작동하는 단순한 시스템에서 진화한 것이다
  • 처음부터 거대하게 설계하면 망한다는 경험칙
• Second-System Effect — 작고 성공한 시스템 뒤에는 과도하게 설계된 비대한 후속작이 따라오기 쉽다
• Zawinski의 법칙 — 모든 프로그램은 메일을 읽을 수 있을 때까지 확장하려 한다 (기능 비대화에 대한 농담)

품질/테스팅 — "버그는 반드시 나온다"

• Murphy의 법칙 — 잘못될 수 있는 건 결국 잘못된다
• Postel의 법칙 — 내가 보낼 때는 보수적으로, 받을 때는 관대하게
  • HTTP, 이메일 프로토콜 설계의 핵심 철학
• Linus의 법칙 — 충분히 많은 눈이 보면 모든 버그는 얕다 (오픈소스의 근본 가정)
• Kernighan의 법칙 — 디버깅은 코드 작성보다 두 배 어렵다
  • 그래서 "가장 똑똑하게 짠 코드"를 쓰면 자기도 못 고침
• 깨진 창문 이론 — 나쁜 설계/잘못된 결정/부실한 코드를 방치하면 더 빨리 망가진다
• 테스팅 피라미드 — 단위 테스트 많이, 통합 테스트 적당히, UI 테스트는 최소로
• Pesticide Paradox — 같은 테스트를 반복하면 시간이 갈수록 효과가 떨어진다
• Sturgeon의 법칙 — 뭐든 90%는 쓰레기다 (소프트웨어도 예외 없음)

계획 — "항상 예상보다 오래 걸린다"

• Hofstadter의 법칙 — 항상 예상보다 오래 걸린다. 이 법칙을 고려해도 그렇다
  • 스프린트 추정할 때 버퍼 왜 두는지 설명해주는 한 줄
• Parkinson의 법칙 — 일은 주어진 시간만큼 늘어난다
• 90-90 규칙 — 코드의 첫 90%가 개발 시간의 90%를 먹고, 나머지 10%가 나머지 90%를 먹는다
• Goodhart의 법칙 — 측정이 목표가 되는 순간, 그것은 더 이상 좋은 측정이 아니게 된다
  • KPI로 줄 선 회사들이 왜 숫자만 채우고 망하는지 설명해주는 법칙
• 조기 최적화 (Knuth) — 조기 최적화는 모든 악의 근원

설계/디자인

• DRY — 모든 지식은 단일하고 명확한 권위 있는 표현을 가져야 한다
• KISS — 가능한 한 단순하게 유지하라
• YAGNI — 필요해질 때까지 기능을 추가하지 마라
• SOLID — 유지보수성과 확장성을 높이는 5가지 객체지향 설계 원칙
• Demeter의 법칙 — 객체는 직접 친구하고만 대화해야 한다 (체이닝 지옥 방지)
• 최소 놀람의 원칙 — UI/API는 사용자가 가장 덜 놀라는 방식으로 동작해야 한다

스케일 — "공짜 성능은 없다"

• Amdahl의 법칙 — 병렬화로 얻는 속도 향상은 병렬화할 수 없는 부분에 의해 제한된다
  • 코어 100개를 꽂아도 직렬 부분 때문에 성능이 안 나오는 이유
• Gustafson의 법칙 — 문제 크기를 키우면 병렬 처리에서 상당한 속도 향상이 가능하다 (Amdahl의 반대 시각)
• Metcalfe의 법칙 — 네트워크의 가치는 사용자 수의 제곱에 비례한다

의사결정 — "편향을 인지하는 것이 첫걸음"

• Dunning-Kruger 효과 — 덜 알수록 더 자신만만하다
• Hanlon의 면도날 — 어리석음이나 부주의로 설명 가능한 것을 악의로 돌리지 마라
• Occam의 면도날 — 가장 단순한 설명이 가장 정확할 가능성이 크다
• 매몰비용의 오류 — 이미 쏟아부은 시간/에너지 때문에 빠져나와야 할 선택을 붙잡고 있는 현상
• Pareto 법칙(80/20) — 문제의 80%는 원인의 20%에서 나온다
• Cunningham의 법칙 — 인터넷에서 정답을 얻는 최선의 방법은 질문이 아니라 틀린 답을 올리는 것이다
  • Stack Overflow의 작동 원리를 한 줄로 설명한 밈급 법칙

---

기술 맥락

이 모음집이 왜 개발자 커뮤니티에서 주기적으로 올라오는지 생각해볼 만해요. 이 법칙들 대부분은 "검증된 공리"가 아니라 경험에서 뽑아낸 휴리스틱이거든요. 그래서 맹신하면 위험하지만, 반대로 팀에서 벌어지는 현상을 빠르게 진단하는 도구로는 정말 유용해요.

특히 Conway의 법칙과 Hyrum의 법칙은 최근 10년간 재조명된 케이스예요. 전자는 마이크로서비스/플랫폼 엔지니어링 맥락에서 "조직 설계 = 시스템 설계"라는 인식이 퍼지면서, 후자는 공개 API를 운영하는 플랫폼 기업들이 "어떤 동작이든 누군가는 의존한다"는 뼈아픈 교훈을 얻으면서 거의 공리처럼 자리잡았어요.

Goodhart의 법칙은 DevOps/SRE 쪽에서 SLO를 설계할 때 핵심 고려사항이에요. 에러율 0.1%를 목표로 잡으면 팀이 에러 로그를 숨기는 방향으로 행동을 바꾸거든요. 그래서 측정 지표를 여러 개 섞고, 목표를 주기적으로 재정의하는 게 중요해요.

Tesler의 법칙은 제품 설계할 때 엔지니어와 디자이너가 싸우는 지점을 설명해줘요. "사용자에게 이걸 물어볼까, 아니면 우리가 판단할까" 하는 모든 결정이 결국 복잡성을 누구에게 떠넘길지의 문제인 거예요. 한쪽을 단순하게 만들면 다른 쪽이 복잡해지는 건 피할 수 없거든요.

마지막으로 Hyrum의 법칙이 현실에서 터지는 예시가 궁금하다면, 구글이 std::unordered_map의 반복 순서를 의도적으로 랜덤화한 이야기를 찾아보세요. 스펙에 없는 동작에 의존하는 코드를 막기 위한 조치였어요.