프로젝트 범위·원가·일정 관리

4장에서 개관했던 세 영역을 여기서 깊이 판다

4장에서 PMBOK의 10개 지식 영역을 한 장의 표로 훑으며 "범위·원가·일정 관리는 22장에서 따로 더 깊이 다룬다"고 예고했다. 이 시리즈의 마지막 장인 이번 22장에서 그 약속을 지킨다. 4장이 "이런 지식 영역들이 있다"는 지도를 그렸다면, 이번 장은 그중 세 영역 — 범위, 원가, 일정 — 을 실제로 손에 쥐고 쓸 수 있는 기법 수준까지 파고든다.

범위 관리 — 무엇을 만들고 무엇을 만들지 않을지

범위에는 두 가지 서로 다른 개념이 있다. **제품범위(product scope)**는 제품이나 서비스, 프로젝트 결과물이 가지는 특징과 기능을 뜻한다. **프로젝트범위(project scope)**는 그 특징과 기능을 가진 결과물을 만들기 위해 수행해야 할 작업들까지 포괄하는 개념이다. 책마루로 비유하면, 제품범위는 "우편번호 기반 배달 판정 기능이 있다"는 결과물의 특징이고, 프로젝트범위는 "그 기능을 만들기 위해 요구사항 분석, 설계, 구현, 테스트 작업을 수행한다"는 작업 전체다.

프로젝트 범위 관리(scope management)는 계획 단계에서 프로젝트에 포함시킬 사항과 제외시킬 사항을 정의하고 통제하는 활동이며, 다섯 단계로 진행된다.

1. 요구사항 수집: 계획된 시스템이 충족시켜야 할 요구사항들을 모은다.
2. 범위 정의: 도출된 요구사항을 중심으로 프로젝트 범위 설명, 인도물(deliverable), 사용자 인수 기준을 상세히 정의한다.
3. 작업 분류 체계(WBS) 작성: 범위를 세부 작업으로 분할한다.
4. 범위 검증(scope verification): 프로젝트 범위 관련 산출물을 고객이나 스폰서 같은 이해관계자가 검토하는 활동.
5. 범위 통제(scope control): 범위 기준선 문서의 변경이 발생할 때 이를 감시하고 통제하는 활동.

여기서 5번 범위 통제는 20장에서 다룬 형상 통제, 그리고 4장에서 다룬 변경통제위원회의 원리와 그대로 맞닿아 있다 — "배달 지역을 넓혀달라"는 요청이 들어왔을 때 이것이 원래 범위인지 추가 범위인지 판단하고 승인 절차를 거치는 것이 곧 범위 통제다.

작업 분류 체계(WBS)와 작업패키지

**WBS(Work Breakdown Structure)**는 프로젝트의 전체 업무를 점차 작은 업무로 쪼개어(decomposition) "구체적으로 무엇을 할 것인가"를 세부적으로 나타낸 결과물이다. 프로젝트의 범위와 최종 산출물을 세부 요소로 분할한 트리 형태의 계통도이며, 일정과 자원을 산정하는 기초 자료를 제공한다.

WBS를 계층적으로 쪼개다 보면 최하위 단위에 도달하는데, 이를 **작업패키지(work package)**라 부른다. 작업패키지는 한 사람 또는 한 팀이 독립적으로 수행할 수 있는 일의 단위이며, 다음 원칙을 따라야 한다.

• 범위, 일정, 원가 추정이 가능한 정도까지 분할한다.
• 진척 상황을 판단할 수 있는 현실적인 측정 기준이 있어야 한다.
• 산출물이 명확히 식별되어야 한다.
• 담당자를 명확히 지정할 수 있고, 소수 인력(1~2명)이나 한 팀이 수행할 수 있는 수준이어야 한다.

작업패키지들은 서로 중복되지 않고 상호 배타적이어야 하며, 최하위 수준의 모든 작업이 상위 작업과 남김없이 연동되어야 한다는 원칙을 100% 규칙이라 부른다.

책마루 온라인 주문 시스템의 WBS는 대략 이런 모습이 된다.

이렇게 나눠두면 "요구사항 분석"이라는 큰 덩어리를 통째로 관리하는 대신, "유스케이스 모델링 1주, 담당자 이수정" 같은 구체적인 단위로 진척과 비용을 추적할 수 있다.

원가 관리 — 공수를 어떻게 예측하는가

프로젝트를 진행하기 전, 혹은 개발 과정에서 시스템의 규모(비용, 인력, 시간)를 측정하는 일을 **공수 추정(manpower estimation)**이라 한다. 소프트웨어는 눈에 보이지 않아 규모 산정이 본질적으로 어렵고, 프로젝트 초기에는 시스템이 주고받는 데이터나 기능 정도만 파악할 수 있어 추정이 부정확해지기 쉽다. 그럼에도 합리적인 공수 추정은 납기 지연·인재 부족·비용 증가 같은 문제를 최소화하는 핵심 관리 기법이다.

공수 추정 방법은 크게 두 갈래로 나뉜다.

• 하향식(top-down) 추정: 유사 추정, 전문가 의견, 수학적 모델을 이용해 프로젝트의 총 비용을 먼저 추정한 뒤, 이를 각 하위 단계에 배분한다. 일반화하기 쉽지만 초기 정확도는 낮다.
• 상향식(bottom-up) 추정: 프로세스를 WBS의 작업패키지 같은 작은 단위로 분해하고, 각 작업에 드는 노력을 개별적으로 측정한 뒤 합산해 총 비용을 산정한다. 시간과 비용이 더 들지만 신뢰도가 높고, 과거 기록이 없는 새로운 프로젝트에 특히 적합하다.

COCOMO 모델 — 코드 줄 수로 비용을 추정한다

소프트웨어 규모를 측정하는 전통적인 단위는 코드의 줄 수를 나타내는 **LOC(lines of code)**다. 1981년 B. Boehm이 제안한 **COCOMO(Constructive Cost Model)**는 이 LOC를 추정하고 준비된 공식에 대입해 소요 기간과 인원을 구하는 대표적인 하향식 모델이며, 중소 규모 프로젝트의 비용 추정에 적합하다.

COCOMO는 개발 유형을 프로젝트의 규모와 복잡도에 따라 세 가지로 나눈다.

책마루 온라인 주문 시스템은 규모가 크지 않고 요구사항도 비교적 안정적이니 단순형(Organic)에 해당할 가능성이 높다. 기본 단계에서 이렇게 대략적인 노력(effort)을 계산한 뒤, 두 번째 단계에서는 신뢰도 요구 수준, 개발 요원의 숙련도, 도구 환경 같은 여러 **비용 인자(cost driver)**를 곱해 예상 노력을 보정한다. 요구되는 신뢰도가 높을수록, 데이터베이스 규모가 클수록 계수가 커지는 반면, 분석가나 프로그래머의 능력이 뛰어날수록 계수는 작아지는 식이다.

LOC 기반 추정의 한계: 개발 공수의 절반 이상이 투입되는 분석·설계·문서화·품질 관리 같은 공정은 코드 줄 수로 측정할 수 없고, 프로그램이 작성되기 전에 정확한 줄 수를 예측하는 것 자체가 근본적으로 어렵다. 또한 개발자의 역량에 따라 같은 기능도 코드 줄 수가 크게 달라질 수 있어 객관적인 규모 측정이 쉽지 않다.

기능점수(Function Point) — 사용자가 요구한 것을 센다

LOC 방식의 한계를 보완하기 위해 1970년대 IBM의 Allan J. Albrecht가 고안한 것이 기능점수(function point) 모델이다. 측정의 초점을 "소프트웨어가 어떻게 구현되었는지"에서 "사용자가 어떤 기능을 요구했는지"로 옮김으로써, 프로그래밍 언어와 무관하게 규모를 측정할 수 있도록 설계되었다.

기능점수는 소프트웨어가 사용자에게 제공하는 기능을 다섯 가지 핵심 항목으로 나누고, 각 항목의 복잡도에 따라 가중치를 부여해 합산하는 방식으로 산정한다.

각 항목의 개수를 세고 복잡도(단순/보통/복잡)에 따른 가중치를 곱해 더하면 미조정 기능점수가 나오고, 여기에 분산 처리·성능 요구·다중 사이트 지원 같은 특성을 반영한 조정 인자를 곱하면 최종 기능점수가 산출된다. 책마루 시스템이라면 "배달 지역 입력"은 외부입력, "재고 부족 알림"은 외부출력, "주문 내역 조회"는 외부조회로 분류해 각각의 기능점수를 매길 수 있다. 기능점수는 코드가 한 줄도 작성되지 않은 요구사항 분석 단계에서부터 산정할 수 있다는 점이 LOC 방식과 가장 큰 차이다.

일정 관리 — 언제 무엇을 끝낼 것인가

**프로젝트 일정 관리(schedule development)**는 프로젝트를 마감기일 안에 완료하도록 관리하는 데 필요한 요소들을 다룬다. 활동과 활동 순서를 정의하고, 각 활동에 필요한 자원을 예측하여 소요 기간을 산정하는 과정을 거쳐 전체 일정을 개발한다. 이 과정은 활동 정의 → 활동 순서 배열 → 활동 자원 추정 → 활동 기간 추정 → 일정 개발 → 일정 통제의 여섯 단계로 이루어진다.

PERT/CPM — 주경로를 찾아라

PERT/CPM은 일정 개발의 기본 골격을 제시하는 대표적인 도구다. 작업 일정을 세분화하여 공기 지연을 사전에 예방하고 공기를 단축하기 위한 추정 기법이며, 핵심은 프로젝트의 **주경로(CP: critical path)**를 계산해 전체 수행 기간을 예측하는 데 있다.

먼저 활동의 기간을 추정할 때, 하나의 확정값 대신 세 가지 시나리오의 가중 평균을 쓰는 것이 PERT 기법이다.

예상 기간(tE) = (낙관치 + 4 × 최빈치 + 비관치) / 6

• 낙관치(tO): 최상의 시나리오를 가정한 기간
• 최빈치(tM): 실질적으로 기대되는 기간
• 비관치(tP): 최악의 시나리오를 가정한 기간

이렇게 각 활동의 기간을 추정한 뒤, 활동 간 선후 관계를 노드로 표현하는 **선행 다이어그램 방법(PDM: Precedence Diagramming Method)**으로 네트워크 다이어그램을 그린다. PDM에서 활동 간 의존 관계는 네 가지 유형(종료 후 시작, 종료 후 종료, 시작 후 시작, 시작 후 종료)으로 표현되며, 이 중 선행 활동이 끝나야 후행 활동이 시작되는 '종료 후 시작(FS)'이 가장 일반적인 기본 유형이다.

네트워크 다이어그램이 완성되면 각 활동마다 네 가지 시각을 계산한다.

이 네 값의 차이(LS-ES 또는 LF-EF)를 **여유 시간(float)**이라 하며, 여유 시간이 0인 활동을 **주활동(CA: critical activity)**이라 부른다. 네트워크상의 여러 경로 중 수행 기간이 가장 긴 경로, 즉 주활동들로 이어진 경로가 바로 주경로다. 프로젝트 전체 수행 기간은 결국 주경로를 구성하는 활동들의 기간 합으로 결정되기 때문에, 주경로상의 활동이 하루라도 지연되면 프로젝트 전체 종료일도 그만큼 늦어진다.

주경로가 알려주는 것: 주경로에 있지 않은 활동은 어느 정도 여유(float)가 있어 며칠 늦어져도 전체 일정에 영향이 없다. 반대로 주경로상의 활동은 여유가 전혀 없다. 책마루 프로젝트에서 "프로그램 구현" 작업이 주경로에 있다면, 이 작업이 하루 늦어지는 순간 오픈일 전체가 하루 밀린다는 뜻이다. 관리자가 특별히 신경 써야 할 활동이 무엇인지, 일정을 단축하려면 어디에 자원을 더 투입해야 하는지를 주경로가 정확히 짚어준다.

간트 차트 — 한눈에 보는 일정표

**간트 차트(Gantt chart)**는 프로젝트 일정 관리를 위한 막대 도표(bar chart) 형태의 도구다. 가로축에 기간을, 세로축에 활동을 나열하고, 각 활동마다 계획된 일정을 막대 길이로 표시해 전체 일정을 한눈에 보여준다. PERT/CPM이 활동 간의 논리적 선후 관계와 주경로를 찾는 데 강하다면, 간트 차트는 그 결과를 누구나 이해하기 쉬운 형태로 보고하는 데 강하다. 두 도구는 경쟁 관계가 아니라 상호 보완적이다 — 먼저 PERT/CPM으로 주경로를 계산한 뒤, 그 결과를 간트 차트로 시각화해 사장님에게 매주 진행 상황을 보고하는 식으로 함께 쓰인다. 작성 방법이 단순하고 계획을 세우기 쉬워, 실무에서 가장 널리 쓰이는 일정 관리 기법 중 하나다.

맺음말 — 22강을 마치며

1장에서 "온라인 주문 되게 해주세요"라는 책마루 사장님의 막연한 한마디로 시작한 이 시리즈는, 소프트웨어 개발이 왜 공학이어야 하는지를 묻는 데서 출발해 프로젝트 관리, 요구사항 분석, 설계, 구현과 테스트, 그리고 이번 파트의 품질·형상·검증·범위/원가/일정 관리까지 22개 장을 거쳐왔다. 돌아보면 각 장에서 다룬 기법들은 결국 하나의 질문으로 수렴한다 — 막연한 바람과 실제로 만들어지는 결과물 사이의 간극을 어떻게 좁힐 것인가. 요구사항 명세서는 그 간극을 문서로, 설계와 아키텍처는 구조로, 품질 관리와 형상 관리는 절차로, 범위·원가·일정 관리는 숫자로 좁히는 도구였을 뿐이다.

책마루라는 가상의 동네 책방은 22강 내내 같은 모습으로 남아 있지 않았다. 프로젝트 헌장 한 장짜리 소상공인의 요청에서 출발해, WBS로 쪼개지고, ERD로 그려지고, 디자인 패턴이 적용되고, 형상 관리로 통제되고, 마침내 주경로가 계산된 일정표 위에 놓이기까지 — 이 변화 하나하나가 소프트웨어 공학이 실제로 하는 일이다. 도구와 모델의 이름은 프로젝트마다 다르게 쓰일 수 있지만, 이 시리즈에서 반복해서 확인한 원칙 — 무엇을 만들지와 어떻게 만들지를 분리하고, 변경을 통제된 절차 안에 두고, 결과를 문서와 숫자로 추적 가능하게 만드는 것 — 은 프로젝트의 규모와 무관하게 유효하다. 이제 남은 것은 이 원칙들을 실제 프로젝트에 적용해보는 일이다.