✔ 1차 클론 프로젝트가 끝났다. 2주 동안 모두들 너무 고생하고 정신없이 보낸 시간이었다. 특히 개발자가 되는 과정속에서 경험한 첫 프로젝트였기에, 느낀 점이 정말 많았다. 프로젝트 소개와 더불어 느낀 많은 점들에 대해 자세히 써보고자 한다.

WECODE 1차 클론 프로젝트

1. Introduction

• 클론 대상 사이트는 내가 선정했던 왓챠피디아라는 사이트였다. 이는 영화, 드라마 및 책을 추천하는 서비스이다. 박스 오피스 순위, 넷플릭수 순위 추천 이외 사용자가 평점 및 댓글을 남김으로써 사용자의 취향 분석을 통해 맞춤 컨텐츠를 추천하는 서비스를 제공한다.

2. 프로젝트 소개

• 프로젝트 클론 사이트 : 왓챠피디아

• 프로젝트 팀명: 영차피디아

• 프로젝트 기간: 2021.05.10 ~ 2021.05.21

• 프로젝트 팀 구성원

  • Front: 임유진, 이다슬, 전용민(PM)
  • Back: 김하민, 최대환

3. 사용 기술

• Front-end: HTML, CSS, JavaScript, React(CRA), Sass

• Back-end: Python, Django, My SQL

• 공통 협업 도구: Git & Github, Trello, Notion, Slack

4. 담당 역할

• 영화 상세 페이지

  • 영화 상세 페이지 layout 및 UI 구현

  • path parameter를 통한 메인 페이지와의 동적 라우팅 setting

  • 보고 싶어요 버튼 클릭시, 코멘트 모달창 생성, 댓글 작성 및 삭제 (GET/POST)

5. 잘한점 and 배운점

잘한점: 서로간의 배려 및 소통

• 중간발표, 최종발표때도 얘기했지만, 프로젝트 진행 기간 동안 우리 팀은 서로간의 배려가 너무 좋았다. 전에 멘토님, 영은님과의 러브 면담에서도 프로젝트 진행간 팀의 분위기가 정말 중요하다고 들었는데, 이 부분에 대해서는 100점 만점의 100점이다 (그 이상!!)
  또한 매일 아침 스탠드업 미팅을 통해 백, 프론트 간의 작업 진행 상황을 공유하고 피드백을 주며 속도를 조정하면서 함께 나아가는 모습은 정말 잘했다고 생각한다.

배운점: Back, Front간 소통

• 프론트와 백과의 사용 용어가 달라 서로간의 이해가 부족하여 소통하는데 시간이 좀 걸렸다. (객체(F) = 딕셔너리(B), 배열(F) = 리스트(B) 등..) 또한 나 스스로 통신간 사용될 키값, method (POST, GET, DELETE)에 대한 개념이 부족하여 이해하는데까지의 시간이 오래 걸렸다. (밤 늦게까지 설명해주신 하민님... 감사합니다 ...) 적극적인 소통 및 협업을 위해서는 내 영역뿐만이 아닌, 다른 영역의 기본 base는 알아야 할 필요성을 느끼게 되었다.

6. 스스로에 대한 아쉬운 점

다기능 보다는, 하나의 기능이라도 완벽히 구현하여 내것으로 만드는것

• 프로젝트 마감 당일날, 멘토 준식님께서 해주신 말씀이며 많은 공감이 갔다.
  상세 페이지에서의 필수 구현 기능으로 지정한 기능들은 보고싶어요, 별점, 슬라이드, 스크롤이벤트, 댓글이었다. 하지만 나는 하나를 완벽히 끝내고 넘어가기 보다는, 동시 다발적으로 구현을 진행하며 다된 기능을 쳐내는 방식으로 진행했다. 이렇게 진행하다보니 완벽히 내 것이 되는 것보다, 말그대로 기능 구현에만 치중되기에 시간에 쫒기기 일쑤였다. 때문에 코드에 대해 생각하는 시간이 줄어들어 배움의 자세로서는 적절하지 않다는 것을 나중에서야 깨닫게 되었다. 처음 개발자를 시작했을 때 생각했던 하나의 언어라도 완벽히 다룰 줄 아는 개발자가 되자 라는 생각처럼, 하나의 기능이라도 완벽하게 알고 자신있게 말할 수 있도록 노력하자.

Git branch 관리

• branch 관리를 철저하게 하지 못했다. 레이아웃, 혹은 컴포넌트의 merge 시간이 지연되면서 (개판인 내 코드때문에....) 기존 작성하던 브랜치에서 추가로 브랜치를 생성하여 작업을 진행했다. 물론 초반에는 '관리하면 되겠지~!' 하는 생각에 해당 방법을 진행했지만.. 결론은 갈수록 난장판이었다. 멘토님분들께서 말씀하셨듯이 권장하지 않는 방법이었는데도, 굳이 해보고 쓴 맛을 봐야 깨닫는 나란... (말좀 잘 듣자...) 추가로 commit 포맷 및 관련 사항을 일정하게 지켜서 작성해야 남이 봐도 잘 이해할 수 있게 관리하는 것이 중요함을 느꼈다. (merge 후 내 commit 내역을 보니 좀 가관이었다..)

데드라인 전, 컴포넌트 별 통신이 아닌 전체 작업물 기준으로 예비 통신을 해볼것

• 컴포넌트별 fetch api 통신이 아닌, 내가 담당한 상세 페이지 전체 fetch api test를 미리 하지 않아 이 부분에서 시간을 많이 뺐겼다. 전체 그림을 보고 작업을 해나가야 하지만 해당 컴포넌트를 우선적으로 작업한 후, 뒤늦게 로직을 수정하려다보니 일이 번거로워지고 시간만 더 잡아먹었다. 때문에 전체 작업물 기준으로 백에서 받아올 데이터 형식의 Mock 데이터로 미리 통신 테스트를 준비하는 치밀함이 필요하다고 생각한다.

7. 개인 소감

• 프로젝트를 진행하면서 PM을 맡긴 했지만, 계획성이 부족해 마감 및 발표 당일까지 수정 사항이 생겨 PM으로서의 역할에 충실하지 못해 팀원들에게 많이 미안했다. 또한 프로젝트 진행 도중, 담당 파트에 대해 무조건 혼자서 해결하려다보니, 해결 안되는 문제를 혼자서 안고 끙끙 앓다가 작업에 대한 진척도가 늦어진 적이 있었다. 이를 통해 프로젝트는 혼자가 아닌, 팀원들과의 협업으로 이루어지기에 담당 영역에 대한 책임감은 좋지만 심할 경우 오히려 독이 됨을 잘 알 수 있는 계기가 되었다.

저희 팀 프론트를 캐리해주시고 많은 도움을 주신 에이스 유진님, 항상 밝은 모습으로 팀원들에게 좋은 기운을 주신 다슬님, 수줍음이 많으시지만 알고보면 재밌으신 대환님, 유쾌함과 함께 거리낌없이 즐겁게 대해주신 하민님, 좋으신 네분 모두와 함께 할 수 있어서 너무 값진 경험이었습니다. 감사합니다. 😊😊