콘웨이의 법칙 편집하기

[[분류:소프트웨어 공학]]
콘웨이의 법칙(Conway’s Law)은 조직이 설계하는 시스템의 구조가 그 조직의 커뮤니케이션 구조를 그대로 반영한다는 통찰이다.
==개요 ==
“어떤 조직이 시스템을 설계한다면, 그 조직의 커뮤니케이션 구조의 복사본과 같은 구조를 갖는 설계를 산출하게 된다.” — 멜빈 E. 콘웨이.<ref>[https://www.melconway.com/Home/pdf/committees.pdf Conway, Melvin E. “How Do Committees Invent?” Datamation, April 1968. pp. 28-31.]</ref>  즉, 조직의 팀 구성, 부서 간 경계, 커뮤니케이션 흐름이 시스템의 컴포넌트 간 의존성, 모듈 간 인터페이스, 아키텍처의 분할 방식 등에 반영된다는 것이다.<ref>[https://www.atlassian.com/blog/teamwork/what-is-conways-law-acmi Gilson, Nathania. “Conway’s Law: the little-known principle that influences your work more than you think.” Atlassian Blog, 2021.]</ref>
==역사==
1967년, 멜빈 E. 콘웨이는 “How Do Committees Invent?”이라는 논문을 발표하였다.<ref>[https://www.melconway.com/Home/pdf/committees.pdf Conway, Melvin E. “How Do Committees Invent?” Datamation, 1968.]</ref>  이 논문은 이후 《맨먼스 미신(The Mythical Man-Month)》(프레드 브룩스 저) 등에서 인용되며 “콘웨이의 법칙”이라는 이름으로 널리 퍼졌다.<ref>[https://martinfowler.com/bliki/ConwaysLaw.html Fowler, Martin. “Conway’s Law.” Martin Fowler Blog, 2022.]</ref>
==주요 내용 및 해석==
===조직 구조 ↔ 시스템 구조===
*조직의 팀 구성, 부서 간 경계, 커뮤니케이션 채널이 시스템 설계에 반영된다.<ref>[https://www.atlassian.com/blog/teamwork/what-is-conways-law-acmi Gilson, Nathania. Atlassian Blog, 2021.]</ref>
*예컨대 조직이 프런트엔드·백엔드·데이터베이스로 팀을 나눠 운영한다면, 개발된 시스템도 데이터 → 백엔드 → 프런트엔드라는 계층 구조로 분할될 가능성이 높다.
*반대로, 시스템 아키텍처를 먼저 정하고 인력 구성이나 팀 구조를 나중에 맞추려 할 때, 조직과 설계 간의 불일치로 인해 비효율과 마찰이 발생할 수 있다.
===대응 전략===
*받아들임(Accept) : 조직 구조가 설계에 미치는 영향을 인식하고, 팀 구성과 커뮤니케이션 구조를 설계 목표에 맞게 정비한다.
*역(逆) 콘웨이 조작(Inverse Conway Maneuver) : 설계하고자 하는 시스템 구조에 맞춰 조직 구조를 의도적으로 재설계하는 접근법이다.
*무시(Ignore) : 조직 구조·커뮤니케이션 흐름을 고려하지 않고 설계하면, 결국 조직 내부의 경계와 흐름이 시스템에 나타나 버릴 수 있다.
==적용 사례 및 의미==
*조직이 여러 독립 팀으로 나뉘어 수평적 커뮤니케이션보다는 내부 위주 커뮤니케이션 구조를 갖고 있다면, 시스템도 모듈 간 통합이 약하고 서로 고립된 구조가 될 가능성이 높다.
*반대로 크로스펑셔널 팀(개발·운영·품질 등으로 구성)이나 자율적인 팀이 많고 커뮤니케이션 흐름이 자유롭다면, 시스템 또한 자율 모듈화된 구조로 설계되기 쉽다.
*최근 마이크로서비스, DevOps, 팀 토폴로지(Team Topologies) 같은 조직 설계 패러다임이 콘웨이의 법칙을 고려한 사례로 많이 언급된다.
==장점과 제한==
===장점===
*조직 구조가 설계 품질에 미치는 영향을 명확히 보여줌으로써 조직 설계·팀 구성의 중요성을 부각한다.
*기술적 아키텍처뿐 아니라 조직 문화·커뮤니케이션 방식·팀 경계까지 고려하게 만든다.
*설계 목표가 조직 구조에 의해 제한될 수 있다는 인식을 통해 구조적 제약을 사전에 인지할 수 있게 한다.
===제한 및 주의점===
*“법칙”이라는 명칭이 붙어 있지만 엄격한 과학적 법칙이 아니라 관찰된 경향 또는 지침이다.<ref>[https://thinkinsights.net/strategy/conways-law Think Insights. “Conway’s Law.” 2022.]</ref>
*조직 구조 외에도 기술적 제약, 시장 환경, 제품 전략 등 다양한 요인이 설계 결과에 영향을 준다.
*조직 구조를 바꾼다고 해서 즉시 시스템 구조가 바뀌는 것은 아니며, 변화에는 시간과 비용이 수반된다.
==현대적 함의==
오늘날 소프트웨어 아키텍처·디지털 조직 설계 측면에서 콘웨이의 법칙은 다음과 같은 의미를 갖는다.
*팀을 기능(feature) 중심으로, 비즈니스 역량(business capability) 중심으로 구성하면 설계된 시스템도 이러한 역량에 맞춰 모듈화될 가능성이 높다.
*리모트·분산 근무 환경에서는 물리적 거리보다 온라인상 커뮤니케이션 패턴이 조직 및 시스템 구조에 더 큰 영향을 준다.
*조직 재구성이나 팀 경계 재설계가 시스템 아키텍처 변화의 중요한 부분이 될 수 있다.
==같이 보기==
*[[소프트웨어 아키텍처]]
*[[마이크로서비스 아키텍처]]
*[[DevOps]]
*[[조직 설계]]
*[[팀 토폴로지(Team Topologies)]]
==참고 문헌==

* [https://www.melconway.com/Home/pdf/committees.pdf Conway, Melvin E. “How Do Committees Invent?” Datamation, 1968.]

==각주==
<references />