대형 프로젝트 품질관리 실무 기록 : QA vs QC
품질관리(QM)를 이야기할 때, QA와 QC의 구분은 이론으론 쉬워 보이지만, 실무에선 늘 뒤엉켜 있죠. 특히 대형 프로젝트에서는 QA는 문서에만 존재하고, QC만 잔뜩 하게 되는 상황이 비일비재합니다. 이 글에서는 대형 SI 프로젝트 품질관리자의 입장에서 QA와 QC의 본질적 차이를 설명하고, 왜 둘 다 균형 있게 적용돼야 하는지 실제 사례 중심으로 풀어보겠습니다. 문서가 아닌, 사람과 행동에 기반한 품질 이야기를 시작해봅니다.
목차
QA와 QC의 차이, 정말 알고 계신가요?
QA(Quality Assurance)는 ‘품질을 확보하기 위한 체계와 활동’을, QC(Quality Control)는 ‘결과물의 품질을 확인하는 작업’을 의미합니다. QA는 프로세스를 다루고, QC는 산출물을 다룹니다. 그런데 실무에서는 테스트를 QA라고 부르곤 하죠. 테스트는 사실 QC에 속합니다. 진짜 QA는 설계 리뷰, 요구사항 기준 명확화, 결함 예방 정책 같은 ‘선제적 활동’입니다.
대형 프로젝트에서 QA가 사라지는 이유
제가 경험한 금융 프로젝트에서는 품질계획서가 무려 90페이지였지만, 실무에서 QA 역할은 존재하지 않았습니다. 그 이유는 명확했어요. ‘QA는 문서상 역할’이었고, 실제 업무는 QC에 집중돼 있었기 때문이죠. 모든 품질활동이 테스트 케이스 작성과 수행에만 집중되고, 설계나 분석 단계에서의 품질 확보는 뒷전이었습니다. QA가 제 기능을 하려면 프로젝트 초반부터 자리를 잡아야 합니다.
QC가 남긴 결과와 실무에서의 교훈
QC 중심으로 운영된 프로젝트에서는 당장은 문제를 잘 걸러내는 것 같지만, 본질적으로는 ‘사후 대응’에 그칠 수밖에 없습니다. 특히 요구사항이 흔들릴 때, QA 체계 없이 테스트만 늘리면 결과는 더 혼란스럽습니다. 테스트를 아무리 많이 해도, 잘못된 요구사항을 잡지 못하면 무의미하니까요. 결국 QC만으로는 프로젝트 품질을 보장할 수 없습니다.
- QC는 결함을 ‘발견’하지만, QA는 결함을 ‘예방’합니다.
- QC만 있는 환경은 ‘소방수 프로젝트’가 되기 쉽습니다.
- QA 없는 QC는 방어 없는 전쟁입니다.
QA를 실무에 되살리는 방법
QA를 실무에 적용하려면, 실천 가능한 작은 단위로부터 시작해야 합니다. 예를 들어 회의록에 ‘품질 리스크’ 항목을 추가하거나, 요구사항 변경 시 QA 확인 프로세스를 명시하는 것이죠. 제가 참여했던 공공 프로젝트에선 테스트보다 더 중요한 ‘요구사항 기준 명확화’ 절차를 QA 단계에 도입했는데, 후속 결함이 40% 줄어드는 결과를 얻었습니다. QA는 복잡한 정책보다 ‘작은 반복’이 핵심입니다.
QA와 QC를 비교하는 실무 테이블
| 구분 | QA (Quality Assurance) | QC (Quality Control) |
|---|---|---|
| 주요 목적 | 결함 예방 | 결함 탐지 |
| 초점 영역 | 프로세스 | 산출물 |
| 시점 | 계획, 분석, 설계 단계 | 구현 이후 |
| 핵심 활동 | 프로세스 감리, 리뷰, 표준 적용 | 테스트 수행, 오류 리포팅 |
| 실무 예시 | 요구사항 기준화, 리뷰 체크리스트 | 테스트케이스 작성, 결함 관리 |
프로젝트 품질관리를 위한 핵심 체크리스트
- QA와 QC의 구분을 팀 전체가 공유하고 있는가?
- 요구사항 기준 명확화 절차가 존재하는가?
- 테스트 외의 품질 활동(QA)이 기록되고 있는가?
- QA 결과를 정기적으로 리뷰하는 체계가 있는가?
- 품질 목표가 단지 ‘결함 수’가 아닌 ‘예방률’로 설정되어 있는가?
두 용어 모두 ‘품질’을 다루지만, 접근 방식이 다르기 때문입니다. 특히 실무에서는 테스트를 QA로 부르는 경향이 강합니다.
실제 QA는 프로세스 전반을 다루는 ‘예방적 활동’이고, 테스트는 QC 즉 ‘결과 확인’입니다.
결과 중심 문화, 일정 압박, 조직 내 QA 인식 부족이 원인입니다. 문서에는 있으나 실제 운영은 안 되는 경우가 많죠.
QA는 사전 예방 활동이기에 당장의 성과가 눈에 보이지 않아 예산과 일정에서 후순위로 밀립니다.
요구사항 기준 정의, 설계 리뷰 체크리스트 운영, QA 리뷰 회의체 구성부터 시작하는 것이 효과적입니다.
복잡한 절차보다, 실무에서 적용 가능한 ‘1장짜리 리뷰 기준’이 훨씬 효과적이에요.
이상적으론 분리하는 게 맞습니다. QA는 프로세스 관리자, QC는 테스트 실행자로 역할이 다릅니다.
동일인이 수행해도 무방하지만, 의사결정과 피드백 흐름은 분리되어야 오류를 줄일 수 있어요.
QA가 잘 작동하면 테스트 기간 중 결함 발생률이 절반 이상 줄고, 사용자 요구 변경에 유연하게 대응할 수 있습니다.
사후 조치보다 사전 품질 확보가 훨씬 경제적입니다. QA는 투자이고, QC는 보험이죠.
대형 프로젝트에서 품질관리는 단순히 ‘결함 잡기’가 아닙니다. QA와 QC는 서로 다른 목적과 도구를 가진 품질의 두 축이며, 둘 중 하나라도 약해지면 전체 프로젝트의 안정성이 흔들립니다. 실무에선 QC만 남고 QA는 사라지기 쉽지만, 진짜 문제는 그렇게 생긴다는 걸 알면서도 방치한다는 데 있습니다. 이 글을 통해 여러분이 실무에서 QA를 다시 세우는 데 작은 실마리를 얻으셨길 바랍니다.
QA, QC, 품질관리, 프로젝트품질, 테스트관리, 사전품질, 결함예방, 품질체계, 대형프로젝트, 소프트웨어테스트