고객 버그 신고를 우선순위와 재현 기록으로 바꾸는 트리아지 절차

고객 버그 신고는 접수 순서대로 개발자에게 넘기면 빨리 해결되지 않습니다. 첫 응답에서 사용자·환경·재현 절차·영향 범위를 고정하고, 증거가 부족하면 긴급도를 낮추는 대신 다음 확인 시각을 기록해야 합니다. 이 글의 트리아지는 신고를 버리는 절차가 아니라 조사 가능한 작업으로 바꾸는 운영 기록입니다. 트리아지 카드에는 영향·재현·우회·다음 확인 시각이 한 줄로 남습니다.

가장 먼저 할 일은 ‘안 된다’는 문장을 재현 가능한 관찰로 바꾸는 것입니다. 예를 들어 로그인이 실패했다면 계정 유형, 발생 시각, 브라우저, 입력 단계, 오류 화면과 서버 요청 식별자를 함께 수집합니다. OWASP는 오류 처리에서 민감한 내부 정보를 사용자에게 노출하지 않으면서 운영자가 조사할 로그를 남길 것을 권고하므로, 상세 로그와 고객 답변을 분리해야 합니다.OWASP Logging Cheat Sheet를 기준 자료로 삼았습니다.

접수 기록: 7개 입력 필드

신고 원문을 제목으로 축약하지 말고 원문, 신고자 역할, 발생 시각, 영향을 받은 업무, 재현 여부, 첨부 증거를 별도 필드로 보관합니다. 관찰과 추정을 섞으면 담당자가 원인을 사실로 오해합니다. ‘결제 API가 원인 같다’는 추정은 증거가 아니라 가설 칸에 둡니다.

재현 조건을 확인하는 조사 분기

우선순위는 고객의 목소리 크기보다 영향 범위와 업무 중단 정도로 정합니다. 전체 사용자가 핵심 업무를 완료할 수 없는지, 일부 사용자인지, 안전·금전·개인정보 위험이 있는지, 임시 우회가 있는지를 한 표에서 비교합니다. 위험이 확인되면 일반 큐를 기다리지 않고 보안·서비스 책임자에게 에스컬레이션합니다.

• P1: 핵심 업무 중단 또는 안전·보안 위험, 즉시 담당자 지정

• P2: 반복되는 주요 기능 장애, 우회책과 조사 시각 기록

• P3: 제한적 불편 또는 개선 요청, 재현 증거가 모일 때 처리

우선순위와 에스컬레이션 결정

가상 사례의 입력은 ‘모바일에서 결제가 안 돼요’라는 신고 3건입니다. 운영자는 신고 시각, OS, 결제수단, 주문번호, 화면 오류 문구를 요청하고 서버 로그의 요청 ID를 대조합니다. 같은 카드사와 특정 앱 버전에서만 재현되고 웹 결제라는 우회가 가능하다면 P2로 결정합니다.

중간 산출물은 ‘영향: 앱 버전 4.2, 카드사 A, 3건 / 재현: 테스트 계정에서 성공 / 가설: 결제 SDK 응답 처리 / 우회: 웹 결제 / 다음 확인: 16:00’이라는 트리아지 카드입니다. 예상 결과는 개발자가 추측이 아니라 재현 조건과 확인 시각을 받아 로그를 조사하고, 운영자가 고객에게 같은 안내를 반복하지 않는 것입니다.

인수인계 기록과 실패 복구 경로

재현되지 않는다는 이유로 신고를 닫는 것이 흔한 실패입니다. 고객 환경이 사라졌거나 로그 보존 시간이 지났을 수 있으므로, 상태를 ‘재현 대기’로 두고 요청할 증거와 만료 시각을 남깁니다. 개인정보가 첨부되었다면 원문을 공유 큐에 복사하지 말고 접근을 제한한 저장소로 옮긴 뒤 민감정보 없는 요약으로 복구합니다.

트리아지 완료 조건과 증거

트리아지 완료 조건은 우선순위, 담당자, 재현 조건 또는 재현 불가 사유, 고객 안내, 다음 조치가 기록되어 있고 담당자가 카드를 다시 읽어 같은 판단을 재현할 수 있는 상태입니다. 수정 후에는 회귀 테스트나 로그 확인 결과를 카드에 남기고, 확인 시각과 결과가 기록되면 검증 완료로 표시합니다.