>wecode 1차 프로젝트 회고:KLUSH

💡References
이 프로젝트는 러쉬 코리아를 참고하여 학습목적으로 만들었습니다.
이 프로젝트에서 사용한 이미지는 모두 unsplashed에서 가져온 이미지입니다.

1. 프로젝트 소개

• 핸드메이드 코스메틱 브랜드인 러쉬 코리아의 웹사이트를 모티브로 한 프로젝트입니다.

• 프론트엔드 Github
  김태현, 김희열, 정새미

• 백엔드 Github
  김현영, 이병재, 황수민(me!)

• 개발 기간
  2021.04.12 ~ 2021.04.23 (2주)

2. Stack - Backend

Python, Django, bcrypt, pyjwt, MySQL, AqueryTool, AWS EC2, AWS RDS

Communication Tool

Slack, Trello, Github, Postman

모델링

AqueryTool을 이용한 ERD 작성

3. Endpoint

3-1. 내가 구현한 엔드포인트

• 회원가입 유효성 검사 구현
• bcrypt 사용 PW저장 및 JWT 사용 token 전송
• 유저 인증 Decorator 로직 구현
• 리뷰댓글 C.R.U.D API 생성
• 장바구니 C.R.U.D API 생성
• DB업로더 fakeseed 생성

3-2 배포

• AWS EC2에 가상환경 구축하여 프로젝트 배포
• AWS RDS에 데이터베이스 구축
• Backend Frontend 통신

4. 기억에 남는 코드

4-1. get_or_create / update_or_create

새로운 메소드를 사용하여 코드가 확 줄어듬과 동시에 가독성도 올라가서 가장 기억에 남는 코드이다.
수정 전 코드도 이미 리펙토링을 거쳐 다듬어진 상태(라고 믿음)였기에 어느정도 만족하고 있었지만, 새로운 메소드를 알고 그걸 적용시켜 본 후로 이전 코드들은 아무런 미련없이 지울 수 있었다. 신세계를 발견한 느낌이었달까!

그리고 위 코드에서 아쉬운 점을 꼽자면 오류코드를 더 심지 못한 부분이다. 예를 들어 존재하지 않는 상품/옵션 이거나, 상품과 매칭되지 않는 옵션이 선택 될 경우에 대해 '애초에 화면에 그렇게 표출 될 일이 없으면 오류도 발생하지 않을 것이다' 라고 생각하고 오류코드를 작성하지 않았었고, 이 부분에 대해 연우님께 질문을 드렸었다. 여기서 언제나 착한 유저만 존재하는 것은 아니며, 우리가 의도하지 않은 경로로 접근해서 오류가 발생할 수 있다는 사실을 알게 되었다. 언제나 백엔드의 최종목표는 '서버가 터지지 않게 하는 것'을 잊지 말고 다양한 관점에서 생각하고 오류코드를 작성해야 함을 잊지말자!

4-2. fakeseed

우리 팀은 fakeseed와 csv를 모두 만들어 사용했다. 이중 fakeseed를 내가 작성했는데, 생각보다 활용이 많이 되지 않아 아쉬웠던 부분이다.
왜 활용이 되지 않았는가에 대해 짚어보면, 모든게 만든 사람인 내가 django-seed에 대한 절대적인 이해도 부족으로 인해 일어난 일이다.

• django에서 제공 해 주는 기본 모듈(name, address, password, nickname 등)에 대한 학습 부족
  • product_name 에 사람 이름이 나옴
    (django에서 제공하는 기본 모듈이 더 있다고 한다. 아마 제공 모듈에 product_name도 있지 않았을까? 공식문서를 찾아보자!)
  • 회원가입 시 작성해놓은 validation에 맞지 않는 무작위의 fake data 생성
    (이 부분도 설정이 가능하다고 함!)
  • 제공 모듈에 hashtag가 없어 결국 숫자를 입력하는 것으로 작성
    (이것도 무작위 단어를 넣을 수 있는 방법이 있지 않았을까?)

이런 부분들 때문에 우리 팀은 csv를 만드는 것으로 노선을 갈아탔었다.
다음 프로젝트때는 fakeseed에 대해 위 부분을 좀 더 보안 해서 사용 해 보고 싶다.

5. 아쉬웠던 부분

우선, 백엔드에서 모델링 당시 기획했던 내용은 이렇다.
1. 한 유저는 제품 당 하나의 리뷰 및 별점을 작성할 수 있다.
2. 회원탈퇴 시 댓글과 이미지는 삭제되지만, 별점은 유지한다.

때문에 우리는 별점과 댓글이 서로 참조되지 않고 유저/상품과만 참조되는 모델링을 작성했고, 모델링대로 뷰를 rate와 comment 나누어 따로 작성하였다.


작성한 코드는 백엔드에서 httpie 및 postman으로 확인했을 때 이상없이 돌아가기는 했지만, 프론트에서는 댓글과 별점을 함께 POST, GET 해야 했기 때문에 프론트분이 많은 고생을 했었다.(결국 별점부분은 맞추지 못하였다)
백엔드에서는 별점과 댓글을 참조시키는 것으로 모델링을 수정할까 라는 얘기도 나왔었지만, 프론트에서는 이대로 진행 해 보겠다고 말씀을 주셨었다. 아마 백엔드에서 이미 다 짜놓은 코드를 수정해야 한다는 것에 미안함과 부담감이 있었던 것 같다. 추가구현 사항이었던지라 시간이 넉넉치 않아 하루만에 코드를 짜고, 프론트와 통신을 들어갔지만 FE/BE간의 이해도 부족으로 결국 미완성 상태로 남게 되었다. 기회가 된다면 리펙토링을 진행 할 수 있었으면 한다.

(댓글 작성은 되지만 백엔드 DB로 넘어오지 않던 별점..🥲)

6. 소감

우선 첫 프로젝트 시작 당시 '1인분만 하자'가 목표였는데, 그래도 팀에서 1인분의 몫은 해내지 않았을까 한다.
프로젝트 시작 전, 위스타그램 때까지만 해도 코드 한줄 제대로 못 짜서 항상 노트북 들고 동기들 괴롭히러(?) 다녔어야 했기 때문에 스스로 스트레스가 많이 쌓여있는 상황이었다. 그러다보니 코딩할 때 즐거운 마음 보다는 결과물이 나오기 전까지 상당히 많은 스트레스와, 두려운 마음이 더 앞섰던 것 같다.

하지만 이번 프로젝트를 진행하며 이제는 두려움보다는 즐거움이 조금 더 커진 것 같다. 2주동안 몰입해서 진행하다 보니 자려고 누웠는데 갑자기 오류 이렇게 수정하면 작동 되지 않을까? 하는 생각도 나고(물론 그 오류는 이때 했던 생각으로 잡히지 않았다. 다른 방법으로 수정했다.), 잠들려는 찰나 코드를 왜 이렇게 짰는지 설명 해 보라는 멘토님의 목소리가 울려퍼지는 덕에 의도치 않은 이미지트레이닝도 해 보고..! 이렇게 2주를 보내다 보니 스스로 조금씩 성장하는 모습을 볼 수 있었고, 덕분에 몸은 정말정말정말정말 힘들었지만 힘든 와중에도 즐겁다는 생각을 할 수 있었던 것 같다.

그리고 앞으로는 같은 팀원의 코드를 보는 시간도 가져보면 어떨까 싶었다. 당장 내가 맡은 부분을 구현하기 급했기 때문에 백엔드의 다른 팀원들의 코드를 볼 수 있는 시간이 없었다. 최종발표날 발표를 맡게 되며 그때서야 팀원들의 코드를 읽어보았는데, Query Parameter(키값 유무에 따라 정렬, 페이지네이션, 검색)와 같이 내가 아직 사용해보지 않아 잘 모르는 부분들이 있었다. 다음날 위코드에 오자마자 모르는 부분은 코드를 작성한 팀원에게 물어보는 시간을 갖긴 했지만, 조금 더 일찍 보았다면 하는 아쉬움이 남는다.

마지막으로, 아직 백엔드에서도 배울 점이 많지만 프론트에 대해서도 기본적인 지식은 어느정도 알고있어야 겠다는 생각이 들었다. 통신할 때 어떻게 대화를 해야 하는지, 그리고 통신 중 오류가 발생했을 때 서로의 코드를 보고 대충이라도 이해할 수 있었다면 좀 더 원활한 커뮤니케이션이 가능했을 것 같기 때문이다.