경력·사례·글은 한국어 원문으로 제공됩니다.

← 모든 에피소드

학생·연구원 시절 · 학생·연구 시절 · 사람 개입 경로

말이 글자로 바뀌어도 남았던 문제

손을 쓰기 어려운 사람을 위해 음성 명령 앱을 만들었지만, 진료 현장에 도입하지 못했다. 이후의 상담 기록 활용을 함께 돌아보며, 오류를 확인할 위치를 생각한다.

그때
인식된 단어를 조건문에 더했지만 진료 현장에 도입하지 못했다.
지금
상담 기록 도구의 사용법과 보정 절차를 전달했다. 인식과 결과를 함께 확인할 방법도 더 살펴보고 싶다.

손을 쓰기 어려운 자리에서

대학원 시절 외부에서 맡은 과제로 치과 진료를 돕는 앱을 만들었다. 의사가 진료 중 손을 쓰지 않고 말로 특정 치아에 표시할 수 있게 하려는 것이었다. Unity로 만든 안드로이드 앱을 태블릿에 설치했고, 치아 번호와 활성·비활성·체크 같은 명령을 처리했다.

음성 인식은 말소리를 글자로 바꿔주는 도구를 썼다. STT(Speech-to-Text)라고 부르는 기능이다. 블루투스 헤드셋으로도 시험했지만, 현장에서 쓰는 단어를 제대로 알아듣지 못하는 경우가 있었다. 글자로 나온 결과에서 정해둔 단어를 찾아 명령으로 처리하는 방식이라, 말하는 사람도 그 방식에 맞춰야 했다.

운영자가 오류를 알려오면 같은 단어를 여러 번 말해봤다. 어떤 글자로 나오는지 보고, 그 형태를 조건문에 하나씩 추가했다. 음성 인식 엔진을 바꿀지도 고민했다. 일단 태블릿에 설치해 실제로 동작을 확인하는 일을 반복했다.

결국 진료 현장에 도입하지 못했다. 인식 품질과 사용성이 충분하지 않았던 것으로 기억한다. 말을 받아 글자로 만드는 데 성공한 것과, 손을 쓰기 어려운 사람이 쓸 만한 입력 방법을 만드는 것은 달랐다.

틀린 단어를 더 넣는 방법의 한계

내가 보완한 곳은 인식이 끝난 뒤였다. 도구가 어떤 글자를 돌려주면 그것을 명령으로 받아들일지 코드에 더했다. 같은 오류가 다시 나왔을 때 처리할 수는 있어도, 처음부터 다른 말로 인식되는 문제를 모두 해결할 수 있는 방법은 아니었다.

다시 살펴본다면 인식 전후를 나눠서 확인해볼 수 있겠다. 앞에서는 말소리가 어떤 텍스트가 되는지 보고, 뒤에서는 그 텍스트가 어느 명령으로 연결되는지 보는 것이다. 인식이 틀렸는지, 글자는 맞는데 명령 해석이 틀렸는지 구분해야 바꿀 곳도 알 수 있다.

현재의 방법 중에는 인식기에 자주 나오는 단어나 표현을 알려주는 기능이 있다. Google Cloud Speech-to-Text의 모델 적응(model adaptation)은 그런 표현을 인식 후보로 더 잘 고려하도록 돕는다. PhraseSet에 표현을 담거나 boost로 가중치를 줄 수 있다. 인식 뒤에 틀린 단어를 조건문에 더하는 것과 달리, 소리를 글자로 바꾸는 단계에 단서를 주는 방법이다. Google 음성 인식의 모델 적응

예를 들어 정해진 번호와 몇 가지 상태를 말하는 입력이라면, 자주 쓰는 표현을 미리 알려주는 방법을 검토할 수 있겠다. 다만 특정 단어가 잘 나오도록 가중치를 높이면 실제로 말하지 않은 단어가 결과에 들어갈 가능성도 커진다. 문서에도 이 한계가 설명돼 있다. 알고 있는 단어가 많이 나온다고 정확한 결과가 늘었다고 판단해서는 안 된다.

확인한다면 같은 녹음을 두고 설정 전후의 결과를 비교해볼 만하다. 기대하는 단어가 들어간 말뿐 아니라 비슷하게 들리는 다른 말도 함께 봐야 한다. 특정 한국어 표현과 사용 환경에 이 기능이 맞는지, 어떤 모델과 언어 조합에서 지원하는지는 먼저 확인해야 한다.

나중에는 요약 앞에서 다시 만났다

이후 회사에서는 고객 상담 음성파일을 클로바에 직접 올려 전사하고 요약하는 활용 방법을 제안했다. 담당자에게 도구 사용법과 결과 확인 방법을 직접 교육했다. 업로드와 확인은 담당자가 하는 수동 과정이었다.

그때 사투리의 한 단어가 다른 단어로 전사되면서 요약까지 틀어지는 사례를 확인했다. 담당자가 통화 뒤 텍스트 요약을 추가해 보정하도록 절차를 조정했다. 이후에도 사용한다는 이야기를 들었지만, 얼마나 자주 쓰고 시간이 얼마나 줄었는지까지 측정한 것은 아니다.

이것은 학생 때 만든 앱과 다른 일이다. 앞의 앱은 짧은 말을 명령으로 바꾸려 했고, 회사에서는 녹음된 상담 내용을 정리하는 데 도구를 썼다. 다만 인식 결과를 다음 단계가 그대로 받아 쓸 때, 처음의 오류가 뒤에서도 영향을 준다는 점은 함께 생각해볼 수 있다.

어디서 확인하면 덜 놓칠까

사람이 확인하도록 했다고 해서 문제를 다 풀었다고 보기는 어렵다. 무엇을 봐야 하는지 찾기 어렵다면 확인하는 사람도 놓칠 수 있다. 다시 검토한다면 인식된 말과 그 말로 처리하려는 결과를 나란히 보여주는 방법을 생각해보고 싶다.

명령 입력을 설명하는 예로, 번호만 인식되고 동작이 빠졌다면 임의로 채우지 않고 다시 물을 수 있다. 두 항목이 다 있어도 실제 말과 다르게 읽혔을 수 있으므로, 형식 검사만으로 맞는 명령이라고 할 수는 없다. 요약이라면 결과의 어느 부분이 전사 원문의 어느 대목에서 왔는지 함께 볼 수 있으면 확인할 곳을 찾는 데 도움이 될지 살펴볼 만하다.

손을 덜 쓰게 하려고 음성을 넣었는데, 매번 결과를 확인하느라 더 번거로워진다면 처음의 목적과 멀어진다. 얼마나 잘 알아듣는지와 함께, 틀렸을 때 얼마나 쉽게 알아채고 고칠 수 있는지도 봐야 할 것 같다. 그 균형을 당시에는 충분히 만들지 못했다.

다시 만난 문제

이 글의 연결

AI에게 화면 검수를 맡겼더니 화면이 빠졌다AI에게 화면 검수를 맡…

댓글

댓글은 GitHub 토론을 사용하며, 열면 GitHub 로그인이 필요합니다. 고객·사람이 드러나는 정보는 남기지 말아 주세요.

작성 2026-10-06

기억에 의존한 회고이며 당시 문서로 확인하지 못했다.