콘웨이의 법칙 / 역 콘웨이 전략 ( Reverse Conway maneuver )

콘웨이의 법칙에 대해서 읽었을 때 이게 무얼 의미하는 지 몰랐다.

 

콘웨이의 법칙

지인에게 MSA에 대해 설명하다가 이걸 왜 해야 하냐는 이야기를 들었다. API의 요청 수가 많아져서 서버가 죽는 속도가 서버의 증설 속도보다 빨라지는 시점에 서버는 차례대로 다운되고 결국 모든 서버가 닫히면서 서비스가 중단된다는 설명을 해줬다. 기술적으로는 그랬다. 그런데 불현듯 조직에 대한 생각이 들었다. 기술적인 부분 말고도, 조직 관리 측면에서도 MSA는 필연적인 것은 아닐까? 나는 지금 내 생황이 떠올랐다. 나는 새로운 회사로 이직한지 이제 일주일이 되었는데, 이 회사는 현재 100명이 넘는 사람이 있어서 사람들 얼굴과 이름을 외우는 것도 한 세월이다. 아마 1년 후에도 다 못외우고 있을지도 모른다. 그런데 만약 모든 개발자가 나랑 같은 상황에 있다면, 어떠한 이슈가 발생했을 때 그 문제를 해결할 수 있는 담당자가 누구인지 찾는 것으로도 한 세월의 시간을 보낼 것이다. 그렇다면 문제를 적절한 시간 내에 대응할 수 없지 않을까. 담당자가 누군지 알 수 있게 하나의 서버를 잘게 잘라서 역할을 명확히 구분해야 한다는 생각이 들었다. 이 생각을 하자 나는 스스로가 대견하다고 느꼈다. 엄청난 생각이지 않은가? 조직을 최소한의 크기로 나눈, 여러 조직의 연결로 유지하는 것이 가장 안정적이란 생각을 한 것이다.

 

콘웨이의 법칙(Conway's Law)는 소프트웨어 개발과 조직 구조 간의 상관관계를 설명하는 원리다. 이 법칙은 조직의 커뮤니케이션 구조와 개발되는 소프트웨어 아키텍처 사이에 유사성을 보여준다. 존 코콘웨이가 1967년 제안한 이 법칙은 "어떤 조직이 설계하는 시스템은 해당 조직의 의사소통 구조를 반영한다."고 말했다. 즉, 조직 내부 구조와 의사소통 경로는 그 조직에서 개발되는 소프트웨어의 모듈 구조와 유사한 형태를 가지게 되는 경향이 있다.

 

역 콘웨이 전략

그런데 이미 있는 개념이었고, 내가 읽은 적 있는, 그럼에도 뭔 말인지 모르고 넘겼던 내용이었다. 콘웨이의 법칙을 이해하기에는 내가 가지고 있는 경험치가 너무 적었기 때문에, 크게 와닿지 못했던 것 같다. 그렇지만 이제 MSA를 배우고, 실제로 MSA를 적용 중인 조직에 있다보니 보는 안목이 더 키워진 모양이다. MSA의 채택은 사실 콘웨이의 법칙과 반대로, 조직의 형태가 기술을 결정하는 것이 아니라 기술의 형태, 모듈의 느슨한 결합이 조직의 형태를 바꾸는 것에 해당한다. 이를 역 콘웨이 전략이라고 한다. 개발팀과 서비스는 느슨하게 결합되어야 한다.