개념
같은 결함, 다른 질문
결제 화면에서 카드사 응답이 5초 넘게 걸리면 "결제 실패" 메시지가 뜨는 결함이 있다고 하자.
결함 탐지 중심 QA는 이렇게 보고한다. "카드사 응답 지연 시 결제 실패 메시지 노출. 실제로는 승인 완료. 재현율 약 3%. 심각도: 주요."
제품 품질 엔지니어는 질문을 더 한다. 이 3%는 전체 결제의 몇 건인가? 이 사용자들은 다시 결제를 시도하는가, 이탈하는가? 다시 시도하면 중복 결제가 생기는가? 고객센터 문의 중 이것과 관련된 것은 몇 건인가? 이 결함이 결제 완료율에 몇 %p 영향을 주는가? 그리고 보고서는 이렇게 바뀐다. "월 약 1,800건 발생 추정. 이 중 40%가 재결제 시도, 그중 일부 중복 승인. 관련 고객 문의 월 210건. 결제 완료율 약 0.8%p 손실 추정. 수정 시 기대 효과: 결제 완료율 회복 + 문의 감소."
앞의 보고서는 개발팀의 할 일 목록에 들어간다. 뒤의 보고서는 제품 로드맵 회의의 안건 이 된다.
결함 탐지 QA와 제품 품질 엔지니어
| 결함 탐지 중심 QA | 제품 품질 엔지니어 | |
|---|---|---|
| 주 관심 | 명세대로 동작하는가 | 사용자가 목표를 이루는가, 제품 목표에 기여하는가 |
| 활동 시점 | 개발 후 ~ 출시 전 | 기획 단계 ~ 출시 후 운영까지 |
| 데이터 | 테스트 결과, 결함 | 테스트 결과 + 고객 문의 + 사용 데이터 + 운영 로그 |
| 결과물 | 결함 보고서, 테스트 결과 | 여정별 품질 위험, 통합 분석, 전후 효과가 측정된 개선안 |
| 협업 상대 | 개발팀 | 기획·개발·디자인·운영·CS·데이터 |
| 성과 | 탈출 결함 감소 | 제품 지표 개선에 대한 기여 |
제품 품질 엔지니어가 결함 탐지를 안 하는 것이 아니다. 결함 탐지는 여전히 기반이다. 다만 탐지 결과를 제품의 맥락에 놓는 일 이 추가된다.
가치 흐름에서 품질의 자리
가치 흐름(value stream)은 아이디어가 사용자 가치로 바뀌기까지의 전체 흐름이다.
아이디어 → 발견·검증 → 요구 정의 → 설계·개발 → 출시 → 사용 → 학습
│ │ │ │ │ │ │
품질 활동: 위험 가설 수용 기준· 테스트 출시 운영 문의·
(레슨 2) 규칙 검토 실행 판정 모니터링 데이터 분석
(레슨 5·6) (레슨 3·4)
│
◀───────── 개선안(레슨 7) ────────────┘전통적인 QA는 가운데 "설계·개발 → 출시" 구간에 있다. 제품 품질 엔지니어는 양 끝으로 넓힌다. 앞쪽에서는 요구 정의 단계에 품질 위험을 가져가고, 뒤쪽에서는 사용 데이터에서 품질 문제를 발견해 다시 앞으로 보낸다. 이 되먹임 고리가 품질 피드백 루프 다.
출시 후 품질 — 테스트가 못 보는 것
출시 전 테스트는 아무리 잘해도 볼 수 없는 것이 있다.
| 출시 전 테스트가 못 보는 것 | 출시 후 발견 경로 |
|---|---|
| 실제 사용자의 행동 패턴 | 사용 데이터, 퍼널 분석 |
| 실제 기기·네트워크·데이터의 다양성 | 오류 로그, 크래시 리포트(모듈 17 레슨 4) |
| 사용자가 "결함"이라고 느끼는 사양 | 고객 문의, 앱 리뷰 |
| 장시간·대량 사용의 누적 효과 | 운영 모니터링, SLO(모듈 14 레슨 7) |
제품 품질 엔지니어는 이 경로들을 정기적으로 본다. 매주 고객 문의 상위 유형, 오류 로그 상위 항목, 핵심 퍼널의 단계별 이탈률을 확인하고, 이상이 있으면 원인을 추적한다.
완료 기준과 품질 우선순위의 합의
제품 품질 엔지니어의 중요한 일 중 하나는 제품 팀과 "무엇이 되면 완료인가" 를 합의하는 것이다. 모듈 2 레슨 4의 수용 기준이 기능 단위라면, 여기서는 제품 단위의 품질 기준이다.
[제품 품질 기준 예 — 결제 영역]
기능 결제 수단별 핵심 흐름 자동 회귀 100% 통과
신뢰성 결제 API 오류율 0.1% 미만, 카드사 지연 시 사용자 안내 존재
경험 결제 단계 이탈률 전 분기 대비 악화 없음
운영 결제 관련 고객 문의 주간 추이 모니터링, 급증 시 알림이 기준은 기획·개발·운영과 함께 정하고, 기준 간 우선순위(예: 신뢰성 > 경험 > 신규 기능)도 합의한다. 합의된 우선순위가 있으면 "이 결함을 이번에 고칠까"의 논쟁이 짧아진다.
제품 품질 엔지니어의 한 주
월 지난주 고객 문의·오류 로그 상위 10개 검토, 신규 패턴 표시
화 다음 스프린트 기획 리뷰 참여 — 여정별 품질 위험 제시
수 테스트 설계·실행(여전히 기반 업무)
목 데이터 팀과 결제 이탈 원인 분석 — 결함 데이터와 퍼널 데이터 결합
금 개선안 1건 정리(문제·근거·선택지·기대 효과), 지난 개선안의 효과 측정실무에서 왜 필요한가
많은 조직에서 QA는 "출시를 막는 부서"로 인식된다. 제품 품질 엔지니어의 관점을 가지면 QA는 "제품 지표를 개선하는 부서" 가 된다. 이 차이는 예산과 인력, 의사결정 참여에서 드러난다. 또 결함의 우선순위 논쟁에서 "사용자 영향과 사업 영향"의 언어를 쓰면, 기획과 개발이 같은 기준으로 판단할 수 있다.
채용시장에서의 위치
커머스·핀테크·플랫폼 기업의 "Product QA", "서비스 품질" 공고는 SQL 활용, 데이터 분석 도구 경험, 고객 문의 분석 경험을 우대한다. QA 경력에 이 경험을 더하면 서비스 기획·PO로 넘어가는 다리가 된다.