핵심 모듈의 조건

중요한 건 모듈 자체가 아니라, 역량 유무

모듈을 고정부와 변동부로 나누면, 정작 제품군 내에서 또는 시간에 따라서 변치 않는다는 속성에만
집중하는 경향이 있습니다.

​그러다 보면, 재사용하기 쉬운 모듈, 공용화하기 쉬운 모듈을 고정부 모듈로 정하고
그렇게 누가 봐도 당연한 기준을 가지고 실행해 놓고는 아무런 변화가 없다고 불만을 갖는 경우가 있습니다.

​자, 고정부와 변동부 모듈을 정할 때는 과거의 히스토리를 기준으로 모듈의 속성을 판단해야 합니다.
제품군 내에서 변화가 없으면 고정부의 속성을 갖는 것이고, 변화가 잦으면 변동부의 속성을 갖는 것입니다.

​그런데, 속성에 따라서 모듈의 분류, 고정부와 변동부로 나누면 될까요?
제 책에도 써놓았지만, 분류는 의지치가 담겨 있어야 합니다.

​여기서 의지 치는 무엇일까요?
"해당 제품군 내에서 모듈 A는 변화시키지 않겠다"
"두 세대 이상 모듈 B를 재사용하겠다"
등이겠죠. 당장 모듈 A와 모듈 B가 변동부 속성을 갖더라도 분류를 고정부로 하는 겁니다.

​자, 그럼 핵심 모듈은 무엇으로 정해야 할까요?
핵심 모듈은 말 그대로 관리할 가치가 있는,

관리할 가치가 있어서 중장기 계획을 세워야만 하는 모듈을
의미합니다.

​원가 비중도 높고, 제품 품질 속성에 지대한 영향을 미치는 등의 속성을 갖는 모듈이라면
핵심 모듈로 관리할 가치가 있는 것이죠.

​그런데, 이런 질문이 있을 수 있습니다.
우리가 직접 개발하지 않는데? 직접 만들지 않는데?
핵심 모듈로 해야 하나요?

​원칙적으로는 핵심 모듈이라면 내재화하는 것을 추천합니다.
제품에 미치는 영향이 지대하다면, 내부 역량으로 흡수하는 것이 유리한 것은 둘째치고
리스크를 줄이는 데 용이하기 때문이죠.

당장 그렇지 못하다 하더라도 관리는 필요합니다.
기술 로드맵을 작성할 것이고, 기술 로드맵에 따라서 모듈 로드맵을 작성해서 기획하겠죠.
직접 설계하고, 제조하지 않더라도 말이죠.

​소프트웨어도 동일합니다.
당장 우리가 소프트웨어 개발 역량이 없다면, 손만 빨고 있어야 할까요?
시스템에 미치는 영향이 크고, 그것으로 인해서 제품의 가치가 달라진다면
핵심 모듈로 관리하고 점차 내재화하려고 노력해야 합니다.

그렇게 안된다면 최대한 관리 범위 내에 두려고 해야죠.

​우리가 설계하고 제조를 하지 않는다면
공용화, 재사용에 대한 필요는 더욱 커집니다.
더더욱 철저하게 관리를 해야겠죠.

할 수 있는가 없는가의 문제가 아닙니다.
해야만 하는가에 대한 문제입니다.