소프트웨어 공학 100 주제 시리즈의 81번째 글이다. (카테고리: 품질·신뢰성·보안)

한 줄 요약

QC 는 만들어진 것이 요구사항을 만족하는지 확인하고 걸러 내는 활동이고, QA 는 만드는 방식이 요구사항을 만족하는 결과를 낼 것이라는 확신을 주는 활동이다. 둘 다 품질 경영의 일부이며, 테스트는 그중 QC 쪽에 속하는 한 가지 도구일 뿐이다.

왜 필요한가

많은 조직에서 “QA 팀” 은 릴리스 직전에 테스트를 돌리는 팀을 가리킨다. 이 용법이 굳어지면 세 가지 문제가 생긴다.

  • 품질이 마지막 단계의 일이 된다. 요구사항이 모호하고 설계 리뷰가 없어도 “QA 가 잡아 주겠지” 하고 넘어간다. 걸러 내는 단계가 아무리 촘촘해도, 걸러 낼 결함을 만드는 과정이 그대로면 같은 종류의 결함이 계속 들어온다.
  • “테스트 통과 = 품질” 이라는 착각. 테스트는 정한 기준에 맞는지를 확인한다. 기준 자체가 틀렸거나(요구사항 결함), 기준에 없는 성질(보안, 유지보수성)은 테스트를 아무리 늘려도 보이지 않는다.
  • 책임이 한 팀에 몰린다. 결함이 유출되면 “QA 가 못 잡았다” 가 된다. 결함을 만든 과정은 질문받지 않는다.

QA 와 QC 를 구분하는 이유는 용어 정리가 아니라 어디에 투자할지를 정하기 위해서다. 같은 결함을 매번 늦게 잡고 있다면 QC 를 늘릴 게 아니라 QA, 즉 과정을 고쳐야 한다.

핵심 개념

ISO 9000 의 정의

품질 경영 용어의 기준은 ISO 9000:2015 (Quality management systems — Fundamentals and vocabulary) 다. 핵심 정의는 다음과 같다(번역은 필자).

용어 (조항) 정의
품질 quality (3.6.2) 대상의 고유 특성 집합이 요구사항을 충족하는 정도
품질 경영 quality management (3.3.4) 품질에 관한 경영
품질 계획 quality planning (3.3.5) 품질 목표를 정하고 필요한 운영 프로세스와 자원을 정하는 데 초점을 둔 품질 경영의 일부
품질 보증 quality assurance (3.3.6) 품질 요구사항이 충족될 것이라는 확신을 제공하는 데 초점을 둔 품질 경영의 일부
품질 관리 quality control (3.3.7) 품질 요구사항을 충족하는 데 초점을 둔 품질 경영의 일부

두 가지를 읽어 낼 수 있다. 첫째, 품질은 “좋다” 가 아니라 요구사항 대비 충족 정도다. 요구사항이 없으면 품질을 말할 수 없다. 둘째, QA 와 QC 는 상하 관계가 아니라 품질 경영 아래 나란히 있는 두 초점이다. QA 는 “확신”, QC 는 “충족” 이다.

두 초점의 차이

구분 QA (보증) QC (관리)
대상 프로세스, 방법, 기준 산출물(코드, 빌드, 문서)
성격 예방 검출과 교정
질문 “이 방식이면 기준을 만족하는 결과가 나오는가?” “이 결과물은 기준을 만족하는가?”
소프트웨어 예 코딩 표준 수립, 리뷰 절차 설계, 프로세스 감사, 결함 근본 원인 분석, 교육 테스트 실행, 정적 분석 결과 판정, 인스펙션에서 결함 기록, 릴리스 게이트 판정
실패 시 대응 과정을 바꾼다 산출물을 고치거나 출하를 막는다

경계는 칼같지 않다. 코드 리뷰는 개별 변경의 결함을 찾는 순간에는 QC 지만, 리뷰 체크리스트를 만들고 리뷰 데이터를 모아 반복되는 결함 유형을 줄이는 순간에는 QA 다. 같은 활동이라도 무엇을 고치려는가로 나뉜다.

검증과 확인

ISO 9000 은 검증(verification, 3.8.12)과 확인(validation, 3.8.13)도 구분한다. 검증은 객관적 증거로 지정된 요구사항이 충족되었음을 확인하는 것이고, 확인은 특정한 의도된 사용이나 적용을 위한 요구사항이 충족되었음을 확인하는 것이다. 소프트웨어로 옮기면 검증은 “명세대로 만들었는가”, 확인은 “사용자가 실제로 쓰려는 목적에 맞는가” 다. 단위 테스트는 주로 검증이고, 사용자 수용 테스트나 베타 운영은 확인에 가깝다. 명세가 틀렸으면 검증은 전부 통과하고 확인에서 무너진다.

품질 요구사항은 어디서 오는가

“품질 요구사항” 을 구체화하는 공용 어휘가 ISO/IEC 25010:2023 의 제품 품질 모델이다. 2023년판은 기능 적합성, 성능 효율성, 호환성, 상호작용 능력(interaction capability), 신뢰성, 보안, 유지보수성, 유연성(flexibility), 안전(safety)의 아홉 특성을 둔다. 2011년판의 사용성·이식성이 이름을 바꾸었고 안전이 새로 들어왔다. QA 의 첫 일은 이 목록을 놓고 “우리 제품은 어떤 특성에 어떤 수준을 요구하는가” 를 합의하는 것이다. 합의가 없으면 QC 는 기능 테스트만 하게 된다.

소프트웨어 QA 표준

소프트웨어 영역에서 QA 활동을 정리한 표준은 IEEE 730 이다. 오래 쓰인 IEEE 730-2014 는 2026년 2월 IEEE SA 표준위원회가 승인한 IEEE 730-2026 (Standard for Software Quality Assurance Processes) 으로 대체되었다. 두 판 모두 SQA 를 개별 테스트가 아니라 소프트웨어 개발·유지보수 프로젝트의 SQA 프로세스를 시작·계획·통제·실행하는 요구사항으로 다룬다. 실무 원칙 하나를 덧붙이면, 프로세스를 평가하는 쪽은 개발 조직으로부터 어느 정도 독립성을 갖는 편이 좋다. 자기 과정을 자기가 감사하면 확신을 주기 어렵기 때문이다. SWEBOK 도 V4.0에서 Software Quality 를 별도 지식 영역으로 둔다.

품질 비용으로 보는 투자 배분

품질 관련 비용은 전통적으로 네 가지로 나눈다.

묶음 항목 소프트웨어 예 주로 관련된 활동
적합 비용 예방 (prevention) 교육, 코딩 표준, 설계 리뷰, 도구 정비 QA
적합 비용 평가 (appraisal) 테스트, 인스펙션, 정적 분석, 감사 QC
부적합 비용 내부 실패 출시 전 발견된 결함의 재작업, 재테스트 —
부적합 비용 외부 실패 장애 대응, 핫픽스, 보상, 신뢰 하락 —

QA 는 주로 예방에, QC 는 평가에 돈을 쓴다. 두 비용은 부적합 비용을 줄이기 위해 존재한다. Philip Crosby 가 Quality Is Free (McGraw-Hill, 1979)에서 말한 요지가 이것이다. 품질에 드는 돈은 적합 비용이 아니라 처음부터 제대로 하지 못해서 드는 돈이라는 것. 어떤 비율이 최적인지는 조직마다 다르므로 여기서는 수치를 들지 않는다. 대신 다음 절의 지표로 각자 측정하는 편이 낫다.

실무 적용

결함이 “어디서 생겨 어디서 잡혔는가” 를 기록한다

QA 가 과정을 고치려면 데이터가 필요하다. 가장 효과가 큰 단일 데이터는 결함마다 주입 단계와 발견 단계를 함께 남기는 것이다.

# 결함 주입/발견 단계 매트릭스와 단계별 유출률 계산 (데이터는 예시)
from collections import Counter

PHASES = ["요구사항", "설계", "구현", "통합테스트", "운영"]
defects = [  # (주입 단계, 발견 단계)
    ("요구사항", "운영"), ("요구사항", "통합테스트"), ("설계", "통합테스트"),
    ("구현", "구현"), ("구현", "구현"), ("구현", "통합테스트"),
    ("구현", "운영"), ("설계", "운영"), ("요구사항", "운영"), ("구현", "구현"),
]
m = Counter(defects)
print("주입\\발견 " + " ".join(f"{p:>6}" for p in PHASES))
for inj in PHASES[:3]:
    print(f"{inj:>8} " + " ".join(f"{m[(inj, f)]:>6}" for f in PHASES))

# 단계별 유출률: 해당 단계에서 주입됐지만 그 단계에서 잡히지 못한 비율
for inj in PHASES[:3]:
    total = sum(v for (i, _), v in m.items() if i == inj)
    caught_same = m[(inj, inj)]
    print(f"{inj}: 주입 {total}건, 같은 단계 검출 {caught_same}건, 유출률 {1 - caught_same/total:.0%}")

이 예시에서 요구사항 결함은 같은 단계에서 하나도 잡히지 않았고 대부분 운영에서 발견됐다. 대응은 통합 테스트를 늘리는 것(QC)이 아니라 요구사항 리뷰를 도입하는 것(QA)이다. 이런 판단을 숫자로 하게 해 주는 것이 매트릭스의 목적이다.

최소 SQA 계획 템플릿

# sqa-plan.yaml — 한 페이지 SQA 계획 (형식 예시)
product: order-service
quality_requirements:          # ISO/IEC 25010 특성 중 이 제품이 약속하는 것
  reliability: "주문 API 성공률 SLO 99.9% (4주 롤링)"
  security: "ASVS L2 대상 요구사항 충족"
  maintainability: "모듈 간 순환 의존 0, 핵심 도메인 테스트 필수"
prevention:                    # QA: 과정
  - 설계 변경은 ADR 작성 후 리뷰
  - 코딩 표준 + 린터 규칙 저장소에 버전 관리
  - 분기별 결함 근본 원인 분석, 상위 3개 유형에 대책 1개씩
appraisal:                     # QC: 산출물
  - PR 마다 리뷰 1인 이상 + CI(단위/통합/정적분석)
  - 릴리스 게이트: 차단 등급 결함 0, 회귀 스위트 통과
audit:
  owner: "개발 팀 외부의 리뷰어"  # 독립성
  cadence: quarterly
  checks: ["계획대로 리뷰가 수행됐는가", "게이트 예외가 기록됐는가"]

핵심은 prevention 과 appraisal 을 분리해 적는 것이다. 둘 중 한쪽이 비어 있으면 무엇이 빠졌는지 바로 보인다.

흔한 오해와 함정

  • “QA = 테스터” — 테스트 실행은 QC 다. QA 직군이 실제로 테스트만 한다면 이름과 일이 어긋나 있는 것이고, 그 조직에는 과정을 고치는 역할이 비어 있을 가능성이 크다.
  • “QC 는 구식이고 QA 만 하면 된다” — 예방이 완벽할 수 없으므로 검출은 늘 필요하다. CI 파이프라인의 자동 게이트는 현대적 QC 그 자체다.
  • “커버리지 100% 면 품질이 보증된다” — 커버리지는 테스트가 코드를 실행했다는 사실만 말한다. 요구사항 대비 충족이라는 품질의 정의와는 다른 축이다.
  • “QA 가 품질을 책임진다” — QA 는 확신을 주는 활동이지 품질을 만드는 활동이 아니다. 품질은 요구사항을 쓰고 설계하고 코드를 짜는 사람들이 만든다.
  • 지표가 목표가 되는 함정 — “발견 결함 수” 를 QC 성과로 삼으면 사소한 결함 쪼개기가, “유출 결함 0” 을 목표로 삼으면 결함 등록 회피가 생긴다. 지표는 과정을 고치는 데 쓰고 사람을 평가하는 데 쓰지 않는다.

관련 기초는 CS300 의 코드 리뷰, 단위 테스트, CI/CD 글에서 다뤘다. 정형 리뷰 기법은 SE100 #082 에서 다룬다.

확인 문제

  1. ISO 9000 의 정의에서 QA 와 QC 를 가르는 핵심 단어는 각각 무엇인가?
  2. 정적 분석 도구를 CI 에 넣어 경고가 있으면 머지를 막는 것은 QA 인가 QC 인가? 그 도구의 규칙 세트를 지난 분기 결함 데이터를 보고 조정하는 것은?
  3. 검증은 모두 통과했는데 확인에서 실패하는 상황의 예를 하나 들라.
  4. 결함 매트릭스에서 “설계 단계 주입, 운영 단계 발견” 이 가장 많다면 어떤 종류의 투자를 먼저 검토해야 하는가?

풀이

  1. QA 는 “확신 제공(providing confidence)”, QC 는 “충족(fulfilling)” 이다.
  2. 머지를 막는 것은 개별 산출물을 판정하고 거르는 QC 다. 결함 데이터를 보고 규칙 세트를 조정하는 것은 과정을 바꾸는 QA 다.
  3. 명세에 “검색 결과를 가격순으로 정렬” 이라고 적혀 있어 그대로 구현하고 테스트도 통과했지만, 실제 사용자는 거리순 정렬이 필요했던 경우. 명세(요구사항) 자체가 의도된 사용과 어긋났다.
  4. 설계 결함이 설계 단계에서 걸러지지 않는다는 뜻이므로 설계 리뷰, 아키텍처 결정 기록과 리뷰, 프로토타이핑 같은 예방·조기 평가 활동이다. 운영 직전 테스트를 늘리는 것은 비용이 큰 단계에서 잡는 방식이라 후순위다.

더 읽을거리 (References)