[Wecode] 1차 프로젝트 후기

송진수·2021년 8월 17일
1
post-thumbnail

뉴발란스 클론 코딩

저희 팀은 뉴발란스의 디자인 레이아웃을 참고하여, 지금까지 배운 파이썬 언어, Django Framework, MySQL을 활용하여 뉴발란스 사이트에서 볼 수 있는 기능들을 직접 구현해보았습니다.

개발란스 백엔드 GitHub

DB 모델링 & 업무 분담

백엔드 업무 분담에 앞서, 구현할 주요 기능을 회원가입/로그인, 상품 조회, 장바구니/결제 등 크게 3가지로 나누어 각각의 데이터 참조 관계를 디자인하였습니다.

업무 분담 과정에서는 상품 조회 기능을 맡기로 하였습니다. 로그인/회원가입 기능 같은 이미 배운 내용을 그대로 복습하는 방식은 충분히 연습했다고 판단이 되었습니다. 또한 URI에 쿼리 변수를 받아서 응답하는 방식은 당시에는 잘 모르는 내용이어서 지금까지 연습해보던 기능과는 새로운 시도가 될 것 같다는 확신이 들었기 때문입니다.

다중필터링 & 정렬 구현

특정 상품의 상세 정보를 조회하는 페이지는 Path parameter를 통해 상품 id로 API를 호출하면, 상품 테이블의 해당 상품의 데이터를 응답하는 방식으로 쉽게 구현할 수 있었습니다.

한편 상품 리스트 페이지에는 여러 상품들의 요약 정보를 보내주어야 하는데, 프론트에서 어떤 방식으로 저에게 요청을 해야 필요한 상품들만 걸러내어 응답할 수 있을지에 대한 고민이 필요했습니다.

특히, GET method를 통해 데이터를 조회하기 때문에 HTML 요청 body에 내용을 담을 수도 없었기 때문에, 여태껏 배운 요청/응답과는 다른 방식이 필요했습니다.

그리하여 알아본 결과, request body 없이도 HTTP 요청에 쿼리 변수를 담아서 받아볼 수 있다는 것을 알게 되었습니다. 이를 활용하여 다양한 쿼리 변수를 파이썬 변수, 또는 리스트로 받았습니다. 그리고 같은 기준 내에서는 합집합, 서로 다른 기준 사이에서는 교집합 형태의 쿼리 조건을 Q객체 하나로 쌓을 수 있도록 코드를 구현하여 다중필터링이 가능하도록 하였습니다.

다만 까다로운 부분은 가격대 필터였는데, 각 가격대에 대한 id값이 DB상에 존재하지 않아 1) 프론트에서 min/max값을 담은 리스트 형태로 쿼리 변수를 보내거나, 2) 백에서 직접 대응하는 방식 둘 중 하나를 택해야만 했습니다.

프론트와의 상의 끝에, 다른 쿼리 변수들과 같은 방식으로 번호를 보내는 것이 일관성이 있고, 프론트쪽에서도 URI 스트링을 생성하기도 쉽다고 판단이 되어 제 쪽에서 딕셔너리를 만들었습니다.

필터 조건을 완성시킨 이후에는 위와 같은 딕셔너리 방식으로 정렬 기준을 제한하기도 하고, 새로운 기준을 annotate하여 확장했습니다.

또한 미리 받은 limit & offset 변수로 프론트에서 요청하는 만큼만 데이터의 개수를 제한하여 pagination과 유사한 기능을 할 수 있도록 구현했습니다.

최종적으로 DB에 접근하는 동작은 모든 쿼리 조건이 완성된 이후 단 한번 이루어지게끔 하였습니다.

구현 영상(2:14~)

느낀 점

프로젝트 시작 전에 알았더라면....

앞으로 어떤 프로젝트를 마주치든 마찬가지겠지만, 프로젝트 전에는 몰랐다가 '아차, 진작 알았더라면 여기서 이렇게 막히지 않았을텐데..' 싶던 순간들이 매우 많았다. 쿼리 변수, Q객체, Annotation/Aggregation 같이 DB의 정보를 원하는 대로 가지고 놀 수 있는 방법들을 진작에 알았더라면.. 연장통에서 공구들을 일일이 꺼내어 어떻게 쓸 수 있는지 휘둘러 보는 과정에 시간을 제일 오래 썼었던 것 같다.

대신 이렇게 아무도 가르쳐주지 않지도 쓰라고 시키지도 않았지만, 그래도 내가 스스로 필요를 느껴 직접 찾아내고 문제해결에 활용하는 과정에서 배운 내용이 머리에 남고 손에 익는 것 같다.

profile
보초

0개의 댓글