콘웨이의 법칙( 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. 

Conway's Law

콘웨이는 조직 구조가 얼마나 아키텍처에 영향을 주는지를 강조했던 것이다. 늘 느끼는 건데 현재 직장은 "구조 공학적인 조직 구조"라는 생각을 하고 있었다.  객체 지향이나 CBD 기반의 프로젝트를 한다고는 하는데 조직 구조와 의식은 왠지 방법론에 맞지 않는 것 같은 느낌을 받곤한다는 것이다. 말은 CBD, OO로 한다고 하는데 실제 진행은 구조공학적인 방법론이다. 개발과 어울리지 않는 조직 구조를 그대로 이어받다 보니 유지보수 및 운영도 그 구조를 그대로 이어받게 되고 그러다 보니 계속 뭔가 조직과 시스템이 삐거덕 거린다. 

음...프레임워크라는 기본적인 컴포넌트 및 기능에 대한 이해와 경험이 부족한 것, 공수를 산정하는데도 화면 본수를 근거로만 산출하는 것( 물론 편의를 위해서 그럴수도 있다지만), 업무 어플리케이션과 시스템 단위로만 이해한다는 것 그래서 그 수준에서만 구조를 파악하고 있다는 점. 그 사람들의 머리에서는 시스템 아키텍처 수준에서 구조 파악이 끝나고 있다. 

공통과 프레임워크 및 어플리케이션 배포 구조를 포함하는 어플리케이션 수준의 아키텍처는 그들의 머리에 없다. 그것은 "니들"이 알아서 할 부분이다. 인력이 투입되고 돈이 들어가는데도 말이다. 어플리케이션 아키텍처에서 돈과 인력이 들어가야 하는 이슈가 발생하면 "니들"과 고객과 커뮤니케이션이 힘들어지거나 또는 고객이 왠지 "공돈"이 나간다는 기분이 들 수 있다. 아니면 "니들"이 잘 못해서 그럴 수 있다고 느낄 수 있을 것이다. 커뮤니케이션이 힘들어지는 상황이 되는 것이다. 

 

소프트웨어 구조와 맞는 아키텍처, 그 아키텍처의 모니터링과 확인을 담당하는 고객 조직의 존재. 이것의 일치에 대한 필요성이 느껴지고 제기되면  그 조직의 구조는 점점 효율적으로 변하게 될 것이다. 

근데 조직의 구조가 소프트웨어 구조에 영향을 주듯이, 소프트웨어 구조가 조직의 구조에도 영향을 준다는 의미의 Reverse-conway's law도 나왔단다. 변화의 속도에 부응하기 위해서 SOA가 유행되면서 독립된 작은 구조의 서비스가 업무 시스템을 구성하는 단위가 되고 마이크로 서비스(Microservice) 아키텍처가 유행되게 된다. 그러면서 기존의 어플리케이션 단위의 관리조직에서 서비스 단위의 시스템을 관리하는 조직도 변하게 된 듯하다. 그러면서 reverse 법칙도 나오게 된 듯 하다. 

Demystifying Conway's law

정리하면 아래와 같다는 것이다.

조직 구조 --> 소프트웨어 아키텍처  

조직구조 <--  소프트웨어 아키텍처