음성으로 대화하는 앱 세 개를 운영합니다. 통화가 제대로 끝난 세션 218건을 보니, 143건에서 사용자 음성이 한 번도 서버에 닿지 않았습니다. 66%입니다.
사용자 단위로 세면 더 선명합니다. 130명 중 87명이 단 한 번도 말한 적이 없습니다.
이 숫자를 처음 봤을 때 제 머리에 떠오른 건 하나였습니다. 마이크가 안 잡히는구나.
당신은 "사용자가 안 했다"와 "시스템이 못 받았다"를 무엇으로 구분합니까?
코드로 하나씩 지웠습니다
마이크 권한 거부. 오디오 시작이 서버 세션 생성보다 먼저 실행되고, 권한이 거부되면 거기서 막히면서 백엔드를 아예 호출하지 않습니다. 테스트가 "마이크 실패는 서버 세션을 아예 만들지 않는다"로 이 성질을 고정하고 있었습니다. 즉 DB에 남은 무음 세션은 전부 권한이 있는 사용자입니다. 배제.
에코 게이트. 스피커 소리가 마이크로 되돌아오는 것을 막는 2차 방어선이 있습니다. 이게 사용자 음성까지 삼키면 딱 이런 증상이 납니다. 읽어보니 마지막 재생 프레임 뒤 0.4초 안에서만 작동하고 그 밖에는 그대로 통과시킵니다. 앱이 먼저 말을 걸지 않는 두 앱에서는 사용자가 첫 마디를 할 때 재생이 없으니 게이트가 투명합니다. 배제.
연결 실패. 토큰 발급 횟수가 평균 1.0입니다. 소켓은 열렸습니다. 배제.
여기까지 오면 남는 건 계측을 추가하는 것뿐이라고 생각했습니다. 캡처 버퍼 개수를 서버에 남기면 "마이크가 들어왔는데 안 갔다"와 "사용자가 말을 안 했다"가 갈립니다. 실제로 그 값은 이미 수집되고 있었는데, 개인정보 라벨 판정을 건드리지 않으려고 DB에 저장하지 않고 로그로만 흘리고 있었습니다. 그리고 그 로그는 보관 기간이 지나 비어 있었습니다.
그때 시간을 봤습니다
계측 계획을 적다가, 혹시나 해서 세션 길이를 부류별로 갈라봤습니다.
| 부류 | 건수 | 소비 시간 중앙값 |
|---|---|---|
| 아무도 말 안 함 | 129 (59%) | 4~12초 |
| 앱만 말함 | 14 | 12~180초 |
| 양방향 대화 | 73 | 30~34초 |
4초입니다.
응답 모델의 첫 응답 지연만 13초입니다. 4초 안에는 어떤 대화도 물리적으로 일어날 수 없습니다. 오디오가 정말 고장났다면 사용자는 말을 시도하고, 반응을 기다리고, 한 번 더 해보느라 최소 1530초는 머물렀을 겁니다.
계측은 필요 없었습니다. 이미 있는 열 하나가 답을 갖고 있었습니다.
대조군이 결정타였습니다
세 앱 중 하나만 앱이 먼저 말을 겁니다. 나머지 둘은 사용자가 침묵을 깨야 합니다.
먼저 말을 거는 그 앱에서도 "아무도 말 안 함"이 25건이고 중앙값이 4초였습니다. 인사말이 도착하기도 전에 닫은 겁니다. 반대로 인사말이 실제로 도착한 12건은 중앙값 24초까지 머물렀지만, 사용자는 끝내 대답하지 않았습니다.
즉 문제는 "먼저 말을 걸어주지 않아서"가 아니었습니다. 그건 제가 며칠 전에 세우고 수정까지 출하한 가설이었는데, 유일한 대조군이 그걸 반증했습니다.
자가진단
- 실패로 보이는 표본의 체류 시간을 본 적 있습니까? 시스템이 응답할 수 있는 최소 시간보다 짧지는 않습니까?
- "기능이 안 됐다"와 "기회가 없었다"를 가르는 열이 당신 테이블에 이미 있지는 않습니까?
- 새 계측을 붙이기 전에, 기존 열의 조합으로 답할 수 있는지 5분만 확인해 봅니까?
솔직한 부분
이건 좋은 소식이 아닙니다. 기술 결함이면 고치면 되는데, 사람들이 통화 화면을 열고 4초 만에 닫는 것은 고칠 코드가 없습니다. 설치는 늘었는데 매출은 0이던 이야기와 같은 자리에 있습니다 — 유입을 늘려도 이 구간을 통과하지 못합니다.
다만 진단은 정직해졌습니다. 없는 오디오 버그를 이틀 더 팠다면 그만큼 늦게 알았을 겁니다.
당신의 실패 표본에서 중앙 체류 시간을 한 줄 쿼리로 뽑아보세요. 그 값이 시스템 응답 시간보다 짧다면, 당신이 찾는 버그는 없을지도 모릅니다.