[SWM] 소마 6월 회고 - 서비스 구체화, 기획 심사, 개발 준비

1. 서비스 구체화

이전 주제 선정 단계에서 주점을 운영하는 사장님(이하 주점업자)와 주점을 방문하려는 고객(이하 주점이용자)을 연결해 실시간 주점 자리 확인 및 예약이 가능한 서비스를 개발하기로 확정했다. 서비스명은 지금 당장 갈 수 있는 주점을 찾아 바로 출발할 수 있다는 의미를 담아 '지금갈게'라고 작명했다. 주제가 정해졌으니 구체화 작업을 통해 핵심 기능과 서비스 플로우를 정의해야 했다. 결론적부터 적어보자면, 주점이용자는 현 위치에서 일정 반경 안에 위치한 주점업자 측에 특정 인원에 대한 수용 가능 여부를 묻는 자리 확인 요청을 보내고, 이에 주점업자는 업장 내 상황을 판단하여 수락 또는 거절 응답을 보낸다. 주점이용자에게는 수락 응답을 보낸 주점들이 주점 정보와 함께 실시간으로 리스트업되고, 실제 방문할 주점을 골라 실시간 예약을 체결시키는 방식을 채택했다. 주점이용자가 주점업자에게 자리 확인 요청을 보내는 것은 카카오T 서비스에서 택시 콜 요청을 보내는 방식과 비슷하게 떠올렸다. 예약 체결이 완료되면 주점이용자에게는 길찾기 서비스를 연결해주고, 주점업자에게는 이용자가 입력한 출발 지연 시간과 예약자의 위치를 바탕으로 계산된 예상 도착시간을 보여준다. 만약 이용자가 예상 도착 시간이 지나도록 주점업자 측에서 도착 확인이 되지 않는다면 이는 노쇼로 간주되어 패널티를 받게된다. 이에 부가적으로 도착 지연 신청 및 푸시알람 기능을 지원할 예정이다.

 

1-1. 실질적 Needs 파악을 위한 주점 사장님 인터뷰

여러 멘토링에서 반드시 확보해야 할 고객인 주점업자들의 입장에서 우리 서비스를 꼭 써야할 이유가 명확하지 않은 것 같다는 피드백을 많이 받았다. 사실 주점 이용자 같은 경우 실제로 우리가 주점 이용 시 불편함을 몸소 겪으면서 실시간 자리 확인과 예약 서비스가 꼭 필요하다는 것은 명확했지만 주점업자의 입장은 크게 고려해보지 못했다. 그저 막연하게 손님이 늘고, 예약 관리가 수월해질 것이라고 판단했다. 하지만 멘토님A는 이러한 판단은 그저 추측일 뿐이며, 사실이라해도 사장님이 우리 서비스의 필요성을 느끼게 만들기엔 부족하다고 말씀하셨다. 주점업자들의 실질적엔 pain point를 찾고, 이를 해결할 수 있는 기능이나 요소가 필요했다.

우리는 곧바로 주점업자 분들을 찾아가 인터뷰를 진행하기로 계획했다. 인터뷰는 단국대학교 상권에서 '도*' 술집을 운영하시는 사장님(이하 사장님A)과 '라*칼' 술집을 운영하고 계신 사장님(이하 사장님B)을 대상으로 2회 진행했다. 나의 학교 선배의 도움으로 어렵지않게 섭외할 수 있었으며, 두 사장님 모두 3년 이상 운영해오신 분들이었다. 인터뷰 질문은 주로 기존의 자리확인 및 예약 방식, 영업 시 불편한점, 서비스 사용 의사 및 원하는 기능 등으로 이루어져고 30분씩 소요되었다. 아쉬운 점은 인터뷰 내용을 영상이 아닌 녹음의 형태로 기록해 놓아 발표 자료나 이곳에 첨부할 자료를 남기지 못했다는 점이다. 그래도 인터뷰 후 서비스에 대한 확신을 가질 수 있었다. 확실한 needs를 발견했고, 서비스에 대해서도 긍정적인 의견을 내주셨다. 인터뷰 내용을 토대로 정리한 주점업자 측 paint point는 다음과 같다.

• 영업 중간중간 예약 및 자리 문의 전화를 받기 어렵다.
• 고객들이 산발적으로 자리를 찾아다니기 때문에 주점 중복 예약이 종종 발생하고, 이는 의도치 않은 노쇼로 이어진다.
• 노쇼로 인해 발생하는 피해는 모두 사장님이 떠안는다.
  • 노쇼 방지책 및 보상책이 없다.
  • '10분 뒤 갈꺼니까 자리좀 빼주세요' 등과 같이 약속의 형태로 예약이 이루어지다 보니 서면으로 예약금이나 피해보상금을 요구하기 어렵다.

 

1-2. 유저 시나리오를 통한 솔루션 기능 도출

멘토님A의 코칭 아래 페르소나를 설정하고 유저 시나리오를 작성했다. 처음에는 왜 꼭 유저 시나리오를 상세하게 작성해야 하는 지 잘 몰랐다. 하지만 실질적인 사용자 유형인 페르소나가 언제 어디서 어떻게 서비스를 사용할 것인지에 따라 기능 및 솔루션 디테일이 달라질 수 있어 유저 시나리오를 작성하는 과정은 꽤나 중요했다. 먼저, 주점업자와 주점이용자 각각을 대표하는 가상 인물인 페르소나를 구체적으로 설정해보았다. 이후 다음과 같이 프로필을 만들어 시각화했다.

주점이용자 페르소나 프로필

주점업자 페르소나 프로필

핵심 시나리오 작성을 위해 주점업자와 주점이용자 각각의 불편함 중 우리 서비스가 가장 중요하게 해결할 문제를 정리해보았다.

• 주점이용자: 일일이 돌아다니며 술집 자리를 찾아 들어가기 힘들다
• 주점업자: 영업 중 자리 확인 문의 대응 및 노쇼 관리가 어렵다

 

시나리오는 여러 단계에 거쳐서 작성했다. 처음에는 그저 페르소나가 어떤 문제상황에서 언제, 어디서, 어떻게 서비스를 사용했는지에 초점을 맞추어 시나리오 초안을 작성했다. 페르소나가 무엇을 원하는지, 어떤 기분이였는지까지 최대한 자세하게 적으려고 노력했다. 이후에는 시나리오 초안을 기반으로 구체적인 솔루션 및 서비스 플로우를 도출해보았다. 다양한 기능들을 떠올렸고, 사용자가 원하는 바를 이룰 수 있는 최적의 솔루션을 시나리오에 추가했다. 즉, 기존의 초안에서 점점 서비스 기능 및 플로우가 드러나도록 살을 덧붙히는 작업을 진행한 것이다. 이후에도 여러번의 수정을 거쳐 어떤 서비스 로직을 통해 어떻게 사용자가 만족감을 느끼게 되었는지를 명확하게 알 수 있는 최종 시나리오가 완성되었다. 주점이용자와 주점업자 각각의 핵심시나리오는 다음과 같다.

<주점이용자 최지윤 핵심 시나리오>
지윤이는 오늘 8시에 전공수업이 끝날 예정이고, 수업 종료까지 10분 정도 남았다. 오늘따라 집에 가기 아쉬웠던 지윤이는 학년 단체 채팅방에 같이 술먹을 사람을 구하는 글을 올렸다. 약 5명정도에게 참석한다는 연락이 왔다. 배가 고팠던 지윤이는 수업이 끝나자마자 빠르게 자리가 있는 술집으로 들어가고 싶었다. 지윤이는 휴대폰을 통해 실시간 술집 예약 서비스를 켰다. 소마대 주변에 있는 술집 중 10분 뒤에 6명이 바로 방문할 수 있는 술집 목록을 확인할 수 있었다. 걷기가 너무 싫었던 지윤이는 리스팅된 술집들 중 가장 가까이 있는 가게를 선택해 실시간으로 예약했다. 수업 종료 후 지윤이는 친구들과 예약한 가게로 곧장 향했다. 늦은 저녁시간이라 술집에는 사람이 가득했지만 지윤이가 미리 예약한 6명 자리는 따로 마련되어 있었다. 지윤이와 친구들은 뿌듯함을 느끼며 늦은 밤까지 술자리를 즐겼다.

<주점업자 오명진 핵심 시나리오>
소마대학교는 오늘 체육대회였다. 체육대회로 인해 뒤풀이를 하는 학생들이 많아 아남포차 사장님인 명진이는 쉴새없이 손님들을 받고 움직였다. 이전에는 이런 경우 손님들이 너무 많아 테이블정리도 안되고, 계속해서 자리가 있냐는 전화를 받느라 정신이 없었던 명진이였지만 지금은 포스기에서 오는 알림을 통해 손님들의 실시간 예약 문의를 확인할 수 있다. 이러한 예약 문의들에 대해 명진이는 예약 손님의 신용점수와 매장 상황을 체크한 뒤, 수용 가능하다면 수락 버튼을, 그렇지 않다면 거절 버튼을 누르거나 알림을 무시하면 된다. 덕분에 명진이는 수월하게 테이블 정리가 가능했고 끊임없이 울리는 전화벨 소리도 안 들을 수 있게 되었다. 또한, 신용등급제도를 통해 노쇼 전적을 확인한 뒤 손님을 가려받을 수 있게 되었고, 시스템 도입으로 이전처럼 중복예약으로 인한 노쇼 발생이 없어져 노쇼에 대한 걱정도 덜어낼 수 있었다.

 

 

2. 기획 심사

소마에는 기획 심사 단계가 있다. 나라에서 지원금을 받고 진행하는 프로젝트인 만큼 제대로된 기획이 바탕이 되어야할 것이다. 가치있는 프로젝트 경험을 위해서도 꼭 필요한 단계라고 생각한다. 1차 기획 심사에서 합격하지 못할 경우, 기획을 보완하거나 새로운 기획을 가지고 2주 뒤 2차 기획 심사를 받아야 한다. 다만, 기획 심사 결과는 최종 평가에 반영되지 않는다. 프로젝트 질 향상을 위한 과정일 뿐이다. 그래도 기획을 한번에 통과하지 못하면 2주 동안 2차 기획 심사 준비를 해야하기 때문에 전체적인 개발 일정이 밀리게 된다. 따라서, 한번에 심사를 통과하기 위한 준비와 노력이 필요했다.

 

2-1. 의욕 넘쳤던 발표 준비

기획 심사를 위한 발표를 준비하면서 힘 조절에 실패했다. 심사 전, 기획을 튼튼히 적립할 필요성은 분명하지만 기획 심사 자체는 최종 평가에 반영되지 않으니 자료 준비에 너무 시간을 할애할 필요는 없다는 일부 멘토님의 조언이 있었다. 대충하라는 것이 아니라 1차 기획 심사를 통과할 수 있게 설득력만 갖출 정도로만 준비하면 된다는 뜻이었다. 그럼에도 불구하고, 우리가 고안한 서비스를 공식적으로 처음 보여주는 자리이다 보니 기획서부터 발표 자료 제작에 열정을 쏟아버렸다. 그래도 다행인 것은 발표 준비에만 전념한 것이 아니라, 동시에 기획을 튼튼히 잡는 일에도 힘썼기 때문에 전체적으로 발표 준비에 시간을 모두 뺏겼다는 느낌은 들지 않았다. 힘 조절은 실패했지만 프로젝트 자체의 질이나 일정에 차질이 가지 않으면서 부가적으로 열심히 했던 경험이기 때문에 후회는 하지 않는다.

먼저 발표 내용에 포함할 항목을 나열한 뒤 책임자를 나누어 자료를 만들었다. 내용은 크게 서비스 배경 및 필요성, 서비스 핵심 기능, 사업성 분석, 적용 기술 및 스택, 기대 효과 및 활용 방안 등으로 구성했다. 발표는 MVP 기능인 실시간 주점 자리 탐색 및 예약을 중심적으로 기획과 개발 방향을 보여드렸다. 그 외 주점업자의 역제안 예약, 시간 지정 예약 등의 부가적인 기능은 추후 확장 가능성만 염두해두었다.

 

2-2. 생각보다 긍정적이었던 피드백

20분 발표 후 10분씩 5분의 심사위원께 팀 별로 서비스에 관한 질문이나 피드백을 받는 시간이 있다. 기존 서비스와의 차별점, 구체적인 비즈니스 모델 등 주요하게 나올 수 있는 질문에 대하여 예상 질문 리스트를 만들어가며 대비했다. 하지만 막상 발표 후 질문은 거의 없었고 대부분 피드백을 많이 주시는 분위기였다. 다행이더 우리가 받았던 피드백은 대부분 긍정적인 피드백이였다. 특히, '지금갈게'와 같은 서비스의 필요성은 깊이 공감한다는 의견을 많이들었다. 심사위원 분들 중 한 분은 본인도 발표일 기준 어제 동료들과 3차까지 술자리를 즐겼는데 3차 술집 찾기가 너무 어려웠다며 '지금갈게' 서비스가 출시된다면 바로 사용할 의사가 충분하다는 극찬(?)을 주셨다. 다만, 솔루션에 대해서는 몇 가지 조언 받은 내용이 있었다. 받았던 피드백들을 정리해보자면 다음과 같다.

• 프로젝트 목적과 필요성에 대해서는 깊이 공감한다.
• 프리미엄 모델을 통해 주점업자 측에서만 수익을 창출하는 구조인 것 같은데 이용자 측에서도 수익을 낼 수 있는 장치가 있었으면 좋겠다.
• 점죽가 매번 메시지를 확인하며 응답하는 것은 다소 불편한 방식으로 보인다. 주점 내의 포스기 프로그램과 연동할 수 있다면 자리 여석 여부를 실시간으로 모니터링이 가능해 예약을 자동화할 수 있으므로 포스기 업체와의 컨택을 고래해봤으면 좋겠다.
• 초기에 대규모 시장과 사용자를 유치할 수 방안에 대한 고민이 필요하다.
• 매칭 성공률이 높아야 할 것이다.
• 타이머 + 할인 등 노쇼 방지에 대한 방법을 재미 요소로 가져갈 방안 등에 대한 고민이 필요하다.

 

 

3. 개발 준비

기획 심사를 기점으로 기획 단계를 어느정도 마무리 하고 개발을 위한 구체적인 계획 수립 및 준비 단계에 들어갔다. 물론 기획을 픽스 시키는 것은 아니였다. 개발 준비 단계나 개발 진행 중에도 언제든지 유연하게 기획이 수정될 수 있음을 염두해 두었다. 또, 기획이 끝나면 바로 편하게 개발을 할 수 있을 줄 알았는데 큰 오산이었다. 준비하거나 설계해야 하는 것도, 새롭게 배워야 하는 내용들도 굉장히 많았다. 그럼에도 개발 전에 기반을 단단히 다져놓아야 이후 개발 일정에 차질이 생기지 않을 것이기 때문에 소홀이 할 수 없었다. 따라서, 7월부터 바로 실질적인 개발에 착수한다는 기존의 계획을 수정하여 설계 등 개발 준비 단계에 조금 더 힘써보기로 하였다.

 

3-1. 애자일 기반의 개발 및 협업 계획 수립

효과적인 프로젝트 진행을 위한 소프트웨어 개발 방식으로 애자일, 그 중에서도 스크럼 방법론을 채택했다. 2주를 스프린트 단위로 설정하고, 매 스프린트마다 정의해 둔 백로그를 수행한 후 피어 리뷰를 거쳐 스프린트를 종료하는 방식이다. 스프린트 종료 시에는 지난 스프린트에 대한 회고와 다음 스프린트에 대한 건의, 이슈 정리, 새 스프린트 준비를 위한 백로그 할당 및 담당자 지정 등에 대해 논의한다. 스프린트 종료는 주로 금요일 저녁, 다음 스프린트 시작은 주로 일요일 오전에 이루어진다. 또한, 그라운드 룰상 공식 off day인 토요일을 제외하고는 매일 아침 9시에 데일리 스크럼도 진행한다. 회의 일을 기준으로 팀원 각자가 어제 한 일과 발생한 이슈, 오늘 할 일을 짧게 브리핑한다.

스프린트 관리는 Jira Software를 활용한다. 전반적인 프로젝트 일정을 확립하여 로드맵을 작성했다. 서비스 기능을 기준으로 에픽을 나누고, 에픽 아래 기능 구현을 위한 스토리와 작업을 추가한다. 스프린트에는 에픽 아래의 스토리나 작업 단위가 할당되며, 각 스토리와 작업에 대해서는 담당자가 하위작업을 작성한다. 모든 작업은 생성 당시 '해야할 일' 상태이며, 담당자가 작업을 시작하면 '진행 중', 작업이 완료되면 '리뷰대기', 담당 리뷰어가 해당 작업에 대한 리뷰를 마쳤을 때 '완료됨' 상태로 변경한다. 각 작업에 대한 산출물은 노션에 정리한 후 링크를 첨부한다.

코드 작업물은 깃허브로 관리한다. 팀 페이지 내에 프론트엔드와 백엔드 레포지토리를 분리하여 생성했다. 프론트엔드와 백엔드 코드를 각각 나누어 효율적으로 관리하기 위함이다. 브랜치는 초기 개발의 편의를 위해 기능 별로 feature 브랜치를 만들어 pull request를 보낸 후, 리뷰 담당자가 수정사항을 확인한 후 main 브랜치에 merge하는 방식으로 진행하기로 했다. 추후에 개발 브랜치외 운영 브랜치로 구분하는 gitlab flow 전략을 적용할 것이다. 프론트엔드와 백엔드 통신 시 데이터 형식의 지표가 되는 API 명세서 작성 또한 노션을 이용했다. swagger를 통한 API 명세 관리는 추후에 활용하고, 우선은 사용성이 높은 노션을 이용하기로 합의했다.