주간 업무 보고서 쓰는 법 — 진행율 표로 5분 만에 쓰는 양식

프로젝트·일정 · 실용 가이드 · 2026. 09. 25 · 작성 rohan

금요일 오후마다 주간 보고서 앞에서 30분을 보내고도 "그래서 지금 괜찮은 건가요?"라는 답장을 받는다면, 문제는 글솜씨가 아니라 양식입니다. 이 글은 요약 3줄 + 진행율 표 + 이슈 3요소로 구성된 양식을 소개하고, 계획 진행율과 실제 진행율을 왜 같이 넣는지, 정상·주의·지연을 어떤 숫자로 가르는지, 그리고 도구에서 표를 5분 만에 뽑는 순서를 정리합니다. 마지막에 그대로 베껴 쓸 수 있는 예시 보고서 전문과 흔한 실수를 붙였습니다. 진행율 숫자 자체를 매기고 집계하는 규칙은 프로젝트 진행율 계산법, 보고서에 올릴 마일스톤을 고르는 법은 마일스톤 정하는 법에서 다룹니다.

주간 보고서의 목적 — 읽는 사람이 결정하게 만드는 것

주간 보고서는 "내가 이번 주에 열심히 했다"를 증명하는 문서가 아닙니다. 읽는 사람이 무언가를 결정하거나, 결정할 필요가 없음을 확인하게 하는 문서입니다. 팀장은 보고서를 보고 "이 팀은 그냥 두면 되는가, 개입해야 하는가"를 판단하고, 개입한다면 "사람을 붙일까, 범위를 줄일까, 고객에게 미리 말할까"를 고릅니다. 이 관점으로 쓰면 무엇을 넣고 뺄지가 저절로 정해집니다. 결정에 영향이 없는 내용은 아무리 고생했어도 뺍니다.

그래서 좋은 주간 보고서는 숫자로 상태를 보여 주고, 문장으로는 이슈와 요청만 씁니다. 작업 하나하나를 설명하는 글은 길어질수록 안 읽힙니다. 상태는 표에 맡기고, 글은 표가 말하지 못하는 것에만 씁니다.

기본 구조 — 5개 블록, 이 순서대로

순서	블록	분량	내용
1	요약	3줄	전체 상태(정상/주의/지연), 다음 마일스톤과 날짜, 오늘 결정이 필요한 것 1가지
2	진행율 표	표 1개	작업별 계획 진행율·실제 진행율·차이·상태·비고
3	이번 주 완료	3~5줄	끝난 것만. "진행 중"은 여기 넣지 않음
4	다음 주 계획	3~5줄	다음 주 금요일에 끝나 있을 것
5	이슈·요청	0~3건	사실·영향·요청 3요소로. 없으면 "없음"이라고 명시

요약이 맨 위에 오는 이유는 바쁜 사람이 3줄만 읽고 닫아도 되게 하기 위해서입니다. 진행율 표가 두 번째인 이유는 요약의 근거를 바로 보여 주기 위해서입니다. 완료·계획은 그 다음이고, 이슈는 맨 아래지만 요약 3번째 줄에 반드시 한 번 언급돼 있어야 합니다.

진행율 표 양식 — 계획과 실제를 나란히

표의 열은 여섯 개면 충분합니다. 작업 / 계획 진행율 / 실제 진행율 / 차이 / 상태 / 비고. 여기서 계획 진행율은 기간진행율, 즉 "오늘까지 기간이 얼마나 흘렀나"이고, 실제 진행율은 "일이 실제로 얼마나 됐나"입니다.

작업	계획(기간)	실제	차이	상태	비고
2.1 API 설계	100%	100%	0%p	완료	10/21 리뷰 통과
2.2 회원가입 화면	60%	65%	+5%p	정상	—
2.3 결제 연동	50%	25%	−25%p	지연	PG사 테스트 계정 미발급. 10/28 발급 시 11/4 완료 예정

두 진행율을 같이 넣는 이유는 실제 진행율 하나만으로는 늦었는지 알 수 없기 때문입니다. "결제 연동 25%"는 그 자체로 좋은 것도 나쁜 것도 아닙니다. 기간이 절반 지났는데 25%라서 문제인 것입니다. 차이 열이 이 판단을 숫자 하나로 압축합니다. 기간진행율을 계산하는 방식과 상위 작업 집계, 획득가치(SPI)까지는 프로젝트 진행율 계산법에서 자세히 다뤘으니, 이 글에서는 보고서에 어떻게 얹는지에 집중합니다.

• 표에는 이번 주에 살아 있는 작업만 넣습니다. 3주 전에 끝난 작업이나 다음 달에 시작할 작업은 뺍니다. 보통 5~12행이면 충분합니다.
• 작업 수가 많으면 상위 항목(단계) 단위로 접어서 보고하고, 지연된 것만 하위 작업까지 펼칩니다.
• 표 위에 프로젝트 전체의 계획·실제 진행율 두 숫자를 한 줄로 씁니다. "전체: 계획 48% / 실제 42% (−6%p)"처럼요.

상태 색 규칙 — 팀 안에서 한 번만 정해 둔다

상태를 "정상·주의·지연" 세 단계로 나누고, 차이(실제−계획)를 기준으로 기계적으로 정합니다. 사람마다 다르게 판단하면 색의 의미가 사라집니다. 아래는 소프트웨어·기획 프로젝트에서 무난하게 쓰는 기준이며, 팀 사정에 맞게 숫자만 바꾸면 됩니다.

상태	기준(차이 = 실제 − 계획)	보고서에서의 의미	색
완료	실제 100%	더 볼 것 없음	회색 또는 파랑
정상	−10%p보다 큼(0 근처 또는 앞섬)	개입 불필요	초록
주의	−10%p ~ −20%p	이번 주 안에 회복 가능한지 담당자와 확인	노랑
지연	−20%p보다 작음, 또는 종료일이 지났는데 미완료	새 완료 예정일과 대응이 반드시 적혀야 함	빨강

기간이 짧은 작업(3일 이하)은 하루만 밀려도 −30%p가 나오므로, 차이 대신 "종료일 경과 여부"만으로 판정하는 예외를 둡니다. 경계값에 걸린 경우를 미리 정해 두면 논쟁이 줄어듭니다. 위 기준에서는 −10%p 정각은 주의, −20%p 정각도 주의, −21%p부터 지연입니다. 참고로 이 사이트의 WBS·간트차트 도구가 자동으로 붙이는 상태(완료·진행중·지연·예정)는 날짜 기준입니다. 종료일이 지났는데 100% 미만이면 지연, 그 전까지는 차이가 얼마든 진행중이므로, 정상과 주의는 엑셀로 내려받은 표에서 차이 열을 계산해 직접 나눠야 합니다.

이슈 쓰는 법과 숫자 없는 보고의 문제

이슈는 사실·영향·요청 세 요소로

이슈 항목이 "결제 연동이 어렵습니다"로 끝나면 읽는 사람은 아무것도 할 수 없습니다. 이슈는 반드시 세 요소로 씁니다.

1. 사실 — 무슨 일이 언제 일어났는가. "PG사 테스트 계정이 10/7 신청 후 아직 발급되지 않음(약속은 3영업일)."
2. 영향 — 그래서 일정·범위·품질에 무엇이 생기는가. "결제 연동 작업이 5영업일 밀려, 11/6 베타 마일스톤에서 결제 기능 제외 가능성."
3. 요청 — 읽는 사람이 무엇을 해 주면 되는가. "PG사 영업 담당에게 팀장 명의로 독촉 메일 부탁드립니다. 또는 베타에서 결제 제외를 승인해 주세요."

요청이 없는 이슈는 "공유"라고 따로 표시합니다. 그러면 읽는 사람은 공유 항목은 넘기고 요청 항목에만 답하면 됩니다. 이슈가 셋을 넘으면 가장 큰 것 셋만 보고서에 넣고 나머지는 이슈 목록 문서로 링크합니다.

숫자 없는 보고가 만드는 문제

"순조롭게 진행 중입니다", "거의 다 됐습니다", "조금 지연되고 있으나 만회 가능합니다". 이런 문장은 쓰는 사람에게는 편하지만, 3주 뒤에 "왜 이제 와서 늦었다고 하느냐"는 말을 듣게 하는 원인입니다. 문제는 세 가지입니다.

• 추세가 안 보입니다. "거의 다 됐다"가 3주 연속이면 멈춘 것인데, 숫자가 없으면 아무도 눈치채지 못합니다. 실제 진행율이 60→62→63%로 적혀 있으면 한눈에 보입니다.
• 기준이 없어 논쟁이 됩니다. "조금 지연"이 2일인지 2주인지 사람마다 다르게 읽습니다.
• 작성자가 스스로를 속이기 쉽습니다. 숫자를 쓰려면 계산을 해야 하고, 계산하다 보면 안 좋은 상황을 본인이 먼저 알게 됩니다. 이것이 숫자 보고의 가장 큰 효용입니다.

진행율을 정확히 매기기 어렵다는 반론이 있는데, 정확도보다 같은 규칙으로 매주 재는 것이 중요합니다. 0/50/100 세 단계로만 매겨도 추세는 잡힙니다.

도구에서 표를 5분 만에 만드는 순서

매주 표를 손으로 그리면 결국 안 쓰게 됩니다. 일정 데이터가 한 곳에 있으면 보고서 표는 거기서 뽑아내는 것이어야 합니다. WBS·간트차트 도구에서 뽑는 순서입니다.

1. 금요일 오후, 팀원들이 담당 작업의 진행율을 알려 주면 일정 관리자 한 명이 원본에 입력합니다. 이 도구는 데이터를 각자의 브라우저에 저장하므로 여러 사람이 한 일정을 동시에 고치는 공동 편집은 되지 않습니다. [🔗 공유] 링크는 그 시점 일정의 사본을 보내는 것이라, 받은 사람이 고쳐도 원본에는 반영되지 않습니다. 기간진행율은 오늘 날짜 기준으로 자동 계산되어 있습니다.
2. 대시보드를 열어 전체 진행율과 상태 통계(완료·진행중·지연·예정 비율), 단계별 진척을 확인합니다. 요약 3줄에 들어갈 숫자가 여기서 나옵니다.
3. 툴바의 ⚠ 지연만 버튼(지연 작업이 있을 때만 나타남)으로 필터를 걸어 지연 행을 확인합니다. 이 행들이 이슈 블록의 후보입니다. 비고 칸에 원인과 새 완료 예정일을 그 자리에서 적습니다.
4. 엑셀 다운로드(⋯ 메뉴)로 .xlsx를 받습니다. 번호·과제명·담당자·시작일·종료일·업무량·진행율·기간진행율·상태·비고 열이 함께 나오므로, 이번 주 살아 있는 행만 남기고 "진행율 − 기간진행율" 차이 열을 하나 추가하면 진행율 표가 완성됩니다.
5. 보고서 문서에 표를 붙이고, 요약·완료·계획·이슈를 씁니다. 익숙해지면 표 만들기 5분, 글쓰기 10분입니다.

엑셀로만 관리한다면 기간진행율 열을 수식으로 두면 같은 흐름이 가능합니다. 수식은 간트차트 엑셀로 만드는 법의 진행율 부분에 있습니다.

팀별 통합과 채널별 분량 조절

팀별 보고를 하나로 합칠 때

여러 팀의 주간 보고를 한 문서로 합쳐야 하는 PMO나 부서장이라면, 각 팀이 같은 열 구조·같은 상태 기준으로 쓰게 하는 것이 합치기의 전부입니다. 형식이 다르면 합치는 사람이 매주 번역을 해야 합니다. 통합 보고서는 아래처럼 한 단계 위에서 씁니다.

• 요약은 팀별 한 줄. "A팀 정상 / B팀 주의(결제 연동) / C팀 정상."
• 진행율 표는 팀(또는 프로젝트)이 한 행. 각 팀의 전체 계획·실제 진행율만 넣고, 상세는 팀 보고서 링크로.
• 이슈는 팀 간 의존이 걸린 것과 부서장 결정이 필요한 것만 올립니다. 팀 안에서 해결되는 이슈는 올리지 않습니다.

이메일·슬랙·문서, 어디에 보내느냐에 따라 분량 조절

채널	분량	넣을 것	뺄 것
슬랙·메신저	10줄 이내	요약 3줄, 전체 진행율 한 줄, 요청 사항, 문서 링크	표 전체(스크린샷이나 링크로 대체)
이메일	화면 1~1.5장	요약, 진행율 표(살아 있는 행만), 이슈·요청	완료·계획 상세는 접거나 첨부
문서(위키·공유 문서)	제한 없음	5개 블록 전부, 지난주 대비 변화, 첨부 자료	—. 다만 누적본은 주차별로 나눠 둠

같은 내용을 채널마다 따로 쓰지 말고, 문서를 원본으로 두고 슬랙·이메일에는 요약과 링크만 보냅니다. 원본이 하나여야 "어느 버전이 맞느냐"가 안 생깁니다.

예시 보고서 전문 — 회원가입·결제 기능 개발 3주 차

아래는 실제로 보낼 수 있는 분량의 이메일용 예시입니다. 표는 살아 있는 작업만 넣었습니다.

이 예시에서 전체 차이는 −6%p로 기준상 정상이지만 요약의 전체 상태를 주의로 올린 것은, 다음 마일스톤에 걸린 작업(2.3)이 지연이기 때문입니다. 전체 평균은 지연 작업 하나를 희석하므로, 전체 상태는 평균이 아니라 다음 마일스톤에 걸린 작업 중 가장 나쁜 상태로 적는 규칙을 두면 이런 판단이 일관됩니다.

흔한 실수

• 한 일 나열형. "회의 3회, 문서 2건 작성, 코드 리뷰"는 활동이지 결과가 아닙니다. 끝난 것과 진행율로 바꿔 씁니다.
• 지연을 비고 없이 숫자만 적기. −25%p 옆에 원인과 새 예정일이 없으면 읽는 사람은 다시 물어봐야 합니다. 지연 행의 비고는 필수입니다.
• 매주 형식이 바뀜. 형식이 같아야 지난주와 비교가 됩니다. 한 번 정하면 최소 프로젝트 끝까지 유지합니다.
• 요청을 이슈 안에 숨기기. 요청은 요약 3번째 줄과 이슈 블록 두 곳에 나와야 합니다. 한 곳에만 있으면 놓칩니다.
• 좋은 소식만 쓰기. 주의 상태를 정상으로 올려 적으면 그 주는 편하지만, 지연으로 바뀌는 순간 신뢰가 사라집니다. 주의는 주의로 씁니다.
• 금요일 밤에 몰아서 쓰기. 진행율을 매일 조금씩 갱신해 두면 금요일에는 표를 뽑고 글만 쓰면 됩니다.

자주 묻는 질문

계획 진행율(기간진행율)과 실제 진행율을 왜 둘 다 넣어야 하나요?

실제 진행율만으로는 늦었는지 알 수 없기 때문입니다. '결제 연동 25%'는 기간이 10% 지났으면 앞선 것이고 50% 지났으면 늦은 것입니다. 오늘까지 흘러간 기간의 비율인 계획(기간)진행율을 옆에 두고 차이를 계산하면, 상태를 숫자 하나로 판단할 수 있고 매주 추세도 보입니다.

정상·주의·지연은 어떤 기준으로 나누나요?

차이(실제 − 계획)를 기준으로 기계적으로 정합니다. 무난한 기준은 차이가 −10%p보다 크면 정상, −10%p에서 −20%p까지 주의, −20%p보다 작거나 종료일이 지났는데 미완료면 지연입니다. 기간이 3일 이하인 짧은 작업은 하루만 밀려도 차이가 크게 나오므로 종료일 경과 여부로만 판정하는 예외를 둡니다. 숫자는 팀에 맞게 바꾸되 한 번 정하면 프로젝트 내내 유지합니다.

이슈는 어떻게 써야 읽는 사람이 바로 움직이나요?

사실·영향·요청 세 요소를 빠짐없이 씁니다. 무슨 일이 언제 일어났는지(사실), 그래서 일정·범위·품질에 무엇이 생기는지(영향), 읽는 사람이 무엇을 해 주면 되는지(요청)입니다. 요청이 없는 항목은 [공유]로 표시해 구분하고, 이슈가 셋을 넘으면 가장 큰 셋만 넣고 나머지는 이슈 목록 문서로 링크합니다.

진행율 표를 매주 손으로 만들지 않으려면 어떻게 하나요?

일정 데이터를 한 곳에 두고 거기서 표를 뽑아내는 구조로 바꿉니다. WBS·간트차트 도구라면 일정 관리자 한 명이 팀원들이 알려 준 진행율을 입력한 뒤 대시보드에서 전체 숫자를 읽고, 지연만 보기 필터로 이슈 후보를 확인한 다음, 엑셀 다운로드로 받은 파일에서 이번 주 살아 있는 행만 남기면 표가 됩니다. 기간진행율과 상태는 자동 계산되므로 표 만들기는 5분 정도로 줄어듭니다.

정리

주간 보고서는 읽는 사람이 결정하게 만드는 문서입니다. 요약 3줄 → 진행율 표 → 이번 주 완료 → 다음 주 계획 → 이슈·요청의 순서로 쓰고, 표에는 계획(기간)진행율과 실제 진행율을 나란히 두어 차이로 상태를 판정합니다. 상태는 정상·주의·지연 세 단계로 기준을 한 번 정해 팀 전체가 같은 규칙으로 쓰고, 이슈는 사실·영향·요청 세 요소로 씁니다. 데이터가 도구 한 곳에 있으면 표는 대시보드와 엑셀 내보내기로 5분이면 나오니, 금요일에는 글만 쓰면 됩니다. 형식을 매주 같게 유지하는 것, 그리고 주의를 주의라고 솔직하게 쓰는 것이 보고서의 신뢰를 만듭니다.

→ 프로젝트 진행율 계산법 · → 마일스톤 정하는 법 · → 프로젝트 일정 관리 방법