개념
QA와 QC는 이론적으로 다르다
- QA (Quality Assurance, 품질 보증): 프로세스에 초점. "품질 좋은 결과물이 나오도록 하는 절차를 우리가 따르고 있는가"를 관리한다. 예방적(preventive)이다 — 결함이 생기기 전에 막으려 한다. 요구사항 리뷰 프로세스 개선, 코드 리뷰 기준 수립, 테스트 전략 수립 같은 활동이 여기 속한다.
- QC (Quality Control, 품질 관리): 결과물에 초점. "이 특정 산출물이 품질 기준을 만족하는가"를 검사한다. 발견적(detective)이다 — 이미 만들어진 것에서 결함을 찾는다. 테스트 케이스 실행, 결함 리포팅이 여기 속한다.
- 테스터(Tester): 실제로 테스트 활동을 수행하는 사람. QC 활동의 실행 주체에 가깝지만, 테스트 설계·전략까지 관여하면 QA 활동도 함께 한다.
이론적으로는 이렇게 나뉘지만, 실무에서는 이 구분이 거의 흐려진다. "QA 엔지니어"라는 직함을 가진 사람이 테스트 케이스도 실행하고(QC), 테스트 전략도 짜고(QA), 프로세스 개선도 제안한다. 채용공고의 직함(QA Engineer, Test Engineer, QC Analyst, SDET)만으로 업무 범위를 단정하지 말고, 직무 설명(JD)의 실제 책임 항목을 봐야 한다.
조직에 따라 QA가 배치되는 방식이 다르다
- 임베디드형: QA가 개발팀 안에 소속되어 스프린트마다 함께 일한다. 애자일 조직에서 흔하다. 빠른 피드백이 장점, 다른 팀과의 기준 통일이 어려울 수 있다.
- 독립 QA팀형: QA가 별도 팀으로 존재하며 여러 개발팀을 지원한다. 표준화된 프로세스와 전문성 확보가 장점, 개발과의 커뮤니케이션 오버헤드가 단점이 될 수 있다.
- QA 길드/커뮤니티형: 각 팀에 QA가 흩어져 있지만, 정기적으로 모여 기준과 도구를 맞춘다. 두 방식의 장점을 절충하려는 시도다.
조직 구조는 QA가 릴리즈를 막을 권한이 있는지, 테스트 전략을 얼마나 주도할 수 있는지에 직접 영향을 준다. 면접에서 "이 회사는 QA를 어떻게 조직하나요?"를 물어보면 실제 업무 범위를 가늠하는 데 도움이 된다.
QA의 태도(Mindset)
기술보다 태도가 QA를 정의한다는 말이 있다. 핵심은 세 가지다.
- 호기심 있는 회의주의: "이게 정말 명세대로일까?"를 기본값으로 의심하되, 트집 잡기가 아니라 더 나은 제품을 만들기 위한 태도로 접근한다.
- 사용자 대변: 개발팀 내부에서 유일하게 "실제로 이걸 쓰는 사람 입장"을 계속 상기시키는 역할을 자처한다.
- 비난 없는 커뮤니케이션: 결함을 "누가 잘못했나"가 아니라 "무엇이 어떻게 다른가"로 전달한다. 이건 모듈 6(결함 관리와 보고)에서 구체적으로 다룬다.
QA 커리어는 한 방향만 있지 않다
- 관리 트랙: 주니어 테스터 → QA 엔지니어 → 시니어/리드 QA → QA 매니저
- 기술 트랙: QA 엔지니어 → 자동화 엔지니어(SDET) → 테스트 아키텍트
- 인접 분야로 이동: DevOps/플랫폼 엔지니어링, 프로덕트 매니저, 그리고 최근엔 AI QA(스테이지 6에서 다룬다) 같은 새 전문 분야로도 이동한다
"관리자가 되는 것"만이 성장이 아니다 — 자동화·성능·보안·AI 검증처럼 깊이 파고드는 기술 전문성도 동등한 성장 경로다. 이 커리큘럼의 스테이지 4(자동화), 5(비기능), 6(AI)이 각각 이런 전문화 방향과 맞닿아 있다.
실무에서 왜 필요한가
QA와 QC, 테스터의 차이를 알고 있으면 채용공고를 읽을 때 실제로 어떤 일을 하게 될지 가늠할 수 있다. "QC 엔지니어"로 채용됐는데 막상 테스트 전략 수립까지 요구받거나, 반대로 "QA 리드"로 뽑혔는데 실행 업무만 반복해야 한다면 기대와 실제가 어긋난다. 조직 구조를 이해하면 입사 후 "내가 릴리즈를 막을 권한이 있는지, 있다면 어느 선까지인지"도 미리 가늠할 수 있다.
채용시장에서의 위치
한국 채용시장에서도 "QA 엔지니어", "테스트 엔지니어", "SDET(Software Development Engineer in Test)", "QA 매니저" 같은 직함이 회사마다 다른 범위로 쓰인다. 스타트업은 한 사람이 QA·QC·자동화를 전부 겸하는 경우가 많고, 대기업·제조업(특히 의료기기·자동차 같은 규제 산업)은 QA와 QC가 조직적으로 분리되어 있는 경우가 흔하다. 이력서에 "QA"라고 쓰기 전에, 실제로 자신이 한 일이 프로세스 개선(QA)에 가까운지 테스트 실행(QC)에 가까운지 구분해서 적으면 채용 담당자에게 더 명확하게 전달된다.
실습 과제
과제 1 — 공고 분석하기 (10분)
아래 두 가상의 채용공고 설명을 읽고, 이론적 정의에 따라 QA에 가까운지 QC에 가까운지, 그리고 왜 그렇게 판단했는지 적는다.
공고 A: "테스트 케이스를 작성·실행하고 결함을 리포팅합니다. 릴리즈 전 회귀 테스트 스위트를 수행합니다."
공고 B: "테스트 전략을 수립하고, 팀의 테스트 프로세스를 개선하며, 품질 지표를 정의하고 추적합니다."
과제 2 — 나의 방향 그려보기 (10분)
관리 트랙과 기술 트랙 중 지금 더 끌리는 쪽은 무엇인지, 그 이유를 2~3문장으로 적는다. 아직 잘 모르겠다면 "왜 아직 판단하기 이른지"를 적어도 된다 — 이 커리큘럼을 끝까지 밟아가며 다시 답해봐도 좋다.
자가 체크리스트
- QA(프로세스)와 QC(결과물)의 이론적 차이를 설명할 수 있다
- 실무에서 이 구분이 왜 자주 흐려지는지 설명할 수 있다
- 조직에 QA가 배치되는 세 가지 방식(임베디드/독립팀/길드)을 구분할 수 있다
- QA의 태도 세 가지(회의주의, 사용자 대변, 비난 없는 커뮤니케이션)를 설명할 수 있다
- QA 커리어가 관리 트랙 외에 기술 트랙으로도 뻗어간다는 것을 안다
흔한 실수
- QA와 QC를 완전히 같은 말로 취급한다. 실무에서 섞여 쓰이는 건 맞지만, 이력서나 면접에서 "내가 한 일이 정확히 무엇이었는가"를 설명할 때는 구분할 수 있어야 설득력이 생긴다.
- QA를 "릴리즈를 막는 사람"으로만 정의한다. 막는 것 자체가 목적이 아니라, 리스크를 근거로 판단을 돕는 역할이다(모듈 4에서 Go/No-Go 판단을 다룬다).
- 성장을 관리자가 되는 것으로만 생각한다. 기술 트랙(자동화, 성능, AI 검증 전문가)도 관리 트랙 못지않게, 때로는 더 높은 시장 가치를 가진 경로다.
참고 자료
- ISTQB Glossary — Quality Assurance / Quality Control — 두 용어의 공식 정의
- ASQ — What is Quality Assurance vs Quality Control? — 제조업 기원의 QA/QC 개념을 소프트웨어에 적용한 설명