인스파이어드

인스파이어드



마티 케이건 지음

제이펍 / 2018년 12월 / 382쪽 / 24,000원





PART Ⅰ 최고의 기술 기업에서 배운 것



실패한 제품의 근본 원인



수많은 제품이 실패하는 근본적인 원인이 무엇일까. 나는 그동안 많은 회사들이 같은 방식으로 일하고 있음을 관찰하였다. 그리고 이러한 방식은 실제로 최고의 회사가 일하는 방식과는 거리가 멀다.

모든 것은 아이디어에서 출발한다. 대부분의 아이디어는 내부(임원, 핵심 이해 관계자 또는 비즈니스 담당자) 혹은 외부(현재 또는 잠재 고객들)로부터 유입된다. 아이디어가 어디에서 발생했건 간에, 항상 비즈니스의 각 분야에서 제품 관리자가 처리해 주기를 바라는 엄청난 양의 과제들이다. 이제 대부분 회사는 이러한 아이디어들의 우선순위를 매겨 로드맵으로 전환하기를 원하는데 그들은 두 가지 이유로 로드맵을 사용한다. 첫째는 가장 중요한 일을 먼저 수행해 주기를 원하기 때문이며, 둘째는 각 업무가 언제 준비 상태가 될지 예측하고 싶기 때문이다. 로드맵을 작성하기 위해 보통 분기 또는 연간 계획 세션과 같은 일정표를 마련한다. 이때 리더들은 아이디어를 검토하면서 제품 로드맵에 대해 협의한다.

그리고 그들은 우선순위를 정하기 위해 먼저 각 아이디어에 대한 비즈니스 케이스 정의가 필요하다고 생각한다. 비즈니스 케이스 정의는 각 아이디어에 대해 두 가지를 분명히 알아야 한다는 것이 핵심이다. (1) 얼마만큼의 매출이나 가치를 만들어 낼 것인가? (2) 얼마만큼의 비용이나 시간이 필요한 것인가? 이러한 정보는 다음 분기의 로드맵(때로는 1년의 로드맵)을 작성하는 데 활용된다. 이때 제품과 기술 조직은 진격 명령이 떨어지면 보통 가장 높은 우선순위의 아이디어부터 차례대로 실행하게 된다. 어떤 아이디어가 가장 높은 우선순위에 있으면 제품 관리자가 가장 먼저 해야 할 일은 해당 이해 관계자를 만나서 아이디어를 구체화하는 것이다. 이를 통해 일련의 요구사항을 정리한다.

이러한 요구사항은 사용자 스토리(user story) 형태이거나, 아마도 기능 명세와 같은 양식의 형태일 것이다. 요구사항은 디자이너와 엔지니어에게 무엇이 만들어져야 하는지를 커뮤니케이션하기 위함이다. 요구사항이 모두 수집되고 나면 사용자 경험 디자인팀은 상호작용 디자인(interaction design), 시각 디자인(visual design), 물리적인 기기의 경우 산업 디자인(industrial design)에 대한 진행을 요청한다. 그리고 그 요구사항과 디자인 결과물은 엔지니어에게 전달된다. 대개 이 시점에서 애자일(agile; 소프트웨어를 일단 빠르게 출시한 다음에 사용자들의 의견과 통계를 바탕으로 업데이트를 배포하는 과정을 반복하는 순환식 개발 방식)이 등장한다. 애자일 모델은 적은 돈과 시간에 맞추기 위해 요구 사항을 끊임없이 수정하는 방식이다. 엔지니어들은 보통 그 과제를 이터레이션(interation, 반복 업무 단위)으로 나눈다. 마지막으로 QA 팀이 그 신규 아이디어 과제가 예상대로 동작하는지, 다른 문제는 없는지를 검증한다. QA 팀으로부터 이상이 없음을 확인하는 녹색 신호를 받으면, 그 신규 아이디어는 마침내 실제 고객에게 배포(deploy)된다.

대다수의 크고 작은 기업들은 위에서 설명한 프로세스를 필수적으로 이미 오랫동안 사용하고 있다. 그리고 이런 기업들은 일관된 불평불만을 제기한다. 혁신이 부족하고, 제품을 고객에게 전달하기까지 너무 오랜 시간이 걸린다는 것이다. 엔지니어들은 대부분 주어진 폭포수(waterfall; 위에서 설명한 프로세스응 통칭한다) 프로세스의 환경에서 할 수 있는 최대한의 애자일을 실천하고 있다. 그런데 왜 이것이 수많은 실패의 필연적인 이유인가? 그 이유를 찾기 위해 단편적인 내용의 조각들을 연결해 보자. 다음은 이러한 업무 방식이 가지는 가장 큰 문제 10가지이다.

① 아이디어의 출처. 이 모델을 사용하면 판매 확대를 위한 기능이나 이해관계자 위주로 제품이 끌려가게 된다. 가장 큰 문제는 이 방식이 뛰어난 제품 아이디어를 가져오지는 못한다는 것이다. 또한 이러한 접근 방법은 팀에게 필요한 권한 위임이 안 된다. 이 모델을 따르면 제품팀은 마치 외부 용병처럼 그저 열심히 실행할 뿐이다.

② 비즈니스 케이스의 치명적인 결함. 물론 큰 규모의 투자가 필요한 아이디어일 경우 비즈니스 케이스가 필요할 수 있다. 하지만 많은 회사가 로드맵 단계에서 비즈니스 케이스를 작성하는 것은 말도 안 된다. 앞에서 말한 대로 모든 비즈니스 케이스의 핵심적인 두 가지 요소는 ‘얼마만큼의 돈을 벌 수 있는가’와 ‘얼마만큼의 비용이 드는가’다. 그런데 냉정히 말해 현재 시점에서 이 두 가지 수치를 알 방법이 없다. 얼마만큼의 돈을 벌 수 있을지는 결국 얼마나 좋은 솔루션을 만들어 낼지에 달려 있기 때문이다. 만일 팀이 환상적으로 일을 해냈다면 큰 성공을 만들어 낼 수도 있다. 하지만 현실은 많은 제품 아이디어가 결국 아무것도 이루어 내지 못한다는 것이다. 마찬가지로 제품을 만드는 데 얼마만큼의 비용이 들어갈지도 알 수 없다. 실제 어떤 솔루션을 만들지도 모르는 상태에서 엔지니어가 비용을 예측하는 것은 불가능에 가까운 일이다.

③ 회사가 제품 로드맵에 대해 빠져들기 시작하면 더 큰 이슈가 발생하기 시작한다. 대부분의 로드맵은 우선순위가 정해진 기능과 프로젝트들의 목록으로 구성되어 있었다. 예를 들어 마케팅은 특정 캠페인을 위해 이런 기능을 원하고, 영업은 새로운 고객 확보를 위해 저 기능을 원할 수 있다. 하지만 여기에 가장 큰 문제가 있다. 소위 제품에 관한 두 가지 불편한 진실이다. 첫 번째 진실은 당신의 아이디어 중 최소 절반 이상은 유효하지 않을 것이라는 사실이다.

아이디어가 기대한 효과를 얻지 못하는 데는 여러 이유가 있다. 가장 흔한 이유는 이 아이디어에 대해 우리만큼 고객이 관심을 갖지 않는다는 것이다. 그래서 고객은 그 제품을 사용하지 않기로 선택한다. 그리고 가끔은 사람들이 좋아하는 제품이지만 당초 예상했던 것보다 더 큰 비용이 드는 상황도 발생한다. 그래서 나는 제품 로드맵에 있는 최소 절반 이상의 아이디어는 기대했던 효과를 만들어 내지 못한다고 장담한다. 두 번째 불편한 진실은 아이디어가 충분히 잠재적인 가치가 있는 것으로 파악되었더라도 필요한 비즈니스 가치를 만들어 내는 수준에 도달하려면 최소 몇 번의 이터레이션을 반복해야 한다는 것이다. 우리는 이것을 돈을 버는 데 필요한 시간(time to money)이라고 한다. 내가 제품을 만들면서 깨달은 가장 중요한 교훈은 이 두 가지 불편한 진실에서 벗어나는 경우는 없다는 것이다. 다행히 나는 정말 뛰어난 팀들과 일을 해왔고, 이들의 다른 점은 이러한 불편한 진실에 대처하는 방법에 있다는 사실을 알 수 있었다.

④ 이 모델에서 제품 관리의 주요 업무는 엔지니어를 위해 요구사항을 수집하고 문서화해 주는 것이 다. 하지만 이는 내가 실제 기술 제품 관리라고 하는 일과는 180도 다르다는 것을 지적하고 싶다.

⑤ 디자인의 역할도 상황이 비슷하다. 디자인의 진정한 가치를 담기에는 너무 늦은 상황이라서 대부분은 이른바 ‘돼지 입술에 립스틱 바르기’를 하게 된다. 이미 상황은 더 나빠졌으므로 엉망인 제품에 페인트 코팅이라도 씌우려고 시도한다. 사용자 경험(UX, User Experience) 디자이너도 이것이 바람직하지 않다는 것을 잘 알고 있지만, 이렇게라도 그들의 방식대로 보기 좋고 일관된 디자인을 해나간다.

⑥ 아마 이 모델에서 놓치는 가장 큰 기회는 엔지니어들이 너무 늦게 참여한다는 것이다. 엔지니어들이 단지 코드를 짜는 일만 한다면 그들이 가진 가치의 절반밖에 활용하지 못하는 것이다. 제품 개발에서 작은 비밀이 있다면 엔지니어가 보통 혁신을 하는 데 가장 훌륭한 원천이라는 것이다. 그러나 이 모델에서 그들은 회의에 초대조차 받지 못한다.

⑦ 엔지니어팀을 너무 늦게 참여시키는 것뿐 아니라 애자일의 원칙과 핵심적인 장점이 너무 늦게 작동된다. 이러한 방식으로 업무를 하면 팀은 애자일 방법론의 실질적인 가치와 잠재성을 단지 20%만 활용하게 된다. 이는 제품 구현과 전달에만 애자일이 적용되는 것이며, 다른 모든 조직과 업무 상황에는 해당하지 않는다.

⑧ 이 모든 프로세스는 다분히 프로젝트 중심적이다. 회사는 프로젝트에 투자하고, 프로젝트에 인력을 지원하며, 조직에 프로젝트 단위로 압박하며, 결국 프로젝트를 출시하게 된다. 불행하게도 프로젝트는 결과물에 대한 것이고, 제품은 비즈니스 성과에 대한 것이다. 이 프로세스는 프로젝트들을 고아와 같은 신세로 만든다. 결과적으로 무언가 출시되었지만, 처음에 생각한 목표에 부합하지 못했다고 하자. 그렇다면 애초에 무엇이 중요했던 것일까? 어떤 경우에도 이것은 매우 치명적인 문제이며, 우리에게 필요한 제품 개발 방식과는 거리가 멀다.

⑨ 전통적인 폭포수 방식이 여전히 가지고 있는 가장 큰 문제는 위험이 가장 마지막에 발견된다는 것이다. 고객에 대한 검증이 너무 늦게 일어난다는 의미다. 린 방식(Lean method)의 핵심적인 원칙은 낭비를 줄이는 것이다. 가장 큰 낭비의 형태는 결국 원하지도 않는 기능이나 제품을 발견하기 위해 디자인-구현-테스트-배포해 나가는 것이다. 아이러니한 사실은 많은 팀이 내가 설명한 폭포수 프로세스를 적용하고 있으면서도 스스로 린의 원칙을 적용하고 있다고 착각한다는 것이다. 그러면 나는 그들이 가장 값비싸고 느린 방법으로 아이디어를 실행하고 있다고 지적한다.

⑩ 끝으로, 우리가 이 프로세스로 시간과 비용을 낭비하느라 정신없을 때 발생하는 가장 큰 손실은 따로 있다. 바로 그 시간에 조직이 할 수 있었던 혹은 해야만 했던 것에 대한 기회비용이다. 많은 기업이 엄청난 시간과 비용을 들이고도 매우 허망한 성과를 거두는 현상은 그리 놀라운 일도 아니다. 우리는 시간과 돈을 다시 돌릴 수 없다. 최고의 팀들은 절대 앞서 설명한 방식처럼 일하지 않는다.



PART Ⅱ 사람



강한 제품팀의 원칙



제품팀은 각기 다른 전문적인 능력과 책임을 진 사람들의 집단이며, 단일 제품 또는 큰 제품의 주요 영역에 대해 실질적인 주인 의식을 느낀다. 뛰어난 제품 회사에서 발견되는 다음과 같은 몇 가지 중요한 유사점들이 있다.

▲ 미션팀: 제품팀은 많은 장점이 있다. 그중에서도 실리콘밸리의 유명한 벤처 캐피털리스 존 도어의 말이 제품팀의 목표를 가장 잘 표현한다. “우리가 원하는 것은 용병팀(team of mercenary)이 아닌 미션팀(team of missionary)이다.” 용병팀은 지시한 것만을 만든다. 반면 미션팀은 진심으로 비전을 믿고 그들의 고객 문제 해결을 위해 최선을 다한다. 제품 전담팀은 마치 사내 스타트업처럼 행동하고 느낀다. 그것이 제품팀에 바라는 모습이다.

▲ 팀의 구성: 일반적인 제품팀은 한 명의 제품 관리자, 한 명의 디자이너 그리고 두 명부터 최대 10~12명의 엔지니어로 구성된다. 제품이 사용자 접점의 경험을 다루는 것이 아니라면 제품 디자이너는 필요 없을 수도 있지만 그 외 많은 제품팀은 제품 디자이너가 꼭 필요하다. 상황에 따라 제품 마케팅 매니저, 테스트 자동화 엔지니어, 사용자 경험 연구원, 데이터 분석가들도 포함될 수 있다.

▲ 팀의 권한과 책임: 제품팀의 콘셉트에서 이야기하는 중요한 사실은 그들이 비즈니스의 매우 어려운 문제를 해결한다는 것이다. 그들은 분명한 목표를 가지고 그 목표에 맞추어 실행한다. 목표 달성을 위한 최상의 방법을 찾아내는 권한이 있으며, 동시에 그 결과에 대한 책임도 진다.

▲ 팀의 크기: 제품팀을 구성하는 최소 조건은 보통 한 명의 제품 관리자, 한 명의 디자이너, 두 명의 엔지니어다. 실질적으로 팀의 규모는 대개 8~12명의 엔지니어까지 가능하다. 아마도 당신은 ‘피자 두 판의 법칙’을 들어 본 적이 있을 것이다. 팀의 규모를 두 판의 피자를 먹을 만한 사람 수 이내로 유지하라는 의미다. 팀의 절대적인 규모보다 더 중요한 것은 팀이 올바른 제품을 올바르게 만드는 데 필요한 고른 역량을 갖추고 있느냐는 것이다.

▲ 팀의 보고 체계: 제품팀은 보고하고 보고 받는 관계가 아니다. 의도적으로 수평 구조를 지향한다. 많은 경우 제품팀의 각 구성원은 독립적이며, 관리자가 별도로 존재하지 않는다. 팀의 구성원들은 보통 그들의 직무 관리자와 지속적으로 상황을 공유한다. 분명히 말하지만 제품 관리자는 제품팀 구성원의 상사가 아니다.

▲ 팀 협업: 제품팀은 어려운 비즈니스 문제를 해결하기 위해 장기간 함께 일하는 숙련된 기술을 가진 구성원들의 조합이다. 이들 관계의 본질은 진정한 협업이다. 여기서 ‘협업(collaboration)’이란 단순히 함께 일한다는 것만을 의미하지는 않고, 제품 관리, 디자인, 기술 구현이 함께 솔루션을 만드는 데 집중한다는 뜻이다.

▲ 팀의 위치: 제품팀은 가능하면 같은 장소에서 함께하기 위해 최선을 다해야 한다. 같은 장소에 있다는 것은 팀 구성원들이 바로 옆에 붙어 앉아서 일한다는 것이다. 서로의 컴퓨터 화면을 쉽게 볼 수 있을 정도로 가까운 거리여야 한다. 최고의 기업들은 팀으로서 같이 앉아서 일하는 것의 가치를 절실히 느끼고 있다. 같이 앉아 일하고, 함께 점심을 먹고, 서로 개인적인 신뢰를 쌓아가는 과정에서 발생하는 특별한 역동성이 있다. 다른 모든 조건이 같다면 같은 장소에서 근무하는 팀이 흩어져 있는 팀 보다 훨씬 더 높은 성과를 낸다. 마찬가지 이유로 계약직이나 외주 업체보다는 정규 직원으로 제품팀을 구성하는 것이 훨씬 효과적이다.

▲ 팀의 자율성: 충분한 권한을 가졌다고 느끼면서 고객 문제를 해결하기 위한 열정으로 뭉친 팀을 원한다면 그들에게 높은 수준의 자율성을 제공해야 한다. 그래야만 팀이 주어진 문제를 해결하는 데 가장 적절하다고 발견한 최고의 방법을 시도해 볼 수 있다. 또한, 자율성은 팀 간의 의존성을 최소화할 수 있다. 확장하는 상황에서는 모든 의존성을 지속적으로 최소화하기 위해 노력해야 한다.

▲ 제품팀이 왜 효과적인가: 제품팀 모델이 왜 그토록 효과적인지에 대한 몇 가지 이유가 있다. 첫째, 협업에서는 관계가 중요한 역할을 하는데, 제품팀은 특히 같은 장소에서 일하는 경우 이러한 관계를 잘 살리는 형태다. 둘째, 전문성이 필요한 혁신을 하는 경우 오래 지속되는 제품팀은 구성원들이 전문성을 충분히 확보할 수 있을 만큼 깊이 업무를 수행한다. 셋째, 제품팀은 다른 사람들이 가치 있을 것으로 예상해서 결정한 것을 만드는 것이 아니다. 팀 전체가 비즈니스 목표와 상황을 잘 이해하고 있으며, 가장 중요한 점은 팀 전체가 주인 의식과 성과에 대해 책임감을 느낀다는 것이다. 프로젝트 중심의 전통적인 모델은 프로세스에 따라 할당된 업무를 수행하고 나면 끝이다. 반면에 전담팀 모델은 출시가 되었다고 문제가 다 해결된 것이 아니다. 사용자와 비즈니스 입장에서 원하는 결과가 나올 때까지 끈을 놓지 않는다. 당신의 회사가 아직 제품 전담팀을 구성하지 않았다면 당신이 해야 할 가장 중요한 일은 제품 전담팀으로 전환하는 일이며, 이는 다른 모든 것에 영향을 준다.

리더십의 역할



모든 기술 조직에서 리더십의 가장 중요한 업무는 훌륭한 인재를 영입하고 성장시키고 유지하는 것이다. 하지만 제품 회사에서 리더십의 역할은 인재 육성을 넘어 이른바 제품의 총체적인 시각을 요구한다. 스타트업에서는 한두 개의 제품팀으로 구성이 되어 있어서 제품 전체의 시야를 모두가 유지하는 것이 그리 어려운 일이 아니지만 회사가 다수의 제품을 다루는 조직으로 성장하게 되면 곧 어려움을 느끼게 된다. 전체 제품이 어떻게 엮여 있는지 이해하는 것은 성장하면서 겪는 큰 도전이다. 제품 전체의 관점을 갖는 것에 있어서 세 가지 중요한 요소들을 살펴보자.

▲ 제품 관리 리더: 전체 제품의 체계(제품 비전, 전략, 기능 정책, 로직 등)가 비즈니스 관점에서 어떻게 맞물려 돌아가는지에 대한 총체적인 시각을 가지려면 제품 관리 조직의 임원 또는 제품 관리자 리더가 있어야 한다. 이 사람들은 정기적으로 다양한 제품 관리자의 업무를 검토하고, 갈등 사항을 발견하고, 해결을 돕는다. 제품 관리자 전담 리더는 제품 자체에 집중하고, 모든 제품 관리자, 제품 디자이너, 엔지니어, 테스트 자동화 엔지니어들이 언제든 문제 해결에 필요한 도움을 얻을 수 있도록 준비되어 있어야 한다. 만일 제품 관리자 리더에게 이 역할을 맡긴다면 제품 총괄에 직접 보고하는 관계가 되어야 한다. 그래야 모두가 이 역할의 중요성과 책임을 이해할 수 있다.