WBS 작성법 2026 — 작업분류체계 레벨 설계와 100% 규칙·엑셀 열 구성

WBS는 프로젝트를 「할 일 목록」으로 쪼갠 문서입니다. 그런데 실무에서 WBS라고 부르며 주고받는 파일 대부분은 사실 일정표입니다. 작업을 나눈 것이 아니라 날짜를 나열한 것이죠. 이 둘이 섞이면 일정은 있는데 범위는 없는 상태가 되고, 프로젝트 중반에 "그건 원래 포함이었나요"를 다투게 됩니다.

이 글은 WBS를 범위를 확정하는 도구로 쓰는 법을 정리했습니다. 레벨을 어디까지 쪼갤지, 무엇을 작업으로 볼지, 과업지시서·일정표와 어떻게 연결할지를 발주처 관점에서 다룹니다.

WBS란 무엇인가

WBS(Work Breakdown Structure, 작업분류체계)는 프로젝트의 최종 산출물을 관리 가능한 단위까지 계층적으로 쪼갠 구조입니다. 이름 그대로 「작업(Work)을 분해(Breakdown)한 구조(Structure)」이며, 일정·비용·책임을 붙이는 모든 관리의 바닥이 됩니다.

핵심 성질은 세 가지입니다.

1. 산출물 중심이다. 「설계한다」가 아니라 「화면설계서」입니다. 동사가 아니라 결과물로 쪼개야 완료 여부를 판정할 수 있습니다.
2. 100% 규칙을 따른다. 하위 항목을 전부 합치면 상위 항목이 됩니다. 빠진 것도, 겹치는 것도 없어야 합니다.
3. 일정이 아니다. WBS는 「무엇을」이고 일정표는 「언제」입니다. WBS를 먼저 만들고 거기에 날짜를 붙이는 순서입니다.

세 번째가 실무에서 가장 자주 무너집니다. 엑셀을 열고 바로 간트 막대를 그리기 시작하면 작업이 아니라 기간을 나누게 되고, 그러면 막대 사이에 빠진 작업이 보이지 않습니다.

WBS와 일정표·간트차트는 무엇이 다른가

둘을 한 파일에서 관리해도 되지만, 만드는 순서는 지켜야 합니다. WBS를 확정한 뒤 각 항목에 시작일·종료일·담당을 붙이면 그게 일정표입니다. 반대로 하면 일정에 맞춰 작업을 지어내게 됩니다.

간트차트는 WBS의 표현 방식 중 하나일 뿐입니다. WBS 자체는 들여쓴 목록이든 트리 그림이든 표든 상관없습니다. 중요한 건 형식이 아니라 100% 규칙을 만족하는가입니다.

레벨을 어디까지 쪼갤 것인가

가장 많이 받는 질문이고, 답이 「프로젝트마다 다르다」로 끝나면 쓸모가 없습니다. 판단 기준이 있습니다.

레벨 구조 (소프트웨어 개발 기준)

레벨 4가 멈추는 지점입니다. 이 최하위 단위를 작업 패키지(Work Package)라고 부르고, 여기서 더 쪼개지 않습니다. 언제 멈출지는 세 가지로 판단합니다.

셋 중 보고 주기가 실질적으로 가장 중요합니다. 작업 하나가 6주짜리면 5주 동안 "진행 중"만 보고됩니다. 그 5주가 끝난 뒤에야 지연을 알게 되고, 그때는 늦습니다. 반대로 반나절짜리로 잘게 쪼개면 관리 문서가 프로젝트보다 커집니다.

중간 규모 웹 시스템이면 작업 패키지 60~120개 선에서 정리됩니다. 300개가 넘어가면 대부분 너무 잘게 쪼갠 것이고, 30개 미만이면 각 항목 안에서 무슨 일이 벌어지는지 보이지 않습니다.

100% 규칙 — 빠진 작업을 찾아내는 유일한 장치

WBS가 일정표와 구별되는 지점이 이것입니다.

하위 항목의 합은 상위 항목과 정확히 같아야 한다. 더도 덜도 아니게.

이 규칙이 왜 중요하냐면, 빠진 작업을 기계적으로 찾아낼 수 있는 유일한 방법이기 때문입니다. 「설계」 아래에 화면설계서·테이블정의서만 있다면, 인터페이스정의서는 어디 갔는지 물을 수 있습니다. 합이 안 맞으니까요.

실무에서 이 규칙으로 자주 걸리는 누락들입니다.

마지막 항목이 특히 자주 빠집니다. 관리도 작업입니다. 회의·보고·일정 조정에 들어가는 공수를 WBS에 넣지 않으면 그 시간이 개발 공수를 잠식합니다. 통상 전체의 8~15%를 관리 항목으로 잡습니다.

WBS 코드 체계 — 번호를 어떻게 매기나

계층을 점으로 잇는 방식이 표준입니다.

1.       회원관리 시스템 구축
1.1        분석
1.1.1        현행 업무 분석
1.1.2        요구사항 정의서 작성
1.2        설계
1.2.1        화면설계서
1.2.1.1        회원 영역 12화면       ← 작업 패키지
1.2.1.2        관리자 영역 8화면      ← 작업 패키지
1.2.2        테이블 정의서·ERD
1.3        개발
1.4        테스트
1.5        이행

번호를 매기는 이유는 정렬이 아니라 참조입니다. 회의에서 "설계 쪽 화면 그거요"가 아니라 "1.2.1.2"라고 부를 수 있고, 이 번호가 일정표·산출물·검수확인서에 그대로 따라갑니다.

규칙 세 가지만 지키면 됩니다.

작업 패키지 하나에 적어야 할 것

WBS를 표로 관리할 때 각 행에 들어갈 열입니다. 이게 채워지면 그대로 일정표가 되고, 비워 두면 나중에 전부 협의 대상이 됩니다.

완료 기준이 가장 자주 비어 있고 가장 비싸게 돌아옵니다. 「화면설계서 작성」이 완료인지, 「발주처 승인」이 완료인지에 따라 2주가 달라집니다. 산출물이 있는 작업은 승인까지를 완료로 잡는 편이 분쟁이 적습니다.

공수 단위는 인일(人日)로 통일하세요. 어떤 행은 시간, 어떤 행은 주로 적으면 합산이 안 됩니다. 인일로 적어 두면 그대로 견적 근거가 되고, 기능점수 산정과 교차 검증할 수 있습니다.

엑셀로 만들 때 열 구성

대부분 엑셀로 만듭니다. 시트 하나에 아래 열을 두면 WBS와 일정표를 같이 굴릴 수 있습니다.

A  WBS코드      1.2.1.2
B  레벨         4
C  단계         설계
D  작업명       관리자 영역 화면설계
E  산출물       화면설계서 8화면분
F  완료기준     발주처 검토 의견 반영 후 승인
G  담당         기획 A
H  공수(인일)   5
I  선행작업     1.2.1.1
J  시작일       2026-03-04
K  종료일       2026-03-10
L  진척(%)      0
M  상태         대기 / 진행 / 완료 / 보류
N  비고

B열(레벨)을 따로 두는 것이 실무 요령입니다. 필터로 레벨 2만 남기면 경영진 보고용 요약이 되고, 레벨 4만 남기면 실무 작업 목록이 됩니다. 같은 시트로 두 청중을 감당할 수 있습니다.

몇 가지 더 붙이면 편합니다.

• H열 합계를 단계별로 소계 내면 100% 규칙 검증이 자동으로 됩니다. 소계 합이 전체와 안 맞으면 어딘가 빠진 것입니다.
• L열(진척)은 0 / 50 / 100 세 값만 쓰세요. 「70% 완료」는 검증할 수 없고 대부분 희망 사항입니다. 산출물이 나왔는지 여부로만 판정합니다.
• 조건부 서식으로 종료일이 지났는데 상태가 완료가 아닌 행을 붉게 칠해 두면 주간 회의 준비가 끝납니다.

주의 하나. 엑셀에 간트 막대를 그리는 데 시간을 쓰지 마세요. 막대는 보기 좋지만 관리되는 것은 위 열들입니다. 막대가 예쁜 WBS와 완료 기준이 채워진 WBS 중 프로젝트를 구하는 쪽은 후자입니다.

과업지시서·요구사항정의서와 어떻게 연결되나

WBS만 따로 만들면 「그 작업이 계약 범위인지」를 답할 수 없습니다. 문서 간 연결이 그 답을 만듭니다.

연결의 실익은 추적입니다. 요구사항 ID(REQ-MBR-001)가 WBS 코드(1.2.1.2)로, 그게 다시 산출물과 검수 항목으로 이어지면 "이 요구사항이 어느 작업에서 만들어지고 어떻게 검수되는가"가 한 줄로 보입니다. 이 연결이 없으면 검수 단계에서 문서 두 개를 대조하는 데만 며칠이 듭니다.

반대 방향도 중요합니다. WBS에는 있는데 요구사항정의서에 없는 작업이 발견되면 둘 중 하나입니다 — 요구사항이 누락됐거나, 범위 밖 작업이 들어왔거나. 어느 쪽이든 지금 확인해야 할 신호입니다.

흔한 실수 여섯

① 동사로 쪼갠다. 「설계한다 → 개발한다 → 테스트한다」는 WBS가 아니라 단계 이름입니다. 산출물로 쪼개야 완료 판정이 됩니다. 「화면설계서 12화면분」처럼 셀 수 있는 결과물로 적으세요.

② 일정부터 그린다. 간트 막대를 먼저 그리면 작업이 아니라 기간을 나누게 되고, 막대 사이에 빠진 작업이 보이지 않습니다. 순서는 WBS → 일정입니다.

③ 관리·회의·문서화를 안 넣는다. PM 공수, 주간 보고, 산출물 검토가 WBS에 없으면 그 시간이 개발 공수를 잠식합니다. 전체의 8~15%를 관리로 잡으세요.

④ 레벨 깊이가 들쭉날쭉하다. 어떤 가지는 레벨 3에서 끝나고 어떤 가지는 레벨 6까지 갑니다. 깊이 자체가 다른 건 괜찮지만, 최하위가 전부 작업 패키지 기준(8/80, 보고 주기)을 만족하는지는 확인해야 합니다.

⑤ 진척률을 감으로 적는다. 「70% 진행」은 검증할 수 없습니다. 0/50/100만 쓰고, 산출물이 나왔는지로 판정하세요.

⑥ 만들고 안 본다. 착수 보고 이후 열리지 않는 WBS가 많습니다. 주간 회의에서 이 문서를 띄워 놓고 진척을 찍지 않으면 그건 계약 부속서류일 뿐 관리 도구가 아닙니다.

WBS 작성 7단계

3단계와 4단계에 시간의 대부분이 들어갑니다. 기술적으로 어려워서가 아니라 "이것도 범위인가"를 합의해야 하기 때문입니다. 여기를 빨리 넘기면 그 논의가 프로젝트 중반으로 미뤄질 뿐이고, 그때는 비용이 훨씬 큽니다.

발주처가 WBS를 받았을 때 확인할 것

개발사가 WBS를 제출하면 전부 읽을 시간은 없습니다. 다섯 가지만 보세요.

1. 최하위 작업에 산출물과 완료 기준이 있는가 — 비어 있으면 검수 때 다툽니다.
2. 이행 단계에 데이터 이관·교육·운영 이관이 있는가 — 가장 자주 빠지는 세 가지입니다.
3. 관리 공수가 잡혀 있는가 — 없으면 그 시간이 어디선가 나옵니다.
4. 한 작업이 2주를 넘지 않는가 — 넘으면 진척이 안 보입니다.
5. 공수 합계가 견적과 맞는가 — 안 맞으면 둘 중 하나가 근거 없이 만들어진 것입니다.

⚠️ 공수 합계와 견적 금액의 대조가 가장 강력한 검증입니다. WBS 공수를 다 더한 값에 단가를 곱한 것이 견적과 크게 차이 나면, 견적이 감으로 만들어졌거나 WBS가 형식적으로 채워진 것입니다. 이 한 번의 곱셈이 많은 것을 드러냅니다.

트리숲의 WBS 운영 방식

트리숲(TreeSoop)은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. WBS에서 이 환경이 실제로 바꾸는 것은 문서를 빨리 쓰는 일이 아니라 빠진 항목을 빨리 찾아내는 일입니다.

요구사항정의서가 확정되면 그것을 작업 패키지로 전개한 뒤, 역방향 점검을 전수로 돌립니다 — 어느 요구사항에도 연결되지 않은 작업 패키지, 그리고 어떤 작업 패키지로도 전개되지 않은 요구사항을 기계적으로 뽑습니다. 사람이 100개를 대조하면 놓치지만 전수 점검은 놓치지 않습니다. 그 빈칸만 들고 발주처와 회의하면, 회의가 「문서를 같이 읽는 시간」에서 「결정이 필요한 항목만 결정하는 시간」으로 바뀝니다.

진척은 산출물 기준으로만 찍습니다. 0/50/100 세 값이고, 50은 「초안은 나왔으나 승인 전」입니다. 감으로 적는 퍼센트를 허용하지 않는 것이 지연을 일찍 드러내는 가장 싼 방법이었습니다. 이런 방식은 트리숲의 AI-Native 개발 방식에서 일관되게 적용하는 원칙입니다.

발주 문서 전체를 어떤 순서로 준비하는지는 외주 개발 산출물 문서 가이드에, 업체 선정 기준은 외주 업체 선정 스코어카드에 정리했습니다.

WBS를 처음 만들거나 받은 문서를 어떻게 검토할지 막막하시다면 AI-Native 개발사 트리숲에 문의해 보세요. 문서 검토만 단독으로도 도와드립니다. (문의: 카카오톡 채널)

자주 묻는 질문

Q: WBS와 간트차트는 같은 건가요?

아닙니다. WBS는 「무엇을 만드는가」를 쪼갠 구조이고, 간트차트는 거기에 날짜를 붙여 막대로 그린 것입니다. WBS를 먼저 만들고 간트로 표현하는 순서이며, 반대로 하면 일정에 맞춰 작업을 지어내게 됩니다.

Q: 레벨을 몇 단계까지 쪼개야 하나요?

깊이 자체에 정답은 없고, 최하위 작업이 8시간~80시간 사이이고 한 보고 주기 안에 끝나는지로 판단합니다. 소프트웨어 개발은 보통 4단계에서 멈추고, 중간 규모 웹 시스템이면 최하위 작업 60~120개 선에서 정리됩니다.

Q: WBS 양식은 어디서 구하나요?

양식 자체는 중요하지 않습니다. 이 글의 엑셀 열 구성(코드·레벨·단계·작업명·산출물·완료기준·담당·공수·선행·시작·종료·진척·상태)이면 충분합니다. 받아온 양식에 「완료 기준」 열이 없는 경우가 많은데, 그 열이 없으면 검수 때 반드시 다툽니다. 없으면 직접 추가하세요.

Q: 작업이 중간에 늘어나면 WBS를 다시 만드나요?

다시 만들지 않고 추가합니다. 새 번호를 부여하고(기존 번호 재사용 금지), 변경 이력에 일자·사유·공수 증감을 남깁니다. 공공사업이라면 과업 내용 변경에 해당할 수 있어 이 기록이 근거가 됩니다.

Q: 진척률은 어떻게 관리하나요?

0/50/100 세 값만 씁니다. 50은 「초안은 나왔으나 승인 전」입니다. 70%·85% 같은 값은 검증할 방법이 없고 대부분 희망 사항이라, 지연이 드러나는 시점을 늦춥니다.

Q: 관리 공수는 얼마나 잡아야 하나요?

전체의 8~15%가 통상 범위입니다. 회의·보고·산출물 검토·일정 조정이 여기 들어갑니다. 이걸 WBS에 넣지 않으면 그 시간이 개발 공수를 잠식하고, 결국 개발이 밀립니다.

정리

WBS의 값어치는 분량이 아니라 빠진 것을 찾아내는 능력에 있습니다.

• 산출물로 쪼갠다 — 동사가 아니라 셀 수 있는 결과물로
• 100% 규칙으로 검증한다 — 하위의 합이 상위와 같은가
• 8/80과 보고 주기로 멈춘다 — 한 작업이 2주를 넘으면 진척이 안 보인다
• 완료 기준을 적는다 — 「다 했다」의 기준이 사람마다 다르면 검수에서 다툰다
• 공수 합계를 견적과 대조한다 — 이 한 번의 곱셈이 많은 것을 드러낸다

일정표는 매주 바뀌지만 WBS는 범위가 바뀔 때만 바뀝니다. 그래서 WBS가 흔들리면 그건 일정 문제가 아니라 범위 합의가 안 된 것입니다.