스타트업이 일하는 법, 린 프로세스 도입하기
이런 분들께 이 글을 추천합니다. 스타트업에서 일하는 분, 프로젝트와 팀 운영 방식을 고민하고 있는 분, PO나 PM이 되고 싶은 분, 린하게 일하는 것이 무엇인지 알고 싶은 분. 이 중 하나라도 해당된다면 재밌게 읽을 수 있습니다. 오늘은 문제와 아이디어를 검증하고 학습하는 방법, 린 프로세스에 대해 알아보겠습니다.
린 모델을 사랑하는 스타트업
스타트업에 관심 있다면, '린(Lean)'이란 단어를 들어본 적이 있을 것이다. 왜 스타트업은 '린'을 사랑할까? '워터폴 모델'과 '린 모델'을 비교한다면, 이해하기 쉽다.
(좌) 워터폴 모델, (우) 린 모델
워터폴 모델이란?
린 모델이 등장하기 전까지, '워터폴(=폭포수) 모델'이란 제품 개발 방법론이 주로 사용됐다. 워터폴 모델은 Top-Down 방식으로 일련의 과정을 순차적으로 진행해 프로덕트를 만드는 방식이다. 각 단계에 대한 구분이 명확하기에 책임 소재나 업무 진행 상황을 확실하게 알 수 있는 장점이 있다.
워터폴 모델은 2가지 문제를 갖고 있는데 첫 번째는 '느린 속도'다. 워터폴 모델에선 각 단계를 순차적으로 진행하는데 이러한 방식이 병목 현상을 야기한다. 만약 앞 단계의 일을 완료하지 못하면 뒤 단계의 일을 시작하기 어렵다. 예를 들어, 기획 단계에서 업무 딜레이가 발생한다면 이후의 디자인과 개발 단계도 모두 업무가 중단된다.
두 번째 문제는 '허튼짓'이다. 워터폴은 완벽한 프로덕트를 만들기 위해 기획 단계에서 오랜 시간을 고객 조사에 쓴다. 철저한 조사 끝에 기획 단계가 완료되고 나서야 프로덕트 구현 단계에 진입한다. 하지만 완성된 프로덕트에 대한 고객 반응은 냉랭하기만 하다. 오랜 시간과 노력을 들여서 고객의 니즈와 페인 포인트를 파악했다고 확신했건만, 무엇이 문제일까?
모든 노력과 시간이 허투루 된다면... (출처: Giphy)
워터폴 모델은 오랜 고객 조사를 기반으로 완벽한 프로덕트 만들기를 지향한다. 그러나 프로덕트 없이 진행한 조사로 고객을 온전히 이해할 수 있을까? 인지 심리학의 연구에 따르면 인간은 가정적 질문에 긍정적으로 답하는 경향이 있다. "이런 문제가 있지 않나요?", "이런 기능이 도움이 될까요?"라는 질문을 들었을 때 과연 고객은 어떻게 반응할까?
'이게 정말 나한테 필요할까?' '내가 진짜 해결하고 싶은 문제일까?'라고 생각할까? 별다른 생각 없이 "네!"라고 외칠 확률이 더 높다. 그리고 기업은 이 반응이 진짜 반응이라 굳게 믿고 프로덕트 제작에 들어간다.
린 모델이란?
스타트업은 자원이 한정됐기에 '고객 가치를 충족하는 프로덕트'를 '빠르게' 만들어야 한다. 기존의 워터폴 모델에선 이런 게 불가능하기에 많은 스타트업은 대안으로써 '린(Lean) 모델'에 주목한다.
'린 모델'은 Build-Measure-Learn의 과정을 Iteration 하는 제품 개발 방법론이다.
린 모델은 워터폴 모델의 흐름과 반대된다. 앞서 말했듯, 워터폴 모델의 가장 큰 문제는 '허튼짓'이다. 워터폴 모델은 고객 조사를 완료한 후, 프로덕트를 만드는 흐름을 취한다. 이러한 흐름에서 고객은 '제품 없이' 가정적 질문을 받기 때문에, 자신의 진짜 니즈와 페인 포인트를 인지하기 어렵다. 린 모델은 프로덕트를 작게 만들고, 고객 조사를 진행하는 반대의 흐름을 갖는다. 고객은 '실체하는 제품'을 직접 보고 사용해 보며, 자신의 니즈와 페인 포인트를 인지하게 된다.
'린 모델'의 핵심은 'Learn'에 있다. 조사를 통해 알게 된 인사이트는 다음 프로덕트 제작 및 개선에 다시 쓰인다. 고객 반응이 좋지 못했다면 더 많은 리소스를 쏟기 전에 '만들지 말아야 할 프로덕트'를 알게 돼서 자원 낭비를 사전에 방지한 셈이다. 반대로 고객 반응이 좋다면 한정된 리소스를 더 집중 투자할 프로덕트를 알게 된 셈이다. 이렇게 학습 사이클이 빠르게 돌면서 고객이 궁극적으로 원하는 프로덕트에 더 빠르게 다가갈 수 있다.
배운 거 써먹고 배우고 써먹고! (출처: Giphy)
(사례) Lean하게 일하는 우리 팀 시스템
메이아이에 내가 속한 팀은 '린하게 일하기'를 중요시 여겼다. 이는 팀 액션 프로세스에도 반영됐는데, 팀은 아래의 골자를 갖는다.
구글 스프린트와 결이 유사하다.
(1) 월요일: 모두가 동의하는 문제 정의, 아이디어 방향 결정
(2) 화요일: 아이디어 구체화 및 얼라인
(3) 수요일: 각자 할 일 정하기, 문제와 아이디어를 검증할 가설 설정
(4) 목요일 이후: 팀 액션 진행, 가설 검증 데이터 수집, 가설 검증 및 학습
1) 월요일, "진짜 문제는 무엇일까?"
어디서나 쓰이는 어피니티 다이어그램 기법!
월요일은 팀이 집중해야 할 진짜 문제를 정의하는 날이다. 회의 전, 각 팀원은 자신이 가진 데이터와 경험 등을 참고해 팀이 해결할 문제를 생각한다. 저조한 KR 수치나 과거의 팀 액션에서 학습한 바도 참고한다. 회의 전의 핵심은 문제를 최대한 발산하는 데 있다. 문제의 수렴은 오직 회의에서만 진행한다.
회의를 시작하면 각자 생각한 문제를 공유한다. 이후 포스트잇에 적고 결이 비슷한 문제끼리 그룹을 맺는다. 그룹 맺기가 끝나면 문제 그룹 사이의 우선순위를 결정한다. 이때, 판단 기준은 현재 KR 수치나 최근에 발생한 이슈 등이 된다. 가장 우선순위가 높은 문제 그룹을 이번에 해결할 문제로 결정하거나, 혹은 5 Whys 기법을 통해 숨겨진 진짜 문제를 찾는다. 이때 결정한 문제는 팀원, 모두가 동의하는 단 1개의 문제여야만 한다. 그렇지 않은 경우 모두가 납득할 때까지 치열하게 논쟁한다.
정의한 문제를 기반으로 아이디어의 방향을 결정한다. 아이디어 방향은 앞선 문제 정의 단계에서 거의 확립된 상태라 금방 끝이 난다. 방향을 논의하는 이유는 팀원 모두의 얼라인을 위함이다. 내일 회의에선 "이 문제를 어떻게 해결할까?"를 이야기할 예정이며 회의 전까지 각자 아이디어를 생각하는 시간을 갖는다. 이때 모두가 같은 결의 아이디어를 생각할 수 있도록 방향 얼라인이 필수적이다.
2) 화요일, "어떻게 해결할까?"
회의에선 '수렴'에만 집중하자
화요일은 문제를 어떻게 해결할지 이야기하는 날이다. 회의 전, 모든 팀원은 정의한 문제를 바탕으로 다양한 아이디어를 생각한다. 문제 정의와 마찬가지로 회의 전까지 아이디어의 발산에만 집중한다. 수렴은 오직 회의에서만 다룬다. 그렇지 않으면 회의가 효율적으로 진행되기 어렵다.
회의에서 각자가 생각한 아이디어를 공유한다. 이때 아이디어가 정의한 문제와 얼라인 되지 않는다면, PO가 빠르게 중재해서 회의가 다른 방향으로 새는 것을 막는다. 회의 텐션이 떨어지거나 좀처럼 기똥찬 아이디어가 나오지 않을 때도 있다. 이럴 땐 60초마다 1개씩 총 8개의 아이디어를 종이에 적는 Crazy 8 방법을 쓰거나, 1시간 정도 흩어져서 아이디어를 스케치하고 다시 모이는 시간을 갖는다.
각자의 아이디어를 모두 포스트잇에 적고 결이 비슷한 아이디어끼리 그룹을 맺는다. 이후 리소스 대비 임팩트를 기준으로 각 아이디어 그룹을 평가한다. (1) 리소스는 '이 아이디어를 실현하기 위해 우리가 며칠을 써야 할까?', (2) 임팩트는 '이 아이디어를 실현하면 정의한 문제를 얼마나 해결할까?'의 답으로 결정한다. 문제를 정의에선 단 1개의 문제만 선택했지만 아이디어에선 여러 개를 선택해도 상관없다.
3) 수요일, "어떻게 증명할까?"
수요일은 아이디어를 구현하기 위해 각자 할 일을 정하고 실험 과정을 의논한다. 앞선 이틀 동안 문제와 아이디어의 치열한 논쟁 덕분에, 모든 팀원이 동일한 청사진을 그리고 있다. 따라서 각 팀원이 어떤 일을 진행할지 결정만 하면 된다. 이때 역할 분배의 기준은 (1) "내가 가진 능력을 적극 활용할 수 있는가?"와, (2) " 내가 흥미를 갖고 일할 수 있는가?"이다. 각 팀원은 맡은 일의 직접 책임자(DRI)로서 그 일의 책임과 권한을 모두 갖는다. 따라서 높은 퍼포먼스를 내기 위해 능력과 흥미, 두 가지 기준을 적용한다. 추가적으로 PO는 각자가 맡은 일을 더 날카롭게 정의해 서로의 역할이 겹치지 않게끔 조정한다.
이제, "우리가 주목한 문제가 진짜 문제일까?", "우리가 생각한 아이디어가 문제를 진짜 해결할까?"를 검증하기 위한 가설 검증 방식을 스케치한다. 지난 이틀 동안 팀이 정의한 문제와 아이디어는 '참/거짓을 모르는 명제'로서 일종의 가설에 불과한데, '진짜 고객'이 아니라 '우리가 해석한 고객'에 기반하기 때문이다. 우리가 '고객이 반드시 필요한 것'이라 생각한 게 알고 보니 고객한테 별거 아닌 것일 수도 있다. 따라서 이를 검증해야 한다.
여러 번의 가설 검증을 해야 올바른 방향으로 나아갈 수 있다.
먼저 가설 검증을 가장 잘 보여주는 검증 데이터를 선택한다. 그리고 기존 데이터와 경험을 참고해 검증 데이터의 목표 수치와 실험 기간을 설정한다. 실험이 끝나는 날에 검증 데이터의 실제 수치가 목표에 도달했다면, 가설이 '참'이라고 말한다.
예를 들면, '고객은 우리 솔루션이 자신의 업종에서 쓸 수 있는지 모른다'라는 문제에 주목해 '솔루션 사례 버튼을 메인 화면의 최상단에 추가한다'를 아이디어로 냈다고 해보자. 이 문제와 아이디어가 '참/거짓'인지 가장 잘 보여주는 데이터는 '해당 버튼의 CTR'이다. 이제 목표 수치를 정하기 위해 다른 버튼 CTR을 참고해 본다. 기존 버튼 CTR 중에 가장 높은 게 6 % 라면, 목표 수치를 그 이상으로 설정한다.
4) 목요일 이후, "해보고, 배우고, 성장하자"
목요일부터 각자가 맡은 일을 진행해 아이디어를 구현 및 배포하는데, 이때 '안 하는 것보다 어떻게든 만든다'라는 마인드를 가져야만 한다. 아이디어 기획과 구현은 별개의 영역이다. 아무리 기획을 열심히 해도 구현하는 과정에서 기술적 한계, 부족한 시간 등 예상치 못한 문제에 직면한다. 이런 경우에 '어떻게든 만든다'라는 마인드를 갖고, 최대한 문제를 헷징 할 수 있는 방법을 찾아야 한다.
예전에 우리 팀은 솔루션 블로그를 만들자는 아이디어를 냈지만 팀 내 개발 인력이 없어서 직접 블로그를 만들기 불가능했다. 이를 헷징하기 위한 방법으로 Notion과 oopy로 '블로그 같아 보이는 것'을 만들었다. 물론 UI 구현에 한계가 있어서 디자이너가 고통받았다.
아이디어를 배포하면 이제 관련 데이터를 계속 수집한다. 우리 팀은 GTM(Google Tag Manager), GA(Google Aanlytics), Google Optimize를 활용해 실험 환경을 구축했다. 실험이 끝나는 날 검증 데이터의 실제 수치와 검증 수치를 비교 분석한다. 실제 수치가 예상보다 낮다면 검증 수치를 너무 높게 잡은 건 아닌지 혹은, 팀이 주목한 문제나 아이디어 자체에 부족한 점이 있었는지 판단한다. 반대로 실제 수치가 예상보다 높은 경우 다음에는 어떤 액션을 집행할지 판단한다. 이렇게 검증 과정을 통해 얻은 인사이트는 다음번 팀 액션에 활용된다.
내가 쓰는 실험 노트 양식. 학습한 바를 따로 쓴다.
유쾌해야 문화가 잡힌다.
치킨이 왔어요 치킨~
우리 팀은 '치킨 팀'이라 불리는데, 이름부터 재밌는 '계란-병아리-치킨'이란 제도를 갖고 있기 때문이다. 계란이 인내와 노력을 거쳐 치킨이 되는 것처럼 각 단어는 우리 팀 시스템을 대변한다.
'계란'은 '팀이 이번 주에 정의한 문제'를 뜻하는데 "이번 주 어떤 계란(=문제)이 있을까요?"라는 말로 월요일 문제 정의 회의를 시작한다. 논의 끝에 우선순위가 밀려서 백로그 처리된 문제를 "계란이 프라이가 됐다"라고 말한다. 반면, 최종적으로 선정한 문제를 "이게 저희가 이번 주에 다룰 계란입니다!"라고 말한다.
'병아리'는 '팀이 이번 주에 구현할 아이디어'를 뜻한다. 모든 아이디어는 정의한 문제에 기반을 두는데, 이는 병아리가 계란을 깨고 세상에 빛을 보는 것과 흡사하다. 구현한 아이디어가 높은 퍼포먼스나 긍정적 실험 결과로 이어지면 "병아리가 치킨이 됐다!"라고 말한다. 어찌 보면 팀의 최종 목표는 많은 '치킨'을 만드는 것이다. 실제로 야무지게 치킨도 시켜 먹는다
일을 재미있게 하기 위해선, 환경이 뒷받침돼야 한다. 웃긴 밈이나 표현은 사람들 사이에서 습관적으로 회자된다. '계란', '병아리', '치킨' 등의 재밌는 단어는 팀원 사이에 계속 회자되며, 결과적으로 린 프로세스가 팀의 문화로 빠르게 자리 잡혔다.
<참고 자료>
프리토타입 (pretotype) - 비즈니스 아이디어 검증 방법론
[pxd talks 77] Fintech / Start-up / Toss
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
