한주간 디자인과 퍼블리싱을 진행했다. 디자이너를 구했고, 함께하는 프론트엔드가 웹퍼블리셔 출신이라 초안이 빠르게 나왔다. 그리고 바로 퍼블리싱에 들어갔다.
기다림의 미학
디자이너가 디자인할 때까지 기다릴 순 없어 웹 퍼블리셔 출신 프론트엔드가 먼저 작업한 초안을 기준으로 퍼블리싱을 시작했다. 초안인 만큼 어떻게 다듬어질지 알 수 없어 윤곽만 먼저 구현하는 형태로 진행하기로 했다. 이때 한 가지 몰랐던 사실은 디자이너가 전적으로 디자인을 전담하는 게 아니라, 웹퍼블리셔 출신 프론트엔드 분이 초안을 잡고 디자이너가 일과시간 이외에 시간을 쪼개어 다듬어주는 과정이었다는 것. 팀프로젝트인 만큼 서로 할 부분을 나누고 시작했으나, 이 부분 인지하지 못해 웹퍼블리셔 출신 프론트엔드가 디자인하며 퍼블리싱하는 동안 나는 디자이너가 완성된 디자인을 주길 기다리며 여유롭게 시간을 보냈다. 프로젝트 시작 3일차에 이 부분을 인지한 후 레퍼런스를 서로 주고 받고 바로 제대로된 퍼블리싱을 들어갔다. 레퍼런스를 기반으로 우리만의 디테일을 만들며 작업했다. 프론트엔드 둘 모두 코드를 짜면서 디자인하는 게 익숙한 사람들이라, 그나마 다행?이었는지 모르겠다. 이렇게 늦게 인지하게 된 이유는 다른 것보다 git의 지분이 크다.
부딪혀야 산다
git에 비하면 디자인은 사실 아무 일도 아니었다. git 전략을 처음 마주한 나에겐 git은 신세계이자, 지옥이었다. git push origin master만 주구장창 쓰던 사람이 작업할 때마다 깃허브에서 이슈 생성하고 checkout, merge, pull에, branch따고 --rebase니, --no-ff니 별 옵션들을 다 써가면서 하려니 죽을 맛이었다. 기분상으론 디자인 작업 속도보다 git branch 만드는 데 시간이 더 걸린 듯하다. 처음 2일은 git을 좀 다뤄본 백엔드 분에게 수시로 물어가면서 적용했다. commit 내용도 통일, 이슈 명도 통일, 브랜치도 작업에 따라 동일하게 통일... 통일을 마주한 줄. 그렇게 일주일이 지나니 손이 자연스래 움직이기 시작했다. 더이상 레퍼런스 코드를 보지 않고, 내가 작업하고자 하는 것에 따라 이슈 생성, 브랜치 생성, 머지, PR, Conflict 등 적절히 대응해가기 시작했다. feature 브랜치가, develop 브랜치가 쌓일 때마다 뿌듯했다. 다만, 실수로 커밋 메세지를 잘못썼거나, 머지가 이상하게 되었을 때 등은 매우 섬뜩했다. 그래도 git은 과거 이력을 가지고 있으니 열심히 reset하며 정리했다.
Frontend's
할 일
- 로그인, 회원가입(크리에이터,일반), 상품등록/수정, 상세페이지 스킨(1,2,3) 등 API 추가, 목업 데이터 추가.
keep
- 역할 분담 먼저하기
problem
- 반응형 일정 이슈, git merge 시간(최신화),
try
- CI/CD 알아보기
