팀이 처음 만난 날부터 100일

우리 셋이 같은 저장소에 처음 커밋을 올린 날을 기준으로 하면, 100일이 넘었다. 마침 연초에 팀 회고를 짧게 했는데, 그 자리에서 나온 이야기들이 꽤 솔직해서 여기에 일부 남겨두려 한다. 물론 기술 블로그이니 기술 쪽 이야기 위주로.

처음에는 도구 선택이 가장 컸다

팀이 처음 구성됐을 때 가장 먼저 결정해야 했던 건 기술 스택이 아니라, 어떤 도구로 어떻게 소통하고 코드를 관리할지였다. 각자 이전에 다른 팀, 다른 방식에 익숙해져 있었기 때문에 당연하게 생각했던 관습들이 충돌하는 경우가 있었다.

예를 들어 커밋 메시지 형식. 누군가에게는 자유롭게 쓰는 게 당연했고, 누군가는 컨벤션을 먼저 정하자고 했다. 작은 문제처럼 보이지만 이런 것들을 초반에 합의하지 않으면 나중에 이력 추적이나 자동화 작업에서 불필요한 마찰이 생긴다. 우리는 초반 2주 동안 이런 기반 규칙들을 정하는 데 시간을 꽤 썼고, 그게 결과적으로 잘 한 선택이었다.

비동기 작업의 현실

세 명이 항상 같은 시간에 일하지는 않는다. 각자 집중이 잘 되는 시간대도 다르고, 병렬로 진행되는 작업이 있다 보니 PR 리뷰나 의견 교환이 자연스럽게 비동기로 이뤄졌다.

처음에는 이게 불편했다. 빠른 피드백을 기대하고 올린 PR이 몇 시간 동안 조용히 있으면 답답한 느낌이 든다. 그런데 시간이 지나면서 비동기의 장점을 더 많이 느끼게 됐다. 리뷰를 받기 전에 스스로 한 번 더 검토하게 되고, 즉흥적인 반응보다 생각을 정리한 의견이 오가는 경우가 많아졌다.

물론 정말 막히는 문제가 있을 때는 짧게 동기 미팅을 잡는 게 낫다는 것도 배웠다. 텍스트로 30분 동안 해결 안 되는 게 10분 통화로 풀릴 때가 있다.

100일이 지나고 남은 것

코드는 그 사이에 많이 바뀌었다. 초반에 빠르게 만들었던 구조 중 일부는 이미 리팩터링됐고, 처음에 중요하다고 생각했던 기능이 실제로는 별로 안 쓰인다는 것도 알게 됐다.

반면 팀의 작동 방식은 생각보다 안정적으로 자리를 잡았다. PR을 어떻게 쪼갤지, 리뷰 댓글을 어떤 수준으로 달지, 급한 픽스는 어떻게 처리할지. 이런 것들이 명시적으로 문서화된 것은 아니지만, 팀이 공유하는 암묵지가 됐다.

100일은 짧다면 짧고 길다면 길다. 다음 100일이 지났을 때 지금을 어떻게 돌아볼지 궁금하다.

— by slecs