퍼블리 읽어주는 청년 182 요즘 퍼블리에서 사이드 프로젝트 경험담을 콘텐츠로 종종 소개하여 관심있게 구독하고 있습니다. 본업은 회사에서 맡고 있는 직무가 있지만 회사 밖에서 내가 해보고 싶은 일
퍼블리 읽어주는 청년 182 요즘 퍼블리에서 사이드 프로젝트 경험담을 콘텐츠로 종종 소개하여 관심있게 구독하고 있습니다. 본업은 회사에서 맡고 있는 직무가 있지만 회사 밖에서 내가 해보고 싶은 일을 도전해 보는 가치있는 경험인 것 같습니다. 이번 글을 보면서 저도 사이드 프로젝트를 해보고 싶은 작은 욕심이 생겼는데요. 팀을 어떤 채널로 모집하고 프로젝트를 어떻게 구체화시켜 가는지 정보를 얻을 수 있습니다 :) 회사 밖 팀원들과 만든 앱, '쉐어워크' 런칭 경험담 저자 현승민 우리가 자주 쓰는 서비스들은 우리가 불편해하고 귀찮아 하는 일들을 대신 해결해 줍니다. 검색 포털 서비스는 우리가 모르는 모든 답을 알려주고, 이커머스는 우리가 필요한 상품들을 다음 날 집 앞까지 배송해 주죠. 이처럼 유저가 불편해하는 포인트에 눈길을 돌리면 좋은 아이디어를 떠올릴 수 있습니다. 이 세 가지 필요성을 바탕으로 지도 기반의 구인 구직 서비스 '쉐어워크'를 만들기로 결심했습니다. 이처럼 자신이 겪은 불편함에서 아이디어의 힌트를 얻을 수 있습니다. 또한 나만의 불편함이 아니라 모두가 겪고 있는 불편함이라면 시장에서 살아남을 가능성이 더 높아지겠죠. 첫째, 수년이 흘렀음에도 불구하고, 현업에서조차 구인 구직 과정에서 파생되는 불편함을 해결하지 못했다는 점 둘째, 아직 시장을 장악하고 있는 1인자가 없다는 점 셋째, 이러한 불편함을 기술로 해결할 수 있다는 점 문득 '사이드 프로젝트에 관심 있는 사람들이 모여 있는 곳을 찾아봐야겠다'라는 생각이 들었습니다. 그리고 페이스북에서 한 광고를 보게 됐어요. 3개월 안에 원하는 서비스를 런칭하게 해준다는 교육 프로그램 '멋쟁이사자처럼 직장인'이었습니다 가장 먼저 '서비스가 공략해야 할 타깃 시장'을 선정해야 합니다. 투자자들이 알고 싶어하는 것은 이 서비스가 유저의 어떤 문제점을 해결해 줄 것인지, 그리고 그 시장이 얼마나 빠르게 성장하고 있느냐입니다. 따라서 기획자는 시장의 정보를 꾸준히 수집하고 인사이트를 찾아내야 합니다. 유저를 특정하기 위해 '유저 인터뷰'라는 방법을 선택했습니다. 우선 알바천국, 알바몬, 워크넷에서 공고 수가 가장 많은 지역을 두 곳 선정하고, 구인을 진행 중인 사장님들을 대상으로 최종 대상자를 선발했습니다. 인터뷰 대상자를 세 개의 그룹으로 분리하고, 각 그룹별로 맞춤형 질문을 준비했습니다. 1) 쉐어워크를 쓸 의향이 있는 유저: 우리 서비스에 꼭 필요하거나 보완해야 하는 기능은 무엇인가요? 2) 경쟁 서비스를 사용하고 있는 유저: 경쟁 서비스를 사용하는 구체적인 이유가 무엇인가요? 그렇다면 우리 서비스가 경쟁력이 있다고 생각하시나요? 3) 관련 서비스를 전혀 사용하지 않는 유저: 우리 서비스가 해결해줬으면 하는 문제점 혹은 불편사항은 무엇인가요? 유저 인터뷰의 장점은 유저의 목소리를 가까이에서 들을 수 있다는 점도 있지만, 팀원들 간에 '이 기능이 왜 필요한지'를 보다 직관적으로 이해할 수 있다는 점도 있습니다. 그 덕분에 개발, 디자인, 기획 모두 동일 선상에서 서비스를 바라보고, 서비스 방향성까지 좀 더 명확하게 잡을 수 있었습니다. 모든 기능에 공통적으로 적용할 제1원칙이 있었습니다. 그건 바로 '유저가 5번 클릭 이내에 원하는 결과를 얻어야 한다'였습니다. 필수 기능을 정의할 때, 유의할 점이 두 가지 있는데요. 첫째, 경험과 직관만으로 선정하지 말 것. 개인적인 경험에 의존해서 기능을 선별하면 유저에게 선택받지 못할 확률이 높아집니다. 둘째, 서비스 스펙에 너무 많은 제한을 두지 말 것. 한 번도 사용해 본 적 없는 기술일지라도 스터디를 통해 충분히 개발할 수 있기 때문에 최대한 가능성을 열어 두고 접근하시길 바랍니다. 참고로 쉐어워크의 기능들 역시 전부 스터디를 통해 구현했답니다. 테스트할 수 있을 정도로 개발이 마무리되면 각 OS별로 개발자 인증을 통해 스토어에 앱을 등록할 수 있습니다. 이때 유의할 점은 실제 인터뷰를 진행한 분들을 대상으로 우선적으로 배포하고 사용을 부탁하는 것입니다. 배포 전에 아무리 꼼꼼하게 점검한다고 해도 예상치 못한 에러는 나타날 수밖에 없습니다. 따라서 좀 더 안전하게 테스트를 진행하려면 아예 새로운 유저보다는 우리 서비스를 어느 정도 이해하고 있는 유저를 활용하는 게 좋습니다. 초기 문제점들을 수정한 이후부터는 유저들의 판단에 따라 서비스 가치가 결정됩니다. 이때, 서비스의 성장세를 가늠할 수 있는 지표가 바로 KPI인데요. KPI를 통해 서비스의 현재 상황을 점검하고, 앞으로 어떤 결정을 내려야 하는지를 알 수 있습니다. 처음부터 촘촘하게 기획하는 것보다는 라이트한 기능을 배포해서 유저 반응을 확인하고, 이 데이터를 기반으로 유지 보수하는 방식이 좀 더 효과적이라는 교훈까지 얻을 수 있었습니다.