핵심 인사이트

  1. 소프트웨어 비용 산정은 프로젝트 시작 전 개발 공수(PM, Person-Month)·일정·원가를 예측하는 활동으로 — Boehm의 COCOMO 연구에 따르면 초기 산정 오차가 ±4배에 달하지만, 요구사항이 명확해질수록 ±25% 이내로 수렴한다.
  2. 기능 점수(FP — Function Point)와 COCOMO는 가장 널리 쓰이는 산정 기법으로 — FP는 사용자 관점의 기능 규모를 측정하는 반면, COCOMO는 LOC(Lines of Code) 기반 통계 모델로 규모·복잡도·팀 능력 등 비용 유발 요소(Cost Driver)를 반영한다.
  3. 소프트웨어 산정의 근본 어려움은 "눈에 보이지 않는 제품을 미래에 만드는 비용을 현재 추정"하는 것으로 — 이 때문에 애자일은 스토리 포인트를 통한 상대적 추정과 속도(Velocity) 기반 적응형 계획으로 전통적 산정 한계를 보완한다.

Ⅰ. 비용 산정 개요

소프트웨어 비용 산정 (Cost Estimation):

필요성:
  프로젝트 승인/기각 결정
  일정 및 인력 계획
  계약 및 예산 편성
  위험 관리

산정 어려움:
  비가시성: 소프트웨어는 눈에 보이지 않음
  불확실성: 초기에 요구사항 불명확
  창의성: 반복 생산 아닌 독자적 개발
  복잡성: 팀 규모 증가 → 비선형 복잡도 증가

비용 구성 요소:
  인건비 (People): 60~80%
  하드웨어 (HW): 5~15%
  소프트웨어 (SW): 5~10%
  기타 (교육, 출장): 5~15%

산정 유형:
  1. 전문가 판단 (Expert Judgment): 경험 기반
  2. 유추 산정 (Analogy): 유사 프로젝트 비교
  3. 상향식 (Bottom-Up): 작업 단위로 합산
  4. 하향식 (Top-Down): 전체 규모 → 분할
  5. 매개변수 모델 (Parametric Model): COCOMO, FP

산정 정확도 (불확실성 콘):
  타당성 검토:  ×4 ~ ×0.25
  개념 설계:    ×2 ~ ×0.5
  상세 설계:    ×1.5 ~ ×0.67
  코딩 시작:    ×1.25 ~ ×0.8
  구현 완료:    ×1.1 ~ ×0.9

📢 섹션 요약 비유: 비용 산정은 집 짓기 전 견적 — 설계도도 없을 때(타당성 검토)는 ±4배 오차, 상세 도면 완성 후(코딩 시작)는 ±25% 이내. 정보가 많을수록 견적이 정확해져요.


Ⅱ. 기능 점수 (FP)

기능 점수 (FP — Function Point):
  Albrecht (IBM), 1979년 제안
  
  사용자 기능 관점에서 규모 측정
  프로그래밍 언어 독립적

FP 측정 요소:
  내부 논리 파일 (ILF — Internal Logical File):
    시스템이 관리하는 내부 데이터 그룹
    
  외부 인터페이스 파일 (EIF — External Interface File):
    외부 시스템이 관리하는 데이터 그룹
    
  외부 입력 (EI — External Input):
    외부에서 처리되어 내부 데이터 갱신하는 입력
    
  외부 출력 (EO — External Output):
    내부 데이터를 처리하여 외부로 전달하는 출력
    
  외부 조회 (EQ — External Inquiry):
    조회 요청 + 조회 응답 (계산 없는 검색)

가중치 (단순/보통/복잡):
  ILF: 7 / 10 / 15
  EIF: 5 / 7 / 10
  EI: 3 / 4 / 6
  EO: 4 / 5 / 7
  EQ: 3 / 4 / 6

미조정 기능 점수 (UFP):
  UFP = Σ(요소별 수량 × 가중치)

기술적 복잡도 조정 (VAFP):
  TCP (Technical Complexity Processing): 14개 요소
  예: 온라인 처리, 성능, 이식성, 보안 등
  0~5점 → TCF = 0.65 + 0.01 × Σ
  
  AFP = UFP × TCF

개발 공수 추정:
  공수 = AFP / 팀 생산성 (FP/월)

📢 섹션 요약 비유: 기능 점수는 집 평수 재기 — 방 수, 창문 수, 문 수를 세서 "평수"를 계산하는 것처럼, 입력·출력·파일·조회를 세어서 소프트웨어 크기를 수치화.


Ⅲ. COCOMO 모델

COCOMO (Constructive Cost Model):
  Boehm, 1981년 발표
  LOC (Lines of Code) 기반 공수 추정

COCOMO I (기본 모델):
  공수 = a × (KLOC)^b  [PM, Person-Month]
  기간 = c × (공수)^d  [Month]
  
  프로젝트 유형별 계수:
  
  유형     | 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, 10KLOC):
  공수 = 2.4 × 10^1.05 = 2.4 × 11.22 ≈ 27 PM
  기간 = 2.5 × 27^0.38 ≈ 8.4개월
  인원 = 27 / 8.4 ≈ 3.2명

COCOMO II (개선 모델):
  2000년 발표 (객체지향, 재사용 반영)
  
  공수 = A × (Size)^SF × ΠEM_i
  
  Size: KLOC 또는 기능 점수
  SF (Scale Factor): 5개 (선례성, 개발 유연성 등)
  EM (Effort Multiplier): 17개 비용 유발 요소
    예: RELY(신뢰성), CPLX(복잡도), ACAP(분석 능력)
    
  비용 유발 요소 범위: 0.5 ~ 1.58
  (Very Low ~ Very High로 5단계)

📢 섹션 요약 비유: COCOMO는 벽돌 수 기반 건축 공수 — 벽돌 수(LOC)가 2배면 공수는 2배가 아닌 2.1~2.4배. 규모가 클수록 팀 조율 비용이 비선형으로 증가해요.


Ⅳ. 애자일 산정

애자일 산정 (Agile Estimation):

배경:
  전통적 방법: 상세 요구사항 없이 초기 정확 산정 불가
  애자일: 불확실성 인정 + 반복으로 학습

스토리 포인트 (Story Point):
  절대적 시간 대신 상대적 복잡도 추정
  
  기준 스토리 설정 (예: 5SP = "보통 복잡도 로그인 기능")
  
  비교로 추정:
  "회원가입 = 로그인의 2배" → 10SP
  "단순 조회 = 로그인의 절반" → 2~3SP

플래닝 포커 (Planning Poker):
  피보나치: 1, 2, 3, 5, 8, 13, 21, 40, 100
  
  팀원 동시에 카드 공개 → 토론 → 합의
  불일치: 가장 높은/낮은 사람이 이유 설명
  
  목적: 집단 지성 + 앵커링 편향 방지

속도 (Velocity):
  이전 스프린트 처리 SP 평균
  
  스프린트 1: 40SP
  스프린트 2: 35SP
  스프린트 3: 42SP
  평균 속도 = 39SP/스프린트
  
  백로그 200SP → 예상 기간 = 200/39 ≈ 5.1 스프린트

장단점:
  장점: 불확실성 수용, 팀 역량 반영, 빠른 갱신
  단점: 팀/프로젝트 간 비교 어려움, 초기 속도 미확정

PERT 산정 (전통적):
  O (낙관): 10일
  M (최빈): 15일
  P (비관): 25일
  E = (O + 4M + P) / 6 = (10 + 60 + 25) / 6 ≈ 15.8일
  σ = (P - O) / 6 = (25-10)/6 = 2.5일

📢 섹션 요약 비유: 애자일 산정은 상대 크기로 비교 — 특대/대/중/소로 음식 주문하듯, 스토리 포인트는 "이 기능이 저 기능의 두 배 어려워"처럼 상대적으로 크기를 측정해요.


Ⅴ. 실무 시나리오 — ERP 시스템 산정

ERP 시스템 비용 산정 사례:

프로젝트 배경:
  중소 제조업 ERP 신규 개발
  모듈: 생산관리, 구매, 재고, 회계, HR
  
FP 산정:
  ILF: 35개 (중~복잡)  → 35×10 = 350
  EIF: 8개 (단~보통)   → 8×6 = 48
  EI: 65개 (단~보통)   → 65×4 = 260
  EO: 40개 (단~보통)   → 40×5 = 200
  EQ: 50개 (단)        → 50×3 = 150
  
  UFP = 350+48+260+200+150 = 1,008 FP
  TCF = 0.65 + 0.01×32 = 0.97
  AFP = 1,008 × 0.97 = 978 AFP

공수 산정:
  팀 생산성: 8 AFP/월 (중간 수준)
  공수 = 978 / 8 = 122.3 PM
  
COCOMO II 검증:
  LOC 추정: 978 AFP × 150 LOC/FP = 146,700 LOC
  공수 = 3.0 × (146.7)^1.12 × ΠEM ≈ 130 PM
  
  FP 결과(122 PM)와 COCOMO(130 PM) 비교 → 합리적

일정/인원:
  기간 = 2.5 × 122^0.38 ≈ 18개월
  인원 = 122 / 18 ≈ 7명
  
원가:
  개발자 단가: 600만원/월
  총 인건비: 122 × 600 = 7.32억
  HW/SW/기타 30% 추가: 9.5억
  
최종 견적: 10억 (리스크 버퍼 포함)

📢 섹션 요약 비유: ERP 비용 산정은 건축 견적 비교 — 평면도로 평수(FP) 계산하고, 자재 명세서로 공수(COCOMO) 계산해서 두 방법을 비교 검증. 둘이 비슷하면 신뢰도 높아요!


📌 관련 개념 맵

소프트웨어 비용 산정
+-- 전통적 방법
|   +-- 기능 점수 (FP): ILF/EIF/EI/EO/EQ
|   +-- COCOMO I, II: LOC 기반
|   +-- PERT: 3점 추정
+-- 애자일 방법
|   +-- 스토리 포인트
|   +-- 플래닝 포커
|   +-- 속도(Velocity) 기반 계획
+-- 불확실성
|   +-- 불확실성 콘
|   +-- 비용 유발 요소 (Cost Driver)

📈 관련 키워드 및 발전 흐름도

[초기 LOC 기반 (1960s)]
코드 라인 수 직접 산정
경험 기반 추정
      |
      v
[기능 점수 (1979)]
Albrecht (IBM): 사용자 기능 관점
언어 독립적 규모 측정
      |
      v
[COCOMO (1981)]
Boehm: 통계적 매개변수 모델
규모별 계수 체계화
      |
      v
[COCOMO II (2000)]
객체지향, 재사용 반영
17개 비용 유발 요소
      |
      v
[애자일 추정 (2001~)]
스토리 포인트, 플래닝 포커
속도 기반 적응 계획
      |
      v
[현재: AI 지원 산정]
과거 프로젝트 ML 학습
자동 FP 계산 도구

👶 어린이를 위한 3줄 비유 설명

  1. 비용 산정은 집 짓기 전 견적 — 방 수, 창문 수를 세어서(FP) 인부가 얼마나 필요한지(공수) 미리 계산해요!
  2. COCOMO는 벽돌 수 공식 — 벽돌 수(LOC)가 2배가 되면 인부 수도 딱 2배가 아니라 조금 더 많이 필요. 팀이 커지면 소통 비용도 늘어나니까요!
  3. 애자일은 상대적 크기로 — "이 기능이 저 기능의 두 배 어렵다"고 비교하면서 점점 정확한 계획을 만들어가요!