모듈러 아키텍처 평가 방법

힘들게 만들었으면 제대로 써먹어야

"감나무에서 감 떨어지길 바라는 것처럼"

모듈러 아키텍처만 만들어 놓고, 성과가 나길 바라는 경우가 종종 있습니다.

그것은 마치 미래의 찬란한 청사진을 그려놓은 후에 손 놓고 행동하지 않는 것과 다르지 않습니다.

모듈러 아키텍처링 과정을 통해서 제품의 변화와 그것을 운영하기 위한 기준과 절차를

이끌어냈다면 그다음은 철저히 실행하는 일만 남습니다.

"시키니까, 다들 하니까"

모듈러 아키텍처링을 통해서 모듈러 아키텍처를 만들어 놓고, 왜 성과가 나지 않는가라고 묻는다면, 명확한 방향성 없이 기계적으로 일을 한 겁니다.

모듈러 아키텍처를 만들어놓고, 업무가 변한 것이 없다면 과연 모듈러 아키텍처링 이후 운영 관리까지 고려해서 아키텍처링 과정을 거쳤는지 고민해 봐야 합니다. 경쟁사의 결과물만 베끼거나, 따라 한 건 아닌지 아님 흉내만 낸 건 아닌지 고민해 봐야 합니다.

이전 글에서 언급한 적 있었죠.

모듈러 디자인의 도입 순서는 모듈러 아키텍처링, 모듈러 오퍼레이팅, 모듈러 디자인 성과관리 순으로 진행하더라도, 모듈러 아키텍처링 과정에서 성과관리, 모듈러 오퍼레이팅을 고려한 후에 아키텍처링 활동을 수행해야 합니다.

정리하면,

첫 번째, 모듈러 디자인 방향성, 무엇으로 성과를 낼 것인가를 결정한 후에, 어떻게 성과를 낼 것인지 로직을 확정해야 합니다.

두 번째, 성과 로직을 실행하기 위한 프로세스, 조직, 시스템 측면의 변화를 고려해야 합니다.

보통 위 두 가지 활동을 마스터 플래닝 단계에서 수행하지만, 그 과정을 생략했다면 당연히 아키텍처링 단계에서 수행해야 합니다. 절대로 생략해서는 안 됩니다.

이후에 아키텍처링 과정을 진행하는 겁니다. 목적과 활동을 결정한 후에 그것을 위한 제품 아키텍처를 정의하는 겁니다.

물론, 한 번에 모든 것을 다 할 수 없습니다. 부족할 수 있습니다. 그래서, 정의와 최적화는 일회성 활동이 아니라, 반복 활동이라고 말하는 겁니다. 절차대로 부족하더라도 완결해놓고, 오퍼레이팅 해보고 부족하면 또 최적화하는 식으로 반복하면서 완성해 가는 겁니다.

이 과정을 통해서 모듈러 아키텍처링 과정을 마무리했다면, 제대로 모듈러 아키텍처가 만들어졌는지, 모듈러 아키텍처링 과정을 제대로 마쳤는지 확인하기 위해서는 다음 질문에 답할 수 있어야 합니다.

현재 사양 수를 파악하여 최적의 사양 수를 정할 수 있는가?

사양과 모듈 간의 관계가 명확한가?

사양 기준으로 모듈이 중복 없이 최소의 모듈 종수로 운영되는가?

사양의 변화를 모듈 간의 조합으로 대응할 수 있는가?

모듈의 종수를 최소로 유지할 수 있는가? 모듈의 사양과 종수는 파악되는가?

모듈 간 전용성이 없고, 모듈의 조합을 위한 인터페이스가 표준화되어 있는가?

신규 모델, 신규 사양에 대해서 최적의 공용화 수준을 유지하면서 대응할 수 있는가?

개별 질문에 대한 설명은 추후에 기회가 있으면 하겠지만, 결국 평가할 내용은 모듈러 아키텍처링의 결과물이 토털 버라이어티 관리와 모듈 운영의 효율성과 효과성 측면에 적합한 지를 살펴보는 것입니다.