포크 스트림 넷 중 하나를 AMD가 가져간다: 아웃바운드 콜봇 루프의 음성사서함 감지 게이트 설계

AMD가 가르는 넷: 사람·기계·팩스·미확정

아웃바운드 콜봇이 전화를 걸면 받는 쪽이 사람인지 자동응답기(보이스메일)인지부터 구분해야 다음 동작을 정할 수 있습니다. Twilio AMD는 두 판정 모드를 제공합니다. MachineDetection=Enable은 판정이 서는 즉시 결과를 반환해 결과값이 machine_start·human·fax·unknown 네 가지로 좁고, 예측 다이얼러처럼 상담원 유휴시간을 줄이는 용도에 맞습니다. DetectMessageEnd는 보이스메일 인사말이 끝나는 지점(비프음)까지 기다려 machine_end_beep·machine_end_silence·machine_end_other·human·fax·unknown 여섯 가지로 더 세분합니다.

두 모드의 차이는 '언제 멈출지'가 아니라 '얼마나 기다릴지'입니다. 동기 AMD는 판정이 끝난 뒤에야 상대를 연결하고, 비동기 AMD(AsyncAmd=true)는 먼저 연결한 채 판정을 백그라운드에서 돌려 콜백 URL로 결과를 돌려줍니다. 어느 쪽이든 판정 불가 시 돌아오는 unknown 응답을 재시도 없이 그냥 흘려보내면, 사람인지 보이스메일인지 모른 채 스크립트가 진행되는 사각지대가 생깁니다.

포크 스트림 넷, 비동기 AMD가 쓰는 하나

비동기 AMD가 돌아가는 동안에는 통화 1건당 허용된 포크 스트림 4개 중 하나를 그대로 씁니다. 이 한도는 Media Streams, SIPREC, 실시간 전사(Real-Time Transcription)와 공유되므로, 같은 통화에서 실시간 전사와 비동기 AMD를 동시에 켜 두면 남는 여유는 둘뿐입니다. 녹취·분석·AMD를 한 통화에 동시에 얹는 구성에서 한도를 넘기면 나중에 추가한 기능이 조용히 거부됩니다.

속도와 정확도는 반비례합니다. 판정 타임아웃을 짧게 잡을수록 분석할 오디오가 적어 오탐이 늘고, 길게 잡을수록 응답이 느려져 상담원 대기시간이 늘어납니다. Async 모드로 체감 지연을 숨기더라도 포크 스트림 자원 한도까지 사라지는 것은 아니므로, 동시 통화 수를 늘릴 계획이라면 비동기 AMD 채택 전에 스트림 예산부터 다시 계산해야 합니다.

다이얼러에 AMD 게이트를 넣는 법: 기획부터 운영까지

AMD 게이트를 설계에 넣을 때는 세 가지 수치를 먼저 선언합니다. 사람을 기계로 오판하는 비율(거짓 기계 판정)은 2% 이내, 비프음 감지 후 메시지 재생 지연은 300ms 이내, 통화당 포크 스트림 사용량은 한도 4개의 75%인 3개를 넘지 않는 선으로 둡니다. 세 번째 기준이 없으면 실시간 전사나 Media Streams 같은 다른 기능이 AMD 때문에 거부되는 원인을 찾는 데 오래 걸립니다.

실패는 반복되는 모양이 있습니다. 첫째, 타임아웃을 짧게 줄여 응답 속도를 높이려다 사람 상대를 기계로 오판해 통화를 조기 종료하는 경우입니다. 둘째, Enable 모드만 쓰고 DetectMessageEnd를 쓰지 않아 비프음이 끝나기 전에 메시지를 재생해 앞부분이 잘리는 경우입니다.

셋째, Participants API나 <Dial><Number>처럼 비동기 AMD가 기본값으로 고정되고 설정으로 바꿀 수 없는 경로에서 동기 모드를 전제로 로직을 짜 둔 경우입니다. 넷째, 포크 스트림 한도를 계산하지 않은 채 같은 통화에 실시간 전사까지 얹어 AMD나 전사 중 하나가 소리 없이 끊기는 경우입니다.

복구 분기는 미리 선언해 둡니다. unknown 응답은 침묵 처리하지 않고 사람 상담원 큐로 넘기거나 짧은 확인 질문으로 재판정하고, 포크 스트림이 한도에 닿으면 AMD보다 우선순위가 낮은 기능(예: 녹취 전사)을 먼저 내려 AMD 판정을 지킵니다.

배포 전에는 사람 음성·보이스메일 그리팅·팩스 톤을 섞은 녹음 샘플로 회귀 테스트를 돌리고, 캐리어마다 보이스메일 그리팅 길이가 달라 비프음 도달 시점이 흔들리는지 확인합니다. 로그에는 CallSid, AnsweredBy, MachineDetectionDuration을 필수 필드로 남기고, 수신 동의·수신거부 목록 대조 기록을 함께 보관해 사전 녹취·메시지 재생이 정책을 벗어나지 않는지 추적합니다.

페이싱 게이트가 '언제 끊을지'를 결정한다면 AMD 게이트는 그 앞단에서 '누구와 연결할지'를 가릅니다. 주 단위로 오탐율과 포크 스트림 소진 빈도를 추려 타임아웃과 동시 AMD 사용 비율을 다시 튜닝하고, 캐리어별 베이스라인을 분리해 두면 특정 통신사에서만 비프음 감지가 늦어지는 패턴을 놓치지 않습니다.

바로 쓰는 체크리스트

AMD는 '사람인가 기계인가'를 가르는 단순 필터가 아니라 포크 스트림이라는 유한 자원을 쓰는 또 하나의 통화 중 기능입니다. 거짓 기계판정 2% 이내, 비프음 재생 지연 300ms 이내, 스트림 사용량 3개 이내라는 세 수치를 게이트 기준으로 걸어 두고, unknown 응답과 자원 경합 두 갈래의 복구 분기를 미리 선언해 두면 캐리어가 바뀌어도 같은 기준으로 판단할 수 있습니다.

참고 링크

Answering Machine Detection — Twilio Docs

Answering Machine Detection FAQ & Best Practices — Twilio Docs