WBS 작성법 - 레벨 구조, 산출물 관리, 리스크

솔직히 저는 WBS를 처음 접했을 때 "그냥 엑셀에 할 일 적어두는 표 아닌가?"라고 생각했습니다. 그런데 내용을 파고들수록 그게 얼마나 단순한 오해였는지 깨달았습니다. WBS는 프로젝트의 범위, 담당자, 일정, 산출물, 리스크를 하나의 구조 안에서 연결하는 관리 도구입니다. 제대로 이해하고 나면 "왜 이걸 이제야 알았지"라는 생각이 드는 그런 개념입니다.

WBS란 무엇인가 — 레벨 구조와 산출물 관리

WBS는 Work Breakdown Structure의 약자입니다. 여기서 Breakdown이란 업무를 잘게 쪼개어 위계 구조로 나열한다는 뜻으로, 단순히 할 일을 나열하는 것이 아니라 전체 프로젝트를 트리 구조로 시각화하는 방식입니다. 최상위 레벨에는 프로젝트 전체가, 하위 레벨로 내려갈수록 각 포지션별 세부 업무가 자리잡는 구조입니다.

프로젝트 관리 분야의 국제 표준인 PMBOK(Project Management Body of Knowledge)에서도 WBS를 프로젝트 범위 관리의 핵심 도구로 정의하고 있습니다. 레벨은 프로젝트 성격에 따라 보통 3단계에서 6단계까지 세분화됩니다. 제가 이 구조를 처음 살펴봤을 때, 레벨이 너무 많아지면 오히려 관리가 복잡해지겠다는 생각이 들었는데, 실제로 현장에서도 과도한 세분화는 독이 된다는 의견이 많습니다.

포지션 구분도 인상적이었습니다. WBS는 사업관리, 기획, 디자인, 퍼블리싱, 개발, 테스트의 총 6개 영역으로 업무를 분류합니다. 각 포지션마다 담당자와 기간을 명시하고, 업무가 끝났을 때 실제로 무엇이 만들어지는지까지 기록합니다. 이 결과물을 산출물이라고 부르는데, 여기서 산출물이란 각 업무가 완료되었음을 증명하는 실체적인 결과물을 의미합니다. 예를 들어 기획 업무의 산출물은 '요구사항 정의서', 디자인 업무의 산출물은 'PSD 파일'이 되는 식입니다.

WBS를 산출물 중심으로 작성해야 하는 이유

WBS 작성 방식에 대해서는 의견이 갈립니다. '업무 행위'를 중심으로 적어야 한다고 보는 분들도 있는데, 저는 내용을 살펴보면서 '산출물'을 중심으로 정의하는 방식이 훨씬 실용적이라는 쪽에 마음이 기울었습니다. '기획한다'와 '요구사항 정의서 작성 완료'는 같아 보이지만 완전히 다릅니다. 전자는 언제 끝났는지 알 수 없고, 후자는 문서가 나오는 순간 완료가 확인됩니다.

이 차이가 프로젝트 현장에서는 상당히 중요합니다. 완료 기준이 모호하면 "이건 누가 하는 거죠?", "이게 끝난 건가요?"라는 질문이 반복됩니다. 산출물이 명확한 WBS는 그 자체로 커뮤니케이션 비용을 줄이는 역할을 합니다. 또한 WBS는 작성 후 방치해선 안 됩니다. M/M(Man-Month) 기준으로 비용을 산정하는 근거 자료로도 활용되고, 프로젝트 종료 후에는 최종 산출물로 제출되기도 하기 때문에 지속적인 업데이트가 필수입니다. 여기서 M/M이란 한 사람이 한 달 동안 수행할 수 있는 업무량을 단위로 환산한 인력 투입 지표를 의미합니다.

• 레벨 구조(Level Structure): 프로젝트 전체를 트리 형태로 3~6단계까지 세분화하여 업무 위계를 정의
• 포지션별 업무 정의: 사업관리·기획·디자인·퍼블리싱·개발·테스트 6개 영역으로 책임 소재를 명확히 구분
• 산출물(Deliverable) 명시: 각 업무의 완료 기준을 실체적 결과물로 표현하여 완료 시점을 객관화
• M/M 기반 비용 산정: 투입 인력과 기간을 수치화해 견적 근거 자료로 활용 가능

요약: WBS는 업무를 레벨 구조로 쪼개고 산출물 중심으로 정의할 때 완료 기준이 명확해지며, 비용 산정과 커뮤니케이션 비용 절감까지 이어집니다.

 

WBS 잘못 쓰면 생기는 일 — 리스크 관리와 현실적 한계

WBS를 잘못 작성하면 "프로젝트가 산으로 갔다"는 말을 듣게 된다고 합니다. 제가 직접 경험한 건 아니지만, 이 말이 단순한 비유가 아니라는 건 구조를 이해하고 나서 바로 납득이 됐습니다. WBS가 흔들리면 범위(Scope), 일정, 비용, 인력 모두가 한꺼번에 흔들리기 때문입니다.

여기서 범위(Scope)란 프로젝트에서 수행해야 할 업무의 전체 경계를 의미합니다. 이 범위가 명확하지 않으면 작업이 계획 외로 계속 추가되는 스코프 크리프(Scope Creep) 현상이 발생합니다. 스코프 크리프란 초기에 합의된 프로젝트 범위가 통제 없이 점진적으로 확장되는 현상으로, 일정 지연과 비용 초과의 주된 원인 중 하나입니다. WBS에서 범위를 처음부터 명확하게 정의하면 이런 상황을 미연에 차단할 수 있습니다.

WBS는 주간, 일간, 월간 단위로 진척률을 업데이트하며 리스크(Risk)를 관리하는 역할도 합니다. 여기서 리스크란 프로젝트 목표 달성을 방해할 수 있는 불확실한 사건이나 조건을 말합니다. WBS를 정기적으로 갱신하면 어느 업무가 지연되고 있는지, 어디서 병목이 생기는지를 조기에 파악할 수 있습니다.

 

WBS가 만능은 아니라는 점도 솔직히 말씀드립니다

WBS가 프로젝트 관리에 핵심 도구라는 점에는 동의하지만, 한편으로는 WBS 자체에 지나치게 의존하면 오히려 독이 될 수 있다고 생각합니다. 아무리 정교하게 작성해도 실제 담당자가 일정을 못 지키거나, 부서 간 의사소통이 안 되면 WBS는 그냥 예쁜 엑셀 파일로 끝납니다. 문서가 프로젝트를 대신 관리해주지는 않습니다.

'모든 업무를 WBS에 포함해야 한다'는 원칙도 현실에서는 상당히 까다롭다고 느꼈습니다. 프로젝트 초반에는 아직 무엇을 해야 할지 모르는 업무들이 존재하기 때문입니다. 제 생각엔 처음부터 완벽한 WBS를 만들려다 WBS 작성 자체에 시간을 다 써버리는 것보다, 큰 단위로 시작해서 프로젝트가 진행되면서 점진적으로 구체화하는 방식이 훨씬 현실적입니다. WBS는 미래를 예언하는 문서가 아니라, 지금 알고 있는 정보를 바탕으로 만든 관리 기준선이라고 보는 편이 맞습니다.

결국 좋은 WBS는 가장 복잡하게 쪼개진 WBS가 아니라, 프로젝트에 참여하는 사람들이 보는 순간 "지금 내가 뭘 해야 하고, 언제까지 어떤 결과를 내야 하는지"를 바로 이해할 수 있는 WBS라고 생각합니다. 업무 항목 수가 많다고 잘 만든 게 아니라는 점, 저는 이 부분이 가장 중요한 핵심이라고 봅니다.

요약: WBS는 범위 관리와 리스크 조기 감지에 강력하지만, 완벽한 초기 작성보다 점진적 업데이트와 명확한 완료 기준이 더 중요합니다.

 

자주 묻는 질문

Q. WBS는 엑셀로만 만들어야 하나요?

A. 반드시 엑셀일 필요는 없습니다. Jira, Notion, MS Project 등 다양한 도구로도 작성할 수 있습니다. 다만 WBS에서 중요한 것은 도구가 아니라 레벨 구조, 담당자, 산출물, 완료 기준이 명확하게 기록되어 있느냐입니다. 엑셀이 여전히 널리 쓰이는 건 접근성이 높기 때문이지, 엑셀이 정답이라서는 아닙니다.

 

Q. WBS 레벨은 몇 단계까지 쪼개야 하나요?

A. 정해진 정답은 없고, 프로젝트 규모와 복잡도에 따라 3~6단계가 일반적입니다. 지나치게 세분화하면 관리 항목이 폭발적으로 늘어나 오히려 현장에서 혼란이 생깁니다. 각 레벨의 업무가 담당자 한 명이 책임질 수 있는 단위로 쪼개졌다면 그 정도가 적당하다고 보는 시각이 많습니다.

 

Q. WBS가 잘못 작성되면 어떤 문제가 생기나요?

A. 가장 흔한 문제는 스코프 크리프, 즉 계획에 없던 업무가 통제 없이 계속 추가되는 현상입니다. 업무 범위와 완료 기준이 불명확하면 "이거 누가 하는 거죠?", "이게 완료된 건가요?" 같은 질문이 반복되고, 일정 지연과 비용 초과로 이어집니다. WBS를 제대로 작성하고 관리하는 것만으로도 이런 상황을 상당 부분 예방할 수 있습니다.

 

Q. WBS는 처음에 완벽하게 작성해야 하나요?

A. 완벽한 초기 WBS를 만들려는 시도 자체가 오히려 프로젝트 시작을 늦추는 원인이 될 수 있습니다. 프로젝트 초반에는 알 수 없는 것들이 많기 때문에, 처음에는 큰 단위로 작성하고 프로젝트가 진행되면서 점진적으로 구체화하는 방식이 현실적입니다. WBS는 한 번 쓰고 끝나는 문서가 아니라 주간 또는 월간 단위로 꾸준히 업데이트해야 하는 살아있는 관리 도구입니다.

 

결론

WBS를 배우면서 제가 가장 크게 달라진 건 프로젝트를 바라보는 관점이었습니다. '해야 할 일들의 목록'이 아니라 목표 → 업무 → 담당자 → 일정 → 산출물 → 완료 기준으로 이어지는 연결 구조로 보게 되었습니다. 그 연결이 끊어지는 순간 프로젝트가 산으로 가기 시작한다는 것도요.

아직 실제 프로젝트에서 WBS를 직접 운영해본 경험은 없기 때문에, 업무를 어느 수준까지 쪼개야 하는지, 부서 간 업무가 맞물릴 때 어떻게 조정하는지는 아직 배워야 할 부분이 많습니다. 하지만 이제는 엑셀 양식을 채우는 것이 목표가 아니라, 계획과 현실의 차이를 WBS가 어떻게 좁혀주는지를 이해하는 것이 진짜 목표라는 걸 압니다. 처음 WBS를 작성하게 된다면 완벽함보다 명확함을 우선으로 삼아 시작해볼 생각입니다.

 

참고: 이랜서블로그