코드로 우주평화

결과물 사이트 주소 : http://suulgo.s3-website.ap-northeast-2.amazonaws.com/ 깃헙 레포 : https://github.com/Daco2020/27-2nd-SUULGO-backend 고민했던 것들 지난 1차 프로젝트 때 개인적으로 아쉬웠던 점들이 있었다. 노션과 트렐로 툴을 병행하여 트렐로 툴을 적극 활용하지 못한 것 트렐로를 활용하지 못하여 칸반의 진척도를 정확히 파악하지 못한 것 팀원 간 실력차에 의해 업무 공백이 발생한 것 단순 데이터 반환 기능만을 구현한 것 개성 있는 서비스가 아닌 사이트 클론과 기능에 집중한 것 이번 술고 프로젝트에서는 1차 때의 아쉬운 점들을 극복하는데 집중했다. 그래서 이번에는 첫 번째, 트렐로를 과감히 포기하고 노션에서 칸반을 함..

술 GO? 전 글에서 술 취향 매칭 알고리즘을 통해 가장 매칭 점수가 높은 사람들을 리스트로 받는다고 말했었다. 그리고 마음에 드는 유저를 선택하면 해당 유저의 술 취향을 볼 수 있는 상세페이지로 들어갈 수 있다. 상세페이지 화면을 보면 우측 상단에 ‘술고!’ 버튼이 보인다. 이제는 매칭을 넘어 상대방과 술 약속을 잡을 차례다. 버튼을 누르면 날짜 선택 모달 창이 뜨고, 원하는 날짜를 선택하여 실제 요청을 보낼 수 있다. 보낸 요청은 DB 테이블에 기록되는데, 이후 상대방이 확인을 할 수 있는 코드 또한 작성해두었다.(사이트에서는 아직 구현하지 못해 추후 실시간 알림이 뜰 수 있도록 리펙토링 예정) 문어발 요청은 NO! 약속 요청을 만들면서 한 가지 우려스러운 상황이 떠올랐다. 술고(술약속) 요청을 보낼..

실제 고객들은 무엇을 중요하게 볼까? 술고라는 서비스는 우리가 하고 싶어서 만들었지만, 그럼에도 가장 중요한 건 결국 고객의 니즈라고 생각한다. 디자인을 배우고 상업예술에서 잠시 일을 했었던 나는 예술과 비즈니스를 가르는 중요한 기준 중에 하나가 바로 이 ‘제작자와 구매자 간 니즈의 일치’라고 생각한다. 고객의 생각이나 니즈와는 무관하게 만들고 싶은 것을 만든다면 그것은 ‘예술’, 구매자가 원하는 것이 무엇인지 파악하고 이를 만족시켜주기위해 만드는 것은 ‘비즈니스’의 영역이라고 생각한다. 물론 이 둘은 함께 공존할 수 있고, 이 둘이 교집합을 이루는 순간을 '덕업 일치'라고 생각한다. 서론이 길었는데 본론으로 들어가자면, 우리는 우리끼리만 만족하기 보다는 고객의 니즈를 확인하고 고객의 만족도를 높여주고 ..

상대의 술 취향을 알 수 있는 상세페이지? 우리의 서비스는 유저와 유저 간에 술 취향을 매칭 하여 연결시켜주는 매칭 서비스이다. 그렇기 때문에 우리가 유저에게 제공해주는 정보는 다른 유저들의 정보일 수밖에 없다. 나는 상세페이지를 맡았으므로 고객이 선택한 다른 유저의 정보, 즉 상세페이지 뷰를 구현하였다. 내가 프론트에게 넘겨주는 정보는 다음과 같다. 처음에는 디비 테이블에 있는 칼럼명을 그대로 사용하여 반환하였는데, 워낙 정보가 많다 보니 프론트와 상의하여 앞에 'text'와 'alcohol'을 붙여 데이터를 더 쉽게 구분하여 사용할 수 있도록 하였다. #결과 반환값 { "result": { "id": 1, "profile_image_url": "http://www.irobotnews.com/news/..

페이커와의 만남 Faker는 디비에 가짜 데이터를 생성해주는 모듈이다. 맨 아래에 공식 페이지 링크를 남겨놓겠다. 만약 더 쉽게 사용하고 싶다면 구글에 검색해보라. 자주 사용하는 페이커 메서드를 잘 정리해 놓은 블로그들이 많다. 페이커는 1차 때 브랜치 팀에서 데이터를 넣을 때 사용했었다. 그 당시에 우리팀은 모든 상품과 데이터들을 직접 일일이 찾고 직접 입력하는 식으로 진행하였는데 (65개 상품을 입력하는데 하루를 모두 사용했었다..ㅜㅜ) 페이커를 이용한 브랜치 팀은 수십만 개의 데이터를 손쉽게 입력하였다. 그래서 이번에 우리는 페이커를 이용하여 디비에 데이터를 넣기로 하고 여러 글들을 보며 공부를 했다. 그리고 브랜치팀에서 이를 사용했던 도원님에게도 찾아가 조언을 구했다. 페이커는 생각보다 어렵지 않..

혼돈의 모델링 기존 커머스는 유저가 있고, 카테고리가 있고, 상품이 있고, 장바구니, 주문, 등등으로 나누면 되었는데 매칭 서비스의 경우 기존 커머스 DB 구조와는 맞지 않았다.(테이블은 적지만 더 복잡해진 느낌?) 가장 큰 차이점은 두 가지였다. 하나는 유저와 관련된 정보가 매우 많다는 것이고(사용자의 취향을 모두 저장하므로) 다른 하나는 유저가 곧 상품이라는 것이다. (사람을 '상품'취급하는 것이 이상해 보일 수도 있지만 사람과 사람을 이어주는 것이므로 그런 의미로 서로 받아주시면 감사하겠다) 우리는 우선 유저의 회원가입정보와 함께 가입 시 유저가 작성한 취향 정보도 모두 하나의 테이블에 넣었다.(이때의 결정이 이후 디비를 갈아엎는 원흉이 되었다.) 그리고 중복선택이 가능한 항목들은 모두 다대다 테이..

2차 프로젝트의 시작 2차 프로젝트가 시작되었다. 새로운 인원들과 조를 이루었고 우리가 받은 과제는 고수를 찾아 매칭 해주는 서비스 '숨고'였다. 일단 우리는 '숨고' 사이트를 살펴보기 시작했다. 나는 사용자가 직접 입력한 선택지들을 통해 누군가와 연결시켜주는 매칭 서비스가 인상적이었는데, 이 외에도 상대방과의 채팅 기능, 자신을 홍보하는 포스팅, 등 다양한 기능들이 있었다. 우리가 하기에 난이도가 너무 높아 보였다. 우리 팀 PM인 유진님이 숨고 싶다고 표현할 정도..ㅎ 우리는 우리가 할 수 있는 선까지만 하기로 하였고 이왕이면 재밌게 해보고 싶어서 기존 컨셉을 완전히 바꾸기로 했다. 그중에는 여러 가지 아이디어가 있었다. 숨고 싶다 : 심리상담사 매칭 서비스 만나고 : 소개팅 매칭 서비스 숨고 : 술..