들어가며

6/6 ~ 6/22 까지 약 17일 간의 인생 첫 프로젝트가 끝이 났다. 뭔가 우당탕탕 끝난 것 같지만 그 과정에서 좋았던 점도 있고 아쉬웠던 점도 있어서, 곧 있을 최종 프로젝트를 잘 진행하기 위해 글로 정리해두려고 한다.

프로젝트 개요

프로젝트 주제는 깻잎 논쟁, 패딩 논쟁 등 요즘 유행하는 논쟁들 같이 간단하게 의견을 선택하고, 토론할 수 있는 토론 커뮤니티 서비스이다. 팀원들과 함께 프로젝트 주제를 고민하고 있었는데, 한 팀원이 이 의견을 냈다. 나는 주제를 듣자 마자 개발할 때 너무 재미있는 주제일 것 같아서 신이 났었다. (개발 과정에서 내 손으로 좋은 아이디어를 망치는 것 같아 아쉽기도 했다...) 이 프로젝트의 핵심 기능은 사용자가 논쟁 주제에 대해 글을 쓸 수 있고, 다른 사용자가 해당 게시물에 들어와 본인의 의견에 투표하고, 투표 결과를 보며 댓글을 통해 서로 의견을 교환하는 것이었다.
대략적인 프로젝트의 방향이 정해진 것 같아서 프로젝트 첫 날에는 어떤 방식으로 협업 할 지, eslint 와 prettier 룰은 어떻게 사용할 지, 브랜치 전략이나 컴포넌트 설계 방식 등 프로젝트를 진행하기 위한 전반적인 내용에 대해 회의했다.

• git branch 전략: 브랜치 전략으로 gitflow 전략을 사용했다. 예전에 이 그림을 봤을 땐, 뭐가 이렇게 복잡한가 싶었다. 그런데 팀원분이 쉽다고 설명해주셨는데 갑자기 이해가 쏙쏙 되는거다. 데브코스 하면서 느끼는 거지만 예전에는 엄청 어렵다고 느꼈던 기술이나 방법들이 알고 보면 엄청 쉽게 이해되는 것들이 있다. 아마 혼자 공부할 때는 어렵다고 느끼면 아예 이해를 안하려고 하지 않았을까 싶다.
• Jira 사용: Jira는 협업을 위해 실무에서 사용하는 엄청나게 어려운 도구라는 생각이 있었다. 팀원의 추천으로 프로젝트 기간 동안 일정 관리를 위해 사용했는데, 생각보다 쉽고 좋은 도구였다. 개인별로 해야 할 일을 나누고 현재 진행상황이 어떤지 확인할 수 있어서 좋았다.
• Atomic Design: 컴포넌트를 설계할 때 Atomic Design 패턴을 따라 설계하기로 했다. 강의에서 강사님이 사용하는 방법이라서 한 번 적용해보자 라는게 이유의 전부였다. 개인적으로 생각하는 Atomic Design 의 문제점은 어느 수준까지 추상화를 해야할까? 라는 점이었다. 높은 수준의 추상화를 위해서는 많은 시간을 투자해야했고, 프로젝트 기간이 짧기 때문에 일정에 대한 부담이 있었다. 실력이 높지 않아서 더 그런 것 같기도 했다. 그래서 프로젝트 중반으로 갈 수록 추상화는 신경 쓰지 않고 당장 내가 쓰기 위해 만드는 느낌으로 개발했다.
• 작업 분배: 작업은 구상해 놓은 페이지 단위로 진행하기로 했다.

디자인

디자인이 왜 통곡의 벽인지 알 것 같았다. Figma 를 사용해 팀원들과 함께 디자인을 해 보았다. 공대 남자 4명이 모여서 디자인 한 결과는 상당히 처참했던 것 같다. 심지어 멘토님께서는 첫 디자인을 보시고 프로젝트에 참여해서 디자인을 고쳐줘야 하는지 고민하셨다고... 겉으로 보이는 디자인 외에도 문제는 또 있었다. 디자인을 완성하고 팀원들끼리 지금 완성된 디자인은 참고만 하고, 추가하고 싶거나 변경하고 싶으면 각자 원하는 대로 하자고 얘기했다. 이게 프로젝트 마지막에 엄청난 고생을 몰고 왔다. 공통된 디자인이 없어서 페이지 별로 다시 디자인 리팩토링을 진행하느라 팀원분들이 고생하셨다. 만약 이미 완성된 디자인이 있었다면 개발할 때 훨씬 편했을 것 같기도 하다.

개발

각 페이지 별로 작업을 나누고, 공통으로 사용되는 컴포넌트부터 개발하기 시작했다. 컴포넌트는 무난하게 개발했던 것 같다. 필요한 컴포넌트가 있으면 만들고, develop 브랜치에 머지했다. 이 부분에서 약간의 문제가 있었다. develop 브랜치에서 feature 브랜치를 따서 컴포넌트를 만들고 있었는데, 이 컴포넌트에 다른 분이 만들고 있는 버튼 컴포넌트가 필요해서 버튼 컴포넌트가 완성될 때까지 다른 작업을 하고 있었다. 버튼 컴포넌트가 완성되고 develop 브랜치에 병합이 돼서 내가 만들던 컴포넌트에 사용하기 위해 해당 feature 브랜치에서 git pull origin develop 명령어를 실행했다. 그랬더니 그동안 develop 브랜치에 반영된 수많은 commit 들이 작업중인 브랜치로 넘어 왔고, 이걸 어떻게 해결해야 할 지 몰라서 멘토님께 도움을 요청했다.
일단 feature 브랜치에서 develop 브랜치를 직접 당겨오는 건 안된다고 한다. 이상적인 작업 순서는

1. git remote update 로 원격 브랜치의 내용을 업데이트하고
2. develop 브랜치로 이동해서 git pull origin develop 으로 원격의 내용을 가져온다.
3. feature 브랜치로 이동해서 git merge develop 을 실행해 develop 의 변경사항을 feature 로 병합한다.

인 것 같다. 뇌피셜이라 확실하지는 않다.

이렇게 해서 버튼 컴포넌트를 가져오려고 했을 때에도 똑같이 수많은 commit 이 딸려왔다. 이를 해결하기 위해서 git merge --squash develop 으로 스쿼시 머지를 진행했다. 이렇게 하면 그 수많은 commit 을 하나의 commit 으로 압축할 수 있다. 이렇게 하면 commit 은 하나로 줄지만, 파일 변경사항은 아직도 그대로였다. 이걸 해결하기 위해서는 git cherry-pick 명령어를 사용했다. cherry-pick 은 특정 커밋만 가져올 수 있는 기능이다. 이 기능을 사용해 버튼 컴포넌트가 있는 commit 을 가져와서 feature 브랜치에 병합했다. 이 때, 커밋 단위가 커서 다른 변경사항들까지 포함되어 있다면 cherry-pick 을 사용하는 이유가 없다고 느꼈다. 이래서 커밋의 단위는 작게 가져가라는 말이 나온 것 같다.

FormData

API 중에 프로필 이미지를 수정하거나 게시물 이미지를 첨부하는 기능이 있었다. 이 때, 데이터를 FormData로 전송해야 했는데 FormData에 대한 이해가 부족해서 하루 정도 시간을 날렸던 것 같다... FormData를 전달할 때의 헤더(Content-Type)에 관련된 내용이었는데, FormData를 전송할 때에는 이진 데이터가 전송될 수 있기 때문에 한 파일의 시작과 끝을 알 수 있어야 하는데 이 때 사용하는 게 Boundary 라고 한다. 만약 Content-Type을 multipart/form-data 와 같은 형태로 지정하게 되면 boundary에 관련된 정보는 포함되지 않기 때문에 FormData를 읽을 수 없다고 한다. 이를 해결하기 위해서 단순하게 Content-Type 속성을 제거했다. 관련해서는 이 글을 참고했다.

코드리뷰

하나의 컴포넌트가 완성되면 해당 기능에 대한 PR을 작성하고, 2명 이상 리뷰를 하고 문제가 없을 때에만 develop 에 병합하지는 규칙을 세웠다. 어느 정도 잘 진행은 됐는데, 가끔 PR의 단위가 너무 커서 리뷰하기 힘들 때가 있었다. 이건 개인의 잘못이라기보단 초반에 작업을 제대로 분류하지 않아서 생긴 문제 같다. 현업에서도 PR 단위를 크게 작성하면 리뷰해주시는 다른 팀원분이 힘드실 것 같다. 단위가 크면 리뷰하기 힘들고, 리뷰의 퀄리티가 낮아지고, 결국 성장 속도도 늦어지는 악순환이 생기지 않을까... 이래서 PR 단위도 작게 가져가야 하는 것 같다.

프로젝트 마무리

뭔가 많이 못한 것 같지만, 팀원 분들이 열심히 도와주신 덕분에 나름 프로젝트는 잘 마무리 한 것 같다. 더 잘 할 수 있었는데 하는 아쉬움은 있지만 그래도 이 정도면 첫 프로젝트 치고 나쁘지 않았던 것 같다. 앞으로 계속 리팩토링을 하고 싶은 욕심이 있어서, 꾸준히 팀원들이랑 얘기하면서 실제 서비스까지 한 번 가보면 좋을 것 같다.

좋았던 점

1. 새로운 도구를 사용해 본 것 Jira, yarn 등 평소에 사용하려고 생각조차 안했던 도구를 사용할 수 있어서 좋았다. 앞으로 새로운 기술이나 도구에 대해 열린 마음을 갖는 것도 중요할 것 같다.
2. 강의에서 배운 내용을 활용한 것 Tooltip 컴포넌트를 만들 때 기존에는 Tooltip 컴포넌트를 부모 컴포넌트의 상태에 따라 보여줬다 숨겼다 하는 방식으로 구현했었다. 이번에는 Tooltip 컴포넌트 자체에 상태를 만들어 관리하고, React 최상위 API를 사용해 children 을 조작하는 방식으로 재사용성이 나름 높은 Tooltip 컴포넌트를 만들었다. 강의에서 배운 최상위 API를 사용했다는 점이 뿌듯했다.
3. 문제가 생겼을 때 끝까지 해결해보려 한 것 Netlify로 배포하고 API 엔드 포인트를 가리기 위해 서버리스 함수를 사용했다. 서버리스 함수를 사용하는 과정에서 FormData 가 전달되지 않는 문제가 있어서 진짜 딱 하루 정도를 문제 해결을 위해 사용했던 것 같다. 결국에 해결하지는 못했지만 해결하려고 노력했다는 점은 좋았던 것 같다.

아쉬운 점

1. 초반에 계획을 제대로 세우지 않은 것 초반에 개발 시간이 없을까 봐 급하게 계획을 세우고 개발을 시작했다. 그랬더니 프로젝트 후반으로 갈 수록 회의하는 시간이 늘어나서 개발하는 데 쓰는 시간이 줄어들었다. 최종 프로젝트에서는 최대한 모든 프로젝트 계획을 수립하고 개발에 들어가도록 해야겠다.
2. 코드 리뷰를 제대로 반영하지 못한 것 시간이 없어서 코드 리뷰를 제대로 반영하지 못했다. 멘토님께서도 리뷰 많이 남겨주셨는데 거의 적용하지 못한 것 같다. 이 부분은 어떻게 해결할 수 있을까? 일단 내 실력이 늘어나야 시간도 늘어나고, 리뷰도 반영할 수 있을 것 같다.
3. Git 사용에 익숙하지 않은 것 오히려 개발 과정에서의 문제보다 Git 사용에서의 문제가 더 많았던 것 같다. 혼자 공부하고 혼자 프로젝트를 하다 보니 협업에서의 Git 사용에 익숙하지 않았다. 이 부분은 인프런 강의로 해결해야겠다.
4. 시간에 쫓겨 코드 퀄리티가 낮은 것 급하게 코드를 작성하다 보니 배운 내용을 제대로 적용하지 못한 부분이 있고, 실력이 늘고 있다는 느낌을 받지 못했다. 대신 전체적인 협업 프로세스를 느끼기에는 너무 좋은 기회였다.

정리

쓰고 나니까 이게 회고인지 뭔지 모를 글이 된 것 같다. 그래도 프로젝트 과정을 한 번 돌아보는 기회가 됐다는 것에 만족하고 다음 프로젝트에서는 아쉬운 점을 보완할 수 있게 노력해야겠다.

참고자료

https://muffinman.io/blog/uploading-files-using-fetch-multipart-form-data/