[웹기획가이드] WBS를 한 번 만들어볼까요? ①

지금까지 수십 편의 웹기획가이드를 작성해오며 업무를 진행하는데 많은 도움을 받았다는 분들을 가끔 만나곤 합니다. 그런데 왜 댓글은 달리지 않을까요? 그런 고마움을 들을 때마다 좀 더 사명감을 가지고 열심히 작성해봐야겠다는 생각을 하지만, 글 자체가 가볍게 작성할 수 있는 주제가 아닌 만큼, 많은 생각과 고민을 하다보니 다른 주제의 글에 비해 업데이트가 늦어지곤 합니다. 더불어 기획적으로 해볼 수 있는 고민의 영역을 넓히는데 많은 도움은 되지만 좀 더 실무적으로 활용할 수 있는 글이 올라왔으면 좋겠다는 의견을 듣기도 합니다.

 

그래서 준비해봤습니다. 기획자가 업무를 진행 함에 있어 꼭 필요한 문서작업 작성방법에 대해 하나씩 정리해볼까 합니다. 오늘은 그 첫 번째로 WBS 문서를 만드는 방법을 알려드릴텐데요, 그 전에 먼저 WBS가 무엇인지부터 한 번 살펴봐야 겠습니다.

 

WBS의 예시, 으아아아아아아아아아아!!!

우리가 프로젝트를 진행 함에 있어 업무 별, 파트 별 작업 진행 스케줄을 정리하곤 하는데, 보통 이 스케줄을 WBS^[각주:1]라고 칭합니다. WBS는 Work Breakdown Structure의 약자로 굳이 한글로 표현하자면 업무 분업구조^[각주:2]로 해석할 수 있습니다. WBS는 보통 프로젝트의 진행사항을 체크하기 위해 작성하는데, 이를 위해서는 먼저 해당 프로젝트 진행을 위한 개발범위를 파악하고 주어진 일정을 체크해야 합니다. 그 다음으로 프로젝트 참여인원의 역량을 고려하여 일정과 개발범위의 조율이 필요한데, 통상적으로는 개발범위에 따라 일정이 늘어가기 보단 일정에 개발범위를 맞추는 게 일반적입니다. 물론 그 일정은 차츰 늘어나기 마련이고... 그 다음으로 크게 기획, 디자인, 퍼플리싱, 개발, 테스트에 따른 파트 별 업무를 구분짓고 각 파트 별로 세부적인 작업사항과 진행일정을 기재하게 됩니다.

 

 

WBS에 들어갈 항목들, 무엇이 있을까?

이 때, 해당 문서를 작성하는 PM이 모든 WBS 항목의 초안을 작성하고 각 파트가 초안 내 기재된 업무 별 일정을 검토하여 확정 짓는 경우도 있고, 반대로 파트 별로 각각 나누어 작성하고 이것을 PM이 취합하기도 합니다. 이는 PM의 업무 역량이라기 보다는 방법론의 차이라고 볼 수 있겠고요, 전자를 택하나 후자를 택하나 큰 차이점은 없습니다. 이 같은 기본 구조에 따라 WBS를 작성해보면 다음의 항목으로 정리됩니다.

 

①	분류 No.	테스크의 Depth에 따라 "1", "1.1", "1.1.1" 과 같은 분류 테스크 분류 No.를 작성.
②	구분	세부 테스크를 묶어주는 그룹을 작성.
③	테스크	업무의 구체적인 타이틀을 작성하는 영역으로 위의 분류 No와 연계.
④	작업자(또는 파트)	해당 테스크를 수행할 작업자 또는 작업파트를 작성.
⑤	상태	테스크 별 진행 여부를 기록하며 진행중(In progress),완료(Completed),체크(Milestone)로 구분.
⑥	시작일	테스크의 작업 시작일자를 작성.
⑦	종료일	테스크의 작업 종료일자를 작성.
⑧	기간	테스크의 시작일자와 종료일자를 기준으로 업무일자를 작성.
⑨	진척도	테스크의 일정대비 진척도를 퍼센트(%)로 기록.
⑩	일정차트	프로젝트 전체 일자 별 셀에 기간과 진척도를 반영하여 색으로 표기되는 영역.

 

프로젝트의 성격이나 내용에 따라 WBS의 구조는 약간씩 다르지만, 대체적으로 위의 항목으로 정리됩니다. 이렇게 항목을 정의한 다음에 각 테스크의 큰 그룹을 먼저 정리해서 구분 항목에 작성하시면 되는데, "오픈마켓 컨셉의 쇼핑몰 서비스"를 리뉴얼한다고 가정해봅시다. 여러가지의 테스크가 존재할텐데 먼저 분석이 필요할 겁니다. 지피지기면 백전백승이라는 고사성어처럼 서비스의 세부적인 작업 이전에 충분한 서비스, 고객 분석이 이루어져야만 모두가 만족할 수 있는 완성도 높은 서비스를 만들 수가 있겠죠. 분석의 범위에는 크게 다음의 항목이 반영되어야 합니다.

 

①	분석준비	내부고객 요구조건 취합	내부고객(클라이언트)의 희망요건 취합.
		외부고객 이용니즈 취합	외부고객이 바라는 서비스의 변화요소 취합.
②	분석진행	요구사항 취합 분석	내/외부 고객을 통해 취합된 요구조건을 분석하여 리뉴얼 컨셉을 정의.
		시스템 환경 분석	개발언어, 서버 환경 등의 분석.
		요구사항 기능 분석	요구사항 구현에 필요한 기능적요소 정의 및 분석.
		검토	정리된 사항의 내부고객 컨펌.

 

분석의 범주 내에서 정리되는 내용은 위와 같이 크게 분석준비 과정과 분석진행 과정으로 구분할 수 있습니다. 분석을 위한 준비과정을 통해 회사 내부고객의 의견을 취합해야 하고, 외부고객 즉 쇼핑몰을 이용하는 고객의 니즈를 파악해야 합니다. 이 두 가지 항목의 파악이 완료되면 분석 진행과정을 통해 수집한 요건을 통해 리뉴얼 컨셉을 정의하게 됩니다. 그 다음 리뉴얼 될 서비스의 서버 환경, 사용 랭귀지, 데이터베이스 관리로 어떤 SQL을 사용할 것인지 등을 정의하는 일정이 포함되야 합니다.

 

 

더불어 정리된 요구사항을 구현하기 위한 기능, 예를 들어 글로벌에 대응하는 Admin을 도입한다는 요구조건이 리뉴얼을 하겠다고 가정해보죠. 그럼 기능적 요소 정의에 '다국어 시스템 도입에 대한 항목이 들어가야 겠구나?'와 같은 기술적 요소가 어느 정도나 있는가를 파악하는 시간이라고 보시면 됩니다. 여기까지 정리가 됐으면 마지막으로 클라이언트의 최종검토를 받아 프로젝트를 본격적으로 시작하게 됩니다.

 

IA 설계와 정책 설계

앞서 고객의 니즈를 파악하는 과정을 정리해봤는데, 그 다음으로 사이트맵과 함께 전체적인 서비스 로직(logic)과 서비스정책을 정의해야 합니다. 로직은 IA와도 맞닿아 있는 영역으로 IA의 구성요소 중 하나인 Construction 즉 서비스의 구조적 정의 및 상관관계를 의미하는데, 보통은 MS Office 툴 중 하나인 Execl을 통해 정리하기도 합니다. 하지만 Execl을 사용할 경우, 정작 그 구조를 보고 개발해야 하는 개발자의 입장에서는 보기 힘든 서식입니다. 때문에 Execl로 정리하기 보단 알 마인드나 마인드 매니저같은 Mindmapping툴을 이용하여 시각화하는 과정이 필요한데, 이 부분에 대해서는 차후 다른 포스트를 통해 다뤄보기로 하고요.

 

①	Logic 설계 (IA)	Sevice Structure	하나의 서비스를 구성하는 페이지 단위의 흐름 표기.
		Business Logic	위의 페이지 구성을 바탕으로 데이터의 입력, 저장 등의 처리절차를 정의.
		Page Configuration	하나의 페이지를 구성하고 있는 DB, Contents의 흐름을 정의.
		Site Map	레이블링을 바탕으로한 Top Down 형태의 메뉴 구조.
②	서비스정책	단위 영역 별	기획/개발 시 필요한 정책적 요소를 텍스트 기반으로 정리.

 

서비스 로직을 정리한 후, 서비스 정책을 작성해야 합니다. 이 정책적 설계가 완료되어야만 이것을 토대로 스토리보드를 작성할 수 있으며 정책 설계가 미흡할 경우, 겉보기에는 그럴듯한 서비스가 나올지 모르지만 정작 안에서는 꼬인 실타레와 같은 문제가 발생할 수 있기 때문에 정책 설계에 많은 공을 들여야 합니다. 여기서의 로직은 크게 세 가지로 구분되는데, 하나의 페이지에 구성되는 요소를 정의하는 영역과 데이터를 처리하는 과정에서 발생하는 여러가지 루틴들, 즉 눈에 보이는 처리과정과 눈에 보이지 않는 처리과정을 정리하는 논리적 프로세스, 그리고 하나의 서비스를 구성하는 페이지 단위의 구조로 나뉩니다. 일단 WBS 항목 정리를 모두 마치고 서비스 로직에 대해 따로 정리하겠습니다.

 

하나의 페이지를 구성하는 세부적인 구성요소 예시.

이렇게 서비스 로직 정리가 마무리되면, 서비스 정책을 정의해주셔야 합니다. 서비스 정책은 한마디로 "서비스의 기반을 이루는 각 요소들은 어떻게 구성되어 있는가?"를 정의하는 영역입니다. 우리가 이미 아는 것처럼, 하나의 서비스는 아래의 그림과 같이 다양한 구성요소들로 이루어져 있으며 각 구성요소를 텍스트로 상세하게 정리하는 과정을 거치게 됩니다. 예를 들어 회원 정책을 정의한다고 할 때 해당 서비스에서 회원의 정의가 무엇인지와 회원의 구분, 가입방식, 가입 시 수집정보, 활동범위, 회원 탈퇴, 탈퇴 후 재가입 등의 내용을 정리하게 됩니다. 정책 개념과 정리 방법에 대해서는 차후 별도의 포스트를 통해 자세히 정리하겠습니다. 정리해야 할 포스트는 쌓여만 간다..

 

서비스를 구성하고 있는 다양한 요소를 정책으로 정의해줘야 한다.

정책 설계가 완료되면, UI적 요소가 가미된 화면설계 작업을 진행합니다. 화면설계는 앞서 정의한 IA를 기반으로 정리하게 되며, 서비스의 규모에 따라 수십에서 수백 페이지의 스토리보드를 작성하게 됩니다. 이 스토리보드는 서비스해야 할 플랫폼에 따라 Web와 Mobile 또는 App로 구분하며, 여기에 Admin 영역에 대한 스토리보드 작성스케줄까지 WBS에 포함시켜야 합니다. 그리고 이후 다른 포스트에서 언급하겠지만, 스토리보드에 앞서 개발기능 정의서라는 문서를 별도로 만들기도 합니다. 개발기능 정의서란 일종의 개발만을 위한 문서인데, UI나 UX에 대한 내용을 쏙 뺀 담백한(?) 내용으로 구성합니다.

 

①	스토리보드	PC Web Front	고객이 이용하는 PC Web 서비스 영역에 대한 화면설계.
		Mobile Web Front	고객이 이용하는 Mobile Web 서비스 영역에 대한 화면설계.
		App Front	고객이 이용하는 스마트폰 App(Android/iOS) 서비스 영역에 대한 화면설계.
		Admin	서비스의 관리를 목적의 서비스 영역에 대한 화면설계.
②	개발기능정의	단위 영역 별	원활한 기능개발을 위해 스토리보드에서 개발적 영역만 발췌한 문서.

 

여기까지 WBS의 작성이 완료되었다면, 이제 디자인/퍼블리싱/개발 진행사항에 대한 WBS를 작성할 차례인데요, 이 중 가장 먼저 작업되어야 할 내용은 누가 뭐래도 시안이 아닐까 합니다. 시안 작업 범위는 서비스의 메인페이지를 비롯한 주요 페이지 정도이며, 이에 따른 시안 작업 진행 스케줄과 더불어 본 디자인 및 퍼플리싱, 개발 스케줄을 정리하게 되는데 이때 각각의 내용들은 사전에 공유된 기획 범위를 바탕으로 각 파트 담당자들과 협의를 통해 정리하시면 됩니다.

 

①	시안	주요 영역 별	Web, Mobile 주요 영역에 대한 디자인 시안 작업 스케줄 정의.
②	Design	전체	서비스 전체의 영역 별 디자인 스케줄 정의.
③	Publishing		서비스 전체의 영역 별 퍼블리싱(PC Web/Mobile Web) 스케줄 정의.
④	Development		서비스 전체의 개발[각주:3] 스케줄 정의.

 

이제 거의 마무리 되었네요. 마지막 순서로 테스트 계획서 작성과 단위 테스트 일정을 정리해주셔야 하는데요, 테스트 계획서는 말 그대로 어떤 방식에 근거하여 테스트를 진행할 것인가를 서너페이지 분량으로 정리하는 문서입니다. 여기에는 테스트 방법론이 들어갈 수도 있고요, 아니면 테스트를 몇 개의 단계로 구분하여 각 단계에서 어떤 테스트를 진행할 것인가에 대한 내용 및 서비스 단위 별로 테스트를 진행하는 일정이 정리 됩니다.

 

테스트 계획서가 작성된 다음에는 각 단위 또는 단계 별 테스트 스케줄을 정리하게 되며, 테스트 리포트 및 리포트를 기반으로 한 디버깅 과정을 거치게 됩니다. 팁으로 디버깅 과정은 크리티컬한 이슈가 가정 하에 통상 3일에서 일주일 가량을 스케줄로 잡게 됩니다.

 

①	테스트준비	테스트 계획서	테스트에 대한 방법론, 테스트 단계 등 테스트 전반에 대한 계획을 수립.
②	단위테스트	단위테스트	테스트 계획서에 근거하여 세분화 된 각 단위 별 테스트를 진행.
		테스트리포트	테스트 진행내용을 취합하여 디버깅에 활용.
		디버깅	테스트 리포트에 따른 서비스의 디버깅 진행일정 정의.
③	고객검토	작업사항 검토	디버깅까지 완료된 내용에 대해 고객이 검토를 하는 일정 정의.
		고객 요청반영	고객 검토 과정에서 수정이 필요한 사항을 반영하는 일정.
③	서비스릴리즈		고객 검토 및 승인이 완료된 후, 언제 릴리즈 할 것인가에 대한 스케줄 정의.
④	서비스 안정화		서비스 릴리즈 이후, 미처 확인하지 못한 크고 작은 문제를 수정함.

 

자.. 디버깅까지 완료되었다면 이제 승인자의 최종검토를 기다릴 시간입니다. 단 이 과정에서 일부 고객의 요청을 반영할 여지도 있으므로 2일 가량의 스케줄을 빼놓은 것이 바람직합니다. 이렇게 고객 요청을 추가하고 서비스 릴리즈 일정과 함께 릴리즈 이후의 안정화 스케줄을 추가하면 WBS 정리가 마무리 됩니다. 참고로 안정화 과정은 대략 1달 가량을 잡게 됩니다. 비록 WBS 문서 페이지의 분량은 1 페이지(A3 사이즈로)에 불과하지만 서비스의 전체 스케줄을 모두 정리해줘야 하기에 많은 고민과 시간이 소요되는 작업이라는 점, 꼭 기억하시기 바라고요, 이 다음 편에서는 액셀의 함수기능을 통해 WBS 문서를 더욱 손쉽게 작성하는 방법을 설명드리도록 하겠습니다. 어떤가요? 이번엔 좀 실용적인 내용인가요?^^

 

야메군. Web와 Mobile, Digital 카테고리 SME(Subject Matter Expert). 웹기획 15년차로 네이버 웹기획자 커뮤니티 "웹(WWW)를 만드는 사람들"에서 운영진으로 활동하고 있으며, 딴지일보를 시작으로 아이러브스쿨, 짱공유닷컴, YES24 등의 회사를 거쳐, 현재는 민간 IT 원천기술 연구소 "Valhalla Lab"에서 Pattern recognition과 Machine learning, Natural Language Processing 기술의 상업적 이용방법에 대해 연구했으며, 2016년 7월 7일, 기획자의 업무능력 향상으로 위한 Guide Book "처음부터 다시배우는 웹기획(정재용, 최준호, 조영수 공저)" 출간.

1. WBS는 보편적으로 PM이 작성하지만, 기획자가 작성하는 경우도 비교적 빈번하게 접할 수 있습니다. [본문으로]
2. 네이버 지식백과 설명. [본문으로]
3. 개발은 크게 DB, Frontend, Backend 정도로 구분됩니다. [본문으로]