COCOMO II와 COCOTS로 보는 현대 소프트웨어 비용 산정

코드량만으로는 설명하기 어려워진 개발 비용

객체지향 개발, 컴포넌트 기반 개발(CBD), 신속한 프로토타이핑이 일반화되면서 구조적 방법론 시대의 COCOMO 81만으로는 프로젝트 비용을 다루기 어려워졌다. 코드가 직접 작성되는 방식뿐 아니라 재사용, 자동 생성, 상용 컴포넌트 통합이 개발 범위에 포함되기 때문이다.

COCOMO II(Constructive Cost Model II)는 이런 환경을 고려해 발전한 소프트웨어 비용 산정 모델이다. 배리 보엠(Barry Boehm)이 제안했으며, 개발 생명주기의 위치에 따라 다른 산정 방식을 적용하는 상향식·하향식 혼합형 모델로 설계됐다.

COCOMO I(COCOMO 81)가 SLOC 중심의 정적 산정에 집중했다면, COCOMO II는 다음 환경 변화를 반영한다.

객체지향 기술 확산과 컴포넌트 재사용 비중 증가
4세대 언어(4GL) 및 CASE 툴 기반의 자동화된 코드 생성
나선형 모델(Spiral Model)과 같은 반복적 개발 프로세스
초기 단계의 불확실성을 고려한 단계별 모델링

규모를 판단할 때도 SLOC만 고집하지 않는다. 객체 점수(Object Points), 기능 점수(Function Points), SLOC를 개발 단계에 맞춰 활용하며, 개발이 진행될수록 산정 정확도를 높이는 구조다. COTS와 기존 코드의 재사용으로 줄어드는 비용 역시 산정 대상에 포함한다.

프로젝트 정보의 성숙도에 맞춰 산정하는 방식

COCOMO II는 프로젝트가 얼마나 구체화됐는지에 따라 응용 조합 모델, 초기 설계 모델, 설계 이후 모델을 사용한다.

프로토타입 단계의 응용 조합 모델

응용 조합 모델(Application Composition Model)은 프로젝트 초반이나 프로토타이핑, 4세대 언어를 활용한 신속 개발에 맞는다. 화면 수, 보고서 수, 모듈 수 등을 바탕으로 객체 점수를 산정 기준으로 삼는다.

상세 설계가 나오기 전에도 빠르게 비용을 예측해야 할 때 사용할 수 있다는 점이 이 모델의 역할이다.

아키텍처 초기에 사용하는 초기 설계 모델

초기 설계 모델(Early Design Model)은 소프트웨어 아키텍처 설계 초기에 적용한다. 기능 점수를 이용하거나, 기능 점수를 SLOC로 변환해 규모를 산정한다.

이 단계에서는 7개의 주요 비용 동인(Cost Drivers)을 반영해 프로젝트 제약과 개발팀 역량을 비용 산정에 포함한다.

상세 설계 이후의 정밀 산정

설계 이후 모델(Post-Architecture Model)은 상세 설계가 끝나고 구현이 진행되는 시점에 사용한다. SLOC 또는 정밀하게 보정된 기능 점수가 규모 기준이 된다.

17개의 상세 비용 동인과 5개의 규모 인자(Scale Factors)를 적용하므로, 세 모델 가운데 가장 정밀한 산정 결과를 제공한다.

규모와 보정 인자를 연결하는 산정 흐름

COCOMO II는 먼저 개발 단계에 맞는 규모 측정 기준을 고르고, 비용 동인과 규모 인자를 반영해 최종 노력도(Effort)를 계산한다. 산출된 노력도는 Person-Month 기준의 비용과 기간 결정으로 이어진다.

⤢✕

상용 컴포넌트 통합 비용을 다루는 COCOTS

CBD 프로젝트에서는 모든 기능을 자체 개발하지 않고, 검증된 상용 컴포넌트를 구매해 통합하는 경우가 많다. 이때 COCOMO II의 파생 모델인 COCOTS(Constructive COTS)를 활용할 수 있다.

COCOTS는 COTS(Commercial Off The Shelf) 컴포넌트를 시스템에 통합하는 데 필요한 노력과 비용을 산정한다. 자체 개발 영역은 COCOMO II로 계산하고, 컴포넌트 통합 과정의 접착 코드(Glue Code) 개발 및 튜닝 비용은 COCOTS로 다뤄 전체 비용을 구성한다.

상용 컴포넌트 적용 과정은 다음 활동으로 구분된다.

후보 평가 및 선정(Assessment): 요구사항에 맞는 상용 컴포넌트 후보를 조사하고, 기술적·비즈니스적 적합성을 평가해 선정한다.
맞춤 및 튜닝(Tailoring): 파라미터, 보안 설정, 기능을 프로젝트 환경에 맞게 조정한다.
접착 코드 생성(Glue Code): 상용 컴포넌트와 자체 개발 모듈 또는 다른 컴포넌트 사이의 데이터 인터페이스와 상호작용을 위한 통합 코드를 작성한다.
통합 테스트(Test): 조립된 컴포넌트가 시스템 안에서 정상 동작하는지, 성능 또는 보안 결함이 없는지 확인한다.
운영 및 유지보수(Operation): 배포 후 업데이트 대응과 장애 발생 시 벤더 협업을 포함한 관리 활동을 수행한다.

자체 개발과 통합 영역을 분리해 보는 이유

하이브리드 소프트웨어 프로젝트에서는 고유 비즈니스 로직을 만드는 비용과 외부 컴포넌트를 연결하는 비용의 성격이 다르다. 이를 하나의 개발비로 뭉뚱그리면 비용의 근거와 위험 요인이 흐려질 수 있다.

프로젝트 고유의 비즈니스 로직은 COCOMO II의 설계 이후 모델로 정밀하게 산정할 수 있다. 이미 시장에서 검증된 라이브러리나 솔루션을 도입하는 영역은 COCOTS로 통합 난이도와 접착 코드 분량을 산정한다.

이 구분은 고객사에 근거 기반의 수치 데이터를 제시해 예산 적정성을 설명하는 데 도움이 된다. 초기 설계 모델을 통한 리스크 식별과 인력 투입 계획 수립은 프로젝트 지연을 줄이는 데도 연결된다. 충분한 테스트 기간을 비용 산정에 반영하면 결과물의 소프트웨어 유연성과 품질을 확보하는 기반이 된다.

Sources

Boehm, B., et al. (2000). Software Cost Estimation with COCOMO II. Prentice Hall.
Center for Systems and Software Engineering (CSSE) at USC.
Software Engineering Institute (SEI), CMU.
정보관리기술사 전문 지식 덤프 및 기술 세미나 자료.