---
id: P-REINFORCE-WIKI-AE24AEA7
category: "10_Wiki/💡 Topics/05_Cognitive_Engineering"
confidence_score: 0.95
tags: ["conway's-law-(콘웨이의-법칙)", 'layered-architecture', 'macro-architecture', 'the-mythical-man-month', 'team-topologies', 'cognitive-engineering']
last_reinforced: 2026-05-02
---

# [[Conway's Law (콘웨이의 법칙)]]

## 📌 Brief Summary
콘웨이의 법칙(Conway's Law)은 1967년 컴퓨터 프로그래머 멜빈 콘웨이(Melvin Conway)가 처음 관찰한 개념으로, 시스템을 설계하는 조직은 해당 조직의 의사소통 구조를 그대로 복제한 설계를 만들어내도록 제약을 받는다는 인지적 제약(Cognitive constraints)을 의미합니다 [1]. 이 용어는 프레드 브룩스(Fred Brooks)가 자신의 저서 '맨먼스 미신(The Mythical Man-Month)'에서 인용하면서 대중적으로 널리 알려지게 되었습니다 [1]. 

## 📖 Core 소스
* **조직 구조와 아키텍처의 동기화:** 콘웨이의 법칙의 관점에서 볼 때, 소프트웨어 아키텍처는 단순히 내부 설계 방식에 그치는 것이 아니라 **코드베이스와 팀 구조를 모두 형성하는 거시적 아키텍처(macro-architecture)의 성격**을 띱니다 [2].
* **계층형 아키텍처와의 매핑 사례:** 이 법칙이 적용되는 대표적인 예가 계층형 아키텍처(Layered Architecture)입니다. 아키텍처의 수평적 분할(horizontal slices)은 종종 실제 조직의 업무 그룹과 직접적으로 매핑됩니다 [2]. 
  * **프레젠테이션 계층(Presentation Layer):** UI/UX 팀 (예: React 개발자) [2]
  * **비즈니스 계층(Business Layer):** 백엔드 팀 (예: Java 개발자) [2]
  * **데이터베이스 계층(Database Layer):** 데이터베이스 관리자(DBA) [2]

## ⚖️ Trade-offs & Caveats
소스에 관련 정보가 부족합니다. 

(다만, 제공된 소스의 맥락에 따르면, 시스템을 설계하는 조직은 **자신들의 의사소통 구조를 복제한 설계를 만들도록 인지적으로 '제약(constrained)'을 받는다는 점 자체**가 가장 큰 제약 사항입니다 [1]. 즉, 기술적으로 다른 아키텍처 패턴이 더 적합한 상황이라 하더라도, 개발 조직이 UI, 백엔드, DB 부서로 분리되어 있다면 조직 구조의 한계로 인해 자연스럽게 계층형 아키텍처(Layered Architecture)와 같은 형태로 설계가 고착화될 수 있다는 부작용을 내포하고 있습니다 [1, 2].)

## 🔗 Knowledge Connections

### Related Concepts

#### [조직 및 아키텍처 설계 구조]
- [[Layered Architecture]]
  - 연결 이유: 콘웨이의 법칙이 소프트웨어 설계에 어떻게 투영되는지를 가장 명확하게 보여주는 매크로 아키텍처 패턴 사례이기 때문입니다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처의 기술적 계층 분리가 실제 사람으로 구성된 조직 그룹(UI/UX 팀, 백엔드 팀, DBA 등)과 어떻게 결합되고 매핑되는지 이해할 수 있습니다 [2].
  
- [[Macro-architecture]]
  - 연결 이유: 콘웨이의 법칙적 관점에서 볼 때, 특정 아키텍처 패턴은 단순한 내부 구현(micro)을 넘어 팀과 코드베이스의 구조를 결정짓는 거시적 설계 요소로 작용하기 때문입니다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시스템 아키텍처가 조직의 의사소통 방식 및 구조와 상호작용하는 거시적 영향을 파악할 수 있습니다 [1, 2].

### Deeper Research Questions
- 계층형 아키텍처에서 벗어나 마이크로서비스 아키텍처(MSA)나 이벤트 기반 아키텍처로 전환할 때, 콘웨이의 법칙에 따라 조직 구조는 어떻게 변경되어야 하는가?
- 조직의 의사소통 구조가 독립적인 교차 기능 팀(cross-functional teams)으로 구성될 경우 시스템 아키텍처 설계에 어떤 변화가 일어나는가?
- 아키텍처 설계가 조직 구조를 결정하는가, 아니면 조직 구조가 아키텍처 설계를 결정하는가에 대한 실무적 딜레마는 어떻게 해결할 수 있는가?
- 프레드 브룩스의 '맨먼스 미신'에서 콘웨이의 법칙을 어떻게 소프트웨어 공학의 복잡성 문제와 연결하여 설명하고 있는가?
- 조직 구조의 한계(Cognitive constraints)를 우회하거나 극복하고 시스템에 최적화된 아키텍처를 도입하기 위한 개발 팀의 커뮤니케이션 전략은 무엇인가?

### Practical Application Contexts
- **Implementation:** 소스에 관련 정보가 부족합니다.
- **System Design:** 소프트웨어 아키텍처를 설계할 때 기술적 요구사항뿐만 아니라, 해당 시스템을 구현할 개발 조직의 구조(예: 프론트엔드, 백엔드, 인프라 팀 등의 분할 상태)가 설계 결과물에 직접적인 영향을 미치고 제약으로 작용한다는 점을 인지하여 매크로 아키텍처를 결정해야 합니다 [1, 2].
- **Operation / Maintenance:** 소스에 관련 정보가 부족합니다.
- **Learning Path:** 소프트웨어 아키텍처가 단순한 기계적 설계가 아니라, 팀 간의 소통 방식과 조직도에 영향을 받는 '인지적 제약(Cognitive constraints)'의 결과물임을 이해하는 소프트웨어 공학의 기초 개념으로 학습됩니다 [1, 2].
- **My Project Relevance:** 소스에 관련 정보가 부족합니다.

### Adjacent Topics
- [[The Mythical Man-Month]]
  - 확장 방향: 콘웨이의 법칙을 대중에게 널리 알린 프레드 브룩스의 저서를 통해, 소프트웨어 개발 인력의 소통 구조와 프로젝트 관리의 복잡성에 대한 이해도를 확장할 수 있습니다 [1].
- [[Team Topologies]]
  - 확장 방향: 마이크로서비스 아키텍처를 성공적으로 구현하기 위해, 조직 구조를 느슨하게 결합된 교차 기능 팀(loosely coupled, cross-functional teams)으로 구성하는 방법론과 콘웨이의 법칙 간의 연관성을 탐구할 수 있습니다 [3, 4].

---
*Last updated: 2026-05-02*