지난 글에 이이서 프로젝트 회고를 작성하려고 한다. 프로젝트는 22년 8월 19일에 시작하여, 오늘로 일정을 마무리하게 되었다. 글 제목에서 사전 프로젝트라고 언급했는데, 그 이유는 다음 주부터 진행할 프로젝트가 본격적인(main) 프로젝트이기 때문이다. 따라서 오늘까지 진행한 이 프로젝트는 사전 프로젝트가 되는 것이다. 우리 팀은 사전 프로젝트에 걸맞게 '배웠던 내용을 복습하고, 개발 프로세스를 경험'하자는 목적으로 프로젝트에 임했다.
우리 팀의 프로젝트 일정을 다시 공유하자면, 아래와 같다.
프로젝트 전체 일정
프로젝트의 결과
약 2주 동안 stack overflow 웹 클론 프로젝트를 진행했습니다. 해당 프로젝트는 결과물보다 프로젝트 진행 과정을 이해하고, 동료 성장에 큰 목적을 뒀기 때문에 프로젝트에 대한 설명은 자세하게 하지 않겠습니다. 궁금한 내용은 아래 링크를 참고해주세요.
여기서 PM은 Project Manager를 의미한다. 즉, 나는 프로젝트를 관리했다고 할 수 있겠다. 먼저 PM으로서 어떠한 역할을 수행했는지 알아보겠다.
1) 역할
프로젝트의 일정을 세세하게 작성하고 공유
협업 툴을 적절하게 활용하여, 팀원끼리 원활한 소통 유도
프론트엔드 개발팀과 백엔드 개발팀의 중립을 유지하고, 프로젝트 관리
개발에 필요한 명세서 정리
일정 관리
팀원들의 가치(강점)를 이끌어내고 연결
팀 공동 목적에 맞게 프로젝트 수행
팀원에게 역할 부여
2) 수행 여부
위에서 PM으로서 수행했던 내용 중 대표적인 것들을 나열했습니다. 이후 언급할 내용과 겹치는 부분도 있기 때문에 최대한 요약해서 작성했다.
그렇다면 이러한 역할을 잘 수행했는가? 역시 객관적인 지표는 팀원들의 의견을 듣는 것이다.
동료 평가(,,맥북이 아님,,?)
[팀원 평가] 회고를 진행한 결과 계획한 일정을 잘 수행했고, 전반적으로 팀을 잘 이끌었다는 평을 주었다. 그중 아침마다 모두 모여, 일정과 이슈를 공유할 수 있는 짧은 회의 시간을 꾸준히 진행한 것이 좋았다고 했다. 다음으로 듣게 된 평은 코드 리뷰를 통해 개발 역량을 향상할 수 있었다고 했다.
[개인 평가] - 일정 관리를 잘했는가 - ★★★★☆ 전체적인 일정을 따졌을 때, 목표한 기간 내로 결과물을 성공적으로 완성시켰다. 뿐만 아니라 설계 단계, 구현 단계, 배포 후 테스트 단계, 리팩토링 단계를 잘 진행했다. 다만, 아쉬운 점은 갑작스러운 이슈가 발생했을 때 유동적이게 일정 조정을 못했다. 두 가지 경우가 있다. 첫 번째는 백엔드 CTO 역할을 맡은 팀원이 코로나19에 감염되어 일주일간 참여를 못했다. 이때 모두가 함께 성장해야 한다는 목적에 충실했던 나머지 일정을 과감하게 진행하지 못했다. 두 번째는 팀 깃헙 레파지토리가 삭제되었을 때이다. 당시 코드를 관리할 곳이 없어 하루가 공백이 되어버렸다. 이유는 전체 일정을 여유롭게 생각하며, 마땅한 대안을 제시하지 않았기 때문이다.
- 협업 툴을 적절하게 활용하고, 팀원들을 참여시켰는가 - ★★☆☆☆ 기존에 자주 활용하던 툴을 사용했다. 노션, 깃헙, 디스코드, 카톡, 구글 문서 등등. 처음 프로젝트를 시작했을 때 가장 걱정했던 부분은 툴 활용이다. 이전에 많은 팀을 이끌어본 입장에서 느낀 것이 있다. 팀원 중 최소 한 명 이상은 팀의 툴 또는 규칙을 지키지 않는다. 강제성을 높여도, 차이에는 변화가 없다. 참 신기하다. 이번도 역시 그렇다.하지만 이건 팀원의 잘못이 아니다. 보다시피 사용하는 툴이 너무 많았다. 다음 프로젝트에서는 최대한 통합 툴을 활용해야겠다.
- 팀 공동 목적에 맞게 프로젝트 수행 - ★★★★★ 개인적으로 가장 잘했다고 생각한다. 프로젝트를 시작한 순간부터 끝까지 잊지 않으려고 노력했다. 최대한 팀원을 생각했다.
- 팀원에게 역할 부여 후 효율적인 프로젝트 진행 - ★★★☆☆ 초기 팀빌딩 파트에서 팀원들에게 각각 역할을 부여했다. 여기서 '역할 별로 수행이 제대로 되었냐'를 물었을 때, 결과는 50%다. 사실 어느 정도는 의도한 것이다. 지금은 사전 프로젝트라는 점을 고려했다. 현재 팀원들은 개발 실력이 평균적으로 낮았다. 당연하게도 이제야 개발 교육을 마쳤기 때문이다. 반면 나는 혼자서 애플리케이션을 구현할 수 있는 수준이다. 여기에 추가로 깃헙, 노션, 인프라 등 개발 외에 실력까지 갖추고 있었다. 그렇기 때문에 팀원들에게 역할을 부여했음에도, 대부분 PM인 내가 역할을 수행했다. 덕분에 팀원들은 구현에 집중할 수 있게 되고, 기술력 또한 향상했다. 여기서 문제라면 코드리뷰, 깃헙 관리, 배포, 회고, 브랜치 관리, QA, 심화 기능 구현, 동료 성장 등 모든 것을 혼자 하려다 보니 본인 개발 역량은 성장하지 못했다. 간단하게 말하자면, 개인 시간을 갖지 못했다. 메인 프로젝트 때는 혼자 한 업무들을 최대한 분산시킬 것이다. 팀원들에게 책임자 수준으로 역할을 부여할 예정이다.
고민과 해결
위에 PM의 역할에서 언급했던 내용과 중복되는 점이 많기 때문에, 진행하며 크게 고민했던 부분만 적으려고 한다.
1) 짧은 2주 그리고 우리 팀의 실력
[동료 성장 고민] 우리 팀은 이제야 막 개발 교육을 마쳤다. 그래서인지 다들 '내가 구현을 할 수 있을까'라는 질문을 던지며, 자신감이 낮은 상태였다. 이러한 상황에서 2주라는 시간은 굉장히 짧아보였다.
[해결 방법] 해결 방법을 제시하기 전에, '동료 성장'을 가장 큰 목적으로 둔 이유를 말하겠다. 일단 동료가 성장해야 다음 진행할 프로젝트에서 좋은 성과를 만들 수 있다고 생각했다. 뿐만 아니라 동료 성장이 곧 나를 성장시킨다고 믿었다. 두 번째는 평소부터 많은 스터디를 진행하며 동료들과 성장한 경험이 있었다. 팀원들이 어려워한다면, 적극적으로 가르치고, 도우려고 했다.
1) 팀원들 각자의 성향과 강점 파악 학습 시너지가 발휘되는 순간은 팀원마다 달랐다. 평소에 팀원 각자의 성향을 파악해두는 습관 덕분에 금방 캐치할 수 있었다. 가령 한 분은 독립적인 것을 좋아하는데, 본인이 맡은 미션을 책임감 있게 임한다. 만약 문제가 발생하면, 레퍼런스를 보더라도 본인의 것으로 만들어 문제를 해결한다. 이게 이 분의 강점이자 학습 시너지가 발휘되는 순간이었다. 이런 점을 활용하여, 큰 단위의 도메인을 구현하라는 미션을 제공했다. 다른 분은 논리, 체계적인 성향이며, 페어와 함께 학습할 때 시너지를 발휘한다. 그래서 다른 성향을 가진 팀원과 함께 미션을 수행하도록 했다.
2) 코드 리뷰 진행 사실 실무에서 진행하는 코드 리뷰 방법을 잘 몰라서, 지금의 방법이 정확하게 코드 리뷰인지는 모르겠다. 일단 나는 초보 개발자들이 개발을 어려워하는 이유는 기술을 본인의 것으로 만들지 못해서라고 생각했다. 가끔 보면 본인이 작성한 코드를 설명하지 못하는 사람들이 많다. 그래서 매일 아침 본인이 작성한 코드를 설명하는 시간을 가졌다. 여기서 잘못되었거나, 부족한 부분은 내가 보충해서 다시 설명했다.
3) 기술 블로깅 주제 제시 프로젝트를 진행하며 발생하는 이슈 또는 기술 위주로 블로깅하도록 이끌었다. 이때 블로깅 주제를 정리해서 제공했다.
2) 이래서 협업 프로젝트, 협업 프로젝트하는구나~
[백엔드 협업 진행 방법 고민] 나 또한 백엔드 개발자가 2명 이상 있는 프로젝트는 처음이었다. 더군다나 우리 팀은 백엔드 인원이 4명이었다. 개발 진행 방법에 대해 정말 많이 고민했다. 아쉽지만 이 고민은 여전히 해답을 내리지 못한 상황이다. 하지만 다음 프로젝트에서 진행하고 싶은 전략이 생겼다.
[해결 방법] 일단 사전 프로젝트에서는 동료 성장이 우선이었기 때문에, 나는 기본 로직의 코드 구현을 전혀 하지 않았다. 대신 몇 가지 체크를 진행했다. 첫 번째는 동료들의 역량을 체크했다. 동료들에게 미션을 주었을 때 얼마큼 수행할 수 있냐를 체크했다. 여기서 얻는 인사이트를 기반으로, main 프로젝트의 진행 방법을 결정하려고 했다. (결정한 내용은 다음 카테고리에서 다루겠습니다.)
[느낀점] 가장 먼저 백엔드 애플리케이션 아키텍처, 설계 진행 방법 등의 존재 이유를 깨달았다. 그리고 협업 프로젝트의 중요성을 알았다. 만약 이 프로젝트를 혼자 개발했다면, 3~5일 이내로 구현할 수 있었을 것이다. 물론 나뿐만 아니라 어떤 팀원이든 동일할 것이다. 신기하게도 팀으로 프로젝트를 진행하니 쉽지 않았다. 가장 큰 이유는 다른 사람과 맞춰야 한다는 점이다. 사전에 정해야 할 규칙도 많다. 그럼에도 실무에서 팀으로 개발을 진행하는 이유는 있다. 정말 제대로 된 시너지를 발휘한다면, 어마어마한 결과를 가져올 수 있기 때문이다. 그래서인지 지금 과정에서 협업 프로젝트 경험을 강조하는 것은 지금 최대한 리스크를 경험하고, 실무에서 협업 할 때 시너지를 발휘하라는 것 같다.
3) 이 외에 고민
배포 주기, 배포 방법
github 충돌을 최대한 방지하기 위한 브랜치 전략
팀원들이 협업 툴에 적극적으로 참여시키기 위한 방법
프론트엔드와 백엔드 소통 방법
메인 프로젝트 시 적용할 개선사항
사전[PRE] 프로젝트
주요[MAIN] 프로젝트
협업 툴
노션, 디스코드, 카카오톡, 깃헙, 구글문서
지라, 디스코드, 깃헙
일정 관리
엑셀
구글 캘린더
프로젝트 관리
노션, 깃헙 칸반보드
지라
팀 공유 기술 블로그 운영
X
O (티스토리)
배포
V1 완성 후 배포, 3-tier 아키텍처 배포
무중단 배포, 일주일에 한번 배포, 배포 scope 사전 설정, 3-tier 아키텍처 배포, aws codedeploy(Pipeline) 활용
역할
PM 본인 부담
역할별 책임자 지정, CTO 역할 강화
BE 개발 협업 방식
팀원 역량에 맞춰서 배정, 구분 없음
각각 다른 도메인을 책임지고 구현, 의존성을 최대한 낮출 것
* 기획, 설계 탄탄하게 진행할 것 * 깃헙 충돌, 배포 에러 등 부수적인 관심사 부분에서 시간과 에너지를 최대한 감소시킬 것
마무리 (나는 백엔드 개발자가 맞는가?)
이 시점에서 궁금할 것이다. 백엔드 개발자라는 사람이 개발보다 Project Manager 역할을 더 충실히 하는 게 아닌가?
사실 이전에 그런 글을 본 적 있다. "개발자들은 대부분 PM의 역할을 맡지 않으려고 한다"는 글이었다. 직접 경험해보니 왜 그런지 알 것 같다. 이번 사전 프로젝트를 진행하면서 개발 관련된 학습을 한 번도 진행하지 못했다. 프로젝트에 임한 시간을 따지자면, 일주일 168시간을 기준으로 했을 때 136.5시간을 임한 것이다.(그냥 월화수목금토일 매일 임했다는 말..^^) 개발이 아닌 프로젝트를 위해 대부분의 시간을 투자하고 있었다. 하지만 PM의 역할을 수행하는 것에 불만은 없다. 어떠한 직무든 결국은 좋은 결과물을 만들기 위해 적극적으로 고민해야 한다. 이번에 PM을 맡은 덕분에 프로젝트의 전반적인 프로세스와 개발 외에 역량도 쌓을 수 있었다.
