핵심 인사이트
- 본질: QA (Quality Assurance, 품질 보증)는 올바른 프로세스로 품질을 예방하는 활동이고, QC (Quality Control, 품질 통제)는 만들어진 산출물에서 결함을 검출하는 활동이다.
- 가치: QA와 QC를 분리해 이해해야 품질 비용 (CoQ, Cost of Quality)을 최적화할 수 있으며, 결함을 늦게 잡을수록 수정 비용이 급격히 커진다는 사실을 관리 체계에 반영할 수 있다.
- 판단 포인트: 테스트만 많이 한다고 QA가 되는 것은 아니다. QA는 표준·절차·감사·예방 체계이고, QC는 리뷰·테스트·측정으로 실제 결함을 찾아내는 실행 단계다.
Ⅰ. 개요 및 필요성
소프트웨어 품질은 출시 직전 검사만으로 확보되지 않는다. 요구사항이 애매하거나 개발 절차가 들쭉날쭉하면, 테스트 단계에서 아무리 많은 결함을 찾아도 재작업 비용이 커지고 일정은 무너지기 쉽다. 그래서 품질 관리는 처음부터 두 축으로 나뉜다. 하나는 결함이 생기지 않도록 프로세스를 설계하는 QA이고, 다른 하나는 실제 산출물에서 결함을 검출하는 QC다.
QA는 조직과 프로젝트가 표준 절차를 따르도록 만드는 예방 활동이다. 코딩 표준 수립, 형상 관리 절차, 리뷰 프로세스, 테스트 전략, 프로세스 감사가 여기에 속한다. QC는 요구사항 명세서, 설계서, 코드, 빌드 결과물, 운영 릴리스 후보를 검사해 품질 기준 충족 여부를 확인하는 발견 활동이다. 두 개념을 구분해야 품질을 "만드는 활동"과 "검사하는 활동"을 혼동하지 않게 된다.
- 📢 섹션 요약 비유: QA는 요리 전에 주방과 레시피를 정돈하는 일이고, QC는 완성된 음식을 맛보고 기준에 맞는지 확인하는 일이다. 주방이 엉망이면 맛보기만으로는 문제를 다 막을 수 없다.
Ⅱ. 아키텍처 및 핵심 원리
QA와 QC의 가장 중요한 차이는 초점과 시점이다. QA는 프로세스 중심이며 사전에 작동하고, QC는 제품 중심이며 산출물이 나온 뒤에 작동한다. 하지만 둘은 분리된 부서 이름이 아니라 하나의 품질 루프를 이룬다. QA가 기준과 절차를 만들고, QC가 그 결과를 측정해 다시 QA 개선으로 되돌려 주는 구조다.
아래 그림은 SDLC (Software Development Life Cycle, 소프트웨어 개발 생명주기) 전반에서 QA와 QC가 어떻게 배치되는지를 보여 준다.
┌────────────────────────────────────────────────────────────────────────────┐
│ QA and QC across SDLC: prevention + detection │
├────────────────────────────────────────────────────────────────────────────┤
│ Requirements ─ Design ─ Build ─ Test ─ Release ─ Operate │
│ │ │ │ │ │ │
│ └────── QA: standards, process, audit, training, review rules ─────┘ │
│ │ │ │ │
│ └── QC: inspection, test, defect measure, acceptance │
│ │
│ Feedback loop: QC data ──▶ root cause analysis ──▶ QA process improvement │
└────────────────────────────────────────────────────────────────────────────┘
이 그림의 핵심은 QA와 QC가 경쟁 관계가 아니라 순환 관계라는 점이다. QA가 없으면 QC는 결함을 뒤늦게 많이 잡게 되고, QC가 없으면 QA는 실제 품질 수준을 증명할 근거를 잃는다.
| 구분 | QA | QC |
|---|---|---|
| 초점 | 프로세스 | 산출물 |
| 목적 | 결함 예방 | 결함 발견 |
| 시점 | 사전·전 과정 | 산출물 생성 후·검증 시점 |
| 대표 활동 | 표준 수립, 감사, 교육, 절차 정의 | 리뷰, 테스트, 검수, 결함 측정 |
| 책임 범위 | 조직 차원의 품질 체계 | 프로젝트/제품 단위 품질 확인 |
품질 비용 관점에서도 차이가 분명하다. QA는 예방 비용과 일부 평가 비용을 차지하지만, 이를 줄이면 내부 실패 비용과 외부 실패 비용이 급격히 커진다. 그래서 품질 관리는 "검사비를 줄이는 일"이 아니라 "예방과 평가에 적절히 투자해 실패 비용을 줄이는 일"로 봐야 한다.
- 📢 섹션 요약 비유: QA는 우산을 챙기는 일이고, QC는 비를 맞은 뒤 옷이 젖었는지 확인하는 일이다. 우산을 챙기면 검사할 일 자체가 줄어든다.
Ⅲ. 비교 및 연결
QA와 QC를 제대로 이해하려면 테스트, 인스펙션, 표준, 성숙도 모델과의 연결을 같이 봐야 한다. 테스트는 대표적인 QC 활동이지만, 테스트 전략을 정의하고 자동화 기준을 세우는 일은 QA에 가깝다. CMMI (Capability Maturity Model Integration)나 ISO 9001은 조직의 프로세스 성숙도와 품질 체계를 다루므로 QA 측면이 강하고, ISO/IEC 25010은 제품 품질 특성을 정의하므로 QC 기준으로 활용된다.
| 연결 개념 | QA와의 관계 | QC와의 관계 |
|---|---|---|
| ISO 9001 | 품질경영시스템의 틀 제공 | 직접 검사 기준보다는 관리 체계 기준 |
| CMMI | 조직 프로세스 성숙도 향상 | 간접적으로 품질 수준에 영향 |
| ISO/IEC 25010 | 품질 특성을 사전에 정의 | 기능성·성능·보안성 등을 실제 측정 |
| 인스펙션 (Inspection) | 리뷰 절차와 체크리스트를 제도화 | 산출물 결함을 공식적으로 검출 |
| 테스트 자동화 | 자동화 정책과 기준 수립 | 실행으로 결함을 반복 검출 |
또한 DevOps 환경에서는 Shift Left가 중요하다. 이는 QC를 개발 초기로 당기자는 뜻이지만, 동시에 QA 관점에서 요구사항 명확화, 코드 리뷰 문화, 정적 분석 기준을 앞단에 심는 일과 연결된다. 결국 품질 수준은 QA와 QC 중 하나를 선택하는 것이 아니라, 둘을 어디서 어떻게 연결하느냐에 의해 결정된다.
- 📢 섹션 요약 비유: QA는 학교의 수업 규칙과 교과 과정이고, QC는 시험과 채점이다. 규칙이 좋아도 시험이 없으면 실력을 모르고, 시험만 많아도 수업이 엉망이면 성적이 안 오른다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 가장 흔한 오류는 "품질팀이 테스트하니 QA가 되고 있다"고 생각하는 것이다. 그러나 테스트 수행은 QC일 뿐이며, 결함이 반복 발생하는 구조를 고치는 활동은 QA다. 예를 들어 릴리스마다 동일한 유형의 결함이 나온다면 테스트 케이스를 늘리는 것만으로는 부족하다. 요구사항 템플릿, 코드 리뷰 항목, 배포 승인 절차, 자동화 파이프라인 기준을 손봐야 한다.
실무 체크리스트
- 반복 결함의 근본 원인을 프로세스 수준에서 분석하고 있는가?
- 테스트, 인스펙션, UAT (User Acceptance Test, 사용자 인수 테스트)를 QC로 분류해 관리하고 있는가?
- QA 메트릭과 QC 메트릭을 분리하고 있는가? 예: 프로세스 준수율 vs 결함 밀도
- 외부 실패 비용을 줄이기 위해 운영 결함 데이터를 QA 개선에 반영하고 있는가?
대표 안티패턴
-
QA를 테스트 부서의 별칭처럼 사용하는 경우
-
문서와 절차만 많고 실제 QC 데이터가 없어 개선이 닫히지 않는 경우
-
운영 장애를 개인 실수로만 보고 프로세스 개선으로 연결하지 않는 경우
-
📢 섹션 요약 비유: 시험 점수가 낮을 때 답안지만 더 많이 채점하는 것은 QC 강화이고, 공부 방법과 수업 구조를 바꾸는 것은 QA 강화다. 같은 문제를 반복한다면 보통 뒤쪽보다 앞쪽을 손봐야 한다.
Ⅴ. 기대효과 및 결론
QA와 QC를 균형 있게 운영하면 결함 예방, 조기 발견, 재작업 감소, 고객 신뢰 향상이라는 효과를 동시에 얻을 수 있다. QA는 조직 차원의 품질 문화를 만들고, QC는 실제 품질 수준을 수치와 사례로 보여 준다. 두 활동이 선순환하면 품질 비용 총액은 낮아지고, 출시 속도와 안정성의 균형도 좋아진다.
반대로 QA 없이 QC만 강화하면 품질은 항상 뒤늦게 잡히고, QC 없이 QA만 강조하면 현장의 실질 품질이 검증되지 않는다. 따라서 QA와 QC는 "예방 vs 발견"이라는 역할 분담 속에서 함께 설계해야 한다. 기억할 핵심은 품질이 검사로만 생기는 것이 아니라, 올바른 프로세스 위에서 검사와 피드백이 반복될 때 비로소 안정적으로 축적된다는 점이다.
- 📢 섹션 요약 비유: QA와 QC는 자전거의 두 바퀴와 같다. 한쪽만 커도 앞으로 나아가기 어렵고, 둘이 함께 굴러야 품질이라는 방향으로 안정적으로 움직일 수 있다.
관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| CoQ (Cost of Quality) | 예방·평가·실패 비용을 묶어 품질 투자 효율을 판단 |
| CMMI | QA 중심의 프로세스 성숙도 평가 모델 |
| ISO 9001 | 조직 차원의 품질 경영 체계를 규정 |
| ISO/IEC 25010 | QC에서 제품 품질을 평가하는 대표 기준 |
| Inspection | 실행 전 정적 산출물 결함을 찾는 QC 기법 |
| Shift Left | QC를 앞당기고 QA와 조기 연결하는 방향 |
관련 키워드 및 발전 흐름도
품질 목표 정의
│
▼
QA: 표준 · 절차 · 교육 · 감사
│
▼
QC: 리뷰 · 테스트 · 검수 · 결함 측정
│
▼
결함 데이터 · 고객 이슈 수집
│
▼
원인 분석 · 프로세스 개선 · 지속적 품질 향상
이 흐름은 품질 관리가 일회성 검사보다 예방과 피드백의 반복 체계라는 점을 보여 준다.
어린이 비유 설명
- QA는 숙제를 틀리지 않게 하려고 공부 방법과 규칙을 잘 만드는 거예요.
- QC는 숙제를 다 한 뒤에 정말 맞았는지 확인하는 거예요.
- 둘 중 하나만 하면 자꾸 같은 실수를 하게 되니까, 미리 준비하고 나중에 확인도 해야 해요.