음성 모달리티 — 고객센터 상담 요약 실험

왜 결제·정산 팀에게 음성 모달리티가 '데이터 파이프라인' 문제인가

결제와 정산을 운영하는 팀에서 고객센터 통화는 단순한 CS 업무가 아니다. "이체가 왜 안 됐나요", "정산금이 왜 이만큼밖에 안 나왔죠", "환불 요청했는데 언제 들어오나요" — 전화 한 통에는 실제 트랜잭션 이슈가 담겨 있다. 문제는 이 정보가 상담사 메모란에 자유 텍스트로 들어가거나, 최악의 경우 아무 기록도 남지 않는다는 점이다. 정산 오류가 반복되거나 동일 가맹점의 민원이 쌓여도 패턴을 발견하기 어렵다. 배치 로그를 뒤지기 전까지는.

우리가 음성 요약 실험을 시작한 출발점은 바로 여기다. 음성 파일이 자동으로 구조화된 텍스트로 변환되고 — "문의 유형: 정산 오차 / 핵심 내용: 5월 2주차 정산에서 카드 수수료 0.3% 이중 차감 / 처리 결과: 재검토 요청 접수" — 이 형태로 시스템에 기록된다면? 이건 CS 편의성 개선이 아니라, 정산 데이터 파이프라인의 입력 채널을 하나 더 여는 작업이다. 그 관점에서 보면 이 실험이 왜 기술적인 재미를 넘어 운영적 의미를 갖는지 이해할 수 있다.

전사 단계: 기술의 성숙도와 현장의 간극

Whisper, Google STT, Azure Speech 같은 서비스는 일반 품질 음성에서 단어 오류율(WER) 5~10% 수준을 실제 서비스에서 보여준다. 데모가 아니라 상용 수준이 이 정도다. 충분히 써먹을 만하다. 문제는 '일반 품질'이라는 조건이 실제 고객 통화와 얼마나 다른지를 과소평가하면 바로 막힌다는 것이다.

우리가 테스트한 샘플 통화 중 절반 이상은 어떤 형태로든 노이즈가 섞여 있었다. 카페에서 걸려온 전화, 지하철 환승 구간의 끊기는 통화, 아이 울음소리가 배경에 깔린 통화. 이런 케이스에서 WER은 25~40%까지 치솟았다. 더 심각한 건 전문 용어 오인식이다. 'PG사', '정산 배치', 'VAN 수수료' 같은 단어는 일반 STT 모델이 학습한 코퍼스에 거의 없다. 실제로 'PG사'가 '피지사'나 '피케이사'로 전사된 케이스를 반복해서 봤다. 이 오류는 요약 단계에서 그대로 전파된다. 요약 LLM이 아무리 좋아도 입력이 '피케이사에서 수수료가 이중으로 나왔다'로 들어오면 PG사 이슈로 자동 분류할 수 없다.

화자 분리(Diarization): 요약 품질의 숨겨진 결정 변수

전사 품질 다음으로 우리 팀이 가장 많이 신경 쓴 부분이 화자 분리다. 상담사와 고객의 발화를 구분하지 않고 하나의 텍스트 덩어리로 LLM에 넘기면 요약이 이상해진다. 상담사의 스크립트 멘트 — "감사합니다, 헤드빈입니다", "잠시만 기다려 주세요" — 가 고객의 불만 내용과 동일한 무게로 처리되기 때문이다. 결과물은 요약처럼 생겼지만 핵심 민원 내용이 희석된 채 나온다.

pyannote.audio 기반 오픈소스 diarization을 붙여서 실험했다. 스피커 레이블이 SPEAKER_00, SPEAKER_01로 분리되어 나오는 형태인데, 두 스피커 중 어느 쪽이 고객인지 자동으로 판별해야 한다. 우리가 적용한 휴리스틱은 통화 시작 30초 내에 발화 길이가 짧은 쪽을 고객으로 보는 것이었다 — 상담사는 인사 멘트로 시작하는 경향이 있기 때문이다. 정확도는 87% 수준이었다. 이 방식으로 고객 발화만 추출해서 요약하면, 전체 전사 텍스트를 그대로 넘기는 것보다 요약 품질이 눈에 띄게 달라졌다. 내부 평가에서 "핵심 문의 내용 정확히 포함" 기준으로 60%에서 78%로 개선됐다. 화자 분리 하나가 만든 차이다.

요약 파이프라인 설계: 전처리가 결과를 결정한다

전사 텍스트를 바로 LLM에 넣는 건 생각보다 비효율적이다. 세 가지 이유가 있다. 첫째, 전사 오류가 요약에 그대로 전파된다. 둘째, "네", "아 그렇군요", "잠깐만요" 같은 필러 발화가 토큰을 소모하고 요약 품질을 흐린다. 셋째, 30분짜리 민원 통화는 전사 텍스트가 수만 토큰을 넘어 컨텍스트 창을 초과하거나 처리 비용이 급등한다.

우리가 최종 정착시킨 파이프라인 구조는 이렇다:

원본 음성
    → STT (Whisper large-v3, 도메인 핫워드 주입)
    → 화자 분리 → 고객 발화 추출
    → 필러 문장 제거 (3단어 미만 단답 발화)
    → 청크 분할 (600 토큰 단위)
    → 청크별 부분 요약 → 최종 통합 요약
    → 구조화 출력 (문의 유형 / 핵심 내용 / 처리 결과 / 감정 강도)

여기서 '도메인 핫워드 주입'이 실질적인 WER 개선에 가장 효과 대비 비용이 낮았다. Whisper API는 initial_prompt 파라미터로 도메인 용어를 힌트로 줄 수 있다. 'PG사', '정산 배치', 'VAN 수수료', '가맹점 코드' 같은 핵심 용어 20~30개를 넣었더니 전문 용어 오인식률이 약 60% 감소했다. 추가 파인튜닝이 필요 없다. 프롬프트 한 줄 수준의 작업이다. 구조화 출력 설계도 중요하다. 자유 텍스트 요약은 읽기는 편하지만 자동화 파이프라인에 연결하기 어렵다. JSON 스키마를 먼저 정의하고 LLM을 거기에 맞추면, "문의 유형: 정산 오차" 필드 값을 트리거로 Slack 알림이나 배치 로그 풀링 워크플로를 바로 연결할 수 있다.

HEDVION 시나리오: 정산 이상 조기 감지 채널로 연결하기

우리가 그리는 실제 적용 시나리오는 이렇다. 가맹점 사장이 정산 오류로 전화를 건다. 통화가 끝나면 음성 파일이 자동으로 파이프라인에 들어간다. 2~3분 내에 구조화 요약이 나오고, 문의 유형이 '정산 오차'로 분류되면 정산 시스템의 해당 가맹점 계정에 자동으로 태그가 붙는다. 같은 가맹점에서 2주 내에 동일 유형 민원이 3건 이상 쌓이면 정산팀에 알림이 간다. 여기서 사람이 개입해 실제 오류인지 확인한다.

이 흐름에서 음성 요약은 상담사 메모 작성 보조가 아니다. 정산 이슈의 조기 감지 채널이 된다. 배치 로그 분석보다 평균 1~2일 먼저 이상 징후를 잡을 수 있다는 게 우리 팀의 판단이다. 정산 오류가 누적되기 전에 잡는 것과 일주일치가 쌓인 다음 잡는 것은 처리 비용과 고객 이탈 가능성 모두에서 다르다. 다만 현실적인 트레이드오프도 직시해야 한다. 전사 WER이 30% 이상인 통화에서 자동 분류가 오작동하면 오히려 혼선이 생긴다. 그래서 신뢰도 임계값을 파이프라인의 게이트로 넣는 것을 필수로 본다. Whisper가 반환하는 단어 수준 확률(word-level probability) 평균이 0.75 이하이거나, LLM 분류 confidence가 낮으면 자동 액션 없이 사람 검토 큐로 분기하는 로직이다.

지금 바로 써먹을 실행 시사점

이 실험을 복기하며 팀이 정리한 적용 가능한 포인트들이다. 순서대로 따라가면 처음부터 막히는 지점을 줄일 수 있다.

1. Whisper initial_prompt에 도메인 용어부터 넣어라. 파인튜닝 없이 전문 용어 오인식을 60%까지 줄일 수 있다. 여러분 팀의 제품명, 서비스 코드, 업무 용어 20~30개를 리스트업해 initial_prompt에 집어넣는 것으로 시작하라. 비용 추가 없이 즉시 효과가 난다.

2. 화자 분리 없이 요약하지 마라. 전체 텍스트를 그냥 넣으면 상담사 스크립트 멘트가 오염원이 된다. pyannote.audio는 오픈소스로 로컬 실행 가능하다. 상업 서비스를 원하면 AssemblyAI diarization API가 한국어를 지원하며 분당 약 $0.009 수준이다. 화자 분리 한 단계가 요약 정확도를 18%p 가까이 끌어올렸다.

3. 구조화 출력 스키마를 먼저 설계하라. "요약해줘" 프롬프트 대신 JSON 스키마를 먼저 정의하고 LLM을 거기에 맞춰라. 최소한 issue_type, summary, resolution, escalation_needed 4개 필드는 반드시 포함시켜라. 자동화 연결 시 이 필드들이 트리거 조건이 된다.

4. 신뢰도 임계값을 자동 액션의 게이트로 설정하라. 전사 품질이 나쁜 통화에서 자동 분류가 오작동하면 시스템 신뢰를 잃는다. Whisper word-level probability 평균 0.75 이하이거나 LLM confidence가 낮으면 자동 액션 없이 사람 검토 큐로 분기하는 로직을 파이프라인에 반드시 포함시켜라. 자동화 커버리지를 높이는 것보다 오작동을 막는 게 먼저다.

5. 고객 이력 연결은 2단계로 미뤄도 된다. 단일 통화 내 맥락 파악으로 1단계를 안정화하는 것이 우선이다. 이전 통화 참조는 통화 ID와 고객 ID 기반 벡터 임베딩 검색을 붙이는 방식으로 확장 가능하지만, 파이프라인이 안정적으로 돌기 전에 붙이면 변수만 늘어난다. 기반이 돼야 이력이 의미가 있다.

— by slecs