이랬던 사이트 향수 커머스 사이트의 메인페이지가
이렇게 바뀌었다 😅
개요
프로젝트 기간인 2주, 아니 설날 명절 기간을 포함한 3주가 순식간에 지나갔다. 프로젝트 최종 발표 후에 느낀 기분은 후련하기도 하면서도 한편으로는 개발하면서 처음 경험해보고 앞으로 많이 경험해볼 프로젝트 협업의 첫 단추를 잘 꿴 것 같아서 뿌듯했다.
프로젝트 소개
포스트 아포칼립스에 걸맞는 상품들을 판매하는 커머스 사이트 종말론 구현
향수 판매 커머스 사이트인 조 말론의 클론 코딩 프로젝트
조 배정 공지를 보자마자, 향수 사이트인 조말론이 이미지 측면에서 클론 프로젝트에 어울리지 않다는 개인적인 생각이 들었다.(이미지는 저작권 문제가 없는 프리 이미지나 라이선스를 구입해야 된다) 그래서 사이트 구조만 클론하고 내용은 바꿔야겠다는 점이 팀원들의 공통된 의견이었다.
다행히도 첫 미팅 때 프론트엔드 팀원 기만님이 종말론이라는 재미있는 아이디어를 내 주시고 팀원들도 전부 동의해 주셔서 상품 정보를 DB에 넣을 때 필요한 CSV파일을 작성 할 때도 즐겁게 한 기억이 난다.
최종 발표때도 반응이 좋아서 괜시리 기분이 좋았다 😎
개발 인원 및 기간
- 기간 : 21.01.24 ~ 22.02.11
- Frontend 4명 : 김기만, 박재형, 이화종, 홍지은
- Backend 2명 : 김준영, 이강일
Frontend Git Repository
Backend Git Repository
Project Github(Fork)
적용 기술 및 도구
Frontend: JavaScript, React.js, SASS, React-router-domBackend: Python, Django, MySQL, AWS(EC2, RDS, S3)버전 관리: Git, Github협업 및 일정 관리: Slack, Trello, Notion
여러모로 이번 프로젝트를 진행하면서 git의 중요성을 많이 느꼈다.
Foundation 기간에는 repo를 공유해도 서로 폴더를 나누어서 진행하였기 때문에 충돌날 일이 없었으나, 이번에는 팀원이 다른 기능을 구현하면서 같은 파일(products/views.py)를 공유해 작성하면서 충돌이 났다. 2차 프로젝트때는 모델링 및 역할 분담을 철저히 해 이런 일이 없도록 하고, 혹시라도 rebase를 통한 커밋 및 충돌 최적화를 적용해서 이런 일이 없도록 해야겠다.
이외에도 Trello에 간트 차트를 활용하여 작업별로 일정 관리를 하는 법, Notion에 회의록을 작성해서 개발 진척 상황을 공유하는 것 등등 1차 프로젝트를 진행하면서 협업을 어떻게 진행할지 감이 왔다. 😄
Reference
db.diagram은 데이터베이스 세션때 사용해 본 기억이 있어서 금방 프로젝트에 적용해서 사용하였다. 반면 프로젝트의 엔드포인트를 문서화하는 Postman은 사용하면서 신세계를 느끼는 기분이었다.
1주차에는 프론트간 통신을 할 때 구두나 DM으로 엔드포인트와 기능을 프론트에게 알려줬지만, Postman을 통해 문서화를 하니 그럴 필요가 없어져 효율적으로 개발에 착수할 수 있었다.
또한 각종 에러 처리나 사용 예시 까지 문서로 저장할 수 있다는 점도 마음에 들었다. 2차 프로젝트에는 1주차부터 적극적으로 활용해 볼 생각이다.
시연 영상
첫번째는 프론트엔드와 통신을 마친 사이트의 시연 영상 링크,
두번째는 내가 작업한 feature인 카테고리 조회, 상품리스트 조회 및 검색/정렬을 httpie로 시연한 것이다.
쿼리스트링을 처음 적용할 때 httpie는 브라우저 url과는 다르게 ?나 &를 공백으로 구현하고, = 또한 ==로 구현한다는 사실을 몰라서 1시간 정도 헤멘 기억이 난다. 검색의 중요성!
Features
- User : 회원가입, 로그인(+bcrpyt 암호화, JWT Token 발급)
- Product : 카테고리 조회, 상품 리스트 조회/검색/정렬 ,상품 상세 정보
- Cart : 장바구니 추가/조회/삭제/수정
- Wishlist : 관심상품 추가/조회/삭제
- Order : 주문하기/조회/취소(변경)
Planning Meeting때는 필수 구현 사항에 리뷰 기능까지 포함되어 있었지만 시간 여유가 없는 것에 더해 프론트엔드와 진척 상황을 맞추는 것으로 인해서 작업을 하지 못했다. 프론트엔드와의 통신을 무시하고 기능 개발에만 몰두했으면 가능했었지만, 프로젝트 막바지에 여러가지 이슈가 발생하면서 진행하지 못했다. 😭
담당/작업했던 기능들
Modeling
첫 미팅에서 팀명을 정하고 멘토와 함께하는 플래닝 미팅까지 시간이 남아서 모델링을 2시간만에 끝냈다.
사이트 구조가 간단해서 금방 끝낸 점은 좋았지만, 몇몇 디테일을 챙기지 못한 점이 2주차때 아쉬움으로 돌아왔다.
예를 들면 주문할 때, 회원가입할 때 등록했던 연락처나 주소 이외에도 별도로 적는 칸이 있었는데, 모델링에서 그것을 캐치하지 못해 Order API를 구현할 때 어쩔 수 없이 빼게 되었다.
User API
- Validation, 인증/인가 모듈화 초안 코드리뷰 받고 수정
이메일 비밀번호 검증 정규식은 1주차 코드 리뷰를 한번 받아서 모듈화를 시켜놓은 상태였다. 다만 하드코딩과 유지보수를 고려하지 않은 반쪽짜리 모듈화였는데 리뷰를 한번 더 받고 완벽하게 로직만 남기고 모듈화하고 merge에 성공했다.
이 경험은 앞으로도 클래스의 개념을 이해하고 적용하는데 유용하게 쓰일 것 같다.👍
Product API
- 전체 카테고리, 서브카테고리(대분류,소분류)
- 상품 리스트, 키워드를 통한 상품 정렬(sorting) 및 검색(영문,한글이름)
- 상품 상세 정보
Path Parameter수정
1주차의 시간 대부분을 이 기능들을 구현하는데 사용하였다.
전체 카테고리 출력은 이전 Westagram에서 팔로워/팔로우 기능을 만든 경험이 있어 금방 구현했지만 , 상품 리스트 전체 출력은 RESTful API를 제대로 이해하지 못해 애를 먹었다.
각각의 기능들마다 엔드포인트를 여러 개로 설정했는데 (검색,한정판,상품리스트,정렬), 리뷰를 받고 4개였던 각각의 View들을 하나로 합치고 분류를 쿼리스트링으로 동작하도록 만들었다.
Cart API
- 장바구니 추가(POST) 기능에서
F object를 통해 이미 Cart가 존재할 시 수량 +1 코드 구현 - 장바구니 조회(GET) 기능에서
aggregatemethod를 이용한 장바구니에 담긴 상품의 가격 총 합계 구현
연휴 기간에 나는 주문, 백엔드 팀원인 강일님은 장바구니를 맡기로 역할 분담을 했었는데, 주문 기능이 장바구니에서 객체를 불러올 수 밖에 없어서 어쩔 수 없이 같이 구현하게 되었다. 2주차 월요일 통째를 이 기능을 만드는데 사용하였다.
장바구니 추가 부분을 실제 조말론 사이트에서 실행한 결과, 같은 상품을 장바구니에 또 추가하였을 때 새로운 객체가 생성되는 것이 아닌 수량이 1 증가하는 것을 확인했다. 여기서 DB에 직접 접근하여 계산을 하도록 도와주는 F object를 알게 되었고 이를 이용해 수량 +1 코드를 구현할 수 있었다.
장바구니 조회도 마찬가지로 장바구니에 담긴 상품 가격의 총 합계를 출력해야 한다는 Blocker가 있었다. aggregate를 통해서 접근해야 된다는 것은 알고 있었지만 상품의 가격이 장바구니의 field가 아니라 product의 field라서 구현에 애를 먹었는데, F object 안 따옴표 안에서도 __(더블 언더스코어)로 역참조가 가능하다는 사실을 멘토님한테 듣고 해결했다.
Order API
- 주문하기
장바구니 Data를 들어와 주문/주문상품 Table에 추가(POST), 장바구니 Table Data 삭제(DELETE), Transaction을 통한 무결성 보장
- 주문 내역 조회(GET)
- 주문 취소(PATCH) - 주문/주문상품 Status 변경, Transaction을 통한 무결성 보장
장바구니 기능의 구현으로 이전까지 사용해보지 못했던 PATCH나 DELETE 메소드, 혹은 F object같은 각종 메소드를 접하고 나니 주문 기능 구현은 자동으로 속도에 불이 붙었다.
이 기능을 구현하면서도 새로운 개념을 접하게 되었는데, 하나는 주문 정보와 주문상품 추가, 장바구니 삭제를 한꺼번에 처리해 무결성을 보장하게 해주는 Transaction 메소드, 다른 하나는 주문이 확정되었을 때 장바구니에 있는 여러 상품을 주문 상품으로 create 해야하므로 bulk_create러눈 메소드가 그것이다.
검색을 하면서 해당 기능을 처음 알게 되었지만 장바구니 기능을 구현하면서 새로운 개념을 적용하는데 익숙해져서 그런지 금방 적응해 코드에 써먹은 점이 나름 놀라웠다.🤔
AWS
- RDS 생성,
mysqldump로 로컬DB dump 및 원격 host 서버에 삽입 - EC2 인스턴스 생성 및 배포
백엔드 팀원 전부 AWS 세션을 참고해서 인스턴스 생성, RDS 생성을 끝마치고 .pem 확장자로 가상 서버에 들어가 project repo를 클론받고 배포를 하는것 까지 마쳤다. 보안 규칙 생성과 포트 설정에는 강일님이 큰 도움을 주셨다.
원래는 강일님 서버로 프론트간 통신을 했으나, 강일님이 RDS 생성을 안하고 인스턴스에 MySQL을 설치해 사용해서 내가 생성한 인스턴스로 IP를 옮겼다.
S3 이미지 업로드는 강일님이 수고를 해주셨다.👍👍
마치며..
잘한점
1. 쿼리 최적화
쿼리 최적화 중 Eager Loading인 정참조 select_related와 역참조 prefetch_related 메서드를 알게 되어 코드에 적용하였다. 
원래는 쿼리는 생각도 안하고 Views.py에서 중간 테이블을 참조하는게 코드가 너무 길어 짧게 바꾸려고 하는 목적이었지만 이것이 쿼리 최적화에도 연결되어서 일석 이조의 효과가 났다.
2. 백엔드간 지식 공유
1번 내용과도 연결된다. 쿼리 최적화와 Q object F object aggregate annotate같은 여러가지 메서드들을 검색으로 먼저 알게되고 다른 백엔드 동기들에게 이런게 있다고 알려드렸다.
이중에서 F object는 물어보시는 분이 많아서 도와드린 것과(총 3분이 물어보셔서 도와드린 것 같다),
'장바구니 추가' 버튼을 한번 더 누르면 장바구니에서 수량이 하나 더 추가되는 기능을 if문으로 구현하신 것을 내가 사용한 get_or_create 공유하고 설명해 드려 최적화 해드린 것이 기억난다.
내 짧은 지식이 다른 분에게 도움이 된 것 같아 기분이 뿌듯했다.
아쉬웠던 점
1. 모델링 및 앱 분리
앞에 Modeling 부분에서 말했듯이 모델링을 할 때 디테일을 챙기지 못해서 2주차때 주문 기능 구현을 할 때 어쩔 수 없이 해당 field를 누락하고 개발한 것이 아쉬웠다.
그리고 프론트엔드간 최종 통신에서 S3에 이미지를 업로드하고 URL을 CSV에 업로드 했는데, 한글 파일의 인코딩 문제로 URLField의 200자 길이 제한에 걸려 DB에 업로드가 안되는 문제도 있었다.
앱 분리 관련해서는 중간 테이블 마이그레이션 오류로 인해서 User App에 장바구니, 관심상품 모델을 전부 몰아 넣게 되었는데, 이때문에 Cart, Wishlist API의 엔드포인트가 user/cart나 user/wishlist가 되는 불상사가 일어났다.
프로젝트 첫 주 월/화는 초기세팅과 모델링에 집중하고 완벽하게 마친 다음에 DB를 날리고 마이그레이션을 반복하는 일이 없이 기능 구현에 집중해야겠다.😥
2. 역할 분담
기능 구현을 할 때 팀원이랑 같은 파일을 공유해 작성한다면, merge 과정에서 충돌이 나기 마련이다. 이를 망각하고 플래닝 미팅에서 정한 1~8번의 기능을 순서대로 구현하는 것에 집중해서 연휴 기간에 충돌이 났다.
다행히도 백엔드 팀원인 강일님이 git rebase를 공부해 오셔서 브랜치 충돌 문제는 해결되었지만, 1주차때 앱 분리를 철저하게 하고 한 팀원이 하나의 앱을 담당하여 개발했다면 충돌날 일이 애초부터 없었다는 아쉬움이 남는다.
3. 착실하게 하지 못한 블로그
프로젝트 기간에 블로그를 3번 작성했는데, 연휴 기간이 없었다면 이마저도 못했을 거라고 생각한다. 알게 된 내용을 그때그때 메모에 적어서 잊어버렸을 경우를 대비하긴 하지만, 새로운 내용을 더 찾아보는 것 보다는 알게된 내용을 확실하게 내것으로 만드는 것이 중요한 만큼 블로깅을 하지 못한 데에 아쉬움이 남는다.
4. 프론트엔드간 소통 부재
백엔드는 기능을 개발하고 httpie나 Postman을 활용해서 직접 client 요청을 보내서 작동 여부를 확인한다. 하지만 프로젝트는 백엔드 혼자가 하는 게 아닌 법. 프론트엔드와 통신을 하는데 제대로 동작하지 않으면 그것이 무의미하다고 볼 수 있다.
2주차 막바지에 접어들어 더이상의 기능 개발은 중지하고 프론트엔드와 통신에 집중했는데 이 과정에서 소통이 제대로 이루어지지 않아서 내가 생각했던 기능과 프론트엔드가 이해한 기능이 다른 부분이 있었고, React의 fetch함수가 제대로 동작하지 않는 경우도 많았다. 1주일의 시작인 스프린트 미팅, 하루에 한 번 하는 데일리 미팅등 소통의 기회가 여러번 있었음에도 불구하고 이를 캐치하지 못 한 것은 아쉬움으로 남는다.
2차 프로젝트를 시작하며
1차 프로젝트가 끝나고 숨 돌릴 시간도 없이 회고록과 이력서를 작성하고 바로 2차 프로젝트를 시작하게 된다. 2차 프로젝트에는 소셜 로그인 OAuth과 유닛테스트, git rebase 세션이 존재한다. 1차 프로젝트때의 아쉬운 점을 해결해줄 세션이라서 기대된다.
잘한 점은 확실하게 내 것으로 만들고 아쉬운 점은 확실하게 고쳐서 1차때보다 더욱 의미 있는 2차 프로젝트가 되었으면 한다. 😄
