개념
개선안의 대부분은 문서로 끝난다
진단 보고서를 받은 조직의 흔한 반응은 이렇다. 경영진이 "좋다, 하자"고 말한다. 새 절차 문서가 배포된다. 석 달 뒤, 아무도 그 절차를 쓰지 않는다. 이유를 물으면 "바빠서", "우리 팀 상황과 안 맞아서", "원래 방식이 더 빨라서".
프로세스 개선이 실패하는 이유는 개선안이 틀려서가 아니라 변화를 관리하지 않아서 인 경우가 훨씬 많다. 이 레슨은 레슨 4의 진단 결과를 실제로 현장에 정착시키는 방법을 다룬다.
IDEAL — 개선의 한 주기
IDEAL은 카네기멜런대 SEI가 정리한 소프트웨어 프로세스 개선 모델로, 개선을 다섯 단계의 반복 주기로 본다.
| 단계 | 하는 일 | 이 모듈에서 |
|---|---|---|
| I — Initiating(착수) | 개선의 이유와 후원자 확보, 목표 설정 | 경영진 후원, 비즈니스 케이스(레슨 1) |
| D — Diagnosing(진단) | 현재 상태와 원하는 상태의 차이 파악 | 레슨 4의 진단 |
| E — Establishing(수립) | 우선순위 정하고 실행 계획 수립 | 로드맵, 파일럿 설계 |
| A — Acting(실행) | 해결책 만들고 시범 적용 후 확산 | 파일럿 → 확산 |
| L — Learning(학습) | 결과 분석, 다음 주기에 반영 | 효과 측정, 회고 |
중요한 것은 주기 라는 점이다. 한 번의 큰 개혁이 아니라 3~6개월 단위의 작은 주기를 반복한다. ISTQB CTAL-TM v3.0이 테스트 매니저의 성과로 "프로세스 개선 활동 주도"를 넣은 것도 이 반복 주기를 운영하는 능력을 말한다.
파일럿 — 작게, 측정 가능하게, 이길 곳에서
진단에서 우선순위가 높은 개선안을 바로 전사에 적용하지 않는다. 먼저 한두 팀에서 파일럿한다.
파일럿 팀 선정 기준.
| 기준 | 이유 |
|---|---|
| 문제가 실제로 있다 | 효과가 측정되어야 한다 |
| 팀 리드가 의지가 있다 | 저항 팀에서 시작하면 개선안이 아니라 저항과 싸우게 된다 |
| 조직에서 영향력이 있다 | 성공 사례가 다른 팀을 움직인다 |
| 너무 특수하지 않다 | 결과가 다른 팀에 일반화되어야 한다 |
성공 기준을 미리 정한다. 파일럿이 끝난 뒤에 성공 여부를 판단하면 늘 "그럭저럭 괜찮았다"가 된다.
[파일럿 설계 — 요구사항 리뷰 게이트]
대상 커머스 본부 결제팀, 주문팀 (3개월)
개선안 개발 착수 전 수용 기준 리뷰(QA·개발·기획 30분), 변경 시 QA 채널 통보
성공 기준
- 요구사항 원인 결함 비율 49% → 30% 이하
- 리뷰 소요 시간 스토리당 평균 20분 이하(부담 기준)
- 참여 팀원 만족도(5점 척도) 3.5 이상
중단 기준 2개월 차에 리뷰 누락률 50% 초과 시 방식 재설계
확산 조건 성공 기준 3개 중 2개 충족 + 파일럿 팀 리드의 확산 동의"중단 기준"을 두는 것이 신뢰를 만든다. 개선안이 틀릴 수 있다는 것을 인정하면 현장의 저항이 줄어든다.
Kotter의 8단계 — 조직의 변화
John Kotter는 조직 변화가 실패하는 패턴을 연구해 8단계를 제시했다. QA 프로세스 개선에 옮기면 이렇다.
| 단계 | QA 개선에서의 모습 |
|---|---|
| 1. 위기감 조성 | 요구사항 원인 운영 결함 49%, 장애 비용 데이터 공유 |
| 2. 변화 추진 연합 구성 | QA 리드 + 개발 리드 + 기획 리드 + 경영진 후원자 |
| 3. 비전과 전략 수립 | "결함을 찾는 것보다 만들지 않는 조직" |
| 4. 비전 전달 | 타운홀, 팀별 설명, 반복 |
| 5. 장애물 제거 | 기획 일정에 리뷰 시간 공식 반영, 도구 설정 |
| 6. 단기 성과 창출 | 파일럿 팀의 결함 감소 수치 공유 |
| 7. 성과 기반 확산 | 파일럿 성공 → 다른 팀으로 |
| 8. 문화로 정착 | 품질 운영 모델(레슨 2)의 게이트로 공식화 |
가장 자주 건너뛰는 단계는 2(연합) 와 5(장애물 제거) 다. QA 혼자 추진하는 개선은 "QA가 또 뭘 하라고 한다"로 받아들여진다. 기획 일정에 리뷰 시간이 공식적으로 없으면 아무리 설득해도 리뷰는 밀린다.
ADKAR — 개인의 변화
Kotter가 조직 수준이라면, Prosci의 ADKAR는 한 사람이 변화를 받아들이는 순서 를 다룬다. 저항하는 사람이 어느 단계에서 막혀 있는지 진단하는 데 쓴다.
| 단계 | 질문 | 막혀 있을 때의 신호 | 처방 |
|---|---|---|---|
| Awareness(인식) | 왜 바꿔야 하는지 아는가 | "지금도 잘 돌아가는데요" | 데이터와 사례 공유 |
| Desire(열망) | 바꾸고 싶은가 | "알지만 내 일만 늘어나요" | 본인에게 돌아오는 이득, 부담 경감 |
| Knowledge(지식) | 어떻게 하는지 아는가 | "뭘 어떻게 하라는 건지" | 교육, 예시, 템플릿 |
| Ability(능력) | 실제로 할 수 있는가 | "해 봤는데 잘 안 돼요" | 코칭, 페어, 연습 시간 |
| Reinforcement(강화) | 계속하는가 | 한 달 뒤 원래 방식으로 복귀 | 인정, 지표 공유, 절차화 |
저항을 "태도 문제"로 보면 해결되지 않는다. 대부분의 저항은 특정 단계가 채워지지 않았다는 신호다. 예를 들어 요구사항 리뷰를 안 하는 기획자가 Desire 단계에서 막혀 있다면(일만 늘어난다), 교육(Knowledge)을 아무리 해도 소용없다. 리뷰 덕분에 기획 변경 요청이 줄어든다는 이득을 보여 주거나, 리뷰 시간만큼 다른 업무를 줄여 줘야 한다.
워크숍 퍼실리테이션
개선안을 만들거나 파일럿 결과를 확산할 때 워크숍을 연다. 컨설턴트·QMO의 핵심 기술이다.
[90분 개선 워크숍 구성 예]
10분 목적과 규칙(판단 유보, 모두 발언), 진단 결과 요약
20분 개별 아이디어 쓰기(침묵) → 벽에 붙이기
15분 비슷한 것 묶기(친화도), 이름 붙이기
15분 영향 × 용이성 2x2에 배치
20분 상위 2개 안에 대해 "첫 2주 동안 할 일" 구체화
10분 담당·일정·다음 확인일 합의퍼실리테이터의 규칙: 내용에는 중립, 과정에는 단호. 퍼실리테이터가 특정 안을 밀면 참가자는 그것을 "위에서 정해 놓은 답"으로 느낀다. 대신 시간·발언 기회·결정 규칙은 엄격하게 지킨다. "개별 아이디어 쓰기(침묵)" 단계는 목소리 큰 사람이 논의를 장악하는 것을 막는다.
효과 측정과 로드맵
개선의 효과는 파일럿 설계에서 정한 성공 기준으로 잰다. 측정은 개선 전 기준선 이 있어야 의미가 있다 — 진단 단계의 데이터가 기준선이 된다.
[품질 개선 로드맵 — 12개월]
Q1 I·D 경영진 후원 확보, 진단(레슨 4), 기준선 측정
Q2 E·A 파일럿 2건: 요구사항 리뷰 게이트(결제·주문), 결함 보고 템플릿(전 팀)
Q3 A·L 파일럿 효과 측정, 성공 시 커머스 본부 전체 확산, 실패 시 재설계
Q4 A·L 품질 운영 모델에 게이트 공식화, 다음 주기 진단(자동화 영역)
측정 요구사항 원인 결함 비율, 결함 탈출률, 리뷰 부담 시간 — 분기별 경영진 보고실무에서 왜 필요한가
QA 조직이 신뢰를 잃는 가장 흔한 경로는 "매년 새 절차를 만들지만 아무것도 바뀌지 않는" 것이다. 파일럿과 성공 기준, 변화 관리 모델은 이 실패를 구조적으로 막는다. 특히 QA는 다른 부서의 일하는 방식을 바꿔 달라고 요청하는 입장이 많아서, 변화 관리 없이는 거의 아무것도 정착시키지 못한다.
채용시장에서의 위치
QMO·컨설턴트 면접에서 "개선을 추진했는데 저항이 있었다면 어떻게 했나"는 핵심 질문이다. ADKAR로 저항의 단계를 진단하고 처방을 달리했다는 이야기, 파일럿의 성공·중단 기준을 미리 정했다는 이야기는 변화를 설계할 줄 아는 사람의 증거다.