보고서를 만드느라 프로젝트를 못 챙기는 PM

어느 PM의 목요일이다. 오전에는 주간보고 PPT를 만들었다. 간트차트를 캡처해 붙이고 지난주 파일에서 진척 표를 복사해 숫자를 고쳤다. 오후에는 고객사가 요청한 WBS Dictionary를 갱신했고, 저녁에는 조직 개편으로 바뀐 RACI 매트릭스를 손봤다. 팀원 면담 두 건은 다음 주로 미뤘다. 리스크 검토 회의는 30분으로 줄였다.

이 PM은 게으른가. 정반대다. 성실해서 이렇게 됐다. 주 10시간을 산출물 만드는 데 쓰는 PM은 드물지 않다. 문제는 그 10시간이 어디서 왔느냐다. 면담, 리스크 검토, 이해관계자 관리처럼 사람만 할 수 있는 일에서 왔다.

산출물은 작성하는 것이 아니라 추출하는 것이다

여기서 한 가지를 구분해야 한다. WBS Dictionary, RACI, 마일스톤 보고서 같은 PM 산출물은 쓸데없는 형식이 아니다. Dictionary는 Work Package의 경계에 대한 합의이고, RACI(Responsible 실행·Accountable 최종 승인·Consulted 협의·Informed 공유)는 책임의 소재에 대한 합의다. 이 합의가 없으면 1편의 "그 일은 누가 하기로 했죠?"로 돌아간다. 산출물 자체는 프로젝트에 필요한 기반이다.

문제는 그것을 만드는 방식이다. 이 시리즈에서 계속 이야기한 관점으로 보면, 주간보고·Dictionary·RACI에 들어가는 정보는 이미 어딘가에 있다. WBS에, 일정에, 진척 데이터에, 담당자 배정에 있다. 산출물 제작이란 결국 한 곳에 있는 데이터를 다른 서식으로 옮겨 적는 일이다. 옮겨 적는 순간 2편에서 다룬 문제가 시작된다. 원본이 바뀌면 사본은 낡는다. 목요일에 만든 PPT는 금요일이면 이미 지난주 것이 된다.

그래서 방향은 하나다. 산출물은 작성하는 것이 아니라 데이터에서 추출하는 것이어야 한다. 회계팀이 재무제표를 손으로 그리지 않고 원장에서 뽑아내듯이, WBS Dictionary와 RACI와 주간보고도 프로젝트 데이터에서 뽑혀 나와야 한다.

주요 산출물의 원천을 따져보면 이렇다.

왼쪽 두 열은 기계의 일이고 오른쪽 열이 PM의 일이다. 오늘 대부분의 PM은 왼쪽 두 열에 시간을 다 쓰고 오른쪽 열을 못 하고 있다.

다만 추출이 성립하려면 전제가 있다. 이 시리즈의 독자라면 이미 안다. 데이터가 한곳에 살아 있는 상태로 있어야 한다(2편). 구체적으로는 4가지다. 단일 데이터 모델, 노드마다 정리된 담당자 필드, 합의된 완료 기준(4편), 변경 이력 관리(3편)다. 흩어진 데이터에서는 아무것도 추출할 수 없다.

AI에게 맡길 일과 맡기면 안 되는 일

요즘은 여기에 변수가 하나 더 있다. AI다. "WBS 초안을 AI가 만들어 준다면 PM의 일은 무엇이 되는가"라는 질문을 도구를 만들며 오래 붙들었다. 결론은 경계선을 긋는 것이었다.

AI에게 맡길 수 있는 일은 기억을 되살리는 쪽이다. 비슷한 프로젝트의 WBS가 대체로 어떤 구조였는지, 시스템 구축 프로젝트에 마이그레이션·권한·교육 같은 항목이 있어야 한다는 것 정도는 축적된 패턴에서 나오고, 기계가 사람보다 잘한다. 백지에서 시작하지 않는 것의 가치는 크다. 빠뜨림(1편)의 상당수는 백지에서 시작하기 때문에 생긴다.

AI에게 맡기면 안 되는 일은 약속이다. 이 조직에서 이 팀이 이 고객과 하는 이 프로젝트의 범위 경계, 공수 추정, 책임 배정은 맥락과 이해관계의 문제이고 서명하는 사람의 일이다. AI가 만든 초안에서 8/80 위반과 중복을 지적하는 것은 기계가 할 수 있지만, "이 Work Package를 계약 범위에 넣을 것인가"에 답하는 것은 언제나 PM의 몫이다.

그래서 초안은 기계가 만들고 판단은 사람이 한다. 이 분업이 지켜질 때 AI는 PM을 대체하지 않는다. PM을 목요일의 복사·붙여넣기에서 풀어줄 뿐이다.

숫자로 보면 이렇다. 주 10시간의 산출물 제작이 추출된 초안을 검토하고 보정하는 주 2시간으로 줄면 8시간이 돌아온다. 그 8시간이면 미뤄뒀던 팀원 면담 두 건, 30분으로 줄였던 리스크 검토의 원상 복구, 다음 분기 범위 협상 준비가 전부 들어간다. 산출물 자동화가 만들어 내는 진짜 결과물은 문서가 아니라 PM의 판단 시간이다.

마치며: 여섯 개의 순간, 하나의 원인

시리즈를 닫으며 여섯 순간을 요약해 본다. 빠뜨린 일(1편), 낡은 계획(2편), 사라진 기준(3편), 느낌으로 말하는 80%(4편), 두 벌의 장부(5편), 그리고 복사와 붙여넣기로 채운 목요일(6편)이다. 여섯 개의 다른 사건처럼 보이지만 원인은 하나다. 프로젝트의 진실이 한곳에 살아 있는 상태로 존재하지 않는 것이다.

규율은 배웠고 원리는 안다. 남은 것은 그 규율을 유지하는 비용을 누가 감당하느냐다. 사람의 의지로 감당하는 조직은 사람이 지치면 무너지고, 구조로 감당하는 조직은 오래간다. 우리는 뒤쪽을 만드는 일을 하고 있다.

지금 우리 프로젝트에서는 여섯 순간 중 어느 것이 자라고 있는가.

PM의 실행 블록

내일 바로 할 일 3가지

1. 지난 한 달간 만든 산출물을 나열하고 각각 원천 데이터에서 추출할 수 있는지 표시한다.
2. 추출할 수 있는 것 중 하나를 골라(주간보고를 권한다) 원천 데이터에서 서식으로 뽑는 자동화를 시도한다.
3. 회수할 시간을 쓸 곳을 먼저 정한다. 면담, 리스크 검토, 이해관계자 관리 중 가장 밀린 것으로 정한다.

회의에서 던질 질문

• "이 보고서의 숫자 중 원천 데이터와 다른 것이 있습니까?"
• "이 문서를 만드는 데 매주 몇 시간이 듭니까? 그 시간에 원래 무엇을 해야 했습니까?"
• "AI가 만든 이 초안에서 사람이 서명해야 하는 판단은 어느 부분입니까?"

좋은 신호와 나쁜 신호

도구가 해결해야 하는 부분

이 시리즈의 결론이기도 하다. wbsgantt에서 WBS Dictionary·RACI·마일스톤 보고서는 버튼 하나로 프로젝트 데이터에서 export된다. AI는 WBS 초안과 누락 후보 제안까지만 하고 승인은 언제나 사람이 한다. 여섯 개의 순간을 막는 것은 결국 하나의 구조, 살아 있는 단일 데이터 모델이라고 본다.