프로토타입 - 부담 없이 실패하는 방법
리소스는 늘 부족하다.
개발자는 언제나 부족하고, 개발자가 채용될 때쯤에는 기가 막히게 디자이너가 퇴사를 한다. 모든 리소스가 밸런스를 맞춰가며 풍족하게 존재하는 아름다운 세상은 없다. 스타트업에서는 더더욱 기대하기 힘들다.
그럼에도 일은 진행되어야 하기에 조직은 프로젝트 매니징에 많은 관심을 가지게 된다. 어떻게 하면 늘 부족하고 직군마다 울퉁불퉁한 리소스를 과제에 맞게 군더더기 없이 배치할 수 있을까. 개발자의 시간을 헛되이 쓰면 안 된다. 스프린트 플래닝을 기가 막히게 잘해보자. 서버 개발자가 부족하다면 일단 클라이언트 개발만 필요한 과제들을 진행해보자. 인력을 가지고 하는 테트리스(?)가 시작된다.
인력 테트리스의 대명사 WBS Gantt-Chart물론 이 과정은 조직에 매우 중요하다. 잘 구성된 프로젝트 매니징은 조직의 효율을 올리고, 일하는 재미를 더 한다. 하지만 스타트업은 스스로 왜 이런 과정을 반복하고 있는지 반문해볼 필요가 있다.
스타트업이 프로젝트 매니징을 잘해야 하는 이유는 부족한 리소스의 효율을 극대화하여 가설을 더 빨리 검증하기 위함이다. 때문에 더 빨리 가설을 검증하는 것 자체가 스타트업에서는 실력이다. 자연스레 대부분의 조직은 하나라도 더 많은 기능을 런칭하고, 테스트해보길 원한다.
여기에 함정이 있다. 조직이 프로젝트 매니징에 지나치게 집착하게 되는 것은 가설을 오직 제품으로만 검증할 수 있다고 착각하기 때문이다. 사실 세상에는 제품과 기능을 출시하지 않고도 가설과 아이디어를 검증할 수 있는 많은 방법이 있다. 이런 보석과 같은 방법론들은 대부분 Prototyping이라는 방법으로 불리고 있다.
프로토타입(Prototype)은 '처음'을 뜻하는 'protos'와 '느낌'을 뜻하는 'typos'를 유래로 한다. 말 그대로 '처음으로 느낌을 전하는 것'이고, 이것을 제품의 측면에서 해석해보면 '제품 또는 기능의 첫인상을 전하는 것'이다.
하지만 프로토타입의 핵심은 단순히 첫인상을 전달하는 것이 아니다. 최소 비용으로 전달하는 것이 더욱 중요하다. '제품의 첫인상을 전달하기'에 충분한, 딱 그 수준이면 되는 것이다.
Dropbox의 첫 IR 영상은 최소 비용으로 만들어진 프로토타입이 얼마나 효과적일 수 있는지 보여주는 전설적인 예시이다. 창업 초창기의 Dropbox는 당시에는 아주 이해하기 어려웠던 클라우드 저장소라는 개념을 효과적으로 전달해야 했다. 하지만 창업자인 Drew Houston는 아직 버그 투성이인 Dropbox를 세상에 공개할 준비가 되어 있지 않았다.
그는 Dropbox를 완벽하게 고치는 데에 목을 매지 않았다. 대신 그는 Dropbox가 버그 없이 잘 돌아가는 듯한 가짜(?) 영상을 통해 Dropbox의 사용 시나리오를 세상에 보여주며 이 문제를 마법 같이 해결했다. 이 영상은 Dropbox의 첫인상을 너무도 효과적으로 전달했고 결국 Dropbox의 첫 투자사에 Y Combinator가 적힐 수 있었다.
영상 링크 : https://www.youtube.com/watch?v=iAnJjXriIcw&feature=emb_logo
굴지의 클라우드 기업 Dropbox의 데모 영상에 메모장이 활용되었다.이 영상의 킬링 포인트는 단연 메모장과 그림판을 사용한 부분이다. 그는 변경된 파일이 자동으로 Dropbox에 동기화되는 것을 보여주기 위해 메모장과 그림판을 사용했다.
Y Combinator의 펀딩을 유치하고 있는 기업이 데모에 메모장과 그림판을 사용하다니. 하지만 Dropbox의 컨셉을 설명하는데 그 이상은 전혀 필요하지 않았고, 이는 '최소 비용'이라는 프로토타입의 정신에 완벽하게 부합했다. 그는 좋은 개발자인 동시에 끝내주는 Prototyper였다.
3년 후, 그는 자신이 스타트업 경험을 통해 배운 4가지 교훈 중 하나로 이런 말을 했다.
"Put something in user's hands (doesn't have to be code) and get real feedback ASAP"
"사용자의 손에 무언가를 쥐어주어라(그것이 꼭 코드일 필요는 없다) 그리고 최대한 빨리 생생한 피드백을 얻으라"
Drew Houston은 자신이 얻은 가장 중요한 교훈을 정작 괄호 안에 숨겨두는 유머를 보여줬다(doesn't have to be code). 그는 MIT 출신의 유능한 개발자였지만 '코드'가 가장 빨리 사용자에게 피드백을 얻을 수 있는 수단이 아니라는 것을 눈치채고 있었다.
나는 PO로서, 우리 팀이 무엇을 개발할지 결정할 수 있는 권한을 가지고 있다. 하지만 그 막중한 권한만큼 실패에 대한 두려움 또한 마음 한편에 늘 도사리고 있다. 자연스레 내가 가설을 검증하는 것 역시 많은 부분은 완제품이 아닌 프로토타입을 통해 이루어진다. 싸게 실패하기 위해서다.
나는 지난 1년 동안 총 40번 이상을 회사 밖으로 나가 직접 사용자를 만났다. 그 과정에서 셀 수 없이 많은 프로토타입을 만들었고 대부분 실패했다. 하지만 덕분에 많은 가설들을 개발 없이 검증할 수 있었고, 내가 어떤 사람들을 위해 일하고 있는지 깊게 공감할 수 있었다.
며칠 만에 뚝딱해서 만든 프로토타입으로 컨셉을 테스트해보던 모습. 사용자의 반응이 너무 좋아서 개발을 진행하지 않을 수 없었다.
이 프로토타입은 지금 부릉의 메인 제품 중 하나가 되었다. 제품까지 이어진 정말 몇 안 되는 프로토타입 중 하나이다.현장에 나가서 사용자가 나의 프로토타입에 대해 만족하거나 (더 높은 확률로) 악담을 퍼붓는 것을 보고 있으면 프로토타입이야말로 스타트업의 가장 강력한 무기라는 생각을 하지 않을 수가 없다. 그 악담이 1-2달 동안 온갖 리소스를 투자해서 개발한 제품에 달렸다고 생각해보라. 얼마나 아찔한가. 이처럼, 큰 조직에 비해 빠르게 방향을 전환할 수 있는 스타트업과 적은 비용으로 빠르게 가설을 검증할 수 있는 프로토타입의 시너지는 엄청나다.
결국 중요한 것은 가설이 검증되는 것이다. 누구도 그 과정을 완성된 제품을 통해서만 진행해야 한다고 못 박아두지 않았다. 똑같이 가설을 검증할 수만 있다면 최소의 비용으로 하는 것이 좋다는 것은 너무나도 당연하다.
우리는 부족한 리소스를 효율적으로 활용하기 위해 프로젝트 매니징에 엄청난 관심을 기울이고 있다. 하지만 리소스가 가장 비효율적으로 쓰이는 상황은 '굳이 제품으로 검증하지 않아도 될 것을 검증'하는 데에 리소스가 쓰이는 것이다. 때문에 우리는 좋은 프로젝트 매니징 능력을 갖추는 동시에 좋은 Prototyper가 되어야 한다.
또한 우리가 좋은 Prototyper가 되어야 하는 이유는 단순히 리소스가 부족해서가 아니라, 위에서 언급한 것처럼 프로토타입이 스타트업이 추구하는 제품 개발 프로세스와 잘 맞아떨어지기 때문이다.
좋은 Prototyper가 된다는 것은 '실패 당 비용'을 최소 수준으로 유지한다는 것이다. 조직은 한 번 한 번의 시도에 얼마나 많은 비용이 들어가는지를 늘 주시해야 한다. 조직의 '실패 당 비용'이 올라가는 것은 상당히 좋지 않은 신호이다. 큰 실수를 거듭하는 조직엔 실패에 대한 두려움이 팽배하게 된다. 가벼운 실패를 할 수 있어야 실패를 두려워하지 않을 수 있다.
그렇다면 어떻게 하면 우리 조직이 좋은 Prototyper가 될 수 있을까.
주로 시각적 전달물을 활용하는 프로토타입이 가장 효과적이기 때문에 디자이너를 잘 활용하는 것이 좋다. PO-디자이너 사이에서 계획-프로토타이핑-검증이 빠른 사이클로 돌아갈 수 있는 인프라를 마련해두는 게 좋다. 완성된 제품을 만드는 것이 아니기 때문에 퀄리티가 조금 뭉개져도 크게 상관없다. (완성도를 높이고 싶은 욕심이 자꾸 든다면 Dropbox의 메모장을 떠올려보라)
최근에는 Invision, Proto.io, Sketch 등의 발전된 프로토타입 툴로 예전엔 Hi-Fi라고 여겨졌던 프로토타입들도 적은 비용으로 제작할 수 있다. 이조차도 너무 고비용이라고 생각되면 PPT, 그림판, 그리고 당신의 손그림까지도 활용 가능하다. 사실 '첫인상'을 효과적으로 전달할 수만 있다면 어떤 방식이던 상관없다.
그다음이 가장 중요하면서 다들 어려워하는 부분인데, 프로토타입을 들고 실제 사용자를 만나러 나가는 것이다. 아무리 고객 중심을 부르짖는 조직이더라도 좀처럼 사용자를 만나려 하지 않는다. 우리의 엉덩이는 조금 더 가벼워질 필요가 있다. 빠르게 프로토타입을 만들어서 사용자를 만나러 오피스를 박차고 나가보라. 당신의 생각보다 더욱 명쾌하고 생생한 답을 얻게 될 것이다.
부릉의 한 화면 UX를 크게 바꾼 프로토타입이 실제 점주님께 된통 혼나고 있는 사진. 일단 들고나가면 이렇게 시원하게 욕을 먹을 수 있다.프로토타입을 통해 사용자를 만나보면 가설의 검증하는 것을 넘어 사용자와 공감하는 경험을 얻을 수 있다. 사용자가 당신의 눈 앞에서 숨 쉬고, 행동하고, 당신의 제품을 얘기할 때 당신은 당신이 누구를 위해 일하고 있는지 피부로 느끼게 된다. 데이터 속에서 숫자로만 존재하던 당신의 사용자는 어딘가에서 실제로 살아 숨 쉬는 사람이었다!
그리고 좋은 Prototyper가 되기 위해 마지막으로 명심해야 할 점은 이 과정을 지치지 않고 지속하는 것이다.
다시 한번, 우리의 업의 본질은 제품을 성장시키기 위해 수많은 가설을 검증해나가는 것이다. 그리고 그 과정이 최소의 비용으로 치러질 때 우리는 더 많은 가설을 더 빨리 검증할 수 있다. 우리가 좋은 Prototyper가 되어야 하는 이유다. 중요한 것은 제품을 '통해' 가설을 검증하는 것이 아니라, 제품을 '위해' 가설을 검증하는 것이다.
스타트업에서는 빨리, 싸게 실패하는 것이 실력이다.
덧붙여,
가설을 검증하는 방식이 꼭 제품의 개발을 통한 방식과 프로토타입으로 이분법적으로 나눠질 필요는 없다. 비즈니스, 조직, 사용자에 따라 정말 다양한 방식의 가설 검증 방식이 존재할 수 있다. 이 글에서는 가장 잘 발전된 방식으로서의 가설 검증 방식인 프로토타입을 소개하는 데에 집중했다.
게다가 프로토타입이 무조건적으로 옳은 것은 아니다. 잘 쓰인 프로토타입이 좋은 것인데, 프로토타입이 잘못 쓰였을 때의 단점은 아래의 아티클에 더욱 잘 서술되어 있다.
프로토타입의 개념이 익숙지 않은 독자들을 위해 몇 가지 좋은 아티클을 소개하며 글을 마친다.
[1] 프로토타이핑의 세 얼굴
https://ppss.kr/archives/187384
[2] Low-fidelity VS High-fidelity Prototype
https://www.invisionapp.com/inside-design/low-fi-vs-hi-fi-prototyping/
[3] Design Thinking : Get started with prototyping
https://www.interaction-design.org/literature/article/design-thinking-get-started-with-prototyping
[4] 11 Best prototyping tools for UX/UI designers
