[project BODYLIKE] 회고록

Minjae JO·2022년 8월 28일

React frontend project BODYLIKE

BODYLIKE 시연 영상 보러 가기

우리 몸을 편안하게 만들어주는 일상 용품 커머스 사이트, BODYLUV 클론

10일 동안의 달리기

2022년 8월 16일 시작, 2022년 8월 25일 마무리

*프론트엔드 개발자 3명, 백엔드 개발자 2명, 총 5명의 개발자들이 함께하였습니다.

*글쓴이는 프론트엔드 개발자로 참여하였습니다.

*본 회고록은 글쓴이가 구현한 기능 위주가 아닌, 전체적인 프로젝트에 대한 이야기와 프로젝트가 진행됨에 따라 배우고 느낀 점 위주로 작성되었습니다.

기능 구현 사항 보러가기

프로젝트의 시작

1차 Sprint Meeting

사실 프로젝트가 막 주어졌을 때에는, 그저 맡은 부분을 최선을 다해 꼭 완성해야지! 하는 각오만 가득했습니다. 정작 그 '맡게 될 부분'이 무엇이고, 어떻게 일을 나누고, 어떤 일부터 시작할지에 대해서는 생각도 못 하고 있었지요.
10일이라는 짧은 시간에 사실상 한 사이트를 똑같이 클론한다는 것은 불가능함이 당연한데도, 팀원 모두가 그저 눈에 보이는 모든 부분을 다 구현해야겠다! 는 무리한 생각을 했습니다. 그런 상황에서 개발자 멘토님들 앞에서 스프린트 미팅이랍시고 서로 이거저거 해야한다는 식으로 회의를 했으니, 얼마나 황당하셨을까요(웃음).

결국 멘토님들의 도움으로 다음과 같이 User Flow를 생각해 본 뒤, 이에 따라 필수 구현 사항들을 결정할 수 있었습니다.

User Flow

user가 사이트에 처음 접속하여 메인 페이지를 봅니다.
메인 페이지의 상품 리스트, 혹은 내비게이션 바를 통해 카테고리별 상품 리스트를 봅니다.
마음에 드는 상품이 있다면 상품을 클릭해 상품 상세 페이지를 확인합니다.
상품 구매를 위해 로그인/회원가입 절차를 거칩니다.
상품을 담고 나의 장바구니로 이동하여 상품 수량을 조절하거나, 삭제하거나, 총 결제 금액을 확인합니다.
상품 구매 버튼을 눌러 주문/결제 페이지로 이동합니다.

메인페이지, 내비게이션 바, 상품 상세 페이지, 로그인/회원가입, 장바구니는 사용자 입장에서 필수!

기능별 티켓 생성 및 분배

기능 당 Trello 티켓 한 장, 기능 당 Git 브랜치 하나, 기능 당 PR 하나, 기능이라는 것은 곧 컴포넌트 하나라는 것이고...

위와 같이 멘토님께서 열심히 강조하셨던, 기능별 작업 분배.
하지만 처음엔 그저 트렐로의 티켓 생성을 '할 일 배분' 정도로만 생각했던 부족한 저... 깃허브 repo의 브랜치도 그저 페이지 단위로 만들면 되겠다! 하고 넘어갔던 저...
(이 때문에 각 프론트엔드 팀원들이 안고 있던 컴포넌트들을 merge전까지 서로 사용할 수가 없어 결국 필요한 컴포넌트의 코드를 복-붙하는 불상사가 발생하고 말았더랬죠...)

이 때에 기능과 티켓, 브랜치, PR의 연결성에 대해 하나도 이해하지 못하고 프로젝트를 시작하는 바람에, 프로젝트 막바지에 가서야 한번에 몰아치는 Merge와, 그 때문에 제각기 따로 노는 컴포넌트들을 수습하느라 얼마나 고생을 했는지 !

한 기능의 컴포넌트 하나 당 티켓 한 장, 브랜치 하나, PR 하나 !
공통으로 사용하는 코드들은 우선적으로 브랜치를 만들어서 PR 올릴 것 !

*위 방식으로 진행해야 코드 리뷰 및 Merge도 원활히 진행되고, 공통적으로 사용되는 컴포넌트를 다른 팀원들도 빨리 사용할 수 있음!

(그래도 첫 주에 고생한 덕에, 2차 스프린트 미팅 시점에는 제법 잘 분배된 트렐로 티켓들을 얻을 수 있었습니다.)

모든 팀원이 함께 활용하는 협업 툴

Github, Trello, Google spreadsheet, 그리고 화이트보드

당시 우리 프론트엔드 팀원들은 깃헙 컨플릭트 경험도 없었고, 컴포넌트화와 브랜치 생성에조차 익숙하지 않아 초반에 협업 툴 이용에 어려움을 겪은 것이 사실이었습니다. 하지만 프로젝트는 팀이지 않습니까? 우리 든든한 백엔드 팀원들 덕에 빠른 속도로 협업 툴에 적응할 수 있었습니다.

모두가 공용으로 접근할 수 있다는 점에서 Trello를 회의록으로도 활용하기 시작한 것은 훌륭한 결정이었습니다. 팀원들끼리 서로 무슨 작업을 하고 있는지 매번 물어볼 것 없이 회의록을 확인하면 되었고, 프론트엔드와 백엔드만의 일이 아닌, 공통적으로 챙겨야 할 일들도 쉽게 확인하고, 생각나는 대로 업데이트 해 둘 수 있었습니다.

특히나, 백엔드 팀원분들께서 고생해서 만들어주신 API 명세서가 얼마나 큰 도움이 되었는지 모릅니다.

구글 스프레드시트를 사용하여 팀원 모두가 언제든지 확인할 수 있는 명세서가 완성되었습니다. 서버의 엔드 포인트 주소가 바뀌더라도, 백엔드 팀원들이 최선을 다해 빠르게 업데이트 해 주어 프론트엔드 팀원들도 fetch 요청을 할 때 수월하게 작업을 진행할 수 있었습니다.

프로젝트 진행

모두의 Blocker, 통신 (feat. 소통)

통신 경험이라곤 기껏해야 로그인/회원가입이 전부였던 병아리 개발자들에게, 커머스 사이트의 처음부터 끝까지, 모든 부분을 서버와 통신한다는 것은 고통스러운 일이었습니다. 왜냐하면, 저 당시의 저희들은 쿼리스트링이 무엇인지도 몰랐으니까요 !

1차 스프린트 미팅이 끝난 직후의 프로젝트 첫 주는, 말 그대로 통신 고통이었습니다. 프론트 사이드에서의 사이트 모습은 그럭저럭 완성되어 가는데, 정작 서버에서 데이터를 어떻게 가져와야할 지를 몰랐습니다. 서버에서 데이터를 불러오려면 프론트에서 뭘 해야 하는지, 백엔드에서는 무엇을 해 주는 것인지, 어떠한 부분을 어떻게 질문해야 원하는 답을 얻을 수 있는지, 서로에 대한 이해가 너무나도 부족한 상황이었습니다.

프론트엔드 팀원들과 백엔드 팀원들이 서로간에 소통을 하는 게 아니라, 각 분야의 개발자 멘토님들만 붙잡고 있던 어느 끝에, 결국 소통을 위한 '대통합 회의'가 이루어졌습니다. 저 역시 모두가 모여 질의응답을 하는 시간의 필요성을 너무나도 체감하고 있었기에, 너무도 반가운 시간이었습니다.
백엔드 팀원 한 분께서 Flow Chart를 다시 그려봐야 할 것 같다고 제안하셨고, 프론트엔드 팀원 한 분께서도 클라이언트와 서버간의 통신 시나리오가 필요함을 지적해 주셨습니다.

질문들이 봇물 터지듯이 쏟아져나왔습니다. 프론트엔드는 백엔드가 어디까지 해 주는지, 해 줄수 있는지를 몰랐고, 백엔드 역시 프론트엔드에서 할 수 있는 일과 하지 못하는 일을 몰랐습니다.

구현하고자 하는 기능을 제대로 작동하게 하기 위해서는 어느 포인트에서 서버와의 통신이 필요한지, 원하는 데이터를 얻으려먼 어느 엔드포인트로 가야 하는지, 서버에 어떤 식으로 요청을 보내야 맞는 데이터를 보내줄 수 있는지 등, 프론트엔드에서는 이해하고 있지 못한 부분들에 대해 가능한 많은 질문을 했습니다.

결과적으로 이 회의 이후, 꽉 막혀 있던 머릿속의 한 켠이 틔이는 듯 했습니다. 짧은 회의 한 번으로 프론트와 백이 서로 하는 일을 모두 이해할 수 있는 것은 아니었지만, 적어도 프론트엔드와 백엔드가 끊임없이 소통해야 한다는 사실을 알았고, 현재 우리가 함께하고 있는 프로젝트에서는 어떤 포인트에 대해 이야기해야 하는지를 알 수 있는 귀중한 시간이었습니다.

비록 그냥 보기에는 정리되지 않고 화이트보드에 그저 의식의 흐름대로 그려진 플로우차트이긴 하지만, 우리 팀이 저 사진 한 장의 플로우차트를 통해 얻은 것은 눈에 보이는 그 이상의 것들이었습니다.

url을 관찰하라.
백엔드와 끊임없이 소통하고, API 주소를 거침없이 물어보라.
DATA로 가는 길이 보인다 !

2차 Sprint Meeting

2차 스프린트 미팅 전 대대적인 회의를 거친 덕에, 프로젝트에서 앞으로 남은 할일이 조금은 정리된 상황에서 스프린트 미팅을 진행할 수 있었습니다.

둘째 주는 빠른 시일 내로 필수 기능 개발을 마무리하고, 더 욕심내서 추가 기능을 구현하기보단 현재 구현된 기능들이 잘 작동하는지, 서버와의 통신에 문제는 없는지 체크하고, 각 브랜치(기능) merge 후 모든 프론트엔드 팀원들의 로컬 컴퓨터에서 동일하게 잘 작동하는지 등을 확인하는 것 위주로 방향을 잡았습니다.

백엔드 팀원분들은 RESTful하게 API주소를 결정하는 것에 박차를 가했습니다.

Merge 요청이 아니라 PR입니다

프로젝트가 막바지에 다다를수록 마스터 브랜치에 Merge를 향한 열망(?)은 점점 커져만 갔습니다. 마음은 조급한데, PR을 작성에 리뷰 반영에, 다시 PR 작성에 리뷰 요청에... 하염없이 merge만 기다리는 merge 댕댕이가 된 기분이었습니다.

하지만 merge가 되지 않는건 멘토님의 탓이 아니라, 다 저의 탓이었지요...
프로젝트 시작 때 티켓 하나당 기능 하나, 기능 하나당 PR 하나라고 말씀하셨던 멘토님 말씀이, 프로젝트 2주차에 접어들어 PR과 리뷰와 merge가 활발하게 이루어질 때에야 이해된 것이죠.
페이지별로 브랜치를 생성하는 바람에, 컴포넌트 하나에 200줄이 넘어가는 브랜치의 PR을 작성하면서, 리뷰해주실 멘토님께 어찌나 죄송하던지 !

PR은 귀찮은 것이 아니라 스스로의 작업물을 위해 해야 할 일이고,
PR하면 리뷰를 받을 수 있다는 것은 설레는 일이며,
좋은 PR에 merge가 함께합니다.

하지만 PR과 멘토님의 리뷰가 진행됨에 따라, 저는 github이라는 것이 점점 재미있어졌습니다. 그저 로컬 작업물을 리모트에 옮겨두는 곳이라고만 생각했었는데, 여러 사람이 하나의 브랜치에 하나의 작업물을 만드는, 팀 프로젝트라는 과정이 드디어 체감되기 시작했습니다.

팀팀팀, 팀 프로젝트 (feat. github, conflict)

프로젝트를 진행하면서 git에 대해 느낀 점을 솔직히 말하자면, git은 정말 신기하고 대단한 것 같습니다.
이거 왜 하지? 어느 부분에서 남기지? 싶었던 commit도 왜 남기는지, 어떤 부분들에 남겨야 하는지 서서히 감이 오기 시작했습니다.

처음에는 작성하고 다시 쳐다보지도 않았던 내 PR을 이제는 누구보다 열심히 보고, PR내용과 내가 push한 코드가 합당한지, 놓친 부분은 없는지 여러 번 확인하게 되었습니다.
또한 그만큼 팀원들의 PR과 코드도 보기 시작하게 되었습니다.
commit과 change된 코드, PR이 같이 움직이도록 통제할 수 있게 되어가니, github을 이용한 팀 프로젝트가 굉장히 즐거워지기 시작했습니다.

Team 프로젝트에서는 '나만' 하는 일은 지극히 일부입니다.
내가 통제하고 있는 것 같은 부분도, 사실은 팀과 하나의 완성본을 위한 일입니다.

처음으로 내비게이션 바의 merge가 이루어졌을 때, 프론트 팀원들과 얼마나 설레했는지 모릅니다. 컨플릭트에 대한 우려와는 별개로, 내가 작업한 컴포넌트가 팀원들의 로컬 컴퓨터에, 또는 내가 작업하지 않은 팀원들의 컴포넌트가 내 로컬 컴퓨터에 나타난다는 것이 너무 신기했습니다. 물론 처음 pull 받은 직후의 작은 router 컨플릭트에도 벌벌 떨긴 했지만 말입니다(웃음).

첫 컨플릭트를 겪은 후, 프론트엔드 팀원들과 함께 모여 컨플릭트를 최소화하자는 의견을 나누었습니다. 자기 로컬에만 존재하는 작업물에서는 당연히 컨플릭트가 나지 않겠지만, 확인이 소홀해지기 쉬운 공통적인 코드들, Router, index, common, variables 및 API 주소 같은 부분은 push 하기 전 최대한 다른 팀원들과 미리 확인할 수 있도록 하였습니다.

컨플릭트는 피할 순 없어도 줄일 순 있습니다.
너무 무서워하지 말아요 !

프로젝트 마무리

뫼비우스의 Merge

프로젝트 첫 주의 통신 고통에 이어, 둘째 주의 merge 고통이 닥치고 말았습니다.
브랜치를 페이지 위주로 나누었던 만큼, 한번에 merge되는 코드 양이 어마어마했고, 그 많은 코드들을 제 로컬에 Pull 했을 때 문제가 발생하지 않을 확률은...

프론트엔드 팀원들과 사전에 충분이 이야기해두었다고 생각 했음에도, 문제는 발생하였습니다. 여전히 놓친 부분이 많았습니다.
API 경로가 Mock 데이터로 맞춰진 채로 merge된 브랜치도 있었고, common css나 variables에서 물리는 부분들도 발생했습니다. 심지어 각자의 로컬에서 만들었던 컴포넌트명이 겹치는 부분까지 있었습니다.

Merge만 되면 모든 것이 완성될 줄 알았는데, 크나큰 착각을 하고 있었던 것입니다. 심지어 이미 Merge된 브랜치에도 여전히 계속해서 수정 사항이 발생했고, 다시 PR하고 리뷰를 반영한 후 Merge를 받아야 했습니다.

(이게 맞나 싶을 정도의 엄청난 재 merge의 향연)

프로젝트 경험이 처음인 저와 팀원들 입장에서는, 이 전혀 예상하지 못했던, 끝날 듯 끝나지 않는 Merge와 최적화 작업이 정말 당황스럽고 힘든 일이었습니다.

결국 한 팀원의 로컬 컴퓨터에 모여 앉아 팀원 모두가 머리를 맞대고 대대적인 수정 작업을 거치게 되었습니다. 여러 명이 같은 코드를 보고 있으니, 그제야 다 수정했다고 생각한 부분에서도 계속 수정해야할 코드가 보였습니다.
특히 API 주소가 통일되지 않은 부분이 많았고, 미처 지우지 못한 console.log, 통신 테스트 시 사용하고 그대로 남아 있는 token 등이 많았습니다.
프로젝트 마감일이 다가옴에 따라, 마음이 급해져 코드를 꼼꼼히 정리하지 못한 것이었죠.

이 지옥의 Merge 수습을 경험한 날, 미리 체크하지 못한 모든 부분들이 마치 주마등처럼 스쳐가더군요(웃음). 그래도, 아, 다음 프로젝트에는 이러한 부분들을 미리 체크해둬야겠구나 ! 바빠질수록 팀원들과 더 열심히 소통해야겠구나 ! 하는 한편의 깨달음도 얻을 수 있었습니다.
체력적으로도 정신적으로도 모두가 힘들었지만, 사실 배울 수 있는 것이 더 많았죠.