보고서를 만드느라 프로젝트를 못 챙기는 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는 금요일에 이미 지난주 것이 된다.

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

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

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

단, 추출이 성립하려면 전제 조건이 있다. 이 시리즈의 독자라면 이미 안다 — 데이터가 한곳에, 살아 있는 상태로 있어야 한다(2편). 구체적으로는 네 가지다. 단일 데이터 모델, 노드마다 정비된 담당자 필드, 합의된 완료 기준(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 초안과 누락 후보 제안까지만 한다 — 승인은 언제나 사람의 몫으로 남겨두었다. 여섯 개의 순간을 막는 것은 결국 하나의 구조, 살아 있는 단일 데이터 모델이라고 우리는 믿는다.