콘웨이의 법칙(Conway’s Law)과 Two Pizza 조직

Updated:

1968년 Melvin E. Conway는 모듈 프로그래밍이라는 국제 심포지움에서 “How Do Committees Invent?” 이라는 논문을 발표했습니다. 이것은 조직 구조가 프로젝트의 기술적 결과에 어떻게 영향을 미치는지에 대한 내용을 포함하고 있습니다.

콘웨이의 법칙

대부분의 프로젝트에서는 PM/사업관리, PL, 기획자 그리고 설계자, 디자이너, Backend/Frontend 개발자, 테스터로 구성되어 있다. 좀 규모가 있는 경우 품질담당이 더 있는 경우도 있지만, 대부분 이런 인력 구성을 갖고 있습니다.

Glocal 기업의 과거 업무 중심의 조직 구조

업무 중심의 조직 구조의 문제점

현재에도 많은 기업의 조직구조가 업무 중시으로 구분되어 운영되고 있습니다. 특정 업무분야의 전문 인력을 모아 한 팀에 구성하면 좀 더 전문적인 판단을 하고 추가로 같은 역량 기반의 팀원이기에 시너지 효과도 클 것이라고 판단했기 때문입니다. 실제로 과거에는 이런 긍정적 결과가 나타났던 것을 사실이었습니다. 그러나 최근에는 비즈니스가 매우 빠르게 변화하고 있습니다. 이렇게 빠른 변화에 각 분야의 전문인력이 각자의 관점으로 변화를 분석하고 대안을 찾아 통합하는 방법으로는 이 변화의 속도를 따라가기 어렵습니다. 각 업무 분야에 대해서는 전문적일 수는 있지만, 통합에 많은 소통의 시간이 필요하게 된다는 얘기입니다. 아래 그림은 각 조직이 업무 중심으로 나눠져 있고 각 조직간의 의사소통이 조직간 선을 그려 넣은 것 처럼 복잡하고 많다는 것을 보여주고 있습니다.

업무 중심의 조직 구조

Cross Functional 한 조직의 등장

실제 IT 현장에서 일을 하다보면 프로젝트의 설계와 개발, 운영, 유지보수에도 이 업무 중심의 조직구조가 그대로 드러난다고 느끼게 되는데, 시스템이 왠지 조직별 이해관계과 또 소통의 복잡함으로 인해 순조롭지 않다는 것입니다. 아무리 훌륭한 방법론을 갖고 있더라도 이 처럼 조직이 업무 중심으로 분리되어 있다면, 이 조직이 마이크로서비스 아키텍처를 잘 개발하고 운영할 수 없게 됩니다. 그래서 각 업무 중심의 조직 간 원활하고 명확한 의사소통이 가능하도록 기획자, 설계자, 디자이너, 개발자, 테스트 등을 하나의 Cross Functional 한 팀으로 구성해야 한다라는 개념이 등장하게 되는데, 이런 조직을 Two Pizza 팀이라고 얘기합니다. 이 팀은 2개의 피자로 한 끼를 해결할 수 있을 만큼의 작은 인원으로 구성한다는 것을 의미하는데, 보통 5명에서 10명 사이의 인원으로 팀을 구성하게 됩니다.

Two Pizza 팀

여기에서 중요한 것은 각 업무별 전문가가 하나의 팀에 각각 분배되고 하나의 서비스를 담당해야 한다는 것입니다.

Cross Functional Team이 개발한 Microservices

이렇게 다양한 업무 기반의 팀원이 모인 팀은 팀에서 개발해야 하는 마이크로서비스를 설계하고 개발하게 됩니다. 팀 내에 각 업무별 전문가가 있기 때문에 마이크로서비스의 개발/운영을 위한 의사결정이 매우 빠르게 진행될 수 있습니다. 그리고 다른 서비스와 연계가 필요한 경우 해당 서비스를 담당하는 팀과 소통을 통해 연계를 처리합니다. 이렇게 개발된 마이크로서비스는 담당업무를 독립적으로 수행가능하고, 다른 서비스와 느슨한 연계를 갖는 잘 개발이 될 수 있게 됩니다.

Cross Functional Team이 개발한 Microservices

정리

1968년 콘웨이가 발표한 논문은 마이크로서비스 아키텍처를 설명하기 위한 것은 아니었습니다. 그러나 과거에도 그리고 현재에도 소프트웨어를 잘 만들기 위해서는 관리자, 기획자, 설계자, 개발자들이 자주 대화하면서 개발해야 한다는 사실은 변함이 없다고 생각합니다. 이런 대화가 조직의 경계로 인해 원활하지 못하면 올바른 소프트웨어가 만들어지기 어렵기 때문입니다.

콘웨이의 법칙을 요즘 상황에 맞게 재 해석해 보았습니다. “각 서비스 독립적으로 실행가능한 작은 서비스로 구성되고, 각 서비스는 느슨하게 결합되어야 한다.”라는 마이크로서비스의 특징을 살려 잘 개발하기 위해서는 효율적인고 유연한 유연한 조직으로 구성되야 한다.

50여년 전의 소프트웨어에와 그 구조에 대한 통찰이 지금의 상황에도 적용이 될 수 있다는 것에 감동하며 글을 마무리합니다.

감사합니다.