개발 표준·프로세스 평가·테일러링·프레임워크 선정
개발 표준·프로세스 평가·테일러링·프레임워크를 구분한다. 전통적인 CMMI와 SPICE 단계는 판본을 명확히 하여 읽고, 프로젝트 특성에 맞는 조정과 재사용 가능한 프레임워크의 IoC를 이해한다.
핵심 요약
개발 표준은 조직이 일관되게 개발하기 위한 공통 기준이고, 프로세스 평가는 개발 과정의 수행 능력과 개선 수준을 확인하는 활동이다. 테일러링은 공통 방법론을 프로젝트 특성에 맞게 조정하는 것이며, 프레임워크는 애플리케이션 개발에 재사용할 수 있는 구조와 공통 기능을 제공한다.
이 네 개념을 ‘개발 도구의 종류’로 한꺼번에 분류하면 안 된다. 표준·평가는 과정의 기준과 수준, 테일러링은 그 기준의 적용 방법, 프레임워크는 구현에 사용할 공통 구조와 관련된다.
1. 소프트웨어 개발 표준
개발 표준에는 절차, 역할, 산출물, 검토 기준, 문서 형식, 코딩 규칙, 시험·형상관리 방식 등이 포함될 수 있다. 표준을 사용하면 협업의 일관성과 추적성이 높아지지만, 모든 프로젝트에 같은 문서 분량과 작업 순서를 강제로 적용해야 한다는 뜻은 아니다.
ISO/IEC 12207은 소프트웨어 생명주기 프로세스와 관련된 국제 표준이다. 특정 프로그래밍 언어, 폭포수 모델, 제품을 사용하도록 강제하는 규격이 아니다.
고전적 분류를 묻는 문제에서는 다음 세 묶음을 구분한다.
| 전통적 분류 | 대표 프로세스 |
|---|---|
| 기본 생명주기 프로세스 | 획득, 공급, 개발, 운영, 유지보수 |
| 지원 생명주기 프로세스 | 문서화, 형상관리, 품질보증, 검증, 확인, 공동검토, 감사, 문제해결 |
| 조직 생명주기 프로세스 | 관리, 기반구조, 개선, 교육·훈련 |
이는 구판의 전통적 분류다. 개정판의 프로세스 그룹과 무조건 같은 것으로 외우지 않는다. 표준의 목적, 문제에서 제시한 판본과 분류 기준을 먼저 확인한다.
2. CMMI와 성숙도
CMMI(Capability Maturity Model Integration)는 조직의 프로세스 능력과 성과를 개선하기 위한 모델이다. 좋은 개발 결과가 특정 개인의 능력에만 의존하는지, 조직의 표준과 측정·개선 체계로 반복 가능하게 관리되는지를 살펴본다.
전통적인 단계적 표현의 성숙도 1~5는 다음과 같다.
| 수준 | 이름 | 핵심 특징 |
|---|---|---|
| 1 | 초기(Initial) | 작업이 임기응변적이고 개인의 역량에 크게 의존 |
| 2 | 관리(Managed) | 프로젝트 수준에서 계획·수행·측정을 관리 |
| 3 | 정의(Defined) | 조직의 표준 프로세스를 정의하고 프로젝트에 적용 |
| 4 | 정량적 관리(Quantitatively Managed) | 통계·정량적 기법으로 성과를 관리 |
| 5 | 최적화(Optimizing) | 원인을 분석하고 지속적으로 프로세스를 개선 |
‘프로젝트별 관리’와 ‘조직 차원의 표준화’, ‘정량적 통제’와 ‘지속적 개선’을 구분한다. 구형 CMM의 2단계 반복(Repeatable)을 CMMI의 단계명과 혼합하지 않는다. 다른 판본의 0단계나 개별 영역의 능력 수준이 제시되면 전통적 1~5 성숙도와 별도로 읽는다.
3. SPICE와 프로세스 능력
SPICE는 소프트웨어 프로세스의 개선과 능력 평가에 관련된 체계로, 전통적으로 ISO/IEC 15504와 연결된다. 프로세스가 무엇을 하는가를 보는 프로세스 차원과 얼마나 체계적으로 수행하는가를 보는 능력 차원을 구분한다.
| 전통적 능력 수준 | 이름 | 의미 |
|---|---|---|
| 0 | 불완전·미완성(Incomplete) | 프로세스가 구현되지 않았거나 목적을 달성하지 못함 |
| 1 | 수행(Performed) | 프로세스 목적을 달성 |
| 2 | 관리(Managed) | 수행과 작업 산출물을 계획·감시·관리 |
| 3 | 확립(Established) | 정의된 프로세스로 일관되게 수행 |
| 4 | 예측(Predictable) | 정해진 한계 안에서 정량적으로 수행·통제 |
| 5 | 최적화(Optimizing) | 현재와 미래의 목표를 위해 지속적으로 개선 |
위 표는 전통적 SPICE 분류다. 후속 ISO/IEC 330xx 체계에서 사용하는 세부 속성·용어와 혼용하지 않는다. 예를 들어 후속 분류의 5단계 ‘혁신’이라는 이름을 구판 문제의 단계명에 무조건 대입하면 안 된다.
CMMI 성숙도와 SPICE 능력 수준은 숫자가 비슷해도 평가 대상과 의미가 완전히 같지는 않다. 특히 ‘조직이 어느 정도 성숙했는가’와 ‘특정 프로세스를 어느 수준으로 수행하는가’를 구별한다.
4. 테일러링
테일러링(Tailoring)은 조직의 표준 방법론에서 프로젝트에 필요한 절차·활동·역할·산출물·도구를 선택하고 조정하는 것이다. 불필요한 작업을 줄일 수 있지만 필수 품질·보안·계약 조건을 무단으로 삭제하는 활동은 아니다.
| 고려 기준 | 확인할 내용 |
|---|---|
| 규모와 복잡도 | 작업량, 팀 수, 외부 연계 정도 |
| 요구와 일정 | 요구의 안정성, 변경 빈도, 납기와 인도 방식 |
| 기술 | 신규 기술, 도구·플랫폼의 제약, 재사용 가능성 |
| 인력과 조직 | 경험, 역할, 협업 방식, 외주 여부 |
| 위험과 품질 | 실패 영향, 보안·안전·신뢰성 요구 |
| 외부 조건 | 법·규정, 계약, 고객의 승인·문서 요구 |
기본 흐름은 프로젝트 특성 분석 → 표준 방법론과 차이 확인 → 조정 대상 결정 → 검토·승인 → 적용 → 결과 평가와 개선이다.
작은 내부 업무 도구에서는 중복 문서를 통합할 수 있다. 반면 금융 거래처럼 오류 영향이 큰 시스템에서는 보안 검토와 검증 활동을 오히려 강화해야 한다. ‘작은 프로젝트이므로 시험은 생략한다’는 설명은 테일러링을 잘못 적용한 것이다.
테일러링은 생산성을 높이는 관리적 목적과 기술 환경에 맞는 도구·기법을 적용하는 기술적 목적을 함께 갖는다.
5. 개발 프레임워크 선정
프레임워크는 개발에 필요한 기본 구조와 공통 기능을 제공하는 재사용 가능한 틀이다. 업무별 코드는 이 틀에 맞추어 확장한다. 대표 특성은 모듈화·재사용성·확장성·제어의 역전(IoC)이다.
| 비교 | 라이브러리 | 프레임워크 |
|---|---|---|
| 주요 제공 내용 | 특정 기능의 재사용 코드 | 애플리케이션 구조와 실행 흐름의 공통 틀 |
| 호출·제어의 중심 | 응용 코드가 필요한 기능을 호출 | 프레임워크가 정해진 지점에서 응용 코드를 호출할 수 있음 |
| 적용 범위 | 기능 단위인 경우가 많음 | 구조·생명주기·확장 규칙까지 포함 가능 |
제어의 역전은 개발자가 코드를 전혀 실행하지 못한다는 뜻이 아니다. 전체 흐름의 일부를 프레임워크가 관리하고 사용자 코드를 호출한다는 관계가 핵심이다.
선정할 때는 필요한 기능, 기존 기술과의 호환성, 성능·보안, 확장성과 유지보수성, 개발자의 숙련도, 문서·지원, 라이선스·도입 비용을 비교한다. 유행하거나 사용자가 많다는 사실 하나로 최적 후보를 결정하지 않는다. 또한 공통 기능을 제공해도 응용 업무의 요구 분석·시험 책임은 남는다.
프레임워크의 필수 조건과 확장
프레임워크 선정은 필수 조건과 선호 조건을 분리한다. 필수 런타임이나 라이선스 조건을 충족하지 못한 후보를 다른 장점의 점수만으로 선택해서는 안 된다. 공개 확장점으로 기능을 추가하면 내부 코드를 직접 수정하는 것보다 업그레이드 시 충돌을 줄이는 데 도움이 된다. 다만 확장점 사용만으로 호환성 시험이 불필요해지는 것은 아니다.