콘웨이의 법칙 - Conway's law

"시스템을 설계하는 조직은 필연적으로 해당 조직의 커뮤니케이션 구조를 복제한 설계물을 만들게 된다"

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

- Melvin E. Conway

해커들의 Slang을 모아놓은 Jargon File에서는 이를 아래와 같이 설명하고 있습니다.

 

소프트웨어 구조는 소프트웨어 개발팀의 구조와 같아질 것이다. 일반적으로 4개의 팀이 컴파일러 작업을 하고 있다면, 4단계의 컴파일러가 만들어질 것이다.

 

간단히 요약하자면.

조직의 구조 = 서비스의 구조.

이해를 쉽게 하기 위해서 아래 예를 봅시다.

Monolithic architecture

Monolithic architecture 서비스를 운영하는 조직의 경우, 모든 팀이 모놀리식 아키텍쳐와 같이 큰 하나의 유기체로 돌아가게 될 것입니다. 서비스의 각각의 구성이 서로 밀접하게 연결되어 있으니 전체가 하나의 팀이 되어 언제든지 쉽게 커뮤니케이션하고 공유할 수 있는 상태여야 하기 때문입니다.

Micro service architecture

반면 Microservice architecture를 따르는 조직은 필연적으로 분리될 수밖에 없습니다. Netlify, Spotify가 대표적인 예입니다. 서비스의 결속이 느슨해진다는 의미는 결국 legacy 코드에 대한 걱정을 쉽게 떨칠 수 있고 핵심기능에 좀 더 집중할 수 있게 도와줍니다. 마찬가지로 팀 또한 기능이나 서비스별로 분리가 되므로 자연스럽게 서비스와 조직의 구조가 일치하게 됩니다.

그렇기 때문에 마이크로서비스를 운영하는 회사는 팀 간의 원활한 소통을 중요시합니다!

물론 서비스 혹은 조직 아키텍쳐에 대한 깊이 있는 고민이 이루어지지 않은 회사에서는 통용될 수 없는 법칙일 수 있습니다. 왜냐하면 서비스의 구조가 어설프게 잡혀있다면 조직도 어설프게 돌아가고 있을 확률이 높기 때문입니다. 만약 확실한 컨셉이 존재하는 회사라면 자연스럽게 느낄 수 있는 법칙입니다.

역 콘웨이 전략(Inverse Conway's maneuver)

필연적으로 조직의 커뮤니케이션 구조를 복제한 설계 물을 만든다는 콘웨이의 법칙을 전략적으로 이용해서 조직의 구조를 마이크로서비스 아키텍처에 반영되도록 설계하는 걸 역 콘웨이 전략이라고 합니다.

마치며

데브옵스나 소프트웨어 개발 방법론 이야기를 할때, Agile같은 개념들을 팀에 급하게 적용하지 말고 조직과 문화가 함계 전체적으로 변경해야 된다고 언급했었는데, 긴 설명이 필요 없이 콘웨이의 법칙으로 깔끔하게 정리가 되네요.

Ref