콘웨이의 법칙

콘웨이의 법칙은 소프트웨어가 그것을 만든 조직을 닮는다고 말합니다. 팀 셋이 나눠 만든 시스템은 대개 세 덩어리로 갈라집니다. 팀끼리 이야기하는 길이 그대로 모듈 사이의 연결이 됩니다. 그래서 시스템 구조를 정할 때 팀을 어떻게 짤지도 함께 봅니다.

쉽고 빠른 이해

콘웨이의 법칙은 「시스템은 만든 사람들의 소통 구조를 따라 나뉜다」는 관찰입니다. 소통 구조는 누가 누구와 얼마나 쉽게 이야기하느냐입니다. 주문 팀과 결제 팀이 따로 있으면 주문 서비스와 결제 서비스도 따로 생기기 쉽습니다.

이걸 모르면 설계도와 조직이 서로 다른 쪽으로 당깁니다. 서비스 셋을 그려 놓고 팀 하나에 맡기면 셋이 다시 한 덩어리로 엉킵니다.

도는 방식은 이렇습니다.

1. 두 부분이 맞물리려면 두 부분을 만드는 사람들이 약속을 맞춰야 합니다
2. 약속은 이야기를 나눠야 맞춰집니다
3. 그래서 이야기가 쉬운 곳에서는 코드가 촘촘히 붙습니다. 서로 부르는 곳이 많고 함께 고칠 일이 잦아진다는 뜻입니다. 이야기가 드문 곳에서는 코드도 떨어집니다

이걸 거꾸로 써서 원하는 구조대로 팀을 먼저 짜기도 합니다. 대가는 팀을 다시 짜는 일이 코드를 고치는 일보다 느리고 비싸다는 것입니다. 개발자가 몇 안 되는 조직이면 서비스를 쪼개지 않고 한 덩어리로 두는 편이 낫습니다.

상세

이 절은 먼저 법칙이 무엇을 말하는지 봅니다. 그다음 왜 그런 일이 생기는지, 백엔드 시스템에서 어떤 모습으로 드러나는지를 봅니다. 마지막으로 이 법칙을 거꾸로 쓰는 방법과 그 값을 봅니다. 예로는 쇼핑몰의 주문·결제·배송 팀을 끝까지 씁니다.

보고서 한 편을 세 사람이 한 장씩 나눠 쓴다고 해 보겠습니다. 다 모아 놓으면 보고서도 세 장으로 갈라져 읽힙니다. 장과 장 사이는 세 사람이 미리 말을 맞춘 만큼만 매끄럽게 이어집니다. 소프트웨어에서도 같은 일이 생깁니다. 세 사람은 세 팀에 해당합니다. 장과 장 사이의 이음매는 모듈 사이의 연결에 해당합니다.

법칙이 말하는 것

시스템을 설계하는 조직은 자기 소통 구조(누가 누구와 이야기하는지)를 닮은 설계를 내놓습니다. 이것이 콘웨이의 법칙입니다. 여기서 시스템은 소프트웨어만이 아닙니다. 여러 사람이 나눠 만드는 설계물이면 다 해당합니다.

소통 구조는 조직도와 같을 수도 있고 다를 수도 있습니다. 조직도에서는 한 부서여도 층이 갈려 말을 거의 안 섞는 두 팀이 있습니다. 그 두 팀이 만든 코드는 조직도가 아니라 실제 대화를 따라 나뉩니다.

이름은 멜빈 콘웨이(Melvin Conway)에게서 왔습니다. 그가 1968년에 잡지에 실은 글에서 이 생각을 내놓았습니다. 뒤에 프레드 브룩스(Fred Brooks)가 책 「맨먼스 미신(The Mythical Man-Month)」에서 이것을 「콘웨이의 법칙」이라고 불렀습니다.

「법칙」이라는 이름이 붙었지만 물리 법칙처럼 늘 맞는 규칙은 아닙니다. 여러 사람이 함께 일할 때 거듭 보이는 경향을 적은 관찰입니다. 경향이 강해서 설계를 할 때 무시하기 어려울 뿐입니다.

왜 그렇게 되나

시스템의 두 부분이 함께 돌려면 그 사이에 약속이 있어야 합니다. 어떤 값을 넘기고 무엇을 돌려받는지 같은 약속입니다. 코드에서는 이것이 인터페이스나 API(Application Programming Interface, 프로그램끼리 주고받는 창구)로 드러납니다.

약속은 두 부분을 만드는 사람들이 이야기를 나눠야 정해집니다. 한 팀 안에서는 옆자리에 물어보면 끝납니다. 그래서 팀 안의 코드는 서로 쉽게 부르고 쉽게 바꿉니다.

팀 사이에서는 회의를 잡고 문서를 써야 합니다. 이 비용 때문에 팀 사이의 약속은 가짓수가 적고 잘 바뀌지 않습니다. 바꿀 때마다 같은 비용을 다시 치러야 하니 처음부터 단순하게 정합니다.

결국 이야기가 쉬운 곳에서는 코드가 촘촘히 붙습니다. 서로 부르는 곳이 많고 한쪽을 고치면 다른 쪽도 함께 고칠 일이 잦습니다. 이야기가 드문 곳에서는 코드 사이에 선이 생깁니다. 아래 그림은 이 대응을 쇼핑몰 팀 셋으로 보입니다.

flowchart TD
    subgraph ORG["조직 · 누가 누구와 이야기하나"]
        A["주문 팀"]
        B["결제 팀"]
        C["배송 팀"]
        A <-->|"매일 회의"| B
        A <-->|"가끔 메일"| C
    end
    subgraph SYS["시스템 · 무엇이 무엇을 부르나"]
        SA["주문 서비스"]
        SB["결제 서비스"]
        SC["배송 서비스"]
        SA <-->|"자주 바뀌는 촘촘한 API"| SB
        SA -->|"단순한 알림 하나"| SC
    end
    ORG -->|"소통 구조가 옮겨 간다"| SYS

주문 팀과 결제 팀은 매일 이야기합니다. 그래서 두 서비스 사이의 API도 촘촘하고 자주 바뀝니다. 주문 팀과 배송 팀은 가끔만 연락합니다. 둘 사이에는 「주문이 확정됐다」는 알림 하나만 오갑니다.

결제 팀과 배송 팀은 서로 이야기할 일이 없습니다. 그림에서도 두 서비스 사이에는 연결이 없습니다.

백엔드에서 보이는 모습

이 소절은 팀을 나누는 방식 둘을 놓고 각각 어떤 시스템이 나오는지 견줘 봅니다. 하나는 기술 분야로 나누는 방식입니다. 다른 하나는 업무로 나누는 방식입니다.

첫째는 화면 팀, 서버 팀, 데이터베이스 팀으로 나눈 조직입니다. 이 조직에서는 시스템도 화면, 서버, 데이터베이스의 세 계층으로 갈라집니다. 결제 화면에 칸 하나를 더하려 해도 세 팀이 모두 움직여야 합니다.

둘째는 주문 팀, 결제 팀, 배송 팀으로 나눈 조직입니다. 각 팀이 자기 업무의 화면부터 저장소까지 다 맡습니다. 이 조직에서는 시스템이 업무를 따라 나뉩니다. 결제 화면을 고치는 일은 결제 팀 안에서 끝납니다.

표의 셋째 줄은 팀이 하나뿐인 경우입니다. 이때는 코드 사이에 선을 그을 압력이 약합니다. 서비스를 여럿으로 그려 두어도 한 팀이 다 만지면 경계가 점점 흐려집니다.

반대도 있습니다. 주문 서비스 하나를 주문 팀과 결제 팀이 나눠 맡으면 그 안에 눈에 안 보이는 선이 생깁니다. 두 팀이 맡은 패키지마다 코드를 쓰는 방식이 다릅니다. 두 패키지 사이에는 공통 모듈 하나만 붙어 있습니다.

거꾸로 쓰기

시스템이 조직을 닮는다면 조직을 먼저 바꿔 시스템을 이끌 수도 있습니다. 원하는 시스템 구조를 먼저 정하고 팀을 그 모양대로 짜는 것입니다. 이 방법을 흔히 역 콘웨이 전략(Inverse Conway Maneuver)이라고 부릅니다.

쇼핑몰을 마이크로서비스로 나누고 싶다고 해 보겠습니다. 마이크로서비스는 시스템을 따로 배포하는 작은 서비스 여럿으로 나누는 방식입니다. 서버 팀 하나가 그대로 있으면 서비스를 여럿 그려도 다시 한 덩어리로 엉킵니다. 그래서 주문 팀, 결제 팀, 배송 팀을 먼저 세우고 서비스도 팀마다 하나씩 맡깁니다.

어디서 나눌지는 도메인 주도 설계에서 기준을 자주 빌려 옵니다. 도메인 주도 설계는 업무에서 쓰는 낱말과 규칙을 코드 구조의 중심에 두는 설계 방법입니다.

그 기준이 경계 컨텍스트입니다. 경계 컨텍스트는 한 낱말이 한 가지 뜻으로만 통하는 업무 범위입니다. 쇼핑몰의 「상품」을 보면 쉽습니다. 주문 쪽에서 상품은 값과 수량입니다. 배송 쪽에서 상품은 무게와 부피입니다. 이렇게 뜻이 갈리는 곳이 경계입니다.

그 범위 하나를 팀 하나가 맡으면 팀의 경계와 코드의 경계가 같아집니다. 주문 팀은 주문 쪽의 상품만 다룹니다. 배송 팀은 배송 쪽의 상품만 다룹니다.

거꾸로 쓰면 치르는 값

이 소절은 역 콘웨이 전략으로 팀을 먼저 짤 때 치르는 값 셋을 봅니다.

첫째, 팀을 다시 짜는 일은 느리고 비쌉니다. 코드는 하루 만에 옮길 수 있습니다. 사람은 역할과 보고 체계와 일하는 습관이 함께 바뀌어야 합니다.

둘째, 경계를 잘못 정하면 그 실수가 조직에까지 굳습니다. 한 업무를 두 팀이 쪼개 맡게 되면 기능 하나를 고칠 때마다 두 팀이 일정을 맞춰야 합니다. 이때는 코드만 고쳐서는 안 풀리고 팀을 다시 짜야 합니다.

셋째, 서비스마다 팀을 세우는 방식은 작은 조직에 맞지 않을 수 있습니다. 개발자가 다섯 명이라고 해 보겠습니다. 서비스를 다섯으로 나누면 한 사람이 서비스 하나를 떠안습니다. 팀 사이의 선이 없으니 서비스 사이의 선도 지키기 어렵습니다. 이럴 때는 시스템을 한 덩어리로 만들어 한 번에 배포하는 모놀리스 쪽이 법칙과 맞습니다. 팀이 하나이니 덩어리도 하나인 것입니다.

관련 항목

콘웨이의 법칙이 속하는 설계 분야

소프트웨어 아키텍처 · 도메인 주도 설계 · 사회기술 시스템 · 시스템 설계

이 법칙을 거꾸로 쓰는 조직 설계 방법

역 콘웨이 전략 · 팀 토폴로지 · 팀 경계 · 스트림 정렬 팀 · 플랫폼 팀

팀 경계를 따라 갈리는 시스템 구조

경계 컨텍스트 · 마이크로서비스 · 모듈러 모놀리스 · 모놀리스 · 레이어드 · 서비스 지향 아키텍처

팀 사이의 약속이 되는 연결

API · 인터페이스 · API 설계 · 모듈 · 이벤트

경계가 잘 나뉘었나를 재는 성질

결합도 · 응집도 · 관심사 분리 · 정보 은닉

법칙을 거스를 때 드러나는 문제

분산 모놀리스 · 빅 볼 오브 머드 · 신 객체 · 순환 의존

팀 사이의 소통 비용을 다루는 원칙·문화

브룩스의 법칙 · 두 피자 팀 · 인지 부하 · 데브옵스