개요

여러 legacy 를 직접 만들거나(😭) 다른 곳에서 만든 legacy 를 유지보수/운영해 본 경험을 정리해보면 아주 이상한 현상이 있었습니다.

레거시 서비스들은 Monolithic Architecture 를 가지므로 한 서비스에 모든 기능이 통합되어 있으므로 하나의 변경이 여러 side effect 를 발생시킬수 있습니다.

이때문에 변경시 구성원들간 긴밀한 소통과 협조가 필요한데 레거시일 수록 소통이나 협조가 부재했고 문제가 발생하면 서로 비난하고 책임을 전가하는데 급급했습니다.

보통 이런 책임 전가는 장문의 Email 을 다수의 이해 관계자들을 CC 로 추가해서 보내고 내용의 사나움은 제목에 Re: 와 FW: 의 갯수만큼 커져갔습니다.

이런 일이 발생하는 건 대개 사일로 현상을 필연적으로 발생시킬수 밖에 없는 조직 구성(Functional Team) 문제때문이라고 생각합니다.

개발팀, 영업팀, 운영팀, 보안팀등 기능별로 팀을 쪼개다 보니 각자 수행하는 기능 입장(관심사)에서만 생각하고 이 일을 왜 하는지에 대한 목표가 불명확해지고 팀의 목표와 회사의 목표가 align 되지 않기 때문입니다.

콘웨이의 법칙

이런 현상을 잘 설명해주는 게 바로 콘웨이의 법칙이 아닐까요.

조직의 시스템 디자인은 해당 조직의 의사 소통 구조의 닮게 된다.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway

제대로 된 SW 와 서비스를 만들려면 조직 구조와 조직 문화가 받쳐주지 않는다면 많은 스타 개발자가 있더라도 불가능하다고 봅니다.

성당과 시장의 저자이자 저명한 오픈소스 개발자인 에릭 레이몬드는 다음과 같이 말했습니다.

컴파일러를 개발하는 4개의 그룹이 있을 경우 4단계로 실행하는 컴파일러가 나오게 된다.
If you have four groups working on a compiler, you'll get a 4-pass compiler.

조직 구조가 복잡하고 기능별로 나눠져 있을 경우 사공이 많아지게 되고 그러면 어떤 결과물이 나오게 되는지 명쾌하게 설명하고 있습니다.

왜 MSA가 필요한가?

역할과 책임이 복잡하게 얽혀 있는 모노리틱 구조의 대안으로 마이크로 서비스 아키텍처(MSA; Micro Service Architecture)가 주목받고 있지만 MSA 를 제대로 만들려면 조직 구조와 문화부터 바뀌어야 합니다.

MSA 는 특정 기능이나 도구가 아니라 애자일, DevOps, 협업과 공유등의 기업 문화에서 꽃 필수 있으니까요.

참고

Browser not supported