개념
팀이 셋을 넘으면 필요해지는 것
QA 팀이 하나일 때는 리드의 판단이 곧 기준이다. 팀이 셋, 다섯, 열로 늘면 문제가 달라진다. A팀은 치명 결함 1건이 있어도 출시하고 B팀은 막는다. C팀은 자동화 커버리지 80%를 요구하고 D팀은 측정도 안 한다. 경영진이 "우리 회사 제품들의 품질이 어떤가"를 물으면 답할 수 없다. 팀마다 다른 말을 하기 때문이다.
QMO(Quality Management Office, 품질 관리 조직)나 QA 조직 책임자의 일은 이 문제를 푸는 것이다. 결과물은 품질 운영 모델(Quality Operating Model) — 여러 팀이 함께 쓰는 원칙, 역할, 의사결정 구조, 공통 절차의 한 벌이다.
1. 품질 원칙 — 판단이 갈릴 때 돌아갈 문장
원칙은 규칙이 아니라 규칙이 없는 상황에서 판단의 방향을 정하는 문장 이다. 5~7개면 충분하고, 각 원칙은 실제 판단 장면으로 설명할 수 있어야 한다.
[품질 원칙 예]
P1. 고객 돈과 개인정보에 닿는 결함은 일정보다 우선한다.
P2. 품질 판단은 사람의 감이 아니라 합의된 기준과 데이터로 한다.
P3. 위험을 감수하는 결정은 할 수 있지만, 이름과 근거를 남긴다.
P4. 결함은 찾는 것보다 만들지 않는 것이 싸다 — 품질 활동을 앞단으로 옮긴다.
P5. 공통 기준은 최소한으로, 팀의 자율은 최대한으로.P5가 중요하다. 중앙 조직이 모든 것을 표준화하려 들면 팀은 형식만 맞추고 실질은 우회한다. 원칙은 꼭 같아야 하는 것 과 팀이 정해도 되는 것 의 경계를 선언한다.
2. 조직 모델 — 어디에 두는가
모듈 7 레슨 9에서 팀 수준의 배치를 봤다. 조직 수준에서는 세 모델이 있다.
| 모델 | 구조 | 강점 | 약점 |
|---|---|---|---|
| 중앙형 | QA 인력이 모두 QA 조직 소속, 프로젝트에 배정 | 기준 일관성, 인력 유연성, 전문성 축적 | 제품 팀과 거리, 병목 |
| 임베디드형 | QA가 각 제품 팀 소속 | 제품 이해, 빠른 피드백 | 기준 파편화, QA의 고립 |
| 하이브리드(허브 앤 스포크) | QA는 제품 팀에 소속, QMO가 기준·도구·역량을 관리 | 두 장점의 결합 | 이중 보고 관계의 긴장 |
최근 많은 조직이 하이브리드로 간다. 이때 QMO는 사람을 관리하지 않고 기준·도구·역량을 관리 한다. 인사 평가는 제품 팀 리더가, 전문성 평가와 성장 경로는 QMO가 맡는 식으로 역할을 나눈다. 이 경계를 문서로 정하지 않으면 이중 보고 관계가 갈등이 된다.
3. RACI — 누가 무엇을 결정하는가
역할이 겹치는 곳에서 갈등이 생긴다. RACI 표로 핵심 품질 활동의 책임을 정리한다.
- R(Responsible) 실행한다
- A(Accountable) 최종 책임지고 결정한다 — 활동마다 한 명
- C(Consulted) 사전에 의견을 준다
- I(Informed) 결과를 통보받는다
| 활동 | 제품 책임자 | 개발 리드 | QA 리드 | QMO | 보안팀 |
|---|---|---|---|---|---|
| 프로젝트 테스트 전략 승인 | C | C | R | A | I |
| 결함 심각도 판정 | I | C | A | I | C(보안 결함) |
| 결함 우선순위 결정 | A | C | R | I | C |
| 릴리스 Go/No-Go | A | R | R | C | C |
| 품질 게이트 예외 승인 | C | C | R | A | C |
| 공통 도구 선정 | I | C | C | A | C |
A가 두 명인 줄이 있으면 그 활동에서 반드시 충돌이 난다. A가 없는 줄이 있으면 아무도 결정하지 않는다.
4. 품질 게이트 표준과 예외 절차
품질 게이트는 모듈 14 레슨 4에서 CI 수준으로 봤다. 조직 수준에서는 생명주기 단계마다 통과 조건 을 표준으로 정한다.
| 게이트 | 시점 | 공통 조건(예) |
|---|---|---|
| G1 요구사항 | 개발 착수 전 | 수용 기준 작성, 위험 평가 완료, QA 리뷰 참여 |
| G2 개발 완료 | 시스템 테스트 진입 전 | 단위 테스트 통과, 정적 분석 치명 0, 스모크 통과 |
| G3 시스템 테스트 완료 | 인수 테스트 진입 전 | 종료 조건 충족, 미해결 치명 0 |
| G4 출시 | 운영 반영 전 | Go/No-Go 결정 기록, 롤백 계획, 모니터링 준비 |
게이트만큼 중요한 것이 예외 절차 다. 예외 절차가 없으면 게이트는 두 가지로 무너진다. 기준을 조용히 무시하거나, 기준 때문에 사업이 멈춘다. 예외는 허용하되 누가, 어떤 근거로, 어떤 보완 조치와 함께 승인했는지 기록한다(RACI의 "품질 게이트 예외 승인" 줄). 예외가 한 게이트에서 반복되면 그 기준이 현실과 맞지 않는다는 신호이므로 기준을 고친다.
5. 테일러링 규칙 — 모든 프로젝트에 같은 절차를 강요하지 않는다
직원 두 명이 2주 만에 만드는 사내 도구와 1년짜리 결제 시스템 개편에 같은 절차를 요구하면 작은 프로젝트는 서류에 질식한다. 테일러링 규칙은 프로젝트 특성에 따라 절차를 줄이거나 늘리는 공식 이다.
| 등급 | 기준(예) | 필수 산출물 | 게이트 |
|---|---|---|---|
| S | 사내 도구, 사용자 100명 미만, 개인정보 없음 | 테스트 체크리스트, 결함 목록 | G4만 |
| M | 고객 대면 기능, 결제·개인정보 간접 | 테스트 계획(약식), 케이스, 요약 보고 | G2, G4 |
| L | 결제·정산·개인정보 직접, 규제 대상 | 전략·계획·추적표·보고서 전체 | G1~G4 전부 |
등급 판정 자체를 프로젝트 시작 시 QMO와 프로젝트가 함께 한다. 이 판정표 하나로 "왜 우리만 서류가 많냐"는 불만의 대부분이 사라진다.
6. 도구·교육·역량의 중장기 계획
QMO는 1~3년 단위로 조직의 품질 역량에 투자한다.
- 도구 — 테스트 관리·결함 추적·자동화 프레임워크·성능 도구의 표준 선정(모듈 22 레슨 12의 다섯 축)
- 교육 — 역할별 학습 경로(모듈 42의 지도), 사내 자격, 외부 자격 지원
- 역량 — 조직 스킬 매트릭스(모듈 7 레슨 9)를 SFIA 수준으로 집계해 부족한 역량 파악
- 자동화 — 조직 공통 라이브러리와 파이프라인 템플릿
품질 운영 모델 설계서 — 한 벌로 묶기
[품질 운영 모델 v1.0 목차]
1. 목적과 적용 범위
2. 품질 원칙(5~7개)
3. 조직 모델과 보고 관계
4. 역할과 RACI
5. 생명주기 품질 게이트와 예외 절차
6. 테일러링 규칙(프로젝트 등급표)
7. 공통 지표와 보고 주기(레슨 3)
8. 도구·교육·역량 로드맵
9. 개정 절차(누가, 언제, 어떻게 이 문서를 고치는가)9번이 빠지면 문서는 1년 안에 현실과 멀어진다. 분기마다 예외 기록과 회고를 검토해 개정한다.
실무에서 왜 필요한가
조직이 커지면 품질 문제의 원인이 개인이 아니라 구조 로 옮겨 간다. 같은 유형의 장애가 다른 팀에서 반복되고, 기준이 달라 경영진 보고가 불가능하고, 결정권이 모호해 릴리스 직전에 충돌한다. 품질 운영 모델은 이 구조 문제에 대한 답이다. 규제 산업(금융·의료·자동차)에서는 감사·인증 대응을 위해서도 이런 문서화된 체계가 요구된다.
채용시장에서의 위치
QMO·QA 조직장 공고는 "QA 프로세스 수립", "품질 표준 체계 구축", "전사 품질 거버넌스"라는 말로 나온다. 면접에서 원칙·RACI·게이트·테일러링을 하나의 설계로 설명할 수 있으면 조직 수준의 사고를 가진 사람으로 읽힌다.