> [!abstract] Introduction > 프로젝트에 대한 계획을 처음 세울 때 아무런 틀도 없다면 전체적인 계획을 세우기 매우 어려울 것입니다. 이번 글에서는 프로젝트를 계획하는 틀이 되어주는 WBS(Work Breakdown Structure)를 알아봅니다. # Decomposition 수많은 인력이 필요한 프로젝트는 매우 거대하고 프로젝트가 구현하고자 하는 기능을 가진 소프트웨어를 실제로 구현하고 소비자에게 전하기까지 굉장히 많은 업무가 필요하다. 그렇다면 구체적으로 무슨 업무가 필요할까? 프로젝트가 어떻게 이루어지고 관리될 것인지를 정하는 방법이 바로 개발 접근법*Development Approach*이다. ## Development Approach 여러가지 개발 접근이 존재하지만, 전부 예측과 적응이라는 하나의 스펙트럼 위에 존재한다. ![[TheSpectrumOfDevelopmentApproaches.png]] 스펙트럼의 양쪽 끝에는 주어진 상황에 적응하는 적응형*adaptive* 접근법과 앞으로 일어날 상황을 미리 예측하는 예측형*predictive* 접근법이 있으며, 그 사이는 혼합형*hybrid* 접근법의 영역이다. 개발 방법을 사용하면 프로젝트에 필요한 업무 전체를 감싸는 경계를 그릴 수 있는데, 이것이 바로 프로젝트의 범위*project scope*다. ## Decomposition 그중 예측형 혹은 혼합형 접근법에서는 어찌 됐든 전체 업무를 파악하고 나서 본격적인 일을 시작하기 때문에 어떤 일이 필요한지 한눈에 볼 수 있어야 하는데, 이때 필요한 것이 바로 분해*Decomposition*다. 소프트웨어 공학에서 분해란, 프로젝트의 범위와 제품을 작고 관리 가능한 조각들인 작업 패키지*work package*로 쪼개는 과정이다. 어디까지 나눌지는 프로젝트에 필요한 통제 수준에 따라 달라지겠지만, 언제나 최소 단위는 작업 패키지다. 프로젝트에 필요한 모든 업무를 작업 패키지로 분해하는 과정은 다음과 같다: 개발해야 할 제품과 이에 연관된 작업을 파악한 다음 WBS(Work Breakdown Structure)를 만들고 상위 요소를 하위 요소로 더 세세하게 분해한다. 이 분해가 맞는지 검증하는 것도 잊으면 안된다. # Work Breakdown Structure ![[SampleWBSDecomposedDownThroughWorkPackages.png]] WBS는 이러한 분해의 결과물이자 프로젝트 범위에 대한 구조물이다. 일반적으로 WBS는 작업 패키지를 파악하고 조직하기 위한 양식을 제공하는 작업물이며 프로젝트 팀이 목표를 달성하고 요구된 제품을 개발하기 위해 해야 하는 모든 업무를 분해한 결과물 중 하나다. WBS는 프로젝트와 함께 만들어지며, 잘 만들어지면 초기 견적을 작성할 때 그 뼈대가 되어줄 수 있다. WBS가 만들어지면 전체 프로젝트가 관리 가능한 요소들의 연결망으로 재구성되어, 조직은 WBS를 통해 일정, 책임, 노동력을 분배하기 위한 기본 틀을 가지게 되며 이를 통해 앞으로 무엇을 만들어야 하는지에 대해 알 수 있다. ![[DevelopScopeStructure.png]] ## Expert Judgement 효과적인 WBS를 만들기 위해서는 프로젝트의 결과물을 잘 나눠야 하는데, 여기에 필요한 정보를 분석하기 위해 전문가 평가*Expert Judgement*가 사용되는 일이 잦다. 전문가들의 평가와 의견은 프로젝트 범위의 기술적 디테일에 적용되며, 프로젝트 범위를 어떻게 나눠야 잘 나누는 것인지에 대한 의견 간의 격차를 줄여준다. 이렇게 전문적인 기술은 관련된 훈련과 지식에서 나오거나, 유사한 프로젝트 혹은 분야에서 일한 경험에서 나온다. 전문가 평가는 자주 나오는 상품을 효과적으로 쪼개는 가이드를 제공하는 템플릿의 형태로도 제공된다. 이런 템플릿은 산업 혹은 특정 유형에 대한 템플릿이거나 비슷한 프로젝트에서 얻은 경험이 집약된 것일 수도 있다. 프로젝트 관리자는 팀과 협의해 프로젝트 범위의 최종 분해를 결정한다. ## WBS Structure WBS의 구조는 다양한 접근법을 통해 결정된다. WBS 템플릿이나 조직의 가이드라인을 활용해 위에서 아래로*top-down* 만들어지거나, 하위 요소를 합치면서 점점 큰 요소를 만들어가는 방법*bottom-up*도 있다. WBS의 구조에서 특기할 만한 부분은 이들이 다양한 형태로 만들어질 수 있다는 것이다. ![[SampleWBSOrganizedByPhase.png]] 예를 들어, 위에 있는 Figure 5-7처럼 두번째 레벨을 프로젝트 생명 주기의 페이즈로 구성하고 세번째 레벨을 제품과 프로젝트의 상품으로 구성하거나, ![[SampleWBSWithMajorDeliverables.png]] Figure 5-8처럼 두번째 레벨을 주요 상품들로 구성할 수 있다. 이때 결합되는 하위 요소들은 프로젝트 팀이 아닌 외부에서 만들어진 것일 수도 있다. --- # 출처 - PMI, Project Management Institute (ed.) (2025) _A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Eighth Edition and the Standard for Project Management_. 8th ed. Chicago: Project Management Institute (PMBOK® Guide Series).