창업 엔지니어

BIP #6 - 애널리틱스를 안 넣기로 했습니다 🤗

출시를 앞두고 앱에 애널리틱스를 열심히 넣으며 어떤 이벤트들이 중요할까, 어떤 것들을 목표 행동으로 설정할까 생각하며 열심히 작업을 하다가 글을 하나 읽고 하던 작업을 그만뒀습니다.

(방금 첫 문장을 읽으시며 “뭐야, 뭔가 잘못됐는데" 하신 분들이 계신가요? 정답*은 글의 끝에 공개하겠습니다.)

그리고 디자이너분에게 말씀드렸습니다.

“지난 번에 애널리틱스 넣자고 말씀드렸는데, 죄송하지만 나중에 넣어도 괜찮을까요? 생각해보니 이걸 작업하다가 출시가 늦어질 것 같아서요”

언제는 애널리틱스를 꼭 넣자고 하던 개발자놈이 별안간 넣지말고 출시부터 하자니. 이 나쁜 개발자는 도대체 무슨 생각인지 짐작이 가시나요? 애초에 무슨 글을 읽었길래 이러는 걸까요.

바로 얼마 전에 파운더 스토리에서 소개한 미스터 비스트의 온보딩 문서입니다.

미스터 비스트는 자신이 사용자들이 자신의 영상을 보게 만들고 이탈하지 않도록 하기 위해 2만 시간을 썼다고 얘기하며, 새로 팀에 합류한 사람들에게 딱 세 가지 지표에 집중하라고 말합니다.

영상을 끝까지 보게 만들려면?

비스트의 가르침을 받기 전에 제가 질문을 하나 던져보겠습니다.

유튜브 영상을 끝까지 보게 하려면 무엇이 제일 중요할까요?

네, 아쉽지만 틀렸습니다.

애초에 영상을 보게 만드는 게 제일 중요합니다.

영상의 처음을 시청한 사람들이 영상을 끝까지 본 사람들보다 많을 수 밖에 없습니다.

즉, 영상을 시청하게 만드는 데 실패했다면 영상을 끝까지 보게 만드는 노력은 버려지게 됩니다.

(물론 링크를 공유받아서 중간부터 보거나, 특정 부분이 하이라이트인 경우는 제외입니다.)

애초에 보는 사람이 없으면 영상이 좋은 게 무슨 소용이 있을까요?

좋은 제품을 만들었으니 사람들이 알아서 찾아서 쓸 거라고 생각하는 것과 다를 게 없습니다.

탐색창 또는 검색 결과 화면에 내 영상의 썸네일과 제목에 이끌려 사람들이 내 영상을 선택하는 비율이 바로 CTR이란 지표입니다.

그리고 미스터 비스트는 이 지표를 제일 먼저 언급합니다.

(나머지 두 지표는 Average View Duration과 Average View Percentage 입니다. 자세한 내용은 파운더 스토리의 글에서 확인해보세요!)

애널리틱스를 안 넣은 이유

제 독서 기록앱도 마찬가지입니다.

이번에는 반드시 ASO를 해본다고 제가 나름대로 ASO 도구를 만지작 거려보긴 했지만, 애초에 키워드 조사를 먼저하고 앱을 만든 게 아니라서 저는 제 앱이 검색 결과에 얼마나 자주 등장할지, 그리고 사용자들이 얼마나 제 앱을 써볼지 모릅니다.

몇 천 개씩 리뷰가 쌓인 다른 앱을 선택할 가능성이 매우 높습니다.

반면에 감각적인 앱 아이콘과 디자인에 이끌려 제 앱을 한 번 써보는 유저가 있을 가능성도 0은 아닙니다.

그리고 제가 앱을 출시하는 것을 미룬다면 제 앱이 선택받을 가능성은 0입니다.

앱 출시를 앞둔 상황에서 과정을 되돌아 보며 제가 처음부터 기획을 잘못했다는 걸 깨닫고 있습니다.

키워드 조사를 통해 쟁쟁한 앱 사이에서 살아남을 수 있는 유즈 케이스를 찾지 못한 채로 기획을 했고,

어떤 행동을 목표로 삼아야 할지도 불분명했습니다.

그래서 다른 앱에도 전부 있는 기능을 그저 예쁘게 만들어서 출시를 앞두고 있습니다.

(물론 주관적으로는 독서 기록 앱들 중에서 제일 예쁩니다. 😉)

부끄럽지만 믹스패널을 써보는 것도 이번이 처음인지라 삐걱대면서 배워야 합니다.

이런 상황에서 저는 하루라도 빨리 출시를 하고 앱 이름과 키워드, 스크린샷 등이 제대로 동작하는지 확인하는 게 애널리틱스를 넣는 것보다 낫다고 생각했습니다.

애초에 검색에 뜨지 않고 앱 페이지로 유입되지 않으면 제가 사용자 이벤트를 아무리 완벽하게 수집해봤자 크게 도움은 되지 않을 거니까요.

하루라도 빨리 유입 단계에서 고칠 게 있으면 고치자는 마음에 이번에도 저는 나쁜 개발자가 되었습니다.

*첫 문단에서 제 생각에서 잘못된 점은 바로 “목표 행동을 정하고 앱을 만들지 않은 것”입니다. 요즘 유튜브에 대해서도 조금 공부 중인데, 거기서도 “제목과 썸네일부터 정하고 영상을 만들라”는 얘기를 많이 하더라고요 😉

BIP#5 - 회사에서 싫어하는 개발자가 되기로 했습니다

회사에서 좋아하는 개발자들은 다음의 특징들을 가지고 있다고 생각합니다.

• 설계 능력이 좋다.

• 디자이너가 만든 다양한 요소들을 잘 구현해준다.

• 사업팀/기획자가 원하는 것들을 기술적으로 가능하면 최대한 반영한다.

• 다른 사람이 프로젝트를 물려받아도 원활하게 작업할 수 있도록 프로그램을 만든다.

• 기술을 쓸 줄만 아는 게 아니라 원리와 구성 요소들에 대해 이해를 하고 있다.

• 가독성이 좋은 코드를 짠다.

• 테스트 코드를 짠다.

저는 스스로를 회사에서 좋아하는 개발자라고 생각합니다. (…🤔)

그리고 앞으로는 회사에서 싫어하는 개발자가 되기로 했습니다.

MVP를 1년 가까이 만들며 출시를 앞두고 조금씩 회고를 하고 있습니다. (BIP #3, #4)

그리고 제가 개인 프로젝트에는 어울리지 않는 개발을 하고 있다는 것을 많이 느끼고 있습니다.

위의 적은 특징들은 모든 개발자가 가지고 있어야 할 덕목이라고 생각합니다.

하지만 앱을 사업화하려는 사람은 개발자처럼 생각해서는 안 된다고 생각합니다.

특히 MVP를 만드는 경우에는 더더욱 말이죠.

MVP를 만드는 이유는 핵심적인 아이디어에 대한 시장의 반응으로 보려고 하는 것입니다.

정말 가려운 곳을 잘 긁어주는 앱이라면 다소 투박하더라도 반응이 있을 것이고,

가려운 곳을 긁어주지 못하는 앱이라면 아무리 예뻐도 리텐션이 없을 것이라고 생각합니다.

그래서 앞으로 개인 앱을 만들 때에 고도화된 UX는 가능하면 넣지 않으려 합니다.

유저는 저와 디자이너가 얼마나 공을 들여서 UX를 만들었는지 관심이 없습니다.

해당 UX가 셀링 포인트가 아닌 이상 애플에서 기본적으로 제공하는 컴포넌트를 사용하더라도 충분히 괜찮은 앱을 만들 수 있다고 생각합니다.

이런 마음을 가지고 지난 회의때 조심스럽게 디자이너 분께 말씀드렸습니다.

앞으로는 기본 컴포넌트를 최대한 활용하면 어떻겠냐고. 그리고 디자인 QA는 출시 후에 조금씩 반영하며 업데이트를 하자고요.

다행히 디자이너 분도 ‘앱 수익화’가 목표셔서 게으른 디자이너(?)가 되는 것에 동의를 해주셨습니다.

여전히 고도화된 설계와 테스트 코드는 중요하다고 생각합니다. 그리고 이번에 개발을 하면서도 이런 설계의 장점을 많이 느꼈고요. 그래서 최소한의 퀄리티만 유지하며 속도를 중시하는 게 얼마나 가능할지, 과연 장기적으로 도움이 되는 방향인지는 모르겠습니다.

하지만 상황에 맞게 적절한 전략을 쓰지 못하면 좋은 사업가가 되기는 힘들 것 같습니다. 이번에 시간을 많이 소요했으니 다음 번에는 MVP 답게 빠르게 만들어 보는 게 맞을 것 같습니다. 철저히 비즈니스 관점에서 말이죠.

제 목표는 회사의 개발자가 아니라 회사를 운영하는 사람이 되는 것이니까요.

BIP#4 - MVP, 저처럼 잘못 만들고 계신가요?

현재 bookbear라는 독서 기록 앱을 만들고 있습니다.
MVP라고 시작을 하긴 했는데 어느새 거의 1년이 다 되어가고 있네요. 😓 (관련 글 - BIP#3)

곧 앱 출시를 앞두고 혼자 회고를 하고 있는데,
다른 분들은 저처럼 잘못된 MVP를 만들지 않으셨으면 하는 마음에
MVP를 만들 때 절대 하지 말아야 할 두 가지를 공유해보려 합니다

잘못된 MVP #1 - 4-6주가 넘어가는 MVP

MVP 제작에 6주가 넘어간다고 해서 절대 서비스가 망하지는 않습니다.
MVP는 ‘뭘 좋아할지 몰라서 최대한 빠르게 많이 준비해봤어’를 실천하는 것일 뿐이니까요.

시장이 좋아하는 아이디어라면 얼마나 빠르게 완성했는지와 상관 없이 성공을 할 것입니다.

문제는 시장이 과연 내 아이디어를 좋아할지 아는 방법은 하나 밖에 없다는 점입니다.
실제로 시장의 검증을 받는 방법이죠.

bookbear가 성공하면 저는 괜찮은 투자를 한 게 되겠지만, 
큰 수익을 내지 못하면 저는 1년이라는 시간을 잘못된 아이디어에 묻어버린 게 될 것입니다.
(물론 성공한다고 하더라도 저는 다음 MVP는 6주를 넘기지 않도록 할 것입니다.)

잘못된 MVP #2 - 검증하려는 가설이 명확하지 않은 MVP

‘이 문제가 진짜 문제인 게 맞아?’

시장도 문제에 공감하는지 파악하는 게 MVP를 만드는 이유 중 하나입니다.
따라서 MVP를 만들 때에는 핵심 문제를 정의하고 그 문제에 대한 해결책에 모든 것을 집중해야 한다고 생각합니다.

하지만 저는 bookbear를 만들면서 기존의 독서 기록앱들이 해결하지 못한 문제가 무엇인지 명확하게 정의하지 않았습니다.

몇 가지 문제라고 느낀 점은 물론 있습니다.
하지만 그 중에서 어떤 것에 초점을 맞춰 MVP를 만들지, 시장에서 무엇을 제일 가려워할지 고민을 오랜 시간 하다가 시간이 많이 갔습니다. 그렇게 가볍고 빠르게 검증할 방법이 생각나지 않아서 일단 만들기 시작했습니다.

그러다보니 적당히 다른 독서 기록앱들도 가지고 있는 기능을 넣으면서 딱히 특색이나 방향성이 없는 앱이 된 것 같습니다.
(물론 UX와 앱의 완성도는 굉장히 높은 상태입니다.)

‘지나치게 분석을 하면서 움직이지 못하는 모습’을 뜻하는 analysis paralysis라는 단어가 있습니다.

저는 지나치게 분석만 하면서 가만히 있기 싫어서 일단 만들기 시작하기는 했지만, 완성을 하기까지 1년씩 걸린 것은 굉장히 아쉬운 부분이라고 생각합니다. 어찌보면 검증하려는 게 명확하지 않았기 때문에 시간이 더 오래 걸린 것 같기도 합니다.

다른 분들은 저처럼 잘못된 MVP를 만들지 않고, 빠르게 검증할 포인트에 집중한 MVP 만드셔서 빠르게 아이디어를 검증해보시면 좋겠습니다. 🙂

BIP#3 - MVP를 1년째 만들고 있습니다...

질문: 실제 제품이 없으면 서비스를 제공할 수 없는 경우에는 어떻게 빠른 검증을 할 수 있을까요?

🤦‍♂️ '1년째 MVP를 만들고 있다고? 님 그거 MVP 아님.'

물론 오래 걸렸다고 해서 MVP가 아니란 법은 없습니다.

(엄청 간단한 기능을 가진 제품을 하루에 10분씩만 만든다면... 🤡)

하지만 제가 봐도 제가 만들고 있는 건 MVP라고 하기엔 좀 무리가 있는 것 같습니다.

사실 MVP를 만드는 게 가능한 경우가 있고 불가능한 경우가 있는 것 같습니다.

오프라인 서비스의 경우 수요 검증을 위해 수작업을 통해서라도 핵심 가치를 전달할 수 있지 않나 싶습니다.

하지만 앱/프로그램이 핵심이 되는 서비스의 경우는 참 아이디어 검증이 쉽지 않다는 생각이 듭니다.

작년 여름, '창업형 인간되기'라는 강좌의 세미나에서 제가 비슷한 질문을 했었습니다.

Q: '카카오톡 오픈채팅처럼 동작하는 제품이 있어야만 서비스를 제공할 수 있으면 빠른 가설 검증을 어떻게 하나요?'

A: '그런 사업은 하지 않아야 합니다.'

확실히 패스트 팔로워 전략을 쓰고 최소한의 리소스를 투자해서 검증을 하고 싶으면 앱을 만들면 안 된다는 생각이 들긴 합니다.

하지만 주캐가 개발자라서 그런지 제가 다른 분야에서 사업 아이디어를 얻는 것은 쉽지 않더군요.

개발이 아닌 다른 일을 해야 기술적으로 해결이 가능한 부분이 눈에 보일텐데 말이죠.

어느 분야든지 제품을 잘 만들고 마케팅을 잘하면 사업화가 가능하다는 것을 믿고 일단 지금 프로젝트를 시작했습니다.

이전에 했던 5개의 프로젝트는 홍보를 전혀하지 않고 '좋은 제품은 언젠가 빛을 본다'는 순진한 마음을 가지고 개발에만 집중했다면,

이번에는 소셜 미디어를 통해 홍보를 하며 신사임당님의 '슈퍼노멀 프로세스'를 적용해보자고 마음 먹고 프로젝트를 시작했습니다.

하지만 개발자 중에서도 특히나 소프트웨어 공학적인 문제 푸는 것을 좋아하는 제 성향이 어디 가지 않더군요. 문제를 최대한 아름답게 해결하기 위해 고민을 하며 시간을 많이 허비했습니다.

경쟁앱 리뷰를 보면서 분석하고 전략적으로 접근한다고 한 것도 어느새 목표를 향해 성과를 내는 게 아니라 문서 작성을 하며 제자리에서 발만 열심히 구르는 것으로 변질되어 있었습니다. 반년이 넘게 지난 지금와서 보면, 그 때 나름 분석한다고 정리해둔 자료는 전혀 보지 않고 있더라고요. 결과적으로는 경쟁 분석한다고 썼던 시간을 버린 것이죠.

이번 달에 앱 출시를 앞둔 상황에서 '내가 1년전으로 돌아간다면 어떤 것을 다르게 진행해볼까' 생각해봤습니다.

1. 시장의 크기를 조금 더 고려했을 것 같다.

작은 시장에서도 물론 돈을 벌 수 있다고 합니다. 하지만 그렇게 돈을 벌려면 해당 분야를 내가 정말 재밌어하고 문제에 깊이 공감할 수 있어야 기존 플레이어들 사이에 침투해서 성공을 거둘 수 있지 않나 생각이 듭니다. 좁은 타겟을 대상으로 하는 대신에 유저들이 느끼는 문제를 확실하게 이해하고 해결해 줘야 할테니까요. 그런 측면에서 지금의 프로젝트는 제게 적합한가 의문이 조금 있습니다.

그게 아니라면 시장의 크기가 워낙 커서 시장의 리더를 따라하면서 조금만 변화를 주어도 어느 정도 돈을 벌 수 있는 분야를 선택했을 것 같습니다.

1. 기획은 벤치마킹하고 UI만 더 개선했을 것 같다.

이번 프로젝트를 진행하며 시간이 많이 걸렸던 구간들을 생각해보면 디자이너와 제가 기획에 대한 다른 의견이 있어서 논의가 길어지는 경우 또는 기획 자체가 복잡해서 구멍을 메꾸는 경우였던 것 같습니다.

가볍게 가설 검증용 MVP를 만들 수 있는 게 아니라면, 기획이라도 철저하게 벤치마킹해서 제품의 UX 개선과 빠른 개발에 80%의 역량을 쏟았어야 하지 않나 싶습니다.

1. 잘 나가는 앱 중에서 제일 간단한 앱을 참고했을 것 같다.

제가 만들고 있는 앱 분야의 비슷한 상위권 앱을 보면 컨셉이 각각 다릅니다. 어떤 게 시장에서 먹힐지 모르는 상황에서 뇌피셜로 이게 통하지 않을까 생각하며 제품을 만드는 게 아니라 제일 빠르고 간단하게 쫓아갈 수 있는 앱을 벤치마킹 했어야 하지 않나 싶습니다.

이외에도 디자인과 개발에 힘을 덜 줬을 것 같다 등 다양한 생각들이 있습니다.

다른 분들은 어떻게 생각하시나요?

노코드 등으로는 핵심 가치를 전달 할 수 없고 개발을 제대로 해야만 하는 서비스는 전략적으로 쳐다보지 않는 게 답일까요?

그리고 개발을 어쩔 수 없이 해야 하는 경우 빠르게 움직이는 노하우가 있을지 궁금합니다.