회고 일기 - 함께 성장하는 팀문화 만들기

나는 어떻게 협업을 준비했는가

데브코스에 들어오고 본격적인 팀프로젝트에 돌입했다. 이에 맞추어 팀이 변경되었고 2달간 진행되게 되었다. 첫 한 달은 리액트 과제가 진행되고 이후 한 달 동안 팀프로젝트가 시작된다.

이러한 일정에서 처음 한 달을 어떻게 준비하는지가 나한테는 중요하게 느껴졌다.

실제 업무를 생각했을 때도 새로 들어온 팀원은 팀에 적응하는 시간이 필요할 것이다. 이를 위해 온보딩이라든지 새로운 팀원을 위한 프로세스가 진행된다. 이러한 과정을 통해 하나의 팀으로 온전히 협업을 할 수 있게 된다.

이와 마찬가지로 우리가 진행하는 팀 프로젝트에서도 아무런 준비없이 바로 협업하는 환경에 처하면 어려움을 겪게될 것이라고 생각했다. 서로의 작업에 대해 신경쓰지 않기, 작업 내내 아무런 응답이 없다가 막바지가 되어서야 작업을 공유하기, 한 번에 거대한 작업량 내보내기 등 우리가 팀 활동을 하면 마주하게 될 여러 문제점이 발생할 것이다.

이러한 상황이 일어나는 것을 막고 싶었다. 그래서 협업을 미리 준비하는 과정이 필요하다고 느껴졌다.

함께 두려움을 없애기 Playground

해당 저장소는 완벽을 추구하지 않습니다. 같이 학습하며 충돌 상황을 미리 경험해보는 것을 목적으로 합니다.

우리는 왜 협업을 어려워할까?

개인적으로 우리 모두가 협업에 괜스레 어려움과 두려움을 느낀다고 생각한다. 특히 두려움이 문제가 되는 것 같다.

한 번도 해보지 않았기에, 혼자가 아닌 다른 사람과 함께 하기에 더더욱 쓸데없는 두려움을 느끼는 것 같다.

하지만 협업과 개발에 있어 대부분이 막상 한 번이라도 경험해보면 별거 아닌 경우가 많았다. 오히려 시간이 지나고 괜한 두려움 때문에 아무것도 하지 못한 걸 후회하게 된다.

그래서 나는 팀원들과 함께 이 두려움을 없애고 싶었다.

이를 위해 본격적인 팀 프로젝트하기 전에 협업을 위한 준비 단계로 React Playground Study를 만들었다.

해당 저장소는 리액트 관련 학습을 명칭하고 있지만 주요 목적은 다음과 같다.

• 함께 학습하기
• 프로젝트를 대비하여 충돌 상황에 대한 두려움 없애기

내가 팀내에서 주도해서 시작한 스터디였지만 팀원들에게 플레이그라운드에 대해 설득하는 과정이 필요했었다.

React와 관련된 학습이라는 명확한 목표가 없는 스터디이다 보니 처음에는 팀원들이 동기 부여와 필요성을 크게 느끼지 못했었다.

그래서 회고를 진행해야겠다는 생각을 하게 되었다.

회고에서 나는 플레이그라운드의 필요성과 나에게 우선 순위가 높은 이유를 설명했다.

플레이그라운드의 활용 방안에 대해서도 고민한 끝에 학습한 내용을 공유해서 팀원들에게 발표하는 방식으로 변경했다.

그렇게 해서 플레이그라운드에는 짧은 시간임에도 많은 지식 공유가 일어날 수 있었다.

React Playground Ground Docs

그리고 나에게는 해당 플레이그라운드의 존재가 프로젝트를 하면서도 큰 도움이 될 것이라고 판단되었다.

분명 프로젝트에서는 예상치 못한 문제가 발생할 것이다. 이를 해결하는 과정으로 프로젝트에서 작업을 진행하면 괜히 잘못되는 건 아닐까 라는 두려움이 생기게 된다.

하지만 플레이그라운드는 아무렇게나 사용해도 부담이 없어 맘편하게 연습을 할 수 있을 것이다. 이를 통해 나는 프로젝트를 진행하는 동안에도 플레이그라운드가 협업의 두려움을 없애는 역할을 할 것으로 기대했다.

이러한 준비 과정 속에 우리는 본격적인 프로젝트에 돌입하게 되었다.

나는 어떻게 협업에 임했는가

한 명이 작업한 것처럼

한 명이 작업한 것처럼 프로젝트를 완성하자.

내가 내세운 우리 팀의 목표이다. 다른 사람이 봤을 때 한 명이 작성한 것처럼 코드를 구성하고 싶었다.

이를 중요하게 생각한 이유는 나에게 가독성이 굉장히 중요한 요소였기 때문이다.

빠르게 읽히는 코드가 좋은 코드라는 생각을 갖고 있는데, 우리 모두가 정한 규칙에 맞는 코드를 작성하면 모두가 손쉽게 코드를 구성하고 읽으면서 빠르게 작업을 할 수 있을 것이다.

이를 위해서는 처음부터 우리 팀의 문화를 단단하게 가져가는 것이 중요하다는 생각을 했다. 이와 관련해서 많은 시행착오를 겪고 끊임없이 수정하는 과정을 거치게 되었다.

팀문화 만들어나가기

깃허브 활용

우선 작업 흐름을 깃허브 내에서만 가져가는 것을 목표로 했다. 처음 하는 협업으로 노션이나 슬랙 등 여러 도구를 활용하면 정보의 파편화가 일어나고 관리의 어려움을 느낄 것이라고 판단했다.

그래서 깃허브 내에 이슈, 디스커션, 프로젝트, 위키 등 제공해주는 기능들을 적극적으로 활용했다.

이를 통해 깃허브 내에서만 정보를 모아서 불필요한 요소를 최소화할 수 있었다.

문서화

깃허브 위키 내에서 모든 문서화를 이뤄나가고자 했다. 개발과 관련된 내용에 대해 팀 개발 규칙, 기술 스택, 트러블 슈팅을 추가하고 수정하면서 지속적으로 관리했다.

React Query 예시

물론 이와 같은 과정이 처음부터 제대로 이루어지지는 않았다. 초기 규칙에서 수정할 부분이 계속해서 생겨나기도 했고 새롭게 규칙을 추가하는 경우도 발생했다. 그래서 이러한 작업이 번거롭고 무의미하다고 느껴지는 구간이 발생하기도 했지만 이러한 작업은 시간이 필요한 부분이라고 판단했다.

그렇게 지속적으로 위키 문서를 만들어나가는 인내의 시간을 거치면서 나중에는 코드 리뷰에서 활용할 수 있는 단계까지 도달했다.

이렇게 팀원의 코드를 리뷰하는 과정에서 모호한 부분이나 규칙이 지켜지지 않는 부분은 위키 문서를 공유하면서 팀 내 규칙을 중요하게 여기도록 했다.

트러블 슈팅과 관련해서도 팀원분이 겪었던 어려움과 작업 과정을 정리된 문서로 확인하면서 내가 한 작업 내용이 아니여도 빠르게 파악할 수 있도록 했다. 이를 통해 프로젝트에서 내에서 반복해서 마주하게 되는 문제 상황을 없애나갔다.

작은 작업 단위

2일 이상을 넘기는 작업 단위는 최대한 지양했다. 아무리 중요하고 큰 작업 단위여도 최대한 잘게 쪼개서 작업을 진행하고자 노력했다.

이를 위한 방안으로 깃허브 내 마일스톤을 활용하여 주차별로 스프린트를 구성했다.

그리고 최소 1일 1 PR을 목표로 작업을 진행했다. 나의 경우에는 프로젝트 기간 동안 이슈 40개, PR 34개로 최대한 작은 작업 단위를 이루고자 했다.

내가 먼저 주도적으로

이렇게 우리 팀의 문화가 잘 형성될 수 있다고 생각하는 가장 큰 이유는 내가 먼저 주도적으로 했기 때문이라고 생각한다. 팀에 필요하다고 판단되는 부분은 주저하지 않고 이야기를 나누었다. 최대한 나의 의도와 목적을 순수하게, 솔직하게 드러내고자 했다.

그리고 책임감을 가지면서 작게는 코드 리뷰에서부터 나의 생각과 의견을 적극적으로 공유했다.

문서화와 팀규칙에서도 먼저 작성하면서 틀을 만들어나갔다.

이렇게 주도적으로 행동했기 때문에 팀원들에게 믿음을 주었다고 여겨진다.

다행히도 팀원 모두가 프로젝트 끝까지 열심히 참여해주면서 같이 성장하는 팀문화 속에 성공한 프로젝트가 되었다고 생각한다.

같이 고생하고 노력한 팀원들에게 감사함을 전한다..! 🙇‍♂️

• 배포: 혼콕
• 팀 회고: 회고