소프트웨어 엔지니어링의 56가지 법칙: 팀, 아키텍처, 품질을 관통하는 원칙들
목차
개요
Dr. Milan Milanović이 운영하는 lawsofsoftwareengineering.com은 소프트웨어 시스템과 팀, 의사결정을 형성하는 원칙과 패턴 56가지를 정리한 컬렉션이다. 이 사이트는 주니어/중급/시니어 수준별로 법칙을 분류해 제공하며, 각 법칙을 카테고리별로 탐색할 수 있도록 구성되어 있다. Hacker News 커뮤니티에서는 이 컬렉션을 두고 “조기 최적화” 해석을 비롯해 다양한 논쟁이 벌어졌고, “언제 어떤 법칙을 깨야 하는지 아는 것이 진짜 어렵다”는 메타적 지적도 등장했다.
법칙을 관통하는 7가지 영역
56가지 법칙은 크게 팀, 계획, 아키텍처, 품질, 스케일, 설계, 의사결정이라는 7가지 영역으로 분류된다. 각 영역은 서로 독립적이지 않으며, 실제 프로젝트에서는 여러 법칙이 동시에 작용한다.
팀과 계획
팀 영역에는 조직 구조와 커뮤니케이션에 관한 고전적 법칙들이 포함된다.
| 법칙 | 핵심 내용 |
|---|---|
| 콘웨이 법칙 | 조직의 통신 구조가 설계하는 시스템에 반영됨 |
| 브룩스 법칙 | 지연된 프로젝트에 인력을 추가하면 완성이 더 늦춰짐 |
| 던바의 수 | 한 사람이 안정적으로 유지할 수 있는 관계는 약 150개 |
| 피터 원리 | 조직 내 직원은 무능력해지는 지점까지 승진함 |
| 버스 팩터 | 프로젝트 위험에 빠뜨릴 최소 팀원 수 |
계획 영역은 예측과 측정의 한계를 다룬다.
| 법칙 | 핵심 내용 |
|---|---|
| 조기 최적화 | 조기 최적화는 모든 악의 근원 |
| 파킨슨 법칙 | 업무는 할당된 시간만큼 늘어남 |
| 90-90 규칙 | 코드 90%가 개발 시간 90%를, 남은 10%가 나머지 90%를 소모 |
| 호프슈테터 법칙 | 예상보다 항상 더 오래 걸림 |
| 굿하트 법칙 | 측정이 목표가 되면 좋은 측정치가 아니게 됨 |
아키텍처와 품질
아키텍처 영역은 시스템 진화와 추상화의 본질을 설명한다.
| 법칙 | 핵심 내용 |
|---|---|
| 하이럼 법칙 | 충분한 API 사용자가 있으면 모든 동작에 의존함 |
| 골의 법칙 | 작동하는 복잡 시스템은 작동하던 단순 시스템에서 진화함 |
| 누수 추상화 법칙 | 모든 비자명 추상화는 어느 정도 누수됨 |
| 테슬러 법칙 | 모든 애플리케이션은 줄일 수 없는 기본 복잡성을 보유함 |
| CAP 정리 | 분산 시스템은 일관성, 가용성, 분할 허용성 중 2개만 보장 |
| 이계 효과 | 작은 성공 시스템은 과도하게 설계된 후속작으로 이어짐 |
품질 영역은 코드 유지보수와 디버깅에 관한 실용적 지침을 제공한다.
| 법칙 | 핵심 내용 |
|---|---|
| 보이스카우트 규칙 | 발견한 것보다 더 나은 상태로 코드를 남기기 |
| 머피 법칙 | 잘못될 수 있는 모든 것은 잘못됨 |
| 포스텔 법칙 | 보수적으로 행동하되 타방으로부터는 개방적으로 수용 |
| 깨진 유리창 이론 | 나쁜 설계나 낮은 품질 코드를 방치하지 말 것 |
| 리누스 법칙 | 눈이 충분하면 모든 버그는 표면화 |
| 커니핸 법칙 | 디버깅은 코딩보다 2배 어려움 |
| 테스트 피라미드 | 단위 테스트 많음, 통합 테스트 중간, UI 테스트 적음 |
핵심 통찰과 실무 적용
조직이 시스템을 결정한다
콘웨이 법칙은 1967년에 제시되었음에도 현대 마이크로서비스 아키텍처 논의에서 가장 자주 인용되는 원칙이다. 조직의 통신 구조가 설계하는 시스템에 그대로 반영된다는 관찰은, 아키텍처 재설계 시 조직 구조 자체를 먼저 검토해야 함을 시사한다. 역콘웨이 기동이라 불리는 전략은 원하는 아키텍처를 얻기 위해 먼저 팀 구조를 재편성하는 접근을 의미한다.
복잡성은 이동만 가능하다
테슬러 법칙은 모든 애플리케이션이 줄일 수 없는 기본 복잡성을 지닌다고 본다. 이 복잡성은 제거될 수 없고 다만 사용자와 개발자 사이에서 이동할 뿐이다. 개발자가 복잡성을 흡수하면 사용자 경험이 단순해지고, 사용자에게 복잡성을 노출하면 개발자 작업이 단순해진다. 굿하트 법칙은 KPI나 성과 지표 설계 시 반드시 고려해야 할 경고로, 지표가 목표가 되는 순간 본래의 측정 가치를 상실한다는 것이다.
설계 영역의 원칙들은 실무 코드 품질과 직결된다.
| 원칙 | 설명 |
|---|---|
| DRY | 모든 지식은 단일하고 명확한 권위 있는 표현 필요 |
| KISS | 설계와 시스템은 최대한 단순해야 함 |
| SOLID | 유지보수성과 확장성을 높이는 5가지 지침 |
| 데메테르 법칙 | 객체는 직접 친구와만 상호작용할 것 |
의사결정 영역에서는 인지 편향과 경험칙을 다룬다.
| 법칙 | 설명 |
|---|---|
| 던닝-크루거 효과 | 지식이 적을수록 자신감이 높음 |
| 행론의 면도날 | 악의보다 무능함으로 설명하는 것이 먼저 |
| 오컴의 면도날 | 가장 단순한 설명이 보통 정확함 |
| 매몰 비용 오류 | 이미 투자한 것만으로 선택을 고집하기 |
| 린디 효과 | 오래 사용된 것일수록 계속 사용될 가능성이 높음 |
| 파레토 원칙 | 80%의 문제는 20%의 원인에서 비롯됨 |
법칙을 둘러싼 논쟁
Hacker News에서 가장 뜨거운 논쟁은 “조기 최적화는 모든 악의 근원”이라는 1974년 Knuth의 원문 해석이다. 원문은 측정 없이 불필요한 최적화를 경고한 것이지만, 현대에는 아키텍처 선택 단계에서의 성능 고려가 필수라는 반박이 제기된다. 이 논쟁은 법칙을 맥락 없이 적용할 때 발생하는 위험을 보여준다.
또 다른 논점은 법칙들 사이의 내부 모순이다. 포스텔 법칙과 하이럼 법칙은 인터페이스 설계에서 긴장 관계를 만들고, DRY의 과도한 적용은 오히려 결합도를 높이는 역효과를 낳을 수 있다. 커뮤니티는 또한 LLM의 Vibe Coding 관행이 맥락 없이 원칙을 나열한다고 비판하며, 완벽한 법칙보다 반복적 개발과 유연한 아키텍처가 더 실용적이라고 본다.
결론
이 컬렉션이 전달하는 메시지는 법칙은 지침이지 교조가 아니라는 것이다. 소프트웨어 엔지니어링 법칙 컬렉션은 56가지 원칙을 체계화하여 제공하지만, 실제 적용은 경험과 맥락에 달려 있다. 팀, 계획, 아키텍처, 품질, 스케일, 설계, 의사결정이라는 7가지 영역은 서로 얽혀 있으며, 어떤 법칙을 우선할지는 프로젝트 단계와 제약 조건에 따라 달라진다. 중요한 것은 법칙을 암기하는 것이 아니라 언제 어떤 법칙을 따르고 언제 깨야 하는지 판단하는 능력이다.