고친 버그, 그 고객도 알고 있습니까? — VOC를 제품 개정과 회신까지 잇는 법
출시 다음 날부터 들어온 고객 불만 12건을 문제 5개로 묶고 긴급 패치·정기 개정·로드맵으로 나눈 뒤 묶인 고객 모두에게 회신하기까지. 쇼핑몰 주문·재고 관리 SaaS 팀이 Recoble 한 곳에서 처리한 흐름입니다(가상 사례).
한눈에 보기
고객 불만은 메일·채팅·전화·영업 메모로 흩어져 들어옵니다. 건마다 따로 처리하면 같은 문제를 열 번 고치려 하거나, 고쳐 놓고도 몇몇 고객은 소식을 못 듣습니다. 이 글은 가상의 B2B SaaS 팀이 v3.7 출시 뒤 받은 VOC 12건을 ① 한 접수함에 원문 그대로 모으고 ② 문제 5개로 묶어 ③ 주간 회의에서 결정과 이유를 남기고 ④ 시험에서 왜 못 잡았는지까지 원인을 파고 ⑤ 개정 일정에 올린 뒤 ⑥ 묶인 고객 모두에게 회신하고 닫는 과정을 Recoble 화면으로 보여 줍니다.
출시 2주 뒤, 흔한 장면
v3.7을 내보낸 지 2주. CS 메일함과 채팅 상담 기록에는 "주문이 안 들어온다", "엑셀이 깨진다"는 문의가 섞여 있고, 영업 담당 메모에는 "대량 고객사가 연장 계약을 다시 보겠다고 함"이 적혀 있습니다. 앱 리뷰에는 별점 1점짜리 리뷰가 하나 올라왔습니다.
개발 회의에서 누군가 묻습니다. "주문 누락 건, 고객 몇 곳이 겪는 거죠?" CS는 메일함을 다시 뒤지고, 영업은 메모를 찾습니다. 수정 배포가 끝난 뒤에는 다른 질문이 나옵니다. "이거 그 고객들한테 다 알려 줬나요?"
불만을 받는 일보다 어려운 것은 같은 문제를 하나로 셈하고 고친 뒤 묶인 고객 모두에게 닫는 일입니다. 받는 곳과 고치는 곳과 알리는 곳이 다르면 그 연결이 사람 기억에만 남습니다.
표준이 요구하는 것과, 실제로 자주 빠지는 것
고객 불만을 기록하고 시정하라는 요구는 새롭지 않습니다. 많은 팀이 이미 따르는 표준에 들어 있습니다. 그런데 그 요구대로 불만 한 건 한 건이 끝까지 닫혔는지 확인하기는 어렵습니다.
|
표준·관행 |
요구하는 것 |
실무에서 자주 빠지는 것 |
|---|---|---|
|
ISO 10002 (고객 불만 처리 지침) |
불만 접수·추적·대응·종결과 고객 소통 |
같은 문제의 여러 불만을 묶어 세지 않음 |
|
ISO 9001 9.1.2 고객 만족 |
고객이 어떻게 인식하는지 모니터링 |
불만 수만 세고 처리 결과는 연결하지 않음 |
|
ISO 9001 10.2 부적합 및 시정 조치 |
원인 파악, 시정, 효과 검토 |
"왜 시험에서 못 잡았나"까지 가지 않음 |
|
일반적인 버그 트래커 운영 |
결함을 이슈로 등록해 수정 |
이슈와 그 이슈를 제기한 고객의 연결이 끊김 |
이 사례의 팀과 상황
아래는 Recoble 사용 흐름을 보여 주려고 만든 가상 시연 데이터입니다. 회사·고객 이름은 모두 지어냈습니다.
-
제품: 소규모 온라인 쇼핑몰용 주문·재고 관리 SaaS. 오픈마켓 주문을 모아 오고, 재고를 채널에 반영하고, 송장을 출력합니다.
-
사건: 10월 13일 v3.7 출시(화면 개편 + 연동 라이브러리 교체). 10월 14일부터 24일까지 VOC 12건 접수.
-
팀: 제품 책임자, 백엔드·프론트엔드 리드, QA, CS 리드, 영업 담당. 매주 금요일 "주간 VOC 검토 회의".
Recoble에는 보드 두 개와 노트 세 개를 두었습니다.
|
종류 |
이름 |
역할 |
|---|---|---|
|
워크보드 |
고객 VOC 접수함 |
불만 한 건 = 항목 하나. 고객, 채널, 유형, 심각도, 반영 계획, 회신 기한 |
|
워크보드 |
제품 개정 — VOC 반영 |
문제 하나 = 항목 하나. 원인, 반영 릴리스, 관련 VOC 수, 완료 확인 기준, 하위 작업 |
|
노트 |
주간 VOC 검토 회의 |
문제별 결정과 이유 |
|
노트 |
원인 분석 |
5 Why와 대책 |
|
노트 |
v3.7.1 릴리스 노트 |
고친 내용과 고객 회신 문안 |
1단계. 흩어진 불만을 한 접수함에 원문 그대로 모은다
메일·채팅·전화·영업 메모·앱 리뷰, 들어온 길이 달라도 VOC 접수함의 항목 하나로 옮깁니다. 이때 요약하지 말고 고객이 쓴 문장을 그대로 설명에 남겨야 합니다. "주문 누락"이라는 요약보다 "오픈마켓에는 132건인데 여기에는 102건만 보입니다"라는 원문이 원인을 훨씬 빨리 가리킵니다.
항목에는 고객, 채널, 유형(결함·사용성·성능·기능 요청), 심각도, 반영 계획, 회신 기한을 적습니다. 상태는 고객 쪽 관점으로 이름을 바꿨습니다. "접수 → 반영 중 → 회신 대기 → 회신 완료". 그래야 개발이 끝났어도 고객에게 알리기 전까지는 닫히지 않습니다.
Claude나 ChatGPT 같은 AI를 Recoble에 연결해 두면, CS 담당자는 메일 원문을 붙여 넣고 "VOC 접수함에 등록해 줘"라고 말하는 것으로 요약·유형·심각도 초안까지 채운 항목을 만들 수 있습니다. 분류는 사람이 확정합니다.
2단계. 12건을 문제 5개로 묶는다
같은 원인에서 나온 불만은 제품 개정 보드의 문제 항목 하나에 링크로 묶습니다. 이 사례에서는 12건 중 11건이 5개 문제로 모였습니다.
|
문제 |
묶인 VOC |
유형 |
영향 |
|---|---|---|---|
|
REV-1 오픈마켓 연동 주문 누락(하루 100건 초과 시) |
3건 |
결함 |
발송 지연 페널티, 대량 고객 계약 위험 |
|
REV-2 주문 엑셀 다운로드 한글 깨짐 |
3건 |
결함 |
택배 송장 업로드 중단 |
|
REV-3 품절 상품이 판매 중으로 남음 |
2건 |
성능 |
품절 취소, 구매자 항의 |
|
REV-4 화면 개편 후 '송장 출력' 버튼을 못 찾음 |
2건 |
사용성 |
하루 수십 번 쓰는 기능의 클릭 증가 |
|
REV-5 모바일 송장번호 일괄 입력 |
1건 |
기능 요청 |
외근 중 업무 불편 |
묶어 놓으면 질문이 바뀝니다. 전에는 "주문 누락 메일이 몇 통 왔지?"를 물었다면 이제는 "REV-1에 고객이 몇 곳 걸려 있지?"를 봅니다. 문제 항목에 걸린 VOC 링크가 곧 영향받는 고객 목록이고 나중에 회신할 대상 목록이 됩니다.
나머지 1건(VOC-12, 반품 알림 메일 미발송)은 10월 24일에 들어와 아직 분류 전입니다. 그래서 추적 표에서 이 건은 문제 칸부터 "누락"으로 보입니다.
3단계. 주간 회의에서 결정과 그 이유를 남긴다
문제마다 반영 방법을 넷 중 하나로 정합니다. 이유는 결정만큼 중요합니다. 석 달 뒤 "이건 왜 로드맵으로 갔지?"라는 질문에 회의록이 답해야 합니다.
|
결정 |
이 팀이 쓴 기준 |
이 사례 |
|---|---|---|
|
긴급 패치 |
매출·계약 손실로 바로 이어지고, 수정 범위가 좁음 |
REV-1, REV-2 → v3.7.1(10/27) |
|
정기 개정 |
구조 변경이 필요해 급히 넣으면 위험. 그동안 쓸 임시 방법이 있음 |
REV-3, REV-4 → v3.8(11/24) |
|
로드맵 |
요청 수가 적고 대체 방법이 있음 |
REV-5 → 2027년 1분기 검토 |
|
반영 안 함 |
제품 방향과 맞지 않음 |
(이번 회의에는 없음) |
회의 노트의 문제별 제목은 제품 개정 보드의 해당 항목과 "도출" 링크로 이어 두었습니다. 보드 항목에서 회의 문단으로, 회의 문단에서 보드 항목으로 한 번에 오갑니다.
정기 개정으로 미룬 문제에는 그동안 고객이 쓸 방법을 함께 정했습니다. REV-3은 "품절 임박 상품은 수동으로 판매 중지", REV-4는 "새 위치 캡처 전달"입니다. 고객은 고쳐지는 날짜와 그때까지 할 일을 함께 받습니다.
4단계. 원인은 "왜 시험에서 못 잡았나"까지 판다
긴급 패치로 정한 REV-1은 원인 분석 노트를 따로 썼습니다. 5 Why를 따라가면 코드 한 줄에서 끝나지 않습니다.
|
단계 |
질문 |
답 |
|---|---|---|
|
1 |
왜 주문이 빠졌나? |
수집 작업이 첫 페이지(100건)만 가져옴 |
|
2 |
왜 첫 페이지만? |
'다음 페이지 있음' 값을 바뀐 응답 필드 이름으로 읽지 않음 |
|
3 |
왜 놓쳤나? |
연동 라이브러리를 올리며 바뀐 응답 형식을 반영하지 않음 |
|
4 |
왜 시험에서 안 잡혔나? |
시험 데이터가 하루 30건이라 두 번째 페이지가 생기지 않음 |
|
5 |
왜 30건이었나? |
대량 주문 시나리오가 회귀 시험 목록에 없었음 |
그래서 대책도 셋입니다. 즉시 수정, 누락 주문 재수집, 그리고 회귀 시험에 '하루 150건' 시나리오를 상시 추가. 문제 항목의 "완료 확인 기준" 칸에는 고객이 겪은 상황을 그대로 적었습니다. "하루 150건 주문 시험에서 누락 0건, 고객 3곳의 누락 주문 재수집 완료". 고쳤다는 선언만으로 닫지 않고 이 고객 상황으로 확인합니다.
5단계. 개정 작업을 일정에 올린다
문제 항목 아래에 실제 작업을 하위 항목으로 두고 배포일을 마일스톤으로 찍습니다.
간트에서는 v3.7.1까지 남은 작업이 한눈에 보입니다. 이 사례에서 10월 24일 기준으로 수집 API 수정과 CSV 한글 표식(BOM) 추가는 끝났고, 재수집은 진행 중, 회귀 시험은 시작 전입니다. 배포 전에 무엇이 남았는지 회의에서 따로 물을 필요가 없습니다.
6단계. 묶인 고객 모두에게 회신하고 닫는다
v3.7.1 릴리스 노트에는 고친 내용과 함께 CS용 회신 문안을 넣었습니다. 제품 개정 보드의 REV-1·REV-2는 이 릴리스 노트와 "반영 릴리스" 링크로 이어져 있습니다.
그래서 추적 표 하나로 이렇게 따라갈 수 있습니다.
VOC-3(대량 고객사) → REV-1 → v3.7.1 릴리스 노트 REV-1
회신할 대상은 REV-1에 묶인 VOC 세 건이라, 누구에게 무엇을 보내야 하는지 메일함을 뒤지지 않고도 압니다. 회신을 마친 VOC는 "회신 완료"로 옮기고 그전까지는 대시보드의 "회신 기한 지남" 숫자로 지켜봅니다.
추적 표의 "누락"은 아직 릴리스로 이어지지 않은 묶음을 가리킵니다. v3.8로 간 REV-3·REV-4는 릴리스 노트가 나오면 연결됨으로 바뀝니다. 로드맵으로 보낸 REV-5는 릴리스 대신 이유와 검토 시점을 회신해 VOC-11을 닫았습니다.
대시보드에는 VOC 유형별·반영 계획별 분포와 AI 요약을 함께 두었습니다. 배포 뒤 1주일 동안 같은 유형의 VOC가 다시 들어오는지도 이 화면에서 봅니다. 다시 들어오면 아직 고쳐지지 않은 것으로 봅니다.
운영하며 정한 규칙 다섯 가지
-
원문은 그대로 둔다. 요약은 항목 이름에, 고객 문장은 설명에.
-
불만은 문제에 묶어서 센다. 우선순위는 메일 수가 아니라 문제에 걸린 고객 수로 본다.
-
결정에는 이유를 붙인다. 로드맵이나 반영 안 함일수록 이유를 그대로 고객에게도 보낸다.
-
완료 기준은 고객 상황으로 쓴다. "수정함"이 아니라 "고객이 겪은 조건에서 재현되지 않음".
-
회신해야 닫힌다. 개발 완료와 VOC 종결을 다른 상태로 둔다.
내일 바로 해 볼 수 있는 것
-
CS 리드: 지난 2주의 불만을 한 보드에 원문 그대로 옮기고 회신 기한 칸을 채워 보세요. 기한이 지난 건이 몇 개인지가 첫 숫자입니다.
-
제품 책임자: 그 불만들을 문제 단위로 묶어 보세요. 묶이지 않는 불만이 많다면 분류 기준부터 정해야 한다는 신호입니다.
-
개발·QA 리드: 최근 긴급 수정 한 건을 골라 시험에서 왜 못 잡았는지 한 번 더 물어보세요. 답이 회귀 시험 목록에 새 항목으로 남아야 합니다.
자주 묻는 질문
Q1. 버그 트래커가 이미 있는데 VOC 접수함을 따로 둬야 하나요?
버그 트래커는 "무엇을 고칠지"를 관리하고, VOC 접수함은 "누가 무엇을 겪었고 답을 들었는지"를 관리합니다. 둘을 링크로 이어야 고친 뒤 알릴 고객이 링크를 따라 바로 보입니다. Recoble에서는 둘 다 워크보드로 두고 링크 유형으로 연결합니다.
Q2. 같은 문제인지 판단은 누가 하나요?
1차 분류는 CS가, 확정은 주간 VOC 검토 회의에서 합니다. AI가 비슷한 VOC를 묶자고 제안할 수는 있지만 확정은 사람이 합니다.
Q3. 기능 요청까지 같은 접수함에 넣나요?
네. 유형을 "기능 요청"으로 두고 같은 흐름을 탑니다. 이 사례의 REV-5처럼 로드맵으로 보내더라도 이유와 검토 시점을 회신하면 고객은 무시당했다고 느끼지 않습니다.
Q4. VOC가 수백 건이면 어떻게 하나요?
흐름은 같고 묶는 단계의 비중이 커집니다. 문제 항목의 "관련 VOC 수"로 정렬하면 어디부터 볼지 정해집니다. 대시보드의 유형별·반영 계획별 차트로 추세를 봅니다.
Q5. 이 시연 데이터의 숫자는 실제 회사 기록인가요?
아닙니다. Recoble 사용 흐름을 보여 주려고 만든 가상 데이터입니다. 표준 이름(ISO 10002, ISO 9001)과 Recoble 기능만 실제입니다.
마무리
고객 불만은 받는 일보다 닫는 일이 어렵습니다. 원문을 한곳에 모으고, 문제로 묶고, 결정과 이유를 남기고, 회신까지 한 줄로 이어 두면 "그 고객한테 알려 줬나요?"라는 질문에 화면 하나로 답할 수 있습니다.
무료로 시작하기 — recoble.com
Recoble은 VWAY가 만든 AI 협업 워크스페이스로, 노트·워크보드·링크·대시보드를 한 공간에서 쓰고 Claude나 ChatGPT 같은 AI가 노트와 작업을 직접 읽고 씁니다. 본문의 회사, 고객, VOC, 수치는 사용 흐름을 보여 주려고 만든 가상 시연 데이터이며, ISO 10002·ISO 9001 같은 표준 이름만 실제입니다.