최근 들어 사이드 프로젝트를 하는 직장인이 점점 많아지고 있습니다. 스타트업에 다니는 주변 지인들도 대부분 사이드 프로젝트를 진행하고 있고, 저도 개발자로서 역량을 쌓기 위해 이제까지 작은 프로젝트를 종종 개발해왔습니다. 그러나 상당수의 사이드 프로젝트는 개인에 의해 시작되고, 얼마 지나지 않아서 중단됩니다. 여러 명이 함께하는 경우에도 흐지부지되는 경우가 많은데요. 부캐를 위한 공간, HYDE 이런 몇 번의 시행착오 끝에, 저는 마침내 좋은 사람들과 함께 원하는 프로덕트를 만들게 되었습니다. 다만 팀을 구성하는 것부터 프로덕트를 완성하는 과정까지 전부 쉽지만은 않았는데요. 오늘은 현재 운영하고 있는 저희 프로젝트를 통해 어떤 방식으로 진행했고, 무엇이 목표이며, 어떻게 운영하고 있는지 등 사이드 프로젝트의 궁금증에 대해 설명하고자 합니다. 서비스의 시작: 아이디어에 대한 열정과 확신팀원 모집 전에 작성한 서비스 소개. 이를 토대로 팀원을 모았다. 사이드 프로젝트에서 가장 중요한 것은 '아이디어 제안자(혹은 대표)가 서비스(비전)에 얼마나 큰 열정을 갖고 있는가'라고 생각합니다. 이제까지 중단한 프로젝트를 생각해 보면, 처음에는 재밌을 것 같아 시작했다가 나중에 흥미가 식어서 관두는 경우가 대부분이었기 때문입니다. 그러나 이번에는 달랐습니다. 아이디어에 애정과 확신이 있었고, 그것이 그 순간만의 감정이 아님을 확인하기 위해 프로덕트의 장기적인 모습을 상상해 보거나, 미리 간단하게 기획서를 작성하기도 했습니다. 팀 구성하기: 팀의 성장, 개인의 성취서비스에 확신이 있던 저는 애플리케이션(이하 앱)을 빠르게 출시하고 싶었습니다. 물론 혼자 모든 것을 진행한다면 병목현상 없이 원하는 속도로 개발할 수 있겠지만, 다른 사람들과 함께 배우면서 프로덕트를 만들어나가는 것이 더 효율적이라고 판단했습니다. 개인의 생각으로만 서비스를 만들다 보면 실제 이용자의 니즈에서 벗어나기 쉬울 것이라는 생각도 있었습니다. 첫 시작부터 런칭까지의 회의록 다행히 주변에는 함께하고 싶은 사람들이 많았고, 아이디어에 공감하는 사람들에게 함께할 것을 제안했습니다. 그렇게 저를 포함한 네 명의 팀이 구성되었습니다. 팀원들이 본업 외의 시간을 투자하는 만큼, 팀장은 팀원들이 사이드 프로젝트 경험을 통해 얻고 싶은 것을 성취하도록 도와줘야 합니다. 회사에서 프로덕트 매니저(PM)로 근무하는 팀원 A는 백엔드 개발에 관심이 있다고 해서 서버 개발을 하게 되었고, 콘텐츠 프로듀서가 본업인 팀원 B은 프론트엔드 개발에 관심이 있다고 해서 앱 개발을 맡았습니다. 그리고 프로덕트 디자이너로서 주로 웹 디자인을 하던 팀원 C는 앱 디자인을 하게 되었는데요. 마지막으로 개발자로 일하던 저는 프로덕트 매니징과 기획을 주로 하고, 개발을 보조/관리하는 역할을 맡았습니다. 팀이 일하는 방식: 느슨하되 꾸준히, 애자일스럽게느슨하다: 자율적인 참여를 장려한다.팀의 업무 방식을 짧게 표현하면, '느슨하되 꾸준히', 혹은 '애자일'로 설명할 수 있습니다. 우선 느슨하다는 말은 여유를 갖고 프로젝트에 임한다는 뜻입니다. 창업팀의 경우, 모든 시간과 노력을 들여 프로덕트를 개발해야 합니다. 그러나 각자의 본업과 생활이 있는 사이드 프로젝트에서 그렇게 하기는 현실적으로 어려운데요. 아이디어 발제자는 보다 빨리 서비스를 개발하고 싶을 수 있겠지만, 모두에게 똑같은 몰입을 강요해서는 안 된다고 생각합니다. 만약 현재의 속도보다 더 빠르게 만들고 싶은 욕심이 있다면, 당사자가 더 많은 일을 맡는 것이 바람직한 것이죠. 저 역시 속도에 대한 욕심이 있었고, 회의에서 업무를 나눌 때 조금 더 많은 업무를 스스로에게 할당하는 방식으로 프로젝트를 진행했습니다. 꾸준하다: 동기부여를 유지하며 서비스를 만들어나간다.여유만 추구하다 보면 자연스럽게 속도가 늦어지고, 동기부여가 떨어지게 됩니다. 사이드 프로젝트에서 동기부여가 떨어진다는 것은 결국 프로젝트 종료를 의미합니다. 이를 위해서는 꾸준함이 필요합니다. 저희는 꾸준함을 유지하기 위해, 매주 최소 한 번의 회의 시간을 가졌습니다. 회의를 통해 각자의 작업을 공유하며 서로에게 피드백을 받았고, 덕분에 차근차근 서비스를 만들어나갈 수 있었죠. 회의는 비대면으로 약 1시간 동안만 진행했기에, 큰 부담 없이 이러한 과정을 지속할 수 있었습니다. 애자일: 잦은 피드백으로 짧은 목표를 달성해나간다.마일스톤 달성을 위한 단기 목표 정리 원활한 서비스 출시를 위해 '욕심'을 경계해야 합니다. 누구나 서비스를 구상할 때 다양하고 멋진 기능으로 세상에 알려지는 것을 상상하게 됩니다. 이러한 욕심을 갖고 서비스를 기획하다 보면 필요한 기능이 많아지고, 일정이 늦춰질 수밖에 없습니다. 그러나 많은 노력으로 탄생한 서비스도 충분히 시장에서 외면당할 수 있습니다. 어떤 서비스가 사람들에게 각광받을지 아무도 모르기 때문입니다. 그렇기에 새로운 아이디어나 서비스를 검증하기 위해서는 핵심 기능만을 제공하는 최소 단위의 제품(MVP, Minimum Viable Product)을 빠르게 개발하여 유저의 반응을 확인하는 것이 중요합니다. HYDE 버전 기록 페이지. 출시 후에도 꾸준히 개선하고 있다. 사실 저희 서비스도 매우 큰 목표를 갖고 있습니다. HYDE는 장기적으로 부캐 기반의 차세대 소셜 네트워크를 지향하고 있지만, 우선 '사람들이 자신의 부캐를 관리하고 싶어 하는가'를 검증하기 위해 부캐를 관리할 수 있는 다양한 탬플릿을 제공하는 기능에만 초점을 맞췄습니다. 그렇게 MVP를 설정하고 난 이후에는 매주 회의를 통해 짧은 목표를 설정하고, 기획과 디자인 및 개발에 대해 서로 피드백을 주고받으며 프로젝트를 진행했습니다. 서비스 출시: 끝이 아닌 새로운 시작많은 사람들이 사이드 프로젝트를 꾸준히 운영하지 못하는 가장 큰 이유 중 하나는 바로 완성에 초점을 맞추는 경우가 많기 때문입니다. 저도 이제까지 다양한 프로젝트를 시도해 왔는데요. 완성할 때까지는 집중력을 가지고 꾸준히 개발했지만, 그 이후에 흥미가 급격하게 떨어지는 경우가 많았습니다. 만약 사이드 프로젝트를 제대로 운영해 보고 싶다면, 완성이 끝이 아님을 알고 있어야 합니다. 서비스의 출시는 프로젝트의 시작일 뿐입니다. 저희는 앱을 출시한 이후, 팀원끼리 소소하게 축하하는 시간을 갖고 바로 회의를 진행했습니다. 출시 후 첫 회의에서는 크게 두 가지에 대해 다루었는데요. 우선 회고 과정을 통해, 기존까지의 프로세스에 대한 팀원들의 생각과 앞으로 프로젝트를 통해 개인적으로 성취하고 싶은 점에 대한 이야기를 나누었습니다. 본격적으로 개발을 하는 것이 처음이었던 팀원 A와 팀원 B는 구조가 복잡해지면서 코드를 이해하기 어려워지는 경우가 힘들었다는 이야기를 했고, 디자인을 맡았던 팀원 C는 본업과 유사한 영역의 작업을 하다 보니 가끔 일처럼 느껴지는 경우가 있었다고 말했습니다. 의견을 공유한 이후 팀원들의 성장에 도움이 되고 동기부여를 줄 수 있도록, 앞으로 팀원 A와 팀원 B에게는 작업을 할 때 개발에 대해 보다 구체적으로 설명하고, 팀원 C는 디자인을 하는 동시에 평소에 관심 있던 웹 개발을 할 수 있도록 디자인과 랜딩 페이지 개발을 함께 병행하기로 결정했습니다. 그리고 모두가 만족했던 저희의 ‘느슨하고 꾸준한' 업무 문화는 계속해서 가져가기로 했습니다. 두 번째로, 다음 마일스톤에 대한 이야기를 나누었습니다. 이제 막 출시한 MVP 단계의 프로덕트를 어떻게 검증하고, 현재 부족한 사용성을 어떻게 개선하며, 앞으로 어떤 작업을 할지 논의하는 시간이었는데요. 이런저런 이야기가 나왔지만, 가장 핵심적인 내용은 유저의 피드백과 데이터를 통해서 꾸준히 사용성을 개선하고 의사결정을 해야 한다는 것이었습니다. 사이드 프로젝트 로고. HYDE 문자를 형상화하여 제작했다. 앞서 말한 내용을 종합하여, 팀을 구성하고 서비스를 출시하는 데 있어서 느낀 점을 요약하면 다음과 같습니다. [팀원]함께하는 팀원들은 함께 성장할 수 있는 의지와 능력이 있어야 한다.함께하는 팀원들이 서비스(혹은 비전)에 공감하고 있어야 한다. [팀장(PM)]PM/매니저 역할을 하는 사람이 필요하고, 아이디어 제안자가 PM을 하는 것이 좋다.아이디어 제안자/PM은 진심으로 아이디어에 공감하고 서비스를 원해야 한다.자발적으로 참여하고 있는 팀원들의 성장에 도움이 될 수 있도록 고민하고 노력해야 한다. [프로세스]규칙적인 회의 시간을 잡아두는 것이 좋다.MVP의 기준을 잘 세우고, 한 번에 모든 기능을 구현하려 하지 않는다.서비스 출시는 끝이 아닌 시작임을 잊지 않는다. 오늘 글에서는 사이드 프로젝트에 도전하게 된 이야기에 대해 소개했습니다. 현재 저희 팀은 서비스 출시 이후에도 다양한 시도를 하며 성장하고 있습니다. 다음에는 초기 서비스로서 저희가 어떤 기준으로 개발 스택을 결정했는지, 그리고 어떻게 데이터를 통해서 사용성을 개선하고 있는지에 대해 이야기하겠습니다. 사이드 프로젝트 도전기 글 목록사이드 프로젝트 도전기: ②개발 스택 결정하기사이드 프로젝트 도전기: ③데이터 분석을 통해 발전하기 ©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
