레슨 12: 소프트웨어 프로세스 개선(Software Process Improvement)
레슨 12: 소프트웨어 프로세스 개선(Software Process Improvement)¶
이전: 소프트웨어 유지보수와 진화 | 다음: DevOps와 CI/CD
모든 소프트웨어 조직에는 정의되었든 아니든 프로세스가 존재한다. 문제는 프로세스의 존재 여부가 아니라, 그것이 효과적이고 가시적이며 시간이 지남에 따라 개선되고 있는가이다. 소프트웨어 프로세스 개선(SPI, Software Process Improvement)은 소프트웨어가 어떻게 구축되고 운영되는지를 분석하고, 약점을 식별하며, 품질·속도·비용·팀 만족도 측면에서 더 나은 결과를 이끌어내는 목표 지향적 변화를 만드는 체계적인 실천이다.
난이도: ⭐⭐⭐
선수 학습: - 소프트웨어 개발 생명주기(레슨 02) - 애자일(Agile) 기초(레슨 03) - 소프트웨어 품질 보증 개념(레슨 07) - 기본 프로젝트 관리(레슨 10)
학습 목표: - 소프트웨어 프로세스 개선이 더 나은 결과를 가져오는 이유를 이해한다 - CMM/CMMI 성숙도 모델과 5단계 레벨을 설명한다 - ISO/IEC 12207 및 15504/33000 표준이 프로세스 평가에 어떻게 적용되는지 파악한다 - PSP와 TSP 규율을 개인 및 팀 수준의 개선에 적용한다 - Start/Stop/Continue, 4Ls, 피시본 형식을 활용하여 효과적인 회고를 진행한다 - 5 Why와 피시본 다이어그램을 사용하여 근본 원인 분석을 수행한다 - GQM 접근법을 이용하여 메트릭 기반 개선 프로그램을 설계한다 - 프로세스 조정(tailoring)과 표준 프레임워크의 전면 도입을 구별한다
1. 소프트웨어 프로세스를 개선하는 이유¶
1.1 나쁜 프로세스의 비용¶
소프트웨어 실패는 비용이 크다. 1990년대 IBM 연구에 따르면 운영 환경에서 발견된 결함은 요구사항 단계에서 발견된 결함보다 수정 비용이 100배에 달하며, 이후 연구들도 이 수치를 뒤집지 못했다. 프로세스 개선은 개별 결함이 아닌 결함을 만들어내는 시스템을 다룬다.
나쁜 프로세스는 다음과 같이 나타난다: - 요구사항이 잘못 이해되어 뒤늦게 발견됨 - 매번 병합할 때마다 빌드가 깨짐 - 배포 순서를 아는 영웅적인 엔지니어 한 명에게 의존하는 배포 - 조기 경보 없이 반복적으로 지연되는 릴리스 - 같은 유형의 실패에 대한 반복적인 사후 검토
1.2 체계적인 개선의 필요성¶
개인의 영웅적 노력은 확장되지 않는다. 뛰어난 엔지니어 한 명이 망가진 프로세스를 보완하는 팀은 취약하다 — 그 사람이 떠나면 팀 성과가 무너진다. 체계적인 프로세스 개선은 다음을 만들어낸다:
- 반복 가능성(Repeatability): 누가 일하느냐에 의존하지 않는 결과
- 예측 가능성(Predictability): 프로세스를 이해하기 때문에 신뢰할 수 있는 추정
- 학습 가능성(Learnability): 새 팀원이 더 빠르게 생산적으로 될 수 있음
- 가시성(Visibility): 문제가 수정 비용이 가장 낮을 때 조기에 드러남
1.3 프로세스 개선이 아닌 것¶
- 그 자체를 위한 관료주의가 아니다. 위험을 줄이지 않고 작업만 늘리는 프로세스는 제거해야 한다.
- 일회성 인증 활동이 아니다. 개선은 지속적이다.
- 애자일(또는 SAFe, DevOps) 도입과 동일하지 않다. 프레임워크는 도구이고, 개선은 사고방식이다.
2. CMM과 CMMI¶
2.1 능력 성숙도 모델(CMM, Capability Maturity Model)¶
능력 성숙도 모델(CMM)은 1980년대 후반 카네기멜런 대학교 소프트웨어 공학 연구소(SEI)에서 개발되었으며, 처음에는 미국 국방부가 소프트웨어 계약자를 평가하기 위한 방법으로 시작되었다. 조직이 소프트웨어 프로세스를 개선해 나가면서 거치는 다섯 가지 성숙도 수준을 설명한다.
| 레벨 | 명칭 | 특징 |
|---|---|---|
| 1 | 초기(Initial) | 혼돈적. 성공은 개인의 영웅적 노력에 달려 있다. 안정적인 프로세스 없음. |
| 2 | 반복 가능(Repeatable) | 기본 프로젝트 관리 수립. 유사한 프로젝트를 일관성 있게 관리 가능. 요구사항, 일정, 비용 추적 구축. |
| 3 | 정의됨(Defined) | 조직 전체의 표준 프로세스. 특정 프로젝트를 위한 조정 지침. 교육 프로그램. |
| 4 | 관리됨(Managed) | 프로세스 및 제품 품질 모두에 대한 정량적 성과 목표. 변동성을 이해하고 통제하기 위한 통계적 방법 사용. |
| 5 | 최적화(Optimizing) | 정량적 피드백을 통한 지속적 개선. 새로운 아이디어와 기술을 체계적인 방식으로 시범 적용. |
대부분의 상업용 소프트웨어 조직은 레벨 1 또는 2에서 운영된다. 레벨 3 달성은 프로세스 투자가 안정적으로 성과를 내는 임계점으로 간주된다. 레벨 4와 5는 상당한 통계적 프로세스 제어 인프라를 필요로 하며, 국방·항공우주·안전 중요 분야에서 주로 나타난다.
2.2 CMMI: 진화¶
CMMI(Capability Maturity Model Integration)는 2000년대 초 CMM을 대체했으며, 소프트웨어·시스템 공학·획득 등 여러 CMM을 단일 프레임워크로 통합했다. CMMI v2.0(2018년 출시)이 현재 버전이다.
CMMI의 두 가지 표현 방식:
| 표현 방식 | 초점 | 사용 사례 |
|---|---|---|
| 단계형(Staged) | 조직 전체의 성숙도 레벨 (1–5) | 벤치마킹, 계약, DoD 준수 |
| 연속형(Continuous) | 프로세스 영역별 역량 레벨 (0–3) | 목표 지향적 개선, 인증 불필요 |
주요 CMMI 프로세스 영역 (선별):
| 프로세스 영역 | 도메인 |
|---|---|
| 요구사항 관리(Requirements Management) | 요구사항 변경 관리 |
| 프로젝트 계획(Project Planning) | 프로젝트 계획 수립 |
| 프로젝트 모니터링 및 통제(Project Monitoring and Control) | 계획 대비 성과 추적 |
| 형상 관리(Configuration Management) | 작업 산출물 통제 |
| 프로세스 및 제품 품질 보증(Process and Product Quality Assurance) | 컴플라이언스 및 품질 감사 |
| 원인 분석 및 해결(Causal Analysis and Resolution) | 근본 원인 파악 및 예방 |
| 조직 프로세스 집중(Organizational Process Focus) | 프로세스 개선 계획 및 실행 |
| 정량적 프로젝트 관리(Quantitative Project Management) | 프로젝트 성과의 통계적 관리 |
2.3 CMMI 비판¶
- 특히 레벨 3–5에서 문서화 부담이 큼
- 인증 비용과 노력이 실제 개선 작업을 밀어낼 수 있음
- 폭포수(Waterfall) 중심의 기원; 애자일 실천과 긴장 관계
- "성숙도 연기(Maturity theater)": 실제로는 따르지 않는 프로세스를 문서화
CMMI는 엄격한 처방으로서가 아니라 격차를 파악하는 렌즈로서 가장 가치 있다.
3. 소프트웨어 프로세스를 위한 ISO 표준¶
3.1 ISO/IEC 12207: 소프트웨어 생명주기 프로세스¶
ISO/IEC 12207은 소프트웨어 개발의 구상부터 폐기까지 관련된 프로세스, 활동, 과제를 정의한다. 소프트웨어 생명주기 프로세스의 공통 어휘를 확립한다.
이 표준은 프로세스를 세 그룹으로 구성한다:
| 그룹 | 프로세스 예시 |
|---|---|
| 합의 프로세스(Agreement Processes) | 획득, 공급 |
| 프로젝트 지원(Project Enabling) | 생명주기 모델 관리, 인프라, 품질, 지식 |
| 기술 프로세스(Technical Processes) | 요구사항, 아키텍처, 설계, 구현, 통합, 검증, 확인, 운영, 유지보수 |
ISO 12207은 프레임워크 중립적이다 — 무엇이 이루어져야 하는지를 설명하며 어떻게는 설명하지 않는다. 스크럼(Scrum)을 사용하는 조직도 필요한 프로세스 결과를 다루는 한 ISO 12207을 준수할 수 있다.
3.2 ISO/IEC 15504 / ISO 33000: 프로세스 평가¶
ISO/IEC 15504(SPICE — Software Process Improvement and Capability dEtermination으로 알려짐)는 소프트웨어 프로세스 역량을 평가하는 프레임워크를 제공한다. ISO 33000 시리즈로 대체되었다.
ISO 33000의 역량 레벨:
| 레벨 | 명칭 | 특징 |
|---|---|---|
| 0 | 불완전(Incomplete) | 프로세스가 수행되지 않거나 부분적으로만 수행됨 |
| 1 | 수행됨(Performed) | 프로세스가 목적을 달성함 |
| 2 | 관리됨(Managed) | 프로세스가 계획되고, 모니터링되고, 조정됨 |
| 3 | 확립됨(Established) | 조정이 포함된 표준 프로세스를 기반으로 함 |
| 4 | 예측 가능(Predictable) | 정량적 데이터를 사용하여 정의된 한도 내에서 운영됨 |
| 5 | 최적화(Optimizing) | 목표 달성을 위해 프로세스가 지속적으로 개선됨 |
CMMI와의 핵심 차이점: ISO 33000은 프로세스 영역별이지, 조직 전체가 아니다. 조직이 테스트는 레벨 4이고 요구사항 관리는 레벨 1일 수 있어, 단일 CMMI 성숙도 레벨보다 더 세밀한 시각을 제공한다.
4. 프로세스 평가 수행¶
프로세스를 개선하기 전에 현재 상태를 이해해야 한다. 프로세스 평가(Process Assessment)는 CMMI, ISO 33000 등의 참조 모델에 대비하여 조직의 소프트웨어 프로세스를 구조적으로 평가하는 것이다.
4.1 평가(Assessment) vs. 감정(Appraisal)¶
| 용어 | 범위 | 목적 | 형식성 |
|---|---|---|---|
| 평가(Assessment) | 내부, 팀 주도 | 개선 기회 파악 | 낮음 (비공식 가능) |
| 감정(Appraisal) | 공식 평가 | 인증 등급 획득 | 높음 (감사, 공인 평가자) |
대부분의 팀에게는 공식 감정보다 내부 평가가 훨씬 유용하다. 목표는 학습이지 인증이 아니다.
4.2 SCAMPI 방법 (CMMI 감정)¶
SCAMPI(Standard CMMI Appraisal Method for Process Improvement)는 CMMI 감정을 위한 공식 방법이다. 세 가지 등급이 있다:
| 등급 | 기간 | 엄밀성 | 일반적 용도 |
|---|---|---|---|
| SCAMPI A | 1–3주 | 전체; 공식 등급 산출 | 계약을 위한 인증 |
| SCAMPI B | 3–5일 | 부분; 강점/약점 파악 | 감정 전 준비 상태 확인 |
| SCAMPI C | 1–2일 | 경량; 빠른 격차 분석 | 내부 개선 계획 |
4.3 경량 평가 기법¶
전체 SCAMPI 감정을 정당화할 수 없는 팀을 위한 경량 대안이 있다:
프로세스 설문 접근법: 팀원들이 각 프로세스 영역을 1–5점으로 평가하는 구조화된 설문을 독립적으로 작성한다. 응답자 간 편차는 불명확하거나 일관성 없이 적용되는 영역을 드러낸다.
## 프로세스 건강 설문 — 샘플 항목
1(전혀 아님)부터 5(일관적이고 잘됨)까지 평가하세요
요구사항 관리:
[ ] 요구사항을 수집하고 기록하는 정의된 프로세스가 있다.
[ ] 개발 시작 전에 요구사항이 검토되고 승인된다.
[ ] 요구사항 변경은 공식 변경 관리 프로세스를 거친다.
[ ] 요구사항은 테스트 케이스와 추적 가능하다.
점수: ___/20 성숙도 지표: 1-8=레벨 1, 9-14=레벨 2, 15-20=레벨 3
벽 걷기(Walking the wall): 각 팀원이 신입 사원에게 설명하듯 자신이 담당하는 프로세스 부분을 설명하게 한다. 설명의 격차와 모순이 프로세스 약점을 드러낸다.
가치 흐름 매핑 세션(Value stream mapping session): 아이디어에서 운영까지 최근 작업의 실제 전체 흐름을 매핑하고, 인계 지점·대기 시간·재작업 루프를 기록한다.
4.4 평가 결과 형식¶
잘 문서화된 평가 결과는 일관된 구조를 따른다:
## 프로세스 영역: 요구사항 관리
## 강점/약점: 약점
## 근거:
- 샘플링된 5개 프로젝트 중 4개에서, 설계 스프린트 시작 전에
개발 팀이 요구사항을 검토하지 않았다.
- 프로젝트 추적 시스템에 30일 이상 된 "요구사항 명확화" 과제가
23개 열려 있다.
## 영향:
- 늦은 요구사항 명확화로 평균 2주의 재작업 주기가 발생한다.
- 개발자 설문: 67%가 "불명확한 요구사항"을 최대 장애물로 꼽는다.
## 권장 조치:
- "요구사항 준비 완료" 체크리스트를 정의한다.
- 스프린트 계획의 준비 완료 기준(Definition of Ready)에 요구사항 검토 게이트를 추가한다.
- 담당: 제품 관리자 | 목표: 2분기 말
5. PSP(개인 소프트웨어 프로세스)와 TSP(팀 소프트웨어 프로세스)¶
SEI의 Watts Humphrey가 개발한 PSP와 TSP는 프로세스 규율을 개인 및 팀 수준으로 가져온다.
4.1 개인 소프트웨어 프로세스(PSP, Personal Software Process)¶
PSP는 엔지니어가 자신의 작업을 측정하고 관리하도록 가르친다:
- 크기 추정: 시작 전에 코드 라인 또는 기능 점수 추정
- 노력 추정: 단계별 시간 추정 (계획, 설계, 코딩, 검토, 테스트)
- 결함 추적: 단계별 결함 주입 및 제거 기록
- 프로세스 스크립트: 설계 검토, 코드 검토를 위한 구조화된 체크리스트
PSP 데이터 수집 (단순화 예제):
## PSP 시간 기록 — 기능: 사용자 인증
| 날짜 | 단계 | 시작 | 종료 | 소요 | 중단 |
|------------|------------|-------|-------|-------|------|
| 2026-01-10 | 계획 | 09:00 | 09:30 | 30 | 0 |
| 2026-01-10 | 설계 | 09:30 | 10:45 | 75 | 10 |
| 2026-01-10 | 코드 검토 | 10:45 | 11:15 | 30 | 0 |
| 2026-01-10 | 코딩 | 11:15 | 13:00 | 105 | 15 |
| 2026-01-11 | 단위 테스트| 09:00 | 10:00 | 60 | 0 |
## 결함 기록
| ID | 날짜 | 주입 단계 | 제거 단계 | 결함 유형 | 수정 시간 |
|----|------------|-----------|------------|-----------|-----------|
| D1 | 2026-01-11 | 코딩 | 단위 테스트 | 논리 오류 | 20분 |
| D2 | 2026-01-11 | 설계 | 단위 테스트 | 인터페이스 | 35분 |
시간이 지남에 따라 이 데이터는 개인 패턴을 드러낸다: 어느 단계에서 결함이 가장 많이 주입되는지, 추정이 얼마나 정확한지, 검토에서 가장 많은 문제가 잡히는 곳이 어디인지.
PSP의 핵심 통찰: 대부분의 소프트웨어 결함은 개별 엔지니어가 주입하며, 체계적인 설계와 코드 검토를 통해 테스트 전에 대부분 잡을 수 있다. 검토에서 결함을 발견하는 비용은 시스템 테스트에서 발견하는 것보다 극적으로 낮다.
4.2 팀 소프트웨어 프로세스(TSP, Team Software Process)¶
TSP는 PSP를 팀 수준으로 확장한다. TSP로 관리되는 프로젝트는:
- 팀이 집단적으로 목표, 역할, 계획을 정의하는 착수(launch) 단계로 시작함
- 개인의 PSP 데이터를 사용하여 팀 수준 추정을 산출함
- 계획 대비 실제 진행을 비교하는 주간 추적 회의를 진행함
- 관리자에게 정량적 품질 데이터 (결함 밀도, 검토율)를 보고함
TSP는 여러 연구에서 결함 밀도의 2.7배 감소와 5% 이내의 일정 예측 정확도를 포함한 상당한 품질 향상을 입증했다. 구현에는 상당한 조직적 헌신이 필요하다.
6. 회고(Retrospectives)¶
회고는 애자일 조직에서 가장 널리 실천되는 프로세스 개선 기법이다. 잘 진행될 때, 팀이 집단적으로 작업 프로세스를 검토하고 개선에 대한 구체적인 약속을 만드는 장이 된다.
5.1 핵심 구조 (모든 형식)¶
잘 진행된 회고는 대략 다음 구조를 따른다:
- 준비(Set the stage) (5분): 심리적 안전감 확립, 솔직하게 반성하도록 팀 분위기 조성
- 데이터 수집(Gather data) (15–20분): 무슨 일이 있었는가? 관찰 사항 수집
- 통찰 도출(Generate insights) (10–15분): 왜 그런 일이 있었는가? 패턴 파악
- 행동 결정(Decide what to do) (10분): 어떤 구체적인 변화를 만들 것인가?
- 마무리(Close) (5분): 감사, 다음 단계
5.2 회고 형식¶
Start / Stop / Continue (시작/중단/지속)
가장 단순하고 널리 사용되는 형식. 팀원들이 포스트잇을 작성한다: - Start (시작): 시작해야 할 것들 - Stop (중단): 멈춰야 할 것들 - Continue (지속): 잘 작동하고 있어 유지해야 할 것들
┌──────────────┬──────────────┬──────────────┐
│ START │ STOP │ CONTINUE │
├──────────────┼──────────────┼──────────────┤
│ Daily design │ Skipping │ Code reviews │
│ reviews │ retrospects │ │
│ │ │ │
│ Pair │ Deploying on │ Automated │
│ programming │ Fridays │ testing │
│ for complex │ │ │
│ features │ Undocumented │ Team lunch │
│ │ hotfixes │ Wednesdays │
└──────────────┴──────────────┴──────────────┘
4Ls: Liked(좋았던 것), Learned(배운 것), Lacked(부족했던 것), Longed For(바랐던 것)
팀 사기가 우려되거나 더 풍부한 감정적 차원을 원할 때 유용하다: - Liked (좋았던 것): 잘 되었고 기분 좋았던 것 - Learned (배운 것): 이번 스프린트에서 얻은 새로운 통찰 - Lacked (부족했던 것): 도움이 되었을 것 같은데 없었던 것 - Longed For (바랐던 것): 있었으면 하고 바랐던 것
돛단배/스피드보트(Sailboat/Speedboat)
시각적 은유: 팀이 섬(목표)으로 항해 중이다. 바람이 돛을 채운다(긍정적 힘); 닻이 배를 붙잡는다(부정적 힘); 바위는 앞의 위험이다.
5.3 회고를 효과적으로 만들기¶
- 심리적 안전(Psychological safety): 사람들이 비난 없이 우려를 제기할 수 있다고 느껴야 한다. 진행자는 비난을 적극적으로 억제한다.
- 행동 항목(Action items): 각 회고는 1–3개의 구체적이고, 담당자가 지정되고, 시간이 한정된 행동 항목을 산출해야 한다. 후속 조치 없이 불만 목록만 만드는 회고는 신뢰를 잃는다.
- 후속 조치(Follow up): 각 회고는 이전 스프린트의 행동 항목을 검토하는 것으로 시작한다. 책임이 피드백 루프를 닫는다.
- 형식 교체(Rotate the format): 매 스프린트 같은 형식을 사용하면 피로가 온다. 분기별로 형식을 교체한다.
7. 근본 원인 분석(Root Cause Analysis)¶
운영 중단, 주요 릴리스 지연, 심각한 보안 침해 등 중대한 실패가 발생하면, 표면적 사건이 아닌 체계적 원인을 이해하기 위해 근본 원인 분석(RCA, Root Cause Analysis)을 사용한다.
6.1 5 Why¶
겉보기에 단순한 기법: 근본 원인에 도달할 때까지 "왜"를 반복적으로 묻는다.
예시: 운영 데이터베이스 중단
증상: 피크 트래픽 중 데이터베이스가 응답하지 않게 됨.
왜 1: 데이터베이스가 왜 응답하지 않게 되었는가?
→ 장시간 실행되는 쿼리가 accounts 테이블을 40초 동안 잠금.
왜 2: 왜 피크 시간에 장시간 실행 쿼리가 실행되었는가?
→ 배치 보고서가 업무 시간을 고려하지 않고 오전 9시에 실행되도록 예약됨.
왜 3: 왜 업무 시간을 고려하지 않고 보고서가 예약되었는가?
→ 일정을 추가한 개발자가 피크 트래픽이 언제 발생하는지 몰랐음.
왜 4: 왜 개발자가 트래픽 패턴을 몰랐는가?
→ 운영 환경의 피크 시간에 대한 런북(runbook)이나 문서가 없음.
왜 5: 왜 그런 문서가 없는가?
→ 새 개발자가 예약된 작업을 배포하기 전에 운영 컨텍스트를
검토하도록 요구하는 프로세스가 없음.
근본 원인: 개발자가 운영 워크로드를 예약하기 전에 운영 컨텍스트를
이해하도록 하는 온보딩 또는 프로세스 게이트 없음.
시정 조치:
1. 개발자 온보딩 체크리스트에 피크 시간 문서 추가 (담당: 개발 리드, 기한: 1주)
2. 새로운 예약된 작업에 대한 운영팀 검토 필수화 (담당: 플랫폼 팀, 기한: 2주)
3. 5초 이상의 테이블 수준 잠금을 방지하는 쿼리 타임아웃 권고 잠금 추가 (담당: DBA, 기한: 3주)
6.2 피시본(Fishbone, Ishikawa) 다이어그램¶
피시본 다이어그램은 여러 범주에 걸쳐 원인을 브레인스토밍하기 위한 구조화된 시각적 도구다. 물고기의 "머리"는 효과(문제)이고, "뼈"는 원인의 범주다.
결과(EFFECT)
원인(Causes) ┌────────────────┐
│ 운영 DB │
사람(People) 프로세스(Process) │ 응답 불가 │
\ \ └────────────────┘
\ \ │
────────\────────────\────────────────────────────┘
\ \
\ \────── 예약된 작업에 대한 검토 프로세스 없음
\
\────── 개발자가 피크 시간 미인지
──────
기술(Technology) 환경(Environment)
\ \
\ \────── 피크 트래픽 문서 없음
\
\────── 쿼리 타임아웃 미설정
\────── 테이블 잠금 모니터링 경보 없음
소프트웨어를 위한 표준 피시본 범주:
| 범주 | 예시 |
|---|---|
| 사람(People) | 기술, 교육, 의사소통, 인력 |
| 프로세스(Process) | 누락된 단계, 불명확한 절차, 인계 격차 |
| 기술(Technology) | 도구, 인프라, 구성, 의존성 |
| 환경(Environment) | 조직적 압박, 문화, 시간 제약 |
| 데이터/정보(Data/Information) | 메트릭 부재, 불량한 요구사항, 지식 격차 |
6.3 결함 트리 분석(Fault Tree Analysis)¶
결함 트리 분석(FTA)은 원치 않는 사건에서 시작하여 AND/OR 논리 게이트를 사용해 기여 원인으로 체계적으로 분해하는 하향식으로 작동한다. 피시본보다 더 형식적이며 안전 중요 시스템에서 일반적이다.
[서비스 불가(Service Unavailable)]
│
OR 게이트 (하나의 원인으로도 발생)
/ | \
[DB 실패] [앱 충돌] [네트워크 실패]
│
AND 게이트 (모두 필요)
/ \
[높은 부하] [연결 풀 없음]
FTA는 고장률 데이터와 결합하면 정량적 확률 모델을 생성한다.
8. 메트릭 기반 개선: GQM 접근법¶
7.1 목표-질문-메트릭(GQM, Goal-Question-Metric)¶
메릴랜드 대학교의 Victor Basili가 개발한 GQM은 실제 개선 목표에 연결된 메트릭을 정의하는 하향식 접근법을 제공한다.
구조: 1. 목표(Goal): 목적, 대상, 품질 속성, 관점, 환경 측면에서 기술된 비즈니스 또는 품질 목표 2. 질문(Questions): 목표가 달성되었는지 판단하기 위해 답해야 할 구체적인 질문 3. 메트릭(Metrics): 각 질문에 답하는 정량적 데이터
GQM 모델 예시:
목표(GOAL): 운영 환경으로 유출되는 결함 수 감소
[목적: 감소] [대상: 결함] [품질: 신뢰성]
[관점: QA 팀] [컨텍스트: 웹 플랫폼, 2026년 2분기]
질문(QUESTIONS):
Q1: 현재 결함 유출률은 얼마인가?
Q2: 유출되는 결함은 어느 단계에서 주로 주입되는가?
Q3: 코드 검토가 테스트 전에 결함을 검출하고 있는가?
Q4: 어느 모듈의 결함 밀도가 가장 높은가?
메트릭(METRICS):
Q1 → M1: 릴리스당 운영 결함 수 / 릴리스된 기능 수
Q2 → M2: 주입 단계별 결함 (요구사항/설계/코드)
Q3 → M3: 코드 검토에서 발견된 결함 / 총 발견 결함
Q4 → M4: 모듈별 KLOC당 결함
7.2 GQM 프로세스¶
- 이해관계자와 함께 목표 정의 (엔지니어만이 아니라)
- 각 목표를 구체화하는 3–5개 질문 도출
- 질문에 답하는 메트릭 파악 — 객관적이고 자동화된 메트릭 선호
- 개선 전 기준선 데이터 수집
- 메트릭 개선을 목표로 한 프로세스 변화 구현
- 다시 측정하고, 비교하고, 다음 단계 결정
피해야 할 안티패턴: 먼저 메트릭을 선택한 다음 이를 정당화하기 위해 역으로 작업하는 것. 이는 허영 메트릭(vanity metrics) — 좋아 보이지만 실제 개선을 나타내지 않는 수치 — 을 만들어낸다.
9. 소프트웨어의 지속적 개선 (카이젠, Kaizen)¶
카이젠(Kaizen)은 지속적이고 점진적인 개선이라는 일본의 개념이다. 소프트웨어에 적용할 때의 의미:
- 어떤 프로세스도 완성된 것이 없다 — 항상 다음 한계적 개선을 찾아라
- 작은 개선이 드문 큰 개선보다 낫다
- 팀의 모든 구성원이 (관리자만이 아니라) 개선에 책임이 있다
- 개선은 의견이 아닌 데이터에 기반한다
8.1 PDCA 사이클¶
Plan-Do-Check-Act(데밍 사이클이라고도 함)는 지속적 개선의 운영 엔진이다:
┌─── Plan(계획) ───┐
│ │
Act(조치) Do(실행)
│ │
└─── Check(확인)──┘
Plan(계획): 문제를 파악하고 개선을 계획한다
Do(실행): 제한적 방식으로 개선을 구현한다 (실험)
Check(확인): 예상 결과와 실제 결과를 측정한다
Act(조치): 성공했다면 표준화한다; 아니라면 배우고 다시 계획한다
소프트웨어 예시: - Plan(계획): 코드 검토 처리 시간이 평균 3일이다. 이것이 납품을 늦춘다고 생각한다. 가설: "24시간 검토 SLA" 규범을 만들면 사이클 타임이 개선될 것이다. - Do(실행): SLA를 공표하고 한 스프린트 동안 추적한다. - Check(확인): 평균 처리 시간이 1.2일로 감소. PR 사이클 타임이 15% 개선. - Act(조치): 팀 규범 문서에 "24시간 검토"를 추가하고; 월별로 메트릭을 추적한다.
8.2 가치 흐름 매핑(Value Stream Mapping)¶
린 제조에서 차용한 가치 흐름 매핑은 아이디어에서 운영까지의 작업 전체 흐름을 시각화하여 낭비를 가시화한다:
아이디어 → 백로그 정제 → 스프린트 계획 → 개발 → 코드 검토 →
CI 파이프라인 → QA → 스테이징 → 운영
[3일] [1일] [2일] [3일] [1일] [2일] [1일]
총 리드 타임: ~13일
가치 추가 시간: ~6일 (개발 + 검토 + 파이프라인)
낭비: ~7일 (대기, 대기열 시간, 컨텍스트 전환)
낭비 — 대기, 재작업, 불필요한 승인 — 를 파악하고 제거하는 것이 종종 더 빠른 코드 작성보다 더 큰 영향을 미친다.
10. 프로세스 조정(Process Tailoring)¶
어떤 표준 프로세스 프레임워크도 모든 팀에 완벽하게 맞지 않는다. 프로세스 조정(Process Tailoring)은 표준 프로세스를 프로젝트의 특정 제약 조건에 맞게 체계적으로 적용하는 것이다.
9.1 조정이 필요한 이유¶
- 3인 스타트업은 공식 변경 통제 위원회가 필요 없다
- 안전 중요 의료 기기 프로젝트는 공식 검증을 생략할 수 없다
- 5명의 시니어 엔지니어 팀은 주니어 중심 팀만큼의 멘토링 오버헤드가 필요 없다
9.2 조정 지침¶
좋은 조정 접근법은 세 단계를 따른다:
- 정의된 표준에서 시작: 기준 프로세스를 문서화한다 (설령 "교과서적 스크럼"이라도)
- 조정 결정 사항 파악: 어떤 실천이 필수이고, 어떤 것이 선택적이고, 어떤 것이 상황에 따라 다른가?
- 근거 문서화: 각 조정 결정이 왜 이루어졌는지 기록하여 나중에 재평가할 수 있게 한다
## 조정 기록: 프로젝트 피닉스 (모바일 앱)
### 기준 프로세스: 회사 표준 SDLC v2.3
| 실천 | 표준 | 결정 | 근거 |
|-----------------------|------|---------|-----------------------------------------|
| 요구사항 검토 | 필수 | 필수 | 건강 기능의 안전 함의 |
| 아키텍처 검토 | 필수 | 축소 | MVP: 아키텍트 1명 + PM 승인 (위원회 아님) |
| 코드 검토 | 필수 | 필수 | 표준 커버리지 규칙 적용 |
| 부하 테스트 | 필수 | 연기 | MVP는 사용자 <1000명; 베타에서 재검토 |
| 보안 침투 테스트 | 필수 | 필수 | 건강 데이터; 규제 요건 |
| 출시 후 검토 | 선택 | 필수 | 첫 모바일 릴리스; 높은 학습 가치 |
9.3 조정하지 말아야 할 때¶
편의를 위해 절대 조정하면 안 되는 실천들이 있다: - 개인 또는 금융 데이터를 처리하는 시스템의 보안 검토 - 버전 관리 (사용하지 않을 핑계는 없다) - 운영 사고를 일으킨 회귀 경로의 테스트 자동화
11. 산업 표준 벤치마킹¶
벤치마킹은 조직의 성과를 동종 기업 또는 산업 데이터와 비교하여 개선 기회를 파악한다.
10.1 DORA 메트릭¶
DevOps Research and Assessment(DORA) 메트릭은 Accelerate State of DevOps 보고서의 수천 명 설문 응답자를 바탕으로 한 소프트웨어 납품 성과에 대해 가장 경험적으로 검증된 벤치마크다.
| 메트릭 | 엘리트 | 높음 | 중간 | 낮음 |
|---|---|---|---|---|
| 배포 빈도(Deployment Frequency) | 하루 여러 번 | 1일/1주 1회 | 1월/1주 1회 | 월 1회 미만 |
| 변경 리드 타임(Lead Time for Changes) | 1시간 미만 | 1일 – 1주 | 1주 – 1개월 | 1개월 초과 |
| 변경 실패율(Change Failure Rate) | 0–5% | 5–10% | 10–15% | 15% 초과 |
| MTTR (복구 시간) | 1시간 미만 | 1일 미만 | 1일 – 1주 | 1주 초과 |
이 메트릭에서 엘리트 성과를 달성하는 팀은 더 높은 조직 성과(수익성, 시장 점유율, 생산성)도 보고한다.
10.2 벤치마크를 올바르게 사용하기¶
- 방향을 위한 벤치마크, 목적지가 아닌: 목표는 지속적 개선이지 특정 등급 달성이 아니다
- 내부 벤치마크도 중요: 팀 성과를 자체 역사적 기준선과 비교한다
- 굿하트의 법칙(Goodhart's Law) 주의: "측정이 목표가 되면 좋은 측정 지표가 되기를 멈춘다." 배포 빈도는 각 배포가 가치를 전달할 때만 의미 있다.
요약¶
소프트웨어 프로세스 개선은 소프트웨어 개발을 더 낫게 만드는 체계적인 규율이다 — 명령이 아니라 측정, 학습, 점진적 변화를 통해. 핵심 개념:
- CMM/CMMI 성숙도 레벨 (1–5): 혼돈적인 초기(Initial)에서 지속적으로 최적화(Optimizing)까지. 대부분의 가치는 레벨 2–3 사이에서 실현됨.
- ISO/IEC 12207: 소프트웨어 생명주기 프로세스의 표준 어휘 (프레임워크 중립)
- ISO 33000/SPICE: 프로세스 영역 수준에서의 프로세스 역량 평가 (레벨 0–5)
- PSP/TSP: 결함 주입을 줄이고 추정 정확도를 향상시키는 개인 및 팀 수준 측정 규율
- 회고: 가장 접근하기 쉬운 SPI 도구 — 구체적인 행동 항목이 있는 구조화되고 정기적인 성찰
- 근본 원인 분석: 5 Why와 피시본 다이어그램은 표면 증상이 아닌 체계적 원인을 다룸
- GQM: 모든 메트릭을 명시된 목표와 질문에 연결 — 편리한 것이 아니라 중요한 것을 측정
- 카이젠/PDCA: 드문 대규모 개혁보다 지속적이고 작은 개선이 낫다
- 프로세스 조정: 표준을 맥락에 맞게 적용하고; 모든 편차를 문서화하고 정당화한다
- DORA 메트릭: 소프트웨어 납품 성과에 대한 산업 검증 벤치마크
프로세스 개선의 궁극적 목표는 프레임워크 준수가 아니라 모든 팀원이 문제를 파악하고, 해결책을 실험하고, 체계적으로 배울 수 있는 권한을 갖는 문화다.
연습 문제¶
-
CMMI 자체 평가: 잘 알고 있는 소프트웨어 팀(현재 팀, 이전 직장, 또는 사례 연구)을 고려하라. 다음 CMMI 프로세스 영역 각각에 대해 현재 역량 레벨(1–3)을 평가하고 구체적인 관찰로 평가를 정당화하라: (a) 요구사항 관리, (b) 프로젝트 계획, (c) 형상 관리, (d) 원인 분석 및 해결. 각 영역을 한 레벨 향상시키려면 팀이 무엇을 해야 하는가?
-
GQM 설계: 팀이 운영 시스템의 신뢰성을 개선하고자 한다. 완전한 GQM 모델을 정의하라: 하나의 목표를 공식적으로 기술하고 (목적/대상/품질 속성/관점), 세 가지 질문을 도출하고, 각 질문에 대해 자동으로 수집할 수 있는 하나 또는 두 가지 구체적인 메트릭을 파악하라. 어떤 데이터 소스가 필요한지 파악하라.
-
회고 진행: 스프린트 목표를 놓치고, 핫픽스로 2시간 중단이 발생하고, 계획 세션 중 두 팀원이 공개적으로 충돌한 나쁜 스프린트에 대한 회고를 진행해야 한다. 회고를 설계하라: 형식을 선택하고, 타이밍이 포함된 안건을 작성하고, 심리적 안전을 유지하기 위해 사용할 3가지 진행 기법을 나열하고, 성공적인 결과가 어떤 모습인지 설명하라.
-
근본 원인 분석: 오전 2시 17분에 중요한 API 엔드포인트가 503 오류를 반환하기 시작하여 47분 동안 12%의 사용자에게 영향을 미쳤고, 온콜 엔지니어가 서비스를 재시작하였다. 서비스는 오후 11시에 배포되었다. 5 Why를 사용하여 이 사고를 최소 4단계로 분석하라. 그런 다음 같은 사고에 대한 피시본 다이어그램을 그려라. 어떤 시정 조치가 근본 원인을 해결하겠는가?
-
프로세스 조정: 소비자용 개인 재무 추적 앱을 개발하는 6명 팀의 엔지니어링 리드이다. 회사의 표준 SDLC 프로세스는 공식 변경 통제 위원회, 주간 운영 위원회 회의, 필수 아키텍처 검토 위원회 승인이 있는 엔터프라이즈 프로젝트를 위해 설계되었다. 맥락에 맞게 이 프로세스를 적용하는 조정 기록을 작성하라. 줄일 실천 5가지, 변경 없이 유지할 실천 2가지, 표준을 넘어 강화할 실천 1가지를 파악하라.
더 읽을거리¶
- 도서:
- Humphrey, W. (1995). A Discipline for Software Engineering. Addison-Wesley. (PSP 원본)
- Chrissis, M., Konrad, M. & Shrum, S. (2011). CMMI for Development, 3rd Ed. Addison-Wesley. (결정판 CMMI 가이드)
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution. (DORA 연구)
-
Derby, E. & Larsen, D. (2006). Agile Retrospectives. Pragmatic Bookshelf.
-
논문 및 온라인 자료:
- Basili, V. & Rombach, H. D. (1988). "The TAME Project." IEEE Transactions on Software Engineering. (GQM 기원)
- DORA State of DevOps Reports: 산업 벤치마크가 있는 연간 설문
- SEI CMMI Institute: 공식 CMMI 자료 및 감정 안내
-
retrospectivewiki.org: 회고 형식의 커뮤니티 모음
-
표준:
- ISO/IEC 12207:2017 — 시스템 및 소프트웨어 공학: 소프트웨어 생명주기 프로세스
- ISO/IEC 33001:2015 — 프로세스 평가 개념 및 용어 (ISO 33000 시리즈)
- ISO/IEC 15939:2007 — 소프트웨어 측정 프로세스 (GQM 기반)
이전: 소프트웨어 유지보수와 진화 | 다음: DevOps와 CI/CD