1.7.1 소프트웨어 개발/전달 조직
사업이 성공하면 기술 팀 규모도 커지기 마련입니다. 더 많은 개발자가 더 많은 일을 할 수 있으니 일단 좋은 일이죠. 프레드 브룩스의 <맨먼스 미신>에 따르면 크기가 N인 팀의 소통 오버헤드는 O(N2)으로 증가한다고 합니다. 팀이 너무 커지면 소통 오버헤드가 급격히 증가하여 운영 효율이 떨어지죠. 매일 아침마다 팀원 20명과 스탠드업 미팅(standup meeting, 참석자가 서서 하는 회의)을 한다고 생각해 보세요.
그래서 규모가 큰 팀을 여러 팀으로 나누는 것이 좋습니다. 팀당 인원은 많아야 8~12명 정도가 좋습니다. 비즈니스 관점에서 팀의 목표는 명확합니다. 어떤 기능이나 비즈니스 능력(business capability)이 구현된 하나 이상의 서비스를 개발/운영하는 것이죠. 범기능(cross-functional, 여러 기능을 고루 갖춘) 팀을 구성하면 다른 팀과 매번 소통하거나 협의하지 않고 서비스를 독자적으로 개발, 테스트, 배포할 수 있습니다.
Note≡ 역 콘웨이 전략(reverse Conway maneuver)
마이크로서비스 아키텍처에서 소프트웨어를 효과적으로 전달하려면 콘웨이의 법칙(Conway’s law)13을 음미할 필요가 있습니다.
시스템을 설계하는 조직은…… 그들이 소통하는 구조를 그대로 옮겨 놓은 듯한 결과물을 낼 수밖에 없는 한계가 있다.
멜빈 콘웨이(Melvin Conway)
즉, 애플리케이션 아키텍처는 그것을 개발하는 조직의 구조를 그대로 반영한다는 뜻입니다. 따라서 이 법칙을 역으로 이용해서14 조직의 구조가 마이크로서비스 아키텍처에 고스란히 반영되도록 설계해야 합니다. 이렇게 하면 개발 팀과 서비스를 느슨하게 결합시킬 수 있습니다.