안녕하세요. 넥스터즈 25기 보틀즈의 PM입니다. 서버 개발자로 일하던 제가 넥스터즈에서 PM 역할을 하면서 느꼈던 점들, 배웠던 점들이 많아 개인 기억으로 휘발시키기 보다 공유하면 좋을 것 같아 글을 쓰기로 하였습니다. 넥스터즈 지원 과정 및 면접에 관한 후기 블로그들은 많기에 그 부분은 생략하겠습니다!

계기

회사에서 개발을 하는 것도 재밌지만, 워낙 훌륭하신 선생님들과 일을 하다보니 개발자로서의 역할이 아쉬워지는 부분도 있습니다. DB는 DBA 분들이, 인프라는 DevOps 분들이, 공통적으로 사용하는 코드나 라이브러리는 플랫폼 개발자 분들이 너무 잘 만들어주십니다. 회사의 입장에서는 최상의 효율을 낼 수 있으나, 제품 개발자로서는 종종 'Json 상하차'한다는 느낌을 받고는 했습니다.

이런 것들을 회사 도움 없이 만들어보고 싶다는 생각을 하게되어서, 사이드 프로젝트를 해야겠다 생각했고 넥스터즈에 지원하게 되었습니다. 또 사이드 프로젝트가 끝나고 유지될 수 있는 프로젝트를 하고 싶었습니다. 이전에도 사이드 프로젝트를 해봤지만 아이디어를 내고 만드는 과정은 재밌지만 어느정도 생각했던 MVP 기능들을 출시하고 나면 비슷했습니다. 매달 나오는 서버비가 작은 가시처럼 거슬리기도하고, 유저들이 사용하지 않아 접는 경우가 많았습니다.

지속적으로 개발을 할 수 있으려면 프로젝트 자체가 지속되어야하고, 그러기 위해서는 최소한의 서버비를 얻을 수 있고, 신규 유저들이 들어와서 트래픽이 느는 경험을 할 수 있어야한다 생각했습니다.

B2C이며, BM이 확실한 서비스를 찾는 와중 마침 주위에 소개팅을 하고 싶어하는 친구들도 많았습니다. 하지만 소개팅 어플에 거부감을 가지는 친구가 많아 제품으로 해결해보고 싶었습니다. 제품이 출시된 배경까지 작성하기에는 글이 길어질 것 같아, 추후 기회가 된다면 별도로 작성을 해볼까합니다.

어찌저찌 아이디어를 제출하게 되었고, PM 역할을 처음으로 해보게 되었습니다.

배운 점

📅 일정과 공유

개발자로 일할 때 'xx님 이거 언제까지 될 것 같으세요?', '어떻게 되어가는 중이에요'라는 말을 들을 때 부담을 느끼기도 했습니다. '언제까지 될 것 같냐'는 말은 '빨리해라'라는 말로 들리기도 했던 것 같습니다. 하지만 PM의 입장이 되어보니 완전 다르게 보였습니다.

어떤 기능을 추가할지 정하고 -> 디자인이 나오고 -> 서버가 개발되고 -> 클라이언트 개발을 하고 -> 필요하다면 qa 까지

이런 프로세스로 제품을 만들 때, 각 직군별로 일정 산정을 해줘야합니다. 저도 개발자로 일할 때 '~까지 됩니다'라고 말하는 것이 어려웠습니다. 실제로 일정 산정 자체가 어려운 것도 있고, 언제까지 된다고 하고 그 일정을 지키지 못하는 것에 대한 걱정도 있었습니다. ~까지 한다고 하면, 일정을 맞추면 본전, 못맞추면 죄송한 상황이기 때문입니다.

그럼에도 불구하고, 프로젝트 일정을 관리하는 입장에서는 각 직군별로 가능한 정확한 일정 산정을 해주고, 만약 변수가 생긴다면 수시로 공유해주는 것이 훨씬 좋았습니다.

만약 디자이너가 3~5일 걸린다라고 일정을 잡고, 백엔드 개발자, 프론트 개발자 모두 비슷한 방식으로 잡는다면 일정이 추가되는데 9~15일이 걸릴 수 있는데 이는 오차가 너무 커서, 사실 일정이라고 말하기는 어렵습니다. 그래서 개발자로서, 내 생산성을 정확히 알고 일정을 가능한 정확하게 추산하는 것도 중요한 능력이라는 것을 알게되었습니다.

'좋은 개발자 되는 법' 같은 아티클들을 보면 커뮤니케이션 능력과 그 중에서 상황 공유가 빠지지 않고 있었는데, PM의 시선으로 보니 더욱 체감할 수 있었습니다.

🏦 신뢰자본

PM 역할을 하면서 많이 했던 고민은 '내가 이렇게 하자고 해도 되나'였습니다. 물론 회의를 하고, 팀원들의 의견을 많이 반영하려 했지만 의견 수렴이 쉽지 않을 때는 제가 결정을 해야할 때도 종종 있었습니다. 그럴 때 팀원들은 얼마나 그 의사결정에 대해 믿고 따를까 고민을 했는데요,

운이 좋게 넥스터즈 25기 기간에 '퀸잇'과 '두들린'의 대표님들이 강연을 오셔서, 창업 이야기를 해주시고 질문 응답도 해주는 시간이 있었습니다. 그때 제가 익명으로 던졌던 질문은 '제가 이전에 대단한 성공을 만들었던 사람이면 신뢰자본이 충분하겠지만, 그렇지 않은 상황에서는 팀원들에게 어떻게 방향성을 설득 할 수 있을까요'였습니다.

퀸잇의 대표님은 창업 당시 이전 회사에서 일을 잘하셨고, 그것을 아는 팀원들과 창업을 했기에 신뢰자본이 있는 상태셨다고 하셨습니다. 만약 그런 상황이 아니라면 압도적인 열정과 노력을 팀원들에게 보여주겠다고 하셨습니다.

저는 이전에 pm으로서 좋은 제품을 만들었던 경험도 없기에 다른 팀원들보다 제품에 많은 노력을 쏟아서 '아 저 사람 열심히는 한다' 이 생각이라도 들게 하려 했습니다.

스스로 생각했을 때 팀원들에게 완전한 신뢰를 얻었냐하면 자신있게 그렇다할 수는 없지만, 올바른 방향으로 노력을 하는 방법을 배웠습니다.

🐣 닭이 먼저 vs 달걀이 먼저

스타트업이 일하는 방식에 대해 좋은 책과, 아티클, 성공 사례들을 흔히 볼 수 있습니다. 그리고 자주 등장하는 내용이 유저의 반응과 지표를 보고 그것 위주로 빠르게 결정을 내리고 실행하는 것입니다. 저와 저희 팀원들 역시 그러고 싶었는데요 이때 딜레마가 생깁니다.

지표를 보려면 유저들이 필요하고, 유의미한 지표들을 보려면 유저들이 필요합니다. 또 소개팅 앱의 서비스 특성상 기존 유저풀이 있어야 새로운 유저들이 매력을 느끼고 유입됩니다.

하지만 정말 필수적인 기능이 제대로 없거나, 치명적인 버그가 있는 상태로라면 유저들이 들어오지 않고, 들어왔다고 하더라도 금방 나가게 됩니다. 무작정 '유저 지표 보고 결정할거야'라는 생각으로 필수 기능 구현을 미룬다면 역설적으로 그 유저 지표 또한 못볼 확률이 높습니다.

'린스타트업' 책에서 MVP란 Minimum Viable Product라고 합니다. 그리고 Viable(실행 가능한)의 뜻은 '최소한의 학습을 할 수 있는' 이라고 합니다.

A가 좋을지, B가 좋을지 헷갈릴 때 유저 지표를 보고 결정하고 싶을 때가 많았지만 너무 초기에는 그런 지표를 보는 것조차 사치일 때가 많다는 것을 배웠습니다.

다행히 저희는 제품 출시 이후, 당일 탈퇴 비율이 높다는 것과 자기소개 작성 비율이 떨어진다는 점을 발견했습니다. 그리고 당시 강제 업데이트 기능이 없어, 버그가 있어도 대응할 수 있는 방법이 없다는 것을 알게 되었고, 얻은 지표들을 바탕으로 제품을 개선 중입니다.

🤔 '좋은' 의사 결정

넥스터즈에서는 7~10명 정도가 한 팀을 이루어 프로젝트를 진행합니다. 저희 팀은 8명이 한팀이 되었습니다. 8명이서 '좋은' 의사 결정을 하기 위해 회의도 많이 하였고, 토론을 하기도 하였습니다. 그렇다면 '좋은' 의사 결정은 무엇일까요?

'좋은' 결과를 내고, 비슷한 상황에서 같은 기준으로 따라갈 수 있는 결정이라고 생각했습니다. 여기서 '좋은 결과'에 대한 기준이 또 필요해집니다. 사실 회사였으면 조금 더 단순했을 것 같습니다. 회사에 이익이 되고, 설정한 지표를 잘 보여주는 것이 좋은 결과이겠죠. 하지만 넥스터즈는 동아리이고, 각자가 다른 목표로 들어왔습니다.

처음 팀이 만들어졌을 때 왜 넥스터즈에 들어왔는지, 얻어 가고 싶은 것이 무엇인지 물어봤습니다. 다양한 사람들을 만나고 네트워킹, 취업용 포트폴리오, 계속 유지되는 앱 등등 다양했습니다.

그래서 의사 결정을 할 때 어떤걸 기준에 두고 결정할지 고민이 많았습니다. 어떤 기능을 붙이는 것이 누군가에게는 사이드 프로젝트치고 오버엔지니어링일 수 있는 것이 누군가에게는 좋은 아키텍처 연습일 수도 있습니다. 누군가에게는 불필요한 UT가 누군가에게는 좋은 포트폴리오를 위해 필수적일 수 있습니다.

이처럼 좋은 의사 결정이 무엇인지 정하기는 어렵지만, '나쁜' 의사 결정은 비교적 명확하다고 생각합니다. 이도저도 안되는 것이 나쁜 의사 결정이라고 생각했습니다. 따라서 지나치게 회의가 길어지거나, 논의가 길어지는 것을 방지하려고 노력했습니다.

🍻결국 사람이 하는 일입니다

결국 사람이 하는 일입니다. 사람이 중요한 일입니다. 이 말이 많이 와닿았습니다. 팀원들 간 거리감이 느껴진다면 회의를 할 때, 좋은 아이디어가 있어도 말을 못꺼내고, 반대 의견도 내지 못합니다.

물론 너무 친해져서 부정적인 피드백을 주기 어려운 경우도 있겠지만, 모르는 사람들이 모여 프로젝트를 할 때는 친해지는 시간을 가지려고 노력을 많이 해야한다는 것도 배웠습니다.

🚌 버스 팩터와 기술 스택

Bus Factor: '프로젝트를 진행하는 팀원 중 몇명이 제대로 된 인수인계 등의 절차 없이 갑작스럽게 빠지게 되었을 때 프로젝트가 중단 내지는 그에 준하는 심각한 상황에 놓이는지'를 나타내는 지수로, 평상시 팀원간의 정보 공유 정도나 업무 대체 가능 여부 등을 종합적으로 반영하는 지표이다.

버스 팩터가 높다는 것은 소수의 한두명이 빠지게 되면 프로젝트 전체에 영향을 받는다는 것입니다.

저희 팀은 디자이너 2, 서버 2, iOS 2, 안드로이드1, 프론트 1명으로 구성되어있습니다. 직장인과 취준생이 함께하는 넥스터즈 특성상 직장인도 비슷하지만, 취준하는 친구들은 공채 시즌이 되면 확 바빠질 수 있습니다. 이럴때도 속도가 줄지언정 프로젝트가 지속될 수 있어야 하는데, 이 중 안드로이드와 프론트는 당장 빠진다면 대체할 사람이 없습니다.

또한 네이티브는 하나의 기능에 대해 iOS, 안드로이드 양쪽에서 구현을 해야 하기에 리소스가 아쉽다라는 생각도 했습니다. 그래서 저희는 웹뷰를 최대한 활용해 생산성을 높이려 하고 있습니다.

만약 돌이켜 봤을 때, 앱 서비스를 만드는데 제일 효율이 좋은 기술 스택을 정하라고 한다면 지금 생각으로는 플러터 + 웹뷰로 갈 것 같습니다. 지금의 팀 구조에서는 웹뷰를 최대한 많이 활용하는게 효율성과 안정성 모두를 가져가는 방법일 것 같습니다.

☠ 명분이 없다 아입니까 명분이

저는 처음 넥스터즈에 참여했을 때 완전 참신하고 좋은 기획이 필요할지 몰랐습니다. 유튜브 이전에도 비메오와 같은 유사한 서비스가 있었음에도 유튜브가 성공했고, 페이스북 이전에도 마이스페이스라는 소셜네트워킹 서비스가 있었습니다. 반대로 사이드 프로젝트들 또는 스타트업을 보면 정말 참신하다, 좋은 아이디어다 싶어도 실패하는 경우가 훨씬 많습니다. 그래서 새롭고 좋은 기획이라고 꼭 성공하는 것도 아니고, 반대로 뻔한 아이디어여도 성공을 할 수 있다고 생각하고 있었습니다.

그렇지만 아이디어 회의와 기획을 하다보면 ~서비스와 뭐가 달라요? 저희 서비스의 특색이 약한 것 같아요 라는 피드백을 많이 들었습니다. 사이드 프로젝트에 참여하는 사람들의 동기부여는 뭘까요? 여러가지가 있겠지만 제가 느낀건 탄탄한 기획과 성공 가능성에 대한 믿음이 공통적이었습니다.

기획에 대해 깊게 생각하지 않고 참여했던 것이 아쉬움으로 남습니다. 미리 탄탄한 기획을 했다면 조금 더 팀원들에게 동기 부여를 하고, 개발 시작 시간도 당길 수 있었을 것입니다.

또 팀원들의 동기부여라는 관점에서 출시되었을 경우 어떻게 마케팅을 할지도 미리 생각을 해놔야한다는 것을 배웠습니다. 유튜브에서도 관련 내용을 들어서 알고 있었지만, 실제 겪어 보니 더 와닿았습니다. 제품 출시가 되기 전 기능 개발이 한참일 때 어떻게 마케팅을 할지 홍보를 할지 고민한다면, 높은 확률로 '출시 후 해도 늦지 않다'라고 말할 것입니다. 하지만 아무도 사용하지 않는 서비스를 만들고 싶은 메이커는 없습니다. 메이커 직군은 본인이 만든 서비스를 사람들이 사용하고, 거기서 피드백이 올 때 보람을 느끼고 그것을 동력으로 다음 기능을 만듭니다. '일단 만들고 생각해'는 자칫 엔진을 꺼트릴 수도 있다는 것을 알게되었습니다.

지금 보틀은 나름의 차별화 전략도 찾아가는 중이고, 사용자들 지표로 동기부여가 되는 중입니다.

그래서 뭘 만들었는데?

첫 번째 제품 버전에 부끄러움이 없다면 출시가 너무 늦은 것이다

기존 소개팅 서비스들이 허위광고, 유령 회원, 가짜 프로필 등으로 문제가 많습니다. 또 상대 외모나 조건만 보는 것이 아닌 서로에 대해 진지한 관점얘기를 짧게라도 하게 해주는 서비스가 있으면 좋겠다 생각했습니다.

• 서로의 프로필(이때는 사진이 보이지 않습니다)을 보고 마음에 들면, 3번의 공통 질문에 대해 함께 답을 하는 시간을 가집니다.

• 가치관 문답 과정이 마음에 들었다면, 상대와 사진 교환 여부, 연락처 교환 여부를 선택합니다.

다행히 AWS에서 약간의 서버비 지원을 받아, (1년정도) 완전 무료 서비스를 만들 수 있었습니다.

아이폰: https://url.kr/c7whp4
안드로이드: https://play.google.com/store/apps/details?id=com.team.bottles

실제 유저들이 사용하는 서비스이기 때문에 자기소개서 작성 및 가치관 문답에서 진심을 보여주신다면 더 좋을 것 같습니다! (넥스터즈와 벨로그 단체 소개팅)

앞으로 채워 나가고 개선해야 할 기능들이 많습니다. 사용해주시면서 피드백을 주신다면, 함께 더 좋은 제품, 소프트웨어를 만들어갈 수 있을 것 같습니다!

한번씩 써주시고, 주실 피드백이 있으시다면 bottles.developer@gamil.com 으로 주세요!

넥스터즈 두달의 기간동안 제가 글로 쓴 것보다 많은 것을 보고 느꼈고, 제가 느낀 것보다 많을 것을 썼네요. 메이커 직군으로서의 자부심과 보람을 느낄 수 있는 순간이었습니다. 앞으로도 재밌는 것들이 있으면 공유를 하도록할게요. 많은 응원 부탁드립니다!