콘웨이의 법칙(Conway's law)에 대해서

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

• 소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게 된다.
• 콘웨이가 논문을 Havard Business Review에 제출했을 때에는 가설을 입증할 수 없다는 이유로 거절당했다고 한다.
  • 그러나 개발자들 사이에서는 상식의 반열에 오른 법칙이다.

 

콘웨이의 법칙

 

아마존(Amazon)의 사례

아마존의 제프 베조스는 피자 두 판의 법칙을 제시한 것으로 유명하다. 한 팀이 모여서 피자를 먹는다고 하면 피자 두 판으로 충분해야 한다는 뜻을 담고 있다. 한 팀의 적정 규모는 8명 내외라는 것이다. 아마존의 시스템 규모는 방대하고 이를 개발하는 조직의 규모는 상당할 것이다. 아마존의 서비스는 빠르게 변화하고, 새로운 상품이 소개되며 기존 상품 프로세스가 변경된다. 전체 시스템을 잘게 나누지 않으면 이러한 변화에 기민하게 대응하는 것이 불가능하다. 시스템을 잘게 나누기 위해서 해야 하는 일은 다음과 같다. 첫째, 소프트웨어의 모듈성을 확보한다. 다른 모듈과 의사소통은 오직 API(Application Programing Interface)를 통해서만 한다. 둘째, 소프트웨어를 개발하는 조직을 최소단위로 정의한다. 각 소프트웨어 조직은 다른 개발 조직의 소프트웨어 구조를 알 필요가 없다. 자율적으로 자신의 서비스를 개발하고 변경할 수 있어야 한다. 제프 베조스는 소프트웨어 아키텍처를 얻기 위해서는 소프트웨어 조직구조를 손대야 한다는 점을 정확하게 이해하고 있었던 것이다.

 

콘웨이의 법칙은 소프트웨어 아키텍트에게 세 가지 교훈을 준다.

 

첫째, 조직의 모습과 싸우지 말라. 소프트웨어 아키텍처가 조직의 모습을 닮는 것은 자연스러운 현상이다. 소프웨어 아키텍처가 꼬여 있다면 그 원인은 조직의 의사소통 방식에 문제가 있을 가능성이 크다. 그렇다고 해서 조직의 모습을 뛰어넘는 또는 조직의 모습과 독립적인 소프트웨어 아키텍처는 실패하기 쉽다.

 

둘째, 조직 구조를 활동 기준으로 나누기보다는 서비스를 기준으로 나누는 것이 좋다. 조직 구조를 활동 기준으로 나누게 되면 의사소통 노력이 증가한다. 예를 들어서 개발팀을 프런트엔드, 미들웨어, 백엔드 등으로 구분하기보다는 서비스 별로 구분하는 것이 좋다. 하나의 서비스팀에는 서비스 제공을 위해 필요한 모든 기능이 포함되어야 한다.

 

셋째, 역콘웨이 기동(the inverse Conway maneuver)은 유용한 도구이지만 만능은 아니다. 기존 시스템의 아키텍처가 딱딱한 경우, 개발조직을 변경한다고 해도 소프트웨어 아키텍처는 바뀌지 않을 것이다. 도리어, 개발자와 코드 간에 불일치가 발생하여 개선 활동에 방해가 될 가능성이 크다. 콘웨이 법칙은 도메인주도설계(DDD, Domain Drivem Design)에서 Bounded Context를 정할 때 도움이 된다.

 

정리하자면

팀의 구조를 프런트앤드, 백앤드로 나누면 해당 구조처럼 소프트웨어 구조도 프런트앤드, 백앤드로 나뉠 것이다. 유연한 소프트웨어를 설계하고 싶다면 팀의 커뮤니케이션 구조를 유연하게 바꿔야 한다.

 

함께 읽으면 좋은 글

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

기업이 바라는 소프트웨어 아키텍처를 도입하기 위해서 가장 먼저 해야 하는 일은 무엇일까요?