---
title: "한 페이지로 보는 소프트웨어 엔지니어링 법칙 모음 — Conway, Hyrum부터 Cunningham까지"
published: 2026-04-21T11:04:56.000Z
canonical: https://jeff.news/article/1851
---
# 한 페이지로 보는 소프트웨어 엔지니어링 법칙 모음 — Conway, Hyrum부터 Cunningham까지

소프트웨어 개발에서 자주 인용되는 경험칙과 법칙들을 팀/아키텍처/품질/계획/설계/의사결정/스케일 7개 카테고리로 정리한 레퍼런스 페이지다. Conway의 법칙, Hyrum의 법칙, CAP 정리 등 50개 가까운 항목을 한 줄 정의로 훑어볼 수 있다. 회고나 설계 리뷰에서 현상을 언어화할 때 쓰기 좋은 도구 모음이다.

- 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의 작동 원리를 한 줄로 설명한 밈급 법칙

> [!TIP]
> 이 법칙들은 외우라고 있는 게 아니라, 팀 회고나 설계 리뷰에서 현상을 언어화할 때 유용함. "이거 Conway의 법칙 아님?" 한마디가 한 시간짜리 토론을 단축시킬 때가 있음

---

## 기술 맥락

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

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

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

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

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

## 핵심 포인트

- 팀/아키텍처/품질/계획/설계/의사결정/스케일 7개 카테고리로 분류된 소프트웨어 법칙 컴필레이션
- Conway의 법칙(조직 구조 = 시스템 구조), Hyrum의 법칙(모든 관찰 가능 동작은 누군가 의존함) 등 핵심 법칙 수록
- Brooks의 법칙, Parkinson의 법칙 등 일정/인력 관리 경험칙도 포함
- Amdahl/Gustafson의 법칙처럼 병렬 컴퓨팅 이론도 다룸
- 각 항목이 한 줄 정의라 사전처럼 쓰기 좋고, 팀 토론에서 공통 언어로 활용 가능

## 인사이트

이런 법칙들은 맹신하면 위험하지만, 팀 내에서 벌어지는 현상을 빠르게 진단하는 공용 어휘로 쓰면 유용하다. 특히 Conway, Hyrum, Goodhart 세 법칙은 요즘 플랫폼 엔지니어링과 SRE 맥락에서 거의 공리급으로 다뤄진다.