1. About Project
2주 짧은 기간 안에 "쇼핑몰 웹 서비스 제작하기"
1차 프로젝트는 엘리스 측에서 프로젝트 주제 및 구현 과제를 정해주었다. 학습과정에 포함된 커리큘럼이기는 하지만, 그동안 배운 웹기초의 내용들을 실전에 적용해 볼 수 있는 좋은 기회였다. 첫 팀 프로젝트인 만큼 창의적인 목적과 목표를 가진 웹사이트를 만들겠다는 마음가짐보다 최대한 기본 기능을 완벽하게 구현하고 기능을 추가하는 방향으로 가는 걸로 팀원들과 얘기를 나누고 프로젝트를 시작했다.
여러가지 브랜드의 운동화들을 카테고리 별로 검색하여 구매 및 판매 할 수 있는 반응형 웹 사이트
팀 이름 '쇼미더코드' 를 따와서 쇼핑몰 이름도 '쇼미더슈즈'로 정했다.
백엔드 파트를 맡은 이유
아직 React 수업을 듣기 전이라서 프론트/백엔드 개발자 중 하나를 확실하게 정하지는 않았다. 하지만 이후에 프론트엔드 개발자를 지원하게 되더라도 이번에 백엔드의 메커니즘을 확실하게 경험해보면 전체적인 웹의 운영방식을 이해할 수 있는 좋은 기회가 될 것이라고 생각해 백엔드를 맡았다.
기능체크리스트를 통해 반드시 구현해야하는 기능들 놓치지 않도록 확인
상세기능을 명세해 바로바로 체크하며 기능을 구현해나갔다.
2. 기술 스택
+ mongoDB Atlas 활용
1주차 초반에 프론트엔드 팀원 중에 한명이 로컬환경에서의 mongoDB 테스팅에 문제가 생겨서 이 부분에 대해서 다같이 고민을 했었다. 당장 mockup 함수를 생성해 테스팅을 진행하기에는 시간적으로 어려움이 있었다. 그래서 mongoDB의 데이터베이스를 업로드하여 관리할 수 있는 하나의 클라우드 서비스인 mongoDB Atlas를 찾게됐고 팀원 모두가 테스팅할 수 있는 환경을 세팅했다.
3. 작업하며 배우고 느낀 것
1) About Code
userId 등을 query, params 처리 하는 것은 보안적으로 위험하다
코치님의 피드백을 듣고 자료를 찾아보니 RESTful API에서는 동일한 자원에 대해 CRUD 요청을 하더라도, 요청한 클라이언트의 권한에 따라 다르게 동작하도록 구현할 필요가 있다고 한다. 기존의 URL query string parameter에 요청메시지를 담는다면, 인증에 필요한 username, id, password 등 민감 정보가 그대로 노출될 수 있으므로 보안상 좋지 않다. 그래서 Request Body parameter에 정보를 넣는 것으로 수정했다. URL query string parameter에 비해 URL에 직접 노출이 되지 않으므로 보안이 좋다고 할 수는 있겠지만, 잘 쓰지 않는 방식이라고 한다. 그래서 다음에 혼자서 토이프로젝트를 진행할 때는 추천되는 방식인, Request header에 값을 넣어서 요청하는 방식을 활용해봐야 겠다.
참고자료_DELETE request 요청/처리/응답에 관한 소소한 고민
카테고리 다중 필터링
이번이 첫번째 프로젝트인만큼 코드적으로 얘기할 부분이 많지 않은 건 사실이다. 기본적인 상품 및 브랜드 CRUD API를 만드는 데 중점을 뒀기 때문이다. 그나마 코드적으로 활용을 했다 라고 말할 수 있는 부분은 상품을 카테고리(브랜드명/남성/여성/키즈)에 따라 조회할 수 있게 다중 필터링 기능을 구현한 것이다.
...
(아직 작성중...)
...
중복부분은 개발 중 리팩토링
개발을 하면서도 상당히 많이 반복되는 부분이 있었는데 그걸 인지하면서도 리팩토링을 하지 않았었다. 그런데 지금 생각해보니 중간중간에 중복부분을 반복함수로 빼줬다면 코드가 훨씬 깔끔해지고 실제 비지니스만 담당하는 로직이 읽기 쉬워졌을 것이다.
처음으로 작성해본 API문서
직접 개인 노션에 API 문서를 생성해 팀원들에게 공유하였다. API 문서 틀은 여러 회사들의 API DOCUMENT를 참고하며 프론트엔드 팀원들이 보기 편하도록 구체적으로 작성하였다. 다행히도 팀원들이 내가 작성한 API 문서 틀을 마음에 들어해서 계속 활용할 수 있었다.
2) About Team
GIT - 1PR 1COMMIT
이 프로젝트를 진행하기 전에 삼성사이트를 클론코딩하는 스터디를 진행한 적이 있다. 그때 다른 한명의 팀원과 함께 GIT PR을 올려보며 조금이나마 익힌 후 이번 프로젝트를 진행해서 훨씬 수월했다. ( 그때 나도 팀원도 PR을 올려본 경험이 없었기 때문에 PR에 관한 글을 작성해 공유했었다. 링크참고_팀원에게 도움이 됐으면 하는 마음에 작성했던 글 )
어쨌든 다시 돌아와서!
이번 프로젝트는 다른 사람들에게 내 PR을 통해 내가 어떤 기능을 추가했고 어떤 코드를 수정했는지 등을 한눈에 알아보게 하고 싶었다. 그래서 1PR 1COMMIT을 프로젝트 첫날 팀원들에게 건의했다. 초반 이틀 정도는 다른 팀원들이 하나의 PR에 10개 이상의 commit을 반영해서 코드를 보기 힘들었었다. 하지만 바로바로 의견을 공유하고 팀원들도 잘 수용해줘서 후반부로 갈수록 코드 리뷰하기도 수월했었다.
백엔드 간의 활발한 코드 리뷰
서로 코드 리뷰 후 상대방이 approve를 해야 merge 할 수 있도록 백엔드만의 규칙을 정하여 진행했다. 그렇게 하니, 서로 어떤 부분을 개발하고 있고 고민하고 있는 부분이 뭔지 수시로 알 수 있었다.
- 팀원의 코드에 대해서 한번에 이해가 잘 되지 않는 부분 적극적으로 질문하기
- 팀원 또는 나의 코드에서 잘못된 점 리뷰를 통해 수정하기
- 해결되지 않는 문제에 대해 같이 고민해보기
나는 리더형? 팔로워형?
결론은 리더형인것 같다! 물론 우리 팀의 팀장님이 워낙 팀원들의 얘기를 잘 들어주고 잘 이끌어주셔서 내가 더 자유롭게 의견을 낼 기회가 많았던 것도 있다. 다만, 예전에 방송에서 사람들을 인터뷰하고 진행을 했던 경험들 때문인지 매일 스크럼회의에서 나도 모르게 팀장님을 도와 회의를 이끌어 나갔던 것 같다. 내가 제안한 의견들에 대해서는 꼭 팀원들의 동의를 구한 후에 실행했기 때문에 서로 기분 상할일 없이 2주를 잘 보낼 수 있었다.
4. 맺으며
이번에 백엔드 파트를 맡으며 POST MAN 사용에도 익숙해지고 API 문서도 작성해보고 MVC 패턴 기반으로 개발해보며 백엔드의 기본을 다질 수 있어서 유익했다. 무엇보다 중요한건 프론트엔드 파트와 소통을 해볼 기회가 있었다는 점이다. 2차 프로젝트때는 프론트엔드를 담당할 계획인데, 그때 백엔드와 어떻게 소통해야 할지 확실히 감을 잡을 수 있게됐다. 역시 시작이 반이라고 하나의 프로젝트를 완성해보니 코드나 소통 여러 부분에서 자신감을 얻게 됐다.
