서론

내가 개발 공부를 시작한지 어언 1년이 지난 시점 나는 드디어 팀프로젝트를 경험하였고 또 처음으로 시작한 팀프로젝트에 팀장을 맏았다. 그리고 오늘로 팀프로젝트를 마무리 하게 되었다. 내가 팀프로젝트를 진행하면서 느낀 점을 적어나가겠다.

처음은 의외로 순항?

사실 처음으로 우리에게 주어진 과제는 단 하나였다. 주어진 API를 활용하여 무엇이든지 한번 만들어보자, 였다. 그렇기 때문에 처음으로 회의를 할 때 정말 많은 말들이 오갔다. 주어진 API는 쇼핑몰 사이트를 만들기 위한 API처럼 보였기 때문에 우리는 가구 쇼핑몰을 만들기로 결정했다. 그 뒤로 일은 일사천리에 진행되었다.

우리는 NEXT_Furniture 라는 브랜드명으로 쇼핑몰을 개발하기로 결정했다.

프로젝트에서 사용된 로고

그렇게 처음은 잘 굴러가나 싶었다. 하지만 프로젝트를 시작하자마자 난관에 빠졌다.

프로젝트 초기설정은 어떻게??

바로 처음부터 난관에 빠졌다. 왜냐면 처음으로 팀 프로젝트를 진행하게 된다면 반드시 처음으로 세팅을 진행하고 모두가 같은 코드에서 시작을 하는 것이 통일성을 위해서 중요하다. 그렇게 해야 나중에 merge 작업을 할 때 그나마 쉽게 해결을 할 수 있다.

그렇기 때문에 먼저는 팀원들과 어떤 라이브러리를 사용하며 어떤 환경이며 각자의 환경마다의 .gitignore 를 설정해줘야한다. 결국 이런 것을 관리 하는 것이 팀장이 하는 일이기도 하고, 그리고 우리는 기본적인 베이스는 js scss 를 활용하여 제작을 하기로했다.

라이브러리는 기본적인 swiper.js 와 바닐라 자바스크립트에서 spa를 만들 수 있게 도와주는 라이브러리인 navigo를 사용하고 서버리스 함수 세팅을 위해서 vervel 을 사용하기로 했다. 그리고 번들링 라이브러리로 pacel 을 사용하기로 했다.

역량의 차이는 어떻게 극복했는가

하지만 기초적인 지식의 차이나 역량의 차이도 꽤 생겼기 때문에 scss를 모르는 팀원분들도 계셨기 때문에 3일정도의 학습 기간을 통해서 먼저는 서로의 역량 차이를 줄이기 위해서 각자의 실력차이를 좁히는 데 노력했다.

팀원들이 각자 학습을 하는 초반부의 나는 팀원들간의 작업을 조금이라도 편하게 도와주기 위해서 나는 먼저 api 호출을 담당하는 함수를 만들고 또 서버리스 함수를 도입하여 민감한 정보들을 숨기는 것으로 결정했다. 그렇게 나는 먼저 서버작업을 먼저 끝내기로 결정하고 그렇게 열심히 작업을 진행했다.

그리고 필요한 유틸리티 함수를 만들고 jsdocs 작업을 하면서 최대한 이해하기 쉽게 만들었다.

내가 작업한 jsdocs

팀원분들께서 긍정적인 피드백을 주셨다. 이런식으로 api를 통일화 해서 하나의 파일로 작업하게 되면 코드의 일관성이 있기 때문에 작업하기가 훨씬 수월했다고 말씀을 해주셨다. 그 때의 그 기분은 정말이지 뿌듯하면서 끝내줬다.

초중반 어느 정도 잡히는 윤곽

우리의 목표는 3주 안에 작업을 완료하여 주어진 프로젝트 기간 한달안에 작업을 미리 하여 남는 시간에 리팩토링이나, 최적화를 하는 것을 목표로 진행했고 우리는 그렇게 프로젝트 중반을 맞이 하면서 어느정도 페이지의 윤곽이 잡혔다.

프로젝트 페이지의 메인 화면

페이지의 레이아웃을 먼저 잡고 나서 작업을 하니 훨씬 쉽게 작업을 할 수 있었다. 그렇게 우리는 순조롭게 작업을 마치고 끝나는 것 처럼 보였다.

CONFLICT CONFLICT CONFLICT CONFLICT

하지만 각자의 작업물이 나오고 또 merge를 진행하는 과정속에 수많은 컨플릭트들이 생겼다.

작업을 하면서 컨플릭트를 해결하는데 예상외로 많은 시간을 쏟게 되었다. 어느 개발자가 말했다. 개발자의 일의 1/5 은 컨플릭트 해결을 하는 일이라고. 정말 많은 컨플릭트를 마주쳤다. 컨플릭트를 마주치는 것 까지는 괜찮았지만, parcel 번들러를 사용하게 되면서 약간의 진빠가 있었다.

class 중복 때문에 스타일이 이상하게 되어버리는 데요?

pacel 번들러의 특성상 하나의 파일로 합치는 과정이 있기 때문에 클래스 이름이 중복되어버리는 경우에는 해당하는 스타일이 이상하게 되어버렸다... 이 것도 해결하는 과정이 상당히 골때렸는데, 그냥 무식하게 각자 고유한 클래스를 설정하여 절대로 겹치지 않게 먼저 설정하고 밑의 작업 방식으로 하기로 결정했다. 그리고 불가피 한 상황에서는 그냥 하나둘씩 수정해야지뭐...

#app{
 .main-page{
 /// do something
 }
}

이런들 어떠하리 저런들 어떠하리 클래스명 때문에 아주 작고 사소한 진빠가 있었지만 이를 가엽게 여긴 팀원분들의 30분 마라톤 회의를 통해 해결을 해내었으니 누이좋고 매부좋은 일이지 아니한가?

배포하는 과정

사실 이 부분에서 굉장히 많은 골머리를 앓게 된다는 데 나는 솔직히 못느꼈다. vercel을 통해서 통합적으로 관리하고 서버리스 함수도 vercel로 굴리니까 그냥 단번에 되던데... 이 맛에 사람들이 다들 vercel 쓰나보다. 그냥 저장소를 연결해주기만 해도 알아서 preview 페이지 만들어주고 main으로 설정한 브랜치가 업데이트 되면 알아서 production 페이지 만들어주니... 이 얼마나 편한가. 대신 가격은 엄청 비싸지만.

죽음의 버그와 10선

디버깅 하는 과정도 상당히 어렸웠었다. 어디선가 예상치 못한 상황들이 생겨버리니 항상 긴장을 떼기 어려웠다. 디버깅 과정중 상당히 골때리던 버그가 있었는데, 메인 페이지에서 상품의 디테일 페이지로 넘어가지지 않았었다. 이유는 단순히 라우팅을 넘겨줄때 /product/ 하나를 빼먹었었다. 저런!

마무리 하면서

사실 지금 이 마무리 하는 글을 작성하면서도 추가했으면 하는 몇몇 기능들이 눈에서 아른거린다. 하지만 현실적인 어려움 때문에 구현하지 못한 것들도 있었다. 조금만 더 계획적으로 했으면 더 좋았을 것 같다. 게다가 다른 팀들이 진행한 것을 보면 나는 아직도 멀었다는 생각이 들었다... 나는 뭔가 체계적으로 단계를 설계하는 것이 아직은 어려운 것 같다.

다이어그램도 만들었으면 좋았을 걸... 왜 나는 밑에 이상한 걸로 대충 때우려고 했을까... 지금에 와서 반성하게 되었다.