핵심 인사이트
- 상향식(Bottom-Up) 비용 산정은 WBS(Work Breakdown Structure)의 개별 작업 단위에서 시작해 합산하는 방식 — 세부 계획이 확정된 후 적용 가능하며, 하향식보다 정확하지만 시간이 많이 소요된다.
- LOC(Lines of Code, 소스 코드 라인 수)는 가장 오래되고 직관적인 소프트웨어 규모 측정 지표 — 생산성(LOC/인월)과 비용(비용/LOC)으로 산정하나, 언어·개발자 숙련도·코딩 스타일에 크게 의존하는 한계가 있다.
- LOC와 기능점수(FP)의 비율은 언어별로 크게 다름 — C언어 1 FP ≈ 100~150 LOC, Java 1 FP ≈ 50~70 LOC, Python 1 FP ≈ 30~50 LOC로, LOC만으로 다른 언어 프로젝트를 비교하면 오류가 생긴다.
Ⅰ. 상향식 비용 산정
상향식 (Bottom-Up) 비용 산정:
WBS (Work Breakdown Structure):
프로젝트를 계층적 작업으로 분해
프로젝트
├── 모듈A
│ ├── 설계: 5일, 1명
│ ├── 구현: 15일, 2명
│ └── 테스트: 5일, 1명
├── 모듈B
│ ├── 설계: 3일, 1명
│ ├── 구현: 10일, 2명
│ └── 테스트: 3일, 1명
└── 통합 테스트: 10일, 2명
합산:
노력 = Σ (작업 × 인원 × 일수)
비용 = 노력 × 단가 + 비인력 비용
상향식 장점:
세부 항목 고려 → 정확도 높음
담당자 직접 추정 → 현실적
작업 누락 최소화 (WBS 완전성 전제)
상향식 단점:
WBS 완성 필요 → 초기 불가
시간·노력 많이 소요
세부 작업 과소/과대 추정 가능
합산 시 상호작용 비용 누락 가능
이중 검증:
상향식 추정 + 하향식(유추) 비교
차이 > 20% → 원인 분석
위험: 하향식 < 상향식
→ 범위 과소 측정 또는 팀 비효율
전제 조건:
상향식은 요구사항 정의 완료 후
설계 수준 WBS 구성 가능 시점에 적용
📢 섹션 요약 비유: 상향식은 재료비 정확 계산 — 레시피(WBS)대로 재료 하나하나 가격 합산. 시간은 걸리지만 정확. 레시피도 없는 초기엔 사용 불가!
Ⅱ. LOC 산정
LOC (Lines of Code):
소프트웨어 규모의 직접 측정 지표
LOC 유형:
물리적 LOC: 공백·주석 포함 모든 줄
논리적 LOC (LLOC): 실행 가능 구문만
SLOC (Source LOC): 주석·공백 제외
일반적으로 SLOC 사용
LOC 기반 산정:
1. 작업량(Effort) 추정:
Effort = LOC / Productivity
예:
예상 LOC: 10,000
생산성: 200 LOC/인월
Effort = 10,000 / 200 = 50 인월
2. 비용 추정:
Cost = Effort × Rate
50 인월 × 500만/월 = 2.5억
3. 기간 추정:
Duration = Effort / Team_Size
50 인월 / 5명 = 10개월
LOC 측정 도구:
cloc (Count Lines of Code): 다중 언어 지원
$ cloc src/
→ 언어별 파일수·공백·주석·코드 통계
LOC 장점:
측정 용이 (자동화 가능)
직관적
초기 데이터 풍부 (역사적 비교)
LOC 단점:
언어별 비교 불가 (Python vs C)
개발자 능력 무시
재사용 코드 과소 평가
코드 품질 미반영 (더 짧은 코드 = 더 능숙)
📢 섹션 요약 비유: LOC는 요리 재료 무게 — "이 요리 재료 5kg" 객관적 측정. 하지만 재료가 같아도 요리사(개발자) 실력, 식재료 종류(언어)에 따라 품질이 달라요!
Ⅲ. 언어별 LOC/FP 비율
언어별 FP(기능점수) 당 LOC 비교:
언어 LOC/FP (중앙값) 특징
Assembly 320 저수준 제어
C 128 시스템 프로그래밍
C++ 64 객체지향
Java 55 엔터프라이즈
C# 54 .NET
Python 33 간결, 높은 생산성
Ruby 28 DSL 최적화
Cobol 107 레거시 비즈니스
(출처: Capers Jones QSM 통계)
의미:
1 FP 기능을 구현하는 데:
C: 128줄
Python: 33줄
→ C로 100,000 LOC = 781 FP
→ Python으로 100,000 LOC = 3,030 FP
LOC만으로 비교하면 Python이 3.9배 기능 더 많음!
→ LOC 기반 비교는 동일 언어에서만 유효
생산성 비교 (LOC/인월):
COBOL: 50~100
Java: 150~300
Python: 300~600
Python 팀이 LOC 적어도 더 많은 기능 구현 가능
규모 추정 시 고려:
언어 선택이 LOC 추정에 직접 영향
LOC 기반 산정 = 언어 고정 후 사용
대안: 기능점수(FP)
언어 독립적 규모 측정
사용자 관점 기능으로 측정
비교 용이
📢 섹션 요약 비유: LOC/FP는 언어별 단어 효율 — 같은 내용(기능)을 영어(C)는 100단어, 한자(Python)는 30단어로 표현. 단어 수만 보면 오해!
Ⅳ. COCOMO II LOC 기반 모델
COCOMO II (Constructive Cost Model):
LOC 기반 가장 널리 사용되는 비용 모델
기본 공식:
PM = A × (Size)^E × ΠEM_i
PM: 노력 (인월, Person-Months)
Size: KSLOC (천 줄 단위 SLOC)
A: 2.94 (보정 상수)
E: 경험적 지수 (규모 효과)
EM_i: 노력 승수 (17개 비용 드라이버)
규모 효과 (Scale Factor):
E = 0.91 + 0.01 × ΣSF_i
SF 예시:
선례성 (Precedentedness): 유사 프로젝트 경험
팀 응집성 (Team Cohesion)
프로세스 성숙도 (Process Maturity)
E 범위: 0.91~1.23
비용 드라이버 (EM, 일부):
RELY (신뢰성 요구): 0.82~1.26
CPLX (복잡도): 0.73~1.74
ACAP (분석가 역량): 0.71~1.42
TOOL (도구 사용): 0.78~1.17
예시 계산:
Size = 100 KSLOC, E = 1.05
EM_RELY = 1.10, EM_CPLX = 1.30, EM_ACAP = 0.85
PM = 2.94 × (100)^1.05 × 1.10 × 1.30 × 0.85
= 2.94 × 140 × 1.218
= 501 인월
5년짜리 팀 10명 → 50개월 → 4.2년
기간 추정:
TDEV = 3.67 × (PM)^(0.28+0.002×ΣSF)
= 3.67 × 501^0.33 ≈ 29.5개월
📢 섹션 요약 비유: COCOMO II는 요리 시간 계산기 — 재료 양(LOC) × 어려운 레시피(복잡도) × 초보 요리사(역량 드라이버) = 완성 시간. 변수가 많을수록 정확!
Ⅴ. 실무 시나리오 — SI 프로젝트 상향식 산정
중견 기업 ERP 커스터마이징 프로젝트:
WBS 기반 상향식 산정:
모듈 1: 구매 관리
요구사항 분석: 5일 × 1명 = 5 인일
DB 설계: 3일 × 1명 = 3 인일
화면 개발 (10개): 15일 × 2명 = 30 인일
API 개발: 10일 × 2명 = 20 인일
단위 테스트: 5일 × 1명 = 5 인일
소계: 63 인일
모듈 2: 재고 관리
소계: 85 인일
모듈 3: 영업 관리
소계: 90 인일
공통 작업:
아키텍처 설계: 10 인일
통합 테스트: 20 인일
배포: 5 인일
총합: 273 인일 = 13.65 인월
LOC 검증:
개발 LOC 추정: ~15,000 SLOC (Java)
Java 생산성: 200 LOC/인월
= 75 인월 (← 차이 큼!)
차이 분석:
상향식 13.65 인월 vs LOC 75 인월
원인: 기존 ERP 위에 커스터마이징
→ 순수 신규 개발 LOC 비율 낮음
→ LOC 모델이 과대 추정
결론: 상향식이 더 현실적
LOC는 레거시/커스터마이징에 부적합
최종 산정:
상향식 기반 14인월 (10% 완충 포함)
팀 구성: 3명 → 기간 약 5개월
총 비용: 14인월 × 500만 = 7,000만원
📢 섹션 요약 비유: SI 프로젝트 상향식은 견적서 — 화면 10개 × 요금, API 20개 × 요금, 테스트 포함. 재료 하나하나 더하기. LOC 모델과 비교해서 차이 크면 이유 분석!
📌 관련 개념 맵
상향식 산정 / LOC
+-- 상향식 비용 산정
| +-- WBS 기반
| +-- 작업 단위 합산
| +-- 이중 검증 (하향식과 비교)
+-- LOC 측정
| +-- SLOC (Source LOC)
| +-- 물리적 LOC
| +-- LOC/FP 언어별 비율
+-- 모델
| +-- COCOMO II
| +-- Putnam 모델
+-- 대안
+-- 기능점수 (FP)
+-- 스토리 포인트 (애자일)
📈 관련 키워드 및 발전 흐름도
[초기 LOC 산정 (1960~70s)]
코드 라인 수로 규모 측정
프로그래머별 LOC/일 측정
|
v
[COCOMO 모델 (1981)]
Boehm: LOC 기반 비용 모델
경험적 공식 체계화
|
v
[기능점수 FP (1984~)]
언어 독립적 대안
LOC 한계 보완
|
v
[COCOMO II (1995~)]
OO·컴포넌트 반영
17개 비용 드라이버
|
v
[현재: 스토리 포인트 병행]
애자일 팀: 상대 추정
LOC는 코드 품질 측정 보조 지표
👶 어린이를 위한 3줄 비유 설명
- 상향식은 장보기 목록 더하기 — 밀가루 얼마, 버터 얼마, 달걀 얼마... 하나하나 더해서 총 장보기 비용. 정확하지만 시간 걸려요!
- LOC는 코드 길이 — 소설 페이지 수처럼 코드 줄 수로 크기 측정. 하지만 영어 책이랑 한자 책을 페이지로 비교하면 오해!
- COCOMO II는 공사 견적 공식 — 건물 크기(LOC) × 공사 어려움(복잡도) × 인부 실력(역량) = 완공 기간. 변수 많을수록 정확!