디스턴스 첫 MVP 개발 이야기

안녕하세요.

팀 디스턴스의 프론트엔드 개발자이자 팀 리드를 맡고 있는 노주영입니다.

 

오늘은 저희가 개발중인 서비스 디스턴스의 팀 빌딩 과정부터 최소 기능 제품(MVP)을 완성하기까지의 과정을 말씀드리고자 합니다. 팀 디스턴스의 시작은 3월부터였는데요, 프로젝트 개발에 치여 글쓰기를 미루다가 이제야 쓰게 되네요 ㅎㅎ

 

저희 팀의 모든 과정을 기록하고자 세세한 부분까지 작성했습니다. 재밌게 읽어주세요~

 

디스턴스 시작 계기

웹 프론트엔드 개발자로 취업을 준비하는 저는 취업 전 다음 세가지 경험을 얻고자 했습니다.

• 실제 유저가 단 한 명이라도 있는 서비스 개발
• 그 유저로부터 받은 피드백을 바탕으로 사용자 경험을 개선
• (유저가 많아진다면) 대규모 유저 트래픽 핸들링

고민 당시에 대학생 신분이였던 저는 대학생들을 타겟으로 하는 서비스를 만들면 좋을 것 같다는 생각을 했습니다. 서비스를 홍보할 때 학교의 도움을 조금이라도 얻을 수 있지 않을까 하는 마음에서 그런 생각을 했던 것 같습니다.

 

대학생들을 타겟으로 하면서 가장 빠르게 바이럴 될 수 있을만한 주제가 무엇이 있을 지 고민이 많았습니다. 그러던 중 대학생 익명 커뮤니티인 에브리타임이 떠올랐습니다. 익명 커뮤니티인 특성 상 에브리타임 게시판에는 데이팅에 대한 글이 굉장히 활발하게, 그리고 꽤 직설적으로 올라오는 편인데요. 이러한 수요층을 바탕으로 괜찮은 서비스를 만들 수 있겠다는 생각이 들었습니다.

 

그래서 에브리타임에는 없는 위치기반 기능과 대학생이 주 유저층이라는 특성, 그리고 익명성을 잘 섞어서 기초적인 아이디어를 메모장에 빠르게 작성했습니다. 에브리타임과는 차별화될 수 있도록 성별구분을 확실히 하고, 대학에서 가장 핫한 이벤트인 대학축제에서 홍보하면 좋을 것 같다는 생각을 했습니다.

 

생각날때마다 메모장에 적은 아이디어 조각들

 

아이디어를 피그마로 그려보기

메모장에 써 내려간 내용을 바탕으로 피그마를 이용해 간단히 화면 스케치를 해봤습니다.

초기 아이디어 스케치

 

정말 최소한의 기능만을 하는 상상도를 그렸는데요. 초기에 생각했던 요구사항은 다음과 같습니다.

• GPS 기반으로 캠퍼스 내에서만 작동
• 회원가입할 때 학생증 사진 제출 후 운영진이 승인해야 가입 완료
• 앱을 켜서 버튼을 클릭하면 가장 가까이 있는 이성을 탐색
• 탐색이 완료되면 PUSH 알림으로 매칭되었다는 알림 표시
• 상대방의 학과와 MBTI만 알 수 있는 일대일 익명 대화방 입장 (1:1 대화만 가능)
• 메시지가 10개 이상 오가면 전화 아이콘 활성화

초기 아이디어 구상에서 가장 중요하게 여긴 점은 사용자들이 얼마나 현실감을 느낄 수 있는가였습니다. 기존의 위치 기반 데이팅 앱들이 있긴 하지만, 그곳에서 제공하는 거리 정보가 너무 광범위해서 실제감이 떨어지는 문제가 있었습니다. 게다가 여성 사용자로 위장한 알바가 존재한다는 소문으로 인해 신뢰도가 떨어지는 문제 또한 존재했습니다.

 

이러한 문제점들을 해결하기 위해 두 가지 핵심 기능을 도입했습니다. 첫째로, 회원가입 시 학생증 인증을 필수로 하여 서로 같은 학교 학생임을 확신할 수 있게 했습니다. 둘째로, 서로의 거리와 소속 학과를 공개함으로써 유저가 실제로 가까이에 있는 우리 학교 학생과 연결되고 있다는 현실감을 제공하고자 했습니다.

 

궁극적으로 익명이지만 존중 속에 대화할 수 있는 공간을 만들고자 했습니다.

 

아이디어 빌딩

마침 저는 구름톤 유니브라는 전국 대학생 IT 동아리에 소속되어 있었는데요. 팀을 모아 실제로 서비스에 도전하기 위해 구름톤 유니브에서 주최하는 해커톤에 디스턴스 아이디어를 갖고 참가했습니다. 다행스럽게도 이 아이디어에 관심을 가져주시는 많은 분들이 계셨고, 인터뷰를 통하여 지금의 팀을 구성할 수 있었습니다.

 

팀원들과 회의를 거쳐서 아이디어를 다듬어 나가던 중 공통적으로 나왔던 의견은 아래와 같습니다.

1. 완전한 랜덤으로 한명만 매칭되는 것이 아니라, 주변에 있는 사람들 중 고를 수 있었으면 좋겠다.
2. 일정 거리 내에 있는 유저만 표시되었으면 좋겠다. (ex. 500m ~ 1km 이내)
3. 익명이지만 나를 좀 더 표현할 수 있는 수단이 있었으면 좋겠다.

아이디어 빌딩 과정에서 나왔던 의견들

 

이러한 의견들을 반영해서 아래와 같은 새로운 디자인이 나왔습니다.

아이디어 빌딩 과정을 거친 디스턴스 디자인

 

저희가 회의를 거쳐 최종적으로 확정한 요구사항은 아래와 같습니다.

1. 주변 1km 내에 있는 4명의 우리 학교 이성을 표시하여 유저가 상대를 선택
2. 자신을 닮은 동물상과 취미, 성격 등을 프로필로 등록할 수 있음
3. 학생인증이 완료되어야 가입 가능
4. 대화방 개수는 최대 3개(현재 매칭된 사람들과의 대화에 더 집중할 수 있도록)

 

본격적인 개발

이렇게 나온 디자인을 가지고 본격적으로 개발에 들어갔습니다. 해커톤 발표까지 2주라는 시간이 주어졌었는데요. 주어진 시간이 많지 않다보니, 새로운 기술을 학습하는 것보다 저희가 가진 역량 내에서 개발하는게 더 낫다는 판단이 들었습니다.

 

프론트엔드는 리액트를 이용하여 PWA 형태로 개발하기로 한것이 그 예입니다. 네이티브 앱이 아닌 PWA만을 활용하더라도 프로젝트의 요구사항을 모두 충족할 수 있었습니다. 저희가 구현해야 했던 프론트엔드 기능은 바로 GPS 기능과 PUSH 알림 기능인데요. GPS는 오래전부터 대부분의 브라우저에서 지원하고 있고, PUSH 알림의 경우는 최근 iOS 16.4 버전 릴리즈를 기점으로 모든 브라우저에서 지원하는 스펙이 되었기 때문에 PWA를 선택했습니다.

 

그리고 백엔드는 저희 팀원들이 가장 자신있어 하는 스프링/MySQL을 통해서 구현하는 등 저희가 가진 역량 내에서 최대한 해결하고자 했습니다.

 

프로젝트의 핵심 기능이 채팅이다 보니, 채팅에 사용되는 필수적인 기술들을 공부하는 시간이 필요했습니다. 대표적으로 다음과 같은 기술들을 사용해서 개발했습니다.

• Stomp 프로토콜을 이용한 실시간 채팅
• Firebase Cloud Messaging을 이용한 PUSH 알림

우선 Stomp를 이용한 실시간 채팅은 인터넷에 올라온 풍부한 자료를 바탕으로 비교적 쉽게 학습할 수 있었습니다. 채팅을 구현하는데 필요한 기능(채팅방, 세션)들을 기본적으로 지원하고 있어서 채팅을 구현하기에 용이하고, 리액트 + 스프링을 이용해 채팅을 구현하는 튜토리얼들이 웹상에 많이 올라와 있어 그리 어렵지 않게 구현했습니다.

STOMP Protocol로 구현한 실시간 채팅

 

PUSH 알림의 경우에는 웹을 기반으로 작동하는 PWA를 위해 Web Push를 학습해야 했었는데요. 문제는 Web Push 자체는 인터넷에 정보가 많았지만, iOS를 위한 예제는 찾기 어려웠다는 점입니다. iOS에 PUSH 기능이 추가된 지 얼마 안된 시점이었다 보니 그랬던 것 같습니다. 그리고 백엔드에 PUSH 알림을 잘 보내고 있는지, 제대로 보냈는데 프론트엔드에서 수신을 하지 못한건지 트래킹이 어려워서 개발자들끼리 삽질을 반복했습니다. 결국 여러번의 시도 끝에 첫 알림을 수신했을 때 저희 팀 모두 놀라서 소리를 질렀던 것 같습니다. ㅎㅎ

새벽 4시 반에 성공한 첫 PUSH 알림

 

저희가 개발한 채팅 시스템은 다음과 같은 구조를 이룹니다. 서버 내에 있는 Stomp Broker가 클라이언트 사이의 실시간 메시지를 중계하는 역할을 수행합니다. Stomp가 메시지를 수신하면 DB에 해당 메시지를 저장함과 동시에 FCM에 푸시 알림을 보내줄 것을 요청합니다. 그러면 FCM이 해당하는 사람에게 알림을 전송합니다. 예를 들어, A 유저가 메시지를 전송하면 B 유저에게만 알림을 보내는 식입니다. 이 구조는 현재까지 이어져오고 있습니다.

디스턴스 채팅 시스템 구조도. 현재까지 이어져오고 있다.

 

이렇게 개발 기간 2주 동안 열심히 개발했습니다. 개인적으로는 저희 팀원들과 대화도 잘 통하고 성격적으로도 잘 맞아서 더 끈끈한 팀워크를 만들 수 있지 않았나 하는 생각이 듭니다.

해커톤 현장에서 전원 기절

 

해커톤에서 들었던 피드백 & 배운점

결과적으로 해커톤 수상은 실패했습니다! ㅎㅎ

 

저희 팀 모두 “우리는 실제 서비스 운영이 목적이니 수상하지 못해도 괜찮아!” 하는 마음가짐으로 개발해 임했음에도 불구하고 막상 진짜 수상에 실패하니 힘이 빠지는게 보였습니다. 지금 와서 생각해보면 디스턴스가 해커톤 주제로부터 많이 떨어져있어서 수상에 실패하지 않았나 하는 생각이 듭니다. 해커톤의 주제가 ‘문제해결’에 집중되어 있었는데, 재미와 설렘만을 위한 디스턴스는 Off-topic 이었습니다.

 

최종발표 전에 해커톤에 참가한 모든 사람들이 저희가 만든 앱을 사용해볼 수 있도록 데모부스를 운영하는 시간이 있었습니다. 많은 분들이 저희 프로젝트에 관심을 갖고 찾아와주셨는데요. 그 곳에서 실제로 사용해보신 분들의 피드백을 들으니 배울 점이 많았습니다. 실제 서비스 운영을 계획하는 저희에게는 정말 중요한 내용들이었습니다.

 

길고 지루한 회원가입

가장 기억에 남는 피드백은 회원가입 과정이 너무 길다는 점이었습니다. 저희가 구성한 회원가입 화면은 계정 가입 화면과 학교 인증 화면으로 구성되어 있었습니다. 외부인의 유입을 차단하기 위해 학생인증을 완료한 유저만 앱에 진입이 가능하게 설계했는데요. 하지만 이 점이 신규 유저 유입에 악영향을 끼칠 수도 있다는 것을 깨닳았습니다.

 

비밀번호 규칙

그리고 회원가입하시는 유저들을 지켜보니 비밀번호를 설정하실 때 규칙에 맞게 작성하느라 고민하시는 것 또한 보았습니다. 데모부스는 저희가 직접 지켜보고 있으니 가입하셨을 수도 있습니다. 하지만, 실제 유저가 저희 앱에 처음 들어올 때는 “구경이나 해볼까?”하는 가벼운 마음으로 올텐데, 비밀번호 규칙을 마주하는 순간 이탈할 수도 있겠다는 생각이 들었습니다.

 

이제 서비스를 시작하는 저희는 유저를 최대한 끌어모아야 하는 입장이기에 이러한 제약과 유저의 편의성 간의 균형을 잘 잡아야겠다고 느꼈습니다. 본격적인 서비스를 운영하기 전, 데모부스에서 이런 귀중한 인사이트를 미리 얻어서 다행스러웠습니다.

유저가 길고 지루하다고 느낀 회원가입 과정

 

첫 서비스 운영은 순천향대학교에서

해커톤 수상 실패한 것에 대해 팀원들 모두 조금은 실망했지만, 실제 서비스 운영이라는 더 큰 목표가 있었기에 금방 털고 일어날 수 있었던 것 같습니다.

 

서비스가 빠르게 바이럴될 수 있도록 대학축제에 맞춰서 서비스를 완성하기로 했고, 그 첫 대학은 백엔드 팀원 준석님의 학교인 순천향대학교으로 설정했습니다. 축제일이 오기 전에 앱에 있던 여러 버그도 해결하고, 회원가입이 길다는 점도 개선하기로 했습니다.

 

다음 포스트는 순천향대학교 축제 때 있었던 배포 과정과 고민들을 담아보겠습니다.

긴 글 읽어주셔서 감사합니다!