콘웨이의 법칙 — 소프트웨어가 조직을 닮는 이유
개요
- 콘웨이의 법칙: 조직은 자신의 커뮤니케이션 구조를 그대로 반영하는 시스템 설계를 만들어낸다
- 기술적인 문제처럼 보이는 것들이 실제로는 조직 구조의 문제인 경우가 많다
- 시스템 아키텍처를 바꾸려면 조직 구조도 함께 바뀌어야 한다
도입 시나리오
- 레거시 모놀리식 시스템을 마이크로서비스로 전환 결정
- 팀 자율성과 소유권을 목표로 했지만 현실은 다름:
- 배포 시 여전히 타 팀 승인 필요
- 서비스 간 의존성으로 인한 팀 간 긴밀한 협업 강제
- 협업 비용으로 인한 업무 블로킹 발생
- 원인: 조직 구조는 그대로인 채 기술 아키텍처만 교체 → 콘웨이의 법칙의 역습
시스템은 조직을 닮는다
- 콘웨이의 법칙 원문: “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations”
- 조직의 커뮤니케이션 패턴이 결국 시스템 설계에 그대로 투영됨
조직 규모별 아키텍처 경향
| 조직 형태 | 특징 | 자연스럽게 도달하는 아키텍처 |
|---|---|---|
| 소규모, 같은 공간 | 상시 커뮤니케이션 가능 | 강한 결합(Tightly Coupled), 모놀리스 |
| 대규모, 다국적·분산 | 시간대·지역 분리 | 분산 시스템, 마이크로서비스 |
조직에 맞는 아키텍처
- 팀은 자연스럽게 자신의 커뮤니케이션 구조에 맞는 아키텍처에 수렴한다
- 맞지 않는 아키텍처를 강제하면 문제가 발생한다
소규모 팀의 경우
- 같은 사무실에서 일하는 소규모 팀 → 모놀리스 아키텍처가 자연스러운 선택
- 예시 구조:
- 백엔드/프론트엔드를 분리한 MVC 모놀리스
- React 앱 + REST API 형태도 동일한 철학
- 핵심: 팀이 소통이 용이하면 강한 결합 시스템도 효율적으로 운영 가능
대규모·분산 팀의 경우
- 미국 팀 + 동유럽 팀처럼 지역 분산 → 독립 배포 가능성이 필수
- 도메인 기준 분리 예시:
- 인보이싱(invoicing) 팀 vs. 멤버십(membership) 팀이 각자 서비스 소유
- UI 개발 팀과 백엔드 팀이 서로 다른 지역에서 운영
- 완전한 팀 자율성을 목표로 하는 조직 → 마이크로서비스가 자연스러운 귀결
- 조직 규모가 클수록 하나의 시스템처럼 움직이기 어려워짐 → 아키텍처 분산으로 대응
중요: 콘웨이의 법칙은 아키텍처의 적합성을 보장하지, 소프트웨어 품질을 보장하지 않는다. 조직에 맞는 아키텍처라도 결과물이 엉망일 수 있다.
콘웨이의 법칙과 싸울 수 없다
- 조직 구조가 뒷받침되지 않으면 원하는 시스템을 만들 수 없다
- 이를 무시하는 조직은 반드시 쓴 교훈을 얻게 된다
마이크로서비스 전환 실패의 전형적 패턴
- 모놀리스를 마이크로서비스로 전환 결정
- 조직 구조와 커뮤니케이션 채널은 변경하지 않음
- 구현 단계에서 계획과 다른 결과로 이어짐:
- 팀이 비용과 편의를 위해 기존 서비스에 기능을 추가 (코너 커팅)
- 분산 팀이 소유권 확보를 위해 로직을 별도 서비스로 임의 분리
- 결국 소프트웨어는 조직 구조를 그대로 반영하는 형태로 수렴
아무리 훌륭한 아키텍처 다이어그램으로 시작해도, 실제 구현은 조직의 커뮤니케이션 구조로 돌아간다.
올바른 전환을 위한 조건
- 엔지니어, 디자이너, 매니저가 기존 팀 해체 후 새로운 팀으로 재편성
- 각 팀이 업무에 대한 완전한 소유권(ownership) 획득
- 마인드셋 전환: 서비스 독립성과 자율 배포를 기본 전제로 수용
아키텍처가 조직을 바꿀 때
- 방향은 양방향: 조직 → 아키텍처뿐 아니라, 아키텍처 → 조직에도 영향을 미친다
- 사람은 함께 일하는 사람과 가장 많이 소통하게 됨
마이크로서비스가 조직에 미치는 영향
- 팀 간 독립성 강화:
- 각 팀 고유의 릴리즈 스케줄 운영
- 각 팀 고유의 빌드/배포 방식 채택
- 사일로(Silo) 현상 위험:
- 점심도, 팀 빌딩도 같은 팀끼리만 진행
- 팀이 외부와 단절된 캡슐처럼 고립될 수 있음
- 대응책: 지식 공유 채널 적극 유지, 팀 간 커뮤니케이션 의도적 촉진 필요
전략적 활용 방법
- 콘웨이의 법칙을 역으로 활용 (Inverse Conway Maneuver):
- 원하는 아키텍처를 먼저 설계
- 그 아키텍처에 맞게 조직 구조를 의도적으로 재편
- 변화를 위한 시스템을 구축할 때는 팀과 커뮤니케이션 구조를 설계의 중심에 놓아야 한다
- 조직이 시스템에 맞춰 구조를 바꿀 의지가 있을 때 가장 큰 성과를 얻는다
핵심 인사이트 요약
- 법칙의 본질: 소프트웨어 아키텍처는 기술 선택이 아니라 조직의 커뮤니케이션 구조의 산물이다
- 실패의 원인: 아키텍처만 바꾸고 조직 구조를 그대로 두면, 시스템은 결국 조직을 닮아간다
- 성공의 조건: 아키텍처 전환 시 팀 구조·소유권·커뮤니케이션 채널을 함께 재설계해야 한다
- 양방향 영향: 아키텍처가 조직 문화와 협업 패턴에도 영향을 주므로, 의도적인 관리가 필요하다