바텀업 방식의 모듈화

모듈화에 대한 거버넌스

제가 소개하는 모듈화 방식은 처음부터 제품 아키텍처를 모듈 단위로 재정하는 하는 탑다운 방식이라면, 모듈화 활동을 바텀업 방식으로 수행하는 경우가 있습니다. 설계 인원들에게 자신들이 현재 만들고 있는 제품의 일부, 서브 시스템의 일부를 재사용 또는 공용화가 가능하도록 공모하는 방식입니다.

이 과정에서는 기본적인 모듈화 개념, 모듈화 방법을 소개해주고, 자발적으로 과제화하여 결과를 심사하는 단계가 포함됩니다. 과거 컴포넌트 화 활동도 이와 비슷했던 것으로 알고 있습니다.

결론만 이야기하면, 이 방법은 성공하기 쉽지 않습니다. 몇 가지 성공 사례는 나올 수 있지만, 그것이 사내에서 널리 확대되긴 쉽지 않습니다. 아니 거의 불가능에 가깝습니다.

그 이유는 무엇일까요?

모듈화에 대한 거버넌스가 없기 때문입니다.

우선 거버넌스 외에도 성공하기 쉽지 않은 이유는 많습니다.

대표적인 몇 가지만 살펴보면,

지나치게 정제되지 않은 모듈화, 즉 특정 제품이나 시스템에 특화된 모듈은 재사용성 또는 공용성이 떨어지게 되고, 활용이 안 되는 모듈은 사장되게 됩니다. 그렇다고 너무 일반화하면 모듈의 규모가 작아지게 돼서, 그것을 재사용 또는 공용화하더라도 효과를 못 얻게 되므로 사장되게 됩니다.

이 모든 것을 알맞은 모듈의 규모로 성공을 해서 만들더라도 시간의 흐름에 따라서 업데이트를 안 해서 사장되기도 합니다. 자, 여기서부터 거버넌스 문제가 불거집니다. 업데이트를 하는 주체는 누구일까요? 처음 모듈을 만든 사람 또는 팀이 주체일까요? 수많은 요구사항을 들어서 업그레이드하거나, 버전 관리해야 하는 주체는 누구일까요? 제품에 적용할 때마다 변경 관리는 누가 해야 할까요?

모듈 간의 기능 경계는 어떻게 조율해야 할까요? 모듈을 사용하도록 강제화할 수는 있을까요?

즉, 모듈의 라이프사이클을 관리하는 주체가 필요합니다. 그것을 모듈의 거버넌스가 있어야 한다고 말합니다. 그런데, 바텀업으로 공모식으로 모듈을 만들어내면 거버넌스에 대해서 고민을 안 하기 쉽습니다.

과제화 해서 성공하거나, 모듈로 결과물을 낸드음 끝나는 거죠. 오픈 소스 프로젝트처럼 참여 그룹이 꾸준히 관리하는 것도 아니니 돌봐주는 주체가 필요합니다.

그렇다면, 바텀업으로 하는 것이 모두 실패로 끝날까요?

차라리 모듈화 콘셉트를 완전히 적용한 제품 또는 시스템을 만들고, 이를 확대하는 편이 조금 더 현실적입니다. 그것은 모듈화에 대한 거버넌스가 제품 또는 시스템을 만드는 조직 또는 팀에 의해서 살아있기 때문입니다. 그리고, 한 가지 성공사례가 있을 테니 따라 하기 식의 또 다른 성공사례를 만들기 용이합니다.

그렇지만, 이 역시 제품 간, 시스템 간의 공용화, 재사용을 위한 활동으로 확대되기는 쉽지 않습니다. 그것도 이유는 동일합니다. 제품 간, 시스템 간 거버넌스가 없기 때문입니다.

정답은 없습니다. 그렇지만, 모듈화에 대한 결과물만 고민하는 것이 아니라, 모듈화를 관리하는 거버넌스도 같이 고민해야만 그를 통한 효과를 온전히 얻을 수 있을 겁니다.

Image by OpenClipart-Vectors from Pixabay