SW 마에스트로 15기 우수자의 활동과 프로젝트 회고(2): 협업 방법과 아이디어 정하기, 기획심의

Created:

팀 빌딩이 끝나면 본격적으로 협업을 시작합니다. 이번 글에서는 저희가 협업을 진행한 방식과 아이디어 창출 과정에서의 고려사항, 그리고 기획심의 준비에 대해 이야기하려고 합니다.

협업 방식 정하기

가장 먼저 할 일은 앞으로 반년 이상을 함께할 동료들과 협업하는 방식을 정하는 것입니다. 지금 와서 되돌아보면 잘 한 것도, 개선할 점도 많네요.

에자일

저희는 에자일 방법론을 도입하기로 결정했습니다. 소마와 같이 기획을 자주 수정하며 프로젝트를 진행하는 경우에는 워터폴 방식보다 상황 변화에 유연하게 대처할 수 있는 에자일 방식이 더 적합하다고 판단했기 때문입니다. 물론 워터폴 방식을 적용하기에 세 명 팀은 너무 규모가 작다는 이유도 있었죠.

흔히 에자일에 대해 오해하는 것이 ‘에자일 = 무계획’이라는 것입니다. 이 오해는 소마에서 에자일 멘토링이나 관련 대학 강의만 몇 번 들어도 바로 깨집니다. 에자일 방식도 계획 설정과 문서화가 매우 중요합니다. 다만 계획-실행-회고의 주기를 짧게 유지할 수 있는 형태로 협업하는 것이지요.

저희가 협업한 구체적인 방법은 추후 시리즈를 작성하며 다룰 기회가 있을 것 같습니다. 다만 제가 에자일 방법을 도입하며 가장 크게 효과를 봤던 것은 데일리 스크럼이었습니다. 매일 아침 업무를 시작하기 전 짧게 어제 무엇을 했는지, 오늘 무엇을 할 것인지, 일의 진행에 무엇이 어려운지 세 문장을 말하는 것이죠. 사람은 스스로가 말한 것은 지키려고 하기 때문에, 적은 시간을 투자해서 팀원 각자가 스스로를 채찍질 할 수 있었던 좋은 방법이라고 생각합니다. 채찍질 뿐만 아니라 스스로의 작업과 성과를 회고하도록 하는 역할도 했고 말이죠.

그라운드 룰

팀 노션 페이지를 파고 저희가 가장 먼저 정한 것은 그라운드 룰이었습니다. 그라운드 룰은 협업에 있어서의 헌법이라고 할 수 있습니다. 모든 경우 최소한으로 지켜야 하는 규칙들을 정하는 것이죠. 저희 팀은 그라운드 룰에 회의/메신저/일정 공유 등 의사소통 방법, 논쟁시 의사결정 방법, 태도 등의 항목을 포함시켰습니다.

그라운드 룰 노션 화면의 일부 당시 저희가 팀 노션에 작성한 그라운드 룰의 일부입니다.

지금 와서 보면 잘 지켜진 것도 있지만 대부분은 생각만큼 지켜지지 않았던 것 같습니다. 잘 지켜진 것들 역시 딱히 의식하지 않고 지켰거나 매일 반복해서 하다보니 자연스럽게 지켜진 것들이라 아쉽네요. 이유를 생각해보자면 아래와 같습니다.

  1. 강제력의 부재: 저희의 그라운드 룰에서 회의는 최대 한 시간이어야 한다는 규칙이 있었지만, 대부분의 경우 이는 지켜지지 못했습니다. 그것이 반복되니 나중 가서는 한 시간 내에 끝내야 한다는 의식 자체도 희미해졌었죠. 하지만 잘 지켜진 규칙들도 있었습니다. 작성한 자료조사 보고서의 가장 위에는 해당 자료조사의 요약이 있어야 한다거나, 매일 오전 10시에 데일리 스크럼을 진행한다거나 하는 것이죠. 잘 지켜진 규칙과 그렇지 못한 규칙의 차이점은 시스템적인 강제력이었습니다.
    • 시스템적인 강제라는 것은 매일 같은 시간에 반복하는 것 같이 시공간적으로 강제하는 것도 있지만, 보고서의 경우와 같이 서식으로 강제하는 것도 있습니다. ‘한 시간 회의 룰’의 경우는 그것이 문장으로만 존재했지 실질적인 강제력이 없었기 때문에 회의를 하다보면 한 시간을 넘어가기 마련이었습니다.
    • ‘한 시간 회의 룰’을 수정한다면 저는 “회의는 시작할 때 예상 소요 시간과 각 항목별 소요 시간을 공지하며, 각 항목의 진행은 타이머를 설정하여 진행한다”라고 수정할 것 같습니다. 회의에 서식을 부여하고, 시간을 강제하는 것이죠.
  2. 무의미한 항목들: 사실 ‘말 끊지 말기’나 ‘시간 엄수’와 같은 태도에 대한 항목들은 지금 와 생각해보면 무의미했습니다. 이런 것들을 몰라서 안 지키는 것이 아니니까요. 때문에 만약 저걸 지키지 못하는 사람이 있다면 저 것을 그라운드 룰로 설정하더라도 같은 문제가 발생하게 됩니다.
    • 무지가 아닌 습관에 의한 행동들의 금지는 단순한 선언이 아닌 그를 효과적으로 교정할 수 있는 실질적인 방법으로 정의되어야 합니다.
    • 다음에 그라운드 룰을 설정할 때에는 저러한 행동들을 기술해두고 “해당 행동을 할 경우 그를 어긴 다음 사람이 나타나기 전까지 소마 센터 내에서 우스꽝스러운 모자를 쓰고 다녀야 한다” 등의 규칙을 정할 것 같습니다. 너무 심하지는 않지만 그 사람을 팀이 합의한 방향으로 이끌어낼 정도의 규칙을 말이죠.

결국 핵심은 어떻게 하면 그라운드 룰을 지킬 수 있을지에 대한 것입니다. 그라운드 룰이 있기 전과 후가 똑같다면 그것은 없는게 나은 규칙이지요. 이 글을 읽는 분들은 어떻게 ‘지켜지는 그라운드 룰’을 만들 수 있을지 고민해보시길 바랍니다.

툴 선택

기본적인 룰을 정하면 협업 툴을 선택해야 합니다. 도구는 팀의 방향성에 따라 정하기 나름이지만, 저희 팀에서 사용한 툴들과 활용 방법, 툴을 사용하며 느낀 점을 간략히 소개하겠습니다.

Notion

Autovertise 팀의 Notion 랜딩 페이지 저희 Autovertise 팀 Notion의 메인 페이지입니다. Agile 아래 부분은 소마 끝나고 팀 구조를 조정하며 추가된 부분입니다.

Notion은 대부분의 팀이 사용하게 될 것 같습니다. Notion은 협업의 중심이 된 툴이었습니다. 팀의 랜딩 페이지라고 할까요? 저희는 Notion을 통해 팀의 대부분의 정보를 탐색 가능하도록 설정해두었습니다.

  1. 팀과 멤버 정보, 그라운드 룰, 그 외 규칙 등 팀에 대한 정보를 정리했습니다.
  2. 회의록과 자료조사 보고서를 작성했습니다. 회의록과 자료조사의 경우 템플릿을 만들어두어 형식을 통일시켰습니다.
    • 꼭 문서에 태그를 달아 검색이 용이하도록 만드시길 바랍니다. 문서가 많이 쌓이는 후반부에는 검색이 어려워집니다.
  3. 추후에 기회가 되면 설명 드리겠지만 User Story 등 기획 관련 문서들이나 백엔드 API 명세와 같은 모두가 확인해야 하는 문서들 또한 Notion에 작성했습니다.
    • 백엔드 API 명세는 Swagger를 사용하여 작성했고, Notion에 해당 페이지로 링크를 걸어두었습니다.
  4. Jira나 Figma 같은 다른 툴로 이동할 수 있는 링크를 걸어두거나, 연동하여 Notion 내에서 정보를 확인할 수 있도록 설정해두기도 했습니다.
  5. 로고나 파비콘 등 디자인이 완료된 애셋들을 업로드 해두고 공유하기도 했습니다.
  6. 이후 프로젝트를 진행하며 이용 약관이나 개인정보 처리방침 등의 문서를 작성할 때에도 Notion을 사용했습니다.
    • Notion에 내용을 작성해둔 후 해당 페이지로 링크를 걸어두거나, NotionHero 등의 서비스를 사용하여 페이지 내에 임베드 했습니다.

Discord

온라인으로 작업하든 오프라인으로 작업하든 팀 메신저는 필요하죠. 저희는 Slack과 Discord 중 어떤 툴을 사용할지 고민했고, Slack의 경우 무료 플랜은 오래된 메시지의 확인이 불가능하기 때문에 소마 기간 후의 아카이빙을 위해 Discord를 선택했습니다. 저희는 Discord를 다음과 같은 방식으로 활용했습니다.

  1. 가벼운 소통 목적으로 채팅 채널을 사용했습니다. Notion에 올리는 문서들은 회의록이나 자료조사 보고서처럼 형식을 갖춘 문서들이었기에, 그 외의 간단한 정보들의 공유와 소통은 Discord 채팅 채널을 사용했습니다.
    • 멘토링 중 언급된 자료들이나 각자가 발견한 참고할만한 자료들을 공유하는 채널, 모두가 필수적으로 알아야 하는 내용들을 공유하는 공지사항 채널, 팀 캘린더와 연동하여 일정 알림등이 오는 팀 일정 채널, Jira에 Under Review 상태로 전환한 이슈들에 대해 리뷰를 요청하는 채널 등을 만들어 사용했습니다.
    • 팀 캘린더와의 연동은 약속을 잡아놓고 까먹는 경우가 많아서 리마인드를 자동화하기 위해 도입했습니다.
  2. 추후 온라인 진행에 대한 이야기를 따로 하게 될 것 같습니다만, 저희 팀의 협업은 대부분 온라인으로 진행되었습니다. 이 때 Core Time을 설정해서 해당 시간에는 모두가 Discord의 음성 채널에 들어와 있었고, 데일리 스크럼 역시 Discord에서 진행했습니다.
    • 데일리 스크럼의 정리본 역시 Discord 채널을 파서 매일 작성했습니다. 아무래도 Notion에 작성할 만큼 중요한 정보는 아니었으니까요.
  3. 서비스가 어느 정도 개발된 후, 고객의 문의사항이 들어오면 웹훅으로 Discord 채널에 알림이 오도록 설정했습니다.

Jira

첫 스프린트의 Jira 타임라인 저희 팀의 첫 스프린트의 Jira 타임라인입니다.

프로젝트 관리를 위해 Jira를 사용할지 Notion을 활용할지 고민이 있었습니다. 체계적으로 사용하기에는 Jira가 좋지만, 사실 세 명이서 프로젝트 진행하는 데에 그렇게 대단한 체계까지는 필요 없거든요. Jira를 도입해서 절약하는 의사소통보다 체계를 준수하는 오버헤드가 더 클 수도 있습니다. 멘토님도 소마 팀에서 처음에는 Jira 쓰다가 나중 가면 흐지부지 되는 경우가 부지기수라고 하시며 노션의 프로젝트 관리 기능으로 충분할 수 있다고 하셨습니다.

그럼에도 저희는 Jira를 사용했고, 저는 나름 만족스러웠습니다. 제가 느낀 Jira의 Notion 애자일 템플릿을 활용하는 것보다 나은 점은 다음과 같습니다. Notion의 애자일 템플릿을 써본 적이 없기에 부정확한 정보가 있을 수 있습니다.

  1. Git과의 연동이 수월합니다. Notion 템플릿을 사용하면 Git과 연동하여 관련된 브랜치와 PR 등을 보는 것이 어렵습니다. 차라리 Notion을 사용한다면 GitHub의 Project를 사용하는 것이 더 나을 수도 있습니다.
  2. 스프린트를 회고할 때 Jira의 스프린트 보고서가 도움이 되었습니다. 번다운 차트나 누적 흐름 보고서 등을 보며 스프린트 진행을 한 눈에 파악할 수 있었습니다. Jira의 보고서는 중간 및 최종 발표를 할 때 협업을 어필하는 참고자료로도 활용했습니다.

Jira의 스프린트 번다운 차트 저희 팀의 Jira 스프린트 번다운 차트입니다.

저희는 Jira를 사용하며 아래와 같은 이슈 템플릿을 사용했습니다. 이런 이슈 템플릿은 Notion에도 적용 가능하겠네요. 저희는 이 템플릿을 사용하며 꽤나 만족했어서, 여러분들도 한 번 적용해보시면 좋겠다 싶습니다.

Jira의 이슈 템플릿 현재 상태인 As-Is, 목표 결과물인 To-Be, 작업계획, 작업 결과로 구성된 이슈 템플릿을 사용했습니다.

Jira는 일장일단이 있습니다. Notion을 사용하는 것보다는 무겁긴 하지만 그만큼 체계적인 프로젝트 관리가 가능합니다. 저는 체계를 중시해서 만족했지만, 저희 팀 내에서도 호불호가 갈리는 부분이라 팀의 성격에 맞게 선택하시면 될 것 같습니다.

MS Office & Onedrive

팀원들과 공유가 필요한 문서들을 대부분 Notion으로 관리하긴 했지만, Word나 Powerpoint로 작성해야 하는 문서들도 있었습니다. 특히 소마에서 요구하는 발표 자료나 보고서같은 문서들은 Word 형식을 요구하는 경우가 많았습니다. 이런 문서들은 Google Docs 등으로 작성하면 나중에 형식이 꼬이는 경우가 많아서 처음부터 Word나 Powerpoint로 작성하는 것이 좋습니다.

저희는 팀장인 제가 Onedrive에 문서를 생성하고 다른 팀원들과 공유하여 작업하는 방식을 사용했습니다. 이 때 주의할 점은 대학생 분들의 경우 학교에서 발급받은 Onedrive 계정으로는 학교 외의 사람들과의 공유 및 공동작업이 불가능하다는 점입니다. 저의 경우는 개인 계정에 학생 할인을 받아 Onedrive를 사용했고, 이 경우 공유와 공동작업에 제약이 없었습니다.

저는 개인용 Onedrive를 사용했지만, 지금 와서 생각해보면 그냥 비즈니스용 Onedrive를 사용해도 좋았을 것 같습니다. 저야 로컬에도 파일이 있으니 큰 상관 없었지만 팀원들은 제가 공유한 파일에만 접근 가능하였고, 각자가 자유롭게 리소스 파일들을 업로드하고 접근하기는 어려웠습니다. 공유 드라이브를 파기는 했지만 로컬에 있는게 아니다보니 접근성이 떨어져 결국 활성화가 안 되었구요. 또 비즈니스용 Onedrive를 사용하면 각자 업무용 이메일을 생성할 수 있는데, 확실히 이러면 고객이나 기업들에 연락할 때 전문성이 있어보입니다. 비용은 인당 월 7.2달러 정도인데, 이런데에 쓰라고 소마에서 프로젝트 비용을 지원해주는 것이지요.

아이디어 정하기

본격적인 기획심의 준비에 들어가는 기획심의 1~2주 전까지는 아이디어가 결정되는 것이 좋습니다. 아이디어가 구체적인 기획안의 형태일 필요는 없습니다. 아이디어와 그 아이디어를 선정한 이유, 시장조사 정도만 진행되면 됩니다. 팀이 구성되고 아이디어가 결정되기까지 치열한 고민을 해야 합니다. 아래는 제가 생각하기에 그 고민에 있어서 생각하고 알아두면 좋은 것들입니다.

멘토링, 멘토링, 멘토링

팀매칭이 끝나도, 적어도 기획심의 끝날 때 까지는 쉬지 않고 멘토링이 열립니다. 기획심의 후에는 각자의 팀에 다들 집중하시느라 멘토링이 줄어들긴 하지만요. 이 시기에는 기술 멘토링들도 많이 열리지만, 가장 유용한 멘토링은 기획 멘토링입니다. 어짜피 기술 멘토링은 나중 가면 기억 잘 안 나는데, 기획 멘토링은 당장 소마에서 프로젝트를 진행하기 위한 아이디에이션에 직접적인 도움이 됩니다.

꼭 기획 멘토링으로 열린 멘토링에 참여하지 않더라도, 관련 분야의 멘토님에게 연락드려 멘토링 개설을 부탁드릴 수 있습니다. 이 경우 멘토님과 팀원들만 탐여하는 멘토링이 될 수 있는데, 이 경우 단체로 참여하는 멘토링보다 더 세세한 멘토링이 가능하여 많은 도움을 받을 수 있습니다. 실재로 저 역시 개인적으로 요청드려 진행한 멘토링에서 발견한 업계 표준안을 프로젝트 끝날 때까지 써먹었습니다.

어쨌든 멘토링을 최대한 활용하세요. 어디를 가도 소마의 멘토님들만큼 좋은 멘토님들을 만나기 힘듭니다. 이 분들의 조언을 최대한 활용하세요. 물론 멘토님들의 모든 말을 들을 필요는 없습니다. 뚝심 있게 밀고 나갈 것은 밀고 나가지만, 그 과정에서 멘토님들의 조언을 통해 아이디어를 다방면으로 검토하고 다시 생각해보는 것이 중요합니다.

목표와 KPI 정하기

소마든 다른 무언가든 결과를 내야하는 모든 활동에서 가장 중요한 것은 결과를 어떻게 측정할 것인가입니다. 이를 위해 KPI(Key Performance Indicator)를 정해야 합니다. KPI는 프로젝트의 목표를 달성하기 위해 어떤 성과를 내야 하는지를 정의하는 지표입니다. 즉, 성과를 무엇으로 계산할 것이냐를 결정하는 것이지요. KPI를 정하는 것은 프로젝트의 방향성을 정하는 것과 같습니다. 예를 들어 설명하자면 회사에서 진행하는 프로젝트의 KPI는 매출이 될 수 있습니다. 매출이 높아지면 회사는 성장하고, 매출이 낮아지면 회사는 위기에 처하게 되는 것이죠. KPI가 매출이라면 그 프로젝트의 방향은 매출을 높이는 방향으로 가야 합니다. 물론 KPI가 꼭 하나일 필요는 없습니다. 각자의 가중치를 가진 여러 KPI가 있을 수도 있습니다.

사실 목적은 팀을 구성할 때 미리 공유해야 하는 것입니다. 물론 이걸 의식하지 않더라도 같이 팀을 하기로 결정한 마음이 맞는 사람들이라면 소마에서의 목표도 비슷할 확률이 높겠죠. 그러나 목표는 두루뭉술하게 공유되는 것이 아니라 구체적으로 정의되어야 합니다. 이를 위해 KPI를 정하여 팀의 방향성을 확고히 하는 것이 좋습니다.

KPI는 팀의 목적과 방향에 알맞게 정하기 나릅입니다. 소마에서의 목표는 크게 보면 창업과 취업 두 가지이고, 조금 더 나누자면 인증을 추가한 세 가지입니다. 인증을 나눈 이유는 창업과 취업같이 배타적이지 않고 둘과 동시에 이룰 수 있는 것이긴 하지만, 인증을 목표로 한다면 창업과 취업만을 목표로 하는 것과는 조금 다른 방향을 가지게 되기 때문입니다. 제가 생각하는 각 목적에 따라 정해지는 팀의 방향성은 다음과 같습니다. 아래를 참고하여 KPI를 정해보세요.

창업

창업을 목표로 한다면, 그 무엇보다 중요한 것은 시장의 수요가 있는 프로젝트를 진행하는겁니다. 진지하게 창업을 목표로 한다면 소마에서의 평가고 뭐고 가장 중요한 것은 시장의 수요를 검증하는 것입니다. 즉, PMF(Product-Market Fit)를 검증하세요. 시장의 수요를 가장 직관적으로 나타내는 지표는 매출이죠. 그 후순위의 지표는 다운로드 수와 MAU 등 사용자 반응이 될 것입니다.

또 창업에 기술은 생각만큼 중요하지 않습니다. 개발할 생각 하지 말고 시장의 수요를 검증할 생각만 하세요. PMF를 검증하는 데에 기술이 생각보다 중요하지 않습니다. 수요를 검증하기 위해서는 작동하는 소프트웨어가 있을 필요도 없습니다. 그냥 랜딩페이지 하나 만들어서 광고 돌리고 반응 보세요. 그게 가장 빠르게 시장의 수요를 검증하는 방법입니다. 나머지 모든 것들은 수요가 검증 된 다음입니다.

소마와는 무관한 이야기이지만, 스타트업 씬에서 스타트업의 운명이 판가름 나는데에는 1년이면 충분합니다. 다시 말해 진지하게 창업을 하실거면 1년 내에 매출이 나와야 해요. 소마 지원 끝나는 것도 대충 1년이니, 그 후에 개인 돈 쓰면서 하기 싫으시다면 어떻게든 소마에서 매출을 내야 합니다. 예비창업패키지 등 정부지원사업이 있지만, 현실적으로 1년 내내 소마 하면서도 시장의 수요를 발굴 못한 프로젝트를 굳이 정부지원사업까지 받으면서 유지할 이유는 없습니다.

무엇보다 빨라야 합니다. 가장 좋은 것은 빠르게 성공하는 것이고, 그 다음으로 좋은 것은 빠르게 실패하고 버리는 것이고, 가장 나쁜 것은 어영부영하다가 성공도 실패도 못 하는 것입니다. 생각보다 빠르게 실패하기도 어려워요. 그러니 기능 개발에 힘쓰지 말고 수동으로 할 수 있는 것은 최대한 수동으로 떼우면서 빠르게 제품을 내세요.

취업

이 부분은 제가 잘 모릅니다. 제 목적은 창업과 인증이었고, 취업은 안중에도 없었습니다. 다른 분들을 보고 관찰한 것을 적지만은 걸러 들으세요.

사실 소마는 취업을 위한 프로그램은 전혀 아닙니다. 공식적으로는 취업 관련 멘토링을 금지하고도 있고 말이죠. 대놓고 취업 공부를 할 수는 없으니 결국 취업을 위한 프로젝트는 팀원 각자가 취업을 위해 필요한 기술을 적용할 수 있는 프로젝트가 됩니다.

이 경우 매출이나 사용자 반응은 크게 신경쓸 것이 없습니다. 그냥 취업에 필요한 기술을 사용할 프로젝트를 기획하고, 개발하고 운영하다가 하반기 공채 시즌에 지원서 내고 취업 준비하면 됩니다. 물론 사용자 반응이 있어서 라이브 유저가 있는 서비스를 운영한 경험이 있으면 취업에 큰 도움이 되겠지만, 현실적으로 원하는 기술도 도입하면서 실제 사용자를 소마 기간 내에 확보하는 것이 가능할지 모르겠습니다. 소마까지 와서 도입해보고 싶은 기술이면 도입하는데에 시간이 적게 걸리지도 않을거고 말이지요.

소마에서의 평가도 그렇게 중요하진 않아집니다. 어짜피 소마 기간 내에 취업을 대비하는 쪽으로 방향을 잡았다면 소마가 원하는 방향하고는 거리감이 좀 있는 방향이니까요. 인증 등 소마에서의 실적은 크게 바라기 어려운 상황이 됩니다. 물론 인증에 적합한 프로젝트가 우연히 취업에 도움이 되는 프로젝트가 될 수도 있지만, 그런 아이디어를 찾아내기가 쉽지는 않을겁니다.

물론 개인적으로는 소마 기간에는 소마 과정에 충실히 임하고, 취업 준비는 소마 활동 후에 진행하는 것이 좋다고 생각합니다. 하지만 개개인의 사정이 다르고, 각자가 소마를 이용하는 방법도 다를테니 제가 왈가왈부 할 수 있는 영역도 아니지요. 소마에서 공식적으로는 취업 관련 멘토링을 금지하고 있지만 팀 멘토링 진행하며 조언과 도움을 받는 것을 금지할 수는 없고 말이죠.

참고로 소마 기간 중 취업이 되면 연수생 자격이 취소되고 받았던 지원금들을 전부 뱉어내야 합니다. 그래도 원하는 곳에 취업하면 그게 개인에게는 더 좋은 선택일 수는 있지요. 취업에 있어서 제가 말씀 드릴 수 있는 것은 소마에서 취업을 준비하는 것이 무의미하지 않고, 그쪽으로도 충분히 큰 도움을 받는 것이 가능하다는 것입니다.

인증

소마가 보다 창업에 초점이 맞추어져 있는 사업이기 때문에 어느 정도는 창업을 목표로 하는 것과 비슷한 방향성을 가지게 됩니다. 다만 창업만을 생각하는 경우와 차이점이 발생하는 지점은 소마에서 좋은 평가를 받는 것이 중요해진다는 것입니다. 즉, 어느 정도 ‘보여주기 좋은’ 프로젝트를 진행하는 것이 좋습니다. 또한 소마 기간 내에 사용자를 확보하지 못하더라도 비전을 제대로 제시할 수 있다면 충분히 경쟁력 있는 프로젝트가 될 수 있습니다.

제가 진행한 프로젝트인 EasterAd는 말했듯 우수 프로젝트들 중 유일하게 사용자를 확보하지 못한 프로젝트였지만 15기 대표 프로젝트로 선정되었습니다. 저는 그 이유가 바로 방금 말한 두 가지 때문이라고 생각합니다. 게임 관련 프로젝트라는 점에서 다른 AI 등의 프로젝트들보다 시각적인 어필을 할 수 있었고, 또 시장 규모가 큰 애드테크 관련 프로젝트라는 점에서 사업성을 보여줄 수 있었기 때문입니다.

또 소마가 창업에 치중된 프로그램이긴 하지만 결국 목적은 고급 SW 인재 양성입니다. 사용자를 얼마나 모았느냐, 돈을 얼마나 벌었느냐 하는 것들이 중요하지 않은 것은 아니지만 소마 입장에서 가장 중요한 것은 프로젝트를 하면서 연수생이 얼마나 많은 발전을 이루었느냐입니다. 그러니 인증을 목표로 한다면 어느정도 색다른, 흔히 하는 프로젝트들은 아닌 프로젝트를 진행하는 것이 좋습니다. 예를 들자면 요즘 광고로 자주 나오는 뇌 비우고 할 수 있는 단순한 게임들을 만들어서 돈을 많이 번다고 해도, 소마에서 좋은 평가를 받기는 어렵습니다. 소마는 연수생들이 특별한 경험과 능력을 가진 인재로 발전하기를 원하니까요.

창업의 경우의 첨언: 실재하는 시장 발견하기

저는 인증과 창업을 염두에 두고 프로젝트를 진행했습니다. 사실 처음에는 말로는 인증은 상관 없고 창업을 하고싶다고 했는데, 하다보니 인증도 점점 욕심이 나더라구요. 프로젝트 주제가 주제인 만큼 인증도 노려볼만하다 싶던 것도 있고, 좋은 성과를 내면 어느정도 알아서 인증은 따라오겠지 싶기도 했습니다.

그런 입장에서 소마를 진행한 후, 지금 와서 생각해보면 실재하는 시장을 발견하는 것이 가장 중요하다 생각합니다. 특히 창업에 있어서 말이죠. 시장이 의미가 없다면 그를 타겟팅하는 제품도 의미가 없습니다. 첫째도 시장, 둘째도 시장입니다. 그러니 가치있는 시장을 발견하기 위해 시장 조사를 철저히 하는 것이 그 무엇보다 중요합니다.

이 조사라는 것이 인터넷을 뒤지는 것만을 의미하지 않습니다. 어느 정도 자료를 찾은 후에는 실제 사용자층을 직접 만나보는 것이 훨씬 좋습니다. 이 시리즈의 마지막 즈음에 몰아서 쓸 일이 있겠지만, 제가 소마 활동에서 가장 많이 반성하는 지점이 바로 이 부분입니다. 인터넷의 많은 자료들과 통계들을 보고 이 프로젝트가 가치있는 시장을 타겟팅하고 있다고 생각했지만, 프로젝트가 끝나고 사업화를 앞두어 회고해보니 너무나 많은 가정 위에서 프로젝트를 진행했다는 것을 깨달았습니다. 즉 수요가 충분히 검증되지 않은 상태에서 프로젝트를 진행했다는 것이죠.

수요가 검증되지 않았고 고객될 사람들을 직접 만나보지 않았으니 방향과 비전을 설득하기 어려워집니다. 팀 내에서도, 투자자 미팅에서도 말이죠. 사업화를 꿈꾸는 지금 와서는 다시 원점으로 돌아가 시장을 다시 조사하고, 실제 사용자들을 만나보고, 그들의 반응을 들어야 하는 상황입니다. 소마에서 미리 그렇게 했다면 고객들이 진짜 원하는 것이 무엇인지 파악하고, 그에 맞추어 최소한의 기능을 정의하고, 빠르게 제품을 출시하여 PMF를 검증하고 그 지표를 바탕으로 논리를 만들어 팀의 비전을 설득하는 것이 가능했을 것입니다. 모쪼록 창업을 꿈꾸시는 여러분들은 이 부분을 꼭 명심하시길 바랍니다.

기획심의

위에서 말한 부분들이 잘 진행되고 적절한 아이디어가 결정되었다면 기획 심의는 크게 어렵지 않습니다. 물론 한 30% 정도의 팀은 1차 기획심의에서 탈락하고 2차 기획심의를 진행하지만, 아이디어로 비전을 설득해낼 수만 있다면 큰 걱정은 안 해도 됩니다.

1차 기획심의에서 탈락하면 몇 주간의 피드백 반영 시간을 거친 후에 2차 기획심의를 진행합니다. 평가에 기획심의 점수가 포함되지는 않지만, 소마 본 연수 기간인 6개월이 생각보다 부족한 만큼 2차 기획심의까지 가게 되면 프로젝트 진행이 꽤나 불리해집니다. 그러니 인증을 목표로 한다면 1차 기획심의에서 통과하는 것을 목표로 하세요.

기획심의 준비는 발표 2주 전부터 준비하면 적절합니다. 15기는 PPT 없이 Word 보고서로만 팀별 발표 10분, Q&A 15분 정도 진행했는데, 이후 기수도 같은 방식으로 한다면 발표자료 만들 수고는 덜 해도 되겠지요. 다만 그 만큼 발표를 매끄럽게 진행할 수 있는 흐름으로 보고서를 작성하고, 발표 준비도 철저하게 해야합니다. 발표 듣다가 의문이 한번 생기면 그것만 계속 생각나서 발표 전달력이 매우 떨어집니다. 모든 부분에서 의문을 가지지 않고 매끄럽게 이해할 수 있도록 다듬기를 권합니다.

기획심의는 멘토님들이 잘 코칭을 해주시기에 제가 크게 적을 것이 없습니다. 다만 쫄지 말라는 말을 하고 싶습니다. 심사의원 분들은 대단하고 경력 많은 분들이지만, 각 팀의 아이디어가 타겟하는 특정 분야의 전문가는 아닙니다. 그러니 심사의원 분들의 질문과 의문에 겁 먹지 말고 아는대로 조사한 것들을 바탕으로 대답하세요. 그리고 발표를 준비할 때 해당 분야를 아예 모르는 사람도 이해할 수 있도록 발표를 준비하세요.

또 정말 하고 싶은 프로젝트가 있는데 기획심의에서 탈락했다고 해서 그를 꼭 포기할 필요는 없습니다. 꼭 하고 싶은 프로젝트라면 2차 기획심의까지 밀고 나가도 아무도 못 말립니다. 실제로 하고싶은 프로젝트가 소마의 방향성과 맞지 않아서, 소마에서의 성과는 신경 안 쓰고 그대로 밀고 나간 팀들도 있습니다. 그런다고 해서 프로젝트 진행비 사용이나 장학금 지급에 불이익이 있는 것은 아니니 꼭 하고 싶은 프로젝트라면 밀고 나가세요.

To Be Continued…

다음 글에서는 기획 심의 후 아이디어를 구체화하고, 초기 계획을 수립하는 과정을 다루겠습니다. 또 이 글에 대한 피드백이나 질문이 있다면 언제든지 메인 페이지의 이메일로 연락주세요. 감사합니다.