Foundations - 06. Conway's Law와 팀 토폴로지

도로가 도시를 만든다 — Conway's Law와 조직 구조

도시 계획자가 도로를 어떻게 깔았느냐가 사람들의 이동 패턴을 정한다. 큰 길이 지나는 곳에 상점이 모이고, 골목길만 있는 동네는 주거로 남는다. 도로가 먼저고, 그 도로를 따라 도시 구조가 형성된다. 도로를 바꾸면 사람들의 이동이 바뀌고, 결국 도시 모양이 바뀐다.

소프트웨어 조직도 비슷하다. 팀 간 소통 경로가 도로 역할을 하고, 그 소통 패턴을 따라 시스템 구조가 만들어진다. 모놀리스를 마이크로서비스로 쪼갠 팀이 1년 뒤 분산 모놀리스를 얻는 이유가 여기에 있다 — 서비스 경계를 도메인에 맞춰 나누고 각자 데이터베이스를 뒀지만, 팀 구조는 모놀리스 시절 그대로라 한 팀이 모든 서비스를 건드렸고 배포도 한꺼번에 일어났다. 도로(소통 구조)를 안 바꿨으니 도시(시스템)도 안 바뀐 것이다.

이것이 Conway's Law(콘웨이의 법칙)다. 1968년 멜빈 콘웨이의 관찰로, 아키텍처와 조직이 뗄 수 없음을 가리킨다.

이 비유의 한계: 도시는 물리적이고 느리게 변하지만, 소프트웨어 조직은 동적이고 소통 경로가 도로처럼 눈에 보이지 않는다. 도로망 비유는 정적 구조에 맞고, 동적인 팀 재편은 뒤에 따로 다룬다.

콘웨이의 원래 진술

콘웨이는 1968년에 이렇게 썼다: 시스템을 설계하는 조직은 그 조직의 의사소통 구조를 복제한 구조를 만들어내게 제한된다. 조직도 상자가 아니라 사람들이 실제로 소통하는 경로가 핵심이다. 여러 팀에 걸친 인터페이스를 설계하려면 팀 간 소통이 필요하고, 소통이 잦은 사람들 사이에선 인터페이스가 자연스럽게 잘 짜인다. 반대로 서로 소통하지 않는 팀들이 만든 부분은 이음새가 어색하다 — 각자 자기 부분을 최적화하느라 전체가 조화롭지 못하다.

이것은 비관론이 아니라 관찰이다. 그리고 이 관찰이 시사하는 전략이 inverse Conway maneuver(역콘웨이 기동)다: 원하는 아키텍처를 먼저 정하고, 그 아키텍처가 요구하는 소통 구조에 맞춰 팀을 재편하면, 조직의 자연스러운 흐름이 그 아키텍처를 만들어낸다. 도시 계획으로 돌아가면, 원하는 도시 구조를 정하고 그에 맞게 도로를 까는 것이다. Skelton과 Pais가 에서 정식화한 접근이다.

MIT의 검증 — 법칙은 실제로 성립한다

이 법칙이 격언이 아니라는 걸 보인 실증이 있다. MIT의 MacCormack 등은 오픈소스와 사내 시스템을 조사해 조직 구조가 제품 구조를 얼마나 정확히 예측하는가를 측정했다. 예측력이 높았다 — 소통이 밀접한 그룹이 만든 부분은 한 덩어리로 묶여 있었고, 소통이 없는 그룹의 경계는 제품의 모듈 경계와 일치했다.

아키텍처를 "기술적 결정"으로만 다루면 조직이 그 아키텍처를 다시 자기 구조로 끌어당긴다. 콘웨이의 법칙은 의식하든 아니든 작동한다. 그래서 성공적인 아키텍처 변화는 거의 항상 조직 변화와 짝을 이룬다.

팀 토폴로지 — 조직을 아키텍처에 맞추는 어휘

Matthew Skelton과 Manuel Pais는 콘웨이의 법칙을 실천적으로 펼친 팀 토폴로지(Team Topologies)를 제안했다. 팀을 네 가지 유형과 세 가지 상호작용 모드로 분류한다.

팀 유형	하는 일	비고
스트림 정렬(stream-aligned)	한 가치 흐름을 종단간 책임	가장 많아야 함 — 대다수 팀은 이 유형
플랫폼(platform)	다른 팀이 쓰는 내부 플랫폼을 "제품"으로 제공	"X-as-a-service"
지원(enabling)	다른 팀이 새 기술·실천을 습득하도록 일시적 돕기	영구적이지 않음
복잡 하위 시스템(complicated-subsystem)	전문 지식이 크게 필요한 특정 하위 시스템	드물어야 함

세 가지 상호작용 모드는 협업(collaboration, 한 팀이 다른 팀과 긴밀히, 일시적), 협업(x-as-a-service, 플랫폼 팀이 서비스 제공, 가장 일반적), 촉진(facilitating, 지원 팀이 학습을 돕는 관계)이다.

아키텍처의 경계는 팀의 경계와 일치해야 한다. 스트림 정렬 팀 하나가 한 서비스(또는 한 묶음)를 독립적으로 배포할 수 있어야, 마이크로서비스의 약속(독립 배포·장애 격리)이 현실이 된다. 한 서비스를 여러 팀이 건드리면 콘웨이의 법칙이 작동해 그 서비스는 사실상 모놀리스의 조각이 된다.

인지 부하가 경계를 정하는 진짜 제약

팀 하나가 한 서비스를 책임져야 하는 이유는 인지 부하(cognitive load)에 있다. Skelton과 Pais가 강조하는 제약이다. 한 팀이 감당할 수 있는 복잡성에는 한계가 있다. 서비스가 너무 크거나 도메인이 넓어 인지 부하를 초과하면, 팀은 그 서비스를 "이해하고 변경"하는 능력을 잃는다.

서비스 경계를 정하는 실용적 기준은 한 팀이 인지 부하 내에서 이해하고 운영할 수 있는 크기로 자르는 것이다. 도메인 경계(DDD의 바운디드 컨텍스트)와 만나면 — 하나의 바운디드 컨텍스트가 대략 한 팀의 인지 부하에 맞는다. 도메인 주도 설계와 팀 토폴로지가 이 지점에서 만난다.

인지 부하 관점에서 보면 "서비스를 작게 쪼갤수록 좋다"는 말도 틀리다. 서비스가 너무 작아져 한 팀이 수십 개를 떠안으면 그 팀의 인지 부하가 폭발한다. 작은 서비스의 이점(독립 배포)보다 운영 부담이 커지는 지점이 있다. 균형이 필요하고, 그 균형의 척도가 인지 부하다.

역콘웨이 기동 — 도로를 먼저 깐다

콘웨이의 법칙을 이용하는 전략은 세 단계다. 원하는 아키텍처를 먼저 정한다 — 도메인 기반의 서비스 경계 등. 그 경계에 맞춰 팀을 재편한다 — 한 서비스(또는 한 묶음)를 한 스트림 정렬 팀이 책임지도록. 불가피한 교차를 플랫폼·지원 팀으로 흡수한다 — 공통 인프라는 플랫폼 팀이 서비스로, 일시적 학습은 지원 팀이.

이것이 inverse Conway maneuver다. 조직이 아키텍처를 따르게 하면 조직의 자연스러운 흐름이 원하는 방향으로 작동한다 — 팀 경계가 곧 서비스 경계가 되고 독립 배포가 자연스러워진다. 반대로 조직을 그대로 둔 채 아키텍처만 바꾸면, 조직이 구조를 다시 자기 모양으로 끌어당긴다. 도로를 안 바꾸고 도시만 바꾸려 하는 것과 같다 — 사람들은 여전히 옛 도로로 다니고, 도시 모양도 옛 모양으로 돌아간다.

설계 사례 — 조직 재편으로 분산 모놀리스에서 독립 서비스로

한 팀이 모놀리스를 마이크로서비스로 쪼갰지만, 조직은 그대로였다. 결과는 분산 모놀리스 — 서비스는 여럿이지만 한 팀이 전부 건드리고, 배포도 한꺼번에 일어났다. 서비스 경계가 팀 경계와 일치하지 않았기 때문이다.

flowchart TB
    subgraph Before["Before: 조직 재편 전 (분산 모놀리스)"]
        Team1["전담 팀 (10명)"] -. 관리 .-> S1["주문 서비스"]
        Team1 -. 관리 .-> S2["결제 서비스"]
        Team1 -. 관리 .-> S3["배송 서비스"]
        Note1["한 팀이 3개 서비스를 전부 건드림<br/>배포 조정 필요, 독립성 없음"]
    end
    subgraph After["After: 역콘웨이 기동 (팀 재편)"]
        TeamA["주문 팀 (4명)"] -. 관리 .-> SA["주문 서비스"]
        TeamB["결제 팀 (3명)"] -. 관리 .-> SB["결제 서비스"]
        TeamC["배송 팀 (3명)"] -. 관리 .-> SC["배송 서비스"]
        Note2["한 팀이 한 서비스 담당<br/>독립 배포, 독립 일정"]
    end
    Before --> After

재편 전, 전담 팀 10명이 주문·결제·배송 세 서비스를 전부 건드렸다. 서비스를 쪼갰지만 "누가 무엇을 책임지는가"는 명확하지 않았다 — 누구나 모든 서비스의 PR을 리뷰하고, 모든 서비스 배포에 전 팀이 참여했다. 독립 배포라는 마이크로서비스의 약속이 현실이 안 됐다.

역콘웨이 기동으로 팀을 재편한다. 먼저 원하는 아키텍처(서비스별 독립 배포)를 정하고, 그 아키텍처가 요구하는 팀 구조로 재편한다 — 한 서비스(또는 한 묶음)를 한 스트림 정렬 팀이 책임지도록. 주문 팀 4명은 주문 서비스만, 결제 팀 3명은 결제 서비스만, 배송 팀 3명은 배송 서비스만 담당한다.

재편 직후에 마찰이 생긴다. 결제 팀이 주문 서비스의 주문 도메인 구조를 알아야 하는데, 이제 주문 팀이 그걸 관리한다 — 두 팀이 협업해야 한다. 이 협업이 처음엔 느리다. 하지만 API 계약(인터페이스)을 정의하고, 그 뒤로 각 팀이 자율적으로 움직이기 시작하면, 배포 주기가 팀마다 독립적으로 돌아간다. 주문 팀은 주간 배포, 결제 팀은 일간 배포, 배송 팀은 격주 배포 — 서로 기다리지 않는다.

이 재편의 핵심 — 코드를 먼저 바꾸는 게 아니라 도로를 먼저 까는 것이다. 소통 경로(팀 구조)를 서비스 경계에 맞추면, 코드 구조가 그것을 따라간다. 도로를 안 바꾸고 도시만 바꾸려 하면, 사람들은 여전히 옛 도로로 다닌다.

도로가 도시를 만든다

아키텍처를 바꾸겠다고 결심하면 코드베이스만 보지 않는 편이 낫다. 먼저 물어야 할 것은 "현재 우리 팀 구조에서, 이 아키텍처가 자연스럽게 유지될 수 있는가"다. 답이 아니라면 조직을 먼저 재편하지 않는 한 그 아키텍처는 존재하지 않는다. 도로가 도시를 만들듯, 소통 구조가 시스템 구조를 만든다 — 콘웨이의 법칙은 허락을 구하지 않고 작동한다.

---

참고

• Conway, Melvin — "How Do Committees Invent?" (Datamation, 1968) — 접근 2026-07-15
• MacCormack, Rusnak, Baldwin — "Exploring the Duality between Product and Organizational Architecture" (Research Policy, 2012)
• Skelton, Matthew; Pais, Manuel — (IT Revolution, 2019)
• Richards, Ford — (O'Reilly, 2020), Ch.18