음성인식의 원리와 기획자가 알아둘 것

 

요즘 AI 스피커 이야기가 많이 들려서, 음성 서비스를 기획할 때 알아 두면 좋은 이야기를 정리해 보려고 해요.

저는 음성 기술을 연구하는 사람이 아니라서, 수식이나 알고리즘을 설명하지는 않습니다.

대신 "소리가 어떤 과정을 거쳐 글자가 되는지"와 "그 과정에서 기획자가 알고 있어야 할 약점"에 집중할게요.

일반적으로 알려진 개념 수준에서 적었고, 세부 방식은 제품마다 다를 수 있습니다.

 

사람이 말을 하면 마이크가 소리를 받아 전기 신호로 바꿔요.

이 신호를 짧은 구간으로 쪼개서 소리의 특징을 숫자로 뽑아냅니다.

그다음에는 이 특징이 어떤 소리 단위와 닮았는지 맞춰 보는 단계가 있어요.

"이 소리는 'ㅏ'에 가깝다"처럼 소리 조각을 추정하는 부분입니다.

마지막으로 소리 조각들이 모여서 어떤 단어와 문장이 되는지를 고릅니다.

이때 언어에 대한 지식이 쓰여요.

같은 소리라도 "이 단어 다음에는 이 단어가 올 가능성이 높다"는 정보를 활용해 가장 그럴듯한 문장을 고르는 거예요.

정리하면 소리를 받고, 특징을 뽑고, 소리 조각을 추정하고, 언어 지식으로 문장을 고르는 흐름입니다.

최근에는 딥러닝이 이 과정에 많이 쓰이면서 정확도가 눈에 띄게 올랐다는 이야기가 많아요.

여기서 꼭 구분해야 할 것이 있습니다.

음성인식은 소리를 글자로 바꾸는 일이고, 그 글자가 무슨 뜻인지 알아듣는 것은 또 다른 단계예요.

"불 꺼 줘"라는 글자를 정확히 받아 적었다고 해서, 서비스가 그 문장을 "거실 조명을 끄라는 명령"으로 이해하는 것은 아닙니다.

기획자가 만드는 대부분의 경험은 이 두 번째 단계, 곧 의도를 파악하고 알맞은 동작으로 연결하는 부분에 달려 있어요.

그래서 "음성인식이 좋아졌으니 대화형 서비스가 금방 되겠네"라는 기대는 조금 조심스럽습니다.

받아쓰기가 잘 되는 것과 대화가 되는 것은 거리가 있더라고요.

 

실험실에서는 정확하던 인식이 실제 환경에서는 떨어지는 경우가 많습니다.

기획자가 알아 두면 좋은 요인을 정리해 볼게요.

• 잡음: 주변 소음, 음악, TV 소리, 차 안의 엔진 소리
• 거리: 마이크에서 멀어질수록 소리가 작아지고 울림이 섞임
• 말하는 방식: 말 빠르기, 억양, 사투리, 아이와 어른의 목소리 차이
• 어휘: 사람 이름, 가게 이름, 신조어처럼 사전에 없을 법한 말
• 문장 길이: 짧은 명령어는 쉽지만 긴 문장은 틀릴 확률이 커짐

특히 고유명사가 어렵습니다.

가정해 보면 "OO식당 전화 연결해 줘"라고 했을 때, 식당 이름이 흔한 단어와 비슷하게 들리면 엉뚱한 곳으로 연결될 수 있어요.

이런 경우에는 인식 결과를 바로 실행하지 않고 한 번 확인하는 단계를 넣는 것이 안전합니다.

그래서 성능을 판단할 때는 발표된 수치만 믿지 않고, 우리 서비스가 쓰일 환경에서 직접 말해 보는 시험이 꼭 필요하다고 생각해요.

사무실처럼 조용한 곳과 차 안, 거리, 부엌처럼 시끄러운 곳에서 같은 문장을 여러 사람이 말해 보고, 몇 번이나 알아듣는지 세어 보면 감이 옵니다.

 

음성은 기다리는 시간이 길게 느껴져요.

화면 서비스에서는 1초나 2초쯤 기다려도 괜찮지만, 사람과 말하는 상황에서는 말이 끝나고 한참 뒤에 답이 나오면 어색합니다.

음성인식은 보통 소리를 서버로 보내 처리하고 결과를 돌려받는 구조가 많아서, 통신 상태가 나쁘면 더 느려져요.

그래서 기획할 때 "듣고 있어요" 같은 신호, 예를 들어 불빛이나 소리를 줘서 사용자가 기다림을 알 수 있게 하는 장치가 필요합니다.

또 어느 부분을 기기 안에서 처리하고 어느 부분을 서버에서 처리할지는 속도와 비용, 개인정보에도 영향을 줍니다.

 

가장 어려운 점은 기술이 아니라 기대감이라고 생각해요.

사용자는 말을 할 수 있으니 사람처럼 다 알아들을 거라고 기대합니다.

그런데 한두 번 못 알아듣는 경험을 하면 "역시 안 되네" 하고 쓰지 않게 돼요.

그래서 처음에 무엇을 할 수 있는지 알려 주고, 못 알아들었을 때 사용자가 다시 시도할 수 있는 방법을 안내해야 합니다.

예를 들어 "잘 못 들었어요. 음악 재생이나 날씨 중에서 말씀해 주세요"처럼 범위를 좁혀서 되묻는 방식이 효과적이었어요.

 

가정해 보겠습니다.

운전 중에 "요즘 많이 듣는 노래 틀어 줘"라고 말하는 상황이에요.

엔진 소리와 도로 소음이 있어서 인식 결과가 "요즘 많이 듣는 노래 틀어 줘"가 아니라 "요즘 말이 듣는 노래 틀어 줘"로 나왔다고 해 봅시다.

여기서 서비스가 할 수 있는 선택은 세 가지입니다.

• 그대로 실행해서 엉뚱한 곡을 튼다
• 인식 결과를 보여 주고 확인을 받는다
• 문장 전체가 아니라 "노래 틀어 줘"라는 핵심 부분만 먼저 잡고 인기 목록을 튼다

운전 중이라 화면을 볼 수 없다면 세 번째처럼 핵심 의도를 먼저 잡고, 필요하면 음성으로 짧게 되묻는 방식이 더 낫다고 봅니다.

숫자로 가정하면, 인식이 100번 중 5번 틀리더라도 틀렸을 때의 복구 방법이 매끄러우면 사용자는 크게 불편해하지 않을 수 있어요.

 

음성인식은 빠르게 좋아지고 있지만, 완벽하다고 가정하고 기획하면 사용자 경험이 먼저 무너질 것 같아요.

틀릴 수 있다는 전제 아래 되묻기와 확인, 복구 흐름을 설계하는 것이 기획자의 일이라고 생각합니다.

남는 질문도 있어요.

 

사투리와 억양이 다양한 한국어 환경에서 어디까지를 지원 범위로 둘지, 그리고 사용자가 편하게 느끼는 응답 속도의 기준은 어느 정도인지 궁금합니다.

이 부분은 직접 써 보면서 더 기록해 볼게요.