모든 AI 벤치마크(benchmark)는 우리에게 정확도(accuracy)를 최적화하라고 말했습니다.

그래서 우리는 정확히 그렇게 했습니다.

우리는 음성 인식 모델을 비교하고, 번역 품질을 평가하며, 다양한 텍스트 음성 변환(text-to-speech) 엔진을 테스트했고, 더 나은 결과를 얻기 위해 몇 주를 보냈습니다.

서류상으로는 모든 것이 유망해 보였습니다.

그러다 우리의 첫 번째 내부 데모 중 하나를 실행했습니다.

두 사람이 시스템을 통해 대화를 시작했습니다.

첫 번째 사람이 말을 마쳤습니다.

잠시 동안 아무 일도 일어나지 않았습니다.

두 번째 사람은 시스템이 듣기를 멈췄다고 가정하고 말을 시작했습니다.

1초 뒤에야 마침내 번역이 재생되었습니다.

AI가 실패한 것이 아니었습니다.

우리의 가정이 실패한 것이었습니다.

그 데모는 실시간 AI를 구축하는 방식에 대한 우리의 생각을 완전히 바꾸어 놓았습니다.

우리는 잘못된 것을 측정하고 있었다

프로젝트 초기 단계에서 우리의 유일한 질문은 이것이었습니다:

"어떻게 하면 번역을 더 정확하게 만들 수 있을까?"

그것은 당연한 목표처럼 보였습니다.

하지만 사람들이 애플리케이션을 사용하는 것을 지켜본 후, 우리는 그들이 우리의 AI 모델을 평가하는 것이 아니라 경험(experience)을 평가하고 있다는 사실을 깨달았습니다.

아무도 번역이 얼마나 정확한지 묻지 않았습니다.

대신 그들은 이렇게 물었습니다:

"왜 이렇게 오래 걸리나요?"

"아직 처리 중인가요?"

"다시 말을 시작해도 될까요?"

그 몇 초간의 침묵은 번역 품질의 미세한 개선보다 훨씬 더 중요했습니다.

그때 우리는 사용자들이 정확도를 인지하기 훨씬 전에 지연 시간(latency)을 인지한다는 것을 깨달았습니다.

실시간 시스템을 구축하는 것은 단순히 적절한 모델을 선택하는 것 이상이다

음성 번역은 단순히 하나의 AI 모델이 고립되어 작동하는 것이 아닙니다.

오디오를 캡처하고, 스트리밍하고, 텍스트로 변환하고, 번역하고, 다시 음성으로 변환한 다음, 마지막으로 청자에게 재생해야 합니다.

각 단계는 약간의 지연을 추가합니다.

개별적으로는 그 어떤 지연도 우려스러워 보이지 않았습니다.

하지만 그것들이 모여 대화가 얼마나 자연스러운지를 완전히 바꾸어 놓았습니다.

그로 인해 우리의 초점은 개별 모델을 개선하는 것에서 전체 파이프라인(pipeline)을 개선하는 것으로 옮겨갔습니다.

가장 큰 차이를 만든 작은 변화

우리의 첫 번째 구현 방식은 화자가 문장 전체를 마칠 때까지 기다렸다가 번역을 위해 전송하는 방식이었습니다.

엔지니어링 관점에서는 타당한 결정이었습니다.

더 많은 문맥(context)이 일반적으로 더 나은 번역으로 이어지기 때문입니다.

하지만 대화는 글로 쓰인 문단처럼 작동하지 않습니다.

사람들은 말을 멈춥니다.

스스로 말을 끊기도 합니다.

문장을 다시 시작하기도 합니다.

말하는 도중에 생각을 바꾸기도 합니다.

완전한 문장을 기다리는 방식은 불필요한 침묵을 만들어냈습니다.

우리는 접근 방식을 바꾸어, 부분적인 전사(transcript)가 도착하는 대로 번역을 시작하고, 더 많은 음성이 확보됨에 따라 출력을 지속적으로 개선하기 시작했습니다.

번역 품질이 가끔 약간 덜 정밀해지기도 했습니다.

하지만 대화는 훨씬 더 매끄러워졌습니다.

그때 우리는 더 나은 사용자 경험(user experience)이 항상 더 나은 AI 모델로부터 오는 것은 아니라는 사실을 진정으로 이해하게 되었습니다.

향후 프로젝트에 적용할 교훈

되돌아보면, 우리는 어떤 모델이 가장 성능이 좋은지를 묻는 데 너무 많은 시간을 소비했습니다.

오늘날이라면 우리는 다른 질문부터 시작할 것입니다.

사용자가 실제로 지연(delay)을 느끼는 지점은 어디인가?

파이프라인(pipeline)의 어느 부분이 가장 많은 지연 시간(latency)을 유발하는가?

어떤 개선 사항을 사용자가 실제로 체감할 수 있는가?

이러한 질문들은 또 다른 모델 벤치마킹(benchmarking)을 수행하는 것보다 훨씬 더 우리의 엔지니어링 작업 방향을 바꾸어 놓았습니다.

실시간 AI (real-time AI)를 구축하며 우리는 사용자가 개별 모델을 경험하는 것이 아니라는 점을 배웠습니다.

사용자는 전체 시스템을 경험합니다.

때로는 가장 큰 개선이 AI 모델을 교체하는 것이 아닐 수도 있습니다.

그것은 AI 모델 주변의 모든 것을 개선하는 것입니다.

이러한 교훈은 실시간 음성 대 음성 번역(speech-to-speech translation)을 위한 오픈 소스 기반의 개인정보 보호 우선 플랫폼인 PolyTalk을 구축하며 얻은 것입니다. 모든 반복(iteration) 과정은 지연 시간(latency), 스트리밍(streaming), 다국어 통신(multilingual communication)에 대한 우리의 가설에 도전해 왔으며, 우리는 새로운 릴리스가 나올 때마다 여전히 배우고 있습니다.

만약 여러분이 스트리밍 (streaming), 음성 AI (voice AI), WebRTC 또는 기타 저지연 (low-latency) 시스템을 포함하는 애플리케이션을 구축해 보셨다면, 여러분이 경험했던 엔지니어링 트레이드오프 (engineering trade-offs)에 대해 듣고 싶습니다. 하나의 지표를 최적화했는데, 정작 사용자는 다른 것을 더 중요하게 여긴다는 사실을 발견한 적이 있으신가요?

리소스 (Resources)

PolyTalk을 탐색하거나 프로젝트에 기여하는 데 관심이 있다면:

라이브 앱 체험하기: https://app.polytalk.io/
소스 코드 살펴보기: https://github.com/PolyTalkIO/polytalk
자세히 알아보기: https://www.polytalk.io/

피드백, 기능 아이디어, 버그 리포트가 있거나 기여하고 싶으시다면 언제든 의견을 들려주세요. 모든 대화와 기여는 우리가 PolyTalk을 더 나은 방향으로 만드는 데 도움이 됩니다.