개념
같은 문제가 세 이름으로 보인다
앱 결제 중 외부 결제 앱에서 돌아오지 못하는 문제가 있다고 하자. 이 하나의 문제는 세 곳에 다른 모습으로 남는다.
| 출처 | 기록 | 담당 |
|---|---|---|
| 이슈 트래커 | "BUG-812 iOS 결제 앱 복귀 시 화면 멈춤" | QA·개발 |
| 고객 문의 | "결제했는데 주문이 안 됐어요", "돈만 빠져나갔어요" | CS |
| 운영 로그 | payment_callback_timeout 오류 급증 | 운영·개발 |
세 팀이 각자의 데이터만 보면 문제의 크기를 과소평가한다. QA는 결함 하나로, CS는 흔한 결제 문의로, 운영은 간헐적 타임아웃으로 본다. 합치면 이번 달 가장 비싼 품질 문제 일 수 있다.
공통 분류 체계
세 출처를 묶으려면 같은 분류 축이 필요하다. 세 개의 축이면 대부분 충분하다.
| 축 | 값의 예 | 왜 필요한가 |
|---|---|---|
| 여정 단계 | 진입·탐색·담기·확인·결제·완료·수령(레슨 2) | 사용자 영향의 위치 |
| 기능·컴포넌트 | 결제, 장바구니, 배송, 알림 | 담당 팀과 수정 위치 |
| 원인 유형 | 결함, 사양·설계, 사용성, 외부 연동, 운영·데이터, 사용자 오해 | 해결 방법의 종류 |
원인 유형이 중요하다. 고객 문의 중 상당수는 결함이 아니다. "배송 마감 시간을 몰랐다"는 사용성이나 사양 문제이고, "카드사 점검 시간이었다"는 외부 연동 문제다. 결함이 아닌 품질 문제 를 찾는 것이 제품 품질 엔지니어의 고유한 가치다. 이것들은 이슈 트래커에 없으므로 테스트 결과만 보면 영원히 보이지 않는다.
고객 문의 분류 — 표본에서 시작한다
고객 문의는 양이 많고 비정형이다. 처음부터 전수 분류하려 하지 않는다.
- 표본 추출 — 최근 한 달 문의에서 무작위 200건
- 개방 분류 — 읽으면서 자유롭게 태그를 붙인다
- 태그 정리 — 비슷한 태그를 묶어 공통 분류 체계에 맞춘다
- 규칙화 — 자주 나오는 키워드와 분류를 대응시킨다("돈만 빠져나갔" → 결제 단계, 외부 연동/결함)
- 전수 적용과 검수 — 규칙으로 전체를 분류하고, 표본을 다시 뽑아 정확도를 확인한다
최근에는 LLM으로 문의를 분류하는 경우가 많다. 이때도 사람이 만든 표본 분류를 정답 삼아 정확도를 측정 하고, 분류 기준을 프롬프트에 명시하며, 경계 사례를 사람이 검토한다(모듈 18c의 교차 검증 원칙). 분류 결과를 그대로 믿으면 잘못된 우선순위가 나온다.
세 출처를 하나의 표로
-- 여정 단계 × 원인 유형별 통합 건수 (최근 30일)
SELECT journey_stage,
cause_type,
SUM(CASE WHEN source = 'defect' THEN 1 ELSE 0 END) AS defects,
SUM(CASE WHEN source = 'inquiry' THEN 1 ELSE 0 END) AS inquiries,
SUM(CASE WHEN source = 'error' THEN 1 ELSE 0 END) AS error_events
FROM quality_signals
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY journey_stage, cause_type
ORDER BY inquiries DESC;quality_signals 는 세 출처를 공통 분류로 모은 테이블(또는 스프레드시트 시트)이다. 처음에는 스프레드시트로 충분하다. 매주 결함 export, 문의 분류 결과, 오류 로그 상위 집계를 한 시트에
붙이고 같은 분류 열을 채운다.
파레토 분석 — 상위 20%를 찾는다
품질 문제는 대개 소수의 유형에 몰린다. 건수(또는 비용) 기준으로 정렬해 누적 비율을 보면 상위 몇 개가 전체의 대부분을 차지한다.
[결제 관련 고객 문의 원인 — 최근 30일, 612건]
원인 건수 누적 비율
외부 결제 앱 복귀 실패(결함) 198 32%
결제 지연 시 실패 표시(결함) 121 52%
카드사 점검 시간 안내 없음(사양) 88 67%
부분 취소 환불 일정 문의(사용성) 74 79%
쿠폰 적용 조건 오해(사용성) 43 86%
기타 11개 유형 88 100%
→ 상위 3개가 67%. 그중 하나는 결함이 아니라 사양 문제.건수만 보지 말고 비용 가중 도 본다. 문의 1건당 상담 시간, 환불·보상 금액을 곱하면 순위가 바뀔 수 있다.
재발 문제 탐지
한 번 고친 문제가 다시 나타나는 것을 잡아야 한다. 재발은 회귀 테스트의 빈틈이나 근본 원인이 해결되지 않았다는 신호다.
- 같은 분류 조합의 재상승 — 결제×외부 연동 문의가 수정 후 줄었다가 3주 뒤 다시 오른다
- 같은 결함의 재오픈 또는 유사 결함 재등록 — 제목·컴포넌트 유사도로 찾는다
- 릴리스 직후 급증 — 릴리스 일자와 문의·오류 급증 시점을 겹쳐 본다
재발이 확인되면 두 가지를 한다. 해당 경로를 자동 회귀에 넣었는지 확인하고, 수정이 증상이 아니라 원인을 고쳤는지 개발과 함께 본다.
원인과 영향으로 설명한다
분석 결과를 전달할 때는 숫자 나열이 아니라 원인 → 영향 → 제안 으로 쓴다.
[결제 품질 월간 분석 — 9월]
핵심 결제 관련 문의 612건 중 67%가 세 가지 원인에 집중.
원인1 iOS 외부 결제 앱 복귀 실패(BUG-812) — 문의 198건, 오류 로그 일 평균 140건
영향: 결제 직전 이탈, 일부 중복 결제로 환불 처리 월 37건
원인2 결제 지연 5초 초과 시 실패로 표시 — 실제 승인 완료, 재결제로 중복 위험
원인3 카드사 정기 점검 시간 안내 없음 — 결함이 아닌 사양 공백
제안 원인1·2 수정 우선(다음 스프린트), 원인3 점검 시간 사전 안내 기능 기획 요청
다음 수정 후 4주간 동일 분류 문의 추이 추적(재발 감시)실무에서 왜 필요한가
QA 조직이 가진 데이터(결함)만으로는 사용자가 겪는 품질 문제의 일부만 보인다. 고객 문의와 운영 로그를 합치면 "테스트가 놓친 것"과 "테스트 대상이 아니었던 것" 이 드러난다. 이것은 다음 테스트 계획의 가장 좋은 입력이고, 동시에 기획·CS·운영과 QA를 연결하는 공통 언어다.
채용시장에서의 위치
"VOC 분석", "고객 문의 기반 품질 개선", "SQL 활용 데이터 분석"은 제품 품질·서비스 품질 공고의 단골 요건이다. 면접에서 공통 분류 체계와 파레토 결과, 그리고 "결함이 아닌 품질 문제"를 찾은 사례를 말할 수 있으면 데이터로 품질을 다루는 사람으로 보인다.