모듈형 전투기 사례, AERALIS (2/2)
모듈러 디자인 A to Z를 살펴볼 수 있는 좋은 사례
이전 글에 이어서 Aeralis 사례를 다뤄보겠습니다.
앞에서 다양한 제품의 구성까지 정했다면, 이후에는 설계하고 검증하고 양산하는 일이 남았겠죠.
5. 제품 설계 및 검증
앞선 글에서 다수의 제품 구성, 모듈 조합에 따른 제품군을 정의했다면, 그것들을 실제로 설계를 해야겠죠. 원하는 성능을 갖춘 하나의 제품을 설계를 하기도 어려운데, 원하는 성능을 갖춘 다수의 제품을 만드는 건 더욱 어려운 일이겠죠.
그런 의미에서 정해진 아키텍처, 정해진 플랫폼 하에서 성능을 만족하는 건, 제약 조건을 하나 더 부여한 상태에서 제품을 설계하는 것과 다를 것이 없습니다. 이렇게 설계된 후의 제품이 검증 단계를 무사히 넘길 것이란 보장도 없습니다.
다수의 모듈을 조합하여 이론적으로 수천~수만 종류의 제품을 만들 수 있다고 하더라도, 완제품 검증을 모두 거치는 것은 현실적으로 무리일 뿐만 아니라 제품 검증 단계에서 상당수가 탈락을 하게 될 겁니다. 실제로 모듈러 디자인을 적용하여 다양한 종류의 제품을 만들 수 있다고 광고하는 제품은 상대적으로 제품 검증 단계의 부담이 덜한 제품이 많습니다. 가구, 액세서리 등 디자인이 중심인 제품이 대표적인 예시겠죠. 아니면, 조합되는 범위를 제품의 핵심 성능이 아니라 액세서리 같은 성능 외적인 부분에 집중한 제품들이 조합을 통한 제품 구성 활용을 합니다.
그 외 성능이 중요한 제품, 그래서 검증 단계가 중요한 제품들은 검증이 완료된 범위 내에서 제품 변형을 허용합니다. Aeralis 사례도 살펴보면 변형되는 범위가 정해져 있고, 그 안에서 검증은 완료가 됐을 겁니다.
만약 새로운 조합의 전투기를 만들고 싶다면 어떻게 할까요? 역시 검증 단계를 거쳐야 합니다.
원하는 성능이 나오지 않는다면? 정해진 플랫폼, 또는 아키텍처를 해치지 않는 선에서 성능이 나오도록 조정을 하겠죠. 주로 변동이 되는 모듈에 해당하는 부분일 겁니다. 그런데, 이렇게 해도 성능이 나오지 않는다면 결정을 해야겠죠. 기존 플랫폼을 바꿀 것인지 아니면 해당 파생 제품을 포기할 것인지를, 혹시 기존 플랫폼의 수명이 다해서 추후에도 변경이 필요할 것 같다면 플랫폼 세대를 바꾸는 작업부터 시작하겠지만 그것이 아니라면 플랫폼의 변화보다 파생 제품을 인정하지 않는 쪽이 가능성이 높을 겁니다.
여기서 알 수 있는 건 해당 플랫폼의 수명은 제품의 수명 주기보다 길지만, 플랫폼을 바꿔야 할 시점은 제품의 성능에 해당 플랫폼이 큰 장애가 될 경우에 해당한다는 겁니다. 그렇지 않을 경우는 최대한 맞추려고 할 겁니다.
아쉽게도 플랫폼과 제품 사이의 의사결정이 장기적인 관점과 효율성만 가지고 이루어지진 않는다는 겁니다. 플랫폼의 효과는 장기적이고, 간접적인 반면에 개별 모델의 효과는 상대적으로 단기적이고 직접적이기 때문에 플랫폼이 유지되기가 쉽지 않습니다. 그래서, 플랫폼을 위한 개별 조직과 개별 프로세스를 만들 것을 권장하는 이유가 여기에 있습니다. 주인 있는 모델 대비해서, 주인 없는 플랫폼은 아무도 보호해 주지 않겠죠.
Aeralis 사례는 마치겠습니다.
