새로운 도전 – 앱 서비스 기획, 협업, 출시까지
STORM 기획자 & 프로덕트 매니저(PM) 회고
수기와 회고는 다르다. 회고는 일부러 며칠씩 미뤄둔다. 당일날 글을 적다 보면 그날의 여운은 고스란히 녹일 수 있겠지만, 스스로를 객관화하여 돌이켜보기는 어렵기 때문이다.
대학생 연합 IT 벤처 창업 동아리 SOPT의 자체 해커톤인 앱잼(AppJam)에 이어 약 한 달간의 추가 작업을 끝으로 실시간 브레인스토밍 협업 툴 – STORM 앱을 출시하게 되었다. 앱잼 데모데이 발표가 끝나고 집에 돌아오자마자 페이스북에 장문의 글을 올렸었지만, 이는 그저 그간의 벅찬 감정을 담아낸 수기에 불과했다. 그땐 우리 팀과 나 자신이 대견하고 동시에 모두에게 미안하면서 고마운 마음뿐이었다.
SOPT 앱잼이 끝난 직후 페이스북 개인 계정에 올린 후기 글5월 초, 앱 서비스 아이디어를 처음으로 떠올려 기획안을 발전시키고 팀원들과 함께 이를 실현해내기까지 – 이번 회고 글에서는 STORM 서비스를 만들어가면서 기획자로서, 팀을 이끄는 리더로서, 그리고 서비스를 총괄하는 프로덕트 매니저(PM)로서 스스로가 성장한 과정을 짚어보려 한다.
1. 문제 도출과 기획의 시작
아이디에이션 번개 워크샵 – 함께 고민하고 생각을 나누는 사람들STORM에 대한 인사이트는 SOPT 내 몇몇 기획 파트원들과 함께 진행한 '번개 워크샵'에서 얻게 되었다. 아이디어가 도저히 떠오르지 않거나 확신이 없는 친구들이 모여 처음으로 함께 생각을 나눈 자리였다. 메모지에 각자 떠올린 아이디어와 피드백을 적어 벽에 붙이며 생각을 나누는 과정에서 확신을 찾아가는 친구들을 지켜보며, 조금은 아이러니하게도 '아이디어가 떠오르지 않는다'라는 문제 현상을 도출하게 되었다.
본격적으로 문제의 본질에 집중하기 시작하면서는 무엇보다 나 자신이 직접 쓸 수 있는 앱을 만들고 싶었다. '나'라는 타겟, 혹은 나와 같은 사용자가 진정으로 공감하며 사용할 수 있는 앱을 기획하고자 했다. 서비스 아이디어를 발전시키는 과정에서는 나의 이전 경험을 바탕으로 고민해보았다. 휴학 전 학교에서 Design Innovation 수업과 활동들을 통해 몸소 익힌 아이디어 브레인스토밍 방식과 작년 여름 참여한 도쿄 이노베이션 프로그램(TISP 2019)에서의 경험을 적용했다. 문제 현상 자체는 '번개 워크샵'에서 발견하였으나, 결국 STORM은 나의 오랜 경험과 생각에서부터 뿌리내린 서비스였던 것이다.
발견한 문제 현상을 바탕으로 문제의 본질을 고민하며 끄적인 낙서애초에 나 자신의 경험에서 비롯된 가설이다 보니 이를 검증하는 과정이 어렵게 느껴졌다. 우선 '아이디어'라는 소재 자체가 워낙 광범위하고 누구에게나 해당되는 사항이다 보니 타겟을 명확하게 정의하기 어려웠다. 사용자 프로필 및 가치 맵 등을 통해 서비스의 적합성을 판단하고 페르소나(Persona)를 설정하는 과정을 거쳐 타겟을 'young creator team'이라고 정의할 수 있었으나, 여전히 명확하게 와닿지는 않았다. 이어 4명의 사람들을 인터뷰하고 100명이 넘는 사람들을 설문 조사하며 기획안 자체에는 어느 정도 확신을 갖게 되었지만, 아무래도 해커톤 특성상 단기간에 검증을 준비하다 보니 대상자 선정이나 진행 방식에 있어서 한계가 있었다. 그럼에도 그 과정에서 스스로 미리 답을 정해두고 결론을 도출하지 말자고 스스로를 끊임없이 상기시켰다. 다행히도 처음 기획안을 공개했을 때 많은 사람들이 내가 도출한 문제점에 공감해주었다.
참고 문헌을 바탕으로 도출해낸 인사이트도출해낸 아이디에이션/브레인스토밍의 본질적인 문제점을 고려해 STORM 앱 서비스의 핵심 기능 구상을 마쳤다. 이후 기능의 구체화 및 세분화를 위해 관련 글과 논문 자료도 참고하였다. 브레인스토밍의 근원 및 정의부터 아이디어 회의를 위한 세부 규칙들까지 세세하게 찾아보며 기획 가설을 여러 차례 검증하고자 했다. 이 과정에서는 주로 영문 원서와 논문을 참고했으며, 여기서 도출해낸 인사이트는 STORM 기능의 타당성을 검증하고 기획안을 다져나가는데 활용하였다.
유학 경험을 바탕으로 자료들을 찾다 보니 의도치 않게 해외 사례들 위주로 참고하게 되었는데, 내가 정의한 국내 타겟들과는 어쩌면 어긋날 수도 있겠다 싶은 생각이 든다. 이제 와서 생각해보니 문제점 도출은 타겟에 집중해 들여다봤지만, 솔루션과 그에 대한 검증은 타겟 안에서가 아닌 외부에서 찾으려 했던 것 같다. 이미 검증된 외부 아이디에이션 과정을 벤치마킹하기보다 직접 발로 뛰며 스타트업이나 학생들 사이에서 아이디어 회의가 어떻게 이루어지는지 심도 있게 살펴봤어야 했는데, 앱잼 특성상 시간적 여유가 없어 그러지 못했다는 점은 정말 아쉽다.
기획 경선 발표 자료 중 일부 (사용 일러스트 출처: http://rammojammo.com/)2. 팀, 앱잼, 그리고 협업
팀 빌딩, 즉 팀을 구성하는 단계에서 STORM의 기획안은 그다지 인기가 많은 편이 아니었다. 서비스 아이디어 자체는 신선했을지언정, 디자이너들은 초기에 내가 임의로 진행해둔 STORM 브랜딩 방식이 그들을 제한한다고 느꼈고, 개발자들 입장에서는 게이미피케이션 형태의 실시간 통신이나 그림판 등 까다로운 기능들을 구현해야 한다는 점이 부담으로 다가왔을 것이다. 하물며 기획자로서 생전 처음 만들어본 와이어프레임이나 기능 명세서는 한눈에 이해하기 어려웠고, 오히려 그들을 혼란스럽게 했다. 가설 검증에 치중한 나머지 팀 빌딩이나 실제 서비스 구현에 필요한 자료들은 신경 써서 준비하지 못한 탓이었다.
팀 구성에 있어서 디자인/개발 실력이나 경험의 유무, 성격 및 성향 등의 제약이나 요건을 걸어두지는 않았다. STORM이라는 서비스를 함께 발전시키고 싶어 하는 디자이너나 개발자를 제한하고 싶지 않았기 때문이다. 누가 들어오든 그들과만 함께할 수 있는 특별한 경험을 만들어 즐기고 싶었다. 팀원 한 명 한 명의 역할이나 기대치에 집중하기보다, 조금 더 포괄적인 의미의 팀원 상이자 팀의 핵심 가치를 구상해 내가 추구하는 팀의 모습을 그려 보였다.
팀 빌딩 이전에 미리 준비해둔 세 가지 팀원 상이자 핵심 가치
합숙 기간 중 진행한 머리말랑토크위의 팀원 상에 해당하는 디자이너나 개발자라면 누구나 환영하는 대신, 적어도 STORM 팀과 함께할 사람들만은 우리가 만들어가는 서비스에 진정으로 공감하기를 원했다. 그래서 앱잼 합숙을 시작하게 되면 팀만의 자체 브레인스토밍 활동인 '머리말랑토크'를 정기적으로 진행하고자 했다. 포스트잇 메모지와 펜, 타이머를 사용해 짧은 시간 동안 최대한 많이 아이디어를 그려낸 뒤 함께 의견을 나누며 발전시키는 활동으로, STORM 서비스의 가장 핵심적인 기능인 '프로젝트 라운드 진행 과정' 또한 이러한 방식을 기반으로 기획한 것이었다. 실제로 여러 워크샵과 개인 프로젝트를 통해 효과를 체감했어서 STORM의 팀원들도 이를 직접 경험해보길 원했는데, 합숙 기간 이 활동을 몇 번 진행해본 결과 여러 팀원들로부터 긍정적인 피드백을 들을 수 있었다. 머리말랑토크는 작업 중 머리가 지끈해지기 시작할 오후 시간에 '베개와 유리병의 공통점 찾기', '완전히 새로운 마스크 디자인' 등의 가벼운 주제로 진행했다. 서비스를 직간접적으로 체험해볼 수 있었을 뿐 아니라, 팀원들과 유쾌한 대화를 나누며 관계를 돈독히 할 수 있어 더욱 의미 있었다.
첫 전체 회의에서 진행한 아이스 브레이킹3주간의 앱잼 중 첫째 주는 팀원 모두가 한 곳에 모여 함께 작업하기보다 파트별로 모여 협업하는 방식으로 진행했다. 팀원 중에는 같은 파트임에도 서로 초면인 사람들이 여럿 있었는데, 팀 내 소통을 중요시한 만큼 첫날에는 모두 모여 서로를 알아가는 아이스 브레이킹의 시간을 가졌다. 포스트잇 메모지를 활용해 이번 앱잼에서 기대하는 바와 얻고 싶은 것, 자신 있는 것들을 공유하며 얘기를 나누는 식이었다. 이후부터는 중간 점검을 위한 전체 회의를 제외하고 각 파트끼리 편한 곳에 모여 앱 기능 구현법을 익히고 개발 기반을 다지는 식으로 모임을 진행하였다. PM으로서 나는 서버-클라이언트 개발자와 디자이너들이 모여있는 곳을 번갈아 찾아가며 필요한 부분을 설명하고 도움을 주고받는 식으로 앱잼 첫 주를 보냈다.
2주 차에서 3주 차, 본격적으로 합숙을 시작하면서는 팀 내 문화를 견고히 하고자 했다. 두 명의 TI(Team Improvement, PM과 함께 서비스 발전과 팀의 조화를 돕는 역할의 기획자)와 팀의 핵심 가치를 우리만의 문화이자 브랜딩으로 구체화해두었다. 앞서 소개한 머리말랑토크와 더불어 팀의 자체 스크럼이자 매일의 회고인 High's and Low's와 서로를 더 끈끈하게 해 줄 마니또 등을 통해 팀 내 유대감을 다졌고, 매일 목표한 바와 성장 과정을 기록하는 데일리 챌린지 등의 활동을 통해 STORM 팀만의 경험을 만들어냈다. 합숙 기간 이의 운영은 두 TI들이 맡아 진행해주었는데, 각각의 룰에 대한 소개 및 운영 방식은 TI 중 한 명인 나연 언니가 브런치에 잘 정리해주었다. 아래 링크 참고!
팀의 전반적인 운영 방식이나 문화는 팀빌딩 전후로 꼼꼼히 준비했지만, PM으로서 팀 내 소통을 조율하는 역할은 잘 해내지 못했다. 앱잼 기간 동안 대내외로 자잘하게 신경 써야 할 것들이 많아서였을까. 정작 중요한 기획자-디자이너-개발자들 간의 소통은 간과한 채 미리 만들어 둔 기획 문서에만 의존했다. 새로운 기능이 추가되거나 변경 사항이 생길 때마다 각 파트 팀원들에게 구두로 전달해준 뒤 기능 명세서만 수정해뒀을 뿐, 이를 따로 정리해 팀에게 공유할 생각은 하지 못했다. 그렇다 보니 서비스의 기능을 총괄하는 나로서도 변경 사항을 헷갈리기 시작했고, 이에 팀원들의 피로도도 높아졌을 뿐만 아니라 팀원마다 서로 다르게 알고 있는 부분들이 늘어가기 시작했다. 소통과 협업의 중심을 맡았던 입장에서 이를 잘 조율하지 못했다는 것이 개인적으로 가장 아쉬우면서 후회스러운 부분이다.
앱잼 당시 준비한 STORM 소개 영상 (출시를 앞두고 '플랫폼' 대신 '툴'이라는 명칭으로 수정되었다.)
3. 서비스 및 팀 정렬부터 실제 출시까지
앱잼 데모데이 발표와 시상을 마치고!데모데이 발표는 우여곡절 끝에 잘 마무리했지만, 실제 출시를 목표로 한다면 그동안의 협업 방식은 결코 효율적이지 않았다. 스스로 자책도 하고 발전 방안도 강구하며 찾은 방법은 바로 팀원들의 서비스와 팀에 대한 이해도를 다시금 동일화시켜 놓는 것, 즉 Alignment였다.
먼저 우리 팀이 추구하는 가치와 방향을 문서화해 팀원들과 공유했다. 우리가 왜 이 일을 하고 있는지, 이를 통해 세상에 어떤 변화를 만들어내고 싶은지, 앞으로 서비스를 어떻게 운영할 것인지, 또 앱잼 이후 우리는 어떻게 협업할 것인지 상세히 적어놓은 문서이다. 단어 하나하나 뜯어가며 앱잼 시작 전 준비한 기획안보다 더욱 꼼꼼하고 상세하게 정리해 팀원들이 STORM의 추구 방향을 명확히 이해하도록 했다.
팀의 미션, 비전, 전략, 문화 등을 정리한 STORM Alignment 문서다음은 STORM 앱 기능에 대한 Alignment였다. 앱잼 기간 합숙 중에는 기능이나 구현 범위가 헷갈릴 때마다 즉시 주변 팀원들에게 물어볼 수 있어 피드백을 주고받기 수월했다. 하지만 더는 합숙을 하지 않는 상황에서는 누구나 언제든 참고할 수 있는 '백과사전'과 같은 문서가 필요했다. 이에 그간 작업해온 기능들을 스토리보드(Storyboard)로 정리해 팀원들과 맞추어 보았다. 출시를 앞둔 상황에서 스토리보드를 작성하기엔 사실 늦은 감이 있지만, 한편으로는 이미 어느 정도 개발을 마친 뒤라 기능을 한꺼번에 정리하는 동시에 혹시라도 놓친 부분은 없는지 세세하게 점검할 수 있어 좋았다. 번거롭지만 분명 필요한 단계였다.
앱 기능을 정리한 스토리보드 중 일부앱잼 중 개인적으로 가장 아쉬워한 부분이었던 '팀원과의 소통'을 위해서도 더욱 노력했다. 합숙 기간 팀원들의 개인 회고를 담당했던 TI들과는 달리, PM인 나에게는 팀원 한 명 한 명과 제대로 얘기를 나눌 기회가 많지 않았다. 개개인과의 소통보다 더 큰 단에서의 소통, 즉 파트별, 혹은 팀 전체의 소통에 초점을 맞추었기 때문이다. 합숙이 끝난 시점에서는 대부분의 작업이 각자의 자리에서 이루어지는 만큼 팀원들과의 더욱 원활한 소통을 위한 1:1 개인 회고가 필수적이라고 생각했다. 이에 밤마다 서너 명의 팀원들과 한 명씩 전화 통화를 하며 그들의 생각과 요구사항을 이해했다. 처음에는 팀원 당 30분 안팎으로 회고를 진행하기로 계획했지만, 서로 깊은 생각들과 고충을 나누다 보니 한 시간씩은 훌쩍 넘기게 되었다. 회고 중 나눈 이야기는 팀원과 PM인 나만 볼 수 있는 구글 문서로 바로 정리해 언제든 다시 읽어볼 수 있도록 했다. 1:1 개인 회고 이후로 팀원들을 더 잘 이해할 수 있었고, 그 덕에 앱잼이 끝난 지금까지도 그들과의 관계를 끈끈하게 이어갈 수 있어 진심으로 감사하다.
1:1 개인 회고 질문 리스트기능 구현이 거의 다 끝난 막바지에는 칸반 보드를 활용해 우리만의 Quality Assurance(QA)를 진행하였다. 기획 및 팀 매니징과 더불어 처음 접한 테스팅 과정인지라 막막하기도 했고, 실시간 통신이 즉각적으로 이루어지는 만큼 고려해야 할 상황이 많아 골치가 아팠지만, STORM 자체가 가볍고 재미있게 사용할 수 있는 서비스이다 보니 오히려 팀원들과 새벽마다 즐겁게 테스트할 수 있었던 것 같다. 안드로이드/아이폰 기종별로, 또 사용성 케이스별로 데모 버전의 앱을 테스트해보며 버그를 잡아냈는데, 이때 각자 찾은 버그들은 바로바로 카톡방에 공유하도록 하였다. 버그 수정에 여념이 없던 개발자들을 위해 카톡방에 모인 버그 내용을 모아 칸반 보드로 정리했고, 이에 개발자들은 버그가 수정되는 즉시 칸반 보드에 진행 상황을 업데이트해주었다.
칸반 보드를 활용한 앱 테스팅
험난했던 새벽 뚝섬 앱 등록 현장ㅋㅋㅋ코로나19로 마땅히 모일 수 있는 장소도 없고, 모이더라도 내내 마스크를 쓰고 대화해야 해서 여간 불편한 점이 한둘이 아니었다. 카페들도 일찌감치 문을 닫다 보니, 스토어에 앱을 등록하는 과정도 늦은 새벽에 공원 한복판에서 진행할 수밖에 없었다. 하필이면 조금씩 비도 오고 바람도 거칠게 불던 밤이었다. 팀에 앱 출시 경험이 있는 개발자는 한두 명 있었어도 직접 앱을 등록해본 경험은 얼마 없던지라 우리는 이틀씩이나 비바람을 맞으며 허둥지둥거려야 했다. 심사 요청 버튼을 누르는 순간까지도 '이게 맞나?' 싶었지만, 두어 달간 팀원 모두가 열심히 달려준 덕분에 그 까다롭다는 앱 심사도 단번에 통과할 수 있었다. 나를 포함한 팀원 대다수가 직접 만든 앱을 출시하는 일은 처음이었기에, 이는 우리 모두에게 절대 잊을 수 없는 특별한 경험으로 남아있다. 9월 초, 그렇게 우리의 앱 서비스 STORM은 세상의 빛을 보게 되었다.
돌이켜보면 참 신기하다. 처음 STORM 기획을 결심했을 때부터 가설 검증부터 기획 산출물 작성법까지 어쩜 모르는 것 투성이었고, 스스로의 무지함에 여러 번 좌절도 했었는데, 결국 여기까지 오게 되었다.
서비스 기획은 첫 도전이었던 만큼 어설프고 부족한 점이 정말 많았다. 앱 출시를 마친 지 한참이 지난 지금까지도 괜한 아쉬움에 밤마다 이불을 차 댈 정도이다. 글의 말머리에서 잠시 얘기했듯, 앱잼이 끝나자마자 감정을 눌러 담아 적은 후기 글과 달리 이번 회고 글은 특히 더 나중으로 미뤄버린 이유이기도 하다. 스스로 부끄러웠달까.
하여간 해냈다. 서비스 기획과 관련해 아는 게 없어 실없는 농담이나 치던 나는 처음으로 내 기획안을 여러 방식으로 증명해 보였고, 처음으로 내가 완전히 모르는 분야의 사람들과 협업해보았으며, 처음으로 나와 팀의 노력의 결과물을 세상에 내보였다.
사용자에게 가치를 줄 수 있는 서비스를 직접 기획하고 팀원들과 만들어냈다는 사실에 너무나 감격스럽다. 그저 경험에 그쳐 안일해져서는 안 되고, 또 아직도 부족한 점이 너무나 많지만, 나도 모르는 새 만들어버린 '컴포트 존'에서 벗어나 한 뼘 더 성장할 수 있었던 과정이었음은 분명하다.
