프로젝트 회고 - 나홀로집

SYhwang·2023년 3월 6일
0

프로젝트 소개

  • 오늘의집을 모티브로 한 커뮤니티&커머스 사이트 프로젝트
    커뮤니티 기능을 중심으로 최근 증가하는 1인 가구 인테리어 수요를 충족시키는 것을 목표로 제작한 커뮤니티 & 커머스 사이트

  • 개발 기간 : 2023.2.24~2023.3.10


데모 이미지

데모 영상
메인 페이지main
글쓰기posting
포스팅 리스트homewarming list
포스팅 상세homewarming
즐겨찾기collections
소셜 로그인소셜로그인
상품 상세상품상세 상품담기
장바구니cart
결제payment
리뷰 작성상세페이지 리뷰쓰기



프로젝트를 진행하며

내가 담당한 구현 기능 : 포스트, 댓글, 즐겨찾기, 장바구니 기능

  • 포스트 글쓰기 POST API 구현

    • 로그인한 사용자만 작성할 수 있도록 JWT 토큰 검증
    • 프론트에서 formdata 형식으로 상품 이미지와 함께 글 정보, 상품 정보, 이미지 내 상품 위치를 전달받음
    • 전달받은 이미지를 미들웨어 단계에서 AWS S3에 업로드
    • 이미지 주소와 나머지 정보를 transaction을 이용해 DB에 저장하여 글 작성 완료
    • 이미지 업로드 이후 과정에서 에러 발생 시 S3 버킷에 업로드된 이미지를 자동으로 삭제하는 기능 구현
  • 포스트 리스트 조회 GET API 구현

    • class 형태의 쿼리빌더를 활용한 필터링, 페이지네이션, 정렬
    • 스타일별 필터 구현, 페이지별 조회 구현, 인기순/최신순 정렬 구현
    • 필터링, 페이지네이션, 정렬 시에는 기본값을 적용하여 들어온 값이 없더라도 에러를 방지함
  • 포스트 상세 조회 GET API 구현

    • JWT 토큰을 검증하여 로그인한 사용자는 해당 포스트에 대한 자신의 즐겨찾기 정보를 확인하고 포스트에 댓글을 달 수 있도록 하되, 토큰이 검증되지 않더라도 포스팅 조회는 가능하도록 구현
    • 포스트의 내용 및 관련된 정보를 DB 내의 여러 테이블에서 모두 JOIN 하여 한번에 조회할 수 있도록 구현
    • 포스트가 존재하지 않을 경우 404 에러를 반환하도록 구현
  • 즐겨찾기 CRUD API 작성

    • 즐겨찾기는 회원 전용 기능으로, 로그인 한 사용자만 사용할 수 있도록 JWT 토큰 검증
    • 한 포스트에 유저당 한 번만 즐겨찾기를 할 수 있도록 DB 테이블 내에 UNIQUE 제약조건 설정
    • 즐겨찾기 GET API를 구현하여 본인이 즐겨찾기한 포스트를 모아 볼 수 있도록 구현
    • 기획상 즐겨찾기는 생성/조회/삭제 기능만 기획하였기에 별도로 즐겨찾기 업데이트 기능은 구현하지 않음
  • 댓글 CRUD API 작성

    • 포스트에 달린 댓글을 조회, 포스트 내에서 댓글을 작성, 댓글을 삭제하는 기능을 구현
    • 댓글 작성과 댓글 삭제는 회원 전용 기능으로, 로그인 한 사용자만 사용할 수 있도록 JWT 토큰 검증
  • 장바구니 CRUD API 작성

    • 로그인한 사용자만 사용할 수 있도록 JWT 토큰 검증
    • 장바구니 수정 시 Query Params을 통해 장바구니에서 온 요청과 상품 페이지에서 온 요청을 구분하여, 한 API 내에서 상품수량을 각각 다른 방식으로 변경할 수 있도록 구현
      • 장바구니에서 요청이 왔을 경우 요청이 온 수량으로 DB 카트 테이블의 수량을 변경
      • 상품 페이지에서 요청이 왔을 경우 DB 카트 테이블의 수량에 요청으로 온 수량을 더하는 방식으로 구현
    • 장바구니에서 주문 버튼을 눌렀을 때 선택된 제품들에 대해 실제 DB 내의 카트 데이터에 선택여부가 반영되도록 하여, 해당 '선택상품' 은 주문을 취소하고 다시 장바구니로 돌아가더라도 선택되어 있도록 구현.
      • 주문 단계에서 중간에 장바구니로 돌아갔을 때 구매할 제품을 다시 일일이 선택하는 것이 귀찮은 행동일 것이라는 판단으로 기획하였음.



어려웠던 점

일단? 새로운 기술을 적용하다

이번 프로젝트에서는 카카오 소셜 로그인을 위해 외부 API를 사용하게 되었다. 처음 외부 API를 제대로 적용해 보는 터라 일 주일 가까이 로그인 적용을 하지 못한 상태로 전전긍긍하다가 카카오 인증 절차는 프론트에서 담당하고 그 이후 단계는 백에서 담당하는 방식으로 구현하였는데, (카카오 소셜 로그인 flow) 비록 내가 담당한 파트는 아니었지만 로그인을 담당한 백엔드 팀원과 계속 회의하면서 어떻게 구현하면 좋을지 논의했다. 주말에 나와서 하루 종일 코드 작성은 하지 않고 회의만 하기도 했다. 이 단계에서는 정말 눈앞이 캄캄하고 이걸 우리끼리 구현할 수 있을까...? 라는 회의감이 들기도 했었지만, 다른 코드를 참고하고 또 자료를 찾아보면서 어떻게 구현에 성공했다. 다른 팀은 외부 API를 여러 개 사용하기도 했다던데, 우리는 소셜 로그인만으로도 시간이 부족해 자괴감을 느끼기도 했다.

거기다 프로젝트 도중에 AWS S3, Docker와 같은 새로운 기술 스택을 학습하여 프로젝트에 반영하게 되었다. AWS S3의 경우는 사용자가 첨부한 이미지를 업로드 할 공간이 필요하여 프로젝트 중간에 회의를 통해 사용하기로 결정되었고, Docker는 백엔드 서버를 최근 널리 사용되는 컨테이너 기술인 도커로 배포하면 좋겠다고 하여 프로젝트 마감 단계에서 학습 후 적용해 보았다. 그러나 시간 부족으로 해당 기술들에 대해 제대로 학습하지 못하고, 우선 지금 당장 구현에 필요한 부분만 학습하여 적용했다는 점이 아쉬웠다.

서비스의 확장성

"이 서비스에 다른 기능을 추가한다면, 어떻게 해야 될 것 같아요?"
데이터 모델링 단계에서부터 마지막 코드 리뷰를 받을 때까지 나를 따라다닌 과제였다. 지금 당장 굴러가는 코드를 짜는 것보다, 추후의 유지보수와 기능 추가를 고려해야 한다는 것. 데이터 모델링 리뷰에서도 그 부분을 고민했고, 여러 번의 수정을 거쳤다. 추후의 확장성도 중요하지만 일정에 맞춰 프로젝트를 마감해내는 것도 중요하기에 어떻게든 타협해서 진행하기는 했지만, 정말 최선의 설계였는지는 아쉬움이 남는 부분들이 있다.

빠듯했던 일정 관리

프로젝트 매니저로 자원해서 호기롭게 일정 관리를 담당하게 된 것은 좋았으나, 내 담당 티켓을 쳐내고 개발하면서 전체적인 프로젝트의 작업 진행도와 팀원들 각각의 상황을 확인하는 데 많은 에너지가 들었다. 회의를 주관하는 것이나 발표에 있어 미흡하기도 했고, 프로젝트 마감일이 다가오면서 초조함에 티켓이 남아 있는 팀원들을 많이 재촉하기도 했다. 결과적으로 잘 마무리되긴 했지만, 더 잘 할 수 있지 않았을까? 라는 아쉬움이 남는다.



좋았던 점

프로젝트 매니징을 경험해 보다

  • 일정 관리를 담당하고 팀원들의 작업을 조율하면서, 프로젝트의 흐름을 더 자세히 보려고 했다. 매일 회의록을 작성하고 trello를 사용하며 단순히 '이 정도 진행되었구나'를 파악하는 것을 넘어, '실제 계획한 것'과 '계획대로 완료한 것'을 제대로 확인하기 위해 고민했다.

  • 각자 본인의 티켓별 마감 일정을 정해 표시하고, automation 기능을 활용해 마감 일정이 임박하거나 마감이 지난 티켓이 있으면 잘 보이도록 자동으로 색이 변경되도록 했다. 실제 처음에 티켓을 분배하면서 시간이 부족하지 않을까?라는 염려를 많이 했었는데, 최대한 마감에 맞춰 개발하고 일정상 안 될 것 같은 티켓은 다른 팀원에게 재분배 하는 등 오히려 좋은 결과가 있었다. 팀원들 모두 잘 따라 주었고, 마감일에 맞춰서 티켓을 마무리하려다 보니 생산성이 증가되는 결과를 낳았다!

  • 매일 오전 DSM을 진행하고 노션에 간단한 회의록을 작성하여 모두가 공유하였으며, 추가로 필요한 회의나 blocker를 기록하여 팀원들이 함께 고민할 수 있도록 했다. 첫 스프린트가 끝나고 2차 스프린트를 시작할 때에는 스프린트에서 부족했던 점, 좋았던 점, 지속할 점을 각자 회고하는 시간을 가지기도 했다.

  • 매일 회의를 진행하고 기록하면서, 각 팀원들의 진행 상황과 고민을 파악하고 공유할 수 있는 좋은 시간이 되었다.


소통과 협업으로 프로젝트 진행하기

  • 개발 과정에서 팀원들, 특히 프론트-백 사이의 소통을 개선하려고 노력했는데, 처음부터 회의에서 최대한의 컨벤션을 정하고 주고받아야 할 key나 정보의 형식까지도 미리 맞추는 api 문서에 대해 공유함으로써 프론트와의 소통에서 겪을 혼란이 많이 줄어들었던 것 같다. 또 프론트끼리, 백끼리도 컨벤션 스타일을 통일해 같은 자료를 다른 방식으로 naming 하는 일이 없도록 했다.
  • 또한 기능을 제작할 때, 특정 기능이 프론트에서 더 효율적으로 구현할 수 있는 부분이라면 프론트에서, 백에서 더 효율적으로 구현할 수 있다면 백에서 하기로 협의하고 최대한 그때그때 소통을 통해 분배하였다. 이러한 부분에서도 시간을 많이 절약할 수 있었다.



프로젝트를 마무리하며

모든 프로젝트가 그렇겠지만, 이번 프로젝트도 치열하고 힘들었다. 개발을 하면서 동시에 새로운 기술을 익히고, 프로젝트 매니저로서 일정 관리와 팀원들의 작업 조율에 힘썼고, 팀원들과 최대한의 소통으로 개발 과정에서 낭비되는 시간을 절약하고자 애썼다. 일정 관리 방식이 어찌 보면 귀찮다고도 할 수 있는 일이라 팀원들이 불만족스러울까 봐 많이 걱정했는데, 프로젝트가 끝나고 팀원들의 긍정적인 피드백을 받고 나서 울컥하기도 했다.

처음 접하는 외부 API와 새로운 기술 스택을 도입하며 많은 어려움을 겪었지만, 결국 팀원들과의 지속적인 논의와 자료 조사를 통해 극복하면서 소중한 경험이 되었다. 이번 프로젝트를 완수함으로써 앞으로의 프로젝트에서도 계속해서 소통, 협업, 기술 습득을 해나갈 수 있을 것이라는 자신감이 생겨났다. 이렇게 앞으로 더 성장하고 발전하고 싶다.

0개의 댓글