brunch

You can make anything
by writing

C.S.Lewis

by 이성긍 Oct 13. 2024

주니어 PM이 장기 프로젝트하며 배운 점

다음 장기 프로젝트를 위해 쓰는 글

01. 6개월 이상 프로젝트는 처음인데 말입죠


현재 참여 중인 프로젝트는 기획 킥오프를 포함해 올해 2월부터 시작되었습니다. 조직 이동으로 인해 저는 5월 초부터 합류했는데요. 중간 합류임에도 불구하고 거진 반년 이상 프로젝트 실무를 보고 있으니- 꽤나 장기전인 프로젝트입니다. 업계에 따라, 회사 규모에 따라 이보다 훨씬 큰 프로젝트 비중이 더 높은 팀도 많지만 제가 속한 팀의 특징과 제 연차를 고려하면 제법 낯선 장기 프로젝트였습니다.


배포 예정일을 얼마 안 남긴 현 시점에서 그간의 제작일지를 돌아보는 것만으로도 정말 많이 배웠구나 싶습니다. (배포 후 '전파'라는 제일 큰 산이 남아있긴 하지만)


플랫폼 조직으로 이동해 이 프로젝트를 시작하기 전까지는, '간결한 실험'을 가장 중요한 원칙으로 두며 짧은 호흡으로 여러 태스크를 진행한 경험이 대부분이었습니다. 그래서 장기 프로젝트를 통해 배운 점들이 향하는 단 하나의 목표는 바로 '일정 관리'였습니다. 어떻게 하면 호흡하는 법을 잊지 않으면서 저 멀리까지 헤엄쳐갈 수 있는지 고민하는 과정에서 해결했던 것들, 배운 것들이 대부분입니다. 직접 실무에 참여하지 않았다면 몰랐을 것들을 이 글에 남기고, 다음에 비슷한 프로젝트를 시작할 때 스스로 참고해보려 합니다.


중간 합류한 저를 환영하는 의미로 피그마 한 켠에 집을 마련해주시기도 했답니다 (정말 종종 찾아가게 되었지요)




02. 기획 대전제를 함께 소화하기


장기 프로젝트에서는 중간에 기획이 변경될 확률이 굉장히 높습니다. 사실 처음에는 '기획을 처음에 확정해야 안정적으로 만들 수 있지 않나?'라고 생각했는데요. 틀린 말은 아니지만, 반드시 맞는 말도 아닌 것 같습니다. 장기 프로젝트이기 때문에 프로젝트 중간에 시장 상황이 변경되어 요구사항 자체가 바뀔 수도 있는 것이고, 또 만들다보면 더 효과적인 제작 방법을 발견해 그에 맞춰 기획의 세부 사항을 약간 변경하는 것이 더 나을 때도 있습니다.


그래서 [기획서를 작성해 메이커에 전달]하는 것이 아니라 [기획의 대전제를 함께 소화]하는 것이 중요하다는 것을 배웠습니다. 여기서 키워드는 (1) 대전제 와 (2) 소화 인데요. 프로젝트 중간에 기획의 세부 사항이 변경되는 것에 대한 유연성을 기르려면, 그 세부 사항을 얹을 수 있는 기본 틀 그러니까 대전제가 그만큼 탄탄하게 준비되어 있어야 합니다. 기획서 상에서는 작은 세부 사항이라 하더라도 개발에서 그걸 반영하려면 많은 것을 변경해야 해서 생각보다 큰 일이 되는 경우가 부지기수입니다. 그래서 개발에서도 세부 사항의 유연성을 고려해 기본 설계를 시작하실 수 있도록 '변하지 않을 대전제'에 대한 공유가 필요합니다.


기획 전제 공유 미팅. 입사 후 처음으로 미팅에 필요한 자료를 종이로 인쇄해 참여자 분들 책상에 두고 왔다


그리고 이 대전제를 (2) 소화 하는 것이 중요합니다. 단순 전달이 아닙니다. 엔드 픽쳐에 대한 해상도가, 단기 태스크에 비해 장기 프로젝트에서 비교적 더 낮을 수 밖에 없습니다. 그래서 '어떻게' 만들 것인가- 보다는 '무엇을' 만들 것인가 부터 같은 선상에서 이해를 해야 엔드 픽쳐에 대한 해상도를 점점 높여나갈 수 있다고 생각합니다. 이 프로젝트에서 변하지 않을 전제가 무엇이며 그 전제의 의도는 무엇인지, 그 전제를 달성하기 위한 핵심 요구사항은 무엇인지- 가급적 실시간 질의응답이 가능한 미팅의 형태로 소화해나갔습니다. 미팅에서 공유되는 내용이 워낙 많았기 때문에 '이것만큼은 꼭 같은 선상에서 이해가 필요하다'라는 내용은 종이에 인쇄해 각 참여자가 미팅 중간중간 참고할 수 있도록 하기도 했습니다.




03. 제작 과정은 모듈화하기


프로젝트의 기간이 긴 만큼 참여하는 사람의 수도 많습니다. 동일한 직군별로 여러 명의 실무자가 있을 확률이 높습니다. 이를테면 한 명의 개발자가 전체 기획을 쪼개서 차례대로 만드는 것이 아니라 여러 명의 개발자가 동시에 개발 실무를 진행합니다. 개발자별 태스크 전달 및 매니징을 위해 기획부터 모듈화를 하는 것이 정말 큰 도움이 되었습니다.


이번 프로젝트에 실무 PM은 저를 포함해 두 명이었는데요. 제가 중간에 합류하면서 기획 업무의 분할이 필요했습니다. 그래서 이 프로젝트의 핵심 기능과 대전제를 점점 추상화해나가면서 2개로 나누었고, 그것을 하나씩 맡아 진행했습니다. 할 때는 몰랐지만 이제 와서 돌아보니 그것이 기획을 도메인 별로 구분하는 작업이었던 것 같습니다. 이 과정에서 저희는 각자의 뇌를 쓰면서도 같은 방향으로 계속 얼라인을 맞추는 게 중요하다고 생각했습니다. 그래서 우스갯소리로 '뇌 공유 합시다'라는 말을 자주 했던 기억도 나네요.


(공유용 기획서 아님) 우스갯소리로 '뇌 공유' 얘기하다가 PM 문서 정리 노션도 '뇌'로 만들어버린 우리들


모듈화를 통해 가장 크게 체감한 장점은 여러 명의 실무자가 동시에 작업을 진행할 수 있다는 점입니다. 그래서 전체 일정의 축소시키는 데에 큰 도움이 되었습니다. 하지만 단점 역시 피부로 와닿았는데요. 모듈화의 전제가 '결합성을 고려한 구조'여야 하지만 사실 작업을 하다보면 이미 서로의 길이 너무나 달라진 경우도 왕왕 있습니다. 그래서 정기적으로 기획이나 코드를 합치는 작업이 필요하고 이 작업에서 소위 '터진다'라고 말하는 현상이 발생할 수 있다는 점을 고려해 일정을 설계해야 합니다. 솔직히 회고하자면 이 점은 프로젝트 진행 중에는 미처 몰랐던 점입니다. 한창 바쁜 기획 실무가 어느 정도 마무리되고 Test Case를 작성하며 QA 일정을 조정하던 중 개발자들과의 대화를 통해 알게 되었던 블로커입니다. 그래서 다음에 작업을 모듈화해서 진행하는 프로젝트를 하게 된다면 꼭 기억하고 실천하고 싶은 부분입니다.




04. 내외부에 현황 공유하기


장기 프로젝트를 운영하는 PM 입장에서는 진행 상황에 블로커는 없는지, 배포 예정일을 맞추는 데에 영향을 줄 만한 문제는 없는지 당연히 걱정이 됩니다. 프로젝트의 면면을 파악하고 있는 PM도 우려가 되는데, 다른 분들은 그 우려의 크기가 더 클 수 밖에 없습니다. 단순히 걱정을 잠재우기 위해서가 아니라- 프로젝트가 끝까지 신뢰를 얻고 지속될 수 있게 하기 위해서라도 내외부에 현황을 투명하게 자주 공유하는 것이 중요하다고 생각합니다.


내부에 공유라 함은, 프로젝트에 참여하는 실무자들 간의 공유입니다. 서로 어떤 일을 하고 있고 그 일이 전체 프로젝트에 어떤 중요성과 영향을 가진 일인지 나눕니다. 저는 개인적으로 스크럼이 스크럼답게 운영되는 것이 어려운 데에 반해 시간 소모가 크기 때문에 데일리 스크럼을 아주 선호하지는 않는 편인데요, 장기 프로젝트에서는 큰 도움이 되었습니다. 개발 실무자 한 분이 의견을 주셔서 시작하게 되었는데- 각자가 일을 쪼개는 관점을 관찰하거나 블로커 발견 시점의 적시성을 높이는 데에도 좋은 영향이 있었다고 생각합니다. (그리고 '논의가 아니라 공유'에 초점을 맞추자는 규칙을 준수하다보니 스크럼을 스크럼답게 운영하는 것도 과거 경험에 비해 훨씬 수월했습니다.) 매일 현황을 공유하다보니 '조금씩 앞으로 나아가고 있다'라는 성공 감정을 나눌 수 있었던 것도 좋았습니다.


그리고 외부에 공유하는 것도 중요합니다. 장기 프로젝트는 기획이 무겁습니다. 그래서 프로젝트 외부자가 기획 사항을 샅샅이 이해하는 것은 당연히 어렵고, 이들은 '배포 여부'라는 매우 추상화된 단위로 프로젝트 현황을 파악하려 하는 것이 자연스러운 절차입니다. 그러니 '아직 배포가 안 된 프로젝트'는 계속 미완성 상태인 것처럼 간주될 수 있습니다. 이것을 해소하는 것이 필요한 이유는, 1) 프로젝트 외부자가 프로젝트 진행 상황에 대한 의사결정권을 가진 경우가 왕왕 있고 2) 프로젝트에 대한 평판은 내부자의 동기 부여에도 영향을 주기 때문입니다.


그래서 저희는 프로젝트 중간 상황을 전사 주크샵 (격주 단위로 팀별 현황을 공유하고 주요 프로젝트에 대해 발표하는 시간)에서 '시연'의 형태로 발표하기로 했습니다. 시연이라는 마일스톤을 구체화하고 나니, '시연에 필요한 내용이 무엇인가?' 의 관점에서 MVP 기능 요건을 좀 더 분명하게 정의하는 데에도 도움이 되었고 & 멀게만 보이던 배포일 앞에 단기 목표를 둠으로써 프로젝트 내부 구성원들과 목표 의식을 다지는 데에도 도움이 되었습니다. 


1차 시연 때. 다같이 으샤으샤 할 수 있었다.






장기 프로젝트는 말 그대로 장기전입니다. '정말 배포할 수 있을까?'라는 걱정이 문득 찾아오는 순간들도 있었지만, 그럴 때 - 일단 저기까지 가보자! 우리 갈 수 있다! 라고 서로 북돋울 수 있도록 팀의 사기를 끌어올리는 것이 PM의 역할 중 하나라는 생각도 듭니다. 아자아자 어쨌거나 저쨌거나 저~기로 같이 가봅시다.



feat. 이왕 하는 거 즐겁게 해보자는 취지에서- 심각한 논의 할 때 라따뚜이 머리띠라도 써보자는 제안에 모두가 OK 했던 요상한 상황. 라따뚜이 머리띠 공구로 19개 주문하게 될 거라는 생각은 못 했다. 의외로 진짜 도움이 되었다(?)

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari