프로세스 개선 모델: TMMi·TPI Next로 팀의 테스트 성숙도 가늠하기

개념

"우리 팀 QA가 뭔가 부족한 것 같다" 는 느낌은 거의 모든 QA가 갖고 있다. 그런데 그 느낌을 그대로 말하면 아무것도 바뀌지 않는다. 바뀌려면 부족한 것의 이름이 필요하다.

체력 측정표를 떠올리면 쉽다. "운동이 부족하다" 는 말로는 무엇을 할지 모르지만, 종목별로 재서 유연성은 평균이고 심폐는 하위권이라는 결과가 나오면 무엇을 훈련할지가 정해진다. 성숙도 모델이 그 측정표다.

그래서 이 레슨의 쓸모는 레벨 숫자가 아니다. "지금 우리에게 없는 것이 무엇인지" 를 남들도 알아듣는 말로 바꾸는 것이다.

왜 "성숙도"라는 개념이 필요한가

모듈 6(레슨 5)에서 결함 밀도·탈출률 같은 지표로 결과를 측정하는 법을 배웠다. 프로세스 개선 모델은 한 단계 더 나아가, 그 결과를 만들어내는 프로세스 자체가 얼마나 체계적인지를 평가한다. "결함이 많이 나온다"는 증상 뒤에는 "테스트 계획을 아예 안 세운다"거나 "테스트 케이스가 문서화되지 않는다" 같은 프로세스 수준의 원인이 있을 수 있다.

증상과 프로세스 원인을 짝지어 보면 이 관점이 분명해진다.

세 번째 줄이 성숙도 모델이 가장 직접적으로 다루는 것이다. 잘하는 사람 한 명에 의존하는 팀은 그 사람이 쉬는 주에 품질이 떨어진다. 성숙도가 높다는 말은 그 의존이 적다는 뜻이다.

TMMi (Test Maturity Model integration)

TMMi는 조직의 테스트 프로세스 성숙도를 5단계로 나눈다.

레벨은 "얼마나 잘하는가"의 절대적 순위가 아니라, 다음에 무엇을 갖춰야 할지 알려주는 로드맵으로 쓰인다. 레벨 1인 팀이 갑자기 레벨 5를 목표로 삼는 건 비현실적이다 — 지금 우리 팀에게 필요한 건 대부분 "레벨 2로 가려면 무엇이 없는가"를 아는 것이다.

실무에서 쓰이는 것은 레벨 2와 3이다

레벨 4·5는 대기업·규제 산업에서 다루는 영역이고, 대부분의 팀이 실제로 고민하는 것은 2와 3이다. 그 둘이 무엇을 요구하는지 알면 이 모델을 바로 쓸 수 있다.

레벨 2의 다섯 줄이 이 커리큘럼 모듈 7의 내용과 거의 같다. 테스트 관리 도구(레슨 1)·데이터(레슨 2)·환경(레슨 3)·결함 추적(모듈 6)이 그것이고, 그래서 이 모듈을 익히면 레벨 2의 요건을 말할 수 있게 된다.

레벨 3의 두 번째 줄이 가장 어렵다. "앞단 참여" 는 QA의 의지만으로 안 되고 팀 전체의 일하는 방식이 바뀌어야 한다. 레슨 5의 Three Amigos와 레슨 8의 인수기준이 그 실천 방법이다.

단계를 건너뛸 수 없는 이유

레벨 1인 팀에 "지표를 측정하자"(레벨 4)고 제안하면 실패한다. 왜 그런지가 분명하다.

레벨 2 없이 레벨 4를 하면
  실행 기록이 없다 → 집계할 데이터가 없다 → 지표가 거짓이 된다
 
레벨 3 없이 레벨 4를 하면
  팀마다 다른 방식으로 측정한다 → 비교가 불가능하다

측정은 기록 위에서만 가능하다. 모듈 6 레슨 5에서 본 "결함 밀도를 계산할 규모 데이터가 없다" 가 정확히 이 상황이다 — 분류(레슨 4의 라벨)가 없으면 지표를 만들 수 없다.

그래서 개선 제안의 순서는 거의 항상 기록 → 표준화 → 측정 → 최적화다. 순서를 지키는 것만으로 제안의 실현 가능성이 크게 올라간다.

TPI Next (Test Process Improvement Next)

TPI Next는 TMMi처럼 단일한 레벨을 매기기보다, 테스트 프로세스를 여러 핵심 영역(예: 테스트 전략, 테스트 조직, 테스트 도구, 이해관계자와의 소통 등)으로 나눠 영역별로 성숙도를 평가한다.

어떤 팀은 "테스트 도구 활용"은 뛰어나지만 "이해관계자와의 소통"은 약할 수 있다 — TMMi의 단일 레벨로는 이런 불균형이 잘 안 보이지만, TPI Next의 영역별 평가는 이걸 명확히 드러낸다.

핵심 영역의 예를 보면 어떤 축으로 보는지 감이 온다.

TPI Next에는 클러스터라는 개념도 있다. 영역별 성숙도를 따로 매기되, 함께 올려야 효과가 나는 묶음을 묶어 다음 목표로 제시하는 방식이다.

이것이 실무적으로 중요한 이유가 있다. 도구만 올리는 개선은 효과가 작다. 테스트 관리 도구를 도입했는데 테스트 전략이 없으면, 케이스를 담을 그릇은 생겼지만 무엇을 담을지는 그대로 모르는 상태다.

두 모델 중 무엇을 쓸까

실무에서는 섞어 쓰거나, 필요한 부분만 가져다 쓴다.

경영 보고에는 TMMi, 내부 계획에는 TPI Next 가 대체로 맞는 조합이다. 임원에게는 단일 숫자가 전달되고, 팀 안에서는 "어느 영역이 약한가" 가 행동으로 이어진다.

두 모델의 공통점 — 진단 도구이지 목표 자체가 아니다

TMMi·TPI Next 모두 "인증을 따는 것" 자체가 목적이 아니다. 우리 팀의 현재 상태를 객관적으로 진단하고, 다음에 개선할 우선순위를 정하기 위한 도구다. 실무에서는 공식 평가·인증 절차를 밟기보다, 이 모델의 체크리스트 항목을 참고해 우리 팀에 무엇이 부족한지 자체 점검하는 방식으로 훨씬 더 많이 쓰인다.

프로세스가 아니라 사람 쪽의 부족함을 진단하는 도구 — 스킬 매트릭스, 버스 팩터, 팀 배치와 아웃소싱 판단, 그리고 품질 비용으로 테스팅의 가치를 논증하는 법 — 은 레슨 9 에서 다룬다.

자체 진단을 하는 가장 쉬운 방법

공식 평가는 비용과 시간이 든다. 대신 예·아니오로 답하는 문항을 만들어 팀과 함께 체크하면 반나절이면 된다. 아래는 레벨 2·3 을 가늠하는 문항이다.

레벨 2를 가늠하는 문항

• 릴리즈마다 무엇을 어디까지 테스트할지 적은 문서가 있나
• 테스트 케이스가 개인 파일이 아닌 공동 저장소에 있나
• 실행 결과가 회차별로 남나(덮어쓰지 않나)
• 테스트 환경이 누군가의 PC가 아닌 공용으로 준비되나
• 결함이 도구에 등록되고 상태가 바뀌나

레벨 3을 가늠하는 문항

• 다른 팀도 같은 방식으로 테스트하나
• QA가 개발 시작 전에 요구를 보나
• 성능·보안 같은 비기능 테스트를 누가 언제 하는지 정해져 있나
• 요구·설계 리뷰가 절차로 있나
• 새로 온 사람이 문서로 배울 수 있나

"아니오" 가 가장 많이 나오는 쪽이 다음 개선 지점이다. 그리고 이 방식의 숨은 효과가 있다 — 팀과 함께 체크하면 합의가 동시에 생긴다. QA 혼자 진단해 제안하면 설득이 필요하지만, 함께 체크하면 "아니오" 를 본 사람이 여럿이 된다.

개선 제안을 통과시키는 법

성숙도 모델의 가장 흔한 실패는 제안이 받아들여지지 않는 것이다. 모델 이름으로 설득하면 거의 안 된다.

오른쪽의 공통점은 모델 이름이 없다는 것이다. 모델은 QA가 생각을 정리하는 틀로 쓰고, 전달할 때는 그 팀이 실제로 겪은 불편으로 바꾼다. 모듈 6 레슨 5의 지표가 그 재료다.

개선의 세 가지 함정

첫 줄이 QA 스스로 가장 많이 저지르는 실수다. "테스트 계획서를 쓰자" 는 제안이 통과되면 양식이 생기는데, 그 문서가 릴리즈 판단에 쓰이지 않으면 일만 늘어난 것이다. 문서를 만들 때마다 "이걸 누가 언제 읽나" 를 먼저 답해야 한다.

세 번째도 흔하다. 성숙도 진단을 하면 부족한 것이 열 개 보이는데, 동시에 열 개를 바꾸면 하나도 안 바뀐다. 분기마다 하나가 현실적인 속도다.

애자일 팀에서 성숙도 모델을 쓸 수 있나

"성숙도 모델은 워터폴 시대의 것" 이라는 오해가 많다. 모델이 요구하는 것을 보면 그렇지 않다.

형식이 아니라 기능으로 읽으면 전부 애자일에 있다. "계획서" 를 요구하는 것이 아니라 "무엇을 어디까지 볼지 합의했는가" 를 묻는 것이다. 그래서 애자일 팀에서도 진단 도구로 쓸 수 있고, 다만 산출물의 형태는 다르게 둔다.

마지막 줄이 특히 중요하다. 회고가 절차 변경으로 이어지는 팀은 모델이 말하는 레벨 5(지속적 개선)의 핵심을 이미 하고 있는 것이다. 회고에서 나온 개선이 다음 스프린트에 실제로 반영되는지가 그 판단 기준이다.

작게 돌리는 개선 사이클

성숙도 모델을 쓰든 안 쓰든, 개선은 같은 사이클을 돈다.

① 지금 상태를 센다  →  ② 하나를 바꾼다  →  ③ 효과를 센다  →  ④ 남길지 정한다
      ↑                                                            │
      └────────────────────────────────────────────────────────────┘

①과 ③이 같은 방식이어야 한다. 바꾸기 전 숫자가 없으면 효과를 말할 수 없고, 효과를 말할 수 없으면 다음 개선의 예산이 안 나온다.

예를 들어 "결함 리포트 템플릿 도입"(모듈 6 레슨 2)을 개선 항목으로 잡으면, 도입 전후의 반려율과 재오픈율을 비교한다. 두 숫자가 내려가면 그것이 다음 개선을 요청할 근거가 된다.

다른 표준과의 관계

이름이 비슷한 것이 많아 혼란스러운데, 다루는 대상이 다르다.

29119와 TMMi의 차이가 가장 많이 헷갈린다. 29119는 "테스트 문서와 절차를 이렇게 쓰라" 는 표준이고, TMMi는 "그 절차가 얼마나 정착됐나" 를 재는 모델이다. 29119는 모듈 8에서, 25010은 모듈 16·21의 비기능 품질에서 이어 받는다.

사례 — 레벨 1에서 1년

QA 두 명뿐인 팀의 기록이다. 진단 문항을 함께 체크했더니 레벨 2 다섯 문항이 전부 "아니오" 였다.

열 가지를 바꾸고 싶었지만 분기마다 하나로 정했다.

1년이 걸렸고, 비용이 든 항목은 하나도 없었다. 레벨 2의 요건은 대부분 도구와 습관이지 예산이 아니다.

그리고 1분기의 효과가 나머지를 가능하게 했다. 결함 숫자가 생기자 "어느 영역이 약한가" 를 말할 수 있게 되고, 그 말이 2·3분기 개선의 근거가 됐다. 측정 가능한 것을 먼저 만드는 것이 순서의 핵심이다.

실무에서 왜 필요한가

QA 리드나 시니어로 성장하면, 개별 테스트 케이스를 짜는 것을 넘어 팀의 테스트 프로세스 자체를 진단하고 개선을 제안해야 하는 순간이 온다. TMMi·TPI Next 같은 모델은 "이 팀은 뭐가 부족한 것 같다"는 막연한 느낌을, "테스트 계획 수립 단계가 체계화되어 있지 않다"처럼 구체적인 영역으로 짚어낼 수 있는 언어를 제공한다. 이건 스테이지 6(부록)에서 다룰, 의료기기 QA처럼 규제 산업의 표준 문서(ISO 29119 등, 모듈 8에서 다룬다)를 이해하는 데도 기초가 된다.

느낌을 요청으로 바꾸는 언어

QA가 가장 많이 막히는 순간은 불편을 느끼지만 그것을 요청으로 만들 수 없을 때다. 이 모델의 항목들이 그 변환표 역할을 한다.

이름이 붙으면 토론이 가능해진다. "급하다" 는 감정이라 반박되지만, "범위 합의가 없다" 는 사실이라 대응이 나온다.

조직이 커질 때 먼저 깨지는 것

팀이 둘에서 다섯으로, 다섯에서 스물로 늘 때 먼저 무너지는 것이 레벨 3 항목들이다. 사람마다 방식이 다르고, 그 차이가 품질 편차로 나타난다.

그래서 성장하는 조직에서 QA 리드의 일이 표준화에 쏠리게 된다. 이때 주의할 것이 하나 있다 — 표준화는 자율성을 줄인다. 모든 것을 표준으로 묶으면 사람들이 일을 기계적으로 하게 되므로, 편차가 실제로 문제를 만드는 영역만 표준화한다(모듈 4의 리스크 판단과 같은 접근).

규제 산업에서는 선택이 아니다

의료기기·금융·자동차·항공에서는 프로세스 증빙 자체가 요구사항이다. "테스트를 했다" 가 아니라 "정해진 절차로 했고 기록이 있다" 를 증명해야 한다. 이 영역에서 성숙도 모델과 29119 같은 표준은 교양이 아니라 업무이고, 스테이지 5·6의 해당 모듈에서 이어 받는다.

채용시장에서의 위치

이 레슨의 내용은 신입에게는 거의 안 묻고, 리드 지원에서는 자주 묻는다. 그래서 지금 당장 쓸 일이 없어도 알아 두면 직급이 올라갈 때 바로 쓰인다.

세 번째와 다섯 번째가 리드 역량을 보는 질문이다. 개선을 제안해 본 사람과 통과시켜 본 사람의 차이가 거기서 드러난다. 특히 다섯 번째는 순서 감각을 보는 질문이고, "기록 → 표준화 → 측정" 을 말할 수 있으면 실제로 해 본 사람으로 읽힌다.

네 번째도 함정이다. "애자일에는 안 맞는다" 고 답하면 모델을 형식으로만 이해한 것이 되고, 기능으로 읽을 수 있으면 두 세계를 다 아는 사람이 된다.

공고 표현으로는 "QA 프로세스 수립·개선", "테스트 표준화", "품질 체계 구축", "TMMi/CMMI" 가 이 레슨에 걸린다. 규제 산업 공고에서는 필수 요건 으로 적히는 경우도 있다.

실습 과제

과제 1 — 우리 팀 레벨 진단하기 (10분)

가상의 팀 상황을 하나 설정한다("테스트 케이스는 각자 알아서 관리하고, 릴리스 전에 급하게 몰아서 테스트한다"). 이 팀이 TMMi 레벨 1~5 중 어디에 가장 가까운지 판단하고 이유를 적는다.

과제 2 — 다음 개선 우선순위 정하기 (10분)

과제 1에서 진단한 팀이 다음 단계로 가기 위해 가장 먼저 갖춰야 할 것 한 가지를 TMMi 레벨 정의를 참고해 제안한다.

과제 3 — 영역별 불균형 찾기 (12분)

아래는 어느 팀의 상태다. TPI Next처럼 영역별로 높음·중간·낮음을 매기고, 함께 올려야 하는 두 영역을 골라 이유를 적는다.

• 자동화 도구를 잘 쓰고 CI에서 매일 돌린다
• 무엇을 어느 깊이로 테스트할지 기준은 없다
• 결함은 Jira로 꼼꼼히 추적한다
• 테스트 결과가 릴리즈 판단에 쓰이지 않는다. 개발 리드가 혼자 정한다
• 환경은 공용 스테이징 하나뿐이고 자주 깨진다

자가 체크리스트

• TMMi의 5단계 레벨을 순서대로 설명할 수 있다
• TPI Next가 TMMi와 어떻게 다른 방식으로 성숙도를 평가하는지 설명할 수 있다
• 이 모델들이 "인증"이 아니라 "진단 도구"로 쓰인다는 것을 설명할 수 있다
• 주어진 팀 상황을 보고 대략적인 성숙도 레벨을 진단할 수 있다
• 보이는 증상을 프로세스 쪽 원인으로 바꿔 말할 수 있다
• 레벨 2의 다섯 요건을 나열할 수 있다
• 레벨 3에서 "앞단 참여"가 왜 가장 어려운지 설명할 수 있다
• 단계를 건너뛸 수 없는 이유를 측정은 기록 위에서만 가능하다로 설명할 수 있다
• 개선 순서가 기록 → 표준화 → 측정 → 최적화임을 말할 수 있다
• TPI Next의 클러스터 개념과 도구만 올리는 개선의 한계를 설명할 수 있다
• 경영 보고와 내부 계획에 어느 모델이 맞는지 판단할 수 있다
• 자체 진단 문항으로 팀과 함께 체크하는 방법과 그 숨은 효과를 안다
• 개선 제안을 모델 이름이 아니라 불편과 숫자로 바꿀 수 있다
• 개선의 세 함정(문서화를 위한 문서화·레벨 사냥·한꺼번에 바꾸기)을 안다
• 성숙도 모델의 요구를 애자일의 산출물로 번역할 수 있다
• TMMi와 ISO 29119·25010의 차이를 구분할 수 있다

흔한 실수

• 성숙도 레벨을 조직의 우열을 가르는 순위표로 오해한다. 다음 개선 방향을 알려주는 로드맵일 뿐이다.
• 레벨 1인 팀에게 레벨 5의 관행(정량적 최적화)을 바로 요구한다. 단계를 건너뛴 개선 제안은 실행 불가능하다.
• 모델의 이름과 레벨 숫자만 외우고, 우리 팀 진단에는 적용해보지 않는다. 실무 가치는 실제 진단·개선 제안에 쓸 때 생긴다.
• 모델 이름으로 설득한다. "TMMi 레벨 2가 필요합니다"는 거의 통하지 않는다. 그 팀이 겪은 불편과 숫자로 바꿔 말한다.
• 측정부터 시작한다. 기록이 없으면 집계할 데이터가 없어 지표가 거짓이 된다. 기록이 먼저다.
• 읽히지 않는 문서를 만든다. 계획서 양식이 생겼는데 릴리즈 판단에 쓰이지 않으면 일만 늘어난 것이다. "누가 언제 읽나"를 먼저 답한다.
• 열 가지를 동시에 바꾼다. 하나도 안 바뀐다. 분기마다 하나가 현실적인 속도다.
• 도구만 올린다. 자동화가 매일 돌아도 무엇을 자동화할지 기준이 없으면 쉬운 것만 늘어난다.
• 애자일에는 안 맞는다고 결론 낸다. 형식이 아니라 기능으로 읽으면 인수기준·완료의 정의·회고가 그 역할을 한다.
• 모든 것을 표준화한다. 표준화는 자율성을 줄인다. 편차가 실제로 문제를 만드는 영역만 표준화한다.
• 노력의 양으로 성숙도를 판단한다. 열심히 하지만 방식이 사람마다 다르면 레벨 1이다.
• 바꾸기 전 숫자를 안 남긴다. 효과를 말할 수 없고, 다음 개선의 예산이 안 나온다.

참고 자료

• TMMi Foundation — TMMi 공식 모델 개요 — TMMi 5단계 레벨의 공식 정의
• TPI Next 공식 소개 — 핵심 영역 기반 평가 모델의 공식 설명
• CMMI Institute — 개발 전반의 프로세스 성숙도 모델. TMMi 와 범위가 다르다
• ISO/IEC/IEEE 29119 — 테스트 프로세스·문서 표준. "얼마나 정착됐나"가 아니라 "이렇게 하라"

이 커리큘럼 안에서

• 모듈 7 레슨 1~3 — 레벨 2의 요건 그 자체(케이스 저장소·데이터·환경)
• 모듈 7 레슨 5 — Three Amigos. 레벨 3의 "앞단 참여"를 실천하는 방법
• 모듈 7 레슨 8 — 완료의 정의. 애자일에서 표준 절차의 역할
• 모듈 7 레슨 9 — 사람 쪽 진단(스킬 매트릭스·버스 팩터·품질 비용)
• 모듈 4 — 리스크 기반. "테스트 전략" 영역의 내용
• 모듈 6 레슨 4~5 — 결함 추적과 지표. 측정의 토대
• 모듈 8 — ISO 29119. 문서·절차 표준
• 모듈 16·21 — 비기능 품질. ISO 25010 의 품질 특성

한 줄 정리 — 성숙도 모델의 쓸모는 레벨 숫자가 아니라 "없는 것에 이름을 붙이는 것" 이다. 순서는 기록 → 표준화 → 측정 → 최적화이고 건너뛸 수 없다(측정은 기록 위에서만 가능하다). 전달할 때는 모델 이름을 빼고 그 팀의 불편과 숫자로 바꾸고, 분기마다 하나씩 바꾼다. 그리고 형식이 아니라 기능으로 읽으면 애자일에도 그대로 적용된다.