WBS란 무엇인가: 비개발자를 위한 작업 분해 구조 가이드

얼마 전 처음 외주를 맡기신다는 발주사 분과 미팅에서 이런 질문을 받았습니다. 다른 회사에서 받은 견적서를 보여주시면서 이렇게 말씀하셨습니다.

“총 5,000만 원이라고만 적혀 있는데, 이게 맞는 견적인지 모르겠습니다.”

흔한 상황입니다. 견적서가 한 줄로 끝나면 발주사 입장에서는 어떻게 협상을 시작해야 할지부터 막막합니다. 어디서 줄일 수 있는지, 변경하면 비용이 얼마나 늘어나는지, 진행률은 어떻게 확인하는지가 모두 보이지 않기 때문입니다.

그래서 저희는 모든 프로젝트에서 가장 먼저 확정하는 문서가 WBS(Work Breakdown Structure, 작업 분해 구조) 입니다. 외주를 사고 파는 ‘단위’ 그 자체라고 보시면 됩니다. 단위가 잘게 분해되어 있어야 협상이 가능하고, 변경이 추적되며, 진행률을 직접 확인하실 수 있습니다.

오늘은 WBS가 정확히 무엇인지, 좋은 양식과 나쁜 양식이 어떻게 다른지, 그리고 견적서·WBS를 받으셨을 때 5분 안에 점검할 3가지를 정리해드립니다.

WBS란 무엇인가

WBS는 Work Breakdown Structure의 약자이며, 한국어로는 ‘작업 분해 구조’ 라고 부릅니다. 한 프로젝트가 만들어내야 할 결과물을 더 작은 단위로 계속 쪼갠 표라고 이해하시면 됩니다.

원래는 PMI(Project Management Institute) 가 정의한 프로젝트 관리 표준이지만, IT 외주 현장에서는 좀 더 실용적인 의미로 사용됩니다. 견적이 어떻게 만들어졌는지, 일정이 어떻게 짜였는지, 진행률은 어떻게 확인하는지, 이 세 가지의 기준선 역할을 합니다.

시작할 때 견적과 끝날 때 비용이 같아야 외주입니다. 그 ‘같음’ 을 보장해주는 종이 한 장이 WBS입니다.

외주에 WBS가 꼭 필요한 이유

저희가 7년 동안 30개 넘는 프로젝트를 진행하면서 외주 분쟁의 패턴을 정리해보니, 80% 이상이 변경관리 단계에서 발생했습니다. “원래 5,000만 원에 합의했는데 끝나니 7,000만 원이 청구됐다”, “이 기능은 들어가는 줄 알았는데 빠져 있다” 같은 사례가 대표적입니다.

분쟁의 공통점은 단 하나입니다. 변경이 발생했을 때, 그 변경이 견적·일정·범위 중 어디에 어떤 영향을 주는지 측정할 기준선이 없었다는 점입니다.

WBS가 있으면 흐름이 달라집니다.

발주사가 “회원가입에 SMS 인증을 추가하고 싶습니다” 라고 하시면, 개발사는 WBS의 어느 행이 어떻게 늘어나는지 즉시 계산해 회신할 수 있습니다. 발주사 분도 “이게 1.5MD니까 약 30만 원 정도 늘어나겠다” 정도는 직접 추정하실 수 있습니다. 합의가 되면 신규 행을 추가하고, 영향받는 마일스톤만 다시 그립니다.

이 흐름이 없으면 변경은 결국 “그냥 추가해주세요” 와 “그건 별도 비용입니다” 의 다툼으로 끝납니다.

나쁜 WBS와 좋은 WBS의 차이

같은 ‘회원가입 기능’ 을 두 양식으로 비교해보면 차이가 분명히 드러납니다.

나쁜 예시

1. 회원가입 기능       — 5일
2. 상품 목록           — 7일
3. 결제                — 10일

세 줄짜리 표입니다. 총 22일, 총 X원. 이 표만 보고 다음 질문에 답하실 수 있는지 한번 확인해보십시오.

• “회원가입에서 SNS 로그인을 빼면 며칠 줄어듭니까?”
• “결제는 PG가 어디로 들어갑니까? 카드만 적용하면 며칠입니까?”
• “상품 목록에 검색 기능이 포함되어 있습니까?”

세 줄짜리 WBS는 사실상 견적서 한 줄과 다르지 않습니다. 분해가 없으니 협상이 불가능하고, 변경의 영향을 측정할 수도 없습니다.

좋은 예시

같은 회원가입 기능이 좋은 WBS에서는 다음과 같이 분해됩니다.

1.1 회원가입 - 화면 (디자이너 1.0MD)
1.2 회원가입 - 이메일 가입 API (백엔드 1.5MD)
1.3 회원가입 - 카카오/네이버 SNS 로그인 (백엔드 2.0MD)
1.4 회원가입 - 본인인증 NICE 연동 (백엔드 1.0MD)
1.5 회원가입 - 모바일 앱 화면 구현 (앱 2.5MD)
1.6 회원가입 - QA (테스터 0.5MD)

이 분해의 가치는 분명합니다. 발주사가 “예산을 줄이려면 SNS 로그인을 빼고 싶다” 라고 하시면, 개발사는 1.3 행을 빼고 2.0MD × 단가만큼 차감해 견적을 다시 드립니다. 일정도 하루 가까이 줄어듭니다. 변경이 즉시 계산되는 구조입니다.

샐링잇이 실제로 사용하는 WBS 양식

저희가 30개 넘는 프로젝트를 거치며 정착시킨 양식은 다음 컬럼으로 구성됩니다.

• NO: W0, W1, W2 형식의 작업 번호. 의존성 표기와 변경 이력 추적에 사용합니다.
• 대분류 / 소분류: “인앱결제(iOS) / 결제 환불” 같은 2단계 분류. 변경·검색이 빠릅니다.
• 완료여부: 대기 / 진행 / 완료. 셀 색상으로도 한눈에 구분되도록 합니다.
• 내용: 그 작업의 상세 메모. 외부 의존성(“PG사 계약. 2주 정도 예상”) 이나 정책 결정도 같은 행에 기록합니다. 나중에 “왜 이렇게 결정했는지” 가 궁금할 때 도움이 됩니다.
• 시작일 / 종료일: 마일스톤·인력 배분의 기준입니다.
• 비고: 담당, 변경 이력, 외부 라이선스 같은 보조 정보입니다.

저희가 실제로 사용하는 WBS. 한 줄이 곧 협상·진행률 추적·정산의 단위입니다.

데모는 WBS 안에 행으로 넣지 않고 별도로 운영합니다. 매주 또는 격주 단위로 일정을 잡아 진행률을 함께 확인하는 방식입니다. WBS는 “무엇을 얼마에 만들 것인가” 의 기준선이고, 데모는 “지금 어디까지 왔는가” 를 보여주는 자리이기 때문에 두 가지를 같은 표 안에 섞지 않습니다.

변경이 발생하면 기존 행은 수정하지 않습니다. 신규 행을 추가합니다. 예를 들어 원래 견적에 없던 “1.7 회원가입 - 토스 본인인증 추가 (1.5MD, 2026-05-15 추가)” 식으로 기록하면 “언제 누가 무엇을 추가했는가” 가 그대로 남고, 분쟁이 발생해도 추적이 가능합니다.

좋은 WBS는 협상의 도구입니다. 빼고 싶으면 빼고, 새로 넣으면 새로 넣고, 그 효과가 그 자리에서 계산됩니다.

받자마자 5분 안에 점검할 3가지

외주사로부터 견적서와 WBS를 함께 받으셨다면, 다음 3가지를 차분히 점검해보십시오.

1. 화면·기능·인프라·QA가 행으로 분리되어 있는가

한 행에 “회원가입 기능 일체 — 5일” 식으로 묶여 있다면 위험 신호입니다. 디자인·프론트·백엔드·QA가 같은 작업이라도 행이 나뉘어 있어야 변경이 가능합니다. 분리되어 있지 않으면 부분 협상 자체가 불가능합니다.

2. MD 합계와 단가의 곱이 총 견적과 일치하는가

WBS의 MD를 합한 값에 회사 단가를 곱한 결과가 견적 총액과 일치해야 합니다. 차이가 크다면 견적 안에 라이선스, 외부 API, 인프라 같은 숨은 항목이 있다는 뜻이므로 항목별로 분리해 달라고 요청하시면 됩니다.

3. 변경관리 절차가 명문화되어 있는가

WBS 자체가 아니라 견적서 또는 별도 문서에 명시되어 있어야 합니다. “변경 요청 → 영향도 회신 → 발주사 승인 → 신규 행 추가” 흐름이 5줄 정도면 충분합니다. 만약 누락되어 있다면 계약 전에 짧게라도 추가해 달라고 요청하시기를 권합니다.

마지막으로

WBS는 외주를 ‘사고 파는 단위’ 그 자체입니다. 단위가 보이지 않는 견적서는 협상도, 변경 추적도, 분쟁 대응도 어렵습니다. 거꾸로 단위가 잘 분해된 WBS가 있으면 변경의 영향이 즉시 계산되고, 발주사 분이 진행률을 직접 확인하실 수 있습니다. 저희가 모든 프로젝트의 첫 결과물을 디자인보다도, 코드보다도 먼저 WBS로 정하는 이유입니다.

외주를 처음 맡기시는 분이라면 IT 외주 맡기기 전에 꼭 확인해야 할 7가지 글도 함께 읽어보시면 도움이 됩니다. 다음에는 견적서 항목을 화면 단가·기능 단가·인프라 단가로 어떻게 분리해 봐야 하는지를 정리해드릴 예정입니다.