실패실패기: 지금 안 해도 되는 것 체크 리스트
누구나 ‘보이지 않는 손’이라는 말을 알지만 그 말이 유래한 ‘국부론’을 읽은 사람은 드뭅니다. 비슷하게, ‘애자일 방법론’이나 ‘린 스타트업’ 같은 말을 그동안 일하며 수없이 들었지만 그 말들의 의미를 저는 다 알지는 못합니다. 다만 ‘빨리 시도하고 빨리 반응을 보고 빨리 깨달아서 대응한다’라는 게 핵심이라고 이해하고 있습니다.
모든 경우에 들어맞는 방법론 같은 건 애초에 없겠습니다만, 이 방법론은 유익할 때가 많습니다. 특히나 쓸 수 있는 시간, 인력, 돈이 한정적인 사이드 프로젝트에서는 더욱 그렇습니다. 처음부터 원대한 계획을 세우고 대단한 무언가를 세상에 내놓으려는 건 욕심일 수 있습니다. 빈약해 보여도 최소한의 기능을 갖고 있는 무언가를 세상에 내놓은 뒤에 유저 반응을 살펴 가며 필요한 것을 알맞게 더해서 자주 업데이트하는 것이 더 좋은 서비스를 덜 헤매면서 더 잘 만드는 덜 힘든 방법입니다.
그런데 저는 사이드 프로젝트로 ‘슬립온잇’이라는 데이팅 앱을 만들면서 이 방법론을 지키는 데 처참하게 실패했습니다. 최소 기능 제품, 이른바 MVP(Minimum Viable Product)를 만들어 내는 데에만 1년이 훌쩍 넘는 시간이 걸렸는데 그 결과물은 만들기 시작한지 세 달 쯤 됐을 때에 비해 그렇게 달라진 것도 없었습니다. 4명의 팀원들은 결국 이 앱이 앱 스토어에 올라가는 모습까지만 확인을 하고 거기서 프로젝트를 중단해야 했습니다.
쏟아 부었던 시간과 노력을 생각하면 쓰라렸지만 많은 것을 배운 경험이었습니다. 흔히 실패는 성공의 어머니라고 합니다. 앞서 말한 방법론들대로라면 빠르게 실패를 해보고, 그 실패가 성공의 어머니가 되도록 움직여야 했습니다. 하지만 저는 실패조차 실패한 셈입니다. 이 글은 제 ‘실패실패기’입니다. 혹시 MVP를 만드는데 너무 오랜 시간을 쓰고 있다고 느껴진다면 아래 리스트를 확인해 보시기 바랍니다.
지금 꼭 팀이 필요한가요?
우선 확실히 해둘 것은 저와 함께 한 슬립온잇 팀원들은 모두 훌륭한 사람들이었다는 점입니다. 팀원들에 대한 불만이 아니라, 팀을 너무 빨리 가진 것에 대한 반성입니다.
두 명이 살던 집에 다섯 명이 살게 되는 것도 쉽지는 않지만, 사실 혼자 살다가 둘이 살게 될 때 더 많은 불편함이 생겨납니다. 서비스를 만드는 것도 똑같습니다. 당신의 팀원이 얼마나 대단한 사람이든지, 팀원이 몇 명이든지 간에 팀이 생기는 순간 혼자 할 때와는 전혀 다른 길을 걷게 됩니다.
팀이 생기면 협의, 규칙, 갈등, 설득 같은 것들이 필연적으로 생깁니다. 무언가를 만들기 시작하면 모호한 영역이 생각보다 많습니다. 혼자서 프로젝트를 진행할 때에는 그 모호한 영역들을 독단적으로 진행할 수 있습니다. 근거 없이 ‘내 감이 그래!’라고 밀어붙여도 문제가 없습니다. 하지만 팀이 생기면 다릅니다. ‘이건 어떻게 하면 좋을까요?’를 논의할 때가 반드시 오고, 이 모든 과정은 아무리 민주적이고 효율적이더라도 결국엔 시간과 에너지가 드는 일입니다.
체크리스트 첫번째에 이것을 둔 것은, 이 아래에 나올 모든 체크리스트들도 팀이 생기면 돌파하기 더 어려워지기 때문입니다. 팀이 없다면 간단하게 ‘이건 일단 그냥 넘어간다!’ 했을 문제를 팀원 중에 누군가가 강력히 주장해서 구현해야 할 수도 있습니다.
지금 꼭 개발이 필요한가요?
앞서 말했듯 ‘슬립온잇’은 데이팅 앱이었습니다. 한창 슬립온잇의 MVP를 개발 중일 때 제게 큰 현타를 준 프로젝트가 있었습니다. 노션을 이용한 데이팅 서비스였는데요, 만드는 데 걸린 시간도 고작 3주였다고 합니다.1 왜 나는 이렇게 못했을까 하는 생각이 크게 들었습니다.
데이팅 서비스 시장은 이미 레드오션입니다. 그런 시장에 뛰어든다는 것은 ‘그래도 우린 이런 차별점(USP: Unique Selling Point)이 있어’라는 자신감이 있기 때문일 겁니다. 그렇다면 우선은 그 USP만 집중해서 시장의 반응을 볼 수 있지 않았을까요? 하다 못해 구글 설문지로 소개를 받아서 직접 카톡방을 만들어 주며 매칭시킬지언정, 일단은 USP가 시장에서 먹히는지 안 먹히는지만 확인할 수 있지 않았을까요? 당신이 개발자이더라도, 당신이 만들고 있는 서비스는 지금 당장 개발을 필요로 하지 않을 수 있습니다.
지금 꼭 인증 절차가 필요한가요?
로그인 기능은 웬만한 서비스에 존재하는 기본적인 기능으로 보입니다. 하지만 당신의 MVP에 벌써부터 꼭 로그인이 들어가야만 할까요? 물론 당신이 로그인 기능을 만드는 데는 잠깐의 시간 밖에 들지 않을 수도 있습니다. 하지만 그런 잠깐의 시간들을 허용한 결과가 바로 슬립온잇이었습니다. 로그인이 있으면 가입과 탈퇴가 있기 마련입니다. 아이디/비밀번호 찾기 기능도 겸사겸사 넣어줄 수 있을 것 같지만, 그러면 서버에서 이메일이나 문자 메시지 등을 보내는 기능도 따라 붙게 됩니다. 슬립온잇은 데이팅 앱이니까 이메일이나 전화번호도 본인 걸 제대로 입력했는지 인증을 받고 싶어질지 모릅니다. 그리고 그건 번거로운 작업입니다. 간편 로그인 기능도 만들고 싶겠지만, 간편 로그인은 유저가 간편한 거지 개발자에게 간편한 것이 아닙니다. 로그인은 어떤 방법으로 구현하실 건가요? 세션? JWT? 토큰 유효 기간은 어떻게 잡으실 건가요? 토큰 리프레시는 어떻게 할까요? 이 모든 고민을 어쩌면 당장은 할 필요가 없을지도 모릅니다. 우선은 MVP를 내놓고 나중에 로그인에 대해 고민해 보세요.
서비스에서 로그인의 개념을 덜어내고 나면 많은 기능들이 함께 덜어집니다. 예를 들어서 유저가 어떤 재화를 구입하는 것도 일단은 MVP를 먼저 시장에 내놓은 뒤 나중에 붙여도 되는 기능일 수 있습니다. MVP에서 로그인을 빼고 간다면 자연스럽게 이런 기능들도 출시 이후로 미루게 되고, 검증하고자 하는 핵심 아이디어에만 집중할 수 있게 됩니다.
심지어 유저들은 로그인을 귀찮아 합니다. 이건 더 설명하지 않아도 글을 읽고 계신 모두가 공감하리라 믿습니다.
지금 꼭 서버가 필요한가요?
요즘은 좋은 서버리스 서비스들이 많이 있습니다. 나중에 직접 서버를 만들고 이전하려면 골치가 아파질 수 있겠지만, 일단 MVP는 서버리스로 출시해 보는 것도 방법입니다. 경우에 따라서는 아예 서버가 필요 없을 수도 있습니다.2
지금 꼭 그 디자인이어야 하나요?
MVP에서 검증하고자 하는 핵심 기능이 디자인과 관련된 것이라면 이야기가 다를 수 있겠습니다. 하지만 거의 대부분의 경우에는 핵심 기능이 디자인과 관련이 없을 거라 생각합니다. 별다른 커스텀을 거치지 않은 기본적인 UI가 못생겨서 견디기 힘들 수 있습니다. 이해합니다. 그렇지만 일단 동작하고 있다면 출시해놓고 나중에 수정해도 됩니다. 역사가 깊은 브랜드들조차 종종 로고를 새로 디자인합니다. 너무나 간단해 보이고 익숙한 UI가 특정 플랫폼에서는 구현이 까다로울 수 있습니다. 디자이너가 ‘A안도 괜찮지만 B안이 그래도 조금 더 낫겠어’라고 정했던 게, 개발자에겐 ‘A안은 바로 구현 가능하지만 B안이면 라이브러리를 내가 새로 만드는 게 낫겠는걸’ 하는 상황이 될 수도 있습니다. 동작한다면, 일단은 못생겨도 그대로 가보세요.
지금 꼭 브랜딩이 필요한가요?
코카콜라가 어느 날 파란색으로 주 색상을 바꾸기로 결정한다면 상당한 비용과 노력이 들 것입니다. 하지만 당신이 시작하는 프로젝트는 아마 아주 작은 규모로 첫 삽을 뜨게 될 것입니다. 브랜딩은 나중에 정해서 바꿔 나가도 충분합니다. 사람들의 인식을 바꾸는 건 어려운 일이 맞지만, 당신의 프로젝트는 아직 그 인식을 갖지도 못했습니다.
지금 꼭 그걸 해야 하나요?
개발을 하다보면 자연스럽게 새로운 아이디어도 생겨 나고, 미처 생각지 못한 디테일도 떠오릅니다. 그것들을 잊지 않고 어딘가에 차곡차곡 적어두는 것은 좋은 일입니다. 하지만 그 일들을 꼭 지금 해야 할 필요가 있을까요? 그 일들은 그렇게 노력이 많이 들어가지 않을 것처럼 보일 수도 있고, 그에 비해 임팩트가 커 보일 수도 있습니다. 그렇지만 MVP에서 검증해야 하는 결정적인 기능이 아니라면, 일단 넘어가고 나중에 추가하세요. ‘하는 김에’를 항상 경계하세요.3 잠깐 동안은 ‘하는 김에’ 처리해 버린 스스로의 센스에 뿌듯하겠지만 이 역시 쌓이면 무시 못할 시간의 손실이 됩니다.
당신이 지금 추가하고자 하는 기능은 좋은 기능일지 모릅니다. 하지만 좋은 기능인가 아닌가를 기준으로 삼아 MVP에 넣을지 말지를 결정하지 마시길 바랍니다. 기준으로 삼아야 할 건 꼭 있어야만 하는가 아닌가입니다. ‘좋은 기능’은 ‘꼭 있어야만 하는 기능’보다 못해도 10배는 더 많습니다. 일단은 ‘꼭 있어야만 하는 기능’으로 출시부터 하고 천천히 ‘좋은 기능’을 붙여 가세요.
1 출처: 3주 만에 ‘노션’으로 데이팅 서비스 만들기
2 저도 이상하다고 생각합니다. 서버리스와 서버가 없는 것은 다른 개념입니다. 서버리스는 제가 직접 관리했어야 할 서버의 여러 기능을 클라우드 환경에 맡겨 버리는 것을 의미합니다. 서버를 추상화했다고 볼수도 있겠습니다.
3 이건 제 전직장인 ‘다노’에서 자주 이야기 되던 말인데, 혹시 원 출처가 어딘지 아시는 분은 댓글로 알려주시면 감사하겠습니다.