팀 협업 프로젝트 마감일을 지키기 위한 노력들
미국 개발자 일지
현재 10명의 엔지니어들과 6개월 프로젝트를 진행 중에 있다.
덕분에 지난 2주간, 마일스톤(Milestone) 첫 단계를 마감일 내에 마무리 짓기 위해 몰입하여 일하는 시간을 보냈다.
금요일까지가 데드라인이었고 다행히 목요일 저녁, 내 PR(Pull Request)를 마스터 브랜치(Master branch)에 병합(merge) 할 수 있게 되었다.
원래 PR은 이미 일주일 전에 다 했지만, 내가 작업한 레포지토리(repository) 코드를 아는 다른 팀원들의 피드백(PR review)을 받는 속도가 늦어졌다.
이후,
1. 특정 엔지니어랑 1:1 zoom meeting으로 실시간 코드 리뷰를 2번 받음
2. 나중에 합류한 다른 엔지니어 2명의 리뷰로 인해 코멘트가 한 번에 40개가 넘게 달림
이로 인해 최종 PR을 머지할 때는 코멘트 개수가 99개가 넘어 99+로 표시되었다.
사실 가장 이상적인 PR은, 여러 개의 코멘트가 필요 없이 1) 모든 자바독(Javadoc) 형식이 깔끔하게 정리되어 있고 2) 불필요한 빈 줄이 없으며 3) 코드 로직이 정확하여 PR을 작성한 엔지니어가 다른 엔지니어에게 설명할 필요 없이 바로 이해할 수 있는 구조다. 특히, 작은 코드 변화가 있는 작은 PR은 다른 엔지니어들의 승인(approve)을 받기에 가장 적합하다.
그러나 이번은 다른 엔지니어의 코드 변화에 의존하게 되면서
'마스터 브랜치(master) <- 다른 엔지니어 PR 브랜치 <- 내 PR 브랜치'와 같이 되어버렸고 그로 인해 PR도 엄청 커져버렸다.
결국 밥 먹는 시간과 가끔 짬 내서 운동하는 시간 빼고 밤 12시까지 계속 노트북을 붙들다가 겨우 제시간에 맞출 수 있게 되었다.
늦은 시간에 일을 한 걸 아는 다른 엔지니어와 이번 일을 통해 우리가 어떻게 하면 앞으로의 마일스톤을 조금 더 부드럽게 이끌어나갈 수 있을지에 대해 다음과 같이 토의했다.
1. PR 은 할 수만 있다면 최대한 작게 하기
2. 만약 PR을 작게 할 수 없는 상황이라면, WIP(Work In Progress) PR 이더라도 다른 엔지니어들에게 미리 피드백받기
3. 만약 다른 엔지니어들도 각자의 일로 바쁜 상황이라면?
미리 양해를 구하고 1:1 줌 미팅으로 시간을 잡아 실시간으로 코드 로직 설명하고 피드백 주고받기
4. 팀 내 데드라인 만들기
엔지니어마다 작업 스타일이 다르다. 어떤 분들은 미리 정해진 마감 기한보다 빠르게 작업을 완료하려고 하는 반면, 다른 분들은 데드라인에 맞춰 일을 진행하는 스타일로, 마감 기한 직전에 휘리릭 끝내버리는 경우도 있다.
후자의 경우, 그전까지는 느리게 진행하다가 데드라인에 가까워지면 갑자기 행동이 매우 빨라지는 경향이 있다. 그렇기에 팀 내에서 내부 마감 기한을 설정하고, 그 데드라인에 대해 매니저와 상의한다면, 앞으로 후자 스타일의 엔지니어들과의 협업이 더 원활해지지 않을까 싶다.
이 두 분들과는 이번에 처음 PR review로 이야기를 나누게 되었는데 엄청 자세한 코멘트를 남겨주시면서도, 내가 한 일들에 대해 고마움을 표현해 줘서 내가 더 고마웠다.
서로가 응원해 주는 분위기의 팀 속에 있는 것에 참 감사하다고 느낀 날아직도 배울게 많은 환경 속에서 일을 하는 건 정말 크나큰 축복이다. 개발자 일은 여전히 어렵지만, 애사심과 상관없이 이 일에 몰두하는 것이 점점 좋아진다.
물론 쉬지 못한 후폭풍으로 주말에 감기 몸살로 하루종일 고생을 했지만, 또 하나 이전보다 나아진 건 때로는 12+ 시간 일해도 이제는 괜찮다는 것. 그전처럼 허탈한 마음 없이 '그냥 해야 되니까 하는 일'이라고 생각하게 됐다.
옆에서 내가 일하는 모습을 본 부모님과 동생은 나에게 도대체 언제 쉬는 거냐고, 너무 일에만 매몰되지 말라고 말해줬지만, 아직 실력이 많이 부족하고 또 이렇게라도 정해진 기한 안에 끝낼 수 있다면 그걸로 감사하다. 때마침 이전에 적은 블로그 기록을 보니, 약 2년 전 글에 8+ 시간 일한다고 찡찡대는 글을 적었었다. 그때보다 좀 더 일에 대한 역치(?)가 높아진 것 같아서 좋다.
