힌글리시가 열어준 문: 음성 AI의 다음 전장

힌글리시는 방언이 아니라 아키텍처 문제다

음성 AI 스타트업 Wispr Flow가 힌글리시(Hinglish) 지원을 출시한 이후 인도 시장 성장세가 눈에 띄게 빨라졌다고 공개적으로 밝혔다. 표면적으로는 "인도 진출 성공 스토리"처럼 들리지만, 이 사례가 흥미로운 이유는 다른 데 있다. 힌글리시를 지원하기 위해 그들이 해결해야 했던 기술적 난제가, 음성 AI가 실제 도메인에서 쓸모 있어지기 위한 핵심 조건과 정확히 맞닿아 있기 때문이다.

힌글리시는 힌디와 영어가 문장 안에서 문법 단위로 뒤섞이는 코드스위칭(code-switching) 언어 현상이다. 단순히 영단어를 힌디식으로 발음하는 수준이 아니다. "मुझे यह meeting postpone करनी है क्योंकि client ने confirm नहीं किया" 같은 문장에서 힌디 동사 어미와 영어 명사가 자연스럽게 결합한다. 언어학자들은 인도 도시 중산층 2억~3억 명이 이 방식으로 실제 대화를 나눈다고 추정한다. 기존 ASR(자동 음성 인식) 시스템이 이 패턴 앞에서 무너지는 이유는 명확하다. 대부분의 모델은 단일 언어 코퍼스로 훈련되어 있고, 코드스위칭이 발생하는 지점에서 음향 모델과 언어 모델이 동시에 혼란을 겪는다. 연구에 따르면 코드스위칭 발화의 단어 경계 예측 오류율은 단일 언어 발화 대비 40% 이상 높다. Wispr Flow가 이 지점을 정조준했다는 것은, "인도 시장 진출"이라는 마케팅 언어 뒤에 실제로는 ASR 아키텍처 수준의 결정이 있었다는 뜻이다.

한국어 결제 현장도 이미 코드스위칭이다

HEDVION은 결제·정산·자동화를 직접 운영하는 작은 팀이다. 우리 사용자는 대부분 화면을 보며 타이핑한다. 그런데 음성 인터페이스가 CS 인입이나 정산 확인 단계에 붙기 시작하면 이야기가 완전히 달라진다. 그리고 그 달라지는 맥락을 들여다보면, 힌글리시 문제가 우리와 먼 이야기가 아니라는 걸 금방 알게 된다.

실제 결제·정산 맥락에서 사용자와 팀원이 쓰는 발화를 떠올려보면, 코드스위칭은 이미 일상이다. "PG사 에러 났어", "리펀드 언제 돼?", "이 트랜잭션 어뷰징 아니야?", "페이먼트 실패 로그 뽑아줘" — 이 문장들은 한국어도 아니고 영어도 아니다. 한국어 문법 구조에 영어 도메인 어휘가 자연스럽게 섞여 있다. 이건 힌글리시와 구조적으로 동일한 코드스위칭이다. 즉, Wispr Flow가 인도에서 맞닥뜨린 문제는, 우리가 한국어 음성 인터페이스를 결제 도메인에 붙이려 할 때 그대로 마주칠 문제다.

ASR이 결제 도메인에서 틀리면 돈이 나간다

음성 AI를 결제 플로우에 붙이는 것이 왜 어려운지를 구체적으로 따지면, 코드스위칭 외에도 여러 층위의 도전이 쌓인다. 가장 먼저 도메인 특화 어휘 문제가 있다. "취소 수수료", "정산 주기", "에스크로 해제", "빌링 어그리먼트" 같은 용어는 일반 목적 ASR 모델의 언어 모델 확률에서 낮은 점수를 받는다. 시스템이 잘못 알아듣거나, 알아들어도 의미를 오파악한다.

더 심각한 건 금액 처리다. "삼십만 원"과 "30만 원"은 발화 방식이 다르고, "삼천만 원"과 "3천만 원"이 혼용된다. 음성으로 금액을 입력받는 플로우에서 ASR이 숫자를 한 자리라도 틀리면, 그건 단순 오타가 아니라 실제 금전 손실이다. 이 때문에 금융 도메인 음성 인터페이스는 일반 음성 비서보다 훨씬 높은 정확도 기준을 요구한다. 업계에서는 금융 관련 음성 명령의 허용 WER(단어 오류율)을 2% 이하로 본다. 반면 일반 목적 ASR의 평균 WER은 영어 기준 58%, 한국어 기준 712% 수준이다. 도메인 파인튜닝 없이 범용 모델을 그냥 붙이는 건 애초에 옵션이 아니다. 트레이드오프는 명확하다: 파인튜닝 비용을 쓰거나, 오류로 인한 분쟁 처리 비용을 쓰거나.

HEDVION 팀이라면 어떤 접점부터 실험할까

우리 팀 규모에서 음성 AI 전체를 직접 개발하는 건 현실적이지 않다. 그러나 Wispr Flow의 사례에서 배울 수 있는 건 기술 자체가 아니라 전략이다. 불완전한 기술이라도 가장 좁은 접점에 먼저 심고, 거기서 실제 데이터와 피드백을 얻어 개선 루프를 만드는 것. 이 방식이 기술이 완성될 때까지 기다리는 것보다 훨씬 빠르다.

우리 서비스에서 음성 인터페이스가 실질적으로 붙을 수 있는 첫 번째 후보는 CS 인입 1차 트리아지다. "이체 실패했어", "환불 왜 안 돼", "카드 등록이 안 된다" — 이 유형의 인입은 패턴이 좁고 반복적이다. 의도 분류(intent classification) 정확도가 85% 이상만 나와도 1차 분류를 자동화하고 상담원에게는 복잡한 케이스만 넘길 수 있다. 우리 경험상 CS 인입의 4050%는 이런 반복 패턴에 해당한다. 이것만 자동화해도 상담원 투입 시간을 2030% 줄일 수 있다는 계산이 나온다. 두 번째 후보는 정산 이상 알림 확인이다. 정산 담당자가 "이 가맹점 이번 주 정산 왜 보류야?" 라고 물으면, 컨텍스트를 가진 시스템이 음성으로 답하는 구조다. 화면 전환 없이 확인만으로 끝난다. 이건 ASR 정확도보다 컨텍스트 추론과 정산 데이터 연결이 핵심이라, 기존 음성 레이어 위에 도메인 로직을 붙이는 방식으로 비교적 빠르게 실험할 수 있다.

지저분한 입력 처리 능력이 실제 경쟁력이다

Wispr Flow가 힌글리시를 처리하기 위해 쌓은 능력 — 혼합 언어 입력을 끊김 없이 파싱하고, 화자마다 다른 코드스위칭 비율을 다루고, 맥락에 따라 언어 경계를 실시간으로 예측하는 것 — 은 결국 지저분한 실세계 입력을 처리하는 능력의 한 형태다. 우리가 결제·정산 파이프라인에서 매일 다루는 문제도 구조적으로 동일하다. 실제 트랜잭션 데이터는 교과서처럼 깔끔하지 않다. 가맹점 코드는 시스템마다 다르고, 취소와 환불이 동시에 발생하고, 정산 주기 예외는 계약마다 다르다. 이 지저분함을 처리하는 파이프라인이 강할수록 자동화의 신뢰도가 올라간다.

코드스위칭을 다루는 언어 모델이 강해지는 방식과, 예외 케이스가 가득한 실서비스 데이터 파이프라인이 강해지는 방식은 놀랍도록 닮아 있다. 둘 다 "깔끔한 케이스"를 먼저 처리하고 나중에 예외를 추가하는 방식으로는 실서비스를 버티지 못한다. 처음부터 지저분함을 전제로 설계해야 한다. Wispr Flow가 힌글리시를 피하지 않고 정조준한 이유가 바로 이것이다. 그리고 그들이 그 판에서 데이터를 쌓는 동안, 깔끔한 입력만 처리하는 경쟁사들은 실서비스 내성을 키울 기회를 잃고 있다.

지금 바로 써먹을 수 있는 시사점

첫째, 우리 도메인의 코드스위칭 어휘 목록을 지금 만들어라. CS 인입 로그나 내부 슬랙 채널에서 팀원과 사용자가 실제로 쓰는 표현을 수집하면, 영어·한국어가 섞인 도메인 고유 어휘가 200~300개 수준에서 나온다. 이게 음성 AI를 도메인에 파인튜닝하기 위한 데이터의 씨앗이다. 오늘 오후에 시작할 수 있다.

둘째, 전체 플로우가 아닌 가장 좁은 접점 하나를 먼저 정의하라. "결제 전반에 음성을 붙인다"는 방향 대신, "월별 정산 상태 조회 음성 질의 하나만 처리한다"는 식으로 범위를 극단적으로 좁혀라. 범위가 좁을수록 정확도 요구치를 맞추기 쉽고, 실패해도 손실이 작다. Wispr Flow도 힌글리시 전체를 한 번에 해결한 게 아니라 특정 사용자 세그먼트에서 먼저 피드백 루프를 만들었다.

셋째, 현재 쓰는 범용 ASR의 WER을 도메인 발화로 직접 측정해두라. 기준선이 없으면 개선을 측정할 수 없다. 내부에서 결제 도메인 발화 샘플 20~30개를 만들고, Whisper나 Google STT 등 현재 후보들을 돌려서 오류율을 재봐라. *"리펀드 처리해줘"*를 시스템이 어떻게 받아적는지 보는 것만으로도, 도메인 파인튜닝이 필요한지 아닌지를 즉각 판단할 수 있다. 기술이 완성되기를 기다리지 말고, 우리가 실험해야 할 접점을 먼저 정의하는 것이 먼저다.

원문: Voice AI in India is hard. Wispr Flow is betting on it anyway — TechCrunch