함께 만드는 모두의 플레이리스트 'Muzily' 탄생 스토리 (from Mash-up)

 

Muzily(뮤즐리)는 IT 연합 동아리인 Mash-up에서 디자이너와 개발자들이 협업해서 만든 프로젝트다. 카페, 바, 동아리, 팀플 상황 등 노래를 여러 사람들과 함께 듣는 상황에서 모두가 원하는 노래를 들을 수 있도록 플레이리스트를 공동으로 생성할 수 있는 웹 플랫폼이다. 이번 포스팅에서는 뮤즐리의 탄생 스토리를 기록하려고 한다. 우선 결과물인 웹사이트는 여기서 확인할 수 있다.

https://muzily.app/

Muzily | 함께 만드는 모두의 플레이리스트

 

 

---

1. GenZ, Playlist : 프로젝트 배경

요즘은 스트리밍 시대이다. Z세대에서 새로운 음악 감상 방식인 '플레이리스트'가 떠오르고 있다. 유튜브만 봐도 다양한 플레이리스트가 업로드 되어 있는 것을 볼 수 있다. 어떤 이는 늦여름에 어울리는 노래들을 모아놓기도 했고, 어떤 이는 비오늘 날에 어울리는 노래들을 모아놓기도 했다. 영상의 댓글에는 플레이리스트에 대한 자신의 감상을 남기거나 해당 플레이리스트 무드에 어울리는 곡을 추천하기도 한다. 이렇듯 사람들은 플레이리스트를 만들어 공유하고, 또 공유받고, 피드백하며 자신을 표현하고 싶어한다.

 

그렇다면 이런 플레이리스트, 함께 잘 만들고 있을까? 이 질문에서 우리의 프로젝트가 시작되었다.

 

 

 

---

2. 문제 너 딱 대! : 우리가 집중한 문제

여럿이서 음악을 함께 듣는 상황을 상상해보자. 음악을 선곡하고 재생하는 Host의 입장과, 플레이리스트를 공유받고 듣는 Geust의 입장이 있을 것이다. 우리는 각 입장을 생각해보고 문제를 정의하고자 하였다.

플레이리스트를 만들고 공유하는 사람의 입장에서는 여러가지 의견을 종합하기 어렵다는 문제가 있다. 요즘에는 카페나 술집에서도 손님들에게 신청곡을 받아서 음악을 틀어주는 곳이 많은데, 조사 결과 보통 카카오톡 오픈 채팅을 이용하고 있었다. 그렇지만 채팅 형식의 의견 수집은 잡담과 섞이기 쉽고 의견 확인 후 플레이리스트 추가까지 과정이 매번 번거롭다는 단점이 있다.

 

반대로 플레이리스트를 공유받고 듣는 사람의 입장은 어떨까?

플레이리스트에 대해 의견을 남길 소통 창구가 없어 스트레스를 받거나, 신청곡을 받는 경우에도 부끄러움을 많이 타는 사람들은 말을 꺼내기가 어렵다는 문제를 가지고 있었다.

 

우리는 "여러 상황에서 함께 플레이리스트를 만들며 모두가 만족할 수는 없을까?”라는 질문을 가지고, 앞서 발견한 문제들을 해결할 서비스를 만들고자 했다.

 

 

 

 

---

3. 모두가 듣고 싶은 노래를 즐길 수 있도록! : 우리만의 미션 설정

한 문장으로 정리된 미션은 팀이 나아갈 방향을 보여준다. 공동의 기준을 수립하지 않으면 나아가야 할 길을 잃을 수도 있다. 팀원 각자가 그리는 그림이 다르다면 프로젝트 내내 서로 다른 이야기를 하기 쉽상이다. 우리가 궁극적으로 이루고 싶은 문제, 우리가 하는 일의 가치를 담아 간단하고 짧은 문장으로 미션을 설정하였다.

 

모두가 듣고 싶은 노래를 즐길 수 있도록!

서비스의 활용 방향

우리는 이러한 미션과 서비스의 방향을 가지고 지난 4개월간 프로젝트를 진행했다.

 

---

4. 시작은 핵심만 간단하게 : MVP설정

사이드프로젝트를 진행하다보면 용두사미가 되기 쉬운 것 같다. 개인적인 의견으로, 초반에 프로젝트의 규모 및 개발 리소스를 예상하지 못하고 의욕만 가득한 채 이런 저런 기능을 넣어 완성도 높은 'SUPER APP'을 만들고 싶은 욕심이 프로젝트 마무리를 힘들게 만드는 가장 큰 요소 중 하나가 아닐까 싶다. 사이드프로젝트는 부가적인 기능은 덜어내고 간단하게, 핵심만, 작지만 1차 완성을 목표로 진행하는 것이 좋다고 생각한다.

 

 

우리팀이 MVP(Minimum Viable Product, 최소한의 기능을 구현한 제품)의 기능을 선정하기 위해 어떻게 했는지 공유하고자 한다. 우선 각자 우리 서비스에 필요하다고 생각하는 기능을 자유롭게 아이데이션하는 시간을 가졌다. 그후 토론을 통해 없으면 작동이 안되거나 서비스의 가치가 사라지는 기능을 'MVP', 없어도 작동하지만 있으면 매우 유용할 기능을 '2순위', 그 외 서비스의 매력을 올리기 위한 기능을 '3순위'로 분류하였다. 그리고 아이데이션을 하다보니 우선순위는 낮지만 기능이 너무 맘에 들어서 개발해보고 싶은 기능이 있어 '굿 아이디어'로 선정하였다.

<서비스를 핵심만 간단하게 만들기 위한 아이디어 분류>
- 없으면 작동이 안되거나 서비스의 가치가 사라지는 기능 : MVP
- 없어도 작동하지만 있으면 매우 유용할 기능 : 2순위
- 그 외 서비스의 매력을 올리기 위한 기능 : 3순위
- 2, 3순위 기능 중 너무 맘에 들어서 개발해보고 싶은 기능 : 굿 아이디어

팀원들과 아이데이션 및 토론을 거친 뮤즐리 초기 기능들

 

이중에서 MVP로 정한 기능만을 우선적으로 먼저 개발하고 'MVP → 굿 아이디어 → 2순위 → 3순위' 순서로 작업하기로 했다. 결과적으로 프로젝트 발표까지 MVP, 굿 아이디어를 모두 개발하고, 2순위 일부를 개발하여 반영하였다.

 

---

5. 놓친 사용성을 잡아라! : Usability Test

짧은 시간 안에 효과적으로 서비스의 사용성을 검증할 수 있는 방법은 아마 사용성 테스트(Usability Test, UT)가 아닐까 생각한다.

프로젝트 기간 안에 정신없이 서비스를 디자인하고 개발하다보면 사용성을 쉽게 놓칠 수 있다. 사용성연구 전문가 제이콥 닐슨(Jacob Nielsen)은 5명의 고객 인터뷰만으로도 사용성 문제의 85%를 얻어낼 수 있다는 것을 발견했으며, 더 많은 사람들을 인터뷰하더라도 그 효율성이 급격히 줄어든다고 주장했다. 이말은 즉, 단 5명의 인터뷰만 진행하면 빠르게 사용성을 체크할 수 있다는 뜻이다.

 

 

우리는 MVP기능이 완료된 직후에 4일간(2022.05.13~ 2022.05.16) 6명을 대상으로 사용성 테스트를 진행했으며 니즈&페인포인트를 종합하여 16가지의 발견점을 도출했다. 그리고 이를 기반으로 크게 4가지의 개선을 진행하였다. 

어피니티 다이어그램을 통한 UT 결과 분석

 

개발하면서 당연하다고 생각한 UI, 자연스럽다고 생각한 Flow에서 헤매는 사용자들을 보며 우리가 많은 것들을 놓치고 있었다는 것을 깨달을 수 있었으며 유용한 의견도 많이 얻을 수 있었다. 바쁜 개발 과정 속에서 사용성 테스트까지 진행하느라 모두 고군분투했는데, 결과적으로 사용성 테스트 이전의 서비스보다 좋은 방향으로 바뀐 것들이 많아서 좋은 선택이였다고 생각했다. 디자인팀에서 사용성 테스트가 필요하다고 주장했을 때, 긍정적으로 받아들여 테스트 직전까지 UI개발을 끝내준 개발자들에게 매우 고마웠다.

 

---

6. 마지막까지 영차영차~ : QA

사용성 테스트 진행 후 개선 UI까지 완료했다면 사실 디자이너 입장에서는 서비스 완성을 위해 더 작업할 것이 없다. 그렇다고 개발자들이 완성시켜줄 때까지 손놓고 있을 수 만은 없다. 우리 서비스는 웹 플랫폼이기 때문에 실시간으로 개발되는 상황을 확인하기 용이했다. 그래서 개발 상황을 보며 QA를 꼼꼼하게 진행했다. 

 

우리는 노션에서 칸반보드로 QA상황을 공유했다. To-do, In progress, Complete으로 나누어 QA상황을 조망하기 쉽도록 했으며, 작성할 때는 제보자와 담당 플랫폼을 설정하고 버그 제보인지, 개선 의견인지, 기획 상 확인이 필요한 사항인지 선택하도록 했다. 버그일 경우는 버그가 나타난 상황을 상세히 적었다.

Muzily의 QA 상황

 

이렇듯 노션을 통해 관리하니 따로 커뮤니케이션 없이도 진행 중인 상황을 확인할 수 있어 편했고 남은 이슈를 체크하기에도 간편했다. 최종 발표 직전까지 버그가 계속 발견되어 '이게.. 끝나긴 하나..?' 싶었는데 이슈를 체계적으로 관리한 덕분에 서비스를 완성할 수 있었다.

 

---

7. 두구두구 과연 결과는?! : 프로젝트 결과

4개월간 기획부터 개발까지 열심히 달려온 결과 만족스럽게 서비스를 론칭할 수 있었다.

그리고 프로젝트 최종 발표날 열심히 서비스를 어필한 결과! 많은 사람들이 우리 서비스를 좋게 평가해주어 1위를 수상할 수 있었다.

상금은 2차에 걸친 회식으로 반쯤 사용하였고, 나머지 반은 바베큐를 구워먹을 수 있는 숙소를 예약하는 데 사용했다. 가서 보드게임과 바베큐를 즐길 예정이다.

 

 

 

---

프로젝트 간단 회고

 

지난 몇번의 사이드프로젝트를 진행하면서 내가 아쉬웠던 점은 '표현하고 싶은 가치 / 기능은 많은데 이를 전달하기 벅차다'는 것이였다. 이번 프로젝트는 '핵심 기능만 잘 드러내자' 라는 개인적인 목표를 가지고 임했으며 서비스의 규모를 최대한 줄이고자 노력했다. (물론 기능은 단순했지만 디자인과 개발은 간단하지 않았다.) 서비스의 기능적인 면에서 규모를 많이 줄이고자 했던 것이 오히려 디자인&개발 퀄리티를 올릴 수 있었다고 생각한다. 결과적으로 '간단하지만 매력적인 서비스'를 만드는 데 어느정도 성공한 것 같아서 너무 좋은 경험이였고 많이 성장할 수 있었다.

 

 

아쉬웠던 점이라고 하면, 서비스 기획/정책에 대해서 글로써 정리하지 못한 채 디자인과 개발이 이루어지다보니 개발 과정에서 급하게 정해야 할 것들이 많아 커뮤니케이션이 어려웠다는 것이다. 다양한 case에 대해 화면흐름과 UX Writing, back단에서 처리되어야 하는 것들을 정리한 문서가 있었다면 더 수월하게 작업할 수 있었을 것이다. 그래서 앞으로 뮤즐리에 새로운 기능을 추가하고 개선시켜 나가면서 서비스 정책서를 만들 계획이다.

 

 

뮤즐리는 그동안 진행한 사이드프로젝트의 결과물 중에서도 가장 잘 사용중인 서비스라 애정이 많이 간다.

앞으로 2순위, 3순위 기능도 차차 추가하여 개선하고 싶다.

---

 

 

 

 

멋진 디자이너 및 개발자와 사이드프로젝트를 경험할 수 있는 Mash-up에 관심 있으신 분은 홈페이지에 들어가보길 바란다.

(이번 기수의 프로젝트가 종료되어 모집을 앞두고 있다)

https://mash-up.kr

Mash-up | IT 연합 동아리