우리에겐 그라운드 룰이 필요하다.

부캐의 일상은 계속 진행 중인데, 보통 금요일 밤 늦게 9시 넘어서 내려가서 토요일 오전 6시 정도부터 일을 시작하고 11시~4시 정도는 여름으로 접어들어서 시에스타를 즐기고 있다. 여름으로 넘어오면서 잡초들이 진짜 무섭게 자라는 것을 느끼고 있는데, 일주일마다 잡초가 다시 무성하게 자라는 것을 보고 왜 이게 잡초라고 불리는지를 새삼느끼고 있다.

처음 포도나무를 심었을 때, 부모님이 포도나무 바닥에 검은색 비닐을 깔아서 눌러주면 잡초가 번창하는 것을 방지할 수 있다고 알려주셨다. 사실 뭐 잡초 뽑는 게 어렵겠나? 운동삼아 하지 라고 생각하며 매주 잡초를 뽑았는데 이젠 한계에 부딪혔고(2시간씩 뽑으면 죽을 것 같다. 🤯), 2주전에 검은색 비밀을 깔아서 더 이상 잡초는 올라오지 않는다.

부캐의 일상과 함께 본캐는 프로젝트를 진행하면서 많은 것들을 느끼고 있다. 프로젝트의 완성이 결국 포도나무를 키우고 포도 열매를 맛보는 것이라면, 잡초는 뭘까? 내 생각에 잡초는 목표에 상관없는 의견이나 코드, 프로세스 등이다. 다양성도 중요하고 소수의견도 중요하지만 프로젝트를 진행함에 있어서, 그리고 일정이 매우 중요한 프로젝트에 있어서 그러한 것들은 의사소통 비용을 증가 시키고 협업과 생산성을 저해 시킨다.

프로젝트를 진행하면서 더 이상 잡초가 올라오지 않게 하는 바닥에 까는 검은색 비밀의 역할이 그라운드 룰(GroundRule)이다. 같이 일하는 개발자, 협업하는 개발자, 팀 내 개발자가 아닌 팀원들과 일할 때 반드시 필요한 것이 그라운드 룰이라는 것을 많이 느끼고 있다.

최근 진행하고 있는 프로젝트에서도 초반에 많이 헤매는 시간들을 보냈다. 나 역시 새로운 언어와 프레임워크의 Best Practics 를 가지고 있지 못한 상황이었고, 새롭게 합류하신 분들도 회사의 형식/스타일에 적응을 하고 있는 중이어서 같은 repository에 코드 작업을 해나가면서 많은 부분을 헤맸다. 그리고 회색영역들이 많았다. 에러코드는 어떻게 처리하며, 어떻게 project structure를 가져갈 것인지 등등. 그리고 이런 것들은 커밋과 PR리뷰가 정체되는 결과로 이어졌다. 그런 과정에서 우리는 우리의 프로젝트가 가져가는 스타일/정책들을 문서로 정리하기 시작했다.

예를 들면, spring 에서 controller 와 service에는 어떤 코드들이 담겨져야 하는지, 예외처리는 어디서 해야하는지, 특정 컬럼은 어떤 타입으로 써야하는지 등을 정의한 문서인데, 단순히 개발에 대한 부분만 써 있지는 않다. PR은 300라인 이하만 올립니다. 리뷰시 서로 수고했다고 말해줍니다. 같은 팀 내 리뷰나 협업 관련된 내용들도 있다.

이런 개발 관련된 그라운드 룰 문서를 만들어 놓았을 때 장점은 우리가 어떤 일을 할 때, 서로 정한 것을 슬랙이나 이메일을 뒤져서 찾을 필요가 없다는 것이다. 그리고 코드리뷰에서 어떤 논의를 할때 명확한 기준/레퍼런스가 된다.(물론 리뷰 안에서 새로운 그라운드 룰이 생겨서 문서 반영되기도 한다.) 그러다 보니 우리 스스로 이것이 매우 중요하고 소중한 문서임을 알게 되고 점점 더 발전시켜 나갈려고 노력하게 되는 것 같다. 우리의 그라운드 룰 문서는 README.md 의 제일 상단에 위치해 있다.

이 때 말로 그라운드 룰을 정할 수도 있는데 가급적 명시적이고, 서술식으로 문서로 적는 게 좋다. 명시적으로 짧게 적는 것도 좋긴 하지만, 명시적이라는 것은 매우 주관적이고 사람들마다 머릿속에서 생각하는 바가 달라서 다르게 행동하게 되는 것 같다. 그래서 서술식으로 적절한 예를 포함 하면서 구체적으로 적어 주는 게 좋은 것 같다.

다음 프로젝트에서는 그라운드 룰을 처음부터 깔고 시작할 것 같다. 그래야 잡초가 올라오지 않을테니까.