헤더 바로가기 메뉴 바로가기 푸터 바로가기
전략

제품개발을 망치는 6가지 맹신

매거진
2013. HBR in DBR (~2013)


2701_02

편집자주

이 글은 <하버드비즈니스리뷰(HBR)> 2012 5월 호에 실린 하버드 경영대학원 경영학 교수 스테판 톰키(Stefan Thomke)와 라이너트슨 앤 어소시에이츠 사장 도널드 라이너트슨(Donald Reinertsen)의 글 ‘Six Myths Of Product Development’를 전문 번역한 것입니다.

 

제품개발 관리자들은 정해진 예산 범위 내에서 제때 프로젝트를 마무리하기 위해 항상 애를 쓴다. 제품개발 관리자들에게 프로젝트를 마무리하기에 충분한 자원이 주어지는 경우는 없다. 상사들은 항상 예측 가능한 스케줄을 제시하고 기한 내에 약속한 제품을 내놓을 것을 요구한다. 따라서 관리자들은 불필요한 지출을 삼가고 좀 더 구체적인 계획을 작성해 스케줄 변동 및 낭비를 최소화하도록 팀원들을 몰아붙인다. 제 기량을 발휘하지 못하는 공장의 성과를 개선하고자 할 때는 이 방법이 도움이 될 수도 있다. 하지만 제품개발에는 오히려 방해가 될 수도 있다.

 

제품개발이 제품생산과 유사하다는 가정 때문에 제품개발과 제품생산을 같은 방식으로 접근하는 기업이 많다. 하지만 제품개발과 제품생산 간에는 커다란 차이가 있다. 물리적인 제품생산의 경우 직무 자체가 반복적이고 활동이 꽤 예측 가능하며 새롭게 생겨난 제품을 한번에 한 장소에 모두 모아둘 수 있다. 반면 제품개발의 경우에는 수많은 직무가 제각기 독특한 성격을 갖고 있는데다 프로젝트 요건이 끊임없이 변하고 제품개발의 결과물이 정보의 형태를 띠는 탓에(고급 CAD/시뮬레이션 방식의 광범위한 활용 및 물리적인 제품에 소프트웨어를 포함시키는 방식이 그 원인) 동시에 다양한 장소에 존재할 수 있다.

 

제품생산과 제품개발 간의 중요한 차이를 제대로 이해하지 못하면 제품개발 프로젝트의 기획, 실행, 평가 등을 방해하는 몇 가지 잘못된 생각이 옳다고 믿게 된다. 필자들이 기업의 제품개발을 연구하고 기업에 제품개발 관련 컨설팅 서비스를 제공해 온 기간을 모두 합하면 50년이 넘는다. 이 기간 동안 필자들은 반도체, 자동차, 가전, 의료 장비, 소프트웨어, 금융 서비스 등 다양한 산업에서 이 같은 오해가 존재한다는 사실을 확인했다. (물론 다른 이유로 인해 또 다른 오해가 발생하는 경우도 숱하게 목격할 수 있었다.) 필자들은 이 글에서 어떤 오해가 있는지 살펴보고 오해로 인해 발생하는 문제를 극복할 방법을 제시할 생각이다.

 

잘못된 믿음 1: 자원 활용도를 높이면 성과가 개선된다.

필자들은 연구와 컨설팅 업무를 진행하는 동안 대다수의 기업들이 제품개발 자원을 최대한 활용하기 위해 애쓰는 모습을 목격했다. (도널드는 캘리포니아공과대 경영자 과정 참가자들을 상대로 조사를 실시해 제품개발 관리자들이 98%가 넘을 정도로 높은 수준의 역량 활용도(capacity utilization)를 유지한다는 사실을 확인했다.) 그 이유는 간단하다. 사람들이 근무시간을 업무에 100% 할애하지 않으면 프로젝트를 진행하는 데 좀 더 오랜 시간이 걸리며, 따라서 사람들을 활용하는 데 능하지 못한 조직보다 분주하게 돌아가는 개발 조직이 좀 더 빠르고 효율적이라고 생각하는 것이다.

 

하지만 이런 논리는 타당하지 않다. 관리자들이 제품개발 담당 직원들에게 쉴 새 없이 일을 시키자 프로젝트 진행 속도와 효율성, 결과물의 질이 오히려 하락하는 경우를 수없이 관찰했다. 관리자들의 숙련도가 아무리 높더라도 마찬가지다. 역량 활용도를 높이면 심각한 부작용이 생긴다. 하지만 관리자들은 다음과 같은 세 가지 이유 때문에 높은 역량 활용도가 초래하는 심각한 부작용을 과소평가한다.

 
2701_03

개발 업무가 갖고 있는 본질적인 변동성을 충분히 고려하지 않는다.프로젝트 시작 시기, 프로젝트가 요구하는 개별 업무, 이런 업무를 처리해 본 경험이 없는 직원이 업무를 완수하는 데 걸리는 시간 등 제품개발에는 예측 불가능한 측면이 많다. 하지만 기업들은 생산, 거래 처리 등 업무의 변화가 크지 않고 예기치 못한 사건이 자주 발생하지 않는 반복적인 공정에 익숙하다. 이런 공정은 자원 활용도가 높아지더라도 질서 정연하게 돌아간다. 업무량이 5% 늘어나면 일을 마무리하는 데 걸리는 시간도 5% 늘어난다.

 

하지만 변동성이 높은 공정은 매우 다른 방식으로 돌아간다. 활용도가 높아지면 지연 기간이 대폭 늘어난다. (그림1) 업무량이 불과 5% 늘어났음에도 불구하고 업무를 완수하는 데 걸리는 시간이 100% 증가할 수도 있다. 하지만 이 같은 효과를 제대로 이해하는 사람은 드물다. 수백 개의 제품개발팀을 관찰한 결과 필자들은 대부분의 제품개발팀이 심각할 정도로 과도한 업무에 시달리고 있다는 사실을 발견했다. 필자들이 함께 일했던 일부 조직에서는 모든 프로젝트를 정해진 예산 범위 내에서 제때 완수하려면 보유 중인 자원보다 최소한 50% 이상 많은 자원을 확보해야 할 정도로 자원 활용도가 지나치게 높은 현상이 관찰됐다.

 

물론 질서가 부족한 탓에 변동성이 발생하는 경우도 있고 제품개발과 관련된 일부 업무(: 항공기 원형 부품 설계, 임상 실험 진행)는 좀 더 반복적인 성질을 갖고 있다. 하지만 제품개발 업무 중 일부가 예측 가능하다 하더라도 예측 불가능한 다른 업무와 결합되면 대기 문제가 발생할 수 있다.

 

대기행렬이 경제적 성과에 미치는 영향을 이해하지 못한다. 자원 활용도가 높아지면 프로젝트 대기가 길어질 수밖에 없다. 업무가 부분적으로 완수됐으나 자원 공급이 여의치 않아 가용 자원이 할당될 때까지 대기해야 하는 상황이 되면 전체 프로젝트 기간이 길어진다. 대기행렬이 생기면 피드백 역시 지연되고 피드백이 지연되면 개발자들이 좀 더 오랜 기간 비생산적인 길을 걷게 된다. 대기행렬이 있으면 기업이 변화하는 시장 요구에 적응하고 너무 늦기 전에 제품의 취약점을 포착하기가 힘들어진다. 역설적이게도 관리자들은 활용도가 높으면 바로 이런 문제를 피할 수 있을 것이라고 생각한다.

 

대기행렬이 생기고 있다는 사실을 인지하고 있을 때조차 관리자들이 대기행렬로 인한 경제적 비용을 깨닫지 못하는 경우가 많다. 얼마든지 이 비용을 수치화할 수 있음에도 불구하고 실제로 이 비용을 계산하는 기업은 드물다. 관리자들은 적정선에서 균형을 유지하기 위해 자원 활용도가 낮을 때 발생하는 비용과 대기비용을 비교해야 한다.

 

제품개발 업무에서 공정중재고(work-in-process inventory)는 대개 눈에 띄지 않는다.제품을 생산할 때 대기행렬이 있을 경우 차례를 기다리는 것은 형태가 있는 물리적인 제품이기 때문에 공장 내 재고가 2배로 늘어나면 재고가 늘어났다는 사실이 분명하게 드러난다. 하지만 제품개발의 경우에는 다르다. 재고의 대부분을 구성하는 것이 결국 정보(설계 문서, 검사 절차와 결과, 원형 설계를 위한 설명 등)이기 때문이다. 엔지니어링 공정 내 재고가 2배 늘어난다 하더라도 물리적으로 보이는 것이 없다. 뿐만 아니라 회계 기준상 대부분의 R&D 재고는 0으로 표시해야 하기 때문에 재무제표를 보더라도 제품개발 부문에서 심각한 재고과잉현상이 나타나고 있다는 사실을 파악할 수 없다.

 

눈에 보이지 않거나 측정할 수 없는 문제와 맞서 싸우기는 매우 힘들다. 대형 제약회사 A에서 벌어진 상황을 보자. 몇 해 전, 새로 부임한 신약 개발 책임자 B는 관리와 관련된 딜레마에 직면했다. 대형 R&D 조직을 지휘하는 다른 고위급 임원들과 마찬가지로 B R&D를 담당하는 과학자들을 좀 더 혁신적으로 만들 방법을 찾기 위해 고심했다. B는 과학자들이 전도 유망한 신약으로 연결될 가능성이 큰 새로운 화합물을 갖고 좀 더 적극적으로 실험을 하고 그와 동시에 장래성 없는 후보 화합물을 가능한 빨리 제거하기를 기대했다. 하지만 생물을 이용한 실험은 B가 아니라 비용 부문(cost center)으로 운영되는 동물실험부서의 관할이었다. 동물실험부서는 검사 자원을 얼마나 효율적으로 활용하는지 평가를 받았으며 이로 인해 당연하게도 이 부서의 자원 활용도는 매우 높았다. 따라서 실험을 진행하는 데 걸리는 기간은 일주일을 약간 넘는 수준이었지만 신약 개발을 담당하는 과학자들은 실험을 맡긴 후 서너 달을 기다려야 결과를 받을 수 있었다. ‘활용도가 높은검사 조직이 신약 개발 부서의 업무 진행을 방해한 것이다.

 

이런 문제를 해결하는 데 가장 도움이 되는 방안은 매우 변동성이 높은 공정에 완충 장치(capacity buffer)를 제공하는 것이다. 몇몇 기업들은 이미 오래 전부터 이 같은 사실을 잘 알고 있었다. 3M은 수십 년 동안 제품개발자들의 역량 활용도를 85% 수준으로 유지할 수 있도록 업무를 조정해 왔다. 구글(Google)은 직원들에게 ‘20%의 자유 시간을 허락하는 것으로 유명하다. (‘20%의 자유 시간은 엔지니어들이 일주일 중 하루 동안 자신이 원하는 일을 할 수 있도록 허용하는 정책이다. 이 정책 덕에 특정 프로젝트가 예정보다 뒤처질 경우 추가적으로 역량을 투입하기가 수월하다.) 하지만 그동안 필자들이 직접 경험한 바에 미뤄보면 이런 해결방안을 실행하기는 매우 힘들다. 뒤에서 좀 더 자세히 이야기하겠지만 사용 가능한 직원 역량을 마지막 한 방울까지 쥐어짜내고 싶은 욕구를 참아낼 수 있는 조직은 드물다. 관리자들은 직원들이 나태하게 시간을 보내고 있는 장면을 목격할 때마다 본능적으로 좀 더 많은 일을 시작하게 된다.

 

하지만 다른 해결방안도 있다.

 

경영 관리 시스템을 변경하라.제약회사 A의 경우라면 동물실험부서의 목표를 신약 개발 부서의 목표에 맞춰 조정하기 위한 조치가 경영 관리 시스템 변경 방안에 포함될 수 있다. 가령, A가 자원 활용도보다는 신속한 반응을 기준으로(동물 실험 요청에서부터 실험을 완수하기까지 걸린 시간 측정) 동물실험부서에 보상을 제공하는 방법도 도움이 될 수 있다.

 

선별적으로 역량을 늘려라.자원 활용률이 70%가 넘는 곳에 추가로 자원을 배치하면 대기시간을 상당히 줄일 수 있다. A가 동물 실험 역량을 확충했더라면 새로운 화합물에 대한 피드백을 훨씬 신속하게 확보할 수 있었을 것이다. 컴퓨터 모델링과 시뮬레이션을 이용해 검사를 하는 경우라면 역량을 강화하기 위한 비용이 상대적으로 저렴한 경우가 많다. 컴퓨터 장비와 소프트웨어 라이선스를 구입하는 것만으로도 역량을 늘릴 수 있기 때문이다.

 

유효한 프로젝트의 수를 제한하라.제약회사 A가 동물 실험 역량을 강화할 수 없다 하더라도 새로운 화합물을 분석하는 유효 프로젝트의 숫자를 줄이는 방법을 통해 얼마든지 활용률을 낮출 수 있다. 제품개발 프로젝트의 숫자를 엄격하게 제한한 결과 좀 더 적은 수의 프로젝트에 더욱 집중하고 우선순위가 한층 더 명료해지는 경우가 많다.

 

공정중재고 재고가 좀 더 쉽게 눈에 띄는 환경을 조성하라.시각적 게시판을 사용하는 방법도 도움이 된다. 다양한 형태의 시각적 게시판을 활용할 수 있다. 하지만 여기서 가장 중요한 점은 개발 업무를 대신하는 물리적인 표시(: 포스트잇 메모)가 있어야 한다는 것이다. (그림3) 게시판에는 진행 중인 모든 업무와 프로젝트 각 부분의 진행 현황이 표시돼 있어야 한다. 게시판을 팀 관리 과정의 중심에 둬야 한다. 팀원들이 힘을 모아 노력하고 업무를 계속 진행하기 위해 매일 15분간 게시판 주위에 서서 회의를 진행하는 방법도 도움이 된다.

2701_04

 

잘못된 믿음 2: 공정 작업을 할 때 제조수량단위(batch)를 늘리면 공정 경제학이 개선된다.

제품개발 과정에서 대기가 발생하는 두 번째 원인은 제조수량단위가 많기 때문이다. 예컨대 신제품이 200개의 부품으로 이뤄져 있다고 생각해 보자. 그 어떤 부품도 검사하지 않은 상태에서 200개의 부품 모두를 설계하고 만들 수도 있다. 하지만 그 대신 검사를 시작하기 전에 20개의 부품만 우선적으로 설계하고 만들기로 결정하면 제조수량단위가 90%나 줄어든다. 이런 변화는 대기시간에 엄청난 영향을 미친다. 공정 내 평균 대기시간은 제조수량단위와 정비례하기 때문이다.

 

제조수량단위 축소는 린 생산(lean manu-facturing)을 위한 중요한 원칙이다. 제조업체가 제조수량단위를 줄이면 공정중재고가 줄어들고 피드백이 전달되는 속도가 빨라진다. 뿐만 아니라 이로 인해 사이클 타임이 빨라지고 품질과 효율성이 개선된다. 제품개발 시에는 제조수량단위를 줄이면 훨씬 커다란 도움이 된다. 하지만 제조수량단위를 줄이는 것이 얼마나 중요한지 제대로 이해하는 개발자는 드물다.

 

첫 번째 이유는 업무 흐름의 본질이다. 다시 한번 말하지만 대부분의 경우 개발자들이 만들어내는 정보가 개발자의 눈에 띄지 않기 때문에 제조수량단위 역시 개발자의 눈에 보이지 않는다. 둘째, 개발자들은 한번에 좀 더 많은 양을 처리하고자 하는 성향을 타고난 듯하다. 제조수량단위가 많아야 규모의 경제를 실현할 수 있다는 잘못된 믿음이 원인일 수도 있다.

 

공정이 제대로 관리되고 있는 경우라면 거래비용과 유지비용 간의 균형이 적절한 수준에서 제조수량단위가 결정된다. (그림2) 슈퍼마켓에서 달걀을 사는 것과 비슷하다. 한번 슈퍼마켓을 방문해 12달 동안 먹을 달걀을 구입하면 거래비용이 줄어든다. 하지만 대부분의 달걀은 썩어버릴 테고 결국 유지비용이 증가하게 된다. 한번에 하루치 달걀만 구입하면 달걀이 부패할 가능성은 낮아진다. 하지만 거래비용은 증가한다. 따라서 소비자들은 직관적으로 거래비용과 유지비용 간의 적절한 균형점을 찾기 위해 노력한다.

 

이 같은 사실을 깨달은 기업들은 IT를 활용해 제조수량단위를 줄였으며 그 결과 놀라운 성과를 얻었다. 과거에는 90일에 한번씩 많은 양의 코드를 검사했던 몇몇 소프트웨어 업체들이 지금은 하루에도 몇 차례씩 훨씬 적은 양의 코드를 검사하고 있다. 어느 컴퓨터 주변기기 제조업체는 소프트웨어 개발에 이 같은 접근방법을 적용한 덕에 소프트웨어 검사 사이클 타임을 95% 줄이고(48개월에서 2.5개월로), 효율성을 220% 개선하고, 불량을 33% 줄일 수 있었다.뿐만 아니라 예상했던 것보다 2배가량 많은 비용을 절약할 수 있었다. 물론 이 같은 결과는 예외적이다. 하지만 필자들은 연구를 통해 제조수량단위를 줄이면 대부분의 개발 프로젝트가 대폭 개선된다는 사실을 발견했다. 마찬가지로 물리적인 제품을 개발하는 기업 역시 컴퓨터 기반 모델링 도구와 시뮬레이션 도구를 활용해 실험과 검사를 위한 최적의 제조수량단위를 대폭 줄일 수 있다.

 

잘못된 믿음 3: 우리가 수립한 계획은 훌륭하다. 계획을 따르기만 하면 된다.

필자들은 오랜 기간 동안 컨설팅과 연구를 해왔지만 설계 과정이 진행되는 동안 처음부터 끝까지 프로젝트 요건이 변하지 않은 제품개발 프로젝트는 단 한 건도 없었다. 하지만 자사의 계획을 지나치게 맹신하는 조직이 많다. 이런 기업들은 관리와 실행에 문제가 있기 때문에 계획을 있는 그대로 따르지 못한다고 생각하며 계획 수정을 최소화하기 위해 중간 목표 및 기준과 비교해 매 단계를 꼼꼼하게 추적한다. 이미 확립된 생산 공정의 일부로 반복성이 매우 높은 활동이라면 그래도 무방하다. 하지만 제품 혁신 과정에 이 같은 방식을 적용하면 형편없는 결과가 초래될 수밖에 없다. 제품을 혁신할 때는 매일 새로운 통찰력이 생겨나고 상황이 끊임없이 변하게 마련이기 때문이다.

 

MIT 토머스 앨런 교수가 진행한 대표적인 기술적 문제해결 연구는 개발 업무가 가변적이라는 사실을 강조한다. 앨런은 항공우주 부문의 하위 시스템을 개발 중이던 엔지니어들이 가장 좋은 방안을 택하기 전 다양한 설계 방안을 떠올리고 평가한다는 사실을 발견했다. 서로 경쟁 관계에 놓여 있는 기술 방안들을 검사하고 개선하는 과정에서 엔지니어들이 선호하는 설계가 자주 바뀌었다. 혁신 프로젝트를 진행할 때는 이런 일이 흔히 벌어지곤 한다. 검사와 실험을 통해 어떤 것이 효과가 있으며 어떤 것이 효과가 없는지 드러나며 비용과 가치에 관한 최초의 가정이 틀린 것으로 밝혀질 수도 있다.

 

제품개발 프로젝트를 시작하는 단계에서 고객의 요구를 정의하기는 힘들다. 고객이 아직 존재하지 않는 해결방안과 관련해 자신이 무엇을 원하는지 정확하고 구체적으로 설명하기가 힘들다는 사실을 생각해 보면 제품개발 프로젝트를 시작할 때 고객의 요구를 정확하게 정의하지 못하는 것이 너무도 당연하다. 사실 기존의 제품 특성에 대한 익숙함이 새로운 제품에 대한 요구를 표현하는 능력에 방해가 될 수도 있다. 경쟁업체가 신제품을 출시하거나 새로운 추세가 등장한 탓에 개발 프로젝트가 진행되고 있는 가운데 고객의 선호가 갑작스레 바뀔 수도 있다.

 

이 같은 사실에도 불구하고 최초의 계획만 무조건적으로 고집하면 엄청난 문제가 발생할 수 있다. (구상이 뛰어나고 실행 능력이 아무리 우수해도 마찬가지다.) 물론 그렇다고 해서 계획을 세울 필요가 없다는 뜻은 아니다. 제품개발은 세심하게 조화를 고려하고 가장 사소한 부분에까지 세심하게 신경을 써야 하는 복잡한 활동의 집합이다. 하지만 최초의 가설을 세웠다 하더라도 증거가 드러나고, 경제적 가정이 변하고, 기회 재평가가 이뤄질 때마다 끊임없이 가설을 수정해야 하듯 제품개발 계획 역시 필요에 따라 지속적으로 수정해야 한다. (<하버드비즈니스리뷰> 2007 5월 호에 실린 리타 건더 맥그래스와 토머스 케일의 글성공적으로 가치를 포획하는 기업이 택하는 공정(The Value Captor’s Process)’ 참조.)

 

잘못된 믿음 4: 프로젝트 시작 시기가 빨라지면 그만큼 프로젝트가 끝나는 시기도 빨라진다.

앞서 이야기했듯이 관리자들은 유휴시간을 매우 싫어한다. 관리자들은 새로운 프로젝트를 시작해 어떻게든 시간을 효율적으로 활용하려는 성향을 갖고 있다. 사람들이 결국 또 다른 프로젝트로 복귀해야 하기 때문에 업무 자체를 완수할 수 없다 하더라도 관리자들은 새로운 프로젝트와 관련해 무엇이든 성취할 수 있는 것이 있다면 굳이 나중으로 미룰 이유가 없다고 생각한다. 이런 사고 방식 때문에 기업들은 활발하게 진행할 수 있는 것 이상으로 많은 프로젝트를 시작해 자원의 효과를 약화시킨다.

 

이런 현상은 위험하다. 앞으로 나아가기 위해 필요한 자원을 확보하지 못한 상황에서 프로젝트를 시작하면 개발 과정 전체를 힘겹고 더딘 속도로 진행하게 된다. 이런 상황은 문제가 될 수 있다. 제품개발 업무 자체가 매우 쉽게 소멸되는 속성을 갖고 있기 때문이다. 사실 기술과 시장에 관한 가정은 매우 빠른 속도로 사라져버린다. 프로젝트 진행 속도가 더딜수록 프로젝트가 다른 방향으로 흘러갈 가능성이 커진다. 어느 군대 조직은 프로젝트 진행 기간이 늘어나면 비용과 일정이 기하급수적으로(4제곱) 늘어난다는 사실을 발견했다. 다시 말해서 프로젝트를 진행하는 기간이 맨 처음 계획보다 2배 증가하면 비용과 작업 일정이 16배 늘어나는 것이다.

 

대표적인 대기행렬이론 공식 리틀의 법칙(Little’s Law)을 통해서도 공정 내 업무량을 줄이는 것이 얼마나 중요한지 확인할 수 있다. 리틀의 법칙은 사이클 타임이 대기시간을 처리율로 나눈 숫자와 비례한다고 설명한다. 다시 말해서, 스타벅스 매장에서 내 앞에 20명의 고객이 대기 중이고 바리스타가 1분에 5명의 고객을 상대한다면 4분 후에 커피를 받게 된다. 이때 처리율을 높이거나 진행 중인 업무의 숫자를 줄이면 사이클 타임을 단축할 수 있다. 대부분의 경우에는 업무의 숫자를 줄이는 것만이 현실적인 대안이 될 수 있다.

 

업무를 시작하는 속도를 엄격하게 통제하는 방안을 택하는 제품개발자들도 있다. 이들은 새로운 업무를 시작하는 속도와 업무를 실제로 완수하는 속도를 일치시키고, 진행 중인 프로젝트의 숫자를 꼼꼼하게 관리하며, 일단 프로젝트를 시작한 후에는 해당 프로젝트가 완수될 때까지 충분한 인력을 공급하며, 진행 중인 프로젝트에 할당된 자원을 새로운 프로젝트에 밀어 넣으려는 욕구를 참아낸다.

 
2701_05

잘못된 믿음 5: 제품의 기능을 늘릴수록 좀 더 많은 고객의 마음을 사로잡을 수 있다.

제품개발팀은 기능을 추가하면 고객이 느끼는 가치가 늘어나는 반면 기능을 줄이면 가치가 파괴된다고 믿는 듯하다. 바로 이런 태도 때문에 제품이 복잡해진다. 리모콘은 제대로 사용하기가 불가능한데다, 컴퓨터는 설치하려면 몇 시간이 걸리고, 자동차에는 마치 비행기 조종석처럼 온갖 스위치와 손잡이가 달려 있으며, 별 것 아닌 토스터에도 설명서와 LCD 디스플레이가 따라 나온다.

 

다다익선이라는 믿음에 도전하는 기업들은 소박함 속에서 우아한 자태를 뽐내는 제품을 만들어낸다. 오디오, 텔레비전, 전화기 등을 제조하는 덴마크 업체 뱅앤올룹슨(Bang & Olufsen)은 모든 고객이 음악을 감상하기에 가장 적합한 조합을 찾기 위해 이퀄라이저, 밸런스, 기타 제어장치 등을 직접 조작하고픈 욕구를 갖고 있는 것은 아니라는 사실을 잘 알고 있다. 뱅앤올룹슨의 고급 스피커는 원곡과 가능한 가까운 방식으로 노래를 재생할 수 있도록 각종 제어장치를 자동으로 조절한다. 사용자가 할 일은 볼륨을 선택하는 것뿐이다.

 

기업이 적은 것이 좋을 수도 있다는 원칙을 믿고 실행하도록 만들기는 쉽지 않다. 제품개발과 관련된 두 분야에서 추가적인 노력이 필요하기 때문이다.

 

문제를 정의하라.혁신을 하려면 개발자가 어떤 문제를 해결해야 할지 명확하게 표현할 수 있어야 한다. 하지만 전체 혁신 과정 중 이 부분이 가장 과소평가되고 있다. 사실 많은 기업이 당면한 문제를 정의하는 데 터무니없이 적은 시간을 할애한다. 하지만 문제를 명확하게 표현하는 단계는 중요하다. 문제를 정의하는 과정에서 제품개발팀이 제품개발의 목표를 명확하게 이해하고 실험을 통해 검증하고 개선해야 할 가설을 수립하기 때문이다. 문제를 얼마나 명확하게 기술하느냐에 따라 제품개발팀이 정말 중요한 소수의 기능에 집중하게 될 수도 있고, 그렇지 못할 수도 있다.

 

디즈니랜드 설립 계획을 세울 당시 월트 디즈니는 다른 놀이동산보다 더 많은 기능(놀이기구, 음식 종류, 주차장 규모)을 추가하기 위해 애쓰지 않았다. 대신 디즈니는디즈니랜드가 방문객들에게 마법 같은 고객 경험을 선사하려면 어떻게 해야 할까라는 훨씬 포괄적인 질문을 던지기 시작했다. 물론 하룻밤 만에 대답을 찾을 수는 없었다. 대답을 찾기 위해서 많은 공이 들어가는 상세한 연구, 끊임없는 실험, 디즈니와 고객들에게마법 같다는 것이 의미하는 바에 대한 심도 깊은 통찰력이 필요했다.아이데오(IDEO)를 비롯한 일부 기업들은 제품이나 서비스가 실제로 사용되는 상황에 완전히 몰입하는 단계를 제품개발 과정에 포함시킨다. 개발자들은 시장에 관한 흥미로운 내용을 하나도 빠짐없이 모두 파악하고, 미래의 사용자를 관찰/인터뷰하고, 신제품과 경쟁할 제품을 연구하고, 자신들이 익힌 모든 내용을 종합해 그림과 모형, 도표를 제작한다. 고객에 대한 심도 깊은 통찰력을 얻은 후에는 반복적인 개발 과정을 통해 관련 내용을 검증하거나, 개선하거나, 포기한다.

 

무엇을 숨기고 생략할지 결정하라.기술 개발팀이 동료와 경영진을 놀라게 할 만큼 훌륭한 기술 방안을 제안해 능력을 과시하고픈 욕구를 느끼는 경우가 많다. 하지만 소비자들은 별다른 노력 없이도 쉽게 작동되는 제품을 선호하는 경향이 있다. 고객의 관점에서 보면 가장 단순한 방식으로 문제를 해결하며 개발자들이 자랑스러워하는 부분이 드러나지 않도록 가려주는 방안이 최고의 해결방안이다.

 

이 같은 점을 잘 이해한 기업이 바로 애플(Apple)이다. 애플은 혁신적인 제품, 맵시 있는 제품 디자인, 뛰어난 마케팅 등으로 유명한 기업이다. 하지만 애플의 최대 강점은 문제의 핵심을 찌르는 능력이다. (<하버드비즈니스리뷰> 4월 호에 실린 월터 아이작슨(Walter Isaacson)의 글 ‘The Real Leadership Lessons of Steve Jobs’(DBR 118스티브 잡스, 창조 신화의 비밀’)을 참고하기 바란다.) 스티브 잡스(Steve Jobs)는 생전에 다음과 같은 이야기를 했다. “어떤 문제에 대해 곰곰이 생각을 하기 시작했는데 그 문제가 매우 단순해 보인다면 그 문제가 안고 있는 복잡성을 제대로 이해하지 못하는 것이다. 뿐만 아니라 해결방안이랍시고 내놓은 것 역시 터무니없이 단순하다. 심층적으로 파고들면 그 문제가 매우 복잡하다는 사실을 깨닫게 된다. 이 같은 사실을 깨달은 사람들은 아주 복잡한 해결방안을 제시한다. 대부분의 사람들은 여기서 멈춘다.” 하지만 애플은 그렇지 않다. 애플은 멈추지 않고 꾸준히 나아간다. “정말 위대한 사람은 계속 앞으로 나아가 문제의 근본 원리를 찾아내고 문제 해결에 도움이 되는 아름답고 품격 있는 해결방안을 생각해낸다.”

 

제품에서 무엇을 생략할지 결정하는 것이 무엇을 포함시킬지 결정하는 것만큼 중요하다. (어쩌면 전자가 더욱 중요할 수도 있다.) 혁신적인 기업이 되겠다는 일념으로 고객이 느끼는 가치, 사용의 편의성 등 중요한 요소를 충분히 고려하지 않은 채 온갖 부수적인 장치를 덧붙이는 기업이 많다. 이런 기업이 계획에 포함돼 있던 일부 기능을 제거할 때는 비용을 줄여야 할 필요성이 생겼거나 제품개발팀의 업무에 차질이 생겨 업무를 예정된 시간 내에 해낼 수 없게 된 탓에 기능 제거라는 방안을 택했을 가능성이 크다. 그 대신 관리자들은 예정된 기능을 제거하면 특정 제품이 개선되고 제품개발팀이 전반적인 고객 경험 개선에 도움이 되는 부분에 집중할 수 있을지 고민해야 한다. 필요요건으로 여겨지는 모든 요소를 기정사실이 아닌 가설로 대하고 잠재 고객을 대상으로 신속하게 소규모 실험을 진행하는 방법이 도움이 될 수 있다.

 

제품개발팀이 더 이상 새로운 기능을 추가할 수 없는 지경이 돼서야 제품이 완성됐다고 가정하는 경우가 많다. 하지만 이런 생각을 완전히 뒤집어 더 이상 어떤 기능도 제거할 수 없을 만큼 불필요한 기능을 모두 제거해야 완벽에 한걸음 가까워지는 것이라고 생각해야 한다. 레오나르도 다빈치가 이야기했듯단순함이야말로 궁극적인 차원의 정교함(Simplicity is the ultimate sophistication)’이다.

 

 

많은 사람들이 옳다고 믿는 잘못된 믿음을 떨쳐내기 위한 실전 지침

 

제품개발 관리자를 위한 체크 리스트

 

1. 대기행렬 및 정보 흐름을 눈에 띄게 만들어라.

 

2. 지연 비용을 수량화하고 의사 결정에 반영하라.

 

3. 자원 활용도가 가장 높은 부분의 자원 활용도를 낮추어라.

 

4. 효율성에 집중돼 있던 통제 시스템의 초점을 반응 시간으로 옮겨라.

 

5. 제조수량단위를 줄이고 신속하게 피드백을 확보해 거래비용을 낮춰라.

 

6. 제조수량단위를 줄여서 실험을 진행하라. 제조수량단위를 줄였으나 효과를 볼 수 없다면 다시 제조수량단위를 늘리면 된다.

 

7. 제품개발 계획이 새로운 정보가 생길 때마다 조금씩 발전하는 가설이라고 생각하라.

 

8. 온전히 노력을 쏟아부을 준비가 된 경우에만 프로젝트를 시작하라.

 

9. 단순함을 추구하라. 어떤 기능을 추가할지에 대해서만 고민하지 말고 어떤 기능을 삭제할지 고민하라.

 

10. 적절히 통제한 실제 고객 환경 내에서 컴퓨터 모형과 물리적 원형을 이용해 초기에 신속하고 빈번하게 실험을 해야 한다.

 

11. 중복되고 반복적인(선형적이지 않은) 공정 설계를 강조하라.

 

12. 단 한번의 시도로 성공하는 것보다 신속한 피드백에 초점을 둬라.

 

 

잘못된 믿음 6: 한번에 제대로 해내면 좀 더 커다란 성공을 거둘 수 있다.

예산과 스케줄, 기술 성과 목표를 달성하지 못하는 제품개발 프로젝트가 많다. 부실한 계획, 융통성 없는 공정, 약한 리더십이 모두 실패의 원인이 되는 것은 틀림없는 사실이다. 하지만 실패를 야기하는 중요한 원인 중 하나임에도 불구하고 흔히 간과되곤 하는 것이 있다. ‘단 한번에 모든 일을 완벽하게 해내야 한다는 제품개발팀을 향한 관리자의 요구가 바로 그것이다. 단 한번만에 성공하라는 요구에 직면한 제품개발팀은 가장 위험성이 낮은 방안을 택하는 경향이 있다. 고객이 이미 시중에 나와 있는 제품과 비교했을 때 신제품이 그다지 개선되지 않았다는 느낌을 받는 경우에도 마찬가지다. 설상가상으로 제품개발팀에는 고객의 문제를 해결하는 데 도움이 될 만한 혁신적인 해결방안을 내놓을 이유가 없다. 제품개발팀은 실수를 저지르지 않기 위해 검토게이트(gate)’에서 각 단계(구체화, 설계, 구축, 검사, 규모 확대, 출시)를 꼼꼼하게 감시하는 선형 공정(linear process)을 따른다. 프로젝트가 게이트를 통과해야만 다음 단계에 속하는 업무를 시작할 수 있다. 프로젝트가 운영되는 동안 제품개발팀 직원들은 엄청난 노력을 기울이며 새로운 통찰력에 대응하는 비용 역시 대폭 증가한다. 프로젝트 후반부에서 성공적인 검사 결과가 나오면 모두가 축하하며 기념한다. 제아무리 가치 있는 것이라 한들 예기치 못한 일이 벌어지면 차질이 생긴 것으로 간주된다. 하지만 안타깝게도 이런 식으로 선형 공정 방식을 채택하면 프로젝트 초과 현상이 벌어진다. 선형 공정 방식하에서는 검사 피드백이 지연되고 제품개발팀이 필요 이상으로 오랜 기간 나쁜 아이디어에 매달리며 문제 해결 비용이 치솟기 전에 미리 문제를 파악할 수 없기 때문이다.

 

사람들이 신속하고 빈번하게 업무를 반복하고 실패를 통해 재빠르게 교훈을 얻을 수 있다면첫 번째에 실수를 저지르는 것을 용인하는 쪽이 더 나은 전략이 될 수 있다. 시뮬레이션 기술 및 빠른 속도로 원형을 개발하는 기술이 발전한 덕에 이런 식의 운영 방식을 채택하기가 한층 수월해졌으며 비용 또한 저렴해졌다.

 

맞춤형 집적회로를 설계하는 391개의 개발팀을 상대로 진행한 연구에서 필자들이 발견한 내용을 보자. 반복적인 접근방법을 따르고 빈번하게 초기 검사를 실행한 팀은 개발 과정에서 좀 더 자주 실수를 저질렀다. 하지만 저비용 원형 개발 기술을 사용했기 때문에 한번에 올바른 설계를 만들어내기 위해 노력한 개발팀보다 뛰어난 성과(소요된 시간 및 노력 기준)를 냈다. 좀 더 높은 원형 개발 비용을 지불한 팀은 구체적인 내용 열거, 개발, 검증에 더 많은 노력을 쏟아부었다. 이런 부류의 개발팀은 프로젝트 후반부에 들어선 후에야 반복 과정을 진행했고(횟수도 훨씬 적었다) 결국 중요한 문제가 발견되는 시점이 늦춰졌다.

 

혁신 프로젝트를 진행할 때는 다수의 다양한 아이디어를 활용해 실험을 진행하는 것이 매우 중요하다. 신속하고 빈번하게 실험을 진행하면 수많은 참신한 구상이 실패로 끝날 수밖에 없다. 하지만 프로젝트 진행 초기에 실패를 경험하는 것이 바람직할 수도 있다. 도움이 되지 않는 요소를 신속하게 제거하고 좀 더 유망한 대안에 집중할 수 있기 때문이다. 자동차 설계가 안전하지 않다는 사실을 보여주는 충돌 검사, 유해한 것으로 밝혀진 신약 후보, 소비자들을 혼란스럽게 만드는 소프트웨어 사용자 인터페이스 등이 모두 바람직한 결과가 될 수 있다. 투입된 자원이 많지 않고 여전히 설계를 변경할 수 있으며 다른 해결방안을 시도해 볼 수 있을 정도로 초기에 벌어진 일이라면 위와 같은 실패들도 얼마든지 바람직한 결과가 될 수 있다.

 

뉴질랜드 요트팀 팀 뉴질랜드가 1995년에 아메리카스컵 요트 대회에서 사람들의 예상을 깨고 우승한 사례를 통해서일찍, 자주 실패하는접근방법에 어떤 장점이 있는지 확인할 수 있다. 팀 뉴질랜드는 용골 설계 개선 방안을 검토하기 위해 거의 비슷한 모양의 요트 2(프로젝트를 통해 수정된 요트와 전혀 수정되지 않은대조요트)를 사용했다. 팀 뉴질랜드는 매일 그래픽 워크스테이션상에서 가설을 시뮬레이션하고 실험용 요트에 도움이 될 것 같은 요소를 추가한 다음 대조용 요트와 함께 경주를 진행하고 결과를 분석했다. 팀 뉴질랜드의 경쟁팀인 팀 데니스 코너(Team Dennis Conner)가 택한 방법은 정반대였다. 좀 더 뛰어난 컴퓨터(보잉(Boeing)의 슈퍼컴퓨터)를 사용할 수 있었던 팀 데니스 코너는 몇 주에 한 번씩 여러 건의 시뮬레이션을 진행한 다음 사용 가능한 것으로 드러난 방안을 실험용 요트에 접목했다. 그 결과 팀 뉴질랜드는 팀 데니스 코너보다 훨씬 많은 숫자의 학습 주기를 통과하고 장래성 없는 아이디어를 좀 더 신속하게 제거했으며 팀 데니스 코너의 요트 영 아메리카(Young America)를 밀어내고 우승을 차지했다.

 

필자들은 실패로 귀결되는 실험이 반드시 실패한 실험은 아니라는 사실이 명백하게 받아들여지기를 바란다. 실패로 끝난 실험을 통해서 그 어떤 혁신가도 예견하지 못한 새로운 정보가 생겨난다. 실험 주기가 빨라질수록 좀 더 많은 피드백을 수집해 참신하지만 위험성을 안고 있는 새로운 실험에 그 피드백을 반영하게 될 가능성이 커진다. 이런 환경에서 근무하는 직원들은 상황이 좋지 않을 때 인내심을 갖고 좀 더 힘든 일에 도전하며 위험을 회피하려는 성향을 갖고 있는 동료들보다 더 나은 결과를 내는 경향이 있다.

 

하지만 이런 환경을 조성하기는 쉽지 않다. (<하버드비즈니스리뷰> 2011 4월 호에 실린 에이미 C. 에드먼슨(Amy C. Edmondson)의 글 ‘Strategies for Learning from Failure’, (DBR 95실패사용설명서 : 줄기찬 실험이 성공 낳는다’)에서 자세한 내용을 확인할 수 있다.) 실패로 인해 당혹감을 느끼고 지식 격차가 드러날 수도 있다. 뿐만 아니라 이로 인해 당사자의 자존심과 조직 내 지위가 약화될 수 있다. 프로젝트 진행 초기에 문제를 발견해 프로젝트 전체를 중단하는 결과를 초래한 팀이 보상을 받고 관리자가 승진을 하는 경우가 얼마나 되는가? 귀중한 자원을 초기에 재배치한 덕에 기업 측에 이익이 됐다 하더라도 실패를 초래한 개발팀이 보상을 받거나 관리자가 승진을 하는 경우는 드물다. ‘실패에 대한 무관용(zero tolerance for failure)’이나 식스시그마(Six Sigma)와 같은무오류(error-free)’ 환경을 구축한 조직에서는 특히 그렇다.

 

토머스 앨버 에디슨(Thomas Alva Edison)은 이 같은 사실을 잘 알고 있었다. 에디슨은 기계 전문가들이 연구진과 긴밀하게 협력할 수 있도록 했다. 모형 제작을 담당하는 기계 공장을 실험을 진행하는 공간과 가까이 배치하는 등 신속한 실험이라는 개념에 중점을 두고 실험실을 조직했다. 실험실 내 도서관에는 직원들이 신속하게 필요한 정보를 찾을 수 있도록 방대한 양의 서적이 비치돼 있었으며, 근처 저장실에는 충분한 양의 자재가 비축돼 있었고, 기능공, 과학자, 엔지니어 등 다양한 인재가 에디슨의 실험실에서 일했다. 에디슨은 자기 자신이나 다른 직원들이 아이디어를 떠올리는 즉시 시험 모형이나 원형을 만들 수 있는 환경을 조성하고자 했다. 에디슨은진정한 성공의 척도는 24시간 내에 진행할 수 있는 실험의 숫자라고 이야기했다.

 

CAD, 컴퓨터 모델링, 시뮬레이션 등 IT가 눈부시게 발전한 덕에 좀 더 짧은 시간 내에, 좀 더 적은 비용으로 더 나은 제품을 만드는 기업의 역량이 비약적으로 발전했다. 경영진의 사고가 기술만큼 빠른 속도로 발전하지 않은 탓에 이런 도구를 충분히 활용하지 못하는 기업이 많다. 변동성이 매우 높은 정보 생성 업무라는 점을 고려하지 않은 채 무작정 제품개발에 제품생산과 같은 접근방법을 접목하는 경영진이 여전히 많은 것이다. IT가 발전하면 제품개발 공정을 개선할 수 있는 여지도 한층 커진다. 하지만 그와 동시에 제품개발이 제품생산과 전혀 다르다는 사실을 깨닫지 못하는 기업이 감당해야 할 위험도 커질 것이다.

 

번역 |김현정 translator.khj@gmail.com

 

스테판 톰키·도널드 라이너트슨

스테판 톰키(Stefan Thomke)는 하버드경영대학원(Harvard Business School) 윌리엄 바클레이 하딩 경영학 교수(William Barclay Harding Professor of Business Administration). 도널드 라이너트슨(Donald Reinertsen)은 캘리포니아 레돈도 비치에 위치한 컨설팅 회사 라이너트슨 앤 어소시에이츠(Reinertsen & Associates) 사장이다. 라이너트슨이 가장 최근에 발표한 저서는 <제품개발 흐름의 원칙(The Principles of Product Development Flow, 셀레리타스 퍼블리싱, 2009)>이다.

 

아티클을 끝까지 보시려면
유료 멤버십에 가입하세요.
첫 달은 무료입니다!

관련 매거진

아티클이 실린 매거진

하버드비즈니스리뷰코리아 2013.HBR in DBR (~2013) 2008~2013 0원
(03187) 서울시 종로구 청계천로 1 동아일보사빌딩 (주)동아일보사
대표자: 김재호 | 등록번호: 종로라00434 | 등록일자: 2014.01.16 | 사업자 등록번호: 102-81-03525
(03737) 서울시 서대문구 충정로 29 동아일보사빌딩 15층 (주)동아미디어엔(온라인비즈니스)
대표이사: 김승환 | 통신판매신고번호: 제 서대문 1,096호 | 사업자 등록번호: 110-81-47558