#01tip:[PM 실무워크플로우 & 협업]QA/QC팀과 소통할 때 오해를 줄여주는 필수 IT 테크 용어 50선

IT 프로젝트 현장에서 릴리즈 직전 가장 극심한 긴장감이 감도는 곳은 단연 QA(Quality Assurance) 및 QC(Quality Control) 현장입니다. PM과 QA/QC팀 간의 커뮤니케이션이 어긋나면 결함의 심각도가 잘못 판단되어 치명적인 버그가 운영 환경에 그대로 배포되거나, 불필요한 재검수로 릴리즈 일정이 지연되는 대참사가 발생합니다.

50여 개 대형 프로젝트 현장에서 품질 관리 담당자들과 합을 맞추며 검증한 QA/QC팀과 소통할 때 오해를 줄여주는 필수 IT 테크 용어 50선을 실무 활용 맥락과 함께 정리합니다.

1. QA/QC 프로세스 & 방법론 영역 (01 ~ 10)

번호	용어	핵심 의미	PM 실무 활용 맥락
01	QA vs QC	프로세스 차원의 예방적 품질 보증(QA) vs 산출물 차원의 결함 검출 검수(QC)	“품질 향상을 위해 QC 단계의 단순 검수뿐만 아니라 QA 프로세스 개편이 필요합니다.”
02	Test Plan	테스트 범위, 일정, 리소스, 환경, 위험 관리 등을 정의한 품질 총괄 계획서	“스프린트 착수 시 QA팀이 작성한 테스트 플랜을 바탕으로 마일스톤을 확정합니다.”
03	Test Case (TC)	입력값, 실행 조건, 예상 결과를 명시한 개별 테스트 시나리오 단위	“신규 결제 기능 개편안에 대한 TC 수량이 총 150건으로 집계되었습니다.”
04	Test Suite / Scenario	연관된 Test Case들을 특정 기능/목적 단위로 묶어둔 집합	“회원 가입 및 로그인 플로우 전반을 검증하는 테스트 스위트를 실행해 주세요.”
05	Smoke Test	대규모 검수 전, 빌드가 안정적인지 주요 핵심 기능만 가볍게 확인하는 테스트	“신규 빌드 배포 직후 Smoke Test를 통과해야 본 검수(QA)에 진입합니다.”
06	Sanity Test	특정 버그 수정이나 소폭 변경 후 해당 기능이 올바르게 작동하는지 빠르게 검증	“핫픽스 반영 건은 전체 QA 대신 Sanity Test 수행 후 운영 배포합니다.”
07	Regression Test	코드 수정 후 기존 기능이 오작동하지 않는지 종합 재검증하는 회귀 테스트	“기존 결제 연동 로직 수정으로 인해 결제 관련 전체 리그레션 테스트가 필수적입니다.”
08	Exploratory Testing	작성된 TC 없이 QA 엔지니어의 경험과 직관에 의존하여 결함을 찾는 탐색적 테스트	“릴리즈 전 2시간 동안 전사 차원의 탐색적 테스트를 진행해 숨은 버그를 발굴합니다.”
09	User Acceptance Test (UAT)	실제 유저나 현업 부서가 비즈니스 요구사항 부합 여부를 최종 검증하는 인수 테스트	“개발 QA 완료 후 롯데닷컴 현업 마케팅팀의 UAT 승인을 거쳐 최종 릴리즈합니다.”
10	Boundary Value Analysis	경계점(최솟값, 최댓값, 경계선 한계값)에서 결함이 많이 발생함을 이용한 검수 기법	“쿠폰 할인율 입력 필드에 경계값 분석 기법을 적용해 0%, 100%, 101% 케이스를 검증했습니다.”

2. 결함(Defect/Bug) & 이슈 관리 영역 (11 ~ 20)

번호	용어	핵심 의미	PM 실무 활용 맥락
11	Defect Severity	결함이 시스템 작업 실행에 미치는 기술적 심각도 (Blocker, Critical, Major 등)	“결제 불가 건은 Severity가 Critical이므로 즉시 개발팀에 최우선 할당합니다.”
12	Defect Priority	비즈니스/시장에 미치는 영향에 따라 해당 버그를 얼마나 빠르게 고칠지의 우선순위	“오탈자는 Severity는 낮지만 메인 홈 노출 건이라 Priority는 High로 책정합니다.”
13	Bug Life Cycle	버그가 발견되어 등록(Open) $\rightarrow$ 수정(Resolved) $\rightarrow$ 재검수(Re-open/Closed)되는 전체 주기	“수정 완료 처리된 버그 티켓의 Bug Life Cycle 상태를 QA팀에서 Closed로 변경했습니다.”
14	Re-open	수정 완료 처리된 버그를 재검수했으나 여전히 동일 현상이 발생하여 다시 열리는 상태	“핫픽스 배포 후 동일 결함 재발로 인해 티켓이 Re-open 되었습니다.”
15	Deferred (Postponed)	버그는 맞으나 기술적 공수나 일정상 차기 버전에 고치기로 유예된 상태	“이번 스프린트 일정 준수를 위해 해당 UI 미세 틀어짐 버그는 Deferred 처리합니다.”
16	False Positive / Negative	정상인데 버그로 오인(False Positive) vs 버그인데 정상으로 통과(False Negative)	“테스트 환경 설정 문제로 오탐(False Positive) 이슈가 다수 발생했습니다.”
17	Steps to Reproduce (STR)	버그를 재현하기 위해 수행해야 하는 구체적인 절차 및 조건 기록	“개발진의 빠른 수정을 위해 버그 티켓에 재현 절차(STR)와 로그를 명확히 첨부하세요.”
18	Intermittent Bug	항시 발생하는 것이 아니라 특정 조건에서 간헐적으로 나타나는 버그	“간헐적 버그(Intermittent Bug) 추적을 위해 서버 가동 로그 수집 범위를 확대했습니다.”
19	Flaky Test	동일한 코드 기반임에도 실행할 때마다 성공/실패 결과가 달라지는 불안정한 테스트	“자동화 테스트 스크립트 중 Flaky Test 항목을 선별해 정비 작업에 착수합니다.”
20	Root Cause Analysis (RCA)	버그가 발생한 단순 표면 이유가 아닌 근본적인 시스템 원인을 분석하는 절차	“대형 장애 발생 후 QA, 개발, PM이 모여 장애 근본 원인 분석(RCA) 회의를 소집했습니다.”

3. 테스트 환경 & 데이터 영역 (21 ~ 30)

번호	용어	핵심 의미	PM 실무 활용 맥락
21	Test Environment (STG/DEV)	개발용(Dev), QA 검수용(Staging), 실운영(Prod) 등으로 분리된 테스트 서버	“스테이징(STG) 환경의 DB 데이터가 실운영과 동기화되어 있는지 체크가 필요합니다.”
22	Test Data (Dummy Data)	테스트 진행을 위해 인위적으로 생성한 검수용 가짜 데이터	“대용량 예약 테스트를 위해 결제 테스트 데이터 1만 건을 일괄 생성했습니다.”
23	Mock Server / Service	외부 연동 API가 아직 미완성일 때 가상의 응답값을 전달해 주는 모의 서버	“PG사 결제 API 개발 지연으로 Mock 서버를 띄워 QA 검수를 먼저 진행합니다.”
24	Stub vs Driver	하위 모듈이 없을 때 가짜 모듈 역할을 하는 Stub vs 상위 호출 역할을 하는 Driver	“백엔드 모듈 개발 미비로 Stub을 활용하여 프론트엔드 통합 QA를 수행했습니다.”
25	Test Bed	테스트를 수행할 수 있도록 하드웨어, 소프트웨어, 네트워크 등을 갖춘 종합 환경	“신규 모바일 앱 기기 호환성 검수를 위한 전용 Test Bed 시스템을 정비했습니다.”
26	Data Seeding	테스트에 필요한 초기 데이터나 상태값을 DB에 미리 주입해 두는 작업	“QA 개시 전 회원 등급별 데이터 시딩(Data Seeding) 작업이 먼저 이뤄져야 합니다.”
27	Clean Environment	잔여 데이터나 기존 캐시 없이 완전히 초기화된 순수 테스트 상태	“앱 설치/재설치 시 결함 검증을 위해 Clean Environment 환경에서 테스트합니다.”
28	Cross Browsing / OS	크롬, Safari, 크로스 안드로이드/iOS 등 다양한 환경에서 동일하게 작용하는지 검수	“티켓베이 웹 개편 건은 크로스 브라우징 QA 체크리스트 확정이 필수적입니다.”
29	Device Lab	실기기 검수를 위해 다양한 스마트폰, 태블릿 기기를 갖춰둔 테스트실	“디바이스 랩에 보유 중인 구형 갤럭시 모델에서 UI 틀어짐을 확인했습니다.”
30	Sandbox	외부 영향을 차단한 독립된 안전 환경에서 실행하는 테스트 공간	“신규 외부 솔루션 연동 시 안전을 위해 샌드박스 환경에서 선검증을 수행합니다.”

4. 자동화 테스트 & 성능 QA 영역 (31 ~ 40)

번호	용어	핵심 의미	PM 실무 활용 맥락
31	Test Automation	사람 대신 스크립트를 통해 검수를 자동으로 수행하는 체계 (Selenium, Appium 등)	“반복적인 리그레션 테스트 공수를 줄이기 위해 QA 자동화를 도입합니다.”
32	Load Testing	시스템이 견딜 수 있는 목표 트래픽 수치까지 임계 부하를 주어 반응을 검증	“여기어때 성수기 이벤트 전 동시 접속자 5만 명 기준 부하 테스트(Load Test)를 실시합니다.”
33	Stress Testing	임계 한계치를 초과하는 과도한 트래픽을 주어 시스템의 파괴 및 복구 능력을 검수	“서버가 다운되는 한계 지점 측정을 위해 스트레스 테스트를 강행했습니다.”
34	End-to-End (E2E) Test	유저 입장에서 로그인부터 결제까지 전체 시스템 흐름을 처음부터 끝까지 검증	“주요 핵심 유저 저니에 대해 E2E 자동화 스크립트를 작성해 주기적으로 돌립니다.”
35	Throughput / TPS	시스템이 1초당 처리할 수 있는 트랜잭션 수 (Transactions Per Second)	“트랜잭션 고도화 작업으로 목표 TPS 수치를 기존 대비 2배 이상 끌어올렸습니다.”
36	Soak Testing (Endurance)	높은 부하 상태를 장시간(예: 24시간) 유지하며 메모리 누수 등을 검증하는 테스트	“시스템 장기 가동 시 메모리 누수 발생 여부를 확인하기 위해 Soak Test를 진행했습니다.”
37	Spike Testing	갑작스럽게 폭증하는 트래픽이 몰렸을 때 시스템이 안정적으로 견디는지 검수	“타임세일 오픈 시 순간 트래픽 폭증 상황을 가상한 Spike Test를 거쳤습니다.”
38	Continuous Testing	CI/CD 파이프라인 내부에서 코드가 빌드될 때마다 자동으로 QA 스크립트가 도는 구조	“CI/CD에 Continuous Testing을 붙여 버그를 코드 작성 즉시 발견하도록 체계화했습니다.”
39	Headless Browser	UI 화면을 띄우지 않고 백그라운드 메모리상에서 빠르게 돌리는 브라우저 검수	“자동화 스크립트 실행 속도를 극대화하기 위해 Headless 브라우저 방식으로 돌립니다.”
40	Code Coverage	작성된 자동화 테스트 코드가 실제 전체 시스템 소스 코드를 얼마나 실행·검증했는지의 비율	“품질 보증을 위해 코드 커버리지 목표치를 80% 이상으로 설정했습니다.”

5. 품질 커버리지 & 릴리즈 지표 영역 (41 ~ 50)

번호	용어	핵심 의미	PM 실무 활용 맥락
41	Test Coverage	전체 기획 요구사항 및 기능 중에서 테스트가 완료된 영역의 비율	“현재 전체 요구사항 대비 테스트 커버리지는 92% 수준까지 도달했습니다.”
42	Pass / Fail Rate	전체 실행된 Test Case 수 중 성공(Pass) 및 실패(Fail)한 개수의 비율	“스프린트 QA 완료 기준은 TC Pass Rate 98% 이상 달성입니다.”
43	Defect Density	모듈 크기(LOC 등)나 기능 단위당 발생한 버그의 밀도 수치	“신규 모듈의 결함 밀도(Defect Density)가 높아 리팩토링 및 추가 QA를 지시했습니다.”
44	Defect Leakage	QA 검수 단계에서 발견되지 못하고 실운영(Prod) 환경으로 유출된 버그	“운영 결함 유출률(Defect Leakage)을 낮추기 위해 QA 체크리스트 항목을 보강합니다.”
45	Quality Gate	다음 단계(예: QA $\rightarrow$ Prod 배포)로 넘어가기 위해 반드시 충족해야 하는 최소 품질 기준	“Quality Gate 기준을 충족하지 못해 오늘 운영 배포 일정을 일시 정지합니다.”
46	Go / No-Go Decision	QA 결과 지표를 토대로 실제 서비스를 릴리즈할지(Go) 보류할지(No-Go) 내리는 최종 결정	“Critical 버그 미해결로 인해 금일 Go/No-Go 회의 결과 No-Go로 결정되었습니다.”
47	Traceability Matrix (RTM)	요구사항(Requirement)과 Test Case, 발견된 버그가 1:1로 추적 가능하도록 매핑한 도표	“요구사항 추적표(RTM)를 작성하여 누락된 검수 영역이 없는지 점검했습니다.”
48	Zero Defect Policy	배포 전 고위험 결함을 단 1건도 허용하지 않고 모두 해결한 뒤 릴리즈하는 품질 정책	“금융 연동 결제 모듈 시스템은 Zero Defect Policy 정책을 엄격히 적용합니다.”
49	Escapes / Escalation	QA 단계에서 해결이 어려운 치명적 기술 이슈를 C-Level이나 개발 리드에게 상향 보고하는 절차	“외부 솔루션 제약 이슈로 인해 QA 리드가 PM 및 CPO에게 에스컬레이션을 요청했습니다.”
50	Bug Trend Analysis	시간 흐름에 따라 등록되는 버그 수와 수정되는 버그 수의 추이를 나타낸 그래프	“버그 트렌드 차트의 수렴 곡선(S-Curve)을 확인한 뒤 안전하게 배포 일정을 확정했습니다.”

[7tipbox 요약]
QA/QC팀과의 성공적인 커뮤니케이션은 단순히 "버그 빠르게 고쳐주세요"라고 독촉하는 데 있지 않습니다.
‘상황에 맞는 핵심 품질 용어 50선의 맥락을 정확히 이해하고, 결함의 Severity/Priority와 Test Coverage 데이터를 기반으로 PMP 표준 체계(품질 통제, 리스크 대응, Go/No-Go 결정)를 일관되게 적용하는 시스템적 리더십’이 50개 이상의 대형 프로젝트 현장에서 최고 수준의 제품 품질과 무결점 배포를 만들어낸 10년 차 IT PM의 실무 핵심 노하우입니다.