콘웨이의 법칙(Conway's Law) : '자세'를 잡지못한 조직이 '프로덕트'라는 힘을 쓸 수 없는 이유

컴퓨터 과학자 Melvin Edward Conway는 다음과 같이 말했습니다.

 

시스템 디자인은 조직의 커뮤니케이션 구조와 유사한 형태의 시스템을 만들게 된다 [1]

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure

 

이 말을 곰곰히 생각해보면, 특정 구조의 시스템 디자인을 원한다면 그러한 커뮤니케이션 구조를 만드는 조직 디자인(Organization Design)을 먼저 해야한다는 점을 알 수 있습니다. 

 

구체적 예시로 생각해보면, 이 말은 '마이크로서비스 아키텍쳐로 개발을 하려면, 마이크로서비스 아키텍쳐 형태의 조직 구조를 먼저 갖춰야 한다'와 같은 것들일 것입니다. 

 

다른 방향으로는, 원하는 시스템(또는 프로덕트) 디자인이 실제 조직의 커뮤니케이션 구조와 어긋난다면 목표하는 시스템 디자인을 이룰 수 없거나 추가적인 비용을 소모하게 된다고 느껴지기도 합니다.

 

그럴듯해 보이는 이 말은 명확한 근거자료가 있는 것일까요? 어느 정도 신빙성이 있는 말이라면, 실제 글로벌 기업이나 devops에는 어떻게 연결지어 이해될 수 있을까요?

 

---

 

조직의 커뮤니케이션 구조는 프로덕트 구조에 영향을 미치는가?

Conway의 아티클(1968) [1]은 조직 구조와 시스템 구조의 연관성에 대한 좋은 인사이트를 남겼지만, 이론적인 추론이었습니다. 하지만 비교적 최근 [2, 3]의 HBS(Harvard Business School)과 Microsoft의 연구결과는 양쪽 모두, '조직의 구조와 조직이 생산해내는 소프트웨어와의 연관성'을 시사하고 있습니다. 

 

특히, HBS의 연구는 조직 구조와 생산해내는 프로덕트의 구조의 미러링 현상, 즉 Conway's Law에 직접적인 결과를 뒷받침합니다. Loosely-coupled한 조직과 Tightly-couple한 조직에서 유사한 형태의 소프트웨어 제품(워드 프로세서, 재무회계 프로그램 등)이 어떻게 구현했는지 조사하였는데요. 그 결과, Loosely-coupled한 조직은 모듈로 구성된 프로덕트를(matrix 기법을 통해 수치화), tightly-coupled한 조직은 일부 코드의 수정이 전체에 미치는 영향이 큰 '뭉친' 코드로 구성된 경향이 강했습니다. 

 

그렇기에, 후자는 각 시기별 한정된 코어 개발자에 의존하고 그러한 코어 개발자가 떠나면 제품의 진화가 더뎌졌습니다. 반대로, 전자는 다수의 개발자가 참여하여 고르게 분포된 기여도를 보여주었습니다. 

 

Skewed Gnumeric (left) and Evenly distributed Apahce (right) - Image from [2]

 

Microsoft 연구도 Mythical Man-Month의 조직구조가 소프트웨어 품질에 영향을 미친다는 부분을 인용하며 시작하고 있습니다. Window Vista라는 샘플을 통해 조직구조가 초기의 소프트웨어 품질(테스팅, 디자인 재작업, 경제적 비용 등) 관점의 성공여부를 판가름하는데 유의미했다라는 정도의 결과를 보여주고 있습니다.

 

이렇게 조직의 커뮤니케이션 구조가 프로덕트에 영향을 미친다면, 최근의 마이크로서비스 아키텍쳐, Devops, FAANG 기업들의 뒷단에는 어떠한 조직 커뮤니케이션 구조가 존재할까요?

 

 

Modern Org Design for Software

어떤 조직구조여야 좋을까라는 생각을 하다보면, 어떤 프로덕트여야하나라는 생각을 먼저하게 됩니다. 특히 프로덕트의 구조, 아키텍쳐를 고민하게 되는데요. 이 부분에 있어서, 책 Team Topologies [6]는 무엇을 고려해야할지 잘 정리해주고 있습니다.

 

1. Conway's Law를 이해할 것, 즉 조직 (커뮤니케이션) 구조가 프로덕트 구조에 미치는 영향을 이해할 것

2. 그렇기에 목표하는 시스템 아키텍쳐를 이루기 위해서, 조직과 팀 구조를 그에 맞게 정비할 것 (Reverse Conway Maneuver)

3. 정비 시, 아래와 같은 사실에 유의할 것

- 개인이 아닌, 팀에 보상을 줄 것

- 피자 한 판의 팀(5 ~ 15명, 가능한 작은 팀을 권장)을 최소단위로, 팀은 장기적으로 유지할 것

- 팀에 명확하고, 인지적으로 부하가 높지않은 범위의 도메인을 할당하고 너무 넓어지지 않도록 제한할 것

- 도메인 간의 커뮤니케이션 패턴을 정리하여, 불필요하게 많은 커뮤니케이션이 발생하지 않도록 할 것

- 팀 간에는, 가능하면 명확한 API로 교류하도록 할 것

- '공유지의 비극'을 최대한 피해서, 각 도메인에 명확한 팀을 할당할 것

 

이런 작은 유닛 구조는 새로운 정보에 부분부분 빨리 대응할 수 있게 한다는 점 [7], 그로 인해 유연한 시스템과 유연한 프로덕트를 가능하게 합니다. 

 

또한, 구체적으로는 그러한 팀에는 어떠한 종류가 있고, 팀 간의 인터랙션은 어떠한 종류가 있는지 아래와 같이 전달해주고 있습니다. 

 

팀의 종류

 

• Stream-aligned 팀: 비지니스 도메인 또는 특정 조직 기능에 align되어 지속적인 업무(feature delivery)를 진행하는 팀. 다른 종류의 팀들은 이 팀의 부하를 덜어주는 것이 주요 목적이게 됨. 프로덕트 delivery의 풀 스펙트럼에 관여하기에 피드백이나 시스템 문제에 near-realtime으로 반응해야 함. 
• Complicated-subsystem 팀: 특정 지식에 깊게 관여한 컴포넌트를 개발하고 운영하는 역할을 담당함. 
• Enabling 팀: 특정 기술 도메인의 전문가로 구성되어, 여러 Stream-alinged팀이 특정 기술 전문성이 필요한 문제를 빠르게 해결하는 것을 지원함. 
• Platform 팀: Stream-aligned 팀이 자율적으로 업무(on-demand)를 진행할 수 있도록 지원함. 

위와 같은 프레임워크를 통해, 현재의 우리팀은 어떠한 역할들을 하고 있는지, 그렇다면 어떤 종류에 해당되고 그 목적은 무엇인지 분석해볼 수 있습니다. 

 

 

Final thoughts

헬스를 하다보면, 아무리 힘을 주어도 제대로 힘이 들어가지 않을 때가 있습니다. 대부분 부정확한 자세에서 기인하는 그 문제는, 애꿎은 곳에 힘을 주어 리소스를 낭비하고 목표한 부분을 타겟팅하지 못하는 기대와는 다른 디자인을 낳게 됩니다. 

 

프로덕트도 내부는 조직 커뮤니케이션 구조에 많은 영향을 받습니다. 필요없는 것 같은 커뮤니케이션이 너무 많이 발생하고 있거나, 조직구조와는 다른 형태의 커뮤니케이션이 필요한데 발생하지 못하는 경우에는 Conway's Law의 관점에서 양쪽을 점검해볼 필요가 있겠습니다.

 

 

 

 

Reference

[1] https://www.melconway.com/Home/pdf/committees.pdf

[2] https://www.hbs.edu/ris/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf?lipi=urn:li:page:d_flagship3_pulse_read;Jt69%2BCqYSgSZqq23lkSrbA%3D%3D

[3] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf

[4] https://radekmaziarka.pl/2021/03/14/conways-law-how-organizations-structure-influences-its-results/

[5] https://teamtopologies.com/key-concepts

[6] Team Topologies

[7] A second effect on performance of creating small, empowered units is to increase the likely speed of adaptation to new information - John Roberts, The Modern Firm