이번 주간보고는 쓰지 않고 뽑았다
월요일 아침 9시의 주간회의를 위해 일요일 밤을 쓰는 PM이 있다. 지난주에 한 일을 계획 문서에서 찾아 복사하고, 이번 주에 할 일을 다시 복사하고, 표의 줄을 맞추고, 결재란을 그린다. 6편에서 우리는 이 시간을 두고 "산출물은 '작성'이 아니라 '추출'이어야 한다"고 썼다. 이번 글은 그 문장의 실물 검증이다.
재료는 지난 케이스 스터디에서 Claude와 함께 만든 6개월짜리 제조사 ERP 프로젝트를 그대로 이어받는다. 노드 44개, 계획 기간 92일(8월 3일~11월 2일), 종속성 17건짜리 진짜 프로젝트다. 이 계획에서 버튼 하나로 주간보고와 월간보고를 뽑아, 어디까지가 자동이고 어디부터가 사람 몫인지 경계를 그대로 적는다.
전제 — '추출'이 성립하는 조건
보고서를 추출하려면 보고서에 들어갈 것들이 이미 데이터로 존재해야 한다. 주간보고 한 장을 뜯어보면 내용물은 이렇다. 이번 주에 걸쳐 있던 작업들, 각각의 일정과 진척률과 담당자, 다음 주에 시작될 작업들, 다가오는 마일스톤. 전부 WBS와 일정이 이미 알고 있는 것들이다.
문제는 그 데이터가 어디에 사는가다. 계획이 엑셀 파일로 살면 보고서는 '또 하나의 엑셀'이 된다 — 원본과 사본이 서로 다른 말을 하기 시작하는 이야기는 2편에서 다뤘다. wbsgantt에서는 WBS·일정·진척·담당이 하나의 모델이므로, 보고서는 그 모델의 뷰가 될 수 있다. 추출이 성립하는 유일한 조건이다.
버튼 하나에서 나오는 네 장
WBS 화면 우측 상단의 Excel 내보내기를 누르면 옵션 팝오버가 뜨고, 다운로드하면 {프로젝트코드}_{생성시각}.xlsx 파일 하나가 떨어진다. 안에는 시트 네 장이 순서대로 들어 있다.
개요 — A4 세로 한 장짜리 경영 요약. 상단에 전체 진척률·작업 수·시작일·종료일 지표 카드 4종, 가운데에 단계별 진척 표(가중치·기간·일정·진척률), 아래에 다가오는 마일스톤 최대 5개가 D-Day와 함께 실린다. 스티어링 커미티 보고의 첫 장으로 그대로 쓰는 용도다.
WBS — 전체 계획표. 코드·작업명·담당자·가중치·기간·선행·시작·종료·진척률 아홉 열에, 오른쪽으로 주 단위 간트 타임라인이 붙는다(완료·진행 중·계획·단계 구간·마일스톤 다섯 가지 표기). A4 가로 인쇄에 맞게 설계돼 있고 표 머리글은 매 페이지 반복된다. 계획 전체를 부록으로 첨부할 때 쓴다.
주간보고·월간보고 — 이 글의 주인공. 아래에서 해부한다.
한 가지 짚어 둘 것. 시트의 언어는 화면 언어가 아니라 계정 언어를 따른다. 한국어 계정이면 "주간 업무 보고", 영어 계정이면 "Weekly Status Report"로 나온다. 영어 보고를 받는 조직이라면 계정 언어만 바꾸면 된다.
주간보고 해부 — 자동으로 채워지는 것
주간보고 시트는 A4 세로 한 장이다. 위에서부터 제목과 결재란(담당·검토·승인 세 칸), 보고 개요 그리드(프로젝트·코드·보고 기간·작성일·작성자·부서), 그리고 금주 실적과 차주 계획 두 개의 표, 마지막에 이슈 및 요청사항 기입란.
자동 채움의 규칙은 단순하고, 단순해서 예측 가능하다.
- 보고 기간은 생성일이 속한 주(월~일)다. 차주 계획은 그다음 주.
- 금주 실적 표에는 그 주와 일정이 겹치는 작업과 마일스톤이 올라온다. 요약(단계) 행은 빼고, 실제 실행 단위만.
- 각 행에는 코드·작업명·담당·일정·진척률이 채워지고, 상태는 진척률에서 도출된다 — 100%면 완료, 0%면 예정, 그 사이면 진행 중, 마일스톤은 ◆.
ERP 프로젝트로 구체화해 보자. 9월 7일 월요일에 이 파일을 뽑으면 보고 기간은 9/79/13이 되고, 금주 실적에는 그 주에 걸친 "요구사항 검토·확정"(9/79/9) 같은 작업들이 진척률·담당자와 함께 올라온다. 차주 계획 표도 같은 규칙으로 다음 주(9/14~9/20)에 걸치는 작업들로 채워진다. 개요 시트의 "시스템 오픈" 마일스톤은 D-56으로 표시된다. 내가 한 일은 날짜를 계산한 것이 아니라 버튼을 누른 것뿐이다.
월간보고는 같은 구조에 두 가지가 다르다. 표가 당월 주요 실적/익월 계획이 되고, 맨 위에 단계별 진척 요약이 먼저 온다 — 임원 보고에서 "지금 어느 단계가 어디까지 왔나"가 첫 질문이기 때문이다.
비워 둔 칸 — 자동과 수기의 경계
이 양식에서 어떤 칸이 비어 있는지는 어떤 칸이 채워지는지만큼 중요하다. 시트 하단의 각주가 경계를 한 문장으로 요약한다. "실적·계획·진척률은 WBS 데이터에서 자동 반영 · 담당/비고/이슈는 기입란."
| 자동 (데이터의 영역) | 수기 (판단의 영역) |
|---|---|
| 보고 기간·작업 목록·일정 | 작성자·부서, 결재 서명 3칸 |
| 진척률과 상태 | 행별 비고 — 숫자가 설명하지 못하는 맥락 |
| 단계 요약·마일스톤 D-Day | 이슈 및 요청사항 — 무엇이 문제고 누가 움직여야 하는가 |
| — | 표 아래 빈 행 — 계획에 없었지만 이번 주에 한 일 |
이 경계는 지난 케이스 스터디에서 본 것과 같은 선이다. 거기서 wbsgantt가 강제하는 것은 구조적 불변식이고 8/80의 적정성 같은 것은 판단으로 남는다고 썼다. 보고서에서도 같다 — 숫자와 목록은 기계가 뽑지만, "이 이슈를 임원 회의에 올릴 것인가"와 결재란의 서명은 판단이고, 판단은 양식이 대신하지 않는다.
그리고 정직함의 상한. 추출된 보고서는 데이터보다 정직할 수 없다. 진척률이 8주째 80%에 멈춰 있다면(4편의 그 거짓말) 보고서는 그 80%를 깨끗한 서식으로 인쇄해 줄 뿐이다. 추출이 없애 주는 것은 보고서 만드는 시간이지, 보고 내용의 정직함이 아니다. 후자는 진척 산정 규칙의 몫이다.
상황에 맞게 — 옵션 레시피
내보내기 옵션 네 가지(머리글 톤·행 밀도·긴 일정 처리·보고 양식)는 조합하면 쓰임이 갈린다.
| 상황 | 조합 |
|---|---|
| 임원 월간 보고 | 보고 양식 월간만 — 개요가 표지, 월간보고가 본문 |
| 팀 주간회의 | 보고 양식 주간만 + 작업이 많으면 행 밀도 컴팩트 |
| 고객 제출·대량 인쇄 | 머리글 톤 라이트 — 토너 절약용으로 만든 옵션이다 |
| 1년 넘는 장기 프로젝트 | 긴 일정 처리 월 단위 압축, 주 단위 상세가 필요하면 가로 분할 |
| 계획 공유만 | 보고 양식 포함 안 함 — 개요+WBS 두 장 |
한계, 그리고 월요일 루틴
정직하게 적는다. 첫째, 회사 표준 양식으로는 나오지 않는다. 발주처가 자기 템플릿을 요구하면 여전히 옮겨 적어야 한다 — 다만 원천이 한 곳이라 숫자를 찾아 헤매는 일은 없어진다. 둘째, 이슈와 리스크의 서술은 기계가 못 한다. 이건 한계라기보다 설계다 — 그 칸을 자동으로 채워 주는 도구가 있다면 의심해야 한다. 셋째, 스냅샷이다. 각주의 "기준일"이 말하듯 생성 시점 데이터 기준이고, 다음 주엔 다시 뽑는다. 파일을 고치는 게 아니라 데이터를 고치고 다시 추출하는 것 — 그게 이 방식의 요점이다.
그래서 월요일 아침 루틴은 이렇게 된다. ① 지난주 작업의 진척률을 갱신한다(이게 본업이다). ② Excel 내보내기를 누른다. ③ 이슈 기입란에 세 줄을 손으로 쓴다. ④ 결재를 올린다. 6편에서 주 10시간이라 썼던 보고서 제작 시간에서 남는 것은 ①과 ③ — 원래부터 PM의 일이었던 부분뿐이다.
직접 해보기
- 프로젝트의 WBS 화면에서 우측 상단 Excel 내보내기 버튼을 누른다.
- 옵션은 처음엔 기본값(네이비·표준·자동·주간+월간)이면 충분하다.
- .xlsx 다운로드 — 개요·WBS·주간보고·월간보고 네 시트를 확인한다. 인쇄 설정은 손댈 것 없이 A4 그대로다(개요·보고는 세로, WBS는 가로).
보고서가 계획의 사본이 되는 순간 죽기 시작한다는 것이 2편의 논지였다. 사본을 만들지 않는 방법은 하나뿐이다 — 보고서를 문서가 아니라 데이터의 뷰로 만드는 것. 그때 도구는 보고서를 대신 써 주는 것이 아니라, 애초에 쓸 필요가 없던 부분을 지운다. 남은 빈칸이 당신 몫이고, 그 빈칸이 보고의 본질이다.