숨고(Soomgo) 웹 사이트 클론 프로젝트가 끝나고

https://soomgo.com/?utm_source=google&utm_medium=cpc&utm_campaign=%EB%A9%94%EC%9D%B8&utm_content=general&utm_term=SOOMGO&gclid=Cj0KCQjw6ZOIBhDdARIsAMf8YyHvEQWldYy8JPdZoki_vkT4VNAL-XpCd0-SK5xvFHCJR8mXospIK_QaAmSEEALw_wcB 

 

숨고: 숨은고수 - 500만명이 선택한 생활서비스 고수 매칭

한 달간 두번의 프로젝트가 끝났다.

 

1차 프로젝트는 왓챠 피디아 사이트의 기능을 활용해 씨유의 상품을 소개하는 서비스를 만들고자 하였다.

기획만 앞서나갔다. 사실 생각해보면 해당 프로젝트기간의 의의는 기획이 아니었음에도 해당 기획에 집착한 듯이, 개발보다 기획에 포커싱 두려했던것이 오히려 실패 포인트였다. 물론 실패라는 것은 나 혼자만의 실패일 것이다. 팀원들 모두 각자 1차,2차 스크럼 당시 계획했던 목표치 만큼 혹은 그 이상으로 초과 구현하기도 하였으니 말이다.

그럼에도 불구하고 너무 아쉬웠다. 나 개인적으로 더 완벽할 수 있고, 더 많은 기능을 구현할 수 있었는데 그러지 못한거 같아서 아쉬웠다. 

이런 아쉬움 속에서도 분명히 얻은 것은 분명했다. 내가 생각한 부분의 코드를 팀원이 나의 생각과 다르게 작성하는 것을 보며 배울 수 있었고 아직까지는 내게 어려운 영역인 프론트 팀원들과 커뮤니케이션 하는 법, 나아가 비개발자들과도 커뮤니케이션 하게 될것인데 

내가 회사에서 업무를 수행하며 해왔던 커뮤니케이션 방법과 크게 다르지 않을 수도 있겠다는 생각이 들었다. 여하튼 1차 프로젝트에 이어 2차 프로젝트가 바로 시작되었다.

 

2차 프로젝트는 숨고 사이트 클론 프로젝트였다.

감사하게도 왓챠와 숨고 모두 내가 제안해준 프로젝트인데 프로젝트 선정 투표에서 살아남았다.

사실 숨고라는 서비스는 개발을 시작하기 전에는 몰랐던 서비스이다. 그럼에도 해당 사이트를 고른 이유는

첫 째. 내가 나중에 창업을 한다면 생각하고 있는 비즈니스 모델 중 한가지와 매우 유사했고 프로젝트를 진행하며 인사이트를 얻을 수도 있을거라 생각했기 때문이다.

둘 째. 솔직히 지금 나의 실력으로 2주안에 해당 핵심기능들을 만들어낸다? 솔직하게 어려울 것이라 생각했다. 일단 각자 사이트 내부에서 모델과 기능간에 유기적으로 얽혀있는 플로우가 제대로 구현하기 위해서는 적어도 2주는 고민을 하고 계획을 해야 만들 수 있는 수준이라고 생각 했다. 하지만 도전해보고 싶었다. 어려운 과제일수록 더 재밌는 법이니까

 

2주라는 기간동안 최대한 핵심적인 기능만을 추려서 프로젝트를 만들고자 하였고

프론트 팀원들 및 멘토님들과 상의하여 기존의 메인페이지를 간소화 시키고 고객 요청서 작성 - 해당 요청서 바탕으로 추천 고수 필터링 - 추천 고수 페이지에서 견적 요청하기 및 견적 수락 및 거절 - 고객 페이지에서 리스트 확인으로 이어지는 플로우로 핵심 기능을 구현하기로 했다

 

로고도 프론트 팀원들이 직접 만들고 사진도 직접 고르고 페이지 기획도 직접 하면서 팀원들이 고생 많이 했다.

 

사실 1차는 뭔가 기능 구현에 있어 실수는 없었지만 더 진행하지 못해서 아쉬웠다고 한다면

2차인 숨고에서는 디테일 하지 못했던, 추후 기능 구현을 하며 코드를 생각하며 모델을 짜지 않았던것이 패착이 되어.. 2주동안 매일 아침 백엔드 팀원들과 모델 바꿔야 될거 있나요? 로 안부인사를 시작하는 기간이 되어서 너무 아쉬웠다.

물론 배운것은 2차 프로젝트 기간이 더 많고, 재미도 있었다. 

 

 

내가 맡은 기능 구현 중 첫번째, 고객이 입력하는 해당 폼을 바탕으로 요청서를 제작한다.

 

해당 요청서를 바탕으로 이렇게 추천 고수들의 리스트를 뿌려준다. 

처음에 접근하던 생각은 맨처음 서비스를 선택했을 때  해당 서비스의 고수들이 M1이라 한다면 필터링 단계에 따라 M2--M4 까지 좁아진다고 하자.

이 떄 최종적으로 필터링을 거치고 나온 M4 만 출력해주자 였는데 

 

기왕 만드는거 실제 서비스다 라고 생각하면서 욕심내고 만들다 보니 숨고의 서비스 중 추리고 추려서 가져온 64가지의 서비스와,지역 23개 구로 만들었는데 확률상 다른 필터링을 거치지 않아도 고수가 1명이상 추천되기 위해서는 이미 1472명의 고수 유저가 있어야 한다

그런데.. 필터링인 성별, 나이, 경력 을 거치고 나면..? 1명 이상이 매칭되기 위해서는 약 4만여개의 데이터가 있어야 했다.

 

근데 과연 실제 서비스에도 이런식으로 필터링을 할까 라는 생각이 들었고 고수는 어떻게 보면 프로덕트인데 유저에게 제공되는 프로덕트의 선택폭을 넓게 주되, 유저가 원한 리스트를 상단에 노출시켜주는 방식으로 해야하는것이 맞지 않을까 라고 생각됐다.

그래서 위의 그림에서 M4 를 먼저 출력해주고 M3-M4, M2-M3 , M1-M2 부분을 순차적으로 노출시켜주자 라고 생각했다가..

생각해보니까 저 그림 부터가 틀렸다는 것을 깨닫았다. 

Service라는 필수 필터조건에 매칭된다면 무조건 노출 , 그 이후 나머지 필터 조건에서 각자 중첩이 되는 갯수가 많은 영역의 고수를 최 상단에서 부터 내림차순으로 정렬 시켜주는것이 맞다고 생각했다. 즉 위의 그림에서 보면 4 - 3 - 2 - 1 의 순서로 말이다.

 

사실 이 접근법을 생각하며 queryset 도 set의 method 가 적용될것이라 생각했는데 안되더라 

그래서 Application 이라는 요청서 모델과 Master 고수 모델 사이에 중간테이블인 ApplicationMaster 에 level 이라는 column 을 부여해주고 해당 컬럼에 level 을 통해 리스트를 관리해주는 방식으로 코드를 구현하였다. 

물론 이 코드는 지금봐도 너무 아쉽다.

뭔가 더 잘할 수 있었는데 깔끔하게, 가독성 좋게 구현할 수 있었는데 그러지 못한거 같다. 동료들은 물론이고 멘토님들도 한 번 봐서 코드를 이해하지 못했다. 개발은 나혼자 하는 것이 아님에 가독성 좋게 남이 알아볼 수 있는 코드를 구현하는것이 얼마나 중요한데... 

 

이렇게 아쉬움을 남겨두고 정해진 기간이 있기 때문에 스크럼 계획에 맞추기 위해서는 이미 기능이 구현 된 코드에 집착을 하기보다 다음 기능구현이 우선이라 생각했다. 

 

 

내가 만든 그다음 기능은 우측 견적 요청 플로우

고객이 고수의 페이지에 가서 견적을 요청하면

고수가 자기 상세 페이지에서 확인하고 수락 or 거절을 통해

매칭이 완료된다. 물론 고수가 실제 견적을 요청하고 고객한테 다시 ok?를 보내는게 논리적으로 맞겠지만 시간상 간소화 시켰다.

사실 실제서비스에서는 고수와 유저가 채팅으로 실제 커뮤니케이션을 진행하기에 이렇게 단계를 복잡하게 나눌것 까지도 없긴했다. 

하지만.. django chennels 를 통한 채팅구현이란 2주동안 구현하기에는 시간안에 구현이 어려울 것이라 판단되어 추후 도전해보기로 했다.

 

여하튼 해당 부분은 Quotaiton이라는 모델을 만들고 

Status 라는 column 을 줘서 고객이 최초 요청시에는 status -waiting, 고수가 수락시에는 accepted, 거절시에는 denied 이런식으로 로직을 구현해주었다.

사실 이부분은 코드를 보여줄것 까진 없긴 하지만 위 사진에서 보면 나의 실수를 볼 수 있다.

... 예외처리를 안해줬다. 고객이 한번 요청했는데 또 요청이 되다니... 이런건 기본적으로 잡고 넘어갔어야했는데 아쉽다.

 

뭔가 한달 동안 프로젝트를 하며 개발을 하면서도 내가 더 재미있고 흥미롭다 생각하는 부분이 무엇인지, 어려워 하는 부분은 무엇인지 알 수 있었다.

 

흥미로운 것은 데이터와 데이터를 기반으로 추천로직을 작성한다든지 하는 부분이었다. 첫번째 프로젝트인 왓씨유 에서도 날씨 기상청 데이터를 통한 상품 추천 로직이라던지, 연령에 따른 주류 상품 노출, 성별에 따른 여성용품의 노출, 그리고 나아가서 특정 고객이 재구매를 한 상품이 있을 때 해당 상품을 구매한 다른 고객들의 구매빈도가 높은 상품을 추천 해준다던지 하는 로직을 작성할것을 생각하면 너무 흥미로웠다. 두번째 프로젝트에서도 고객에게 맞는 고수들을 추천해주는 로직이 아쉽지만 굉장히 재미있었다.

 

어려웠던 부분은 모델링... 괜히 데이터 아키텍트 설계 기획을 아무나 하는게 아니다 라는것을 깨닫을 수 있었다.