소프트웨어 공학 100 주제 시리즈의 7번째 글이다. (카테고리: 기초와 역사)

한 줄 요약

시스템을 설계하는 조직은 자기 조직의 소통 구조를 복사한 설계를 만들게 된다. Melvin Conway 가 1968년 논문에서 제시했고 Fred Brooks 가 “Conway 의 법칙” 이라고 이름 붙였다. 아키텍처를 바꾸고 싶으면 팀 구조와 소통 경로를 함께 봐야 한다는 뜻이다.

왜 필요한가

아키텍처 회의에서 깔끔한 서비스 경계를 그렸는데, 1년 뒤 실제 시스템은 전혀 다른 모양인 경우가 흔하다.

  • “주문” 과 “재고” 를 분리하기로 했는데, 같은 팀이 둘을 맡다 보니 서로의 테이블을 직접 읽는 코드가 생겼다.
  • 프론트엔드·백엔드·DBA 팀으로 나눈 조직에서는 기능 하나를 내기 위해 세 팀이 줄을 서고, 시스템도 기능 단위가 아니라 기술 레이어 단위로 굳는다.
  • 시차가 큰 두 지역 팀이 같이 만든 모듈의 경계에는 유독 두꺼운 어댑터와 오해가 쌓인다.

이것은 개발자의 규율 부족이 아니다. 코드는 대화가 쉬운 곳에서 쉽게 결합되고, 대화가 어려운 곳에서 끊어진다. Conway 의 법칙을 모르면 이 힘과 싸우다 지고, 알면 이 힘을 설계 도구로 쓸 수 있다.

핵심 개념

원문과 이름의 유래

Conway 본인 사이트의 Conway’s Law 페이지에 따르면, 그는 1967년 “How Do Committees Invent?” 를 Harvard Business Review 에 투고했으나 논제를 증명하지 않았다는 이유로 거절당했고, 당시 주요 IT 잡지였던 Datamation 이 1968년 4월에 실었다. 논문 전문은 그의 사이트에 있다. Brooks 가 The Mythical Man-Month 에서 이 논문을 인용하며 “Conway’s Law” 라고 불렀고, 그 이름이 굳었다.

Conway 가 직접 제시한 논제의 한 형태는 이렇다.

시스템(넓은 의미)을 설계하는 모든 조직은 그 조직의 소통 구조를 복사한 구조의 설계를 만든다.

논문 결론부의 원래 표현은 “시스템을 설계하는 조직은 … 그 조직의 소통 구조의 복사본인 설계를 만들도록 제약된다(constrained)” 이다. 조언이 아니라 제약에 대한 관찰이다.

수학적 골격: 준동형

Conway 는 이 관계를 그래프의 준동형(homomorphism) 으로 설명한다. 시스템을 하위 시스템과 인터페이스의 그래프로, 설계 조직을 설계 그룹과 소통 경로의 그래프로 보면, 같은 설계 그룹이 맡은 하위 시스템들은 조직 그래프의 한 노드로 접힌다. 두 하위 시스템이 연결되려면 그것을 맡은 사람들이 소통해야 하므로, 시스템의 구조를 보존하는 사상이 조직 쪽으로 존재한다.

시스템 그래프                          설계 조직 그래프
 [A]──[B]                              (팀1: A,B)
  │    │            준동형 사상  ⇒          │
 [C]──[D]──[E]                         (팀2: C,D)──(팀3: E)

거꾸로 읽으면 실무적 함의가 나온다. 조직 그래프에 경로가 없는 곳에는 시스템 인터페이스도 제대로 생기지 않는다.

조직을 고르는 순간 설계가 정해진다

논문의 “설계 단계” 절은 더 날카롭다. 설계 팀을 조직하는 행위 자체가 이미 어떤 설계 결정을 내린 것이고, 어떤 조직이든 필요한 소통 경로가 없어서 효과적으로 추구할 수 없는 설계 대안의 집합이 존재한다. 그래서 Conway 는 “조직되어 있으면서도 편향되지 않은 설계 그룹은 없다” 고 쓴다. 위임이 일어날 때마다 누군가의 탐색 범위가 좁아지고, 고려할 수 있는 설계 대안도 줄어든다.

큰 시스템이 무너지는 세 단계

Conway 는 큰 시스템의 구조가 개발 중 붕괴하는 과정을 세 단계로 설명한다. 앞의 둘은 통제 가능하고, 셋째는 준동형의 직접적 결과다.

  1. 시스템이 클 것이라는 인식과 조직의 압력 때문에 설계에 너무 많은 사람을 투입하고 싶은 유혹을 이기기 어렵다.
  2. 큰 설계 조직에 관습적인 관리 방식을 적용하면 소통 구조가 분열된다.
  3. 준동형 때문에 시스템 구조가 그 분열을 그대로 반영한다.

그는 관리자의 위신과 권한이 예산 규모에 묶여 있는 한 조직을 키우려는 동기가 생긴다는 점(파킨슨의 법칙)도 지적한다. 결론부의 처방은 이렇다. 설계 조직은 소통의 필요에 따라 구성해야 하고, 처음 나온 설계가 최선인 경우는 거의 없으므로 조직의 유연성이 중요하다. 그리고 “인력을 추가하면 생산성이 그만큼 늘어난다는 가정에 기대지 않는 설계 관리 철학” 이 필요하다고 맺는다. 7년 뒤 Brooks 의 책과 같은 결론이다(SE100 #003).

실증 연구: 미러링 가설

MacCormack, Rusnak, Baldwin 은 이 관계를 소프트웨어에서 검증했다(HBS Working Paper 08-039; 학술지판 Research Policy 41(8), 2012). 같은 기능을 하는 제품을 서로 다른 형태의 조직이 만든 쌍을 비교하는 자연 실험이다.

조직 유형 특징 결과
상용 소프트웨어 회사 목표·구조·행동이 강하게 결합(tightly-coupled) 덜 모듈화된 제품
오픈소스 커뮤니티 상대적으로 느슨하게 결합(loosely-coupled) 더 모듈화된 제품

연구진은 조사한 모든 쌍에서 느슨한 조직의 제품이 유의미하게 더 모듈화되어 있었고, 한 구성요소의 설계 변경이 다른 구성요소로 전파될 가능성에서 차이가 최대 8배였다고 보고한다.

세 가지 대응

Martin Fowler 는 ConwaysLaw에서 대응을 세 가지로 정리한다.

대응 내용
무시(Ignore) 법칙을 모르거나 적용되지 않는다고 생각한다. (그래도 적용된다)
수용(Accept) 아키텍처가 설계자들의 소통 패턴과 충돌하지 않게 맞춘다
역 Conway 기동(Inverse Conway Maneuver) 원하는 아키텍처를 유도하도록 설계자들의 소통 패턴을 바꾼다

Fowler 가 전하는 사례가 인상적이다. 여섯 도시의 여섯 팀으로 구성된 대형 프로젝트의 아키텍트가 “첫 아키텍처 결정을 내렸다. 주요 하위 시스템은 여섯 개다. 그게 뭔지는 아직 모른다” 고 말했다는 것이다. 위치와 시차가 소통을 어떻게 제한하는지 인정하고 그에 맞춰 설계한 결정이다. 같은 글에 따르면 “역 Conway 기동” 이라는 용어는 Jonny LeRoy 와 Matt Simons 가 2010년 12월 Cutter IT Journal 기고에서 만들었다.

Fowler 는 경고도 붙인다. 역 Conway 기동은 유용하지만 만능이 아니다. 이미 경직된 아키텍처를 가진 시스템에서 조직만 바꾸면 즉시 해결되기보다 개발자와 코드 사이의 불일치가 생겨 마찰이 늘 수 있다.

실무 적용

팀과 서비스의 대응표 만들기

조직도와 서비스 목록을 나란히 놓고 어긋남을 찾는다.

# 서비스 ↔ 팀 소유권 점검 (예시)
services:
  order-api:      { owner: checkout-team }
  payment-api:    { owner: checkout-team }      # 같은 팀이 두 서비스 → 경계가 흐려질 위험
  inventory-api:  { owner: fulfillment-team }
  shared-db:      { owner: [checkout-team, fulfillment-team] }   # 소유자 둘 → 경계 붕괴 신호
  notification:   { owner: null }               # 소유자 없음 → 아무도 바꾸지 않는다
cross_team_changes_last_quarter:
  - { pr_count: 37, teams: [checkout-team, fulfillment-team], via: shared-db }

여러 팀이 늘 함께 고치는 지점(위 예의 shared-db)이 바로 조직 구조와 시스템 구조가 어긋난 곳이다. 둘 중 하나를 바꿔야 한다. 테이블 소유를 한 팀으로 모으고 다른 팀은 API 로 접근하게 하거나, 그 영역을 맡는 팀을 새로 정의한다.

팀 설계 어휘

Team Topologies 는 역 Conway 기동을 실무 어휘로 정리한 접근이다. 네 가지 기본 팀 유형(스트림 정렬, 활성화, 복잡한 하위 시스템, 플랫폼)과 세 가지 상호작용 방식(협업, X-as-a-Service, 촉진)을 정의한다. 팀 사이 상호작용 방식을 명시하면, 시스템 사이 인터페이스의 성격도 함께 정해진다. 예를 들어 X-as-a-Service 관계인 두 팀 사이에는 안정된 API 계약이 생긴다.

점검 질문:

  • 기능 하나를 출시하는 데 몇 팀이 관여하는가? 셋 이상이면 시스템이 기술 레이어 단위로 굳고 있을 가능성이 크다.
  • 서비스 경계와 팀 경계가 일치하는가? 한 서비스를 두 팀이 나눠 갖고 있지 않은가?
  • 원격·시차 환경에서 자주 바뀌는 인터페이스가 시간대 경계를 가로지르지 않는가?

흔한 오해와 함정

  • “Conway 의 법칙은 농담이다.” Conway 가 자기 페이지에 인용해 둔 설명은, 이것이 농담이 아니라 유효한 사회학적 관찰이며, 두 모듈은 그 설계자들이 소통하지 않으면 제대로 맞물릴 수 없다는 사실의 귀결이라고 설명한다.
  • “마이크로서비스를 도입하면 팀이 자율적이 된다.” 순서가 반대다. 자율적인 팀 구조 없이 서비스만 쪼개면 분산된 모놀리스가 된다(마이크로서비스 vs 모놀리스).
  • “조직 개편만 하면 아키텍처가 따라온다.” Fowler 의 경고대로, 기존 경직된 시스템에서는 조직 개편이 오히려 불일치를 만든다. 코드 경계와 팀 경계는 함께 옮겨야 한다.
  • “작은 팀에도 중요하다.” Fowler 는 십여 명 정도는 깊고 비공식적인 소통이 가능해 모놀리스를 만들게 되고, 그것은 괜찮다고 쓴다. 법칙이 의사결정에 영향을 줘야 하는 것은 사람을 조직해야 할 규모부터다.

확인 문제

  1. Conway 가 직접 제시한 법칙의 한 문장 형태는?
  2. 논문에서 “조직되어 있으면서도 편향되지 않은 설계 그룹은 없다” 고 말하는 이유는?
  3. MacCormack 등의 연구는 어떤 방법으로 미러링 가설을 검증했고, 무엇을 발견했는가?
  4. 역 Conway 기동이란 무엇이며, Fowler 가 경고하는 한계는?
  5. 여러 팀이 같은 데이터베이스 테이블을 늘 함께 고친다면, Conway 의 법칙 관점에서 어떤 신호인가?

풀이

  1. 시스템(넓은 의미)을 설계하는 모든 조직은 그 조직의 소통 구조를 복사한 구조의 설계를 만든다.
  2. 설계 팀을 조직하는 행위가 이미 설계 결정을 포함하며, 어떤 조직이든 필요한 소통 경로가 없어 추구할 수 없는 설계 대안이 존재하기 때문이다.
  3. 같은 기능을 하는 제품을 상용 기업(강한 결합 조직)과 오픈소스 커뮤니티(느슨한 결합 조직)가 각각 만든 쌍을 비교했다. 모든 쌍에서 느슨한 조직의 제품이 더 모듈화되어 있었고, 변경 전파 가능성의 차이는 최대 8배였다.
  4. 원하는 아키텍처를 유도하도록 팀 구조와 소통 패턴을 의도적으로 바꾸는 것. 이미 경직된 아키텍처에서는 즉각적인 해결책이 아니며, 개발자와 코드 사이의 불일치로 마찰을 늘릴 수 있다.
  5. 조직 경계와 시스템 경계가 어긋나 있다는 신호다. 소유권을 한 팀으로 모으고 다른 팀은 인터페이스로 접근하게 하거나, 팀 경계를 다시 그어야 한다.

더 읽을거리 (References)