모든 VOC를 직접 읽지 않고도 놓치지 않는 법: Slack과 Amplitude로 만든 예외 기반 모니터링

내부 협업 도구와 운영 데이터를 이용해 만든 개인용 업무 흐름을 바탕으로 썼다. 조직과 서비스를 식별할 수 있는 이름, 채널, 주소, 고객 정보와 이벤트 이름은 제외하거나 일반화했다.

매일 Slack에서 여러 VOC 채널을 열었다.

고객의 소리가 올라오는 채널, 버그가 공유되는 채널, 프런트엔드 오류를 알리는 채널을 차례로 읽었다. 장애를 놓치지 않으려면 누군가는 계속 보고 있어야 한다고 생각했다.

하지만 대부분의 날에는 바로 대응할 일이 없었다. 단순 사용 문의, 이미 답변이 끝난 제보, 한 고객의 일시적인 환경 문제도 있었다. 중요한 신호가 섞여 있을 수 있으니 읽지 않을 수는 없었지만, 아무 일도 없다는 사실을 확인하기 위해 매번 집중력을 먼저 지불하고 있었다.

문제는 채널을 읽는 시간만이 아니었다. 하던 개발 작업을 멈추고 메시지를 읽은 뒤, 다시 코드로 돌아와 맥락을 복원하는 비용이 더 컸다. 한 번의 확인은 짧아도 하루 동안 여러 번 반복되면 집중은 계속 끊겼다.

모니터링은 대시보드 하나가 아니었다에서는 여러 채널의 약한 신호를 읽기 전용 AI 스킬로 묶는 과정을 정리했다. 이번에는 그다음 단계다.

필터되지 않은 VOC를 어떻게 나누고 고객 행동 데이터와 대조해, 사람이 정말 필요한 순간에만 개입하게 만들 것인가?

TL;DR

• VOC 채널은 가치가 크지만 장애, 사용 문의, 중복 제보와 일시적인 문제가 함께 들어오는 필터되지 않은 입력이다.
• 첫 번째 단계에서는 AI가 여러 채널을 읽고 중복과 잡음을 줄여 조사할 후보를 만든다.
• 두 번째 단계에서는 Amplitude의 고객 행동 이벤트를 따라가며 제보와 실제 행동 흔적이 일치하는지 확인한다.
• Amplitude는 진실 판별기가 아니다. 이벤트가 남지 않았거나 서버·결제 시스템에서만 확인할 수 있는 상태도 있다.
• 조사 결과는 확인된 사실, 합리적 추정, 확인 불가로 분리한다.
• AI는 읽고 정리하는 데까지만 사용한다. 장애 선언, 고객 답변, 수정 우선순위는 사람이 결정한다.
• 목표는 VOC를 덜 믿는 것이 아니다. 모든 VOC에 같은 양의 주의력을 사용하지 않으면서 중요한 신호를 놓치지 않는 것이다.

VOC 채널은 정답지가 아니라 원재료다

고객이 겪은 불편은 그 자체로 사실이다. 다만 한 문장의 제보만으로 시스템에서 실제로 무슨 일이 있었는지까지 곧바로 알 수는 없다.

예를 들어 다음과 같은 메시지가 올라올 수 있다.

결제 버튼을 눌렀는데 다음 화면으로 넘어가지 않아요.

이 문장에는 여러 가능성이 섞여 있다.

• 버튼 동작이 실행되지 않았을 수 있다.
• 요청은 전송됐지만 응답이 늦었을 수 있다.
• 결제 과정은 진행됐지만 화면 전환만 실패했을 수 있다.
• 고객의 네트워크가 순간적으로 끊겼을 수 있다.
• 이미 정상 처리됐지만 고객이 결과 화면을 보지 못했을 수 있다.

Slack 메시지만 읽고 원인을 고르면 추측이 된다. 그렇다고 모든 제보를 같은 심각도로 보고 곧바로 재현과 로그 조사에 들어가면 운영 비용이 너무 커진다.

VOC 채널은 장애 목록이 아니라 조사를 시작할 수 있는 원재료에 가깝다. 먼저 분류가 필요하고, 그다음에는 제보와 대조할 다른 증거가 필요하다.

첫 번째 필터: 사람이 읽던 채널 순회를 자동화한다

처음 자동화한 것은 판단보다 읽기였다.

여러 VOC·버그 채널
  ↓
새 메시지만 수집
  ↓
중복·답변 완료·단순 문의 분리
  ↓
핵심 사용자 여정과 장애성 표현 확인
  ↓
조사할 후보와 원문 링크 출력

여기서 AI에게 맡긴 일은 대단한 장애 예측이 아니다.

• 마지막 확인 이후 새로 올라온 메시지를 찾는다.
• 같은 증상을 가리키는 메시지를 묶는다.
• 이미 답변되거나 해결된 건을 제외한다.
• 로그인, 주문, 결제처럼 영향이 큰 여정인지 구분한다.
• 흰 화면, 무한 로딩, 진행 불가처럼 장애성이 강한 표현을 찾는다.
• 판단 근거와 원문 링크를 남긴다.

변화가 없으면 아무것도 알리지 않는다. 후보가 있더라도 Slack에 자동으로 답변하거나 장애를 선언하지 않는다. 내가 볼 것은 전체 채널의 모든 메시지가 아니라, 왜 다시 봐야 하는지 근거가 붙은 소수의 후보다.

이 단계만으로도 채널을 순서대로 열고, 앞뒤 문맥을 읽고, 같은 제보가 다른 곳에도 있는지 찾는 반복 작업이 줄었다.

하지만 메시지를 잘 분류했다고 해서 제보의 기술적 상황까지 확인된 것은 아니다. 다음 질문이 남는다.

이 고객은 실제로 어디까지 진행했고, 어느 지점부터 행동 흔적이 사라졌을까?

두 번째 필터: Amplitude에서 고객의 행동 흔적을 따라간다

Amplitude에는 제품에서 계측한 사용자 행동이 이벤트로 남는다. User Lookup에서 특정 고객과 시간 범위를 좁히면 화면 진입, 버튼 선택, 다음 단계 이동, 성공 화면 도달 같은 흐름을 시간순으로 볼 수 있다.

VOC를 읽은 뒤 Amplitude에서 확인하는 순서는 대략 다음과 같다.

1. 제보 시각과 고객을 식별할 수 있는 최소 정보로 세션을 찾는다.
2. 문제가 발생했다고 한 화면에 실제로 진입했는지 확인한다.
3. 관련 버튼이나 기능을 실행한 이벤트가 있는지 본다.
4. 다음 단계 이벤트 또는 성공 이벤트가 이어졌는지 확인한다.
5. 제보 시점 전후로 반복 시도나 이전 화면 복귀가 있었는지 살핀다.
6. 이후 다른 시도에서는 정상적으로 완료했는지 구분한다.

Slack의 VOC가 고객이 무엇을 겪었다고 설명하는지 알려준다면, Amplitude는 제품에 어떤 행동 흔적이 남았는지 보여준다.

둘을 함께 보면 조사 범위를 빠르게 좁힐 수 있다.

VOC:
"버튼을 눌렀지만 다음 단계로 가지 않았다."

행동 데이터:
- 해당 화면 진입 확인
- 버튼 선택 이벤트 확인
- 다음 단계 진입 이벤트 없음
- 잠시 뒤 같은 행동 반복

판단:
- 버튼 선택까지 진행한 것은 확인된 사실
- 버튼 이후 여정이 중단됐을 가능성은 높음
- 요청이 서버에 도달했는지는 행동 데이터만으로 확인 불가

이제 막연히 “재현이 필요하다”에서 시작하지 않아도 된다. 버튼 이전 문제인지, 버튼 이후 클라이언트 문제인지, 서버 로그까지 확인해야 하는지 다음으로 조사할 위치를 정할 수 있다.

Amplitude는 진실 판별기가 아니다

여기서 표현을 조심해야 한다.

Amplitude를 이용해 VOC의 “진위 여부”를 가린다고 말하면 두 가지 문제가 생긴다.

첫째, 고객이 겪은 불편을 거짓과 참으로 나누는 인상을 준다. 고객의 표현이 기술적으로 정확하지 않을 수는 있어도, 불편을 느꼈다는 경험까지 거짓인 것은 아니다.

둘째, 행동 데이터도 완전하지 않다. Amplitude도 공식 문서에서 수집 지연, 차단, 계측 설정과 스키마 문제 등으로 예상한 데이터가 보이지 않을 수 있다고 설명한다.

• 네트워크 문제로 이벤트 전송이 실패할 수 있다.
• 분석 도구가 초기화되기 전에 화면이 종료될 수 있다.
• 광고 차단이나 개인정보 보호 설정이 수집을 막을 수 있다.
• 이벤트 계측 자체가 빠졌거나 잘못 연결됐을 수 있다.
• 결제 승인, 주문 생성, 환불 같은 상태는 서버나 외부 시스템에서만 확인할 수 있다.

따라서 Amplitude는 객관적 진실이라기보다 비교 가능한 관측 데이터다. VOC를 반박하는 도구가 아니라, 제보와 일치하는 흔적이 있는지 확인하고 다음 조사 위치를 정하는 관측 근거다.

조사 결과도 다음 세 가지를 분리해 적는다.

이 구분이 없으면 분석 결과는 다시 그럴듯한 이야기로 돌아간다.

나중의 성공은 이전의 성공을 증명하지 않는다

고객 여정을 조사할 때 자주 빠지는 함정이 있다.

문제가 발생한 뒤 같은 고객이 나중에 구매나 가입을 완료했다면, 첫 제보에서 말한 문제도 일시적인 착오였다고 보기 쉽다. 하지만 나중의 성공은 나중 시도가 성공했다는 뜻일 뿐이다. 이전 시도까지 정상적으로 처리됐다는 증거는 아니다.

각 시도를 시간 구간으로 나눠 봐야 한다.

첫 번째 시도
- 핵심 버튼 선택
- 다음 단계 이벤트 없음
- 이전 화면으로 복귀

두 번째 시도
- 핵심 버튼 선택
- 다음 단계 진입
- 완료 이벤트 확인

이 경우 말할 수 있는 것은 “결국 성공했다”가 아니라 다음과 같다.

첫 번째 시도는 중간에 흐름이 끊긴 정황이 있고, 두 번째 시도에서 정상적으로 완료됐다.

이 작은 차이가 VOC를 성급하게 종료하지 않게 한다. 동시에 두 번째 시도에서 이미 정상적으로 완료한 고객에게 불필요한 추가 대응을 하지 않도록 돕는다.

상시 순찰을 예외 기반 개입으로 바꾼다

이 자동화에서 가장 크게 달라진 것은 조사 속도보다 내 주의력을 사용하는 방식이었다.

이전에는 중요한 신호가 있는지 확인하기 위해 모든 채널을 직접 읽었다.

개발 작업
  ↓ 중단
채널 A 확인
  ↓
채널 B 확인
  ↓
관련 스레드와 이전 제보 검색
  ↓
아무 일 없음
  ↓
개발 맥락 복원

자동화한 뒤에는 흐름이 바뀌었다.

개발 작업에 집중
  ↓
읽기 전용 자동화가 새 신호 확인
  ↓
변화 없음 → 조용히 종료
  ↓
대응 후보 있음 → 원문과 분류 근거 전달
  ↓
필요한 경우 Amplitude 행동 흐름 확인
  ↓
사람이 개입 여부 결정

운영 업무가 사라진 것은 아니다. 사람이 부담하던 비용의 위치가 바뀌었다.

• 모든 메시지를 읽는 반복 작업은 자동 분류 규칙에 맡겼다.
• 여러 채널을 오가는 수고는 근거 링크가 포함된 후보 묶음으로 줄였다.
• 행동 데이터로 범위를 좁힌 뒤 필요한 로그만 확인하게 됐다.
• 새 신호가 없는지 반복해서 확인하던 비용은 “변화가 없으면 알리지 않기”로 없앴다.
• 최종 판단은 여전히 사람이 맡았다.

결과적으로 나는 개발 업무를 계속하다가, 실제로 판단이 필요한 상황이 왔을 때만 운영 맥락으로 전환할 수 있게 됐다.

이것은 단순한 시간 절약보다 중요했다. 복잡한 코드를 읽거나 설계를 이어가는 동안에는 맥락이 곧 작업 자산이다. 짧은 Slack 확인 한 번도 그 맥락을 밀어낼 수 있다. 자동화가 줄인 것은 몇 분의 채널 읽기뿐 아니라, 집중을 다시 만드는 비용이었다.

자동화가 안전하려면 하지 않을 일을 먼저 정해야 한다

필터링과 조사를 자동화할수록 경계도 명확해야 한다.

내가 정한 기본 원칙은 다음과 같다.

• Slack과 분석 도구는 읽기 전용으로 사용한다.
• AI가 고객이나 동료에게 자동으로 답변하지 않는다.
• 장애를 자동으로 선언하지 않는다.
• 원문 링크와 관측 근거 없이 결론만 알리지 않는다.
• 같은 건을 반복해서 알리지 않도록 확인 상태를 저장한다.
• 고객 이름, 연락처, 주문번호 등 불필요한 개인정보를 출력하지 않는다.
• 데이터가 없으면 정상이라고 단정하지 않고 확인 불가로 남긴다.
• 오탐과 누락이 발견되면 분류 규칙과 관측 이벤트를 함께 고친다.

AI가 맡은 역할은 사람을 대신해 결정하는 것이 아니다.

1. 정해 둔 범위를 꾸준히 확인한다.
2. 반복되는 분류 기준을 같은 방식으로 적용한다.
3. 다음 판단에 필요한 근거를 한곳에 모은다.
4. 사람이 개입해야 할 후보를 좁힌다.

장애 선언, 고객 영향 판단, 수정 우선순위와 답변은 여전히 사람이 담당한다. 집중을 지키기 위해 자동화를 만들었지만, 책임까지 자동화한 것은 아니다.

규칙을 만들면 운영도 필요하다

처음 만든 규칙이 계속 맞는 것도 아니다.

VOC에서 자주 등장하지만 실제 장애와 관계없는 표현이 생길 수 있다. 반대로 평범한 문장으로 쓰였지만 핵심 기능이 막힌 제보를 놓칠 수도 있다. Amplitude 계측이 어긋나 실제와 다른 흐름을 보여줄 수도 있다.

이전 글 장애 기록은 대응을 일으켜야 한다에서 기록은 실제 대응으로 이어져야 한다고 썼다. 탐지 규칙도 마찬가지다. 만든 뒤 끝내지 말고 자동화 결과를 다시 규칙으로 돌려보내야 한다.

• 이 후보는 실제로 대응이 필요했는가?
• 제외한 메시지 중 나중에 장애로 확인된 것은 없었는가?
• 같은 사건을 여러 번 알리지 않았는가?
• 행동 데이터가 고객의 실제 여정을 충분히 설명했는가?
• 다음 판단에 필요했지만 수집되지 않은 이벤트는 무엇인가?
• 개인정보 없이도 조사에 필요한 고객 여정을 찾을 수 있었는가?

오탐을 줄이는 것만 목표로 삼으면 중요한 신호까지 숨길 수 있다. 반대로 탐지 규칙을 지나치게 민감하게 만들면 다시 모든 메시지를 읽는 것과 다르지 않다. 자동화의 품질은 알림 개수가 아니라, 필요한 순간에 사람이 근거를 가지고 개입할 수 있었는가로 평가해야 한다.

정리

VOC 채널에는 제품의 문제를 가장 먼저 알려주는 신호가 있다. 동시에 사용 문의, 중복 제보, 개별 환경 문제와 이미 해결된 대화도 함께 들어온다. 가치가 높다는 이유로 사람이 매일 모든 메시지를 직접 읽는 방식은 오래 유지하기 어렵다.

그래서 두 단계를 만들었다.

1. 여러 Slack 채널의 필터되지 않은 메시지를 읽고, 조사할 후보만 분류한다.
2. Amplitude에서 고객 행동 흔적을 확인해 제보와 일치하는 구간과 다음 조사 위치를 찾는다.

여기서도 최종 판단은 자동화하지 않았다. AI는 후보와 근거를 만들고, 사람은 확인된 사실, 합리적 추정, 확인 불가를 구분해 개입 여부를 정한다.

목표는 VOC를 덜 믿는 것이 아니다. 모든 VOC에 같은 양의 주의력을 쓰지 않으면서도 중요한 고객 신호를 놓치지 않는 구조를 만드는 것이다.

이 구조를 만들고 나서야 여러 채널을 계속 바라보지 않아도 됐다. 평소에는 내 작업에 집중하고, 실제 대응이 필요한 상황이 왔을 때는 이미 정리된 근거에서 시작할 수 있다.

모니터링을 없앤 것이 아니라, 상시 순찰을 예외 기반 개입으로 바꾼 것이다.