[시퀀스] 10명의 백엔드 개발자들은 어떻게 협업할까?

이러면 안돼요

💬서론

저는 현재 언더독레볼루션이라는 동아리에서 백엔드 리드로 활동하고 있습니다. 동아리 내에서 여러 프로젝트를 진행해왔지만, 이번에 저를 포함하여 10명의 백엔드 개발자들로 구성된 백엔드팀을 이끌며 대규모 프로젝트를 진행하게 되었습니다.  이 과정에서 개발자들을 어떻게 관리하고 협업을 하면 좋을지에 대한 고민을 하였습니다. 이번 글에서는 이러한 고민과 실행 방안에 대해 이야기를 하려고 합니다. 

 

🚨문제

1. 팀원 간 역량 차이  

 

동아리의 특성상 팀원들은 개발 경험과 수준이 다양했습니다. 일부 팀원은 Docker나 Spring과 같은 기술에 익숙하지 않은 반면, 경험이 많은 팀원은 기술에 어느정도 익숙했습니다. 이러한 역량 차이를 고려해야하기 때문에 팀의 작업 진행 속도와 역할 분담에 어려움이 있었습니다. 이러한 이유로, 팀원 간에  적절하게 역할분담을 하고 협업의 효율성을 높이는 관리가 필요했습니다.

2. MSA와 DevOps 경험 부족

팀원 대부분은 MSA를 처음 경험하는 상황입니다. Docker 이미지 생성과 배포, API 개발 및 연동 과정에서 이해 부족으로 오류가 발생하거나 개발이 원활히 진행되지 않을 수 있었습니다. 특히, MSA 구조는 기존의 모놀리식 방식과 다르기 때문에 이를 제대로 이해하지 못하면 장점이 퇴색되고 오히려 프로젝트의 안정성만 떨어질 수 있었습니다.

3. 백엔드 개발자 간 협업과 소통 체계의 부재

백엔드 개발자만 10명인 팀에서 협업의 방식과 소통 방법을 미리 설정해두지 않으면 나중에 정말 난리가 날것 같았습니다. 각자의 제출 결과물 형태 및 방법이 다르면 정상적인 동장을 테스트하거나 확인하기에 어려움이 있고 많은 시간이 소요될것입니다. 다른 팀원들의 작업한 내용을 보고 함께 피드백하며 소통 해야하는 저의 입장에서는 이부분이 매우 중요하였습니다. (’어디 브랜치에 올려놨어요‘, 도커 이미지로 드릴게요’ , 제 개인 레포지토리에 올려놨어요‘ )
그렇기때문에 각 팀원이 분산된 작업을 수행하는 상황에서, 명확한 협업 규칙들을 설정할 필요가 있었습니다.

(물론 소규모 프로젝트의 경우에도 이러한 규칙이 필뇨하지만 대규모 프로젝트에서는 이러한 규칙을 설정하면 나중에 변경하기에는 어렵기 때문에 더 깊게 고민했습니다.)

 

2인1조로 조별로 함께 협동해서 과제를 정해진 양식에 맞게 제출하세요!

 

이러한 문제들을 해결하고 팀원의 성장을 위하는 방향으로 위과 같은 방식을 선택했습니다. 

1. 2인 1조로 실력이 비슷한 사람들로 팀 구성하기. 효율적인 역할 분담과 협동할 수 있는 환경 조성

팀원들의 기술적 역량을 사전에 분석하여, 실력이 비슷한 사람들끼리 팀을 구성했습니다. 이를 통해 팀 내 협업이 원활해지고, 조별로 과제를 할당하여 상대적으로 난이도가 높은 기능은 더 높은 실력을 가진 팀에게 분배하여, 팀별로 작업의 속도와 균형을 유지하고 프로젝트의 전반적인 품질을 높이고자 했습니다. 이런 구성은 각 팀원의 부담을 줄이는 동시에, 공정한 역할 분담을 가능하게 했습니다.

 

2. 작은 단위로 과제 나누기: 목표를 명확히 하고 단계적 성장을 유도

모든 과제는 가능한 한 작은 단위로 나누어 일주일 단위로 진행하고, 각 과제에 대해 명확한 목표를 제시했습니다. 이를 통해 팀원들은 작업의 범위를 명확히 이해하고, 단계적으로 난이도를 높여가며 자신의 역량을 키울 수 있었습니다. 또한 일주일 단위로 주기적인 피드백을 통해 빠르게 학습하고 수정할 기회를 제공하는 데 효과적이었습니다.

 

3. MSA 학습과 실습 병행: 실무 경험 제공

팀원들이 MSA의 개념을 이해하고 실습할 수 있도록, 체계적인 학습 환경을 구축했습니다.
• DockerHub를 활용한 이미지 관리: 모든 프로젝트를 도메인별로 DockerHub에 배포하도록 설정해, 팀원들이 DevOps 과정에서 필수적인 기술을 직접 경험하도록 했습니다.
• 단계적 과제 설정: 로그인/회원가입 → 게시판 개발의 순차적 과제를 통해, 팀원들이 MSA 구조와 데이터 흐름을 이해할 수 있도록 했습니다.
• REST API 연동 실습: 이전에 개발한 서비스를 활용하여 새로운 프로젝트와 연동하며, 서비스 간 통합과 데이터 연동 경험을 제공했습니다.

4. 협업 방식과 제출 방식 설정 : 통일된 관리와 효율적 확인

효율적인 협업과 결과물 관리를 위해, 하나의 GitHub 레포지토리를 사용해 각 조별로 폴더를 생성하고 브랜치를 분리했습니다. 각 조는 자신들의 폴더 안에 1차 과제, 2차 과제 등 주차 과제를 포함할 폴더를 생성하며, 각 과제 폴더 안에는 스프링 프로젝트와 기능명세서.md 파일을 작성하여 제출하도록 했습니다. 이러한 구조를 통해, 과제별 진행 상황과 결과물을 명확히 파악할 수 있었습니다. 

또한, Docker 관련 작업은 별도로 진행하여, 모든 조가 DockerHub에 이미지를 업로드하고, 각 과제별로 Docker Compose 파일을 제출하도록 했습니다. 이를 통해, 리드인 제가 바로 이미지를 실행하고 결과를 확인할 수 있는 환경을 조성했습니다.

 

repository/
├── teamA/
│   ├── 1차과제/
│   │   ├── spring-project/
│   │   └── 기능명세서.md
│   ├── 2차과제/
│   │   ├── spring-project/
│   │   └── 기능명세서.md
│   └── 3차과제/
│       ├── spring-project/
│       └── 기능명세서.md
├── teamB/
│   ├── 1차과제/
│   │   ├── spring-project/
│   │   └── 기능명세서.md
│   ├── 2차과제/
│   │   ├── spring-project/
│   │   └── 기능명세서.md
│   └── 3차과제/
│       ├── spring-project/
│       └── 기능명세서.md
└── ...

 

이번 프로젝트에서 협업을 하며 발생할 이슈들을 해결하기 위해, 팀원의 실력을 기반으로 팀을 구성하고, 작은 단위의 과제를 통해 점진적으로 난이도를 높이며 협업과 성장을 도모하는 방식을 선택했습니다. 협업 방식과 결과물 제출 방식을 사전에 설정함으로써 혼란을 방지하고 효율적인 진행이 가능하도록 했습니다.

 

단순히 결과물을 만드는 것을 넘어서, 팀원들이 즐겁게 참여하며 이번 프로젝트를 통해 계속해서 성장할 수 있는 발판이 되었으면 좋겠습니다.