핵심 인사이트

  1. QA(Quality Assurance, 품질 보증)는 "올바른 프로세스를 따르고 있는가?"를 확인하는 예방적 활동이고, QC(Quality Control, 품질 통제)는 "산출물이 요구사항을 충족하는가?"를 검사하는 탐지적 활동 — 프로세스 중심 vs 제품 중심의 근본적 차이가 있다.
  2. 현대 소프트웨어 품질 관리는 단순 QC(테스팅 후 검사)를 넘어 QA(설계 단계부터 품질 내재화)로 진화했으며, DevOps의 Shift-Left 원칙은 이를 더 앞당겨 개발자가 직접 단위 테스트를 작성하는 패러다임 전환을 이끌었다.
  3. ISO 9001의 품질경영시스템, CMMI의 프로세스 성숙도 모델, IEEE 730 소프트웨어 QA 계획 표준은 모두 QA 관점에서 품질을 "검사해서 심는 것이 아니라 프로세스에 심는 것"이라는 철학을 공유한다.

Ⅰ. QA vs QC 개념 대비

QA (Quality Assurance, 품질 보증):
  정의: 제품이 품질 요구사항을 만족하도록 보증하는
        체계적 활동 (프로세스 중심)
  목적: 결함 예방 (Defect Prevention)
  시점: 개발 전반에 걸쳐 지속적으로
  활동:
    - 소프트웨어 개발 프로세스 수립/심사
    - 코드 리뷰 표준화
    - 품질 계획 수립
    - 프로세스 감사 (Process Audit)
    - 팀 교육 및 역량 향상

QC (Quality Control, 품질 통제):
  정의: 품질 요구사항이 충족되는지 확인하는 검사/측정 활동
  목적: 결함 탐지 (Defect Detection)
  시점: 산출물 완성 후 검사
  활동:
    - 소프트웨어 테스팅 (단위/통합/시스템)
    - 코드 인스펙션 (완성 코드 검토)
    - 사양 준수 확인
    - 버그 리포팅 및 추적

핵심 구분:
  QA: 프로세스를 옳게 → 제품이 자연히 좋아짐
  QC: 제품을 직접 검사 → 결함 있는 제품 걸러냄

비유:
  QA: 공장 제조 공정 설계 및 감독
  QC: 공장 출고 전 제품 불량 검사

📢 섹션 요약 비유: QA vs QC는 요리 레시피 vs 맛 검사 — QA는 좋은 레시피(프로세스)를 만들어 맛있는 음식이 나오게, QC는 나온 음식을 직접 맛보고 기준 미달이면 폐기.

Ⅱ. QA 핵심 활동

소프트웨어 QA 주요 활동:

1. 품질 계획 수립 (Quality Planning):
   품질 목표 정의 (결함 밀도, 테스트 커버리지)
   품질 활동 일정 및 책임자 지정
   산출물: 소프트웨어 품질 보증 계획서 (SQAP)
   표준: IEEE 730

2. 프로세스 정의 및 개선:
   개발 방법론 표준화 (Agile, CMMI)
   코딩 표준 수립 (Google Style Guide 등)
   리뷰/인스펙션 절차 문서화

3. 감사 (Audit):
   내부 감사: 프로세스 준수 여부 확인
   외부 감사: 고객/인증기관의 품질 시스템 심사
   유형:
     제품 감사: 산출물 품질 확인
     프로세스 감사: 절차 준수 확인

4. 교육 및 역량 관리:
   개발자 코드 리뷰 교육
   테스트 기법 교육
   도구 사용 교육

5. 품질 지표 관리:
   결함 밀도: 결함 수 / 코드 라인 수 (KLOC 기준)
   리뷰 적발률: 리뷰에서 발견된 결함 / 전체 결함
   테스트 커버리지: 실행된 코드 경로 / 전체

CMMI (Capability Maturity Model Integration):
  Level 1 (Initial): 프로세스 없음, 혼돈
  Level 2 (Managed): 기본 프로세스 존재
  Level 3 (Defined): 표준화된 프로세스
  Level 4 (Quantitatively Managed): 측정 기반
  Level 5 (Optimizing): 지속적 개선

📢 섹션 요약 비유: QA는 항공사 안전 관리 부서 — 비행기를 직접 날리지 않고, 정비 절차가 제대로 되는지, 파일럿 훈련이 충분한지 감시하는 역할.

Ⅲ. QC 핵심 활동

소프트웨어 QC 주요 활동:

1. 정적 테스팅 (Static Testing):
   코드 실행 없이 검토
   인스펙션 (Fagan Inspection):
     계획 → 개요 → 준비 → 회의 → 재작업 → 추적
   워크스루 (Walkthrough): 비공식적 리뷰
   코드 리뷰 (Code Review): 동료 검토

2. 동적 테스팅 (Dynamic Testing):
   단위 테스트 (Unit Test): 함수/모듈 단위
   통합 테스트 (Integration Test): 모듈 간 연동
   시스템 테스트: 전체 시스템 검증
   인수 테스트 (UAT): 사용자 수용 확인

3. 테스트 설계 기법:
   블랙박스: 명세 기반 (경계값, 동치 분할)
   화이트박스: 구조 기반 (구문, 분기, 경로 커버리지)
   경험 기반: 탐색적 테스팅

4. 결함 관리:
   결함 발견 → 분류 → 수정 → 재테스트 → 종료
   도구: Jira, Bugzilla, Azure DevOps

5. 품질 메트릭:
   결함 제거 효율(DRE) = 출시 전 발견 결함 / 전체 결함
   목표: DRE ≥ 85%
   
   테스트 커버리지:
     구문 커버리지 (Statement Coverage)
     분기 커버리지 (Branch Coverage)
     조건 커버리지 (Condition Coverage)
     MC/DC: 항공 DO-178C 기준

📢 섹션 요약 비유: QC는 의약품 배치 검사 — 제조된 의약품을 샘플링해서 성분 함량, 불순물, 용량을 검사하고 기준 미달이면 해당 배치 전체 폐기.

Ⅳ. Shift-Left와 DevOps 품질

Shift-Left 원칙:
  전통: 개발 완료 → QC(테스팅) 시작
  Shift-Left: 요구사항 단계부터 QA/QC 통합

결함 수정 비용 증가 법칙 (IBM 연구):
  요구사항 단계: 1x
  설계 단계: 5x
  코딩 단계: 10x
  테스팅 단계: 20x
  출시 후: 100x

DevOps 품질 통합:

  개발자 → 코드 작성 + 단위 테스트 (TDD)
  CI 파이프라인:
    커밋 → 자동 빌드 → 단위 테스트 → 정적 분석
  CD 파이프라인:
    통합 테스트 → 보안 스캔 → 성능 테스트 → 배포

TDD (Test-Driven Development):
  Red: 실패하는 테스트 먼저 작성
  Green: 테스트를 통과하는 최소 코드 작성
  Refactor: 코드 정리 (테스트 보장 하에)

코드 품질 자동화:
  정적 분석: SonarQube, ESLint, Pylint
  보안 취약점: Snyk, SAST (Static Application Security Testing)
  코드 커버리지: JaCoCo (Java), Istanbul (JavaScript)
  품질 게이트 (Quality Gate):
    커버리지 < 80% → CI 빌드 실패
    Critical 취약점 존재 → 배포 차단

📢 섹션 요약 비유: Shift-Left은 교통사고 예방의 진화 — 사고 후 구급차(QC) → 신호등과 도로 설계 개선(QA) → 자동 긴급 브레이크(자동화 테스트)로 진화.

Ⅴ. 실무 시나리오 — 공공 SW 사업 QA/QC

공공기관 정보시스템 구축 품질 관리:

법적 근거:
  전자정부법 제57조: 정보화사업 품질관리 의무
  SW 진흥법: 소프트웨어 품질 인증 제도 (GS 인증)

SQAP (Software Quality Assurance Plan) 필수 항목:
  1. 사업 목적 및 품질 목표
  2. 형상 관리 계획 (변경 통제)
  3. 리뷰/인스펙션 계획
  4. 테스트 계획 (단위/통합/시스템/인수)
  5. 문제 보고 절차
  6. 품질 지표 및 측정 방법

실제 프로젝트 품질 계획 예시:
  목표: 결함 밀도 ≤ 0.5개/KLOC
  리뷰: 주요 산출물 100% 동료 리뷰
  테스트 커버리지: 구문 90%, 분기 80%
  인수 테스트: 사용자 대표 5명 참여

공공 SW 품질 문제 사례:
  건강보험 시스템 오류 (데이터 이관 QC 부실)
  → 대규모 환불 처리 비용 발생
  
  원인: QA(이관 프로세스 감사) 미흡
  교훈: 단순 기능 테스트(QC)만으로는 부족
         데이터 품질 검증 QA 프로세스 필요

감리 관점:
  감리 시 QA 증거:
    SQAP 존재 여부
    리뷰 완료 기록
    결함 관리 시스템 운영 여부
    품질 지표 달성 여부

📢 섹션 요약 비유: 공공 SW 품질 관리는 건축 감리 — QA는 설계도 및 시공 절차 감리(프로세스), QC는 완공 후 구조 안전 검사(제품). 둘 다 있어야 안전한 건물.

📌 관련 개념 맵

QA vs QC
+-- QA (품질 보증)
|   +-- 프로세스 중심, 예방
|   +-- SQAP, CMMI, ISO 9001
|   +-- 감사, 프로세스 정의
+-- QC (품질 통제)
|   +-- 제품 중심, 탐지
|   +-- 테스팅, 인스펙션
|   +-- 결함 밀도, DRE
+-- 진화
|   +-- Shift-Left
|   +-- TDD, DevOps CI/CD
|   +-- 자동화 품질 게이트

📈 관련 키워드 및 발전 흐름도

[전통 품질 관리 (1950s~)]
제조업 QC: 출고 전 검사 (統計的 品質管理)
Deming, Juran: 품질 철학
      |
      v
[소프트웨어 QA 등장 (1970s~)]
IEEE 730 SQAP 표준
NATO SW 공학 컨퍼런스 (품질 위기)
      |
      v
[CMMI 프로세스 성숙도 (1991)]
SEI CMM → CMMI
프로세스 기반 품질 체계화
      |
      v
[애자일과 TDD (2001~)]
Agile 선언: 테스트 코드 함께
TDD: Kent Beck
      |
      v
[DevOps Shift-Left (2010s~)]
CI/CD + 자동화 품질 게이트
SonarQube, SAST/DAST 통합
      |
      v
[현재: AI 기반 품질]
LLM 코드 리뷰 자동화
AI 테스트 케이스 생성

👶 어린이를 위한 3줄 비유 설명

  1. QA는 좋은 레시피 만들기, QC는 완성된 음식 맛보기 — QA가 좋은 요리 과정을 만들면 QC에서 불합격 음식이 줄어요!
  2. Shift-Left는 사고 예방 — 사고 난 후 수리보다, 처음부터 안전하게 만드는 게 훨씬 저렴해요.
  3. DevOps에서는 코드를 짜자마자 테스트 — "배포 전날 몰아서 검사"가 아니라 매 커밋마다 자동으로 품질을 확인해요!