왜 위험·추정·일정을 한데 묶어 다루는가

19편에서 프로젝트 계획의 범위·일정·원가·EVM 진척 관리를 다뤘습니다. 그런데 애초에 일정과 원가를 계획하려면 “얼마나 걸릴지, 얼마나 들지”를 먼저 추정해야 하고, 그 추정과 계획은 무엇이 잘못될 수 있는지(위험) 를 함께 고려해야 현실성을 갖습니다. 이번 편은 계획을 세우기 이전 단계에 필요한 세 가지 — 위험 관리, 노력·원가 추정, 일정 기법 — 를 다룹니다.

쉽게 말하면: 이번 편은 “무엇이 잘못될 수 있는지 미리 대비하고, 얼마나 걸릴지 숫자로 추정하고, 그 추정을 실제 일정표로 만드는” 방법을 다룹니다.

1. 위험 관리 — 식별, 분석, 대응

위험(Risk) 은 아직 일어나지 않았지만 일어나면 프로젝트 목표(범위·일정·원가·품질)에 부정적 영향을 줄 수 있는 불확실한 사건입니다. 위험 관리는 이런 사건을 미리 찾아내 대비하는 활동으로, 세 단계로 진행됩니다.

위험 노출도로 우선순위 매기기

위험이 여러 개일 때 “어느 것부터 대응해야 하는가”를 정하는 대표적인 지표가 위험 노출도(Risk Exposure) 입니다.

• $RE$(Risk Exposure, 위험 노출도)
• $P$(Probability, 발생 확률, 0~1 사이 값)
• $C$(Consequence/Cost, 발생 시 손실 비용)

예시: 위험 A는 발생 확률 40퍼센트(0.4), 발생 시 손실 5,000만 원으로 예상됩니다. 위험 B는 발생 확률 10퍼센트(0.1)로 낮지만 발생하면 손실이 3억 원(30,000만 원)에 이릅니다.

발생 확률만 보면 위험 A가 더 위협적으로 보이지만, 노출도로 계산하면 위험 B의 노출도(3,000만 원)가 위험 A(2,000만 원)보다 커서 더 우선적으로 대응해야 함을 알 수 있습니다.

위험 대응 전략

2. 노력 추정 — LOC와 COCOMO

일정과 원가를 계획하려면 먼저 개발에 필요한 노력(Effort) 을 추정해야 합니다. 대표적인 방법이 COCOMO(COnstructive COst MOdel)입니다. COCOMO는 예상 코드 크기(KLOC, Kilo Lines Of Code)를 바탕으로 필요한 개발 노력(인월, Person-Month)을 추정하는 경험적 모델입니다.

기본형(Basic COCOMO)의 공식은 다음과 같습니다.

• $E$(Effort, 노력): 필요한 개발 노력, 단위는 인월(PM, Person-Month, 한 사람이 한 달 동안 일하는 노력의 단위)
• $KLOC$: 예상 코드 크기(1,000줄 단위)
• $a$, $b$: 프로젝트 유형(조직형·반분리형·내장형)에 따라 정해지는 경험적 상수

예시: 조직형(organic) 프로젝트의 계수를 $a=2.4$, $b=1.05$라 하고, 예상 코드 크기가 20 KLOC라면,

$20^{1.05}$는 $20^1 = 20$에 지수가 조금 커진 값이므로 약 23.4 정도가 되고,

즉 이 프로젝트에는 약 56.2인월의 노력이 필요하다는 뜻입니다. 이는 “한 사람이 56.2개월 동안 일해야 한다”는 뜻이 아니라, 여러 사람이 나눠서 일할 수 있는 총 작업량을 인월 단위로 표현한 것입니다. 예를 들어 5명이 투입되면 대략 $56.2 \div 5 \approx 11.2$개월 정도로 일정을 잡아볼 수 있습니다(실제로는 인력을 늘린다고 기간이 비례해서 줄지 않는다는 점을 이어서 다룹니다).

기능점수(Function Point)와의 비교

LOC(코드 줄 수) 기반 추정은 코드가 작성되기 전에는 정확히 예측하기 어렵고, 프로그래밍 언어에 따라 같은 기능도 줄 수가 크게 달라진다는 한계가 있습니다. 기능점수(FP, Function Point) 는 이런 한계를 보완하기 위해, 코드 줄 수 대신 사용자에게 제공되는 기능의 개수와 복잡도(입력, 출력, 조회, 내부 논리 파일, 외부 인터페이스 파일)를 기준으로 규모를 측정합니다. 기능점수는 특정 언어에 의존하지 않아 서로 다른 언어로 만든 프로젝트끼리도 규모를 비교할 수 있다는 장점이 있습니다.

3. 일정 기법 — 간트 차트와 PERT/CPM

노력을 추정했다면, 이를 실제 작업 순서와 기간으로 배치해야 합니다. 대표적인 두 기법이 간트 차트와 PERT/CPM입니다.

간트 차트(Gantt Chart)

간트 차트는 각 작업의 시작일·종료일을 가로 막대로 표현해 일정을 한눈에 시각화하는 도구입니다.

간트 차트는 직관적이지만, 작업 간 의존 관계(어느 작업이 끝나야 다음 작업을 시작할 수 있는지)나 어느 작업이 지연되면 전체 일정이 늦어지는지는 한눈에 파악하기 어렵습니다. 이를 보완하는 기법이 PERT/CPM입니다.

PERT/CPM — 임계경로 구하기

PERT(Program Evaluation and Review Technique)와 CPM(Critical Path Method)은 작업들을 네트워크(노드-에지 그래프)로 표현해, 작업 간 의존 관계와 임계경로(Critical Path) — 전체 프로젝트 기간을 결정짓는, 여유시간이 없는 작업들의 연쇄 — 를 구하는 기법입니다.

PERT는 각 작업의 소요시간을 하나의 확정값이 아니라 낙관치·최빈치·비관치 세 값으로 추정해 기대시간을 계산합니다.

• $T_e$(Expected Time, 기대시간)
• $O$(Optimistic, 낙관치): 모든 것이 순조로울 때 걸리는 최단 시간
• $M$(Most likely, 최빈치): 가장 그럴듯한 소요시간
• $P$(Pessimistic, 비관치): 문제가 생겼을 때 걸리는 최장 시간

예시: 어떤 작업의 낙관치가 4일, 최빈치가 6일, 비관치가 14일이라면,

이 작업의 기대 소요시간은 7일입니다. 최빈치(6일)보다 기대시간이 다소 긴 이유는 비관치(14일)가 최빈치보다 훨씬 크게 벌어져 있어(분포가 오른쪽으로 치우쳐) 평균을 끌어올렸기 때문입니다.

임계경로 구하기

각 작업의 기대시간을 구한 뒤, 작업들을 선후 관계에 따라 네트워크로 연결하면 여러 경로 중 가장 긴 경로(합산 소요시간이 가장 큰 경로)가 나옵니다. 이 경로가 임계경로이며, 임계경로 위의 작업이 하루라도 지연되면 전체 프로젝트도 그만큼 지연됩니다. 반대로 임계경로에 속하지 않는 작업은 어느 정도 여유시간(Slack, Float)이 있어, 그 범위 안에서는 지연돼도 전체 일정에 영향을 주지 않습니다.

위 예시에서 경로는 두 갈래입니다. 경로 1( S → A → C → E )은 $3+4=7$일, 경로 2( S → B → D → E )는 $5+2=7$일로 두 경로의 합산이 같다면 둘 다 임계경로가 될 수 있습니다. 만약 경로 2의 작업B가 6일로 늘어난다면 경로 2는 $6+2=8$일이 되어, 이때는 경로 2가 임계경로가 되고 전체 프로젝트 기간도 8일로 늘어납니다.

핵심 정리

• 위험 관리는 식별 → 분석 → 대응의 절차를 따르며, 우선순위는 위험 노출도 $RE = P \times C$(확률 × 손실)로 판단한다. 대응 전략은 회피·완화·전가·수용으로 나뉜다.
• COCOMO는 $E = a \times (KLOC)^b$로 코드 크기 기반 개발 노력(인월)을 추정한다. 인력을 늘린다고 기간이 비례해 줄지 않으며, 이미 늦은 프로젝트에 인력을 추가하면 더 늦어질 수 있다(브룩스의 법칙).
• 기능점수(FP) 는 언어에 의존하지 않고 요구·설계 단계부터 규모를 측정할 수 있어 LOC 기반 추정의 한계를 보완한다.
• 간트 차트는 일정을 시각화하지만 의존 관계 파악에 한계가 있고, PERT/CPM은 기대시간 $T_e = (O+4M+P)/6$과 임계경로(가장 긴 경로)로 전체 일정을 결정짓는 작업을 찾아낸다.

마무리 복습

참고 자료

• SWEBOK topics 상세 - IEEE Computer Society 
• SWEBOK PDF 요약본