매튜스켈톤/마누엘페이스: 팀 토폴로지

콘웨이의 법칙과 중요성

"콘웨이의 법칙"이란 프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다는 것을 말한다. 

역콘웨이 법칙이란?

조직이 바라는 소프트웨어 아키텍처를 구성하려면, 팀과 조직 구조를 바꿔야한다는 주장이다. 이 전략은 설계부터 배포에 이르는 동안 팀 사이에 폭넓은 커뮤니케이션 활동이 없더라도, 업무를 완수할 수 있도록 지원하는 것을 목표로 한다. 

불필요한 커뮤니케이션 제한

팀 인터페이스를 정의해서 강한 협업이 필요한 업무와 그렇지 않은 업무의 종류에 대한 기대 수준을 명확하게 해야 한다. 

모든 사람이 모두와 커뮤니케이션할 필요는 없다. 개방형 사무실에서는 누구나 모두와 커뮤니케이션할 수 있다. 이런 환경에서는 모두가 다른 이들과 커뮤니케이션해야만 업무가 진행될 것이라 생각하는 커뮤니케이션 및 상호 작용 패턴에 빠지게 된다. (관련성을 확인하려면 소비자에게 책임을 전가하는 등...)

만약 조직이 '모든 구성원은 모든 채팅 메시지를 봐야만 한다.', '모든 구성원이 전체 스탠드업 미팅에 참여해야만 한다.', '모든 구성원은 회의에 참석해야한다.'고 기대한다면 조직 설계에 문제가 있는 것이다. 콘웨이 법칙은 다자간 커뮤니케이션 (many-to-many)이 뒤얽혀 있으며, 강하게 결합한 상호 의존적 시스템을 만드는 경향이 있기 때문에 빠른 흐름을 방해한다고 설명한다. 더 많은 커뮤니케이션이 언제나 좋은 것만은 아니다. 

콘웨이의 법칙은 효과적인 기술팀 설계에 매우 중요하다.

콘웨이의 법칙은 한 조직이 구현하는 소프트웨어 아키텍처에 조직 구조와 실제 팀 간 커뮤니케이션 경로가 그대로 나타남을 설명한다. 팀 자체의 설계와 소프트웨어 설계의 관련성을 인식하지 못하고, 분리해서 설계하려는 시도를 피하고자 한다.

조직 설계에 따라 아키텍처 결정을 위한 해결책의 수가 제한되기도 하고, 팀 간 의존성 정도가 달라져 소프트웨어 전달 속도에 큰 영향을 미치기도 한다. 

빠른 흐름을 바란다면 팀 간 커뮤니케이션을 제한해야 한다. 팀 간 협업은 개발의 발견과 전문 기술을 활용해 결실을 이루는 그레이 영역에서는 중요하다. 그러나 실행이 중요한 영역에서는 커뮤니케이션 자체가 속도에 큰 영향을 미친다. 

팀이 책임지는 도메인의 수와 종류를 제한하라.

1. 한 도메인을 한 팀에 할당하기

도메인의 크기가  한 팀이 다루기 너무 크다면, 도메인을 하위 도메인으로 나눈 뒤 각 하위 도메인을 한 팀에 할당한다. 도메인의 책임을 여러 팀에 부여하지 않는다.

2. 한 팀에 2~3개의 단순한 도메인을 할당하기 

절차적이고, 기계적으로 대응하기 때문에 도메인 간 컨텍스트 전환비용이 발생하더라도 감당할 수 있는 수준이다. 한 팀이 책임지는 단순 도메인은 크기가 작고, 가끔 간단한 변경만 하는 오래된 소프트웨어일지도 모른다. 판에 박힌 업무의 특성상 구성원의 의욕이 사라질 위험이 있다. 

3. 복잡한 도메인을 담당하는 팀에 다른 도메인을 더 할당하지 말아야 한다

간단한 도메인이라도 더이상 맡게 해서는 안된다. 이는 업무 흐름을 방해하는 비용과 우선순위 결정 때문이다. 

• 복잡한 문제 해결에는 시간과 집중이 필요하다.
• 예측할 수 있고, 간단한 문제를 먼저 해결하려는 경향이 있어서, 비즈니스의 가장 핵심인 복잡한 문제 해결은 나중으로 밀린다.

4. 한 팀이 난해한 도메인을 2개 이상 책임지지 않도록 해야한다 

이 팀은 2개의 하위 팀처럼 행동하면서도, 모든 구성원이 2개 도메인을 파악하고 있을 것이라도 기대하기 때문에 인지 부하와 조정 비용이 증가한다. 이런 팀은 둘로 나눠 5명으로 구성된 2개의 팀을 만들면 해결할 수 있다. 2개 팀은 각자 맡은 도메인에 더 집중하고 자율적으로 업무를 수행할 것이다. 

 

생각

• 다른 팀과 연동할 때, 커뮤니케이션을 최소화하는 방향으로 인터페이스를 개발했던게 생각난다.
  • 스웨거와 연동 가이드를 상세하게 작성한다거나 
  • 내부 구현체를 상대 팀이 몰라도 되게 추상화한다거나 
  • 변경 사항이 상대 팀 서버에 영향을 미치지 않게 한다거나  
• 내가 꼭 필요하지 않은 미팅은 과감하게 불참 신청을 했던 것들이 생각난다. 
• 커뮤니케이션 채널이 너무 많아지면, 의도적으로 전체 의견을 취합하는 절차를 생략하고 일을 추진했던 때가 생각난다. 
• 일하는 방법이 통합되지 않은 상태에서 시스템을 통합하는게 좋은 방향인지 고민되었다. 그런데 팀 구조가 반영되지 않은 상태에서 시스템을 통합하는건, 실제로 좋은 아키텍처가 아니라는 생각이 든다.