기술로드맵이 중심을 잡기 어려운 이유

도구가 아닌 그것을 쓰는 목적이 기획자가 디딜 땅

로드맵은 이제는 상식이 되었습니다. 어떤 목표를 달성하기 위해 필요한 단계적 과정을 기획하는 방식은 오래전부터 기술경영분야에도 도입되어 기술로드맵이라는 이름으로 불리고 있습니다. 국가에서도 기업에서도 어느 정도 규모가 있는 연구개발조직이라면 기술로드맵을 대부분 운영합니다. 상위의 제품이나 서비스 로드맵이 있으면 그 목표에 맞춰 필요한 기술을 개발하면 된다는 단순한 개념이지만 현실에서의 운용은 녹록지 않습니다.

제가 느끼는 기술로드맵의 현실적 어려움은 경영진과 개발자사이에서 위치해 있는 도구의 태생에서 비롯됩니다. 그 사이에서 중심을 잡기 어렵고 자주 휘청일 수밖에 없습니다. 먼저 연구개발 조직의 경영진 입장에서 기술로드맵은 그의 집권과정에서 이루고 싶은 목표이자 임원으로서 생존할 수 있는 포부와 의지를 내비치는 도구입니다. 기술로드맵은 결국 분류와 대상으로 구분이 되는데 경영진이 어떤 관점을 가지고 있느냐에 따라서 분류의 방식이 완전히 달라지고 로드맵의 콘셉트도 달라집니다.

가령 기술중심의 리더는 각 기술들을 어떻게 개발해 나갈지에 초점을 맞추고 이에 따라 최상위 분류는 기술의 카테고리가 됩니다. 개발자 관점에서는 가장 익숙한 형태이며 개발조직의 구성과도 잘 연계됩니다. 한편 제품중심의 리더는 개별기술이 중요한 것이 아니라 그래서 어떤 제품에 어떤 기능/성능이 들어갈지를 중요히 여깁니다. 그에게 성과는 어떤 기술을 개발했는지가 아니라 그래서 우리의 제품에 어떤 기여를 했는지입니다. 또 다른 유형의 고객중심의 리더는 기술/기능/성능이 중요한 것이 아니라 그래서 고객이 체감하는 효용이 올라갔는지를 중요하게 생각합니다. 그래서 고객이 느끼는 가치를 최상위 분류에 넣고 그것에 기술을 연결합니다. 이경우 하나의 기술이 다양한 가치를 줄 수 있기 때문에 연관관계가 복잡해집니다. 또한 가치라는 것이 추상적일 수밖에 없기에 개발자들이 로드맵을 직관적으로 이해하기는 쉽지 않습니다. 이렇게 로드맵은 임원의 임기에 맞춰 2~3년을 주기로 뒤엎어질 수밖에 없는 운명을 타고났습니다.

한편 연구개발의 관점에서 보면 기술로드맵의 현실적인 기능은 각 개발과제의 추진타당성을 증명하는 하나의 수단입니다. 그런데 이 기능만 너무 만연해지면 기술로드맵에 나의 과제를 반영하는데 집중하게 되고 때로는 조직에 거의 모든 과제가 기술로드맵에 등재되기도 합니다. 기술로드맵의 본 목적은 없어지고 부수적인 수단만 남은 격입니다. 이제는 마치 모두가 영어점수가 있어서 영어점수가 있으면 +가 아니라 없으면 -가 되는 이상한 상황이 됩니다. 이것이 지속되면 기술로드맵은 가치를 잃고 이제는 로드맵에 있다고 꼭 하는 것도 아니고 없다고 안 하는 것도 아닌 그냥 하나의 절차와 로드맵을 가지고 있다는 심적위안의 수단으로 전락하게 됩니다.

이것을 방지할 수 있는 유일한 방법은 기술로드맵을 만들고 운영하는 기획자가 할 수 있고 해야 될 역할을 명확화 하는 것입니다. 기술로드맵은 구조이고 도구일 뿐이고 그것을 어떻게 활용할 지라는 목적은 조직에 따라 상이합니다. 그런데 많은 경우 기술로드맵을 어떻게 쓴다는 목적을 뾰족하게 만드는 것이 아니라 기술로드맵을 만드는 것 자체가 목적이 되는 경우가 많습니다.

가령 기술로드맵을 원래의 태생에 맞춰 상위목표를 달성하기 위한 하위 과제를 운영하는 목적으로 활용한다면 기획자는 상위목표의 명확화와 하위 기술의 연계성을 매니지먼트해야 합니다. 기술로드맵에 들어와야 하는 기술과 그렇지 않은 기술의 편출입을 관리하는 것이 핵심이고 만약 특정기술이 들어온다면 그것은 반드시 실행하게 만드는 것에 중심을 두어야 합니다. 한편 기술로드맵을 개발자들이 참고할 수 있는 미래의 기술방향성을 제시하는 용도로 쓴다면, 아이디어/가능성/기회 발굴을 매니지먼트해야 합니다. 기술적 기회가 실제 개발과 연계될 수 있도록 새로운 개발을 조직에서 승인받을 수 있도록 하는 것에 중점을 두어야 합니다.

로드맵을 어떻게 쓸지 목적에는 정답이 있는 것이 아닌 조직의 합의입니다. 그러나 기술로드맵 자체가 목적이 되는 것은 명백한 오답입니다. 그러나 안타깝게도 기술로드맵이 목적이 되어 열심히 유관부문과 협업해서 수립했습니다로 끝나는 경우가 대부분입니다. 그 목적을 뾰족하게 해야 기획자가 살 수 있습니다. 목적이 명확해지는 순간 기술로드맵에는 경영자와 개발자사이에서 기획자가 설 땅이 생깁니다. 목적 없이 경영진에 집중하면 2~3년마다 온 땅을 갈아엎으며 실력이 쌓이지 않고 비슷한 일만 무한히 반복합니다. 반대로 목적이 없고 개발의 내용으로만 접근하면 절대로 개발자를 이길 수 없습니다.

중요과제의 선별 / 가능성의 제공 / 커뮤니케이션 / 단순종합 어떤 목적이든 상관없이 그것이 바로서야 경영진/개발자 모두에게 000 관점에서는 이렇습니다라는 의견을 내거나 질문을 던질 수 있습니다. 그 관점은 내가 가장 많이 고민했기 때문에 비로소 중심을 잡고 그 목적에서 기술로드맵을 운영하는 실력이 쌓일 수 있습니다. 도구는 수단일 뿐 목적이 절대로 되어서는 안 됩니다. 물론 기술로드맵이라는 도구가 태생적으로 중심을 잡기 어려울 수밖에 없는 것도 맞습니다.