콘웨이 법칙은 살아있다. “조직문화부터 MSA까지”

우리는 시스템이라는 용어를 경영, 사회, 생물, 자연과학, 사회과학 등 다양한 곳에서 사용합니다. 우리가 살고 있는 사회도 시스템이라고 공연히 말합니다. 우리 몸도 인체 시스템이라고 말할 때도 있습니다. 그렇다면 시스템은 무엇일까요? 오늘은 ‘콘웨이 법칙’을 이용해 시스템에 관해 설명해 보겠습니다.

시스템은 각 구성 요소들이 상호작용하거나 상호 의존하여 복잡하게 얽힌 통일된 하나의 집합체를 말합니다. 복잡한 사회적 체계의 맥락에서 구조와 행동을 통제하는 규칙들의 집합을 말하기도 합니다. 즉 시스템은 요소, 관계 그리고 규칙으로 어우러진 집합입니다.

컴퓨터 분야에서의 시스템도 크게 다르지 않습니다. 소프트웨어 분야에서는 ‘아키텍처(Architecture)’라는 개념을 통해서 시스템의 속성 또는 기본 개념을 모아 놓고, 요소, 관계, 설계 등의 원칙을 다룹니다.

콘웨이의 법칙(Conway’s law)

1968년 4월에 글로벌 컴퓨터 잡지 ‘Datamation’에 글 하나가 실렸습니다. 멜빈 콘웨이(Melvin E. Conway)가 작성한 ‘How do committees invent?’입니다.

멜빈 콘웨이 박사는 COBOL, ALGOL 컴파일러를 제작하는 연구를 진행했습니다. 연구 조직에는 COBOL과 ALGOL 컴파일러를 생산할 8명의 사람이 있었습니다. 초기에 난이도와 시간을 추정한 후 5명이 COBOL 작업에, 3명이 ALGOL 작업에 할당되었습니다. 그 결과 COBOL 컴파일러는 5단계로 실행되었고, ALGOL 컴파일러는 3단계로 실행됐습니다.

그리고 이들에게 조직 구조와 시스템 구조를 비교하여 할당한 이유를 설명했습니다. 당시 예시로 든 것이 사용자 프로그래머와 시스템 프로그래머, 그리고 엔지니어 세 가지로 분리한 조직 구조와 시스템 구조였습니다. 반세기 이전에 요즘의 프론트엔드, App, 백엔드 그리고 시스템 엔지니어로 분리된 구조를 제시하는 건 정말 놀라운 일입니다.

그리고 글의 결론으로 아래와 같은 말을 언급합니다.

“시스템을 설계하는 조직은 조직의 의사소통 구조를 빼닮은 구조의 디자인을 만들게 됩니다.”

글의 말미에 언급된 이 문장은 이후 소프트웨어 개발자 사이에서 회자되며 ‘콘웨이 법칙’으로 불리게 되었습니다. 재미있게도 당시 멜빈 콘웨이 박사는 위에서 설명한 정의를 따로 법칙으로 정하지 않았습니다.

이는 미국의 소프트웨어 엔지니어인 ‘프레더릭 브룩스(Frederick Brooks)’가 소프트웨어 공학 및 프로젝트에 관한 책 ‘맨먼스 미신(The Mythical Man-Month)’에서 소개하면서 ‘콘웨이 법칙’으로 유명해졌습니다.

콘웨이의 법칙(Conway’s law) 이해하기

지난 반세기 동안 콘웨이 법칙은 많은 소프트웨어 개발자 사이에서 다양하게 언급되고 해석되었습니다. 2011년 미국의 유명 대학인 MIT와 하버드가 공동 연구한 ‘Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis’에 의하면, ‘결합도가 낮은 조직(Loosely coupled organization)에서 개발된 제품이 결합도가 높은 조직(Tightly coupled organization)에서 나온 제품보다 훨씬 더 모듈화되어있다.’라는 연구 결과가 나왔습니다. 이에 따라 콘웨이 법칙의 객관성이 어느 정도 입증되었습니다.

(출처: 조직의 형태별 특징)

조직 구성원의 규모와 의사소통 채널의 증감은 개발자의 생산성에 영향을 끼칩니다. 생산성이 낮은 조직 구조에서의 개발자는 충분한 일정이 주어지지 않았을 때 시스템의 확장성이나 응집성보다는 요구사항에만 충실한 소스 코드를 작성하게 됩니다. 이런 것을 모아서 기술 부채라고 합니다.

그렇다면 빡빡한 일정을 맞추기 위해서 개발자를 추가 채용하여 해당 프로젝트에 투입하게 되면 문제가 해결될까요? 생산량을 늘리기 위해서 인력을 늘리는 것은 합리적으로 보일 수 있으나, 소프트웨어 개발에서는 통용되지 않습니다. 인력이 늘어나면 의사소통 채널도 비례하여 증가하기 때문입니다. 앞서 말한 프레더릭 브룩스는 ‘맨먼스 미신’에서 그 이유를 아래와 같이 자세히 설명하고 있습니다.

“사람과 일정을 교환할 수 있는 경우는 서로 소통할 필요가 없는 경우다. 이는 밀을 수확하거나 목화를 따는 일에는 들어 맞겠지만, 시스템 프로그래밍에는 대략이라도 해당하지 않는다. 아기가 세상에 태어나려면 임산부가 몇 명이든 아홉 달이 필요하다.”

그는 의사소통 비용을 구하는 공식도 간략하게 소개했습니다. 공식에 따르면, 개발자를 n이라고 했을 때, ‘n(n-1)/2’로 볼 수 있습니다.

5명의 구성원으로 구성된 프로젝트팀의 경우, 필요한 커뮤니케이션 채널 수는 ‘5*(5–1)/2=10’입니다. 10명은 ‘15*(15–1)/2=105’, 50명은 ‘50*(50–1)/2=1,225’ 등으로 비용이 급격히 오릅니다.

이러한 의사소통 비용의 문제와 이로 파생되는 소프트웨어 품질의 문제는 이미 오래전부터 기업들의 큰 고민거리였습니다. 그래서 조직 문화를 통해 문제를 해결해 소프트웨어 품질을 관리하고자 노력했습니다. 대표적으로는 아마존(Amazon)의 ‘피자 두 판 법칙’과 토스의 ‘사일로(Silo)’가 있습니다.

콘웨이의 법칙(Conway’s law)의 활용

피자 두 판의 법칙이란 아마존(Amazon) 창업자 제프 베조스가 제시한 팀 운용 법칙입니다. 팀원 수나 회의에 참여하는 사람 수가 피자 두 판 이상을 먹을 인원보다 적어야 하는 것입니다. 보통 피자 두 판은 16조각 정도입니다. 법칙에 따르면, 한 사람당 2~3조각씩 먹는다고 할 때 아무리 많아도 팀원이 8명을 넘지 말아야 합니다. 제프 베조스는 이런 조직문화를 기반으로 회사 내부를 작은 팀들로 구성해 각 팀이 민첩하게 움직이며 의사결정 속도가 높고 결합도가 낮은 조직(Loosely coupled organization)을 운영하고 있습니다.

토스는 ‘사일로(Silo)’라는 조직 단위 구조로 운영하고 있습니다. 각 사일로는 10명 미만의 인원으로 구성되었으며, 하나의 사일로가 하나의 서비스를 담당합니다.

“우선 조직의 크기가 작아야 합니다. 송금·조회·보험 등 각 서비스를 운영하는 토스의 ‘사일로’는 팀원이 10명을 넘지 않습니다. 10명 미만의 조직이 각 사업의 의사결정을 다 내리죠. 각 사일로가 해당 서비스의 최종 의사결정권자이기 때문에 대표인 제게 공유하는 등의 통상적인 절차 없이 스스로 알아서 결정할 수 있습니다. 인원이 적기 때문에 합의 비용이 적게 들고 의사결정을 하는 속도도 빠릅니다.”

사람 간의 의사소통은 복잡하고, 각각의 사람들은 의사소통을 위한 제한된 에너지를 가지고 있습니다. 문제가 복잡하고 여러 조직에 의존성이 있다면 이를 분리해서 효율적인 의사소통을 지원해야 합니다.

위에서 살펴본 아마존과 토스를 비롯해 많은 IT 서비스 기업들이 의사소통 비용을 줄이기 위해 책임을 분리하고 부서의 경계를 명확하게 하여 팀을 간소화하는 정책을 시행하고 있습니다. 더불어 각 소규모 팀은 자신이 담당한 해당 모듈을 책임지도록 조직 구조가 운영되고 있습니다. 이를 통해 모호한 경계를 경계하고, 각 팀끼리 상호 운용 관계를 맺을 수 있도록 설정합니다.

이런 조직 구조는 오늘날의 ‘MSA(Micro Service Architecture)’ 형태의 시스템 디자인으로 이어졌습니다. 각 팀이 가지고 있는 책임은 ‘특정한 문맥(Bounded Context)’으로 제한되어 구분됩니다. 예를 들면 영업팀의 관심사와 책임은 ‘영업’이고, 마케팅팀의 관심과 책임은 ‘마케팅’입니다.

이런 책임과 관심에 따른 분리는 시스템의 분리로 이어지게 되었습니다. 이에 따라 자연스레 하나의 단위 서비스에 사용자 화면과 비즈니스 프로세스 및 DB를 포함하여 소규모 팀이 주도적으로 서비스를 발전시키는 소프트웨어 아키텍처가 등장하였습니다. 이를 ‘MSA(Micro Service Architecture)’라고 부릅니다.

MSA를 적용한 조직은 더욱 적극적으로 의사소통 비용을 낮추기 위해서 노력합니다. 심지어 사용하는 단어조차 일관성 있게 사용하고자 노력합니다. 지식관리시스템을 이용하여 용어사전을 만들어서 이용할 정도입니다. 정의된 용어는 의사소통, 문서화뿐만 아니라, 소프트웨어의 코드와 데이터에도 담겨서 사용됩니다. 이런 노력은 도메인 주도 설계에서 ‘Ubiquitous Language(보편 언어)’를 사용하는 방법으로도 널리 알려져 있습니다. 조직 내 공동의 어휘를 사용해 의사소통 비용을 낮춰서, 기술 부채를 비용을 개선하고 생산성을 높이는 방식입니다.

흔히 MSA를 적용하려는 많은 기업과 조직은 도입을 위해 클라우드, K8S, API-Gateway, Spring Cloud, Saga pattern 등 개발환경이나 기술 스택을 중심으로 고민합니다. 그러나 MSA는 기술적인 부분 외 조직의 문화도 중요합니다.

서비스는 조직이 운영합니다. 작게 분리된 서비스들이 많아지면, 이와 비례하여 서비스 간 관계가 많아지게 됩니다. 서비스 사이의 관계 구간은 운영 관리가 필요한 구간입니다. 조직의 구조가 뒷받침이 되지 않으면 관리할 부분만 증가하게 됩니다.

따라서 MSA를 적용하고자 하는 기업들은 업무 전문가와 개발자가 함께 참여해 워크숍을 진행하여 시스템과 조직의 구조를 분석하고 개선하는 작업을 먼저 진행하곤 합니다. 기업 내 조직의 커뮤니케이션 형태를 기반으로 ‘이벤트 스토밍(Event Storming)’ 등의 방법을 통해 업무 도메인을 분석하고 단위 서비스를 설계해 나갑니다. 이를 통해 시스템 구조를 설계하고, 더 나은 운영을 위해 조직구조를 개편하기도 합니다.

결국 조직의 의사소통에 따라서 시스템의 구조가 설계되기도 하고, 역으로 시스템 구조에 따라서 조직의 의사소통 구조가 반영되는 것입니다. 시스템 구조에 따른 조직 구조의 변경을 ‘역콘웨이 법칙(Reverse Conway’s Law)’이라고도 합니다.

“MSA를 채택할 때는 무엇보다 비즈니스를 중심으로 생각해야 한다. 비용은 물론 기술적·조직적 제약 조건을 충족시키는 세밀성과 분해의 올바른 균형을 찾는 것이 목표가 되어야 한다. MSA에 대한 최적의 접근은 실무진이 주도하면서 최종 결정자가 적극적으로 지원하는 것이 중요하다.” -Gartner

마무리하며

지금까지 콘웨이 법칙에 따라 ‘사람과 조직의 의사소통은 결국 시스템에 영향을 준다’는 것을 설명했습니다. 이런 사실을 미리 알고 있던 기업에서는 이미 조직 운영에 콘웨이 법칙을 활용하고 있습니다. 아마존과 토스가 대표적입니다.

만약 기업 내 조직 문화를 개선하고 싶으면 가능한 모든 수단을 활용하여 의사소통 효율성을 높여야 합니다. 그리고 꼭 해당 업무와 관련된 사람들이 소통하도록 강조해야 합니다. 중요한 건 사람과 시스템 사이를 개선할 때 명확한 책임과 의무가 있어야 합니다. 그리고 책임을 이행하기 위해서는 누구에게 문의해야 하는지 조직구성원 모두가 알 수 있어야 합니다. 좋은 시스템의 구조는 조직 구성원의 작은 한마디부터 시작된다는 걸 잊지 말아야 합니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.