이번 주 화요일부터 협업프로젝트가 시작했다.
프론트 4명, 백엔드 2명(나포함) E커머스/쇼핑몰 사이트를 클론코딩하는 프로젝트이다.
(클론코딩 - 기획시간을 아끼기 위해)
사이트가 만들어지는 과정에 대해 기록을 남겨보려고 한다.
1. 기획 : 클론코딩으로 시간 단축
웹사이트를 만들 때는 기획과 설계가 엄청나게 중요하다고 느껴진다.
유튜브나 블로그에서 종종 보던 내용이기도 하다.
성공적인 사이트를 운영하기 위해서는 다음의 고려가 필요하다.
-
BM(비즈니스 모델) 설계
1. 회사의 정보를 제공하기 위한 보여주는 데이터가 중요한 웹사이트인지? 2. 웹사이트에서 판매/판촉/홍보등을 하는, 사용자가 많이 필요한 사이트인지? 3. 단순히 대화를 주고받을 수 있는 커뮤니티인지? 4. 유지비용/수익성이 감당할만한지?
- 백엔드 기준으로 생각해보면 이는 결국 성공적인 서버 관리를 제공해야 한다.
이를 위해 필요한 정보는 다음과 같다.1. 사용자 종류 (권한에 따른 기능 분리) 2. 사용자의 숫자 3. 데이터의 숫자 (상품이든 뭐든) 4. 각 데이터들이 추가될 방향(종류가 늘어날지, 같은 종류의 데이터가 왕창 들어올지) 등의 데이터가 필요하다. 5. 사이트가 제공하는 기능 - 한편으로는 주어진 시간 내에 구성할 수 있을까? 에 대해서도 고려해야 한다.
- 뿐만 아니라, "어떻게 하면 사용자가 편하게 사용할 수 있을까?" 에 대해 고려하여 UI/UX가 나와야 하고, 수익고려를 한다면 비즈니스모델도 생각해야 하고, 마케팅적인 요소를 고려한다면 Goolge Analytics를 사용하기 위한 구조도 생각해야 한다.
클론코딩을 함으로써, 위의 과정(기획)을 매우 줄일 수 있었다.
실제로 개발자끼리 실제로 운영하지도 않을 사이트에 대해, 정확한 데이터가 없어 "감"이나 "기분"에 따라 바뀔 수 있는 기획을 하느라 시간낭비를 하는 것보다는 클론코딩 하는 것이 매우 합리적이라고 느껴진다.
2. ERD 구성
위의 정보가 주어졌다면, 사용자가 어떤 종류의 데이터에 접근해서
어떤 상호작용을 하는지 (CRUD)에 대해 고려해야 한다.
이를 먼저 대략적으로 알기 위해, "논리 ERD"라는 걸 그려본다.
아래는 내가 작성한 "논리 ERD" 이다.
사용자가 상품을 보고(READ), 주문-구매-배송 처리까지의 과정을 기준으로 그렸다.
다만, 외부와의 연동은 고려하지 않아 아예 제외했다. (Ex. 결제정보 <-> 결제회사와 연동, 배송정보 <-> 배송회사와 연동, 회원가입 <-> 구글/네이버와 연동)
이를 토대로 | 사용자 ID | 후기정보 | 상품정보 | 좋아요,장바구니,주문정보 | 에 대하여 각 테이블에 들어갈 column을 구성했다.
- 데이터베이스의 테이블 및 각 구성요소(column)를 정한다.
- 이 때 고려하는 요소는 "ROW" 말고 "COLUMN"이 증가할 가능성이 있는 테이블은 분리하는 것이다. (중복되는 데이터가 발생하는데, 이를 기존의 column으로 커버하지 못한다는 뜻)
만약 이렇게 DB의 개요를 만들어둔 이후에 테이블이나 column에 변경이 많이 일어난다면, 처음에 기획이 제대로 되지 않은 상태라는 것을 의미한다.
3. API만들기 (feat.수정)
2번에서 백엔드에서 데이터베이스와 기능의 설계도를 만드는 동안,
프론트엔드는 화면 구성의 설계도를 그린다. 각 화면들에 공통으로 들어가는 모듈/템플릿은 무엇인가? 에 대해 파악을 하고, 이 공통 모듈/템플릿을 만들게 된다(마치 백엔드에서 DB의 테이블/column를 만드는 것처럼) - 이것이 React에서는, 컴포넌트이다.
이렇게 서로 프론트엔드의 요청에 따라 API를 제공하게 된다.
그러면 DB에 저장된 그대로 제공하는 것이 아닌 JS에서 편하게 Parsing을 할 수 있는 형태로 전환해서 데이터를 전달해준다. 다만 이는 초기의 과정으로 데이터를 간단하게만 만들었지만
*DB에 쌓여있는 raw한 데이터
*프론트엔드를 위해 가공한 데이터
이 과정에서, 많이 쓰이는 기능인데 여러 테이블을 같이 사용해야 하는 경우가 있다.
-> 테이블을 잘못 만든 것은 아닐까? 하는 생각이 드는데, 사이트가 만들어지기 이전인 지금이, 아직 뭔가 데이터베이스를 변경하기 나쁘지 않은 단계인 것 같다.
4. 남겨진 숙제
- 리팩토링(효율성)
우리는 지금 백엔드서버에 dJango를 사용하고 있는데,
상품의 상세데이터를 위해 데이터베이스를 5번 조회를 하도록 되어 있다.
이 코드는 ASAP 바꿔야 한다. SQL로 따지면 OR과 JOIN을 사용해야 하는데, dJagno의 QuerysetAPI에서는 해당 기능들을 어떻게 사용하는지 찾아봐야 할 것이다.
무수히 많은 objects.get/ object.filter의 향연..
- RESTful API 작성
현재는 경로들의 이름을 대충 지어둔 상태다.
REST의 양식에 맞추어 URI를 변경해야 할 것이다.
path('product/menu_raw/', MenuList.as_view(), name = 'menu'),
path('product/category_raw/', CategoryList.as_view(), name = 'category'),
path('product/product_raw/', ProductList.as_view(), name = 'product_all'),
path('product/product_raw_by_category/<int:category_id>/', MenuByCategory.as_view(), name='menu_good'),
path('product/category/<int:category_id>/', ListByCategory.as_view(), name='menu_good'),
path('product/product/<int:product_id>/', DetailByProduct.as_view(), name="product_detail")- 추가 기능 구현
검색, 로그인, 장바구니,주문 등 추가 기능을 완성해야 한다.
후기
여기까지 만드는데 약 2일정도가 소요되었다.
여태까지는 기본적으로 dJango에서 지원하는 기능을 갖다 썼기 때문에 별 어려움 없이 코드를 짰지만, 이후로는 얼마나 힘든 도전들이 기다리고 있을지 기대와 걱정이 반반이다.
가장 재미있었던 점은 다른 분들이 "~~가 필요해요"라고 말했을 때 뚝딱 만들어줄 수 있었다는 점 이었다.
힘들었던 점은 .. 다른 백엔드분이 git에서 conlfict가 발생해서 반나절을 날려야 했던 점.
