힌글리시가 알려준 것: 음성 AI는 언어가 아니라 맥락이다

힌글리시가 드러낸 진짜 문제: 언어 정확도가 아니라 맥락 파싱이다

Wispr Flow가 인도에서 힌글리시 지원을 출시하고 성장이 가속됐다는 소식은 표면적으로 '현지화 성공 사례'처럼 읽힌다. 그런데 이 사례의 핵심은 인도 시장 규모나 다국어 UI 전략이 아니다. "왜 기존 범용 음성 인식 모델은 힌글리시 앞에서 무너졌는가"라는 질문에 답하는 과정이 더 중요하다.

인도의 언어 현실을 숫자로 보면 압도적이다. 헌법이 인정하는 공식 언어만 22개, 방언까지 포함하면 수백 개다. 그런데 실제 도시 거주 화이트칼라층이 사용하는 언어는 그 어느 공식 언어도 아니다. 힌디와 영어가 문장 중간에 아무 예고 없이 교차하는 코드스위칭(code-switching) 언어다. "Yaar, mujhe is payment ka reconciliation karna hai, but the ledger entries don't match"처럼 힌디 구어체 단어, 영어 금융 용어, 비공식 표현이 한 문장 안에 공존한다. OpenAI Whisper 기반 범용 모델로 이 입력을 처리하면 인식 오류율이 표준 영어 대비 3~4배 높아진다는 결과가 복수의 인도 스타트업 내부 벤치마크에서 보고됐다. Wispr Flow가 힌글리시 전용 파인튜닝을 별도로 진행한 이유는 명확하다. UI에 힌디 번역을 추가하는 게 아니라, 모델이 언어 전환 패턴 자체를 학습하도록 해야 비로소 작동한다.

결제·정산 현장에도 '힌글리시'가 있다

HEDVION은 결제 게이트웨이 연동, 정산 자동화, 대사(reconciliation) 파이프라인을 직접 운영한다. 우리가 매일 처리하는 입력 데이터는 교과서와 거리가 멀다. 실무자가 슬랙에 남기는 정산 요청 메시지를 그대로 옮기면 이렇다. "어제 오후 카드 승인건 중에 A 가맹점 거 환불 처리 해줘, 수수료는 원복하고 부가세는 그대로 놔둬." 이 문장 하나에 의존적 시간 표현, 복수 조건 필터, 금액 조작 규칙, 생략된 주체가 동시에 압축되어 있다. ERP가 기대하는 정형 입력과는 차원이 다르다.

이게 힌글리시 문제와 구조적으로 동일한 이유는 단순하다. 힌글리시 화자가 언어를 섞는 것은 부주의해서가 아니라 그것이 자연스러운 사고 흐름이기 때문이다. 결제 실무자가 구어체 혼합 메시지를 보내는 것도 시스템 적응 실패가 아니라 업무 현실의 반영이다. "역산", "대사 오차", "cut-off 기준", "수취인 변경 건"처럼 도메인 전문 용어와 일상 구어체가 섞인 표현을 음성으로 처리하려면, '한국어를 잘 인식하는 것'이 아니라 '금융 구어체의 맥락 의존적 의도를 파싱하는 것'이 핵심이 된다. 이 구분을 흐리면 음성 AI 도입은 처음부터 잘못된 목표를 향한다.

음성 AI를 정산 워크플로우에 붙이면 실제로 어디서 부서지는가

단순 조회는 지금도 작동한다. "이번 달 카드 매출 합계 보여줘"나 "미수금 리스트 뽑아줘" 수준의 명령은 현재 음성 AI 기술로 충분히 처리된다. 문제는 이런 단순 조회가 실제 결제·정산 업무 전체에서 차지하는 비중이 20%도 안 된다는 점이다. 나머지 80%는 조건이 복잡하고, 이전 대화 맥락에 의존하며, 확인·승인 단계가 반드시 필요하다. "아까 말한 그 건"이라는 지시 대명사가 대화 3턴 전 발화를 가리킬 때 범용 모델은 대부분 맥락을 잃는다.

더 심각한 문제는 오류 허용 기준의 차이다. 음성 인식 정확도가 95%라면 일반 소비자 앱에서는 훌륭한 수치다. 그러나 결제·정산 도메인에서는 나머지 5%의 오류가 어디에 떨어지느냐가 결정적이다. "3,500만 원"과 "350만 원"은 음소 차이가 크지 않지만 정산 금액 오류로는 치명적이다. 국내 한 핀테크 팀이 내부 음성 입력 프로토타입을 실험했을 때, 음성 인식 오류로 인한 금액 파싱 실수가 전체 테스트 케이스의 약 8%에서 발생했고 이것이 프로덕션 도입을 보류한 결정적 이유였다. 정산 자동화가 요구하는 정확도 기준은 99.5%가 아니라 99.99%다. 이 간극을 직시해야 한다.

Wispr Flow 사례에서 가져와야 할 두 가지 설계 원칙

Wispr Flow가 힌글리시 환경에서 선택한 전략 중 우리 도메인에 이식할 수 있는 포인트가 두 개 있다.

첫째, 에러를 숨기지 말고 명시적으로 드러내라. 불확실성이 높은 입력 환경에서 "아마 맞겠지"로 넘어가는 시스템은 신뢰를 잃는다. Wispr Flow는 인식 신뢰도가 낮을 때 사용자에게 재확인 프롬프트를 띄우는 방식으로 이를 처리했다. 결제·정산 컨텍스트에서는 이 원칙이 훨씬 더 엄격하게 적용되어야 한다. 음성 명령이 모호하면 "그냥 실행"은 옵션이 아니다. 확인 → 표시 → 승인의 3단계 플로우가 기본값이어야 한다. 감사 추적(audit trail)이 의무인 환경에서 "시스템이 자동 판단했다"는 로그만으로는 부족하고, 사람이 확인한 기록이 반드시 있어야 한다.

둘째, 현지화는 UI 레이어가 아니라 모델 레이어에서 해결하라. 힌글리시 지원을 힌디 번역 인터페이스로 해결하려 했다면 Wispr Flow는 실패했을 것이다. 우리도 마찬가지다. "카드 수수료 역산해서 가맹점 정산금 다시 계산해줘"라는 문장은 범용 한국어 NLP 모델이 의도를 제대로 파싱하지 못한다. '역산'이라는 도메인 용어, '가맹점 정산금'이라는 복합 개념, '다시 계산'이라는 트리거 액션이 결합된 이 구조는 금융 특화 파인튜닝이나 도메인 지식이 주입된 프롬프트 설계 없이는 풀리지 않는다. 이것은 한국어를 잘 아는 범용 모델로 커버되는 영역이 아니다.

HEDVION이라면 지금 어떻게 접근하는가 — 실제 시나리오

솔직히 말하면, 지금 당장 음성 AI를 프로덕션 정산 워크플로우에 붙일 계획은 없다. 정확도 요건, 감사 추적 의무, 오류 발생 시 책임 귀속 문제를 동시에 해결하기 전까지는 무리다. 음성 명령 하나가 수천만 원짜리 정산에 영향을 미칠 수 있는 환경에서는 신중할 수밖에 없다. 그러나 '보고 있는 단계'와 '아무 준비도 안 하는 단계'는 완전히 다르다.

우리가 지금 실제로 진행 중인 준비 작업은 세 가지다. 첫째, 실무자 발화 데이터 수집. 슬랙, 이메일, 내부 티켓에서 실제 정산 요청 문구 패턴을 수집하고 분류하고 있다. 어떤 표현이 자주 쓰이는지, 어떤 조합이 모호한지를 먼저 파악해야 모델 설계와 파인튜닝에 의미 있는 방향을 잡을 수 있다. 둘째, 낮은 리스크 구간에서 파일럿. 읽기 전용 조회(매출 요약, 미수금 현황 확인)에 음성 인터페이스를 붙여 정확도와 실사용 패턴을 측정한다. 쓰기·변경이 없는 구간은 오류가 나도 안전하고, 여기서 쌓인 실패 로그가 나중에 도메인 특화 학습 데이터가 된다. 셋째, fallback 설계를 먼저 완성. 음성 입력이 모호하거나 신뢰도가 낮을 때 어떤 경로로 처리할지를 프로덕션 도입 이전에 확정해놓는다. fallback 없는 음성 AI는 결제 도메인에서 시한폭탄이다. Wispr Flow가 힌글리시 화자의 실제 발화 데이터를 확보하고 나서야 돌파구를 찾았듯, 우리도 '한국 결제 현장의 금융 구어체'를 먼저 데이터화하는 데 시간을 써야 한다.

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

음성 AI를 도입하든 안 하든, 이 논의에서 즉시 적용 가능한 결론이 세 가지 있다.

입력 현실을 먼저 감사(audit)하라. 지금 팀 내에서 처리되는 요청 메시지들이 얼마나 정형화되어 있는지 들여다봐라. 슬랙, 이메일, 티켓에서 실제 요청 50건만 분석해도 자동화 가능 구간과 여전히 사람 판단이 필요한 구간의 경계선이 보인다. 이 분석이 음성 AI 준비도 측정이자 현행 자동화 파이프라인의 빈틈 진단이다. 도구가 없어도 지금 당장 할 수 있다.

도메인 용어 사전을 지금 만들어라. 금융 구어체 파싱 문제는 음성 AI를 붙이는 순간 갑자기 생기지 않는다. 텍스트 자동화 단계에서 이미 동일한 문제가 존재하고 있고, 사람이 암묵적으로 해소하고 있을 뿐이다. "역산", "대사 오차", "cut-off 이후 건", "원복 처리" 같은 표현을 팀 내에서 어떻게 정의하는지 지금 문서화해두면, 어떤 AI 레이어를 붙이더라도 온보딩 비용이 대폭 줄어든다.

오류 노출 설계를 기본값으로 삼아라. 자동화 시스템이 불확실할 때 어떻게 행동하는가—이 설계 결정이 결제 도메인에서 시스템의 신뢰도를 결정한다. "잘 모르면 멈추고 확인을 요청한다"는 원칙은 음성 AI뿐 아니라 지금 운영 중인 모든 자동화 플로우에 동일하게 적용된다. 힌글리시 문제를 돌파한 핵심은 완벽한 인식 정확도가 아니었다. 안전하게 실패하도록 처음부터 설계하는 것이었다. 그 원칙은 인도 음성 AI 스타트업만의 것이 아니다.

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