캐치패션 클론 사이트 제작 후기

BG·2021년 6월 20일
2

파이썬과 django를 학습 후, 코딩의 꽃(?)인 클론 사이트를 제작해 보았습니다.
프론트 개발자 2명과 백엔드 개발자 3명의 팀으로 진행하였으며, 제작기간은 2주 정도 소요 되었습니다.

[요약]

Clone Site : 캐치패션
GitHub : https://github.com/BG-YU/21-1st-catchcode-backend

팀원

프론트엔드 : 정유정, 황윤성
백엔드 : 손창효, 범승원, 유병건

제작기간

2021/6/7 ~ 2021/6/18

Skill Stack

Python, Django web framework, Bcrypt, JWT, MySQL, RESTful API

ETC

AQueryTool, Git, trello, gspread

1. 사이트 선정


커머스 사이트를 우선 클론해 보고 싶었고, 프론트 기준으로 동일한 기술스택을 사용하고 있는 사이트를 우선 선정하기로 하였습니다.

그렇게 사이트를 둘러보면서 캐치패션이라는 사이트를 발견하였고, 기본적인 커머스 사이트의 기능을 모두 포함 하고 있었으며, 디자인적으로도 너무 과하지 않았기에 2주간의 클론 프로젝트로는 적합하다고 생각되어 선정하게 되었습니다.

2. 요구정의


사이트를 선택하면서 기간을 고려하지 않은 것은 아니었으나, 그럼에도 불구하고 2주라는 기간은 너무나도 짧은 기간이었기에 현실가능한 목표를 세워야만 했습니다.

프론트 분들과 다함께 모여 캐치패션 사이트를 틀어 놓고 어떤것들을 뺄것인지에 대하여 토론하기 시작 하였습니다.

  1. 비슷한 기능이 존재하는데 모두다 구현할 것인가?
    - 위시리스트와 장바구니는 비슷하니 장바구니만 구현한다.

  2. 무한스크롤링은 어떻게 할것인가?
    - 우선적으로 상품 리스트 구현 후, 시간적 여유가 생기면 구현한다.

  3. 회원가입 로그인의 유효성 검사는 어떻게 할것인가?
    - 실제 사이트에 있는 유효성과 동일하게 구현한다.

  4. 상품리스트의 필터기능은 어디까지 구현할 것인가?
    - 가격과 색상, 캐치구매까지만 구현한다.
    - 캐치구매란? : 사이트의 주요 특성이며 쿠팡의 로켓배송과 비슷한 기능

  5. 상세페이지에서는 어디까지 구현할 것인가?
    - 상세페이지에서 선택가능한 옵션은 사이즈로 한정하며, 사이즈는 Large, Medium, Small로 한정한다.

...

위와 같은 과정을 거치며 요구정의를 하였고 회의 결과를 반영하여 모델링을 시작 하였습니다.

3. DataBase Modeling


DB ERD는 AqueryTool을 사용하여 작성하였습니다.

ERD
ERD Password : 2sgs02

3-1. ERD를 작성하며...

커머스 사이트의 모델링은 처음 진행해 보는 거라 약간의 수정을 거쳐 가며 진행하였습니다.

장바구니의 모델링을 처음 작성 하였을때는 결제 테이블과 장바구니의 테이블을 분리하여 모델링을 작성하였습니다만, 그렇게 되면 결제 테이블과 장바구니 테이블 양쪽에 상품리스트가 존재해야 하는 데이터의 중복이 발생하게 되었습니다.

멘토님들의 의견을 구한 결과, 결제 테이블에서 상태값으로 구분하면 데이터의 중복을 거를수 있다는 멘토링을 받고 장바구니의 테이블은 삭제, 결제 테이블에 상태값을 지니게 하여 결제전이면 장바구니로 취급하는 로직으로 구현하기로 결정하였습니다.

4. 기능구현


4-1. 회원가입

  • bcrypt를 이용하여 비밀번호 암호화를 적용하였습니다.
  • 정상적인 회원가입이 아닌 백엔드로 바로 데이터가 들어오는 경우를 생각하여, 백엔드에서도 회원가입의 유효성 검사 로직을 프론트와 동일하게 적용하였습니다.

4-2. 로그인

  • JWT를 이용하여 토큰을 발행하였습니다.
  • 로그인이 필수인 로직의 경우를 대비하여 파이썬의 decorator를 활용한 JWT토큰 유효성 검사로직을 구현하였습니다.

4-3. 상품리스트

  • 상품리스트의 경우 필터 기능이 적용되어야 하기때문에 Q객체를 활용하였습니다.
  • 상품 가격 필터를 위해 range lookup type를 사용하였습니다.
  • 상품의 제목 필터를 위해 startswith lookup type를 사용하였습니다.
  • 최신순 10개 항목만을 가져오기 위해 order_by와 슬라이싱을 사용하였습니다.

4-4. 장바구니

  • 로그인 토큰 유효성 검사를 위해 로그인 decorator를 사용하였습니다.
  • orm의 hit수를 줄이기 위하여 select_ralated, prefetch_related를 사용하였습니다.

5. Third Party(DB Uploader)


개발을 진행하면서 더미 데이터를 수집하기 위해 팀원 개인간에 CSV를 개별로 관리하고 있는 상황이었습니다.

개별로 모은 데이터를 하나의 CSV로 합치고, 다시 그 CSV로 프로젝트 DB에 밀어넣고 하는 작업이 너무나도 비효율적이라 구글 스프레드 시트를 활용하기로 했습니다.

구글 스프레드 시트에 함께 작성한뒤 구글 스프레드에서 바로 프로젝트 DB로 밀어 넣을수 있으면 좋게다는 생각을 했고, 구글 검색을 통해 알아보니 gspread를 활용하면 제가 생각한 그대로를 실현할수 있었기에, 바로 작업을 진행했습니다.

데이터 수집을 위해 소비하던 시간이 대폭적으로 줄었고 그 시간을 활용하여 조금더 코딩에 집중할수 있게 되었습니다.

gspread를 활용한 db uploader는 아래의 블로그에 따로 작성 하였습니다.

gspread 활용하기

6. 나의 역할


저는 개발을 하다가 커리어 성장을 위해 부트캠프를 참가하는 입장이었기에, 어느정도 개발에 대한 감은 충분히 있는 상황이 였습니다.
다만, 제가 부족했던 점은 파이썬과 django framework, orm을 처음 사용해 본다는 점이였습니다.
하지만, 평소 개발을 하면서 첫번째 투입되었던 프로젝트에서는 C#과 java spring, mybatis, oracle조합으로 진행을 했었고, 두번째 프로젝트로는 asp.net, vbscript와 oracle을 사용하여 개발을 했었습니다.
그 덕분에 새로운 언어를 배우는데 있어서는, 어느 정도 익숙한 편이었기에 두려움은 없었습니다.
그리고 배포를 제외한 프론트, 백엔드의 Full Cycle를 경험하였기에 프론트와의 소통도 자신있는 상태였습니다.

하지만, 부트캠프를 참가하는 대부분의 분들은 비전공자 출신분들이 많았기에, 여기에서 제가 선택할수 있는 상황은 두가지 정도일 것이라고 생각했습니다.

첫번째로 전면에 나서서 프로젝트를 이끌어 나간다.
- 장점 : 프로젝트가 산으로 가는것을 막을수 있다.
- 단점 : 너무 전면에 나설 경우, 팀원들의 배움의 깊이가 얕아 질수 있다.

두번째는 전면에 나서지는 않지만, 서포터 역할을 하고 팀원들이 코딩을 원할하게 할수 있도록 다방면으로 지원한다.
- 장점 : 팀원들이 코딩에만 집중할 수 있다.
- 단점 : 서포터의 역할이기에 나의 성장이 더딜수 있다.

이렇게 두가지 상황에서 고민을 하였으나, 결론적으로는 자연스럽게(?) 두가지 역할을 다 수행해야만 했습니다.

아무래도, 개발자 출신이라는 것이 팀원들에게는 자연스럽게 큰형님 같은 존재로서 인식이 되었던것 같습니다.

첫번째 역할로써 행하였던 것은 우선적으로 제가 자신있었던 DB설계를 주도적으로 이끌었으며, 회의를 주관하며 회의록을 작성하고 여러 의견들을 종합하여 결정을 내리는 PM의 역할도 도맡았었습니다.
그리고, 프론트와 백엔드 사이에서 주고 받아야 하는 의견 교환의 창구로써의 역할도 하게 되었습니다.

두번째로 서포터로써의 역할은 시니어 개발자의 느낌으로 백엔드 팀원들이 코딩적인 부분에서 해결이 되지 않는 것과 JSON 데이터구조 설계를 가이드 하고, 서로가 모르는 경우에는 같이 도큐멘트를 찾아가면서 서포터의 역할을 수행 하였습니다.
그리고, 더미 데이터를 쉽게 관리할수 있도록 구글 스프레드시트를 활용한 DBUploader을 개발하였습니다.

그렇게 위 두가지의 역할을 수행하며, 제가 맡았던 API기능까지 개발하기에는 시간이 부족했기에 주말과 집에 돌아온 후의 시간을 활용하여 주로 코딩을 하였습니다.

몸은 힘들었지만, 아래 세가지는 확실히 느낄수 있는 프로젝트였습니다.

  • orm은 양날의 검이다.
  • 아는것과 설명하는 것은 다르다는 것.
  • 스케쥴 관리와 팀원들을 케어하는 것이 생각보다 적성에 잘 맞는다는 것.

7. 마치며...


시간적 여유가 조금 더 있었다면, 더 많은 기능들을 팀원들과 구현해 보고 합도 맞춰 가면서 진행했을텐데 팀원들 간의 호흡이 좀 맞아들어가나 하는 찰나에 프로젝트가 끝나 버려 그것이 제일 아쉽습니다.

개인적으로는 리팩토링을 조금씩 진행해 볼 생각입니다.

로그인 토큰의 유효시간 설정이라던지, redis를 활용하여 캐쉬에서 데이터를 가져온다던지... 어떤식으로 리팩토링을 할지 조금더 리스트업 한다음 천천히 진행해 보아야 겠습니다.

profile
글쎄...?

2개의 댓글

comment-user-thumbnail
2021년 6월 20일

병건님 발표때 말씀을 너무 재밌게 잘하셔서 흥미롭게 들었습니다 🙌🏻
1차 수고 많으셨어요!!

답글 달기
comment-user-thumbnail
2021년 6월 20일

찐어른 병건님!.. 1차 프로젝트 고생많았어요~ 2차도 화이팅합시다@@!!

답글 달기