애자일-디자인씽킹-린 스타트업, 이거 정말 좋은건가요?
방법론과 프로세스를 잘 안다고 좋은 제품/서비스가 만들어지는것은 아닙니다
코로나 기간을 거치면서 평소보다 훨씬 더 많은 기업과 조직들이 디지털 혁신 계획을 발표하고 실행하면서 요즈음 애자일 agile, 디자인씽킹 design thinking, 린 스타트업 lean startup 이라는 단어가 소위 유행어 buzzword처럼 세상에 소개되어지고 생활로 내려 오고 있습니다. 이런 유행처럼 소문과 권위를 동반하여 소개되고 조직에 도입되는 방법론과 프로세스는 도입 전에 올바르게 이해하고 그룹의 상황에 맞도록 사용하지 않으면, 과정에서 생성되는 최고의 결과물인 베스트 프랙티스를 기대하기 어렵게 되고, 또한 이 방법론만이 현재의 상황을 해결 할 수 있는 만능 해결책이 될것이라는 위험한 믿음을 갖게 됩니다. 예를 들어 하루짜리 디자인 씽킹 워크샵을 다녀와서는 현재 엔지니어링 그룹의 모든 문제, 이슈, 계획을 디자인씽킹을 통해 해결하려 하는 시도를 할 수 있다는 것입니다. (주로 상위 레벨의 매니저들 행동에서 쉽게 보여집니다.) 이 경우 지속가능하고 성공적인 제품/서비스의 릴리즈는 어려워 질 수 밖에 없을겁니다. 제 경험상 무엇보다도 애자일, 디자인씽킹, 린스타트업 이 세가지를 학습하고 구별한 후에 나름대로 적용하고 발전시키는 반복적인 과정이 중요하다고 판단해서 오늘은
애자일/디자인씽킹/린스타트업을 간단히 설명하고, ( 각각의 방법론-프로세스 자체를 설명하지는 않고, 글의 전개상, 이 세가지 프로세스가 현실에서는 어떤 상황을 만들어 내는지 이야기를 진행 하기 위한 소재에 필요한 부분만을 설명합니다.)
훌륭한 디지털 프로덕트/서비스를 만들기 위해 반드시 알아야 하는 것에 대해서 이야기 하면서
그 과정서 이들 방법론, 프로세스를 어떻게 이용하는 것이 현명하고 지혜로운것인지에
대해서 이야기를 나누어 볼까 합니다.
0. 영화 '테넷 Tenet'을 얼만큼 재미있게 보셨나요?
(영화에 대한 의견은 지극히 개인적인 것입니다.)
크리스토퍼 놀란 감독은 현 시대의 최고 감독중 한명임에는 틀림이 없습니다. 저 개인적으로도 다크나이트의 짜릿했던 감동을 넘어, 인셉션과 인터스텔라에서 보여준 시간을 다루는 물리학과 인문학의 융합은 지적만족을 극대화 시켜주었습니다. 그럼에도 불구하고 놀란 감독의 영화는 쉽지 않습니다. 특히 최근에 개봉한 또 하나의 시간을 다루는 '테넷'이라는 영화는 정말 어렵더군요. 영화관에서 한번 보는 것으로는 모든 플롯의 얼개를 이해할 수가 없었습니다. 직관적으로 이해가 안되니. 영화에 몰입이 되지 않고, 등장인물에 감정이입이 안됩니다. 결과적으로 영화가 어떻게 진행이 될지 아웃라인이 전혀 그려지기가 않더군요. 영화가 끝나고 집에 돌아와선 허탈한 마음에 영화를 해석한 글을 찾아 읽으면서 제 기억과 느낌을 동기화 시키는 과정을 거쳤습니다.
뭔가 이상하지 않나요? 이 영화가 과연 놀란 감독의 영화가 아니었어도 이렇게 했을까요? 영화의 프로모션은 한발 더 나갑니다. 매우 확실하게 드러나는 톤으로 이 영화는 노벨 물리학상 수상자인 킵쏜 Kip Thorne교수의 감수를 받았다 라고 이야기 합니다. 이 정도 되면, 이젠 누구도 놀란 감독과 킵쏜 교수의 권위에 도전하며 '테넷'영화를 물고 뜯으려 하지 않습니다. "노벨 물리학상 수상자가 모두 다 괜찮다고 했으니 이해가 안되도 그냥 보세요. 이해가 안되는 이유는 당신의 지식이 모자란 이유입니다." 와 같은 분위기가 나타납니다. 권위 있는 사람들이 만들고 감수했으니 당연히 틀린 부분은 있을 수 없는 좋은 영화다 라는 확신을 하고선, 남들의 영화 해석을 보면서 이해를 따라갑니다. 이 상태가 되면 실제로는 정말 무엇이 좋았는지에 대한 본인만의 경험은 하지 못하게 됩니다. 직관적 재미, 즐거운 마음으로 영화를 보기 보다는, 뭔가를 찾아내야 겠고 이해해야겠다라는 엔터테인먼트와는 거리가 먼 이상한 의무감이 동반됩니다.(그 후에 여러번 관람을 하고 나면 실제 이해도 되고 감동도 몇배가 되는게 사실이기도 합니다. - 그것을 '사용자 경험'이라고 할 수는 있습니다.)
왜 뜬금없이 영화 '테넷'이야기를 했을까요? 저를 포함한 대부분의 관객이 놀란의 영화에 저항할 수 없는 이유에는 놀란과 킵쏜이 지금까지 이룩한 범접하기 어려운 권위가 큰 역할을 하고 있다라는 말씀을 드리고 싶었기 때문입니다.
애자일 개발 방법론, 디자인 씽킹, 린스타트업은 모두 실리콘 밸리라는 어마어마하게 큰 권위를 갖고 있습니다. 스탠포드 d.school의 명성도 함께 합니다. 토요타자동차와 헨리포드도 등장합니다. 누구도 이 방법론에 쉽게 토 달기를 할 수가 없는 이유입니다. '실리콘 밸리의 유명기업들이 빠짐없이 모두 사용하는 첨단 방법론들인데, 당연히 우리도 사용해야지'가 시작입니다. 이것이 어떤 조건을 필요로 하고, 어떤 준비과정이 있어야 하고, 어떤 리소스가 준비되고 연습되어야만 실제 그 가치가 발휘된다라는 사전 과정이 매우 짧게 아니면 전혀 없이 훅 들어오게 되었습니다. 그것도 실제 사용자가 아닌 탑매니지먼트의 결정으로 도입이 결정되는 경우도 많지요. 뭔가 이 프로세스만 사용하면 최고의 제품/서비스를 만들어 줄것만 같은 마술지팡이로 믿고서 말입니다.
이 방법론의 권위가 여러분들의 통찰력을 방해하지 않도록 하십시오.
훌륭한 방법론이 가진 권위가 여러분의 제품/서비스의 성공을 보장하지 않습니다. 어설프게 사용하는것은 오히려 여러분의 팀원들에게 도구가 아닌 검이 되어 상처로 남게 하는 무기가 될 수도 있습니다. 도구가 효율을 발휘하려면, 그 도구가 내 몸에 익혀지는 시간이 필요하고, 내 상황에 맞게 도구 자체를 변경 수정해야 하는 경우도 빈번히 생깁니다. 여러분이 그 도구 프로세스의 주인이 되는 연습이 필요합니다. 권위를 존중하되, 그 권위가 여러분의 제품과 고객에 대한 방향을 결정하게 하지는 마십시오.
1.마법같은 표준 프로세스는 없다!
최근의 소프트웨어기업의 엔지니어링 그룹이 제품/서비스를 출하하기 위해 가지는 기본적인 조직 구성은 매우 흡사합니다. 보통 크게 3가지 축으로 나누어 지는데, 고객의 요구사항을 파악하고, 원하는 제품/서비스가 맞는 시장을 파악해서 원하는 시점에 원하는 기능을 포함한 상태의 제품/서비스 릴리즈를 담당하는 프로덕트 매니지먼트 그룹, 실제 제품의 기능을 구현하는 개발 그룹, 고객의 경험 가치를 최대한으로 제품/서비스에 반영하는 디자인 그룹이 있습니다.
개발 그룹은 개발 속도를 올리는데 모든 역량을 집중합니다. 프로덕트 팀은 필요없는 waste를 줄이는데 집중하죠. 디자인팀은 맨 처음 시작 프로세스로 상대적으로 매우 긴시간이 요하는 사용자 리서치에 집중하고자 합니다. 그러다 보니, 개발 엔지니어 그룹에선 애자일 방법론을, 프로덕트 매니지먼트에서는 린 스타트업 프로세스를, 디자이너 그룹에선 디자인 씽킹이라는 방법론을 사용하여 그들의 역량을 최대화 하고 있습니다.
훌륭한 프로세스와 방법론이라고 해서 모든 기업의 구조에 딱 맞을 수는 없습니다. 방법론과 프로세스의 권위에 기죽을 필요는 없지만, 기본 철학과 원칙을 치키지 않는것은 더욱 곤란합니다. 원칙을 지켜가면서, 도입하여 사용하고, 학습하고, 바꾸어 가면서 최적화 경험을 찾아가야 합니다. 다시한번 반복하지만, 방법론이 여러분의 제품/서비스를 성공으로 이끌어 주지 않습니다.
1) 디자인 씽킹 - 이 감춰진 보석같은 가치를 당신의 매니저는 알고 있습니까?
Design Thinking디자인 씽킹은 제품의 UX, UI및 가이드라인을 책임지는 디자이너가 사용자의 현재 문제나 애로점을 파악하고, 솔루션을 디자인하는 과정에서 사용하는 창의적인 전략이라고 정의 할 수 있습니다.
저는 전통적인 의미의 회의 책상 주위에 모여 앉아서 하는 '브레인 스토밍'은 아마도 아이디어 짜내는 방법 중에 최악의 방법이 아닐까 생각합니다.
일반적으로 좋은 아이디어는 우리의 마음에 공간을 제공하기 위해 산책을 할 때, 운동할 때, 샤워를 할 때 떠오르는것이지, 동료와 상사로 둘러싸인 고강도 압박 분위기에서 단 한시간 내에 '혁신적이고 획기적인' 아이디어를 내라고 주어진 사고 환경에서는 나오기 쉽지 않습니다.
디자인 씽킹은 기업이나 조직이 고객/사용자의 상황을 공감할 수 있도록 함으로써 고객이 가치있게 생각하는 제품을 만들 수 있도록 도와줍니다. 고객의 "핵심 요구 사항"에 초점을 맞추고, 제품/서비스 관계자들이 여러 혁신적인 아이디어가 나올 수 있도록 장려함으로써, 해당 제품이 기술적으로도 혁신적이고, 비즈니스로도 성공 가능할 수 있는 솔루션을 제안해 냅니다. 이럼에도 불구하고, 대부분의 기업의 최상위 매니지먼트 그룹은 고객 중심의 공감 문화에 대한 이해도가 깊지 않기 때문에 종종 디자인 씽킹 세션의 결과를 무시하고 기존의 관행대로 중요 결정들을 처리합니다.
디자인 씽킹 프로세스에 익숙하지 않은 상위 매니지먼트의 또 한가지 실수는 명확하고 빠르게 실행 가능한 아이디어가 디자인 씽킹 세션 초기에 나오지 않는 경우, 그 노력이 시간 낭비라고 판단하고, 해당 프로젝트 기간 동안 지속해야 할 이 프로세스를 반복하지 않게 됩니다. 그 후엔 모든 관계자가 고객의 핵심 요구 사항을 반드시 이해해고 공감하여 고객의 관점을 최대한 반영하는것이 목표인 디자인 씽킹은 전체 조직에 영향력을 미치지 못하고 디자인팀만의 프로세스로 머무릅니다. 이런 결과는 각 그룹간에 협조도 없고, 동의도 없는 이상한 종류의 작업으로 마무리 됩니다.
2) 린 스타트업 Lean Startup - MVP가 최종 목적지가 아닙니다.
Lean Startup린 스타트업의 정의는 짧은 시간 동안 제품을 만들고 성과를 측정해 다음 제품 개선에 반영하는 것을 반복해 성공 확률을 높이는 경영 방법론의 일종 이라고 하지만, 소프트웨어의 엔지니어링 그룹으로 오면 훨씬 더 복잡해 집니다. 주로 프로덕트 매니지먼트 그룹에서 이 프로세스를 운영하는데, 쉽게 말하자면, 고객이나 기업내부의 결정으로 제안 된 솔루션을 제품 모델로 전환하는 데 사용되며, 실제 고객과 함께 신속하게 테스트하여 허세/허구데이터 (참조 지난글: 좋은PM은 '허세 지표/메트릭'을 사용하지 않습니다.)를 분리하고, 학습하고, 제품 시장 적합성을 높이기 위해 반복하는 과정을 말합니다.
린 스타트 업 방법론은 실리콘 밸리에서 새롭게 다시 태어 났지만 토요타의 린 생산 시스템과 미국 국방부의 OODA(Object-Orient-Decide-Act) 철학에 뿌리를두고 있습니다. 토요타의 프로세스는 효율적으로 물건을 만드는 방법을 가르쳐 주지만 처음에 무엇을 어디에 타겟을 두고 만들어야 하는지 가르쳐주지는 않습니다.
린 스타트업에서는 이부분을 더욱 강화해서 시행하는 모든 프로젝트는 잠재적인 가치를 가진 비즈니스모델로 실험해 보는것입니다. 린스타트업 프로세스와 애자일 방법론에서 서로 공유하는 부분이 있다면 그건 짧은 싸이클로 계획을 세우고 실험을 해 보는 과정을 강조하고 있는것입니다. 린스타트업에서 현재의 진행방법으로 지속하느냐, 방향전환을 하느냐를 결정하는 가장 중요한 지표/메트릭은 '사용자의 행동'입니다. 좋은 PM이라면 고객이 어떤 제품이나 기능을 원할때 어떻게 행동하는지를 알아야 합니다. 과연 그 제품이나 기능이 고객의 주머니를 열 수 있을까를 알아야 합니다.
이런 '고객 경험'을 빠르게 순환시켜야 고객이 반응하는 제품을 지속적으로 릴리즈할 수 있습니다. 그럼에도 불구하고, 많은 기업에서는 PM들에게 성공했을 때의 경험만을 요구합니다. 사실 경험의 가치는 실패했을때와, 불확실한 상황이었을때가 훨씬 가치가 있음에도, 실패했을때의 경험을 사용해 보거나, 불확실성이 높을 떄를 대비해서 준비된 프로세스를 '실험 사용'할 수 있는 기회를 거의 제공하지 않습니다. 이런 경우 PM들은 위험도를 낮추기 위해서 'Proof-of-Concept(POC)'를 만들때 정도만 린 스타트업 프로세스를 사용하고, 본 제품/서비스를 만들때는 원래의 계획과 프로세스로 돌아갑니다. 이런 린 스타트업 프로세스는 1차 투자시기만을 생각한 MVP(Minimum Viable Product) 개념에 집중하게 되고, 그 다음을 생각하는 치열한 개발 계획이나 세련됨을 발견하기 어렵습니다.
3) 애자일 - 집중이라는 이름으로 좁은 시야를 만들어 내요.
애자일은 제품/서비스의 개발과 릴리즈 과정중에서 수 없이 변화하는 상황에 빠르게 반응하고 적응하는것을 강조합니다. 애자일을 처음 주창했던 그룹에서는 소프트웨어 개발에 영향을 미치는 많은 불확실성에 대해서 관심이 있었습니다. 시장의 상황, 경쟁제품의 상태, 개발자가 반드시 수정해야 할 이슈의 난이도등이 개발 프로세스가 효과적으로 관리되기 어렵게 만듭니다. 그래서 애자일은 '스프린트'라고 하는 짧은 업무 싸이클을 사용합니다. 그리고 그 스프린트가 끝나면 다음 스프린트를 시작하기 전에, 지난 스프린트 과정을 돌아보는 '레트로스펙티브 retrospective'라는 짧은 회고 미팅을 갖고 계속 같은 방법으로 지속할 것인지, 다른 방향, 요소를 고려할 것인지를 결정합니다.
"우리는 현재의 일정을 준수하면서, 변화에 적극적으로 대응하는것을 가치로 삼습니다" 라는 애자일 선언이 발표된 후 부터는 소프트웨어 개발에서의 불확실성은 지속적으로 개선되었습니다. 데브옵스DevOps라는 새로운 직군이 나타나면서 개발자들이 코드를 정해지고 고정된 시기가 아닌 지속적으로 릴리즈 할 수 있게되었고, 이것은 훨씬 빠른 싸이클로 피드백을 받을 수 있게 되었습니다.
이렇게 좋은 환경이 마련되었음에도 불구하고, 개발팀은 최상품질의 코드를 빠르고 효율적으로 개발, 배포하기에만 집중합니다. 회고미팅 retrospective에서 나온 개선점을 반영하는것도 나중이고, 다른 팀의 중요 컴포넌트는 어떻게 진행되는지 관심이 별로 없는 상태에서 오로지 속도전에만 집중합니다. 회사의 전략도 변화하고 고객의 요구와 반응도 변화하는데 본인들의 개발 속도가 더욱 중요하게 됩니다. 점차 고객의 필수 요구 사항과는 달라지고, 멀어지는 결과물이 나오기 시작합니다.
2. 오해를 불러 일으키게 하는 또 다른 권위의 등장
또 다른 엄청난 사이즈의 권위가 등장합니다. 전 세계 IT기업들의 제품을 평가하고 연구하는 가트너가 만든 디자인씽킹, 린스타트업, 애자일 통합 다이어그램입니다. 위의 그림 한장이 세가지 방법론을 사실상 소프트웨어 제품/서비스 개발의 표준 방법론으로 인증을 해 줍니다. 물론 너무도 이해하기 쉽게 각각의 프로세스를 통합해서 한장으로 보여줬는데, 이 그림이 다음의 큰 2가지 오해를 만듭니다.
1. 잘못 이해하면 위의 세가지 프로세스를 순서적으로 나열한 워터폴 waterfall 방법론 으로 이해 할수 있습니다. 즉 디자인씽킹이 끝난후에 린 스타트업을 행하고 그것에 따라 제품 개발을 시작하는 애자일이 동작하는 구나라고 말입니다. 절대 아닙니다. 각 프로세스는 따로 병렬적으로 동작을 합니다. 디자인그룹이 고객의 애로점을 파악할때, PM그룹은 고객의 요구사황 시장상황을 파악하고, 개발그룹은 프로덕트 백로그를 작성하는 것입니다.
2. 서로의 프로세스를 진행하면서 중첩되는 부분에서만 그룹간 커뮤니케이션이 일어난다고 생각하는것도 잘못입니다. 커뮤니케이션은 매 순간 전달되고 공유됩니다. 애자일의 스프린트 리뷰가 PM그룹에 공유되는것은 당연한 사실입니다. 디자인 그룹의 고객공감 리포트가 PM그룹과 개발그룹에 커뮤니케이션 되야 하는것도 투명하게 이루어져야 합니다.
3. 어떻게 사용하는 것이 현명하고 지혜로운것인가
다시 반복 하지만, 여러분이 훌륭한 방법론을 도입해서 사용한다고 해서 여러분의 제품/서비스의 성공을 보장하지 않습니다. 훌륭한 방법론은 이렇게 했더니 이런게 좋더라라고 모아 놓은 베스트프랙티스 일 뿐입니다. 남의 경험이 나에게도 도움이 되려면, 내가 사용해 보면서 나만의 레시피를 찾아야 합니다. 훌륭한 방법론 프로세스의 권위를 존중하되, 그 권위가 여러분의 제품과 고객에 대한 방향을 절대로 결정하게 하지는 마십시오.
제 경험을 바탕으로 다음과 같은 9가지의 추천 항목을 적어보았습니다. 어떤 부분은 동의가 가능하지만, 다른 부분은 안될 수도 있습니다. 여러분만의 방법론 레시피를 찾아가는 템플릿으로 참고 되었으면 좋겠습니다.
1) 디자인 씽킹, 린스타트업, 애자일 무엇이던지 짧은 싸이클로 신속하게 시행착오 trial-and-error를 경험하기를 추천합니다. 그 시행착오가 큰 위험이 없으려면, 작은 단위로 나누고, 조금씩 늘려가면서 incremental, 최대한 자주 행해야 하면, 반드시 회고미팅 retrospective를 가져야 합니다.
2) 팀 업무 진행상황에 대한 정기적인 리뷰는 반드시 필요하고, 해당 리뷰나 회고미팅을 통해 발견된 개선 요청 사항은 공유되어야 합니다. (초기에는 관계자들이 어색하고 불편할 수 있습니다.) 개선 요청 사항중 한두가지만 골라서 다음 사이클에 개선을 해 보기로 동의 합니다. (모든 것을 한번에 해결할 수는 없습니다.)
3) 각 그룹의 책임 매니저들은 각 프로세스의 진행상황을 충실히 파악하기 위해 중요미팅에는 반드시 참석하되, 업무 결정은 팀 자체에서 할 수 있도록 해야 합니다. 현재의 프로세스 진행중 성과가 좋은 프로세스가 있다면 널리 공유하고 확장해서 다른 팀이 사용 할 수 있도록 해야 합니다. 반대로 잘 동작하지 않는 프로세스가 있다면 신속하게 수정하거나 대채방법을 찾으십시오. 이것이 매니저의 역할입니다.
4) 애자일, 린 스타트업, 디자인씽킹의 방법론 원론에 매달리지 마세요. 방법론에 없는 좋은 사용자 경험을 발견했다면, 적극적으로 활용하십시오.
5) 팀이 테스트와 실험, 베스트 프랙티스를 통해서 자율적으로 업무에 대한 결정을 할 수 있는 권한을 가질 수 있도록 해야 합니다.
6) 커뮤니케이션은 지극히 투명하게 해야 합니다. 새로운 계획, 변경사항, 전략등을 설명할때는 왜 이것을 행하여야 하고 어떻게 진행될것인지를 공유해야합니다.
7) 레트로스펙티브를 공유하고, 그것이 절대 경쟁적인 요소로 사용되지 않아야 합니다.
8) 팀이 모두 동의할 수 있는 투명한 진행 지표를 공개합니다.
위의 8가지 보다 가장 중요한 것이 지금의 9번째 한가지 입니다.
"고객은 여러분이 지금 애자일을 사용하는지, 린스타트업을 얼마나 좋아하는지, 디자인 씽킹에 전문가인지 아닌지는 관심이 1도 없다는 사실이고 궁금해 하지 않습니다. 여러분의 팀이 고객의 필요사항과 애로점을 해결하려고 집중하고 있고, 서로간의 경험을 공유하고 협업하고 있다면, 이미 더 없이 좋은 방법론을 가진 것입니다."
9) 당신의 고객을 항상 여러분의 업무 프로세스와 제품/서비스의 중심에 두어야 합니다.
여러분들의 치열한 노력과 열정을 늘 응원드립니다.
읽어주셔서 감사합니다.
