조직도가 제품에 그대로 새겨진다 — 콘웨이의 법칙과 팀 경계 설계

1968년, 멜빈 콘웨이(Melvin Conway)라는 프로그래머가 「How Do Committees Invent?」라는 제목의 짧은 글을 발표했다. 논지는 한 문장으로 압축된다. 시스템을 설계하는 조직은, 그 조직의 소통 구조를 그대로 복제한 구조의 설계를 내놓게 된다.

처음 읽으면 냉소적인 농담처럼 들린다. 그러나 콘웨이가 제시한 근거는 건조하고 기계적이다. 설계란 결국 부분들을 나누고 그 부분들 사이의 접점을 정하는 일이다. 그런데 두 부분 사이의 접점을 제대로 정하려면 그 두 부분을 맡은 사람들이 대화를 해야 한다. 대화가 없는 두 사람 사이에는 정교한 인터페이스가 만들어질 수 없다. 그러니 설계 결과물의 이음매는, 필연적으로 설계자들이 실제로 대화한 경로를 따라 그어진다.

이 논리에는 빠져나갈 구멍이 없다. 조직도를 바꾸지 않은 채 아키텍처만 바꾸겠다는 계획이 대부분 실패하는 이유가 여기에 있다.

한 가지 덧붙여야 할 것은, 콘웨이가 말한 소통 구조가 공식 조직도와 같지 않다는 점이다. 결정적인 것은 결재선이 아니라 실제로 말이 오가는 경로다. 조직도상 다른 본부에 속해 있어도 매일 같은 회의에 들어가는 두 사람 사이에는 정교한 접점이 만들어진다. 반대로 같은 팀 이름을 달고 있어도 서로 다른 시간대에 일하며 분기에 한 번 만나는 두 사람 사이에는 그런 접점이 생기지 않는다. 그려진 조직도가 아니라 관찰된 소통 그래프가 설계를 결정한다.

관찰에서 가설로 — 2012년의 미러링 연구

콘웨이의 글은 오랫동안 업계의 잠언으로 회자됐지만 실증 근거는 부족했다. 이 공백을 메운 대표적 작업이 앨런 맥코맥, 카를리스 볼드윈, 존 러스낙이 2012년에 발표한 「Exploring the duality between product and organizational architectures」다.

연구진의 접근은 단순하고 영리하다. 기능이 비슷한 소프트웨어 제품을 쌍으로 골라, 한쪽은 한 회사 안에서 긴밀하게 결합된 조직이 만든 것, 다른 한쪽은 지리적으로 흩어진 자원봉사자들이 느슨하게 협업해 만든 오픈소스 제품으로 두었다. 그리고 코드의 의존 구조를 계량해 아키텍처가 얼마나 모듈화돼 있는지를 비교했다.

결과는 콘웨이의 예측과 같은 방향을 가리켰다. 느슨하게 결합된 분산 조직이 만든 제품이 더 모듈화된 구조를 보였고, 한 지붕 아래 긴밀히 결합된 조직이 만든 제품은 구성 요소 사이의 의존이 더 얽혀 있었다. 연구진은 이 대응 관계를 미러링 가설(mirroring hypothesis)이라 불렀다.

해석은 상식적이다. 서로 다른 대륙에 있고 얼굴을 본 적 없는 개발자들은 수시로 조율할 수 없다. 그래서 명확한 인터페이스를 먼저 정하고 그 뒤로는 각자 독립적으로 움직인다. 반대로 같은 층에서 일하는 팀은 언제든 옆자리에 물어볼 수 있으므로, 경계를 엄격히 지킬 유인이 약하다. 편의를 위해 남의 내부 구조에 손을 뻗고, 그렇게 만들어진 지름길이 코드에 남는다.

주목할 점은 이것이 능력이나 성실성의 문제가 아니라는 데 있다. 옆자리 동료에게 물어보고 내부 값을 직접 참조하는 선택은 그 순간에는 언제나 합리적이다. 인터페이스를 새로 정의하는 데 드는 시간보다 훨씬 싸기 때문이다. 비용은 몇 달 뒤 그 참조 관계를 아무도 기억하지 못할 때 청구된다. 소통이 쉬운 환경은 협업에는 유리하지만 경계 유지에는 불리하다는 역설이 여기서 나온다. 그렇다고 팀을 일부러 떼어 놓자는 결론으로 갈 수는 없고, 대신 소통의 편의가 경계를 침식하지 않도록 규율을 별도로 세워야 한다는 결론이 나온다.

여기서 나오는 실무적 결론이 역(逆)콘웨이 기동(inverse Conway maneuver)이다. 콘웨이의 법칙이 조직 구조에서 아키텍처로 향하는 화살표라면, 그 화살표를 거꾸로 이용하자는 발상이다. 원하는 아키텍처를 먼저 정하고, 그 아키텍처를 만들어 낼 소통 구조가 되도록 조직을 재편한다. 서비스를 독립적으로 배포하고 싶다면 그 서비스를 온전히 소유한 팀을 먼저 만들어야 한다는 이야기다.

아마존의 사례와 그 사례를 다룰 때의 주의

이 맥락에서 가장 자주 인용되는 사례가 아마존이다. 팀의 크기를 피자 두 판으로 식사가 되는 규모로 제한한다는 원칙, 그리고 모든 팀은 서로의 데이터에 직접 접근하지 말고 반드시 서비스 인터페이스를 통해서만 소통하라는 지침이 그것이다. 소통 경로를 강제로 인터페이스로 좁힌 셈이고, 콘웨이의 법칙에 따르면 그 결과 아키텍처도 인터페이스로 분리된 형태가 된다.

다만 여기서 한 가지는 분명히 해 두는 편이 낫다. 이 서비스 인터페이스 지침의 원문이 공개된 적은 없다. 널리 인용되는 형태는 전직 임직원의 회고와 2차 서술을 통해 전해진 것이고, 표현도 인용마다 조금씩 다르다. 사례로 참고할 가치는 있지만 원문 인용처럼 다루는 것은 부정확하다. 사고의 구조 — 소통 경로를 좁히면 아키텍처의 경계가 선명해진다 — 만 취하는 편이 안전하다.

팀이 감당할 수 있는 만큼만 시스템이 된다

2019년 매슈 스켈턴과 마누엘 파이스가 쓴 『팀 토폴로지』는 콘웨이의 법칙을 조직 설계의 실무 언어로 옮긴 작업이다. 이 책은 팀 유형을 네 가지로 정리한다. 제품이나 서비스 흐름을 끝까지 책임지는 스트림 정렬 팀, 특정 영역의 깊은 전문성을 제공하는 활성화 팀, 복잡한 하위 시스템을 맡는 난해 하위시스템 팀, 그리고 내부 플랫폼을 제공하는 플랫폼 팀이다. 팀 사이의 상호작용 방식도 협업·서비스 제공·촉진의 몇 가지 유형으로 제한한다.

이 정리가 실무에서 유용한 이유는, 팀을 늘릴 때 흔히 생기는 실수를 미리 막아 주기 때문이다. 조직이 커지면 사람들은 대체로 팀을 기능별로 쪼갠다. 프론트엔드, 백엔드, 데이터, QA, 인프라. 각 직군의 전문성이 모이므로 관리하기 편하고 채용 기준도 명확하다. 그런데 이렇게 나누면 고객에게 전달되는 가치 하나를 만드는 데 필요한 팀의 수가 그만큼 늘어난다. 모든 기능이 다섯 팀의 일정 조율을 거쳐야 하는 구조가 되고, 각 팀은 전체 흐름 중 자기 구간만 본다. 스트림 정렬 팀이라는 개념은 이 순서를 뒤집어, 직군이 아니라 가치 흐름을 기준으로 팀을 자르라고 말한다.

이 틀에서 핵심 개념은 인지 부하다. 한 팀이 머릿속에 담을 수 있는 시스템의 양에는 상한이 있다. 담당 범위가 그 상한을 넘어서면 팀은 시스템 전체를 이해하지 못한 채 자기가 만지는 부분만 건드리게 되고, 변경의 파급 효과를 예측하지 못한다. 그래서 이 책의 처방은 팀이 감당할 수 있는 범위를 먼저 정하고, 그 범위에 맞춰 시스템 경계를 긋는 것이다. 시스템을 먼저 나누고 사람을 배치하는 통상적 순서를 뒤집는다.

지금 이 법칙이 다시 문제가 되는 세 지점

첫째, 분산 모놀리스. 마이크로서비스로 나눴는데 배포는 여전히 함께 해야 하고, 하나를 고치면 다른 서비스도 같이 고쳐야 하는 상태를 말한다. 원인은 대개 기술이 아니라 조직에 있다. 서비스 경계는 도메인 기준으로 그었는데 팀 경계는 예전의 기능 조직(프론트엔드팀·백엔드팀·DB팀) 그대로라면, 하나의 기능 변경이 여러 팀의 협의를 거쳐야 한다. 네트워크 호출로 나뉜 모놀리스는 원래의 모놀리스보다 운영이 더 어렵다.

둘째, 원격근무가 만든 새로운 소통 위상. 콘웨이가 말한 소통 구조는 물리적 자리 배치와 회의 구조였다. 지금 그 자리를 채운 것은 슬랙 채널 구성, 이슈 트래커의 프로젝트 분할, 문서 저장소의 권한 구조다. 채널이 어떻게 나뉘어 있고 누가 어느 채널에 들어가 있는지가 실질적인 소통 그래프를 만들고, 그 그래프가 다시 시스템에 새겨진다. 조직도상으로는 하나인 팀이라도 채널 구조 때문에 실질적으로는 둘로 갈라질 수 있다.

이 두 번째 지점은 특히 놓치기 쉽다. 자리 배치는 눈에 보이고 조직 개편은 공식 절차를 거치지만, 채널 하나를 만들고 누군가를 초대하는 일에는 아무 절차도 없기 때문이다. 그런데 누적된 채널 구조는 실질적으로 조직 설계와 같은 효과를 낸다. 논의가 이뤄지는 자리에 들어가 있지 않은 사람은 결정 과정에서 배제되고, 배제된 사람이 맡은 영역은 시스템에서 독립된 섬으로 남는다.

셋째, AI 코딩 도구가 바꾼 비용 구조. 코드를 작성하는 비용이 빠르게 떨어지면서, 병목은 코드를 쓰는 일에서 다른 곳으로 이동하고 있다. 무엇을 만들지 합의하는 일, 인터페이스를 정하는 일, 그리고 만들어진 것을 누가 계속 책임질지 정하는 일이다. 구현이 싸질수록 소유권과 경계의 설계가 상대적으로 더 큰 비중을 차지한다. 생산 속도가 올라간 만큼 경계가 모호한 영역에서 중복 구현과 책임 공백이 쌓이는 속도도 함께 올라간다.

실무 적용 — 그래서 뭘 하면 되나

• 팀 경계와 API 경계를 겹쳐 그려 보라 — 시스템 구성도와 조직도를 한 장에 포개 놓고, 어긋난 지점을 표시한다. 장애와 지연은 거의 언제나 그 어긋난 자리에서 나온다.
• 기능 하나를 출시할 때 거치는 인수인계 지점을 세라 — 팀을 넘어가는 횟수가 리드타임을 결정한다. 회의를 줄이는 것보다 인계 횟수를 줄이는 쪽이 효과가 크다.
• 아키텍처를 바꾸기로 했다면 조직 개편을 같은 안건으로 다뤄라 — 역콘웨이 기동의 요점은 순서다. 조직을 그대로 두고 설계도만 새로 그리면, 몇 분기 뒤 코드는 예전 조직 모양으로 돌아가 있다.
• 모든 서비스에 소유 팀과 온콜 담당을 명시하라 — 주인 없는 컴포넌트는 아무도 리팩터링하지 않고 모두가 조금씩 고친다. 소유권 표시가 없는 경계는 경계가 아니다.
• 팀의 인지 부하를 담당 서비스 개수로 점검하라 — 한 팀이 이해해야 할 시스템의 양이 상한을 넘었는지 정기적으로 묻는다. 넘었다면 사람을 더 넣는 것보다 범위를 덜어 내는 편이 낫다.
• 채널·리포지토리·권한 구조를 조직 설계의 일부로 다뤄라 — 어디에 누가 접근할 수 있는지가 실제 소통 그래프다. 이 구조를 방치하면 의도하지 않은 아키텍처가 자란다.
• 경계를 넘는 지름길을 코드 리뷰의 명시적 점검 항목으로 올려라 — 남의 내부 구조를 직접 참조한 변경은 리뷰에서 걸러 내지 않으면 반드시 쌓인다. 편의로 만든 참조 하나가 몇 분기 뒤 분리 불가능한 결합이 된다.

콘웨이의 법칙이 불편한 이유는 그것이 기술 문제를 조직 문제로 되돌려 보내기 때문이다. 코드가 얽혀 있다는 진단의 다음 문장은 대개 사람들이 얽혀 있다는 문장이다. 설계도를 다시 그리는 일보다 자리 배치를 다시 하는 일이 어렵다는 것이, 이 법칙이 반세기 넘게 유효한 이유다.

콘웨이의 원 논문은 1968년 발표됐고 이후 여러 형태로 재인용되며 표현이 다듬어졌다. 아마존의 팀 규모·서비스 인터페이스 원칙은 널리 알려져 있으나 원 지침 문서가 공개된 적은 없으며, 본문에서도 2차 전언으로 다뤘다. 미러링 가설의 실증 결과는 해당 연구가 다룬 표본과 계량 방식에 한정된 결론이다. 이 글은 조직·아키텍처 설계에 관한 해설이며 특정 기업의 채용·투자 판단을 권유하지 않는다.