팀 협업 경험의 회고

2022년 초, 개발을 시작할때 처음 팀 프로젝트를 진행하면서 겪었던 일들에 대한 내용과 그 이후에 대한 회고입니다.

개발을 시작하고 팀 프로젝트를 하게 되었다.

개발자로서 취업을 위한 포트폴리오를 만들기 위한 팀으로 다른 개발자들과 처음으로 소통하며, 개발을 경험하게 되었다.

개발자의 커뮤니케이션을 잘해야 된다는 이야기를 들었었기에, 여러 개발 블로그나, okky와 생활코딩 페이스북과 같은 곳에서 많은 개발자들이 개발을 시작하고 팀 프로젝트를 경험하면서 겪는 여러 문제점들을 보면서 고민을 하게 되었다.

우선적으로 사전에 얻은 정보들을 바탕으로 팀 프로젝트를 성공적으로 끝내기 위해서 팀장을 맡았다.

그리고 내가 아는 범위에서의 문제점들이 일어나지 않도록 다음 문제점들에 대한 장치들을 만들었다.



1. 공동 목표의 부재: 진짜 목표는 무엇인가?

많은 팀들이 ‘팀 프로젝트를 하겠다.’ 라는 목표로 모였고 여러가지 이유로 프로젝트를 끝맞추기전에 팀이 와해 되었다. 대부분의 사유가 ‘공동 목표의 부재’ 였다. 개발자가 사이드 프로젝트를 팀으로 진행하는데에는 다음과 같은 여러 이유가 있다.

우리의 경우에는 프로 개발자가 아니라 이제 막 취업을 하기 위한 주니어라고 부르기에도 어려운 그냥 취준생 뿐이다.

많은 팀들이 사이드 프로젝트를을 하면서 초반 기획 단계를 너무 크게하다 보니 실제 개발단계에서는 힘이 빠졌고, 재대로된 개발 방식이나, 소통 방식 등을 소훌히여기고 어영부영 하다가 끝나게 된다.

그래서 우리는 실제로 서비스 중인 사이트에서 우리가 하고자하는 기술 스택과 일정 등을 고려해서 최소한으로 서비스를 정하고, 해당 범위에 벗어난다면 해당 부분들을 과감하게 자르고 진행을 하였다.

또한 개발자들과의 처음으로 커뮤니케이션을 하면서 개발을 하는 경험을 중요한 가치로 여기고, 해당 부분들에 대해서 많은 고민을 하여 결정했다.



2. 커뮤니케이션 방식의 부재: 몰입 할 수 있는 환경

우리는 서로의 목표를 확인하고, 어떤것을 만들지를 정했다. 다음으로는 각자가 각자의 작업들에 대해서 몰입을 할 수 있어야 했다. 개발을 하면서 일어 날 수 있는 문제점들에 대해 생각을 해보았다.

이러한 문제점들을 바탕으로 서로가 개발 외적인 부분에 있어서 생길 문제점들을 최소한으로 줄이기 위해서 개발을 위한 도구들을 정하고, 여러 작업 규칙들을 정하게 되었다.


2.1. 작업 환경 갖추기: 의사소통 도구 선정

원격으로 프로젝트를 진행하기 때문에 가장 중요했던 부분이다.

최종적으로 ‘디스코드’를 사용하기로 했다. 위에서 나열한 내용들을 모두 무료로 무제한으로 사용할 수 있었기때문에 선택을 하였다.

깃허브 또한 웹훅으로 레포지토리를 연결해서, 서로의 작업 상황을 공유할 수 있었다.


2.2. 작업 환경 갖추기: 문서화

회의는 디스코드의 음성채널과 채팅을 사용했는데 해당 내용을 정리해둘 문서 관리 툴이 필요했다.

개발 내용이나 규칙을 정해놓고 항상 기억하기 어렵고, 회의를 하면서 업데이트된 최신 내용이 무엇인지 잊어버리게 된다.

문서화 도구로는 모두가 공유 가능하고, 작성이 가능하며, 일관되게 문서를 작성할 수 있는 툴이 필요했고 학창시절에 사용하던 노션을 사용하기로 했다.

깃허브 작성 규칙
깃허브 작성 규칙

깃허브 이슈 규칙
깃허브 이슈 규칙

커밋 규칙
커밋 규칙

파일 구조와
prettier
파일 구조와 prettier

데이터베이스
데이터베이스


2.3. 작업 환경 갖추기: 깃허브로 코드 현상 관리하기

노션에 규칙들을 정리해두고, 디스코드에 웹훅을 연결하여 서로의 작업현황을 확인하면서 효율적으로 작업을 할 수 있게 세팅을 해두었었다.

깃허브 사용은 서로의 작업 상황을 한눈에 알아볼수 있게하고, 이슈을 추적할 수있어야 되는것을 목표로 삼았다.

다음과 같은 플로우로 진행을 했다.

  1. 자신의 작업에 대한 브랜치와 이슈를 생성한다.

    • 각 이슈들은 깃허브 이슈 템플릿에 맞게 생성한다.

    • 커밋을 할때에는 이슈에 대한 번호를 남겨서 어떤 작업인지 추적을 할 수 있게 하고, 작업한 커밋내용을 상세하게 기록한다.

  2. PR시에 해당 코드를 리뷰하고 모두 리뷰를 맞치게 되면 Dev 브랜치에 Merge한다.



3. 작업 분배: 최고 효율 만들기

팀원별로 원하는 작업이 있을 것이고, 작업 분량을 어떻게 분배를 할 것인가에 대한 부분에 대한 고민이 있다. 모든 작업은 다음 두가지 작업으로 분류 했다.

사전 작업을 둔 이유로는 공통 컴포넌트 A가 포함된 B페이지가 있다면, A와 B 작업은 동시에 진행이 불가능 했다. 그허기 때문에 순차적이면서 병렬적으로 작업을 할 수 있도록 분류를 했다.

또한 난이도에 따라서 작업시간이 달라진다. 각 작업 단위를 난이도에 따라 분류하여 서로의 개발 시간 싱크를 맞출 수 있도록 했다.



4. 짧은 회의: 개발에 더 많은 시간을!

회의가 길다.

이 부분은 처음부터 알게 된 것은 아니고 한 일주일 정도 프로젝트를 진행하면서 느끼게 되어서 팀장으로서 개선을 시키기 위해서 노력을 했다. 프로젝트를 시작하고 회의를 하면서 느꼇던 점으로 30분 이내에 끝날 회의들이 길게 늘어선다는 것이다. 논의할 문제에 대해 서로의 의견을 이야기하고 선택을 하면 되는 문제에 대해서, 일일이 회의때마다 해당 내용들을 설명하고 해결할 방안들에 대해 그때 그때 찾아보고 결정했기 때문이였다.

그래서 항상 회의전에 ‘이슈 내용’과 함께 ‘해결 방안’들을 같이 나열하고 해당 해결 방안의 장단점을 나열한뒤에 실제 회의에 들어 와서는 해당 내용들에 대한 의견을 받고 선택하는 과정으로 줄였다.

결론

지나고 나니 이 당시 프로젝트의 경험이 매우 좋았던거 같다. 이후 프로젝트에서 커밋 규칙이나 파일구조 등 여러 규칙들을 자동화하는 것에 대해 고민했고 husky나 hygen, commitlint등과 같은 자동화 라이브러리들을 사용했고, Jira와 같은 이슈관리 프로그램도 사용해 봤다.

하지만 현업에서나, 다른 사이드 프로젝트를 경험해 보았지만 이 프로젝트 만큼 모두가 규칙의 필요성을 인지하고 지킬려고 하지 않았다. 현업에서 일을 해보니, 일정과 프로젝트의 여러 이해관계때문에 규칙을 있어도 지키지 못하기 일수 였기에 현재 이슈가 생겼을때 문제 추적은 안되고, 각 파트의 진행상황은 구두로 물어보며 개발적으로 해결하기 위한 고민은 뒷전이였고 돌아가게 하는데에 급급했다. 이 문제는 상당히 악순환이 되었는데, 조그만한 문제가 추적자체가 안되니 해결하는데 까지의 리소스가 엄청나게 많이 투입된다는 점이다.

회사에 다니면서 ‘이게 맞을까?’, ‘원래 이렇게 했을까?’ 라는 생각이 들어서 과거에 해왔던 내용들을 정리를 하다보니 이 프로젝트에서 협업에 대한 고민을 해보지 않았다면 원래 개발은 이렇게하는구나 하고 당연시하게 넘겼을 것 같다는 생각이 든다. 규칙이 없는 주먹구구식 프로젝트를 경험을 해보니, 이 프로젝트를 진행할때에 이론적으로만 봤던 문제를 직접 경험해보니 왜 개발자에게 커뮤니케이션 능력이 중요하고 이러한 규칙들을 지속적으로 연구해가는지 알겠다. 현재 상황에서 개선시키기는 쉽지않겠지만, 가장 우선시하게 개선시킬 수 있도록 해야할 것 같다.