레슨 06: 추정과 계획 (Estimation and Planning)
레슨 06: 추정과 계획 (Estimation and Planning)¶
이전: 05. 소프트웨어 모델링과 UML | 다음: 07. 소프트웨어 품질 보증
소프트웨어 팀에게 다음 프로젝트가 얼마나 걸릴지 물어보면, 대부분 낙관적인 답변을 내놓고 결국 틀리게 된다. Standish Group의 CHAOS 보고서 연구 결과에 따르면, 대다수의 소프트웨어 프로젝트가 일정과 예산을 초과한다. 이는 단순한 무능함이 아니다 — 소프트웨어는 지적 산물이고, 팀마다 특성이 다르며, 요구사항은 변하기 때문에 추정 자체가 본질적으로 어렵다. 이 레슨에서는 더 나은 추정과 현실적인 계획을 만들어내는 기법, 모델, 사고 습관을 익힌다.
난이도: ⭐⭐⭐
선수 학습: - 레슨 02 — 소프트웨어 개발 생명 주기 - 레슨 03 — 애자일과 반복적 개발 - 레슨 04 — 요구사항 공학
학습 목표: - 소프트웨어 추정이 본질적으로 불확실한 이유를 설명하고 불확실성의 원뿔(Cone of Uncertainty)을 기술할 수 있다 - 코드 라인 수(LOC) 추정을 적용하고 그 한계를 명확히 설명할 수 있다 - 기능 점수 분석(Function Point Analysis, FPA)을 기술하고 기본 미조정 기능 점수를 산정할 수 있다 - COCOMO와 COCOMO II를 설명하고 COCOMO 모델을 사용해 기본 공수 추정치를 계산할 수 있다 - 스토리 포인트와 상대적 추정을 애자일 스프린트 계획에 적용할 수 있다 - 플래닝 포커(Planning Poker) 세션을 진행할 수 있다 - PERT 공식을 사용한 삼점 추정(Three-Point Estimation)을 적용할 수 있다 - 작업 분류 체계(Work Breakdown Structure, WBS)를 구성할 수 있다 - 간트 차트를 작성하고 주경로 분석법(Critical Path Method, CPM)으로 주경로를 파악할 수 있다 - 릴리스 계획과 스프린트 계획을 구별할 수 있다 - 일반적인 추정 편향을 인식하고 이를 상쇄하는 기법을 적용할 수 있다
목차¶
- 추정이 어려운 이유
- 코드 라인 수와 그 한계
- 기능 점수 분석
- COCOMO와 COCOMO II
- 스토리 포인트와 상대적 추정
- 플래닝 포커
- 티셔츠 사이즈 추정
- 삼점 추정과 PERT
- 작업 분류 체계
- 간트 차트와 주경로
- 릴리스 계획 vs. 스프린트 계획
- 추정 정확도: 추적과 개선
- 일반적인 추정 함정
- 요약
- 연습 문제
- 더 읽을거리
1. 추정이 어려운 이유¶
1.1 불확실성의 원뿔 (Cone of Uncertainty)¶
불확실성의 원뿔(Cone of Uncertainty)은 Barry Boehm이 공식화하고 Steve McConnell이 대중화한 개념으로, 프로젝트가 진행될수록 추정 정확도가 어떻게 향상되는지를 설명한다.
추정 │
기간 │ ╲ 4배 초과
(실제 4│ ╲
대비) │ ╲
3│ ╲
│ ╲______________
2│ ╲ ─ ─ ─ 2배 초과
│ ╲
1 │────────────────╲────────────── 실제
│ ╲
0.5│ ╲_____________ 0.5배 (빠른 완료)
│
└──────┬────────────┬────────────┬────────
타당성 아키텍처 기능 완료
검토 완료 완료
(±4배) (±2배) (±1.25배)
프로젝트 초기에는 추정치가 실제와 4배 이내의 범위에서 벗어날 수 있다. 아키텍처가 완성될 즈음에는 불확실성이 ±2배로 좁혀진다. 기능 구현이 완료에 가까워져야 비로소 오차가 ±25%로 줄어든다.
시사점: - 요구사항이 파악되기 전에 정확한 추정치를 요구하지 말 것 — 어차피 틀린다 - 원뿔이 충분히 좁아진 시점에 맞춰 추정치를 확정할 것 - 각 단계 게이트에서 새로운 정보를 바탕으로 재추정할 것
1.2 불확실성의 근본 원인¶
| 원인 | 설명 |
|---|---|
| 요구사항의 불완전성 | 범위가 불명확하면 작업량도 알 수 없음 |
| 기술의 새로움 | 새로운 프레임워크, 플랫폼, 언어는 특성이 불분명함 |
| 팀의 낮은 친숙도 | 도메인이나 도구에 낯선 팀은 과거 데이터보다 느림 |
| 통합 복잡도 | 외부 시스템 인터페이스에는 숨은 작업이 존재함 |
| 설계 결정의 창발성 | 프로젝트 중간에 이루어진 아키텍처 선택이 범위를 바꿈 |
| 인적 요소 | 병가, 이직, 온보딩, 회의, 컨텍스트 전환 등 |
1.3 추정(Estimation) vs. 계획(Planning)¶
중요한 구분:
- 추정(Estimation)은 현재 알고 있는 지식을 바탕으로 얼마나 걸릴지 예측하는 것
- 계획(Planning)은 비즈니스 제약을 고려해 언제까지 무엇을 제공할지에 대한 약속
추정은 계획의 토대가 되지만, 범위·자원·일정이 조정될 때 계획은 추정과 달라질 수 있다. 위험을 명시적으로 인정하지 않은 채 계획이 솔직한 추정을 덮어쓰도록 내버려 두어서는 안 된다.
2. 코드 라인 수와 그 한계¶
코드 라인 수(Lines of Code, LOC) — 또는 KLOC(수천 줄)와 MLOC(수백만 줄) — 는 소프트웨어의 규모를 측정하는 가장 초기의, 그리고 가장 직관적인 지표였다.
2.1 LOC의 활용 방식¶
역사적으로 조직들은 생산성을 LOC/인월(person-month)로, 결함 밀도를 결함/KLOC로 추적했다. 유사 코드베이스의 이력 데이터가 있다면, LOC를 기반으로 비용과 일정을 산출할 수 있다:
Effort = (LOC / Productivity Rate) × adjustment factors
예시: 팀의 과거 생산성이 1,000 LOC/인월이고 예상 규모가 50,000 LOC라면:
Effort = 50,000 / 1,000 = 50 person-months
2.2 LOC의 한계¶
| 문제 | 설명 |
|---|---|
| 언어 의존성 | Python 100줄이 Java 400줄과 동일한 기능을 할 수 있음; LOC는 코드 분량과 작업량을 혼동함 |
| 음수 생산성 | 200줄을 제거하는 리팩터링은 품질을 향상시키지만 "음수 생산성"으로 계산됨 |
| 설계 선행 필요 | 라인 수를 세려면 무엇을 만들지 알아야 함; 초기 추정에는 순환 논리 |
| 코드 비대화 유인 | LOC를 보상 기준으로 삼으면 장황하고 유지보수하기 어려운 코드를 장려함 |
| 현대 개발에 부적합 | 설정 파일, 코드형 인프라(IaC), 자동 생성 코드는 측정치를 왜곡함 |
LOC는 알고리즘 중심의 고성능 코드(예: 과학 계산, 컴파일러 내부)처럼 코드 줄 수가 복잡도와 합리적으로 대응되는 영역에서 과거 규모 지표로는 여전히 유용하다. 일반 비즈니스 소프트웨어에는 기능 점수나 스토리 포인트가 더 적합하다.
3. 기능 점수 분석¶
기능 점수 분석(Function Point Analysis, FPA)은 1979년 IBM의 Allan Albrecht이 개발했다. 시스템이 어떻게 동작하는가가 아니라 무엇을 하는가라는 사용자 관점에서 기능적 규모를 측정한다. 따라서 기능 점수는 기술에 독립적이다.
3.1 다섯 가지 기능 유형¶
기능 점수는 다섯 가지 기능 컴포넌트를 계산한다:
| 기능 유형 | 약자 | 설명 | 예시 |
|---|---|---|---|
| 외부 입력 (External Input) | EI | 외부로부터 시스템에 입력되는 데이터 | 주문 양식 제출 |
| 외부 출력 (External Output) | EO | 시스템에서 외부로 나가는 데이터 | 청구서 생성 |
| 외부 조회 (External Inquiry) | EQ | 영속 데이터 변경 없는 입출력 쌍 | 상품 검색 |
| 내부 논리 파일 (Internal Logical File) | ILF | 시스템이 유지하는 논리적으로 연관된 데이터 그룹 | 주문 테이블 |
| 외부 인터페이스 파일 (External Interface File) | EIF | 다른 시스템이 유지하지만 참조하는 데이터 그룹 | 제품 카탈로그 (ERP에서 제공) |
3.2 복잡도 분류¶
각 컴포넌트는 낮음, 평균, 높음의 복잡도로 평가되어 가중치를 부여받는다:
| 기능 유형 | 낮음 | 평균 | 높음 |
|---|---|---|---|
| EI | 3 | 4 | 6 |
| EO | 4 | 5 | 7 |
| EQ | 3 | 4 | 6 |
| ILF | 7 | 10 | 15 |
| EIF | 5 | 7 | 10 |
3.3 미조정 기능 점수(UFP) 계산¶
UFP = Σ (count × weight) for all function types
예시:
| 유형 | 수량 | 복잡도 | 가중치 | 소계 |
|---|---|---|---|---|
| EI | 8 | 평균 | 4 | 32 |
| EO | 5 | 평균 | 5 | 25 |
| EQ | 6 | 낮음 | 3 | 18 |
| ILF | 4 | 평균 | 10 | 40 |
| EIF | 2 | 낮음 | 5 | 10 |
| UFP | 125 |
3.4 가치 조정 계수 (Value Adjustment Factor)¶
가치 조정 계수(Value Adjustment Factor, VAF)는 0~5점으로 평가되는 14개의 일반 시스템 특성(General System Characteristics, GSC)을 기반으로 UFP를 보정한다:
VAF = 0.65 + 0.01 × Σ(GSC scores) [GSC 점수 합계 범위 0–70]
VAF ranges from 0.65 to 1.35
Adjusted FP = UFP × VAF
ISO/IEC 20926 (IFPUG)와 ISO/IEC 19761 (COSMIC)은 표준화 기구의 기능 점수 계산 변형 방식이다.
3.5 기능 점수를 공수로 변환¶
기능 점수를 산정한 후, 과거 데이터나 산업 벤치마크(예: ISBSG 데이터베이스)에서 도출한 생산성 지수(FP/인월)를 적용한다:
Effort (person-months) = Adjusted FP / Productivity Rate
산업 벤치마크: 비즈니스 애플리케이션 개발의 경우 5~15 FP/인월 (언어, 도메인, 팀에 따라 크게 다름).
4. COCOMO와 COCOMO II¶
구성적 비용 모델(Constructive Cost Model, COCOMO)은 Barry Boehm이 1981년 개발한 알고리즘 모델로, 소프트웨어 프로젝트의 예상 규모(KLOC 기준)에서 공수와 일정을 추정한다.
4.1 COCOMO 기본 모델¶
세 가지 프로젝트 모드 (원래 1981년 모델):
| 모드 | 설명 | 예시 |
|---|---|---|
| 유기적(Organic) | 소규모 팀, 잘 이해된 문제, 친숙한 환경 | 비즈니스 데이터 처리 |
| 반분리형(Semi-detached) | 중규모 팀, 혼합 경험, 일부 새로운 요구사항 | 트랜잭션 처리 시스템 |
| 내장형(Embedded) | 엄격한 하드웨어 제약, 복잡한 요구사항, 높은 신뢰성 요구 | 비행 제어 소프트웨어 |
공수 방정식:
E = a × (KLOC)^b [person-months]
일정 방정식:
D = c × E^d [months]
상수:
| 모드 | a | b | c | d |
|---|---|---|---|---|
| Organic | 2.4 | 1.05 | 2.5 | 0.38 |
| Semi-detached | 3.0 | 1.12 | 2.5 | 0.35 |
| Embedded | 3.6 | 1.20 | 2.5 | 0.32 |
예시 (Organic, 32 KLOC):
E = 2.4 × (32)^1.05 = 2.4 × 36.5 ≈ 87.6 person-months
D = 2.5 × (87.6)^0.38 ≈ 2.5 × 14.0 ≈ 14.0 months
Average team size = E / D = 87.6 / 14.0 ≈ 6.3 people
4.2 COCOMO 중간 모델 (COCOMO Intermediate)¶
중간 COCOMO는 기본 공수 추정치에 비용 동인(Cost Drivers) — 15개 요소(제품, 컴퓨터, 인력, 프로젝트 속성으로 분류) — 를 곱하며, 각 요소는 매우 낮음~매우 높음으로 평가되어 공수 배수(Effort Multiplier, EM)를 적용한다:
E = a × (KLOC)^b × Π(EM_i)
비용 동인 예시:
| 동인 | 매우 낮음 | 낮음 | 보통 | 높음 | 매우 높음 | 초고 |
|---|---|---|---|---|---|---|
| 요구 신뢰성 (RELY) | 0.75 | 0.88 | 1.00 | 1.15 | 1.40 | — |
| 분석가 역량 (ACAP) | 1.46 | 1.19 | 1.00 | 0.86 | 0.71 | — |
| 소프트웨어 도구 사용 (TOOL) | 1.24 | 1.10 | 1.00 | 0.91 | 0.82 | — |
높은 신뢰성 요구 + 낮은 분석가 역량 + 열악한 도구 환경이 겹치면 기본 추정치의 2~3배까지 늘어날 수 있다.
4.3 COCOMO II¶
COCOMO II (1995~2000)는 현대적 개발 패러다임(객체지향 설계, 프로토타이핑, COTS 재사용, 반복적 개발)에 맞게 모델을 갱신했다. 주요 개선 사항:
- 규모 지표: LOC뿐만 아니라 기능 점수(언어별 동등 SLOC로 변환) 또는 스토리 포인트도 사용
- 규모 요소(Scale Factors): 선례성, 개발 유연성, 아키텍처/위험 해소, 팀 결집력, 프로세스 성숙도의 다섯 가지 요소가 모드 분류를 대체
- 세 가지 하위 모델:
- 응용 구성(Application Composition) (초기 단계, 신속 프로토타이핑)
- 초기 설계(Early Design) (아키텍처 완료 후)
- 후기 아키텍처(Post-Architecture) (상세 설계 완료)
COCOMO II 공수 방정식:
E = A × Size^SF × Π(EM_i)
where:
A = 2.94 (calibrated constant)
SF = B + 0.01 × Σ(scale factor scores) [B = 0.91]
Scale factor scores range 0–5; Σ ranges 0–25; SF ranges 0.91–1.23
COCOMO II는 오픈소스 USC COCOMO II 도구와 Construx Estimate, SEER-SEM 상용 도구로 구현되어 있다.
4.4 알고리즘 모델의 활용 시점¶
알고리즘 모델을 사용하려면: 1. 유사 프로젝트에서 도출한 과거 교정 데이터 2. 사용 전 규모 추정치 3. 비용 동인 등급의 신중한 선택
이 모델은 다음 상황에 가장 적합하다: - 요구사항이 안정적인 대규모 폭포수(waterfall) 방식 프로젝트 - 비용 근거 문서화가 필요한 정부/국방 계약 - 방대한 프로젝트 이력 데이터베이스를 보유한 조직
소규모 팀이나 애자일 프로젝트에는 스토리 포인트 기반 추정이 보통 더 실용적이다.
5. 스토리 포인트와 상대적 추정¶
스토리 포인트(Story Points)는 애자일 개발에서 사용자 스토리를 구현하는 데 필요한 공수를 표현하는 상대적이고 무차원적인 단위다. 시간이나 인일(person-day)과 달리, 스토리 포인트는 특정 기간에 얽매이지 않고 공수, 복잡도, 불확실성을 함께 포착한다.
5.1 상대적 추정이 효과적인 이유¶
사람은 절대적 추정("이 작업은 14시간 걸릴 것이다")에는 취약하지만, 상대적 비교("스토리 B는 스토리 A보다 약 두 배 어렵다")에는 꽤 능숙하다. 상대적 추정은 이 인지적 강점을 활용한다.
5.2 스토리 포인트에 피보나치 수열 사용¶
대부분의 팀은 수정된 피보나치 수열을 사용한다: 1, 2, 3, 5, 8, 13, 21, 40, 100.
큰 값 사이의 간격이 점점 커지는 것은 불확실성의 증가를 반영한다: 5와 8의 차이는 의미 있지만, 40과 45의 차이는 그렇지 않다.
일부 팀은 XS, S, M, L, XL (티셔츠 사이즈, §7 참조)이나 2의 거듭제곱 (1, 2, 4, 8, 16)을 사용하기도 한다.
5.3 속도 (Velocity)¶
여러 스프린트를 완료하면 팀은 속도(Velocity)를 측정할 수 있다: 스프린트당 평균 완료 스토리 포인트 수.
Velocity = Total story points completed in sprint / 1 sprint
(averaged over several sprints for stability)
속도는 릴리스 계획에 사용된다: 백로그가 N 스토리 포인트이고 팀 속도가 V 포인트/스프린트라면, 프로젝트에는 약 N/V 스프린트가 필요하다.
5.4 스토리 포인트의 한계¶
- 포인트는 팀 상대적이다: 팀 A의 "5"는 더 경험 많은 팀 B에게는 "3"일 수 있음
- 포인트는 복잡도를 측정하지 시간을 측정하지 않는다; "스토리 포인트 1개가 몇 시간인가?"라고 묻는 이해관계자는 모델을 오해하는 것
- 추정치를 부풀려 속도를 조작할 수 있다("스토리 포인트 인플레이션"이라고 불리는 관행)
- 새로운 팀은 속도 이력이 없어 초기 스프린트로 교정해야 함
6. 플래닝 포커¶
플래닝 포커(Planning Poker)는 전문가 판단, 구조화된 토론, 델파이(Delphi) 방법을 결합해 스토리 포인트 추정치를 산출하는 합의 기반 추정 기법이다.
6.1 진행 방식¶
-
준비: 각 팀원은 피보나치 값(1, 2, 3, 5, 8, 13, 21, ?, ∞, ☕)이 적힌 카드 덱을 받는다. 제품 책임자(Product Owner)가 사용자 스토리를 읽는다.
-
개별 선택: 각 추정자는 자신의 추정치를 나타내는 카드를 비공개로 선택한다. 이 시점에서는 카드를 공개하지 않는 것이 핵심이다.
-
동시 공개: 셋을 세면 모든 추정자가 동시에 카드를 공개한다. 동시 공개는 닻 내리기 편향(Anchoring) — 먼저 들은 숫자가 이후 모든 추정치를 강하게 끌어당기는 현상 — 을 방지한다.
-
토론: 추정치가 다르면, 가장 높게 추정한 사람과 가장 낮게 추정한 사람이 각자의 근거를 설명한다. 이 과정에서 숨겨진 복잡도, 오해된 요구사항, 다른 가정이 드러난다.
-
재추정: 팀이 수렴하거나 다시 투표할 때까지 논의가 이어진다. 추정치가 피보나치 수 한 단계 이내로 모일 때까지 반복한다.
-
기록: 합의된 추정치를 스토리에 기록한다.
6.2 특수 카드¶
| 카드 | 의미 |
|---|---|
? |
"스토리를 충분히 이해하지 못해 추정할 수 없습니다" → 토론 필요 |
∞ |
"이 스토리는 너무 커서 추정이 불가능합니다; 더 작게 나누어야 합니다" |
☕ |
"휴식이 필요합니다" |
6.3 플래닝 포커가 효과적인 이유¶
- 구조화된 토론: 가정을 명확히 표현하도록 강제함
- 닻 내리기 방지: 동시 공개가 인지 편향을 차단함
- 팀 헌신: 추정에 참여한 이들이 그 결과에 더 책임감을 가짐
- 지식 공유: 스토리를 논의하면서 구현 지식이 표면화됨
6.4 원격 플래닝 포커¶
분산 팀을 위한 도구: PlanningPoker.com, Scrum Poker Online, Jira Planning Poker 플러그인, Miro 템플릿.
7. 티셔츠 사이즈 추정¶
티셔츠 사이즈 추정(T-Shirt Sizing)은 XS, S, M, L, XL (때로는 XXL)을 사용해 상대적 규모를 표현한다. 플래닝 포커보다 빠르며 다음 상황에 사용된다:
- 스토리 포인트로 표현하기에 너무 큰 에픽과 테마
- 스토리가 아직 명확하게 정의되지 않은 초기 로드맵 계획
- 전체 플래닝 포커에 앞서 빠른 필터링
팀은 스토리 포인트와의 대응을 약속한다, 예를 들어:
| 티셔츠 | 스토리 포인트 |
|---|---|
| XS | 1–2 |
| S | 3–5 |
| M | 8 |
| L | 13–21 |
| XL | 40+ (분리 고려) |
티셔츠 사이즈 추정은 정밀도를 희생하는 대신 속도를 얻는다. 스토리가 더 구체화되면 정제하는 1차 추정이다.
8. 삼점 추정과 PERT¶
삼점 추정(Three-Point Estimation)은 작업 기간이 단일 숫자가 아니라 분포임을 인정한다. 세 가지 시나리오를 추정한다:
| 매개변수 | 기호 | 의미 |
|---|---|---|
| 낙관적 (Optimistic) | O | 모든 것이 잘 풀릴 때 (최선의 경우; ~5백분위) |
| 최빈값 (Most Likely) | M | 현실적으로 기대되는 기간 |
| 비관적 (Pessimistic) | P | 일이 나쁘게 풀릴 때 (최악의 경우; ~95백분위) |
8.1 PERT 공식¶
프로그램 평가 검토 기법(Program Evaluation and Review Technique, PERT)은 최빈값에 가장 큰 가중치를 부여한 가중 평균을 사용한다:
Expected duration E = (O + 4M + P) / 6
Standard deviation σ = (P - O) / 6
Variance Var = σ²
예시:
| 작업 | O | M | P | E | σ |
|---|---|---|---|---|---|
| 스키마 설계 | 2 | 3 | 8 | 3.33 | 1.0 |
| API 구현 | 3 | 5 | 12 | 5.5 | 1.5 |
| 테스트 작성 | 1 | 2 | 5 | 2.33 | 0.67 |
순차적으로 실행되는 독립 작업들의 경우, 총 기대 기간과 총 분산은 덧셈으로 계산된다:
E_total = Σ E_i
Var_total = Σ Var_i
σ_total = √Var_total
위 세 작업에 대해:
E_total = 3.33 + 5.5 + 2.33 = 11.17 days
σ_total = √(1.0² + 1.5² + 0.67²) = √(1 + 2.25 + 0.45) = √3.70 ≈ 1.92 days
90% 신뢰 구간은 약 E ± 1.65σ = [11.17 ± 3.17] = [8.0, 14.3]일이다.
8.2 삼점 추정 활용 시점¶
- 상세 프로젝트 계획에서 개별 작업 추정
- 일정 불확실성을 이해관계자에게 전달해야 할 때 위험 정량화
- 각 작업의 분포에서 수천 번의 무작위 샘플을 추출해 프로젝트 완료 확률 분포를 생성하는 몬테카를로 시뮬레이션과 결합
9. 작업 분류 체계¶
작업 분류 체계(Work Breakdown Structure, WBS)는 전체 프로젝트 범위를 관리 가능한 작업 패키지로 계층적으로 분해한 것이다. "프로젝트가 무엇을 만들어야 하는가?"라는 질문에 답한다.
9.1 WBS 원칙¶
- 산출물 지향: 각 노드는 활동이 아닌 산출물 또는 결과물
- 100% 규칙: WBS는 프로젝트 범위의 100%를 포함해야 함 — 그 이상도, 그 이하도 아님
- 상호 배타성: 동일한 작업이 두 번 계산되지 않음
- 작업 패키지(리프 노드)는 가장 작은 단위로, 보통 한 보고 기간 동안 한 사람 또는 팀에 할당됨
9.2 WBS 예시: 모바일 뱅킹 앱¶
1. Mobile Banking App
├── 1.1 Project Management
│ ├── 1.1.1 Project Plans
│ ├── 1.1.2 Status Reports
│ └── 1.1.3 Risk Register
├── 1.2 Requirements
│ ├── 1.2.1 Stakeholder Interviews
│ ├── 1.2.2 Use Cases
│ └── 1.2.3 SRS Document
├── 1.3 Design
│ ├── 1.3.1 Architecture Document
│ ├── 1.3.2 Database Schema
│ └── 1.3.3 UI Wireframes
├── 1.4 Implementation
│ ├── 1.4.1 Authentication Module
│ ├── 1.4.2 Account Management Module
│ ├── 1.4.3 Transfer Module
│ └── 1.4.4 Notifications Module
├── 1.5 Testing
│ ├── 1.5.1 Unit Tests
│ ├── 1.5.2 Integration Tests
│ └── 1.5.3 UAT
└── 1.6 Deployment
├── 1.6.1 Infrastructure Setup
└── 1.6.2 Production Release
WBS는 개요 번호 부여(outline numbering) 방식을 사용하여 각 작업 패키지에 고유 식별자(예: 1.4.3)를 부여하며, 이 식별자는 일정, 예산, 위험 등록부에 등장한다.
9.3 WBS 사전 (WBS Dictionary)¶
각 작업 패키지에는 다음을 포함하는 WBS 사전 항목이 있어야 한다: - 작업 설명 - 담당자/팀 - 일정 (시작, 종료) - 예상 비용 - 의존성 - 인수 기준
10. 간트 차트와 주경로¶
10.1 간트 차트 (Gantt Charts)¶
간트 차트(Gantt chart)는 프로젝트 작업을 시간 축에 대해 표시하는 막대 차트다. 각 작업은 수평 막대이며, 길이는 기간을, 위치는 시간 범위를 나타낸다.
Task | Wk1 | Wk2 | Wk3 | Wk4 | Wk5 | Wk6 |
-----------------------|-----|-----|-----|-----|-----|-----|
Requirements |=====|=====| | | | |
Architecture | | ===|=====| | | |
Database Design | | |=====| | | |
Backend Development | | | |=====|=====| |
Frontend Development | | | ===|=====|=====| |
Testing | | | | |=====|=====|
Deployment | | | | | | ===|
현대 프로젝트 관리 도구(Microsoft Project, Jira Plans, Asana, Linear)는 작업 의존성과 추정치로부터 간트 차트를 자동으로 생성한다.
10.2 주경로 분석법 (Critical Path Method, CPM)¶
주경로(Critical Path)는 프로젝트 시작부터 끝까지 종속 작업들로 이어진 가장 긴 경로다. 주경로 위의 어떤 지연도 프로젝트를 직접 지연시킨다. 주경로에 없는 작업들은 여유(Float, Slack)를 가진다 — 프로젝트 종료일에 영향을 주지 않고 지연될 수 있다.
전진 계산(Forward pass) — 최조 시작일(ES)과 최조 완료일(EF) 계산:
ES(task) = max(EF of all predecessors)
EF(task) = ES(task) + duration
후진 계산(Backward pass) — 최지 시작일(LS)과 최지 완료일(LF) 계산:
LF(task) = min(LS of all successors)
LS(task) = LF(task) - duration
여유(Float, Slack):
Float = LS - ES = LF - EF
여유가 0인 작업은 주경로 위에 있다.
네트워크 예시:
┌─────┐ ┌─────┐
●────►│ A:3 │───────►│ C:4 │──────►●
└─────┘ └─────┘ (project end)
│ ▲
│ ┌─────┐ │
└──────────►│ B:6 │────────┘
└─────┘
Tasks: A (3 days), B (6 days), C (4 days, depends on A)
Path 1: A → C = 3 + 4 = 7 days
Path 2: A → B = 3 + 6 = 9 days ← Critical Path
Float for C = 9 - 7 = 2 days
10.3 일정 단축: 충돌과 병렬 진행¶
주경로가 너무 길 때: - 충돌(Crashing): 주경로 작업에 자원을 추가해 기간을 단축 (비용이 들고, Brooks의 법칙으로 수익 체감 — §13 참조) - 패스트 트래킹(Fast-tracking): 주경로 작업을 순차적이 아닌 병렬로 실행 (재작업 위험 증가)
11. 릴리스 계획 vs. 스프린트 계획¶
11.1 릴리스 계획 (Release Planning)¶
릴리스 계획(Release planning)은 특정 날짜까지 어떤 기능을 제공할지(또는 특정 기능들이 언제 준비될지)를 결정한다. 여러 스프린트에 걸쳐 에픽/스토리 수준에서 운영된다.
프로세스: 1. 백로그를 우선순위(비즈니스 가치, 위험, 의존성)로 정렬 2. 팀 속도 결정 (과거 스프린트 이력이나 초기 교정 스프린트 기반) 3. 계산: 스프린트 수 = 총 스토리 포인트 / 속도 4. 스토리를 릴리스에 할당하며, 범위가 용량에 맞는 지점에 릴리스 경계선 설정
Sprint | Stories | Points | Cumulative | Release
----------|-----------------|--------|------------|--------
1 | Login, Profile | 18 | 18 |
2 | Search, Filter | 21 | 39 | v1.0
3 | Checkout, Cart | 25 | 64 |
4 | Payment, Review | 20 | 84 | v1.1
5 | Admin Panel | 22 | 106 |
6 | Reporting | 18 | 124 | v1.2
11.2 스프린트 계획 (Sprint Planning)¶
스프린트 계획(Sprint planning)은 각 스프린트 초에 팀이 백로그에서 스토리를 선택하고 스프린트 내에 완료할 것을 약속하는 의식이다. 며칠에서 일주일 단위로 스토리/작업 수준에서 운영된다.
두 부분으로 구성: 1. 무엇을? — 제품 책임자가 최우선 백로그 항목을 제시하고, 팀이 속도에 맞는 스토리를 선택 2. 어떻게? — 팀이 선택한 스토리를 엔지니어링 작업(시간 기준)으로 분해하고, 기술적 접근법과 의존성을 파악
결과: 스프린트 백로그(Sprint Backlog) — 이번 스프린트에서 완료할 스토리와 작업의 집합.
11.3 이터레이션 제로 (Iteration Zero, Sprint 0)¶
애자일 프로젝트의 첫 번째 스프린트는 종종 다음을 위한 "스프린트 0"이다: - 개발 환경과 CI/CD 파이프라인 구축 - 코딩 표준 및 브랜치 전략 수립 - 초기 아키텍처 스파이크(spike) 수행 - 샘플 백로그 스토리로 플래닝 포커를 실행해 속도 교정
이 스프린트는 사용자 대상 기능을 제공하지 않지만, 이후 모든 스프린트가 효과적으로 작동하도록 기반을 마련한다.
12. 추정 정확도: 추적과 개선¶
12.1 실제 vs. 추정 추적¶
매 스프린트:
# Pseudo-code for tracking estimation accuracy
def sprint_report(sprint):
accuracy_per_story = []
for story in sprint.completed_stories:
# For hour-based tasks
accuracy = story.actual_hours / story.estimated_hours
accuracy_per_story.append(accuracy)
avg_accuracy = mean(accuracy_per_story)
# accuracy > 1.0: over-ran; < 1.0: finished early
return avg_accuracy
팀이 추적해야 할 항목: - 속도 추세 (안정적인가, 향상되고 있는가, 하락하고 있는가?) - 정확도 비율 (스토리 규모별 실제/추정) — 8포인트 스토리가 일관되게 과소평가되는 경향이 자주 있음 - 이월률(Spillover rate) (완료하지 못한 스토리 비율)
12.2 교정 기법¶
| 기법 | 설명 |
|---|---|
| 과거 유추(Historical analogy) | 새 스토리를 비슷한 복잡도의 이전 완료 스토리와 비교 |
| 분해(Decomposition) | 큰 스토리를 작업으로 분해하고, 작업을 추정한 후 합산 |
| 참조 스토리(Reference stories) | 각 크기 포인트에서 교정 기준점 역할을 하는 "참조 스토리" 유지 |
| 와이드밴드 델파이(Wideband Delphi) | 구조화된 전문가 합의 (플래닝 포커가 근사하는 공식 방법) |
12.3 시간에 따른 추정 개선¶
- 추정에 집중한 회고 진행: "어떤 스토리를 가장 많이 잘못 추정했는가? 왜?"
- 참조 스토리 갱신: 팀의 역량이 성장할수록 "5"의 의미를 재교정
- 추정 체크리스트 유지: 자주 누락되는 작업(코드 리뷰 시간, 문서화, 배포 검증)
- 추정 편향 추적: 팀이 지속적으로 20% 과소평가한다면, 행동이 바뀔 때까지 1.2 보정 계수 적용
13. 일반적인 추정 함정¶
13.1 낙관주의 편향 (계획 오류, Planning Fallacy)¶
사람들은 미래 행동의 시간, 비용, 위험을 체계적으로 과소평가한다. Daniel Kahneman은 이를 계획 오류(Planning Fallacy)라고 명명했다: 개인들은 과거 실적과 위험을 무시한 채 최선의 시나리오로 작업을 완료한다고 예측한다.
대응책: 참조 계층 예측(Reference class forecasting) — 현재 프로젝트를 추정하기 전에 유사한 프로젝트가 실제로 얼마나 걸렸는지 살펴본다.
13.2 닻 내리기 편향 (Anchoring Bias)¶
추정 논의에서 처음 언급된 숫자가 인지적 닻이 된다. 관리자가 "이건 한 주 정도 걸릴 것 같아요"라고 말하면, 이후 모든 추정치는 그 숫자 쪽으로 끌린다.
대응책: 동시 공개 (플래닝 포커)와 원하는 기간에 대한 논의가 시작되기 전에 추정치를 먼저 제시하도록 요구하기.
13.3 파킨슨의 법칙 (Parkinson's Law)¶
"업무는 완료하기 위해 주어진 시간을 채운다." 작업에 2주가 주어지면, 3일이면 할 수 있더라도 2주가 걸린다.
대응책: 명시적으로 짧은 기간을 설정한 타임박싱(Timeboxing)과 일일 스탠드업. 애자일 스프린트는 자연스럽게 타임박싱을 적용한다.
13.4 Brooks의 법칙 (Brooks's Law)¶
"지연된 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다." (Fred Brooks, The Mythical Man-Month) 새 팀원은 온보딩이 필요하고, 커뮤니케이션 오버헤드를 증가시키며, 통합 문제를 일으키는 방식으로 작업을 분담한다.
대응책: 팀 구성을 미리 계획하고, 마지막 순간에 인력을 추가하지 않는다. 불가피하다면, 비핵심 업무에 배치한다.
13.5 학생 증후군 (Student Syndrome)¶
사람들은 마지막 순간까지 작업 시작을 미루다가 서두르게 되어 품질 문제와 이월이 발생한다.
대응책: 일일 스탠드업으로 진행 상황을 가시화하고; 완료의 정의(Definition of Done) 기준으로 조기 종료를 방지한다.
13.6 90% 증후군 (Ninety-Percent Syndrome)¶
"90% 완료"로 보고된 작업이 오랫동안 "90% 완료" 상태에 머무르는 경향이 있다. 마지막 10%에 가장 어렵고 불확실한 작업이 들어있다.
대응책: 작업 패키지에 이진 완료 추적(완료/미완료)을 사용한다. 완료 비율이 아닌 남은 작업량을 보고한다.
13.7 범위 팽창 (Scope Creep)¶
일정, 예산, 자원의 조정 없이 프로젝트 범위가 통제되지 않고 확장되는 것.
대응책: 공식 변경 관리(레슨 04 참조); MoSCoW 우선순위 결정; 스프린트 수준의 범위 약속.
14. 요약¶
추정은 의도적인 연습, 교정 데이터, 구조화된 기법을 통해 향상되는 기술이다.
| 기법 | 최적 활용 상황 | 핵심 공식 |
|---|---|---|
| LOC | 알고리즘 중심, 고성능 코드 | Effort = LOC / productivity |
| 기능 점수 (Function Points) | 기술 독립적 규모 측정 | UFP = Σ(count × weight) |
| COCOMO | 대규모 폭포수 프로젝트 | E = a × KLOC^b × Π(EM) |
| 스토리 포인트 (Story Points) | 애자일 스프린트 | 상대적; 속도로 교정 |
| 플래닝 포커 (Planning Poker) | 팀 합의 추정 | 동시 공개 + 토론 |
| 티셔츠 사이즈 (T-shirt sizing) | 에픽, 초기 로드맵 | XS/S/M/L/XL |
| 삼점 추정/PERT | 작업 수준 불확실성 | E = (O + 4M + P) / 6 |
| WBS | 범위 분해 | 100% 규칙; 개요 번호 부여 |
| 주경로 (Critical Path) | 일정 최적화 | Float = LS − ES |
핵심 원칙: - 불확실성을 인정하고 소통하라; 불확실성의 원뿔을 사용해 기대치를 설정하라 - 애자일 팀에는 상대적 추정(스토리 포인트)을 선호하라; 절대 시간 추정보다 빠르고 정확하다 - 추정치에 대해 실제 결과를 철저히 추적하라; 그 데이터가 미래 추정 개선의 토대다 - 닻 내리기 편향, 낙관주의 편향, 관리 압박으로부터 추정치를 보호하라
15. 연습 문제¶
연습 1: PERT 추정
소프트웨어 팀이 새 기능을 위해 세 가지 작업을 파악했다:
| 작업 | 낙관적 | 최빈값 | 비관적 |
|---|---|---|---|
| 데이터베이스 마이그레이션 | 1일 | 2일 | 6일 |
| API 구현 | 3일 | 5일 | 10일 |
| 프론트엔드 통합 | 2일 | 4일 | 9일 |
작업들이 순차적(각 작업이 이전 작업에 의존)이라고 가정한다.
a. 각 작업의 PERT 기대 기간과 표준 편차를 계산하라. b. 총 기대 프로젝트 기간과 표준 편차를 계산하라. c. 프로젝트 완료일에 대한 90% 신뢰 구간을 계산하라. d. 프로젝트 관리자가 "13일에 완료하겠습니다"라고 말한다. 이는 어느 정도의 성공 확률을 나타내는가? (힌트: Z-점수를 계산하라.)
연습 2: 기능 점수 계산
온라인 설문 애플리케이션에 다음 컴포넌트가 있다:
- 설문 생성 양식 (입력: 질문 + 최대 10개 선택지) — 평균 EI
- 투표 양식 (입력: 설문 ID + 선택지) — 낮음 EI
- 결과 보기 페이지 (출력: 선택지별 투표 막대 차트) — 평균 EO
- 키워드로 설문 검색 (입출력 쌍, 데이터 변경 없음) — 낮음 EQ
- 설문 테이블 (시스템이 유지) — 평균 ILF
- 사용자 테이블 (시스템이 유지) — 낮음 ILF
- 인증 서비스 (외부 시스템, 참조만 하고 유지하지 않음) — 낮음 EIF
미조정 기능 점수(UFP)를 계산하라. 팀의 과거 생산성이 8 FP/인월이라면, 공수를 인월로 추정하라.
연습 3: 주경로
다음 프로젝트 네트워크가 주어진다 (작업: 기간, 선행 작업):
| 작업 | 기간 | 선행 작업 |
|---|---|---|
| A | 4일 | — |
| B | 6일 | — |
| C | 3일 | A |
| D | 5일 | A, B |
| E | 4일 | C, D |
| F | 2일 | D |
| G | 3일 | E, F |
a. 네트워크 다이어그램을 그려라. b. 전진/후진 계산을 수행해 각 작업의 ES, EF, LS, LF, 여유(Float)를 계산하라. c. 주경로와 프로젝트 기간을 파악하라. d. 작업 D가 2일 지연되면 새로운 프로젝트 기간은 얼마인가?
연습 4: 릴리스 계획
제품 백로그에 240 스토리 포인트가 있다. 팀의 지난 4번의 스프린트 측정 속도는: 28, 32, 30, 26 포인트/스프린트 (2주 스프린트)이다.
a. 팀의 평균 속도를 계산하라. b. 백로그를 완료하는 데 필요한 스프린트 수와 달력 기준 개월 수를 추정하라. c. 제품 책임자가 우선순위 순으로 처음 100 스토리 포인트를 v1.0으로 릴리스하길 원한다. 몇 번의 스프린트가 필요한가? d. 시니어 엔지니어 한 명이 한 스프린트 동안 휴가를 떠나 해당 스프린트 속도가 20% 감소한다. v1.0 릴리스 날짜에 어떤 영향을 미치는가?
연습 5: 추정 함정
아래 각 시나리오에서 발생하고 있는 추정 함정을 파악하고 완화 방안을 제안하라:
a. 프로젝트 관리자가 팀이 추정을 하기도 전에 킥오프 회의에서 6개월 기한을 발표한다. 이후 모든 추정치가 6개월 근처로 모인다. b. 팀이 어려운 데이터베이스 마이그레이션 작업을 3주 연속으로 "95% 완료"로 보고한다. c. 개발자 한 명이 10일 스프린트의 9일째에야 대규모 기능 코딩을 시작한다. d. 슬리핑하는 일정을 맞추기 위해 관리자가 남은 2주에 개발자 3명을 추가로 프로젝트에 투입한다. e. 팀이 최선의 시나리오("모든 것이 순조롭다면")를 기반으로 기능을 추정하며, 통합 테스트에서 반복적으로 차단 버그가 발견된 과거 스프린트를 무시한다.
16. 더 읽을거리¶
- McConnell, S. — Software Estimation: Demystifying the Black Art (Microsoft Press, 2006) — 이 주제에서 가장 실용적이고 읽기 쉬운 책
- Boehm, B. — Software Engineering Economics (Prentice-Hall, 1981) — 원래 COCOMO; 기초 문헌
- Boehm, B. et al. — Software Cost Estimation with COCOMO II (Prentice-Hall, 2000) — COCOMO II 전체 내용
- Brooks, F. — The Mythical Man-Month (Addison-Wesley, 1975; 기념판 1995) — 필독서; Brooks의 법칙, 외과 팀 모델, 개념적 무결성
- Kahneman, D. — Thinking, Fast and Slow (Farrar, Straus and Giroux, 2011) — 계획 오류와 닻 내리기를 포함한 인지 편향
- Cohn, M. — Agile Estimating and Planning (Prentice-Hall, 2005) — 스토리 포인트, 플래닝 포커, 속도 기반 릴리스 계획
- IFPUG — IFPUG Function Point Counting Practices Manual (Release 4.3.1) — 권위 있는 FPA 참고 문헌
- PMI — A Guide to the Project Management Body of Knowledge (PMBOK Guide) — WBS, CPM, 획득 가치 관리
이전: 05. 소프트웨어 모델링과 UML | 다음: 07. 소프트웨어 품질 보증