소프트웨어 공학 100 주제 시리즈의 72번째 글이다. (카테고리: 프로젝트 관리와 추정)

한 줄 요약

COCOMO II 는 규모(KSLOC 또는 기능 점수)를 입력받아 노력(인-월)과 기간(개월)을 내는 파라미터 모형이다. 핵심은 공식 자체보다 두 가지 구조에 있다. 규모가 커질수록 노력이 규모보다 빨리 늘어나는 규모의 비경제, 그리고 사람·제품·플랫폼 특성을 곱으로 반영하는 비용 동인이다.

왜 필요한가

전문가 판단은 빠르지만 근거를 설명하기 어렵다. “왜 8개월입니까?” 라는 질문에 “경험상” 으로 답하면 협상은 목소리 큰 쪽으로 기운다. 파라미터 모형은 추정을 입력과 가정의 목록으로 바꾼다. 그러면 논쟁의 대상이 숫자에서 가정으로 옮겨 간다. “팀의 분석 역량을 ‘높음’ 으로 본 근거가 뭡니까?” 처럼 말이다.

또 하나의 쓸모는 민감도 분석이다. “일정을 25% 당기면 노력이 얼마나 느는가”, “숙련도 높은 사람을 넣으면 얼마나 줄어드는가” 같은 질문에 일관된 답을 준다.

핵심 개념

계보

COCOMO 는 Barry Boehm 이 Software Engineering Economics(Prentice Hall, 1981)에서 발표한 모형이다. COCOMO II 는 이를 반복적 개발, 재사용, COTS 같은 새 개발 방식에 맞게 다시 만든 것이다. 아래 내용은 USC 소프트웨어공학센터의 COCOMO II Model Definition Manual v2.1(1995–2000, 원 사이트가 현재 응답하지 않아 인터넷 아카이브 사본을 링크)을 기준으로 한다. 책으로는 Boehm 외, Software Cost Estimation with COCOMO II(Prentice Hall, 2000)가 있다.

매뉴얼은 두 가지 모형을 정의한다.

모형 쓰는 시점 노력 승수(EM) 개수
Early Design 아키텍처 대안을 탐색하는 초기 7개(SCED 포함)
Post-Architecture 생애주기 아키텍처가 정해진 뒤 17개(SCED 포함)

노력과 기간 공식

매뉴얼의 식 1·2·14 를 정리하면 다음과 같다.

\[PM = A \times Size^{E} \times \prod_{i} EM_i, \quad E = B + 0.01 \sum_{j=1}^{5} SF_j\] \[TDEV = C \times PM_{NS}^{\,D + 0.2(E - B)} \times \frac{SCED\%}{100}\]

COCOMO II.2000 보정값은 A = 2.94, B = 0.91, C = 3.67, D = 0.28 이다. 매뉴얼에 따르면 이 값들은 COCOMO II 데이터베이스의 161개 프로젝트에 보정해 얻었다. Size 는 KSLOC(천 단위 논리 소스 줄)이고, 기능 점수로 입력하면 언어별 환산표로 SLOC 로 바꾼다(SE100 #073 에서 다룬다). PM_NS 는 일정 압축 승수 SCED 를 뺀 공칭 노력이다.

매뉴얼의 예제는 이렇다. 평균적인 100 KSLOC 프로젝트에서 E = 1.15, 모든 EM = 1.0 이라고 두면 노력은 2.94 × 100^1.15 ≈ 586.6 PM, 기간은 약 29.7개월, 평균 인원은 약 20명이다.

규모 인자(Scale Factors) — 지수를 바꾸는 다섯 가지

지수 E 가 1보다 크면 규모를 두 배로 늘릴 때 노력은 두 배보다 더 는다. 매뉴얼은 그 원인으로 사람 사이 의사소통 오버헤드와 대규모 통합 오버헤드를 든다(SE100 #003 의 Brooks 와 같은 이야기다).

인자 뜻 Very Low Nominal Extra High
PREC 선례성(비슷한 걸 해 봤나) 6.20 3.72 0.00
FLEX 개발 유연성 5.07 3.04 0.00
RESL 아키텍처·위험 해소 정도 7.07 4.24 0.00
TEAM 팀 응집도 5.48 3.29 0.00
PMAT 프로세스 성숙도(CMM 기반) 7.80 4.68 0.00

다섯 개가 모두 Extra High 면 E = 0.91, 모두 Very Low 면 ΣSF = 31.6 이라 E = 1.226 이다. 매뉴얼은 100 KSLOC 기준으로 이 차이가 194 PM 대 832 PM 이라고 계산해 보여 준다. RESL(위험을 얼마나 해소했나)이 들어 있다는 점이 흥미롭다. 위험 관리(SE100 #075)가 비용 모형 안에 지수로 들어가 있다는 뜻이다.

노력 승수(Effort Multipliers) — 곱으로 붙는 비용 동인

Post-Architecture 모형의 승수 중 몇 개만 보자(매뉴얼 Table 62).

동인 Very Low Nominal Very High
RELY 요구 신뢰성 0.82 1.00 1.26
CPLX 제품 복잡도 0.73 1.00 1.34 (Extra High 1.74)
ACAP 분석가 역량 1.42 1.00 0.71
PCAP 프로그래머 역량 1.34 1.00 0.76
TOOL 도구 사용 1.17 1.00 0.78
SCED 요구 일정 1.43 (75%) 1.00 (100%) 1.00 (160%)

SCED 행이 중요하다. 공칭 일정의 75% 로 압축하면 노력이 1.43배가 된다. 반대로 일정을 늘린다고(130%, 160%) 노력이 줄지는 않는다. 매뉴얼은 작은 팀으로 얻는 절감이 관리 기능을 오래 유지하는 비용과 대체로 상쇄되기 때문이라고 설명한다.

예제

공식을 그대로 코드로 옮겨 보자. 규모 인자는 모두 Nominal 로 둔다.

# COCOMO II.2000 Post-Architecture 공칭 일정(nominal-schedule) 계산
# 상수와 표 값은 COCOMO II Model Definition Manual v2.1 의 Table 62 에서 옮겼다.
A, B, C, D = 2.94, 0.91, 3.67, 0.28
SF_NOMINAL = {"PREC": 3.72, "FLEX": 3.04, "RESL": 4.24, "TEAM": 3.29, "PMAT": 4.68}

def cocomo(ksloc, sf, em_product=1.0, sced=1.0, sced_pct=100):
    E = B + 0.01 * sum(sf.values())
    pm_ns = A * ksloc ** E * em_product            # SCED 제외 공칭 노력
    pm = pm_ns * sced                                # SCED 반영 노력
    F = D + 0.2 * (E - B)
    tdev = C * pm_ns ** F * sced_pct / 100           # Eq. 14
    return E, pm, tdev

for size in (10, 50, 100, 200):
    E, pm, t = cocomo(size, SF_NOMINAL)
    print(f"{size:4d} KSLOC  E={E:.4f}  PM={pm:7.1f}  TDEV={t:5.1f}개월  평균인원={pm/t:5.1f}")

print("--- 100 KSLOC, 일정 75% 로 압축(SCED Very Low=1.43) ---")
E, pm, t = cocomo(100, SF_NOMINAL, sced=1.43, sced_pct=75)
print(f"PM={pm:7.1f}  TDEV={t:5.1f}개월  평균인원={pm/t:5.1f}")
print("--- 100 KSLOC, ACAP·PCAP Very High(0.71×0.76) ---")
E, pm, t = cocomo(100, SF_NOMINAL, em_product=0.71*0.76)
print(f"PM={pm:7.1f}  TDEV={t:5.1f}개월")

실행 결과:

  10 KSLOC  E=1.0997  PM=   37.0  TDEV= 11.6개월  평균인원=  3.2
  50 KSLOC  E=1.0997  PM=  217.1  TDEV= 20.3개월  평균인원= 10.7
 100 KSLOC  E=1.0997  PM=  465.3  TDEV= 25.9개월  평균인원= 18.0
 200 KSLOC  E=1.0997  PM=  997.2  TDEV= 33.0개월  평균인원= 30.2
--- 100 KSLOC, 일정 75% 로 압축(SCED Very Low=1.43) ---
PM=  665.4  TDEV= 19.4개월  평균인원= 34.3
--- 100 KSLOC, ACAP·PCAP Very High(0.71×0.76) ---
PM=  251.1  TDEV= 21.3개월

읽을 거리:

  1. 규모의 비경제. 100 → 200 KSLOC 로 두 배가 되면 노력은 465 → 997 PM 으로 2.14배가 된다.
  2. 기간은 노력보다 훨씬 느리게 는다. 노력이 약 27배(37 → 997) 늘 때 기간은 약 2.8배(11.6 → 33.0)만 는다. 기간은 사람을 더 넣는다고 비례해서 줄지 않는다.
  3. 일정 압축은 비싸다. 기간을 25.9 → 19.4개월로 당기면 노력은 465 → 665 PM 으로 늘고, 평균 인원은 18명에서 34명으로 거의 두 배가 된다.
  4. 사람의 역량이 가장 큰 손잡이 중 하나다. 분석가·프로그래머 역량 두 동인만으로 노력이 절반 가까이 줄어든다. 숫자보다 “채용과 유지가 비용 모형의 1급 변수” 라는 점이 중요하다.

실무 적용

지역 보정이 먼저다

매뉴얼은 7장에서 최소한 A(와 C)는 자기 조직 데이터로 보정하라고 권한다. A 만 보정해도 모형이 훨씬 정확해졌다는 연구 결과를 근거로 든다. 보정 절차는 간단하다.

import math
# (KSLOC, 실제 PM, EM 곱, E) — 완료된 자기 조직 프로젝트 기록 (예시)
history = [(12, 50, 1.0, 1.10), (30, 140, 0.9, 1.10), (8, 30, 1.1, 1.10)]
# 로그 공간에서 A 를 맞춘다: ln(PM) = ln(A) + E·ln(Size) + ln(ΠEM)
lnA = sum(math.log(pm) - e * math.log(s) - math.log(em) for s, pm, em, e in history) / len(history)
print(f"보정된 A = {math.exp(lnA):.2f}  (기본값 2.94)")

예시 기록으로 돌리면 보정된 A = 3.21 이 나온다. 이 조직은 기본 모형보다 약 9% 더 노력이 드는 환경이라는 뜻이다.

체크리스트

  • 규모 추정은 범위로(최소·최빈·최대) 넣고, 모형도 세 번 돌린다.
  • 각 규모 인자·승수 등급에 근거 한 줄을 적는다. 이것이 추정 문서의 본체다.
  • 결과를 전문가 추정이나 유사 프로젝트 비교와 나란히 놓는다. 크게 다르면 어느 가정이 다른지 찾는다.
  • 프로젝트가 끝나면 실제 PM 을 기록해 다음 보정에 쓴다.

흔한 오해와 함정

  • “공식이 있으니 정확하다.” 입력인 규모부터 원뿔(SE100 #071)의 영향을 받는다. 규모가 2배 틀리면 노력은 2배보다 더 틀린다(E > 1).
  • “SLOC 가 생산성 지표다.” 매뉴얼은 SLOC 를 ‘논리적 소스 문장’ 으로 엄격히 정의하고, 자동 생성 코드나 COTS 는 별도로 다룬다. 정의 없이 wc -l 로 센 숫자를 넣으면 모형이 무의미해진다.
  • “일정을 늘리면 비용이 준다.” SCED 표에서 늘린 일정의 승수는 1.00 이다. 압축만 비용을 올린다.
  • “보정 없이 써도 된다.” 기본 상수는 특정 데이터베이스의 평균이다. 매뉴얼 스스로 지역 보정을 권장한다.
  • “현대 개발에는 안 맞는다.” 숫자는 낡았을 수 있다. 그래도 규모의 비경제, 일정 압축 비용, 사람 역량의 영향이라는 구조는 그대로 유효하다. 숫자 대신 구조를 가져다 쓰면 된다.

확인 문제

  1. COCOMO II 의 지수 E 가 1보다 크다는 것은 무엇을 뜻하며, 매뉴얼이 드는 원인 두 가지는?
  2. 규모 인자 다섯 개를 쓰고, 그중 위험 관리와 직접 관련된 것을 고르라.
  3. SCED 를 Very Low(75%)로 두면 노력과 기간은 각각 어떻게 변하는가?
  4. 일정을 160% 로 늘려도 노력 승수가 1.00 인 이유를 매뉴얼은 어떻게 설명하는가?
  5. 조직이 COCOMO II 를 도입할 때 가장 먼저 보정하라고 권하는 상수는?

풀이

  1. 규모의 비경제다. 규모를 두 배로 늘리면 노력이 두 배보다 더 는다. 원인은 사람 사이 의사소통 경로 증가와 대규모 시스템 통합 오버헤드다.
  2. PREC, FLEX, RESL, TEAM, PMAT. 위험 관리와 직접 관련된 것은 RESL(아키텍처·위험 해소)이다.
  3. 노력은 1.43배로 늘고, 기간은 공칭 기간의 75% 가 된다. 결과적으로 평균 인원이 크게 는다.
  4. 작은 팀으로 얻는 절감이 관리 기능을 더 오래 유지해야 하는 비용과 대체로 상쇄되기 때문이다.
  5. A(와 C). 자기 조직의 완료 프로젝트 데이터로 맞춘다.

더 읽을거리 (References)