brunch

You can make anything
by writing

C.S.Lewis

by MODAY Mar 03. 2024

사이드 프로젝트에서 배운 스타트업의 성공 요인

사이드 프로젝트의 PM으로 참여하여 겪은 많은 시행착오와 배운 점

IT 회사에서 일하는 많은 직군 중 특히 개발자, 디자이너와 같은 Product와 관련된 직군에 필요한 주요 능력은 문제 해결 능력입니다. 본인이 가지고 있는 전문성을 활용하여 우리에게 주어진 문제를 해결하는 것으로 문제를 발굴하고 우리가 가진 리소스로 어떻게 해결 할 수 있을까를 고민하게 됩니다. 


보통 본인이 일하고 있는 도메인의 속성에 따라 이 문제의 크기나 깊이가 달라지게 됩니다. 제가 속해있는 의료 도메인은 문제 발굴도 어렵고 해결 방법도 복잡한 경우가 많습니다. 특히, 인허가나 비즈니스 관련 부서의 요구사항, 규제 등의 영향을 많이 받기도 하며, 제품 개발 사이클이 길어 에자일하게 고객의 반응을 보며 시장을 개척해 나가는 것이 어렵기도 합니다. 그래서 이 분야에 속해있는 사람들은 답답하고 느린 제품 개발 절차에 힘들어 하는 경우가 종종 있습니다.


저 또한 현업에서 이런저런 답답함을 느껴 사이드 프로젝트에 참여했었습니다. 새로운 동기부여를 얻기 위해서도 있었고, 조금 더 빠르게, 디자이너의 롤을 넘어 팀원들과 주도적으로 소통하며 새로운 제품을 만들어 나가고 싶었습니다. 또한, 새롭게 만든 프로덕트로 수익을 내어 근로소득 외의 사이클을 만들어 내고 싶었습니다. 그래서 제 현재 롤인 UX/UI 디자이너와 더불어 PM의 역할까지 함께 맡았는데, PM을 맡다보니 자연스럽게 PO겸, 팀장겸의 역할까지 맡게 되었습니다. 그만큼 우리의 성공을 위해 여러 시도를 하게 되었는데, 그 시행착오들을 공유해보려 합니다.




작은 스타트업 개발팀보다 큰 조직 이끌기


요즘 사이드 프로젝트 매칭해주는 서비스가 많이 발전하여 새로운 팀을 구하는 것이 어렵지 않았습니다. 저는 기수로 운영되는 사이드 프로젝트 동아리에 참여하였고, 여기서 디자이너, 안드로이드, 백엔드 각 파트별 3명씩 총 9명의 팀원이 매칭되었습니다. 어느정도 1차 아이디어와 MVP가 달성되자, 추가로 ios 파트 인원 3명을 구인하여 충원되었고 총 12명의 팀이 구성되었습니다.


순수 개발자만 9명인, 작은 스타트업보다 큰 규모의 팀이었습니다. 물론 사이드 프로젝트 특성상 학생의 비중이 높았지만, 각 파트에 현직 개발(규모있는 스타트업, 대기업 종사자)을 하고 있는 인원이 포함되어 있어 개발 리드를 하기에 충분한 상황이었습니다. 제가 속한 디자인 파트도 제가 현직자이기에 디자인 프로세스를 구축하고 우리가 무엇을 해야하는지 충분히 설계 가능하였지요. 어떻게 운영되느냐에 따라 초기 스타트업 조직보다 더 훌륭한 프로덕트를 만들 수 있는 환경이였죠. 


저는 PM으로서 처음 프로젝트 시작 단계에서 팀원과 1:1을 진행하여 본인이 생각하는 목표와 우리팀이 추구해야 하는 방향을 Align 하게 하였습니다. 그리하여 사이드 프로젝트지만 열정을 가지고 참여해주길 바랬죠. 자신이 이루고 싶은 목표와 사이드 프로젝트 팀의 목표가 같다면 더 의욕이 생길테니까요. 또한, 프로젝트 진행 짬짬이 1:1을 진행하여 문제가 없는지 확인하였습니다.


그러나 팀을 만드는 것은 쉬웠지만 지속하는 것은 어려웠습니다. 동아리로 묶인 형태였고, 직장처럼 월급이 들어오지 않으니 사이드 프로젝트에 열정을 가지고 참여하기 쉽지 않았습니다. 현생이 바쁘면 사이드 프로젝트는 미뤄야 하는 1순위가 되었죠. 시간이 지날수록 팀원의 의욕과 오너십이 저하되었고, 이탈하는 인원들도 발생하였습니다. 


저의 목표였던 수익창출은 저 스스로가 프로젝트에 적극 참여하게 하는 계기였지만 그와 더불어 팀이 지속되게 하는 가장 큰 원동력이 될 것이라 생각하였습니다. 자본주의에서 금전적인 보상보다 확실한 것은 없으니까요. 조금이라도 수익창출이 이루어진다면 가능성을 믿고 더 열심히 참여할 것이라 생각했습니다. 그래서 수익창출을 최대한 빨리 달성하고 싶었습니다. 그러나 실패하였고, 의욕저하로 이어졌습니다. 


많은 기업에서 인재가 이탈하는 이유는 정말 많은 이유가 있겠지만, 큰 요인 중 하나로 목표 설정과 보상의 실패라 생각합니다. 내가 만드는 제품의 목표가 잘 수립되어있고 그것만 향해 간다면 제품의 성공 그리고 나에게 보상이 떨어질 것을 기대하게 하기 때문입니다. 목표가 부실하면 우리는 무엇을 향해 가야하는지 알 수 없게 되고, 목표가 없기에 성공에서 멀어지며, 그에 따른 보상도 기대할 수 없게 됩니다. 그리고 보상없는 사측에 실망하고 기업을 떠나게 되지요. 사이드 프로젝트도 마찬가지라 생각합니다. 우리가 리소스를 부여하는 이유는 그곳에서 무언가 얻을 것을 기대하기 때문입니다. 개인의 성장도 하나의 목표일 수 있지만, 우리의 성장은 결국 더 큰 보상을 받기 위한 단계니까요.


열정을 억지로 강요할 수는 없습니다. 우리 팀원 모두 각자의 삶이 있고, 원하지 않는 일에 본인의 에너지를 쏟을수는 없지요. 그래서 사이드 프로젝트에서 우리의 목표는 의욕이 생길 수 있는 방향으로 설정하는 것이 중요합니다. 짧은 단위로 여러 지표를 확인할 수 있는 수준으로 설정하여 작은 성공을 볼 수 있게 하거나, 아주 약간이라도 수익이 날 수 있는 방향으로 빠르게 가는것이 도움이 될 수 있습니다. 그렇게 되면 그 다음을 기대하게 되겠지요. 저 또한, 여러 이유로 팀을 떠났기에 함께 했던 팀원들에게 미안함을 느낍니다. 만약 어떠한 가능성을 봤다면 조금 더 지속했을지도 모르겠습니다.




빠르게 실패하다

초기 스타트업에서 중요한 것은 빠른 실패와 학습입니다. 토스도 여러 실패를 거쳐 성공한 프로덕트를 찾을 수 있었죠. 빠르게 도전하고 왜 실패했는지 알아내서 그 다음 도전은 좀 더 잘하게 하는 것 입니다. 저는 우리팀이 에너지를 잃지 않기를 바랬습니다. 그래서 우리의 MVP가 실패하더라도 다시 시작 할 수 있게 '프로젝트의 실패는 있어도 팀의 실패는 없다.'라는 이야기를 했습니다. 

https://www.wanted.co.kr/events/article_23_06_14

MVP를 빠르게 실패하고 회고한 후 다시 시장의 선택을 받을 수 있는 아이디어를 발굴해 도전하고 싶었습니다. 그러나 한 번의 실패의 여파는 팀의 사기를 꺾기에 충분하였습니다. 프로덕트를 런칭하고 마케팅을 시도해도 응답이 없고, 유저가 없는 상태가 꽤 이어졌습니다. 팀원들도 우리가 만든 MVP가 실제로 필요한지에 대해 의문을 가지기 시작했죠. 그러면서 팀에 대한 불신이 생겼습니다. 이 팀과 좋은 것을 만들 수 있을지 의문이 생기면 실패를 회고하는 것도, 다른 시작을 하는 것도 무의미해 지기 때문이죠. 


고객이 없거나, 수익이 없거나 하는 상태보다 제품을 만들어나갈 팀원들의 의욕이 없는 상태가 더 치명적이라 생각합니다. 스타트업이든 사이드 프로젝트 팀이든 어떤 조직이든 실패는 당연합니다. 대기업도 당연히 실패를 하겠지요. 그러나 그 실패속에서 희망을 찾을 수 있게 이끌어나갈 리더의 역량과 정신이 중요하다 생각합니다. 그리고 그 능력이 창업자의 가장 큰 덕목인것 같기도 하구요. 작은 사이드 프로젝트 팀에 참여하며 창업했을 때의 여러 어려움을 간접적으로 체험할 수 있었습니다. 제가 이번 팀의 실패로 배운 교훈을 통해 다음에 또 사이드 프로젝트에 참여하게 된다면 더 잘할 수 있지 않을까요?




Asana를 도입하다

칸반은 위대합니다. 해야할 일을 기록하고 어떻게 되어가고 있는지 시각적으로 관리할 수 있게 해줍니다. To-do list보다 더 구체적이며, 업무에 활용하기 적합합니다. 칸반을 활용하지 않고도 사이드 프로젝트를 진행 할 수 있겠지만, 도입된다면 생산성이 훨씬 더 상승될 것임을 확신하였습니다. 제가 몸담고 있는 회사에서 Task management tool 도입부터 지금까지 활용하며 Tool이 우리의 생산성에 어떤 영향을 주는지 직접 느꼈기 때문입니다.


여러 도구들 중 Asana를 선택하였습니다. 아직 비용을 지불하고 사용할 만큼 수익이 나는 상태가 아니었기에 비용 부담이 없는 tool을 선택하여야 하였고, 다른 후보였던 Notion에서 칸반 만들기는 Notion의 과부하가 문제였습니다. 또한, Asana에서 스프린트와 목표를 설정하고 관리할 수 있었기에 PM으로서 Task 진행 사항 파악에 도움이 되고 각 팀원들의 주도적인 참여를 독려할 수 있을거라 기대하였습니다.


https://asana.com/ko/templates/kanban-board


Asana를 도입한 후 교육을 진행하였습니다. 팀원들 중에는 이러한 Task management tool이 익숙하지 않은 사람들이 있었기에, 우리가 시도하려는 일 진행 방식에 대한 학습이 꼭 필요하였습니다. 칸반과 Task 형태의 업무 처리 방식은 단순히 도구의 도입을 넘어서 일하는 방식의 변화이기에 팀원들에게 Task를 발급하고 일 진행되는 내용을 기록하게 하는 노력이 필요하였습니다.


초기에는 Task가 잘 작성되었지만 갈수록 빈도가 줄어들었습니다. 일 처리되는 것에 대한 내용이 Asana에 작성되지 않으니 다른 팀원들도 구두로 물어보게 되며 전체적으로 Asana 접속 빈도가 줄어들었지요. 당연한 일이었습니다. 돈을 받고 일하는 회사에서도 업무가 바쁘면 Task 작성에 소홀하게 되니까요. 사이드 프로젝트 팀에서 Task 작성에 대한 잔소리를 하고 강제하기는 쉽지 않았죠. 아무리 좋은 툴을 도입하여도 사용하는 팀원들이 잘 사용해주어야 의미가 있습니다. 회사에서도 어떤 팀에서도 마찬가지입니다. 우리가 일을 잘 하고자 하는 마음이 우선되어야 툴이 의미가 있어지는 것이죠. 그런 마음을 팀원들에게 불어 넣기에는 저의 동기부여 능력이 다소 부족하였으나, 그래도 동기를 부여해보자고 북극성을 도입해보려 해봤습니다.




북극성을 도입하다

우리가 만들고자 한 프로덕트는 실제 우리가 겪었던 문제를 해결하자는 목표로 설정되었었습니다. 브레인 스토밍을 통해 나온 아이디어를 구체화하고 주변 지인들 인터뷰를 통해 아이디어를 구체화 하였습니다. 그리고 1차 MVP까지 최대한 빠른 시간안에 만들고, 그 이후 문제를 발굴하여 더 나은 방향을 찾고자 하였습니다. 


그러나 MVP 수준에서는 유의미한 사용자수가 확보 되지 못했고, 새로운 개선 방향 발굴은 주변 지인을 통해 피드백 받는 수준으로 밖에 할 수 없었습니다. 이런 피드백은 시장의 선택과 거리가 있을 가능성이 높아 신뢰하기 쉽지 않았습니다. 명확하지 않은 목표로 인해 팀원들의 의욕이 저하되었죠.


그래서 북극성 지표를 작성하였습니다. 사이드 프로젝트 동아리 세션중에 북극성 지표 강의가 있었고, 강의를 듣고 여러 영감을 받았습니다. 우리 팀의 당시 상황에 아주 필요한 목표 설정 방법이였지요. 북극성 지표는 우리의 프로덕트 성공을 위해 따라가야 할 방향을 설정하는 것입니다. 큰 방향인 북극성을 설정하고 그 길 위에 있는 작은 목표들인 입력지표들을 설정합니다. 입력지표들을 달성하다보면 우리의 최종목표인 북극성 즉 프로덕트 성공에 도달하게 되겠지요.

https://www.ascentkorea.com/north-star-metric-guide/


우리가 만드는 프로덕트가 성공하기 위한 1차 북극성 지표를 잡고 입력지표를 설정하였습니다. 홈 화면, 가입률 등 여러 방면에서 성공을 측정할 지표들을 발굴하였습니다. 지표를 세우는 것은 누가 정해주는 것이 아닌 각 직군이 주도적으로 설정하였습니다. 백엔드에서는 어떤 지표가 상승되어야 하는지 본인이 알고 있는 지식으로 설명해야 하였고, 디자이너 파트에서도 화면의 흐름 중 어느 구간의 사용빈도나 시간이 어떠할 때 성공임을 판별 할 수 있는지 등의 지식을 활용한 목표를 수립하였습니다.


이렇게 목표를 설정하고 나서는 모두가 주도적으로 제품 개발 아이디어를 제시하고 만들어 나가야 하였습니다. 그러기 위해서는 토론이 활발하게 진행되어야 하고 오너십을 가지고 적극적인 아이디어와 실행이 필요하였습니다. 그러나 생각만큼 잘 굴러가지 못했습니다.


12명의 인원이 매번 정기 미팅에서 적극적으로 의견을 말하기 힘들었습니다. 그렇다고 각 직군별 미팅에서 아이디어를 정리해 공유하는 것은 직군의 문제는 공유할 수 있지만, 전체 프로덕트 성공을 위한 지표수준의 아이디어를 나누기에는 적절치 않았습니다. 북극성 지표는 주기적으로 목표가 적절한지 검토하고 수정하여야 합니다. 우리가 올바른 목표로 가는 것을 위한 것이지 절대적인 법칙을 수립하는 것이 아니기 때문입니다. 팀원들이 나서서 우리가 목표를 향해 가고 있는지, 잘못되었다면 이야기를 나누고 수정하여야 하였지만 그러한 노력이 부족하였습니다.


또한, 올바르게 설정되었는지 확인할 수 없는 목표를 설정하였습니다. 어떠한 데이터로든 검증이 가능해야 우리가 달성하였는지 확인 할 수 있지만, 우리는 활성화 된 유저의 수 등을 목표로 잡았었습니다. 실 사용 유저도 마케팅도 실행하기 전에요. 지금 상황에 맞는 목표가 수립되어야 의욕을 가지고 몰입 할 수 있습니다. 그리고 목표를 달성했을때 어떠한 보상, 성과를 기대할 수 있는 목표가 되어야 더 좋겠지요.


스타트업이 망하는 여러 이유 중 하나는 뜬구름 잡는 목표 설정입니다. 우리가 당장 지금 성과를 낼 수 있는 목표가 아닌 허황되고 현실을 직시하지 못하는 목표를 향해 가다 망하는 것이죠. 목표 설정은 정말 중요합니다. 그 목표가 제대로 되었는지에 따라 생사가 갈리기도 하니까요.




사일로를 도입하다

Task management tool도 도입하였고, 목표도 설정하였습니다. 주기적으로 회고와 1:1도 진행하였습니다. 팀이 주도적으로 활기차게 돌아가기를 기대하였었죠. 그러나 팀원들은 점점 Task를 숙제 처리하는 것 처럼 진행했고, 만든 MVP에 애정을 가지고 새로운 아이디어를 제안하는 빈도가 줄어들었습니다. 1주일에 한 번 있던 정기 미팅 시간에는 나한테 주어진 Task가 완료 되었는지 이야기하고 새로운 Task를 받아가는 형태가 반복되었습니다. 


이러한 적극적이지 못한 상황을 타파하고자 팀에 사일로 제도를 도입하였습니다. 디자인, 안드로이드, ios, 백엔드 각 1명씩, 4명이 하나의 사일로에 들어가서 주도적으로 담당하고 싶은 User flow 구간을 설정하고, 그에 따른 입력지표 고민하게 하였습니다. 사일로 구성원이 문제를 발굴하고 개선하는 것이지요. 물론 전체 팀원과 상의는 해야겠지만, 모든 팀원이 모여 이야기 하는 것보다 더 민첩하게 아이디어를 발굴하고 프로덕트가 발전할 수 있을 것이라 기대하였습니다.


각 사일로가 소통할 수 있도록 단톡방을 열고, PM인 저는 모든 사일로에 참여하지만 주도권은 사일로 구성원들이 가지도록 하였습니다. 이런 사일로를 구성할 수 있었던 이유는 직군별 인원 수가 동일하였고, 제품의 규모가 크지 않아 각 직군별 1명의 인원으로도 충분히 기능 개발 가능한 정도로 운영 가능하였기 때문입니다. 예를들어 검색 기능 도입을 위한 사일로가 구성되면 그 인원들은 검색 기능의 기획부터 개발까지 주도적으로 이끌어나가게 됩니다. 검색 기능 개발이 릴리즈 되고나면 다른 개선하고 싶은 기능을 찾아내어 아이디어를 전체 팀원들에게 공유하고 모두의 동의가 떨어지면 개선을 시작하게 됩니다. 


처음 사일로를 도입했을 때는 무척 잘 운영되었다 생각합니다. 12명이 한번에 움직이는 팀보다 4명으로 쪼개지니 훨씬 더 빠르게 소통할 수 있었고, 그만큼 팀원들은 다시 의욕이 생겨 무언가를 만들기 시작했습니다. 그러나 이 사일로도 점점 느려지기 시작했습니다. 사일로에 배정된 인원 중 현생에 바빠 소홀해지는 인원이 발생하였고, 그러면 다른 팀원들이 기다려야 하는 상황이 발생하였습니다. 사일로가 선택한 기능에 대해 오너십을 주었기에 본인들이 주도적으로 진행하지 못하면 다른 팀원이 다른 사일로의 일까지 대신 해주기 어려워졌습니다. 이러한 일이 반복되자 전체 팀원의 Task 분배가 엉망이 되었고, 이 와중에 이탈하는 인원들까지 발생하여 사일로는 구성만 되어있는 무기력한 상태가 되었었습니다.


사일로도 일하는 방식 중 하나일 뿐이었습니다. 가장 중요한 것은 참여하는 인원들의 의지이며, 그 의지를 만들어 줄 수 있는 동기 부여가 일하는 방식에 앞서야 하였었습니다. 사이드 프로젝트는 지속되지 매우 어렵습니다. 또한, 성공하기도 매우 어렵습니다. 저는 프로덕트의 성공과 수익 창출을 이루고 싶었습니다. 그렇기에 어려움을 극복하고 사이드 프로젝트가 계속되게 하는 방법을 찾아야 하였습니다. 그러나 저의 사비를 들여 팀원들에게 금전적 보상을 부여할 수는 없었고, 할 수 있는 방법들인 목표 설정, 이야기 듣기 등을 진행하였습니다. 그리고 또 하나 즐겁게 일하기를 강조하였습니다. 보상없는 일을 하는데 재미까지 없으면 정말 하기 싫을 테니까요.






사이드 프로젝트에 참여하며 많은 고민과 새로운 시도를 하였습니다. 이전에 해커톤도 몇 번 해보고, 현재 몸담고 있는 회사가 스타트업이었기에 잘해 볼 수 있을거라 생각했으나 쉽지 않았습니다. 그러나 배운게 참 많았습니다. 특히 스타트업과 사이드 프로젝트가 많이 닮아있기에, 지금 나의 상황을 돌아보기에 많은 도움이 되었습니다. 저의 일을 잘하고 성장하고 그래서 성공하고 싶습니다. 그러기 위해선 좋은 환경에서 적극적으로 일할 수 있는 환경이 매우 중요하겠지요. 좋은 목표와 적절한 보상이 부여된다면 의욕을 내서 일에 집중할 수 있을테니까요. 이런것들에 대한 고민을 사이드 프로젝트를 통해 해봤습니다. 만약 내가 창업을 한다면 '나는 팀원들에게 무슨 목표와 보상을 제시해야할까?' 라는 고민을요. 


긴 글 읽어주셔서 감사합니다.

작가의 이전글 의료 분야에서 AI는 어떤 역할을 해야 할까?
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari