[엘리스AI트랙] 2차 프로젝트 회고

🍸저쪽 손님께서 보내신 겁니다.

칵린이를 위한 칵테일 소개 및 추천 서비스

 

🚩프로젝트 목표: 칵테일 입문자를 위한 인기 있는 칵테일 정보 제공 및 자신만의 레시피 공유, 재밌는 칵테일 컨텐츠를 통해 칵테일의 진입장벽을 낮추고자 합니다.

https://github.com/ParkJungYoon/cocktailWebService

GitHub - ParkJungYoon/cocktailWebService: 칵린이들을 위한 칵테일 소개 및 추천 서비스 🍸

 

⚙️ 기술 스택

• Node.js, Express
• MongoDB, Mongoose
• Docker, Docker Compose, Nginix

---

💡프로젝트를 통해 배운 점

 

🖥️ 개발편

[ Refresh Token ]

• 사용 이유
  • 초반에는 Access Token만을 이용한 인증 방식으로 개발을 했습니다.
  • 이때 제 3자가 유효기간이 만료되기 전 Token을 탈취해서 사용하게 된다면 ‘우리 서비스는 보안이 좋다고 할 수 있을까? 사용자가 안심하고 서비스를 이용할 수 있을까?’ 라는 고민이 들었습니다.
• 목표: 서비스 보안 강화
• 문제 해결 과정
  1. 토큰의 유효기간을 30분~2시간으로 짧게 설정.
  2. 유효기간이 짧으면 다시 로그인을 해서 토큰을 발급받아야 하기 때문에 사용자가 서비스 이용에 불편.
  3. 로그인 시 Refresh Token을 발급하여 Access Token이 만료되었을 때 재발급 받을 수 있도록 구현.
• 결과 및 느낀 점
  • Access Token의 유효기간을 짧게 설정하더라도 로그인이 풀리지 않아 유저 사용성이 향상됐습니다.
  • 개발을 할 때 서비스 이용자가 신뢰할 수 있는 서비스를 만들어야겠다는 책임감을 가졌습니다.

📎 블로그 포스팅

 

[ Validation 라이브러리, Joi로 단단한 코드짜기 ]

• 사용 이유
  • 회원가입을 구현하며 클라이언트에서 이메일 타입과 비밀번호를 Validation을 함.
  • 서버에서 Request를 받을 때 body가 제대로 들어있는지만 확인.
  • 서버 측에서 postman으로 회원가입을 할 때 잘못된 형식의 이메일로 가입이 가능.
  • 외부에서 들어오는 입력을 항상 validation 하고 서버에서도 들어오는 데이터 타입, 형식을 걸러내야 한다고 판단.
• 목표: 외부의 입력을 validation 한다.
• 문제 해결 과정
  1. Joi로 Validation하는 부분은 미들웨어에서 함수 형태로 구현.
  2. 이때 올바른 형태이면 next()로 다음 회원가입이나 로그인 코드가 실행되도록 구현.
• 결과 및 배운 점
  • 처음 접하는 라이브러리를 공식 문서로 학습하고 프로젝트에 적용하는 방식을 배웠습니다.

📎 블로그 포스팅

 

[ mongoose 쿼리 최적화 ]

• 사용 이유
  • 한번에 모든 칵테일 데이터를 전달하다 보니 칵테일 정보를 조회하는 페이지에서 네트워크 지연이 생겨 유저가 칵테일 정보에 빠르게 접근하는 것이 불가능했습니다.
• 목표: 사용자가 조금 더 빠르게 정보를 받아볼 수 있도록 쿼리를 짜보자.
• 문제 해결 과정
  • 개발자 모드 네트워크 창을 확인한 결과 현재 칵테일 페이지의 응답시간은 669ms이었습니다.
  • 현재 populate 되어 있는 rank 필드를 인덱스를 걸어보았습니다.
  • 연결되어 있는 Document가 많지 않아 속도가 434ms로 개선되었습니다. 하지만 여전히 만족되지 않아 다음 방법을 생각했습니다.
  • mongoose 쿼리를 사용하여 Pagination을 구현했습니다.
• 결과 및 배운 점
  • 다음 결과 669ms 에서 109ms로 속도가 개선되었습니다.
  • 서비스의 확장을 고려했을 때 조금 더 최적화를 고민하고 공부해야겠다고 느꼈습니다. 초반에는 Cache의 사용도 고민했지만 칵테일 페이지에 실시간으로 반영되는 ‘좋아요’ 기능이 있어 적용하지 못한것이 아쉽습니다. 앞으로도 계속 리팩토링하고 공부해가겠습니다.

 

[ Docker, Docker-Compose를 이용한 배포 환경 구축 ]

• 사용 이유
  • 이전 프로젝트에서 배포 단계에서 VM을 사용했을 때 두 가지 불편한 점을 겪었습니다.
    1. 로컬 서버는 윈도우 OS 이지만 운영 서버는 ubuntu OS로 어플리케이션이 OS 환경에 종속적이기 때문에 배포한 후 오류가 생기는 경우.
    2. 코드가 변경되었을 때 원래 어플리케이션의 소스를 고쳐 배포하는 과정이 복잡하고 다시 배포하는 과정에서 에러 발생.
• 문제 해결 과정
  • 운영 서버에 Docker를 설치함.
  • 프로젝트의 react-app과 node-app을 띄움.
  • 직접 하나하나 CLI를 입력하여 Docker를 수행하는 것의 불편함.
  • 그래서 Docker Compose를 이용했고, 멀티 컨테이너 관리가 용이하게 됐습니다.
• 결과 및 느낀 점
  • 컨테이너 환경에서 배포했습니다.
  • 내가 가진 기술 스택을 팀원에게 ‘문서화’하여 전달하고 설명하여 협업하는 능력을 키울 수 있었습니다.

📎 블로그 포스팅

 

 

👩‍🏫 협업편

[ 팀 리드 경험 ]

• 팀 리더로서 나의 역할
  1. 프로젝트에서 '조율자'로서 역할을 수행했습니다.
  2. 팀원 개개인의 개발 진행 상태 관리와 팀 전체 진행 상황을 파악하고 계획을 수립하는 데 역할 했습니다.
  3. 그 결과 3주 프로젝트 이후 팀원에게 ‘부드러운 카리스마의 표본’ 이라는 피드백을 받았습니다.

 

[ Swagger를 활용한 API 명세와 개발 협업 ]

• swagger를 사용하여 API 문서화를 통해 프론트엔드와 협업을 진행했습니다.