군에 있으면서 다양한 경험을 해왔고 그 과정에서 리더십이 요구되던 상황이 많이 있었습니다. 개발팀을 꾸려 프로젝트를 이끌었던 최근 1년은 그 중에서도 가장 어려우면서도 재밌었던 시기였습니다.
들어가며 - 개발 협업은 (거의) 처음이라서..
그동안 개발 경력은 꽤 쌓였지만, 회사에서 쌓은 경력보단 혼자 쌓은 경험들이 대부분이었고 아주 간간히 대외활동으로 팀 프로젝트를 했었지만 개발 협업은 익숙치 않았습니다. 아무래도 군에서 개발을 주 업무로 하지 않고 퇴근 후 사이드 프로젝트로 공부해왔기 때문인 것 같습니다. 그나마 오픈소스 기여를 통한 협업 경험을 쌓아놓은 것이 다행이었습니다. (심지어 유일한 인턴 경험인 보이저엑스 때에도 팀에 개발자가 저 혼자였다는 것...)
군에 있으며 제 계급보다 높은 팀장, 부서장 보직을 맡았던 경험도 있습니다. 하지만 AI 도입을 추진하면서 개발이 주 업무가 되고, 개발 프로젝트와 팀을 리드하는 경험은 처음이었기 때문에 고민이 많았습니다. 다양한 책을 읽고 여기저기서 주워들은 내용들을 바탕으로 어떻게 하면 개발팀을 잘 이끌 수 있을까 생각했습니다. 그래서 일단은 가장 편리하고 쉽다고 생각하는 방향으로 시작했습니다.
초기 설계 - 일단 나를 던져
프로젝트의 초반 방향성, 설계, 주요 결정은 팀 빌딩 이전에 혼자 진행했습니다. 모두가 해보지 않은 분야의 프로젝트를 진행해야 하는 상황에서 협업 방식이나 체계가 정립되지 않은 시점에 프로젝트 기능 기획, 회의를 하다보면 중심이 안잡히고 역할에 대한 분담이 더 어려워질 것이라 생각했습니다. 리더 없이 모두가 동등하게 참여하는게 오히려 생산성에 방해가 될 것이라 예상했습니다.
그래서 초반에는 팀원들에게 프로젝트와 관련된 기술스택을 공부하는 시간을 주었습니다. 다들 역량이 훌륭하지만 개발이 주 분야는 아니었고 오픈소스 기여와 같은 협업 경험도 없기 때문에 어느정도 준비 시간이 필요하다 느꼈습니다.
그 사이에 혼자 프로젝트 MVP를 만들었습니다. 예전이었으면 일주일만에 MVP를 혼자 만드는게 어려웠겠지만, 클로드 코드 덕분에 수월했습니다. 그리고 이걸 팀원들에게 보여주며 우리가 나아갈 방향이 무엇인지, 앞으로 뭘 만드는 것인지 직관적으로 설명할 수 있었습니다.
협업 설계 - 효과적인 협업하기
MVP를 만들며 앞으로 더 구현해야 하는 부분, 현재 미흡한 부분들을 모두 나열해 문서로 만들었습니다. 그리고 이것들을 비슷한 역할군으로 묶어 팀원 수 만큼 과제로 만들었습니다. 그 과제들은 미리 세팅해둔 Gitlab에 이슈 형태로 올려놓고 할당했습니다. 과제를 나눌 때는 프로젝트와 너무 동떨어진 것 같은 과제만 받는 사람이 없도록 했습니다. 프로젝트 자체에 기여하고 있다는 느낌을 계속 주는게 동기부여에 도움이 될거라 생각했습니다.
Gitlab, 매터모스트, PR 및 브랜치 시스템 등 기본적인 협업 체계를 구축하고 교육했습니다. 나름 오픈소스 기여 경험이 있다보니 git 기반의 협업 시스템에 익숙했고, 원활한 협업을 위해 팀 브랜치 규칙을 설정했습니다. 그리고 경험이 없는 팀원들을 위해 세미나를 하고, 연습할 수 있는 예제도 제공했습니다. 그렇게 브랜치를 만들고, PR을 올리고, 리뷰받으면 머지한다를 팀의 기본 규칙으로 만들었습니다.
PR을 올리기 전 논의와 공유를 필수로 했습니다. 코드리뷰를 하는 입장에서 아무 맥락 없이 PR만 올라오면 리뷰가 힘들다는 것을 프로젝트를 진행하며 몇 차례 느꼈습니다. 특히 요즘 코딩 에이전트로 작업하다보면 작업 규모가 커지고, 리뷰가 불가능한 크기의 PR이 올라오는게 잦아졌습니다. 메신저나 미팅을 통해 현재 해결하고자 하는 문제와 시도하려는 접근법을 꼭 먼저 공유하도록 했고, 그 덕분에 팀을 리드하는 입장에서 컨텍스트를 잘 유지하고 리뷰와 피드백을 줄 수 있게 되었습니다.
내적 동기부여 - 팀원들의 안녕을 위해
팀을 이끌며 느꼈던 가장 중요한 점은 팀원들이 본인의 일과 프로젝트에 애정을 가져야 좋은 생산성과 결과물을 얻을 수 있다는 것입니다. 내적 동기부여가 가장 중요하며, 그와 동시에 참 어려운 일이라는 것을 알게 되었습니다. 최대한 본인이 하고 싶어하는 분야의 과제를 맡기고, 비슷한 과제를 여러번 맡겨 숙달 시키고, 벤치마크나 테스트처럼 비교적 재미없는 작업 중에도 눈에 보이는 생산적인 과제들을 한번씩 할 수 있도록 관리했습니다. 이외에도 내적 동기부여를 주기 위해 많은 노력을 했지만, 마음 속을 들여다 볼 수 없어 잘 됐는지는 모르겠습니다..ㅎㅎ
작업 결과를 기록하고, 회고하고, 발표하는 활동을 권장했습니다. 이전에 기술 세미나 관련 포스트에서 공유했듯 팀원들이 본인의 역량을 키우고 작업했던 결과물을 본인 것으로 만드는 데 큰 도움이 될 것이라 생각했기 때문입니다.
귀찮은 일은 최대한 없앴습니다. 상부를 위한 보고서 작성, 회의 참석 등은 팀장으로서 도맡았으며 팀원들은 최대한 일에만 집중할 수 있는 환경을 만들었습니다.
마치며
이와 같은 방식으로 1년 가까이 팀을 이끌어왔습니다. 여기까지 노력한 것과 함께 좋은 팀원들을 만난 운 덕분에, 프로젝트는 순항 중입니다. 감동스럽게도 이제 팀원들이 알아서 프로젝트의 미흡한 부분을 찾고 놓쳤던 이슈들을 찾아 먼저 제시하고, 기여를 시작했습니다. 이 정도면 나름 성공적인 팀플이지 않았을까요?ㅎㅎ
