콘웨이 법칙 (Conway's Law), 역 콘웨이 법칙(Inverse Conway's Law)

무려 1967년에 맬빈 콘웨이(Melvin Conway)가 발표한 논문에서 소개한 내용이 요새에도 쓰이고 있다.

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure."

소프트웨어 구조는 그 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 따라간다는 말이지만, 문장의 앞뒤를 바꾸면 우리 나라사람들에게 직관적인 문장이 된다. 즉, 조직 구조/ 조직의 커뮤니케이션 구조가 소프트웨어 구조를 결정한다.

 

콘웨이 박사의 실험

코볼과 ALGOL 컴파일러를 제작하는 연구팀 여덟 명과 함께 수행한 콘웨이 박사의 실험 결과에 따르면,

• 난이도와 작업 추정시간에 따라 다섯 명이 코볼에, 세 명이 ALGOL에 배정되었음
• 코볼 컴파일러는 5단계로, ALGOL 컴파일러는 3단계에 걸쳐 실행되었음
• 즉, 팀을 구성하는 방법이 업무 수행 방식에 영향을 끼침.

 

조직 구조와 시스템 구조

조직의 구조는 조직의 의사 소통 구조와 밀접한 관계를 갖는다. 그리고, 조직의 의사소통 구조는 시스템 설계에 반영이 된다는 의미이다. 당연히 최초의 설계가 완벽할 수는 없으므로, 효율적인 설계를 하려면 조직 구성이 유연해야 한다. 단순히 인력을 추구하는 것이 생산성을 높여주지는 않으며, 유연한 조직/ 유연한 커뮤니케이션을 바탕으로 하는 설계가 바람직하다.

에릭 레이몬드는 The-Jargon-File의 콘웨이 법칙에서

If you have four groups working on a compiler, you'll get a 4-pass compiler.

라고 표현하였다. 결국 조직의 구성이 아키텍쳐에 영향을 준다는 의미이다.

http://www.catb.org/jargon/html/C/Conways-Law.html

 

3-Tier 아키텍처와 콘웨이 법칙 예

Frontend, Backend, DB로 이뤄지는 3-tier 아키텍처와 콘웨이 법칙을 예로 들면, 기술 중심으로 3개의 팀을 만든다.

• Frontend: Frontend 개발팀
• Backend: Backend 개발팀
• DB: DB관리팀

각 팀은 각 전문분야의 사람들로 구성되어 있기 때문에 기술관점에서의 응집력이 높다. 그러나, 비즈니스 기능 관점에서는 그렇지 않다. 무엇인가 변경하려면 세 팀이 각각 우선순위를 조율하고, 협력해야 하고 일정도 맞춰야 할 것이다. 즉, 변경을 쉽게하려면 기술보다 비즈니스 기능을 기준으로 응집력을 높여야 할 것이다.

 

역 콘웨이의 법칙 (Inverse Conway's Law)

한편, 콘웨이의 법칙을 반대로 적용하는 것으로 역 콘웨이의 법칙이 있다.

• 콘웨이의 법칙: 조직 구조가 소프트웨어 아키텍처를 결정함
• 역 콘웨이의 법칙: 소프트웨어 아키텍처 구조가 회사 조직 구조를 결정함

 

콘웨이 법칙이 나쁘고, 역 콘웨이 법칙이 좋다는 말인가?

콘웨이 법칙이 시사하는 바는, 소프트웨어 아키텍처에 조직 구조와 팀간 커뮤니케이션 구조가 그대로 투영된다는 것을 뜻한다. 즉, 팀의 구조와 설계의 관련을 무시할 수 없다는 것인데, 이를 간과하여 분리하여 설계하고자 하는 것을 피하자는 것이다. 다자간 커뮤니케이션이 많을 수록 좋다는 것이 아니라, 오히려 효율성에 근거하여 필요한 커뮤니케이션에만 집중하고, 불필요한 커뮤니케이션을 줄이는 구조가 더 바람직하다고 본다. 역 콘웨이 법칙은 이를 역으로 응용한 것이다. 원하는 소프트웨어 아키텍쳐를 얻기 위해, 아키텍처를 기반으로 그 아키텍처에 맞는 팀을 구성하는 방안이다.

따라서, 콘웨이 법칙과 역 콘웨이 법칙이 추구하는 바는 무엇인가? 소프트웨어 아키텍처와 팀의 구조를 일체화 시키는 것이 목적임을 다시 생각해 본다면, 이 두 법칙은 서로 배타적인 관계라기 보다는 저 목적을 성취하기 위한 상호 보완적인 관계로 보는 편이 보다 타당할 것이다.