실시간 음성 전사, 화자 구별까지 되는데 억양까지는 아직

오후 5시 55분, 한 참여자가 최근 진행한 음성 전사가 실시간 처리였는지 파일 업로드 방식이었는지 묻는 질문을 던지며 대화가 시작됐다.

무슨 일

질문을 받은 참여자는 "실시간 전사는 아마 처리량이 안될걸요"라며, 실시간 전사에는 별도로 맞춰진 모델이 필요하다고 답했다. 자신은 파일 업로드 방식으로 처리했다고 밝히면서도, 곧이어 실시간 처리 가능 여부를 직접 확인해보겠다며 초당 토큰 처리량(TPS)을 살펴보겠다고 덧붙였다. 이 자리에서는 위스퍼(Whisper)의 large-turbo 모델이 언급되며 성능이 좋다는 평가가 함께 나왔다.

다른 참여자가 "Tps 는 나오는데 모델이 지원안하지 않나요?"라며 스트리밍 처리 여부를 되묻자, 대화는 구글의 Chirp API로 옮겨갔다. 확인에 나선 참여자는 Chirp API가 이미 초기 버전 때부터 스트리밍을 지원해왔고, 아예 스트리밍 모드가 API에 내장돼 있다고 전했다. TPU 인프라 덕분인지 처리량도 충분하다는 평가와 함께, 구글 쪽 요금이 비싸지 않다는 언급도 이어졌다.

다만 위스퍼 자체의 스트리밍 지원 여부는 이 자리에서 명확히 정리되지 않았다. 위스퍼를 그록(Groq) 인프라에서 구동하는 경우 스트리밍이 되는지를 두고 "위스퍼는 groq에서 되지않아요?"라는 질문이 나왔지만, "스트리밍이 없었나"라는 반응만 돌아오며 결론 없이 넘어갔다. 이 과정에서 다른 참여자는 구글의 또 다른 번역 모델이 스트리밍 기능을 내세워 홍보했던 기억을 떠올리기도 했는데, 정작 화자들이 실제로 비교하려던 대상은 위스퍼와 Chirp 두 축이었던 셈이라 대화가 잠시 갈래를 타기도 했다.

맥락과 시사점

대화의 무게중심은 마지막에 실전 활용 시나리오로 옮겨갔다. 한 참여자가 "그 회의같은거 하면 억양 구분해서 Distribution까지는 못하겠죠 ?"라고 묻자, 다른 참여자는 "화자구별은 완벽하게 하던데요"라고 답했다. 즉 누가 말하고 있는지 구분하는 화자 분리 기능은 이미 실용 수준에 올라와 있다는 평가다. 다만 억양이나 어조 같은 세밀한 특성까지 구분해 화자별로 분포를 나누는 수준에 대해서는 "억양 구별은 모르겠네요"라며 명확한 답이 나오지 않았다.

이 대화는 실시간 음성 전사 기술의 현재 위치를 압축해서 보여준다. 파일 업로드 후 처리하는 방식과 실시간 스트리밍 처리 방식은 여전히 요구되는 모델과 인프라가 다르고, 구글 Chirp처럼 스트리밍을 처음부터 설계에 넣은 API가 앞서 있다는 인식이 자리 잡고 있다. 반면 오픈소스 진영의 위스퍼는 정확도로는 널리 쓰이지만 스트리밍 대응은 아직 사용자들 사이에서도 확신이 서지 않는 영역으로 남아 있다. "누가 말했는가"를 가르는 화자 구별은 이미 완성도 높은 기능으로 인식되는 반면, 회의록처럼 억양·어조 뉘앙스까지 반영한 정교한 구분은 다음 단계 과제로 남아 있다는 점도 눈에 띈다. 이런 격차는 실시간 전사 도구를 실무에 도입하려는 이들에게, 어떤 시나리오까지 지금 기술로 커버되는지를 가늠하는 기준점이 될 수 있다.

특히 이 대화에서 흥미로운 지점은, 화자 구별과 억양 구별이 언뜻 비슷해 보이지만 기술적으로는 전혀 다른 문제라는 걸 참여자들이 자연스럽게 구분해서 이야기했다는 점이다. 화자 구별은 "누가 말했는가"를 시간축 위에서 나누는 문제이고, 억양이나 어조를 반영한 분포 분석은 그 위에 화자별 특성을 추가로 라벨링해야 하는 훨씬 무거운 작업이다. 회의록 자동화처럼 실무에 바로 쓰이는 시나리오일수록 후자에 대한 수요가 크지만, 이 방 참여자들의 경험상으로는 아직 그 지점까지 상용 서비스가 자신 있게 답을 내놓지 못하고 있다는 인상이 강했다. 처리량과 비용, 그리고 정교함이라는 세 축이 동시에 만족되는 실시간 전사 서비스가 나오기까지는 시간이 더 필요해 보인다는 게 이날 대화가 남긴 잠정적인 결론이다.