MVP 모델로 개발해보기(1)
사이드 프로젝트 일기
들어가기 전에
프로젝트들을 많이 진행해왔었지만 제가 해보면서 느꼈던 생각들이나 과정들을 기록한 적이 없는 것 같아서 아쉬웠어요.(사실 있었지만 내용이 차마 올릴 수 없어서 삭제..) 그래서 지금부터라도! 일기처럼 써보려고 합니다. 이전에 했었던 프로젝트들도 정리하다 보면 "이 프로젝트에선 이렇게 했었지"라고 추억팔이(?)를 할 수 있을 것 같아서 시간이 지났지만, 조금씩 적어보려고 해요. 우연히 이 글을 보게 된다면 그냥 '아 이 사람은 이런 걸 이런 방식으로 해왔구나'라고 가볍게 읽어주시면 감사할 것 같습니다. :)
저는 사이드 프로젝트를 진행할 때마다 개인적으로 목표를 다르게 해왔었습니다. 예를 들면 이번 프로젝트에서는 커뮤니케이션을 하는 방법을 익히자! 라던가, 이번 프로젝트에서는 출시를 해보자! 같은 것을 말이죠. 그래서 이번 프로젝트에서 세웠던 가장 큰 목표(물론 동아리에서 자체적으로 세웠던 목표와 동일했어요.)는 "MVP로 빠르게 제작해서 데이터를 만나보자!"였습니다. 그렇기 때문에 이번엔 빠르게 가설을 세워서, 빠르게 검증하는 것에 초점을 두고 시작했죠.
MVP 방법론은 "Minimum Viable Product"를 뜻하는 약자로, "린 방법론"에 적용하기 적합한 개발 모델이라고 할 수 있습니다. 사실 매번 회사나 강의에서 린하게! MVP 모델로 개발합시다! 와 같은 말을 많이 들어왔는데 감이 잘 오지 않았어요. 특히나 회사에서 적용하고 있는 것이 과연 정말 린하게 하는 방법일까?라는 의구심을 떨치기 힘들었죠. 사실 지금도 이게 린인가..? 하는 고민이 들긴 합니다.
이러니 저러니 해도 부딪히면서 실패(?)도 해보고, 직접 해봐야 아는 거니까 이번 프로젝트의 방향이 굉장히 좋았다고 생각해요. 지금까지와는 다른 일정과 방식이 새롭기도 했고, 어떻게 해나가야 할지 감이 오질 않았지만 팀원들과 함께 의견을 나누면서 고민하는 과정이 재미있었거든요. 어쨌거나 일단 시작하기로 했습니다, 뭐든 해봐야 아는 거니까요!
1. 계획 세우고 시작하기
우선 저희들은 노션을 정리하는 것부터 시작했습니다. 파트별로 기록할 페이지와 프로젝트를 관리할 문서를 따로 제작해서 관리했죠. 회의록의 경우 주차별로 회의 내용을 정리해서 회고하는 방식으로 활용했는데, 정리는 제가 아닌 다른 분이 굉장히, 매우, 엄청! 잘해주셔서 많이 배웠습니다. 다만 스프린트의 경우 디자인 파트에서는 활용을 충분히 하지 못해서 아쉬움이 남았어요. 개발자분들은 스프린트를 굉장히 많이 활용하는 것을 보고 디자인을 하면서 다음엔 최대한 적용을 해보고 싶었습니다.
2. 주제 선정 과정과 아이디어 정리하기
사이드 프로젝트 팀 노션 아이디어 회의_0주 차_1차 회의팀원들의 생각이 다 달랐기에 처음 시작했던 것은 아이디어를 정리하는 것이었습니다. (아이디어는 개인 의견이기에 혹시 몰라서 블러 처리를 했습니다.) 정리를 위해서 회의록에 각자의 아이디어를 나열한 뒤 팀원들에게 설명을 하고 투표를 하는 방식을 택했어요. 이 과정에서 아이디어를 정리해서 말로 전달해야 하는 게 어렵다는 것을 느꼈습니다. 아이디어들은 큰 카테고리를 먼저 설명한 뒤 투표했었어요. 다양한 아이디어들이 나왔었고 해당 아이디어를 투표한 이유를 설명하면서 선택지를 줄여나갔습니다.
사이드 프로젝트 팀 노션 아이디어 회의_0 주자_2차 회의저희 조는 앞서 투표한 결과로 아이디어를 선정한 뒤 구체화했어요. 팀원들이 해당 아이디어에 대해서 생각나는 기능과 아이디어를 나열한 뒤 우선순위에 대한 투표를 진행하는 식으로 구체화를 했죠. 그 후 투표를 진행하면서 "팀원들이 같은 아이디어를 생각하더라도 대면이 아니다 보니 진행방향에 대해서는 생각하는 것이 다를 수 있구나"라는 점을 알게 되었어요. 그렇기에 저희는 각자 매운맛 서비스에 투표를 한 이유를 적어보면서 의견을 공유하고 적절한 합의 지점을 찾아갔습니다.
3. 가설 설정과 최소 기능 설계하기
그렇게 정해진 서비스는 "매운맛 음식 서비스를 만들자!"였습니다. 서비스와 관련된 많은 아이디어들이 나왔고 현실적인 부분들, 구현 과정에서의 어려움 등을 고려하여 우선순위를 나누었죠. 그다음 구체화된 아이디어들에서 우선적으로 빠르게 개발하고 디자인할 수 있는 부분을 정리하여 맞는 가설을 설정했습니다. 저희 조가 설정한 가설은 아래와 같죠.
[이번 프로젝트에서 검증해 볼 가설]
1. 사용자의 매운맛 레벨을 기반으로 매운 음식을 추천하면 사람들은 사용할 것이다.
2. 어떤 음식을 먹기 전, 사용자의 맵기 레벨을 기준으로 도전할 만 한지 알려준다면 사용할 것이다.
3. 자신의 맵기 레벨을 재미있게 표현하고, 공유할 수 있게 한다면 데이터 확보에 도움이 될 것이다.
가설을 검증하기 위해 필요한 기능들은 리스트업을 한 뒤 기능별로 나누어 정리했습니다. 저희들이 제공할 서비스의 주요 기능은 총 3가지로 아주 간단합니다. 첫 번째는 사용자의 매운맛 레벨을 측정하는 것이고, 두 번째는 특정 음식의 매운맛 정도를 사용자가 매운맛 레벨에 따라 평가하는 것이고, 마지막으로 세 번째는 사용자의 매운맛 레벨을 기반으로 매운 음식을 추천하는 것이죠.
전반적인 기획에 관한 회의는 1주 차가 오기 전에 마무리를 짓고, 각 직군별로 회의를 준비했어요. 저는 디자인팀에 속해있기에 이제부터는 디자인에 관한 내용들이 주를 이룰 것 같습니다. 디자인팀에서 가장 먼저 진행한 것은 디자인 콘셉트이었는데 어떤 콘셉트를 갖고 GUI를 표현하는지를 정해야 했죠. 이러한 GUI 콘셉트 디자인은 우리 조의 다른 디자이너분께서 맡아서 담당해주셨어요.
매운맛 레벨 테스트 서비스 유저 플로우그동안 화면을 크게 크게 잡아보고 있었습니다. 심리테스트를 여러 번 실행해보면서 페이지들을 경험했고, 가설을 검증하기 위한 사용자 플로우도 설정했죠. 플로우가 나와야 1차 가설을 검증할 수 있는 최소한의 페이지가 정리가 되기 때문이었습니다. 아까 위의 가설 중 첫 번째인 사용자의 매운맛 레벨을 측정하는 것을 검증하기 위해선 제일 먼저 기획과 디자인, 개발이 되어야 할 페이지는 테스트 페이지와 결과 페이지였죠.
사이드프로젝트 와이어프레임 1단계플로우를 짠 뒤 크게 화면의 구성을 배치하기 시작했습니다. 출시 전 프로토타입으로 조별 의견 공유 시간이 있었기에 대략적으로라도 디자인이 되어있어야 했기에 와이어프레임을 완벽하게 짜기보단 대략적으로 텍스트와 이미지를 올린 뒤 디자이너들끼리 상의해서 화면을 구성했습니다. 이후 디자인을 프레임 위에 얹혀보면서 정리했고 정기 모임 시간에 개발자분들과 함께 공유하면서 피드백을 받고 수정했습니다.
사이드프로젝트 와이어프레임 2단계와이어프레임이 와이어프레임 같지 않지만, 짧은 기간 내에 출시를 해야 했기에 빠른 개발을 위해 디자인도 컨셉과 일러스트 등을 동시에 작업하면서 화면을 잡아나간다는 것이 쉽지는 않았었습니다. 우선 앞에서 잡았던 와이어프레임을 기반으로 컬러와 디자인 컨셉 등을 녹여내었습니다. 2단계 와이어프레임에서는 대략적인 느낌과 컨셉을 조금이라도 표현할 수 있도록 구성했죠.
이번 사이드프로젝트에서의 목표는 크게 두 가지로 나눌 수 있습니다. 첫 번째는 MVP 모델을 빠르게 설정해서 빠르게 출시해볼 것이고, 두 번째는 MVP 모델의 데이터를 다뤄보는 것이죠. 저희는 우선 페이지를 나누어 빠르게 디자인한 후 개발자분들께 차례로 넘겨드렸고 이후 디자인이 수정될 경우 개발자분들께 물어가면서 아이디어를 정리하고 디자인에 적용했습니다. 이러한 과정들이 첫 번째 목표인 MVP 모델을 빠르게 설정해서 출시할 수 있었던 배경인 것 같아요.
출시 전의 사이드프로젝트 디자인위에 올린 사진들을 보시면 아시겠지만 처음 잡았던 디자인에서 출시 전의 디자인까지 비교해보면 비슷한데 다르게 디자인되어있다는 것을 확인할 수 있죠. 이렇게 빠르게 큰 틀을 잡고 이후에 세세한 디자인을 잡아가는 과정을 정리하면서 보니 눈에 보였습니다. 할 때만 하더라도 잘 되고 있는 건지 속으로 고민을 많이 했었으니까요. 그래도 이렇게 정리를 하다 보니 디자인의 변천 과정(?)이 보여서 기분이 참 새로웠습니다.
4. 수정하고 출시하기
프로토타입 버전의 디자인을 먼저 동아리에서 공유를 했습니다. 프로토타입 링크를 공유하고 사람들에게 경험해보게 한 뒤 피드백을 받는 시간이었죠. 저는 사이드 프로젝트를 진행하면서 이런 피드백을 받을 수 있는 과정이 없었기에 너무 신선했고 좋았습니다. 기간 내에 끝내야 한다는 마음도 들고, 최소한의 피드백을 받았으면 좋겠다! 와 같은 마음도 들어서 준비를 열심히 하게 되더라고요! 우선 저희들은 정해져 있는 템플릿을 활용해서 사이드 프로젝트의 중간 아이디어 발표를 진행했습니다.
사이드프로젝트 엘리베이터 피치 자료이 과정에서 받았던 피드백은 다양했는데, 매운 정도의 표현은 객관적인 것인지, 주관적인 것인지, 음식점마다 같은 메뉴여도 매운 정도가 다른 경우는 어떻게 할 것인지, 매운맛의 종류에도 고추맛이나 고추장 맛이나 마라 맛처럼 종류가 다양한데 어떻게 표현을 할 것인지, 매운 음식의 정보는 어떻게 수집할 것인지, 객관적인 지표로 표현을 한다면 어떻게 정립할 것인지 등이 주된 피드백들이었죠.
아이디어 공유 이후 수정된 디자인피드백은 주로 기획 쪽의 영역이라 내부적인 기준으로 만들어놨으며, 매운맛 레벨 테스트에 활용할 점수 알고리즘도 짜 놨는데 그 부분이 공유가 되지 않은 상황이었기에 나왔던 의견들이었죠. 그 외에 디자인적으로 추가되어야 할 사항이나 수정되어야 할 부분은 디자이너와 조원들과 함께 회의를 진행하여 수정했습니다. 이에 대한 내용들은 다음 편에서 정리하고 소개할 예정이에요!
5. 마무리 주저리
짧은 기간이지만 앞으로 출시할 프로젝트의 큰 틀을 잡는 과정이라 제일 많은 의견들이 오갔던 것 같습니다. 그 과정에서 MVP 모델을 정하는 것이 처음 경험해본 것이라 매우 재미가 있었고 공부가 많이 됐습니다. 간단한 가설이지만 그 가설을 검증할 수 있는 서비스 기획, 그리고 이후에 확장될 기능까지 고려한 기획 등 고민해야 할 부분이 생각했던 것보다 빡세다(?)는 것을 느꼈어요.
처음 해보는 방식이라 미숙하고 부족한 부분들도 많지만 이런 것들을 진행하면서 성장하는 거니까, 열심히 해보려고 합니다. 다만 이번 편의 주된 내용은 서비스를 소개하는 것이 아니라, 우리 조가 어떻게 MVP 모델을 개발하기 위해 노력했고, 어떤 방식으로 진행했고, 어떻게 서비스를 발전시키는지를 보여주려고 했기에 '그래서 네가 만든 서비스가 뭔데?'라고 생각하실 것 같아요.
오맵땡! 오늘 당신은 매운 게 땡긴다! (https://ohmebddeng.kr/)
저희들의 서비스는 "오늘 매운 게 땡긴다"가 컨셉인 오맵땡입니다. 링크를 달아놨으니 간단한 테스트라고 생각하시고 한번 참여해주시면 감사하겠습니다.
