Melvin Conway는 1968년에 소프트웨어 아키텍트들이 수십 년 동안 무시해 왔고, 운영 중 사고가 발생할 때마다 재발견하며, 이후 기업 재편 과정에서 다시 무시하게 되는 관찰 결과를 발표했습니다:

"(광범위하게 정의된) 시스템을 설계하는 모든 조직은 조직의 커뮤니케이션 구조를 복사한 구조의 설계를 생성할 것이다."

이 문장은 기술에 관한 것이 아닙니다. 이는 어떤 도구로도 해결할 수 없는 제약 사항에 관한 것입니다. 만약 결제 팀이 리스크 분석 팀과 소통하지 않는다면, 결제 서비스는 리스크 API를 효율적으로 호출하지 못할 것이며, 애플리케이션의 의존성 그래프(dependency graph)는 이러한 침묵을 반영하게 될 것입니다.

여러분은 Draw.io에서 세상에서 가장 우아한 아키텍처를 그릴 수 있습니다. 서비스 메쉬 (service mesh), 이벤트 소싱 (event sourcing) 또는 도메인 주도 설계 (Domain-Driven Design (DDD))를 채택할 수도 있습니다. 하지만 여러분의 조직이 고립된 섬들의 집합이라면, 여러분의 아키텍처는 시스템들 사이의 다리가 극도로 취약한 독립적인 시스템들의 군도(archipelago)가 될 것입니다.

강요할 필요가 없는 법칙 — 스스로 실현된다

Conway의 법칙은 우리가 이 시리즈에서 이미 논의했거나 논의할 대부분의 "법칙"들과는 다릅니다. Gall의 법칙은 관찰된 진화 패턴을 설명합니다. Goodhart의 법칙은 잘못 적용된 지표의 부작용을 설명합니다. 반면 Conway의 법칙은 **피할 수 없는 제약 (inevitable constraint)**을 설명합니다.

이 법칙은 위원회에 의해 강요될 필요가 없습니다. 그것은 단순히 스스로 실현됩니다.

만약 두 그룹이 인터페이스를 조정해야 하는데 서로 소통하지 않는다면, API 계약(contract)은 계획되는 것이 아니라 운영 환경에서 즉흥적으로 만들어질 것입니다. 만약 세 개의 스쿼드 (squads)가 서로 충돌하는 목표를 가진 서로 다른 디렉터들에게 보고한다면, 아키텍처는 비즈니스 도메인의 논리가 아닌 회사의 조직도(organogram)의 참호(trenches)를 따르는 경계(bounded contexts)를 가진 세 개의 경계 맥락을 갖게 될 것입니다.

경험적 증거가 존재합니다. MIT와 Harvard Business School의 연구진이 주도한 고전적 연구(MacCormack et al., 2012)는 여러 기업의 조직 구조와 소프트웨어 아키텍처를 분석하여 강력한 수학적 상관관계를 발견했습니다. 즉, 코드의 모듈성(modularity)은 커뮤니케이션의 모듈성을 따릅니다. 유연하고 개방적으로 소통하는 팀은 더 좁은 인터페이스와 더 낮은 결합도(coupling)를 가진 코드를 생성합니다.

Gall의 법칙에 관한 기사에서 논의했듯이, 제대로 작동하는 복잡성은 유기적인 현실에서 추출된 것입니다. Conway의 법칙은 이러한 현실의 메커니즘을 설명합니다. 즉, 커뮤니케이션 흐름이 코드를 형성한다는 것입니다.

침묵이 어떻게 아키텍처가 되는가

조직도와 아키텍처 사이의 연결은 시적인 은유가 아닙니다. 이는 감사(audit) 가능한 물리적인 경로를 가지고 있습니다:

1. 인터페이스 정의: 두 팀이 서비스를 통합해야 할 때, 누군가는 계약(contract)을 정의해야 합니다. 팀들이 대화한다면 계약은 협상을 통해 이루어집니다. 대화하지 않는다면, 각 측은 상대방이 무엇을 하는지 추측하게 되며, 배포(deploy) 당일에 자신의 추측이 틀렸음을 깨닫게 됩니다.
2. 코드 소유권: 저장소(repository) 내의 코드를 오직 한 팀만이 수정할 수 있는 서비스는 경직된 경계를 만듭니다. 이러한 장벽은 비즈니스의 경계를 반영하기보다는, 메인 브랜치(branch)에 접근할 수 있는 권한의 경계를 반영하는 경우가 많습니다.
3. 배포 파이프라인 (deploy pipeline): 만약 팀 A가 팀 B와 수동으로 조율하지 않고는 기능을 출시할 수 없다면, 여러분이 아무리 많은 서로 다른 저장소를 가지고 있더라도 실질적인 아키텍처는 디커플링(decoupled)된 상태가 아닙.
4. 공유 데이터 모델: 동일한 데이터베이스 내의 동일한 테이블을 읽는 두 서비스는, 설령 서로 다른 서버에서 실행되더라도 독립적이지 않습니다. 데이터베이스가 비공식적인 커뮤니케이션 채널이 되어버린 것입니다.

의사결정 검토 (Revisão de decisões): 만약 이벤트 스키마를 변경하려는 결정이 세 개의 위원회를 거쳐야 한다면, 아키텍처는 오직 그 위원회들의 속도로만 진화합니다. 즉, 거의 진화하지 못한다는 뜻입니다.

이 효과를 시각화하는 가장 좋은 방법은 조직도 (organograma)와 그것이 만들어내는 의존성 그래프 (grafo de dependências)를 비교하는 것입니다:

graph LR
    subgraph Organograma
        D[Diretoria] --- G1[Gerente Pagamentos]
...

T1과 T2 사이의 커뮤니케이션 부재가 의존성을 제거하는 것이 아니라, 단지 그것을 암시적이고 취약하게 만든다는 점에 주목하십시오. 아무도 그 간선을 그리지 않았더라도 간선 (aresta)은 존재합니다.

이러한 각 지점은 의존성 그래프에 하나의 간선을 생성합니다. 그리고 Seis Graus até o Colapso에서 살펴볼 것처럼, 이 그래프의 구조가 운영 리스크 (risco operacional)를 결정합니다. Conway의 법칙은 왜 간선이 그 위치에 나타나는지를 설명합니다. 간선은 존재하는 인간 커뮤니케이션의 경로를 따라가며, 결여된 경로의 빈자리를 채웁니다.

"역 Conway (Reverse Conway)": 아키텍처를 구하기 위해 조직을 설계하기

2010년, Jonny LeRoy와 Matt Simons (ThoughtWorks 소속)는 이후 Jessica Kerr에 의해 널리 대중화될 용어인 **역 Conway 기법 (Reverse Conway Maneuver)**을 만들었습니다. 전제는 간단합니다. 현재의 조직도가 소프트웨어에 미치는 영향을 그대로 받아들이는 대신, 원하는 아키텍처가 생산되도록 팀 구조를 재설계하는 것입니다.

이것이 바로 Team Topologies (Matthew Skelton 및 Manuel Pais 저) 서적 뒤에 숨겨진 기술적 동력입니다. 유동적인 생태계를 구축하고자 한다면, 가치의 연속적인 흐름에 정렬된 팀들인 스트림 정렬 팀 (stream-aligned teams)이 필요합니다. 인프라 병목 현상을 피하고 싶다면, AWS 리소스를 할당하기 위해 Jira 티켓을 처리하는 고립된 그룹이 아니라, 셀프 서비스 (self-service)를 통해 역량을 제공하는 플랫폼 팀 (platform teams)이 필요합니다.

Conway의 법칙을 수용하는 것과 역 Conway를 실행하는 것의 차이는 구조적입니다:

graph TB
    subgraph "이전: 계층적 조직도"
        D1[이사국] --> G1[관리 A]
...

하지만 모든 "역 Conway (Reverse Conway)"가 작동하는 것은 아닙니다. 슬라이드 위에서 사각형을 다시 그리는 것만으로는 수년간 구축된 비공식적인 신뢰 네트워크를 하루아침에 바꿀 수 없습니다. 엔지니어는 새로운 관료적 정책을 따르는 대신, 여전히 Slack에서 이전 팀 동료에게 아키텍처에 관한 의문을 물을 것입니다.

아키텍처를 진정으로 변화시키는 것은 **조직적 인센티브 (organizational incentives)와 마찰 플랫폼 (friction platforms)**을 바꾸는 것입니다:

• 내부 제품으로서의 API (APIs as internal products): 명확한 SLA (Service Level Agreement)와 유의적 버전 관리 (semantic versioning)가 포함된 계약은 비공식적인 조율의 필요성을 줄여줍니다.
• 효율적인 플랫폼 팀 (Platform teams): 온디맨드 역량 (표준화된 파이프라인 (pipelines) 또는 관리형 클러스터 (clusters)와 같은)은 "인프라 팀에 허가를 받아야 한다"는 문제를 제거합니다.
• 실행 공동체 (Communities of practice): 스쿼드 (squads)의 경계를 넘나드는 수평적 상호작용을 통해, 임계 경로 (critical path)에 제약을 가하지 않으면서 지식을 분산시킵니다.
• 공유된 코드 소유권 (Shared code ownership): 두 개의 복잡한 도메인이 충돌하는 지점에서는 계약에 대한 거버넌스가 Git에서 관리되는 상호 책임이 되어야 합니다.
• 정렬된 목표 (OKRs): 의존 관계에 있는 팀들이 통합된 성공 지표를 가진다면, 우선순위 결정 위원회는 불필요해집니다.

격돌: AI가 Conway를 해킹할 수 있을까?

Vitor: Archie, 생성형 AI (generative AI)에 대한 기대가 기업의 현실에 부딪히는 지점이 바로 여기입니다. Conway의 법칙은 사회정치적 제약입니다. 어떤 파운데이션 모델 (foundation model)도 부정 방지 팀과 신용 승인 팀이 서로 경쟁하는 목표를 가진 채 서로 다른 이사에게 보고한다는 사실을 바꿀 수는 없습니다. 세계에서 가장 똑똑한 자율 에이전트 (autonomous agent)를 통신 중재자로 배치할 수는 있겠지만, 어떤 기능 (feature)을 스프린트 (sprint)에 포함할지에 대한 최종 결정은 코드의 병목 현상이 아니라 여전히 인간의 권력 게임입니다.

Archie: Vitor, 비즈니스 결정이 의심할 여지 없이 여전히 인간적이고 정치적이라는 점에는 동의합니다. 하지만 기술적 비효율성이 이사회의 조율을 기다릴 필요는 없습니다. 오늘날 사기 탐지 (Fraud) 팀이 새로운 분류 체계 (taxonomy)가 신용 (Credit) 서비스에 미치는 영향을 이해해야 할 때, 그들은 티켓 (ticket)을 생성하고 업데이트되지 않은 다이어그램을 기다리며 3일을 허비합니다. 제한된 컨텍스트 (context)에 접근하여 API 계약 (contract), Kafka 스키마 (schema)를 매핑하고 양측의 리포지토리 (repository)를 읽을 수 있는 AI 에이전트 (agent)는 이러한 마찰을 몇 초 만에 제거합니다. AI가 계약에 대한 정치적 협상을 대신하는 것은 아니지만, 조직 스스로는 유지할 수 없었던 즉각적인 관찰 가능성 (observability) 채널을 만들어냅니다.

이 도발은 날카롭지만 기술적인 경계 설정이 필요합니다.

제 요점은 본질적으로 반박할 수 없습니다. AI는 조직도 (organogram)를 바꾸지 않으며 예산을 재협상하지도 않습니다. 하지만 Archie는 _거래 및 발견 비용 (transaction and discovery cost)_의 감소 측면에서 정확한 지적을 하고 있습니다. 에이전트가 두 팀의 협업을 강제하지는 않지만, 에이전트는 사회 기술적 결합 (sociotechnical coupling)의 관찰 가능성으로서 작용합니다.

AI가 당신의 아키텍처를 위해 정당하게 수행할 수 있는 일:

• 발견의 마찰 감소: 에이전트는 세 개의 스쿼드 (squad) 간의 위원회를 소집하지 않고도 핵심적인 질문(예: "이벤트 X의 JSON에서 이 필드를 제거하면 폭발 반경(blast radius)이 어떻게 되나요?")에 답할 수 있습니다.
• 우발적인 창발적 결합 탐지: 계약 변경 로그 (logs)와 리포지토리를 교차 분석함으로써, AI는 도메인 경계 (domain boundaries)가 배후에서 위험하게 융합되고 있을 때 경고를 보냅니다.

AI가 절대 하지 못하는 일:

• 비즈니스 이해관계 충돌 해결: 팀들의 인센티브가 상충한다면, AI는 단지 재앙의 규모를 더 빠르게 계산할 뿐입니다.
• 계약 책임 대체: _누가 누구를 호출하는지_와 _허용 가능한 응답 시간은 얼마인지_에 대한 실용적인 정의는 여전히 실제 엔지니어들 사이에서 맺어지는 합의의 영역입니다.

EDA와 AI에 관한 기사에서 살펴본 바와 같이, AI는 주로 지속적인 인사이트 (insight) 계층에서 작동합니다. AI는 조직도(organogram)의 지름길과 결함이 운영 환경(production environment)을 무너뜨리기 전에 이를 드러냅니다.

가장 치명적인 안티 패턴 (anti-pattern): "분산 모놀리스 (distributed monolith)"

Conway의 법칙을 무시하려는 이들이 겪는 가장 흔하고 (비싼) 대가는 바로 **분산 모놀리스 (distributed monolith)**를 구축하는 것입니다. 수십 개의 파편화된 서비스와 수백 개의 파이프라인 (pipelines)이 존재하지만, 기존 레거시 (legacy) 시스템과 동일한 수준의 경직된 결합도 (coupling)를 가집니다.

**모듈형 모놀리스 (modular monolith)**와의 차이는 극명합니다. 모듈형 모놀리스는 높은 응집도 (cohesion)와 낮은 내부 결합도 (low coupling)를 가지며, 단일 프로세스와 배포 (deploy) 환경에서 효율적으로 실행됩니다. 반면, 분산 모놀리스는 팀들이 통신 라인을 재편하지 않은 채 마이크로서비스 (microservices)를 사용하려고 할 때 발생합니다:

graph LR
    subgraph "모듈형 모놀리스 (건강한 상태)"
        M[모놀리스] --> MA[모듈 A]
...

• 경영진이 (유행, 이력서, 또는 시장의 약속 때문에) 마이크로서비스 도입을 결정합니다.
• 조직도는 그대로 유지됩니다.
• 새로운 서비스 간의 네트워크를 통한 통신은 기존의 얽혀 있는 의존성 (dependencies)을 그대로 반영합니다.
• 결과적으로 약속된 자율성은 전혀 얻지 못한 채, 분산 아키텍처 (distributed architecture)의 매우 높은 지연 시간 (latency)과 복잡성만을 비용으로 지불하게 됩니다.

진단은 치명적입니다. 만약 두 개의 API — 예를 들어, Quarkus 기반의 결제 마이크로서비스와 물류 마이크로서비스 — 가 플랫폼을 깨뜨리지 않기 위해 반드시 동시에 운영 환경 (production)에 배포되어야 한다면, 당신은 마이크로서비스를 가지고 있는 것이 아닙니다. 당신은 파편화된 괴물을 가지고 있는 것입니다. 해결책은 코드를 리팩터링 (refactor)하는 것이 아닙니다. 서비스를 합치고 해당 팀들을 통합하거나, 성숙한 비즈니스 경계 (business boundaries)를 중심으로 조직을 재편하는 것입니다.

당신의 Conway를 감사(Audit)하는 방법

회사 전체를 재편하려고 시도하기 전에, 이 법칙의 중력이 당신의 생태계 어디에서 이미 작용하고 있는지 찾아내십시오:

1. 보이지 않는 커뮤니케이션 네트워크를 매핑하십시오: PDF로 된 조직도를 잊으십시오. _배포 (deploy)_가 막혔을 때, 도움을 요청하기 위해 Slack에서 실제로 누구를 찾습니까?
2. 멘탈 맵(Mental map)을 기술적 의존성 그래프(Dependency graph)와 대조하십시오: 애플리케이션의 네트워크 트래픽이 엔지니어들의 대화 흐름을 따르고 있습니까? 만약 두 마이크로서비스 (microservices)가 수백만 건의 요청을 주고받지만, 그 유지보수 담당자들이 결코 _페어 프로그래밍 (pair programming)_을 하지 않는다면, 장애 발생은 단지 "언제"의 문제일 뿐입니다.
3. 공유 데이터베이스를 추적하십시오: 여러 도메인이 동기화를 유지하기 위해 동일한 데이터베이스에 읽기 및 쓰기를 수행하고 있다면, 조직은 API의 장벽을 완전히 무시한 채 테이블을 통해 "대화"하고 있는 것입니다.
4. 커밋 (commit) 및 배포 (deploy) 이력을 분석하십시오: 어떤 서비스들이 묶여서 올라가는지 목록을 만드십시오. Git 상의 모든 결합된 쌍은 도메인 경계가 착시 현상에 불과하다는 증거입니다.

감사(Audit)는 시니어 개발자들이 이미 몸소 느끼고 있는 것들을 새로 밝혀내지는 않지만, 직관을 의사 결정권자들을 위한 반박 불가능한 증거로 전환해 줍니다.

조직과 코드를 정렬하기 위한 로드맵