CMMI와의 비교
30.5.1. CMMI 개요
CMMI(Capability Maturity Model Integration, 능력 성숙도 통합 모델)는 조직의 프로세스 성숙도를 평가하고 개선하기 위한 프레임워크입니다. 카네기멜론대학교 소프트웨어공학연구소(SEI)에서 개발하였으며, 현재는 ISACA 산하의 CMMI Institute가 운영하고 있습니다.
CMMI는 원래 미국 국방부의 소프트웨어 개발 프로젝트 품질 관리를 위해 탄생한 CMM(Capability Maturity Model)에서 발전한 것입니다. 2002년 CMMI V1.1이 발표되었고, 2018년에 CMMI V2.0으로 대폭 개정되었습니다. CMMI V2.0은 기존 버전 대비 구조가 간소화되고, 성과 중심의 평가 방식이 강화되었습니다.
CMMI는 주로 대규모 소프트웨어 개발 조직, SI(시스템 통합) 기업, 국방/항공우주 분야에서 널리 채택되고 있습니다. 국내에서는 대형 SI 기업이나 공공 프로젝트 수주를 위해 CMMI 레벨 3 이상을 요구받는 경우가 있습니다.
CMMI의 핵심 특징은 조직의 프로세스 역량을 단계별로 평가하는 "성숙도 모델"에 있습니다. 조직이 어느 수준에 있는지를 객관적으로 진단하고, 다음 수준으로 올라가기 위해 어떤 프로세스를 개선해야 하는지를 제시합니다.
30.5.2. 성숙도 5단계
CMMI는 조직의 프로세스 성숙도를 5단계로 구분합니다.
| 레벨 | 명칭 | 설명 | 핵심 특징 |
|---|---|---|---|
| 1 | 초기 (Initial) | 프로세스가 정의되어 있지 않은 상태. 개인의 역량에 의존 | 예측 불가능, 반응적 대응, 일관성 없음 |
| 2 | 관리 (Managed) | 프로젝트 수준에서 기본 프로세스가 정의되고 관리되는 상태 | 프로젝트 계획, 요구사항 관리, 형상 관리, 품질 보증 |
| 3 | 정의 (Defined) | 조직 수준에서 표준 프로세스가 정의되고 모든 프로젝트에 적용되는 상태 | 조직 표준 프로세스, 교육 훈련, 의사결정 분석 |
| 4 | 정량적 관리 (Quantitatively Managed) | 프로세스 성과를 정량적으로 측정하고 통제하는 상태 | 통계적 프로세스 제어, 정량적 프로젝트 관리 |
| 5 | 최적화 (Optimizing) | 지속적인 프로세스 개선이 조직 문화로 정착된 상태 | 근본 원인 분석, 지속적 개선, 혁신 |
각 레벨은 이전 레벨의 프로세스를 포함합니다. 레벨 3을 달성하려면 레벨 2의 모든 프로세스를 충족한 상태여야 합니다. 대부분의 조직은 레벨 3 달성을 목표로 하며, 레벨 4와 5에 도달하는 조직은 전 세계적으로도 소수입니다.
30.5.2.1. 레벨별 소요 기간 및 비용
CMMI 평가에 소요되는 기간과 비용은 목표 레벨에 따라 크게 달라집니다.
| 목표 레벨 | 준비 기간 | 평가 비용 | 비고 |
|---|---|---|---|
| 레벨 2 | 6~12개월 | 수천만 원 | 기본 프로세스 정의 및 적용 |
| 레벨 3 | 12~24개월 | 수억 원 | 조직 표준 프로세스 수립 필요 |
| 레벨 4 | 24~36개월 | 수억 원 이상 | 정량적 관리 체계 구축 필요 |
| 레벨 5 | 36개월 이상 | 수억 원 이상 | 지속적 개선 문화 정착 필요 |
준비 기간에는 프로세스 정의, 교육, 파일럿 적용, 내부 평가 등이 포함됩니다. 외부 컨설팅을 활용하는 경우 컨설팅 비용이 추가로 발생합니다.
30.5.3. 프로세스 영역
CMMI V2.0은 프로세스 영역(Practice Area)을 4개 카테고리로 분류합니다.
30.5.3.1. 카테고리 구성
| 카테고리 | 프로세스 영역 수 | 주요 내용 |
|---|---|---|
| Doing (수행) | 7개 | 제품/서비스의 개발 및 제공과 직접 관련된 프로세스 |
| Managing (관리) | 6개 | 프로젝트와 작업의 계획 및 관리 프로세스 |
| Enabling (지원) | 5개 | 수행과 관리를 지원하는 기반 프로세스 |
| Improving (개선) | 2개 | 프로세스 성과 개선 프로세스 |
30.5.3.2. 주요 프로세스 영역
| 프로세스 영역 | 카테고리 | 설명 |
|---|---|---|
| 요구사항 개발 및 관리 (RDM) | Doing | 제품 요구사항의 도출, 분석, 검증, 관리 |
| 기술 솔루션 (TS) | Doing | 설계, 구현, 단위 테스트 |
| 제품 통합 (PI) | Doing | 컴포넌트 통합, 통합 테스트 |
| 검증 및 확인 (VV) | Doing | 제품의 검증(기술 요구사항 충족)과 확인(사용자 요구사항 충족) |
| 프로젝트 계획 (PLAN) | Managing | 프로젝트 계획 수립, 자원/일정 산정 |
| 프로젝트 모니터링 및 통제 (MC) | Managing | 계획 대비 진척 모니터링, 시정조치 |
| 형상 관리 (CM) | Enabling | 작업 산출물의 무결성 유지, 변경 통제 |
| 프로세스 품질 보증 (PQA) | Enabling | 프로세스 및 산출물의 품질 보증 |
| 프로세스 관리 (PCM) | Improving | 조직 프로세스의 정의, 배포, 개선 |
| 성과 개선 관리 (PIM) | Improving | 프로세스 성과의 정량적 분석 및 개선 |
30.5.3.3. 평가 방법 (SCAMPI)
CMMI 성숙도 레벨 평가는 SCAMPI(Standard CMMI Appraisal Method for Process Improvement)라는 공식 평가 방법을 사용합니다.
| 유형 | 명칭 | 용도 | 소요 기간 |
|---|---|---|---|
| SCAMPI A | 공식 평가 | 공식 성숙도 레벨 부여, 외부 공개용 | 1~2주 (현장 평가) |
| SCAMPI B | 중간 평가 | 공식 평가 준비 상태 점검, 내부 진단용 | 3~5일 |
| SCAMPI C | 간이 평가 | 초기 진단, 개선 계획 수립용 | 1~2일 |
SCAMPI A 평가는 CMMI Institute에서 인증한 수석 평가사(Lead Appraiser)가 수행합니다. 평가팀은 조직의 프로세스 문서, 프로젝트 산출물, 직원 인터뷰를 통해 각 프로세스 영역의 이행 수준을 판정합니다.
30.5.4. TQS와의 비교 분석
다음 표는 CMMI와 TQS를 핵심 비교 축에 따라 정리한 것입니다.
| 비교 축 | CMMI | TQS |
|---|---|---|
| 인증 목적 | 조직 프로세스 성숙도 평가 및 개선 | 코드 수준 기술 품질 검증 |
| 검증 대상 | 조직의 프로세스 (요구사항 관리, 형상 관리, 품질 보증 등) | 프로젝트의 소스코드, 빌드 설정, CI/CD 파이프라인 |
| 검증 수준 | 프로세스 수준 ("프로세스가 정의되고 운영되는가") | 코드 수준 ("코드가 기준을 충족하는가") |
| 성숙도 모델 | 5단계 (초기→관리→정의→정량적 관리→최적화) | 5단계 (TQS 자체 성숙도 모델) |
| 성숙도 초점 | 프로세스 역량 성숙도 | 기술 구현 성숙도 |
| 심사 방법 | SCAMPI 평가 (문서 심사 + 인터뷰 + 현장 평가) | 자동화 검증 + 코드 리뷰 |
| 형상 관리 검증 | "형상 관리 프로세스가 정의되어 있는가" | "GitHub Flow가 적용되고, Conventional Commits를 사용하는가" |
| 품질 보증 검증 | "품질 보증 프로세스가 수행되고 있는가" | "테스트 커버리지 80% 이상, ESLint 통과, 빌드 성공" |
| 검증 주기 | 3년 (SCAMPI A 평가) | 커밋마다 (CI/CD 자동 검증) |
| 인증 비용 | 고비용 (수억 원 규모) | 무료 (자체 내부 인증) |
| 소요 기간 | 12~36개월 (준비 + 평가) | 1~2주 (심사) |
| 인증 기관 | CMMI Institute (ISACA 산하) | 티에니피아 기술표준위원회 |
| 대상 조직 | 대규모 소프트웨어 개발 조직 | 모든 규모의 프로젝트 팀 |
30.5.4.1. 프로세스 성숙도 vs 기술 성숙도
CMMI와 TQS의 가장 근본적인 차이는 "성숙도"가 의미하는 바에 있습니다.
CMMI는 조직이 소프트웨어를 개발하는 프로세스가 얼마나 성숙한지를 평가합니다. "요구사항 관리 프로세스가 정의되어 있는가", "형상 관리 절차가 모든 프로젝트에 일관되게 적용되고 있는가", "프로세스 성과를 정량적으로 측정하고 있는가"와 같은 질문에 답합니다.
TQS는 조직이 만든 소프트웨어의 기술적 구현이 얼마나 성숙한지를 검증합니다. "코드 포매팅이 일관되게 적용되고 있는가", "테스트 커버리지가 충분한가", "보안 설정이 올바르게 구현되어 있는가"와 같은 질문에 답합니다.
비유하자면, CMMI는 "공장의 생산 공정이 얼마나 잘 정비되어 있는가"를 검사하고, TQS는 "공장에서 나온 제품의 품질이 기준을 충족하는가"를 검사합니다.
30.5.4.2. 비용 및 기간의 차이
CMMI 평가는 준비부터 공식 평가까지 최소 12개월 이상이 소요되며, 외부 컨설팅과 평가 비용을 포함하면 수억 원의 비용이 발생합니다. 이는 CMMI가 조직 전체의 프로세스를 대상으로 하기 때문입니다.
TQS는 프로젝트 단위로 인증을 부여하며, CI/CD 파이프라인에 이미 자동화 검증이 통합되어 있으므로 심사 기간이 1~2주에 불과합니다. 별도의 인증 비용도 발생하지 않습니다.
30.5.5. TQS 성숙도 모델과의 관계
TQS도 5단계 성숙도 모델을 운영합니다. CMMI의 성숙도 모델이 프로세스 역량을 기준으로 한다면, TQS의 성숙도 모델은 기술 구현 역량을 기준으로 합니다.
30.5.5.1. CMMI와 TQS 성숙도 단계 매핑
| 단계 | CMMI 성숙도 | CMMI 초점 | TQS 성숙도 | TQS 초점 |
|---|---|---|---|---|
| 1 | 초기 (Initial) | 프로세스 미정의, 개인 역량 의존 | 초기 | 코드 컨벤션 미적용, 테스트 없음 |
| 2 | 관리 (Managed) | 프로젝트 기본 프로세스 정의 | 기초 | 포매터 적용, 기본 테스트 존재 |
| 3 | 정의 (Defined) | 조직 표준 프로세스 정의 및 적용 | 표준 | TQS 필수 항목 전체 충족, CI/CD 통합 |
| 4 | 정량적 관리 (Quantitatively Managed) | 프로세스 성과 정량적 측정 | 고도화 | 커버리지 90% 이상, 성능 최적화, 보안 강화 |
| 5 | 최적화 (Optimizing) | 지속적 프로세스 개선 문화 정착 | 최적화 | 자동화 리포팅, 품질 추이 분석, 선제적 개선 |
30.5.5.2. 두 모델의 보완적 적용
CMMI 성숙도와 TQS 성숙도는 서로 독립적이지만 보완적입니다.
- CMMI 레벨 3 조직이라도 TQS 성숙도가 낮을 수 있습니다. 프로세스는 잘 정의되어 있으나 실제 코드 품질이 기준을 충족하지 못하는 상태입니다.
- 반대로 TQS 성숙도가 높은 프로젝트라도 CMMI 레벨이 낮을 수 있습니다. 코드 품질은 우수하나 조직 차원의 프로세스 표준화가 이루어지지 않은 상태입니다.
이상적인 조직은 CMMI 성숙도(프로세스 역량)와 TQS 성숙도(기술 구현 역량)를 함께 높여가는 것입니다. CMMI로 "어떻게 일하는가"를 표준화하고, TQS로 "일의 결과물이 기준을 충족하는가"를 검증하는 양방향 품질 관리가 가장 효과적입니다.
30.5.5.3. 적용 시나리오
CMMI와 TQS를 함께 적용하는 것이 효과적인 시나리오는 다음과 같습니다.
- 대규모 SI 프로젝트: CMMI 레벨 3 이상을 요구하는 공공/국방 프로젝트에서, CMMI로 프로세스 역량을 증명하고 TQS로 산출물 품질을 보증합니다.
- 다수 프로젝트 운영 조직: CMMI로 조직 표준 프로세스를 정의하고, 각 프로젝트에 TQS를 적용하여 프로젝트별 코드 품질을 일관되게 관리합니다.
- 프로세스 개선 추진 조직: CMMI 레벨 향상을 추진하면서, TQS를 통해 프로세스 개선의 실질적 효과(코드 품질 향상)를 정량적으로 측정합니다.
CMMI는 "조직이 성숙한 프로세스를 운영하는가"를 평가하고, TQS는 "성숙한 프로세스가 실제로 고품질 코드를 만들어내는가"를 검증합니다. 두 모델은 프로세스(원인)와 산출물(결과)이라는 인과관계의 양 끝을 각각 담당합니다.