리더님과의 티타임에서 나는 개발 PM의 역할을 단순히 업무를 분배하고 일정을 조율하는 정도로 생각했다. 프로젝트의 모든 스펙을 세세하게 알 필요도 없고, 알 수도 없다고 여겼다. 따라서 가능한 한 빠르게 업무를 쪼개고 담당자를 지정하고 싶었다. 개발 담당자가 정해져야 기획자들도 신속하게 논의를 진행할 수 있을 것이라 판단했다.
기획서를 빠르게 훑어보니, 10페이지가 훌쩍 넘는 문서가 UI 요소별로 분리되어 있었고, 각 요소마다 기획 담당자가 지정되어 있었다. 자연스럽게 각 UI 요소에 대한 개발 담당자를 배정하는 것이 소통에 용이하겠다는 생각이 들었다. 이에 따라 각 스펙을 검토한 후 UI 요소별 완성본 이미지를 캡처하고, 고려해야 할 사항을 정리했다. 또한, 회의에서 논의된 배포 우선순위를 반영해 순서를 조정했다. 이후 팀 주간회의에서 이를 기반으로 담당 개발자를 분배했다.
당시 팀원들이 적극적으로 지원해 준 덕분에 개발 업무 분배는 수월했다. 큰 작업을 작은 단위로 쪼개어 각각 담당하도록 하니 부담도 줄어든 듯했다. 개발 담당자가 정해지면서 기획 및 디자인 커뮤니케이션도 원활하게 이루어졌고, 업무의 흐름이 정돈되는 느낌이었다.
하지만, 기능이나 UI 요소 단위로 업무를 분리하는 방식이 가장 쉽고 빠른 해결책은 될 수 있어도, 반드시 최선의 방법은 아니었다. (이 부분은 ‘초보 개발 PM의 위기’ 편에서 더 자세히 다룰 예정이다.)
모든 메시지에 내 이름이 멘션되기 시작했다.
하나의 서비스가 세상에 나오기까지는 단순한 화면 구성 외에도 다양한 요소를 고려해야 한다. 데이터는 어디에서 서빙할지, 로딩 및 에러 발생 시 UI는 어떻게 보여줄지, 배포 가능 여부, 운영과 모니터링을 위한 로깅 기준, 다국어 적용 방식 등 개발과 직접 연관된 많은 고민이 필요했다. 또한, 협업 방식과 툴 선정, QA 프로세스, 배포 중 발생할 이슈 대응 방식까지 프로젝트 전반을 아우르는 사항들도 중요했다.
이처럼 개발 과정에서 공통 이슈가 발생하거나, 일정 내 배포를 위해 스펙을 조정해야 할 때, 개발 PM은 자연스럽게 관련 논의에 멘션된다. 나 혼자 모든 문제를 해결할 수는 없지만, 가장 먼저 파악하고 적절한 담당자에게 연결하는 역할이 필요했다.
위임 전략의 활용
5년간 여러 개발 프로젝트를 진행하면서 사내 툴과 배포 프로세스에는 익숙했지만, 개발 PM을 맡으면서 관심사의 범위가 더 넓어졌다. 이전에는 내 업무만 챙기면 됐지만, 이제는 프로젝트 전반을 살펴야 했고, 이에 따라 자연스럽게 책임감도 커졌다.
한정된 자원 속에서 가장 효과적인 해결 방법을 찾기 위해 위임 전략을 적극 활용했다. 예를 들어, 내가 맡은 프로젝트는 웹뿐만 아니라 앱에서도 같은 스펙의 서비스를 제공해야 했다. 기존에는 웹용 BFF API만 고려하면 됐지만, 앱 배포의 어려움을 감안해 보다 유연한 BFF API를 설계해야 했다. 이 역할을 맡아준 팀원들이 여러 팀과 협업하며 프로젝트를 원활히 진행해 주었다.
또한, 복잡한 스펙을 한 번에 구현하는 것은 현실적으로 불가능했다. 이에 따라 최소한의 기능을 1차 배포 대상으로 정하고, 추가적인 요구사항은 2차 배포로 넘기는 방식으로 접근했다. 이는 일정 관리와 자원 배분의 효율성을 높이는 데 큰 도움이 되었다.
가장 중요한 것은 상황파악
처음에는 개발 PM의 역할을 "업무 나누고 일정 협의하는 것"으로 여겼지만, 시간이 지날수록 가장 중요한 것은 상황을 정확히 파악하는 것이라는 깨달음이 들었다. 현재의 진행 속도로 프로젝트가 일정 내 완료될 수 있을지를 지속적으로 점검해야 했다.
이를 위해 매일 아침 30분간 데일리 스크럼을 진행하다가, 중간부터는 팀원들이 진행 상황을 한눈에 볼 수 있도록 프로젝트 보드를 활용했다. 프로젝트 보드는 칸반 형식으로 새로운 이슈, 진행 중인 이슈, 완료된 이슈, 보류된 이슈를 구분할 수 있어 업무 현황을 직관적으로 파악할 수 있었다. 또한, 필터링 기능을 활용해 각 팀원이 맡고 있는 일을 쉽게 확인하고, 적절한 담당자를 배정하는 데에도 효과적이었다.
이런 방식은 팀원들 간의 업무 조율에도 긍정적인 영향을 미쳤다. 프로젝트 보드 업데이트를 통해 해야 할 일들이 줄어드는 과정을 시각적으로 확인하면서 동기부여가 되었고, 특정 팀원에게 업무가 과중될 경우 서로 돕는 분위기가 형성되었다. 그리고 중복되는 업무도 빠르게 찾아 여러 사람이 같은 일을 하는 경우를 예방할 수 있었다.
물론, 프로젝트 보드나 데일리 스크럼이 모든 경우에 적절한 것은 아니다. 과거 다른 프로젝트에서는 팀원들의 업무가 크게 연관되지 않아 스크럼이 비효율적이었던 경험도 있었다. 하지만 이번 프로젝트처럼 긴박하고 얽힌 업무가 많아 협업이 중요한 경우에는 이 방식이 매우 효과적이었다. 이 경험을 통해 툴과 방법론은 상황에 맞게 적용해야 가장 큰 효과를 낼 수 있다는 교훈을 얻었다.
다음 글에서는 개발 PM의 가장 중요한 덕목 중 하나인 커뮤니케이션에 대해 다룰 예정이다. 이렇게 글을 통해 경험을 정리하다 보니, 당시의 배움을 다시금 되새길 수 있어 의미 있는 시간이 되고 있다.