[레디베리 1편] 우당탕탕 실결제 서비스 MVP 배포 이야기

8개월의 여정을 마치고 뒤늦은 후기를 올려본다.

사건의 발단

---

 

열정 넘치는 한 PM분과 연락이 닿아 지금껏 동고동락한 형과 함께 팀을 꾸리게 되었다.

제품을 만들기에 앞서 가장 힘들었던 부분은 팀원 모으기 였던 것 같다.

 

아무리 학교 커뮤니티에 올리고, 게시물을 붙혀도 아무것도 없는 팀 에는 관심 조차 주지 않았다…

특히, 프론트엔드가 문제였다.

지이이이이이인짜 안구해졌다…. 그래서 기존에 프론트엔드를 했던 경험을 다시금 살려 해야하나…. 고민마저 들었다….

그래서 직접 발로 뛰며 발품 파는 방법으로 진행할 수 밖에 없었다.

결국 지인의 지인, 지인의 지인의 지인으로 사람을 모을 수 있었고, 이때 정말 네트워킹의 중요성을 명확히 알 수 있었다. ㅠㅠ

여차저차해서 개발 시작 전까지 PM 1, 디자이너 1, 백엔드 2, 프론트 4 총 8명이 모여 MVP 시작할 준비가 되었다.

 

 

 

아이디어의 시작 (다사다난의 시작)

---

PM 분이 가져온 아이디어는 학교 주변의 카페와 연결하여 커피 원격 주문 서비스를 학생들에게 제공하는 것이었다.

 

아이디어 배경

• 학생들이 교내 카페를 쉬는 시간에 이용하는데 줄이 너무 길어 지각하거나 이용하지 못하는 경우가 많음
• 사장님들이 교내 학생들에게 카페 신메뉴 혹은 카페 자체를 홍보하고 싶지만 알릴 방법이 입소문밖에 없음

위와 같은 불편은 교내 학생이라면 1번씩은 느꼈을 것이고 커피를 달고 사는 저는 매우 공감되는 문제 였다.

또한, 실서비스로 직접 유저가 사용하는 것을 보고 우리가 풀고자하는 문제를 정말 해결할 수 있을지도 의문이라 바로 시작하게 되었다.

 

일정

각자가 기존의 계획된 일정을 마무리하고 10월 23일에 프로젝트가 본격적으로 시작하기로 결정되었기때문에 프로젝트의 출시 기한은 정말 촉박 그 자체 였다.

출시 기한은 교내 유동인구가 제일 많을 시기인 기말고사 기간으로 잡았다.

• MVP 기간에 최대한의 유의미한 데이터을 뽑기 위함이죠 ㅎㅅㅎ

따라서 6주 라는 짧은 시간을 고려해서 기획, 마케팅, (디자인, 개발) 을 진행했어야 했다.

보안까지…

또한, 실결제가 이루어지는 서비스이기에 회원과 주문 결제가 안정적으로 이루어져야 하는 상황마저 고려해야 했다…

 

 

기획

PM분이 아이디어는 얼리어단계였다.

먼저, 하나로 묶여 생각하고 있던 서비스를 학생들이 커피를 멀리서 주문하기 위한 유저페이지 와 유저의 주문을 받기 위한 점주 페이지 로 분리하여 진행했다.

나중에 이를 분리해 생각한게 백엔드에 신의 한수로 작용했다….

 

 

고객관리적으로는 3주간 바이럴이 가능한 계획으로 현실적인 부스 운영 신청, SNS 광고 , 학교 커뮤니티 광고(에브리 타임 등) 이 있었다.

 

기획적으로는 UX/UI 설계, 이용약관, 개인정보처리방침 , 사업자 등록증 신청 , PG 계약 , 사장님 컨텍 , 비즈니스 계정 신청 이 있었다.

 

기능적으로 유저페이지에는 간편로그인, 메뉴판, 장바구니, 주문 결제, 결제 취소 , 주문 상태 , 주문 내역, 이벤트 , 쿠폰 등이 있었고,

점주 페이지에는 간편 로그인 , 주문 거부 , 주문 상태 변경 , 가게 오픈 , 알림톡 전송 , 메뉴 품절 , 매출 확인 등이 있었다.

 

위와 같이 이전에 창업경진대회의 경험을 살려 필요한 요소들을 팀원 모두와 칠판에 리스트업하여 파트를 분배했고 6주의 계획에 맞게 세세하게 일정을 조정했다.

 

또한, 우리를 믿고 들어와준 팀원들이기에 불안에 떠는 팀원들의 컨디션 관리와 커리어패스 역시 고려를 안해줄 수가 없었다… 그래서 주마다 1명씩 원온원 커뮤니케이션 자리를 만들어 커리어를 설계하는데 있어 줄 수 있는 요소와 스펙 그리고 원하는 방향을 제시해주기도 했다.

 

 

이러한 원온원 커뮤니케이션 덕분에 팀원과 신뢰가 쌓였고, 덕분에 MVP에 이어 추가 개발을 더 나아갈 수 있었던것 같다. 또한 신뢰와 친밀도가 높아지면서 프로젝트에서 다양한 관점의 의견을 더 자유롭게 낼 수 있던 환경이 만들어 진거 같아 잡담이 힘이다 라는 것을 너무 극명하게 느꼈다.

 

 

그러나 이제서야 터놓는거지만, 배달의 민족 포장 버전이라는 점에서 보이는 기능들만 너무 많았고 6주 내에 개발이 가능할지 의문과 의심이 들었다. 특히 기존에 프론트엔드를 주로 하고 백엔드를 보조로 했던 내겐 두려움이 더 앞섰지만, 불안에 떠는 팀원들 앞에서 같이 불안에 떨면 분위기가 더 안좋아질 것 같아 일부러 더 강한척한 것 같고 망하더라도 할 수 있는데까지는 포기하지말고 다 해보자는 마인드로 진행했던거 같다.

 

ERD 설계

 

ERD를 설계하는 것부터 쉽지 않은 여정이였다. 데이터베이스 설계가 실전경험으로는 처음이였고, 데이터베이스 설계에 따라 엄청난 비용과 서비스 이슈를 불러올 수 있기 때문에 신중하게 설계해야 했다.

이때, 같이하는 형의 발목 붙잡지 않으려고 정규화와 Spring(1:N) 도메인 설계 등 공부를 집와서 항상 2시간씩 했던것 같다…

추후 나중에 더 공부하면서 더 나은 방법으로 데이터베이스 테이블의 의존성을 분리하고 개선했지만 아직도 개선의 여지는 많다고 생각한다.

 

또한, 현재 서비스가 진행되면서 점진적 개선하기 위한 설계는 또 다른 어려움이라 느꼈다…

 

개발

기획과 데이터베이스 설계가 끝나고 개발이 시작되었다.

 

백엔드는 2명 프론트 4명으로

백엔드는 SpringBoot로 프론트는 만약을 대비해 내가 할 수 있는 React를 골랐다.

(결국 내가 점주사이드 프론트를 만들게 됐다….ㅠㅠ)

API 명세를 작성해보니 대략 50개의 API가 필요했고, 나는 OAuth 간편로그인과 점주사이드 관련 API를 맡았다.

 

 

OAuth 로그인은 카카오 간편로그인으로 선택했다.

카카오톡이 많은 유저 정보를 받을 수 있었으며, 특히 전화번호를 받을 수 있는 점이 컸다.

하지만 spring으로 oauth 구현은 처음 해보는 것이기도 했고, spring에 대한 개념을 명확히 알지도 못한채 springsecurity에 들어가기 때문에 bean과 DI의 명확한 개념도 모르는 나에게 있어 springsecurity 설정은 정말 난해하고도 복잡한 내용이었다.

 

특히나 자료는 spring 2.x 버전의 springsecurity가 대다수였고, 가장 쓰고 싶었던 springsecurity + OAuth2 + JWT 조합을 쓴 자료를 찾기가 쉽지 않았다.

결국 단기간에 springsecurity, OAuth2, JWT 최신 자료들을 뒤적뒤적하면서 끌어모았고,

다행히 우아한테크코스에서 위 내용을 정리한 블로그를 찾아 최대한 따라서 진행할 수 있었다.

 

 

하지만 여기서 깊게 고민했던 것은 해당 블로그는 SSR방식.

즉, 프론트엔드에 토큰을 전달할 필요없이 서버에서 이루어지는 방식이기에 토큰전송 방식을 고려할 필요가 없었지만, 우리는 CSR 방식인 react를 사용했기 때문에 302 리다이렉트가 이루어지면서 토큰을 프론트에 전송할 방법을 생각해야했다.

 

대중적으로 블로그 자료에 나와있는 것은 queryString 방식으로 토큰을 전송하는 방식을 알려줬다.

하지만 우연의 일치일지는 몰라도 기존에 jwt토큰의 보관과 인증방식의 절차는 NCSOFT 취약점 점검, 이화여대 플랫폼 제작 외주를 함으로써 queryString 방식은 기존에 브라우저 방문기록에 남는다는 이유로 보안에 취약하다는 점을 인지하고 있었다.

그래서 가장 안전할 것 같은 쿠키를 통한 전송방식을 고려했고, 쿠키는 서브도메인이 같아야 통신이 가능하기 때문에 인프라 파트에 부탁해서 백엔드, 프론트엔드 url을 /api 기준으로 구분하여 설정해주었다.

 

 

이로써 결국 아래와 같은 절차로 간편로그인을 안전하게 설계할 수 있었다.

Frontend 간편로그인 버튼 클릭 → Backend Redirect → KAKAO OAuth 로그인 → Backend 정보 처리 → Backend 토큰 쿠키에 적재 → Frontend Redirect → 가입 완료

 

 

 

하지만 여기서 조금 아쉬움이 남았던 건 디스크 기반 데이터베이스인 MySQL에 RefreshToken을 담아 재인증할 때마다 디스크 I/O가 발생했다는 점이다.

 

이는 추후 Redis로 RefreshToken을 마이그레이션해 문제점을 해결했다.

 

관련 자료 첨부.

https://farmfarm1223.tistory.com/97

Redis로 RT 마이그레이션 적용기 및 유닛테스트

 

 

JWT 토큰을 왜 사용했고, Session과의 차이 그리고 Authorization 헤더와 Cookie 전송방식 등의 내용은 다음 블로그에서 다뤄보겠다.

(여기는 후기니까 ㅎ)여러 OAuth 서비스(google, apple)도 추가되면서 수평적 확장을 진행했는데 이도 2편에서… ㅎㅎ

주문 접수쪽에서도 Long Polling 방식으로 주문이 들어왔는지를 API를 3초마다 받는 방식으로 진행하도록 설계를 진행했다.

 

처음에는 WebSocket를 사용하려고 했으나, Long Polling 방식 얼마나 서버에 무리를 줄지는 감이 오지 않았기 때문에 Long Polling 방식으로 데이터가 조금 쌓이고 나서 필요하다고 생각이 들면 마이그레이션을 할 예정이다.

아쉬움이 남고 지금 개선하고자 하는 내용은 다음과 같다. 아무래도 차례차례 글이 올라오지 않을까 싶다.

 

위 내용으로 마이그레이션을 점진적으로 진행해보면서 아쉬움이 남은 코드를 개선하고자 한다.

많관부…

 

QA

백엔드 개발을 다하고 나니 서비스 시작 예정까지 2일도 남지 않게 되었는데, 한 팀원이 너무 힘들다며, 잠수와 일정지연을 반복해 설득을 진행했으나 결국 개발적으로는 큰 변화가 없어 만들어진 서비스의 QA를 부탁드렸었다…

 

 

결국, 2일도 남지 않은 시간에 프론트엔드 개발을 맡게 되었고 내가 만든 API를 내가 직접 연결하게 되는 기묘한 일이 생겼다…

이 덕분에 내가 프론트엔드에서의 상황을 고려해 내 API를 직접 QA를 진행하면서 제작하게 되었다… ㅋㅋ

( 백엔드 에러나는데 누구야? 전데용? 자문자답…)ㅋㅋㅋㅋㅋㅋㅋㅋ

 

일정을 미루고 싶었으나… 점주님들과의 계약이 있어 서비스를 미루기 어려웠고 결국 개발이 다 끝난 우리에게 남은 시간은 단 6시간.

이미 출시 때문에 며칠 밤을 새서 개발했기 때문에 마지막 QA와 수정은 모든 팀원들이 정신력으로 진행했고, 이 덕분에 치명적 오류는 없었다… 휴

 

이슈

문제는 서비스가 진행되면서 발생했다. 서비스 진행 중에 점주 주문접수화면에서 갑자기 햐얀화면이 나오면서 에러가 뜬 것이였다!!!

원인은 카카오톡에서 받은 전화번호가 주문 접수 화면에 표기되어야하는데 Null 값이 나와 발생한 에러였다.

 

애초에 카카오톡 서비스는 전화번호가 있어야 가입이 된다.

또한 비즈니스 계정까지 통과 시켜 전화번호를 필수로 받기를 설정했기 때문에 카카오톡 간편가입 동의항목에 전화번호가 없을 경우에 카카오 측에서 가입이 되지 않을 것이라 생각했다.

 

하지만, 과거 카카오톡에는 전화번호 없이 계정을 만들 수 있던 시기가 있었고, 이 시기에 만든 아이디는 전화번호가 NULL값이라 이 NULL값을 회원정보로 넘겨줘서 전화번호 예외처리가 없던 우리 서비스에 치명적인 오류를 일으킨 것이다.

 

 

결국 외부 API에 너무 과한 의존을 한 결과가 치명적인 에러를 불러온 것이다. 이 때문에 의존성 분리, SOLID 원칙을 열심히 공부했고, SRP, OCP,DIP를 적용하고자 노력했다.

 

 

반응

 

점주

점주님들 반응은 매우 좋았다.

한 점주님은 계약을 3일만 했지만 3일이 지나고 시험 마지막 주차까지 서비스를 이용해주셨담…

좋았다고 하신 부분은 신메뉴 광고, 카페 홍보, 학생이 많이 먹는 메뉴의 리스트업, 매출 확인 등의 요인이 있었고, 위 이점들을 더 좋은 방향으로 활용할 수 있도록 피드백도 주셨다!!

 

유저

유감스럽게도 유저의 반응은 좋지 못했다…

• 이미 종강한 학생들이 있었던 점
• 부스 운영에서 시간대가 좋지 않았던 점
• 학교 커뮤니티 및 게시물의 홍보 효과가 부족했던 점
• 포스터의 요점이 부족한 점
• 앱의 부재(접근성 문제)

등의 문제들이 겹쳐 미미했다..

그래도 2주간의 서비스 기간동안 227명의 유저가 우리 서비스를 이용해주었다 ㅎㅎ

 

지표

이때까지 측정한 지표는 서비스가 지속 가능한지 판단하기에는 무리라 생각됐다.

그래도 GA4와 Clarity를 사용해 2주간의 유저 데이터를 측정했었다.

13일에 유저의 사용이 가장 많았는데 12일 밤에 에브리타임에 게시물이 주목을 받아서 그랬던 것 같다.

그러나 앞서 말한 이유들로 구매 전환이 많이 일어나지는 않았다.

매출은 그 당시 64만원 정도 나왔고 MVP이기에 다 점주님께 드리고 마케팅 비용을 제외하면 적자였다…

취소가 29건인 이유는 우리가 테스트를 위해 결제를 하고 취소한 것 그리고 앞서 말한 이슈로 인한 문제로 취소된 건이였다.

 

마무리

정말 6주간의 우당탕탕의 일상이였고 어지러운 생활의 반복이었지만, 짧은 기간에 실제 유저가 사용하고 결제가 이루어지는 서비스를 직접 제작해보고 운영해보면서 정말 좋은 경험이 되었다.

 

또한,

이만큼 달려올 수 있도록 옆에서 항상 같이 밤을 새주고 내 물음에 긍정적으로 답을 해준 동고동락 운명공동체 형

늦게 합류해 어색할 수도 있지만 항상 으쌰으쌰 분위기를 만들고 일이 많아도 불평,불만 없이 부탁한 모든 일을 잘해준 분위기 메이퀸 친구같은 동생

어려운 부분을 맡았지만 결국 꿋꿋이 자기 일을 마치고 QA까지 밤새서 해준 책임감 넘치는 형같은 동생

재잘재잘 짹짹 밤새는 분위기를 즐겁?게 만들어주고 모르는 걸 질문 공세하면서 제 일 잘 끝내준 말많은 동생

개발하면서 잦게 변경된 UX/UI에도 불평없이 더 고도화해서 만들어준 엄마같은 착한 능력자 동생

정신 없는 와중에 최대한의 쾌적한 환경을 만들어줘 개발자 편의를 봐주고 암울한 랩실에 웃음을 주던 남동생 같은 형

 

정말 좋은 사람들과 6주를 재밌게 즐길 수 있었고, 좋은 사람들과 함께 한다는게 내게 어떤 영향을 주는지도 명확히 알 수 있었다.

생각해보면 정말 천운이었다. 짧으면 짧고 길면 긴 시간동안 좋은 사람들과 힘든 여정을 유쾌하게 즐기면서 떠날 수 있었던 이 경험은 내게 있어 무엇보다도

(개발 경험보다 더)

가장 가치있던 경험이였던 것 같다.

 

결과