기업이 바라는 소프트웨어 아키텍처를 도입하기 위해서 가장 먼저 해야 하는 일은 무엇일까요?ㅣ콘웨이 법칙ㅣConway's Law
상태바
기업이 바라는 소프트웨어 아키텍처를 도입하기 위해서 가장 먼저 해야 하는 일은 무엇일까요?ㅣ콘웨이 법칙ㅣConway's Law
  • 김인현
  • 승인 2023.03.02 09:44
  • 조회수 1932
  • 댓글 0
이 콘텐츠를 공유합니다

 

정보기술은 계속 바뀌고 있습니다. 1960년대 초기에는 메인프레임시대였는데요. 1990년대에는 클라이언트서버 시대가 시작되었습니다. 2010년 이후에는 클라우드 네이티브 아키텍처가 확산되고 있으며, 정보화 사회에서 디지털 경제로 진화됨에 따라 마이크로서비스 아키텍처가 베스트프랙티스가 되었습니다. 새로운 아키텍처를 도입해야만 비즈니스 경쟁력을 확보할 수 있는데요. 기업이 바라는 소프트웨어 아키텍처를 도입하기 위해서 가장 먼저 해야 하는 일은 무엇일까요? 외부에서 전문가를 채용하기도 하고 새로운 기술을 적용한 플랫폼을 도입하기도 합니다. 그러나, 이러한 시도들만으로 충분하지 않습니다. 이를 해결하기 위해서 생각해야 하는 법칙이 있는데요. 바로 콘웨이의 법칙입니다.


콘웨이의 법칙은 1967년에 앨빈 콘웨이 박사가 이야기를 했고 콘웨이 법칙의 원문은 다음과 같습니다. 

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

“조직이 만드는 시스템의 설계는 조직의 의사소통 구조를 닮는다”

소프트웨어 아키텍처는 조직의 의사소통 구조에 따라 결정된다는 뜻입니다. 콘웨이는 이러한 생각을 1967년, 하버드비즈니스리뷰에 기고했지만, 가설을 입증할 수 있는 증거가 부족하다는 이유로 기각되었습니다. 1968년 콘웨이는 모듈 프로그래밍이라는 국제 심포지움에서 “How do committees invent?” 라는 논문을 발표했는데요. 프레드 브룩스는 1975년에 ‘The mythical man-month”라는 책을 출간했습니다. 지연되고 있는 프로젝트에 인원을 추가 투입하면 프로젝트는 더 지연된다는 주장으로 유명합니다. 또한 콘웨이의 법칙을 소개했습니다. 소프트웨어의 인터페이스는 조직의 의사소통방식을 따라갈 수 밖에 없는데, 대부분 조직의 의사소통 방식에는 문제가 있다는 점을 설명했습니다. 그리고 콘웨이 법칙은 55년이 지난 2023년인 지금에도 여전히 유효합니다. 더 나아가서 어떤 면에서는 소프트웨어 아키텍처 도입을 성공하기 위해 반드시 지켜야 하는 규칙이 되어 있습니다. 


콘웨이는 코볼과 알골 컴파일러를 만드는 프로젝트를 수행했습니다. 프로젝트 난이도와 업무량을 고려하여, 코볼 컴파일러 작업에는 다섯 명을, 알골 컴파일러 작업에는 세명을 투입했고 컴파일러가 완성되었습니다. 코볼 컴파일러는 다섯 단계로, 알골 컴파일러는 세 단계로 수행되도록 개발되었고 코볼과 알골의 컴파일 단계가 다른 것은 프로그래밍 언어의 특성 때문이 아니었습니다. 투입된 개발자가 각각 다섯 명이고, 세 명이었기 때문입니다. 완성된 소프트웨어를 만들기 위해서 개발자들은 각자의 개발 범위를 정해야 합니다. 그리고 다른 개발자와 커뮤니케이션을 해야 하죠. 소프트웨어가 통합된 모습으로 개발되기 위해서는 각 개발자의 범위가 서로 충돌되지 않아야 합니다. 이는 개발자의 구성 형태가 소프트웨어의 모습을 정하는 결과가 됩니다. 

 

콘웨이의 법칙은 현실 세계에서 증명됩니다. 우리나라 금융회사들은 하나의 IT조직에서 전체 사업부서가 사용하는 소프트웨어를 만들고 운영하는데요. 당연히 금융회사 IT조직의 규모는 커질 수밖에 없습니다. 거대한 IT조직은 하나의 통합된 소프트웨어를 개발하기 위해 개발팀들 간의 의사소통을 중요하게 생각합니다. 엔터프라이즈 아키텍트가 전체 소프트웨어 모습을 총괄하고 개발 조정 프로세스는 각 개발팀이 독자적으로 행동하는 것을 금지합니다. 개발자들은 다른 개발팀이 소프트웨어를 어떻게 만들고 있는지 알아야 하며 또한 다른 팀의 소프트웨어가 변경되면, 변경 영향을 파악해서 자신의 소프트웨어를 고쳐야 합니다. 자연히 통합된 IT조직은 통합된 소프트웨어를 낳는데요. 우리나라 금융회사들의 금융 시스템이 거대한 모놀리스(Monolith)가 되어 있는 것은 당연한 결과입니다. 외부의 반화에 대응하기 위해 전체를 동시에 변화시키는 빅뱅 방식을 적용할 수밖에 없게 됩니다. 콘웨이의 법칙이 작동하고 있는 것입니다. 

 

손해보험회사의 차세대시스템 모델링 컨설팅하던 때가 생각납니다. 당시에 손해보험회사는 고객 서비스를 강조하고 있었는데요. 손해보험회사의 상품은 일반, 장기, 자동차, 퇴직연금 등으로 구성되어 있었고 고객이 보험사를 찾아오면 상담하는 직원은 고객이 어떤 보험을 가입하고 있는가를 알기 위해서 상품별로 만들어져 있는 화면들을 열어봐야 했습니다. 고객 정보 조회가 기본과 상세로 나누어져 있기도 해서 조회해야 하는 화면 수가 상당히 많았습니다. 고객 중심이라면서 실제로 시스템은 상품 중심으로 되어 있어 개발자와 협의했습니다. 데이터 테이블의 설계가 상품별로 나누어져 있기 때문이라고 했습니다. 네 종류의 상품을 하나의 데이터 테이블로 표현하지 못하면 하나의 화면에서 고객 정보를 통합해 제공하는 것은 불가능합니다. 현업부서와 상의했고 현업부서는 보험 상품별로 따로 구성되어 있었습니다. 현업부서의 용어 개념, 업무 규칙, 관리 기준 등은 달랐습니다. 컨설팅 당시에는 강하게 주장했는데요. “고객 중심이라면서요? 왜 통합하지 않는 거죠?” 그리고 고객 통합 데이터 모델을 제시했고, 고객 정보 조회 화면을 하나로 통합했습니다. 하지만 사용하지 않는 항목들이 보여지게 되고, 고객 응대 시간이 길어지는 결과가 되었는데요. 시간이 지나면서, 통합된 데이터모델과 화면은 다시 상품별로 나누어지기 시작했었죠. 지금 생각해보면, 소프트웨어 아키텍처를 정하기 위해서, 조직의 의사소통 방식을 따라야 한다는 점을 간과했더라고요.

 

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

 

디자인 패턴으로 유명한 마틴 파울러는 2022년 그의 블로그에서 콘웨이의 법칙에 대해 설명하고 있습니다(https://martinfowler.com/bliki/ConwaysLaw.html). 소프트웨어에서 발생하는 커플링(모듈 간의 연관성, 커플링이 높아지면 모듈간 간섭이 발생함. 좋은 소프트웨어는 커플링이 낮아야 함)은 사용자들의 의사소통 방식에 영향을 크게 받는다고 설명합니다. 사용자들의 활동 지역이 다르거나 근무 시간대가 다르다면 이는 서로 다른 아키텍처를 가질 가능성이 큽니다.


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

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

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

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

 

댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.