Falcon ASR 소개, 음성을 글로 바꾸는 열린 앞단

TII UAE가 공개한 Introducing Falcon ASR은 말소리를 글로 옮기는 자동 음성 인식 모델을 소개하는 글입니다. 이 글이 내세우는 주장은 하나의 문장으로 정리됩니다. Falcon 언어 모델 곁에서 음성을 텍스트로 바꾸는 열린 앞단을 두겠다는 것입니다. 원문은 제목 아래 링크로 연결해 두었습니다.

안녕하세요, 패트릭입니다. 제가 이 글을 처음 읽을 때 마음에 걸린 것은 성능표가 아니라 위치였습니다. 요즘 언어 모델 이야기는 대부분 텍스트 안에서 끝나는데, 여기서는 맨 앞의 귀에 해당하는 부분을 새로 놓겠다고 말하고 있기 때문입니다. 왜 하필 지금 귀를 다시 만들까 하는 궁금증이 생겼고, 그래서 음성이 글로 바뀌는 과정을 처음부터 따라가 보기로 했습니다.

왜 지금 음성인식 이야기를 다시 꺼냈을까

음성 인식은 이미 끝난 문제처럼 보일 때가 많죠. 휴대폰 받아쓰기도 잘 되고 회의 녹취도 그럭저럭 되니까요. 그런데 막상 녹취를 열어보면 문장이 어딘가 어색하고, 누가 언제 말했는지는 헷갈리고, 조사 하나가 바뀌어 뜻이 달라지는 경우도 있습니다. 들리는 대로 옮기는 것과 읽을 수 있게 옮기는 것은 다른 일인데, 우리는 그 차이를 자주 잊어버립니다.

제가 이 글에서 가장 흥미롭게 본 부분은 Falcon 진영이 텍스트 모델만 키우지 않고 귀로 들어오는 입구를 함께 챙기기 시작했다는 점입니다. 언어 모델이 똑똑해질수록 음성으로 들어오는 요청도 늘어날 수밖에 없는데, 그 입구가 닫혀 있거나 남의 것에 기대고 있으면 전체 그림이 어색해지기 때문입니다. 그래서 이번 글은 단순한 모델 공개 소식이라기보다 앞으로 무엇을 하겠다는 방향 선언에 가깝게 읽혔습니다.

그렇다면 무엇을 선언한 것일까요. 말소리를 글로 바꾸는 일을 Falcon 곁에 두겠다는 것인데, 그 안에는 다국어 전사와 구두점, 대소문자와 타임스탬프까지 포함한 읽을 수 있는 텍스트를 만들겠다는 뜻이 들어 있습니다. 여기서부터는 한 걸음씩 들어가 볼 차례입니다.

말소리가 글로 바뀌기까지 무슨 일이 생길까

사람이 말을 들을 때는 파도가 아니라 뜻으로 듣습니다. 그런데 기계에게는 처음부터 뜻이 아니라 파형이 들어오는데, 이 파형은 길고 울퉁불퉁하며 말하는 사람마다 속도와 높낮이가 다릅니다. 그래서 곧바로 글자로 바꾸려 들기보다 중간에 오디오 특징을 뽑아내는 단계를 두는데, Falcon ASR이 log-mel spectrogram 같은 오디오 특징을 Transformer 기반 인코더 디코더 구조로 처리한다고 설명한 대목이 바로 그 부분입니다.

이 과정을 식당 주방에 비유하면 이해가 쉬운데요. 재료가 들어오면 먼저 손질해서 같은 크기로 썰어야 다음 조리가 수월하듯이, 오디오도 시간과 주파수 축으로 정리된 특징으로 바꾸면 뒤의 신경망이 패턴을 읽기 쉬워집니다. 인코더는 이 손질된 특징을 듣고 문맥을 쌓는 역할을 하고, 디코더는 그 문맥을 보면서 글자를 한 자씩 써내려가는 역할을 합니다. 듣는 쪽과 쓰는 쪽을 나눈 셈이죠.

저는 이 나누기가 생각보다 중요하다고 봅니다. 듣는 쪽이 길게 이어지는 소리를 잘 기억해야 뒤에 오는 단어가 자연스러워지고, 쓰는 쪽이 앞에서 쓴 단어를 기억해야 문장이 어긋나지 않기 때문입니다. 예를 들어 아침 회의에서 누군가 빨리 말한 문장을 받아쓴다고 상상해 보세요. 앞부분을 놓치면 뒷부분도 흔들리는데, 인코더가 앞뒤 문맥을 넓게 잡아주면 그런 흔들림이 줄어듭니다. 물론 구조가 그렇다고 매번 잘 된다는 뜻은 아닙니다. 다만 어디가 잘되면 전체가 좋아지는지 가늠할 수 있게 해준다는 점에서 구조 이야기는 숫자 이야기보다 오래 남습니다.

듣기와 이해를 나누면 뭐가 편해질까

여기서 재미있는 질문이 생깁니다. 왜 굳이 음성 모델을 따로 두고 언어 모델과 짝을 지으려 할까요. 한 모델이 처음부터 끝까지 다 하면 편하지 않을까요.

표면적으로 보면 하나로 합치는 편이 깔끔해 보입니다. 실제로는 그렇지 않은 경우가 많은데, ears에 해당하는 부분과 brain에 해당하는 부분이 요구하는 데이터와 학습 방식이 서로 다르기 때문입니다. 오디오 앞단은 초 단위로 이어지는 신호를 다루고 시간 정렬과 발음 변이에 민감한 반면, 텍스트 뒷단은 단어와 문장, 문서 수준의 의미를 다룹니다. 그래서 앞단에서 소리를 글로 잘 바꾸어 주면 뒷단의 언어 모델은 자기가 잘하는 일인 요약이나 질의응답, 번역에 집중할 수 있습니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이런 관점에서 보면 음성 앞단을 Falcon 곁에 두는 선택은 유지보수 측면에서도 이해가 됩니다. 받아쓰기 품질을 고치고 싶을 때 언어 모델 전체를 다시 만지지 않고 앞단만 손볼 수 있으니까요. 반대로 앞단이 흔들리면 뒷단이 아무리 좋아도 소용이 없다는 뜻이기도 합니다. 귀가 잘못 들으면 아무리 머리가 좋아도 답이 어긋나죠.

문제는 그다음입니다. 앞단과 뒷단을 나누면 사이를 잇는 약속이 필요해지는데, 그 약속이 바로 구두점과 대소문자, 타임스탬프 같은 읽을 수 있는 형태입니다. 기계가 읽기 편한 토큰 나열이 아니라 사람이 읽기 편한 문장이어야 뒷단도 덜 헤매기 때문입니다.

다국어 전사가 어렵다는 말의 실제 뜻

다국어를 지원한다는 말은 들으면 쉬워 보이는데, 막상 들여다보면 꽤 까다로운 약속입니다. 언어마다 소리의 자릿수가 다르고, 같은 알파벳을 써도 읽는 방식이 다르며, 띄어쓰기가 없는 언어도 있기 때문입니다. Falcon ASR이 다국어 전사를 겨냥한다고 말한 부분은 그래서 단순한 언어 목록 자랑이 아니라 여러 소리 체계를 하나의 귀로 듣겠다는 선언에 가깝습니다.

생각해보면 사람도 비슷하게 배웁니다. 영어만 듣던 귀에 갑자기 다른 언어의 대화를 틀어주면 어디서 단어가 끊기는지도 모르는데, 여러 언어를 오래 들은 사람은 끊기는 지점이 어렴풋이 들리기 시작합니다. 모델도 여러 언어의 오디오와 텍스트 쌍을 함께 보면서 경계를 어림하는 감각을 익히는데, 이 감각이 생기면 새로운 억양이나 비슷한 언어에도 조금 덜 당황합니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 다국어를 겨냥했다는 말과 모든 언어에서 똑같이 잘된다는 말은 다르니까요. 흔히 데이터가 많은 언어에서는 매끈하게 나오다가 자료가 적은 언어에서는 같은 구조라도 어색해지는 일이 생깁니다. 그렇다면 우리가 물어야 하는 것은 지원 언어의 개수가 아니라 어느 조건에서 어디까지 믿을 수 있는지입니다. 발표 글의 결을 보면 여러 벤치마크로 그 조건을 가늠하려는 태도가 엿보이는데, 이 부분은 뒤에서 숫자를 다루는 대목과 이어서 보겠습니다.

마침표 하나가 왜 그렇게 중요할까

받아쓰기에서 마침표와 쉼표는 장식이 아니라 뜻입니다. 같은 단어 나열이라도 어디서 끊느냐에 따라 질문이 부탁이 되고, 부탁이 경고가 되기도 하죠. 대소문자도 마찬가지인데, 영어에서 첫 글자를 키우느냐 마느냐에 따라 고유명사가 보통명사가 되기도 합니다. 그래서 구두점과 대소문자를 함께 내어준다는 설명은 읽는 사람을 위한 배려이자 뒷단 모델을 위한 배려입니다.

타임스탬프 이야기도 같은 연장선에 있습니다. 언제 누가 말했는지 시간 정보가 붙으면 회의록은 단순한 글 더미에서 찾아볼 수 있는 기록으로 바뀝니다. 예를 들어 한 시간짜리 기획 회의를 뒤늦게 합류한 동료에게 건넨다고 해보세요. 글만 있으면 처음부터 읽어야 하지만, 시간 표시가 있으면 자기가 궁금한 대목으로 바로 넘어갈 수 있습니다. 검색 구간을 좁힐 수 있다는 점에서 운영 비용도 줄어듭니다.

저는 이 대목에서 실무 감각이 느껴졌습니다. 연구실에서는 단어 오류율 하나만 보면 되지만, 현장에서는 마침표가 없으면 사람이 다시 손봐야 하고 그 손보는 시간이 곧 돈이기 때문입니다. 받아쓰기 다음 단계인 요약이나 번역이 매끈하려면 앞단에서 문장 경계와 시간 경계를 잘 잡아주는 편이 훨씬 낫습니다. 문장이 어긋난 채로 넘어가면 요약도 어긋나고, 시간이 어긋난 채로 넘어가면 자막도 어긋나니까요.

억양과 소음이 들어오면 모델은 어디서 흔들릴까

현장의 오디오는 교과서처럼 들리지 않습니다. 카페에서는 컵 부딪히는 소리가 끼고, 길거리에서는 바람 소리가 말을 갉아먹고, 회의실에서는 여러 사람이 겹쳐 말하면서 문장이 서로를 덮습니다. 억양도 마찬가지인데, 같은 문장이라도 어디서 배운 발음이냐에 따라 모음의 색이 달라집니다. Falcon ASR이 억양과 잡음 조건에서의 강건함을 겨냥한다고 말한 것은 그래서 실험실 점수보다 현장 점수를 보겠다는 뜻으로 읽힙니다.

왜 잡음에 약할까요. 오디오 특징 단계에서 말소리와 잡음이 비슷한 자리를 차지하면 인코더가 둘을 가르는 데 힘을 쓰게 되는데, 이 구분이 흔들리면 디코더가 쓸 다음 단어도 함께 흔들리기 때문입니다. 마치 시끄러운 식당에서 친구 말을 듣다가 앞 단어를 놓쳐서 뒷말까지 잘못 알아듣는 것과 비슷합니다. (참고로 저는 시끄러운 곳에서 회의록을 받아쓴 경험이 있는데, 그때는 마이크 위치 하나가 인식률보다 더 크게 느껴졌습니다.)

그렇다면 어떻게 덜 흔들리게 만들까요. 발표 글에서 말한 디코딩 최적화와 분할 같은 장치는 이런 흔들림을 줄이는 쪽에 가깝습니다. 한 번에 너무 길게 듣지 않고 적당한 길이로 나눠 듣거나, 다음 단어를 고를 때 너무 성급하게 한 가지만 보지 않고 여러 가능성을 저울질하면 갑작스러운 소음에 덜 넘어집니다. 물론 잡음을 완전히 없앨 수는 없습니다. 다만 넘어지는 지점을 뒤로 미루고, 넘어져도 문장 전체가 무너지지 않게 버티는 것이 목표가 됩니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 버팀이 실시간 대화에서도 같은 값으로 이어질까요.

긴 오디오는 왜 짧게 잘라서 듣게 될까

한 시간짜리 강연을 통째로 모델에 넣으면 좋을까요. 마음은 그렇지만 메모리와 계산은 금방 한계를 드러냅니다. 오디오가 길어질수록 기억해야 할 문맥이 길어지고, 한 번의 실수가 뒤로 길게 번지기도 합니다. 그래서 긴 오디오는 적당한 길이로 나눠 듣고 다시 잇는 방식을 쓰는데, 발표 글에서 말한 분할과 디코딩 최적화도 이 고민과 연결됩니다.

여기서 어려운 부분은 자르는 위치입니다. 문장 중간을 툭 잘라버리면 앞 조각과 뒤 조각이 서로 모르는 사이가 되어 문장이 어색해집니다. 그래서 조금씩 겹치게 자르거나 앞뒤 문맥을 함께 보고, 타임스탬프를 기준으로 다시 붙이는 손질이 필요합니다. 바게트를 썰 때 부스러기가 덜 생기게 사선으로 써는 것과 비슷한데, 자르는 기술이 결과의 매끈함을 좌우합니다.

저는 이 대목에서 운영의 아침을 떠올렸습니다. 밤사이 쌓인 고객 상담 녹취 수백 건을 아침마다 텍스트로 바꿔야 하는 팀이 있다고 해보세요. 하나하나 길게 붙잡고 있으면 아침 업무가 밀리고, 너무 잘게 자르면 문장이 깨져서 다시 손봐야 합니다. 적당한 길이로 나누고 겹치는 구간으로 매끈하게 잇는 능력은 그래서 연구실 점수를 넘어 운영의 리듬과 직결됩니다. 길게 듣는 것과 짧게 나눠 듣는 것 사이의 균형이 곧 비용이 되기 때문입니다.

숫자를 읽기 전에 물어야 하는 질문들

평가 이야기로 넘어가 볼까요. 발표 글은 LibriSpeech와 Common Voice, FLEURS 같은 벤치마크에서 단어 오류율 같은 표준 지표로 본다고 설명합니다. 처음 음성 인식을 접하는 분에게는 이름이 낯설 수 있는데, 각각의 역할이 조금씩 다릅니다. 낭독체처럼 정돈된 오디오가 있는가 하면, 여러 사람이 각자 환경에서 녹음한 모음이 있고, 여러 언어를 나란히 보는 모음도 있습니다. 하나의 시험만 잘 보는 것보다 여러 시험에서 고르게 잘 보는 편이 현장과 가깝습니다.

단어 오류율은 말 그대로 받아쓴 단어 가운데 틀린 비율을 재는 자입니다. 낮을수록 좋다는 방향은 분명한데, 이 숫자만 보고 모든 것을 판단하면 놓치는 것이 생깁니다. 바뀐 단어 하나와 빠진 조사 하나가 같은 1점으로 찍히지만, 사람이 느끼는 어색함은 다르기 때문입니다. 구두점이 찍혔는지, 문장이 읽히는지, 시간 정보가 맞는지는 이 숫자 안에 다 들어가지 않습니다. 그래서 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 어떤 조건에서 어디가 틀렸는지를 알아야 고칠 수 있기 때문입니다.

그렇다면 이 흐름은 어디에서 끊을 수 있을까요가 아니라 어디까지 믿을 수 있을까요. 발표 글만으로는 세부 점수를 알 수 없으니 섣부른 순위 매기기는 피하는 편이 낫습니다. 대신 이렇게 물으면 도움이 됩니다. 정돈된 낭독과 시끄러운 자유 발화에서 차이가 얼마나 날까. 데이터가 많은 언어와 적은 언어에서 경향이 갈릴까. 긴 오디오를 나눠 들을 때 경계에서 오류가 몰릴까. 이런 질문을 들고 원문의 다음 소식을 기다리는 태도가 숫자 하나를 외우는 것보다 훨씬 실용적입니다.

받아쓰기를 넘어 어디에 쓰일까

받아쓰기가 목적지가 아니라 입구라는 말이 있습니다. 글로 바뀌는 순간부터 요약과 번역, 음성 에이전트 같은 뒷일이 열리기 때문입니다. 발표 글이 전사 너머의 활용을 함께 말한 것도 같은 맥락인데, 귀로 들은 것을 텍스트로 잘 정리해 두면 그 다음 일들이 한결 수월해집니다.

예를 들어 고객 상담 녹취를 생각해 보세요. 글로만 바뀌어도 검색은 되지만, 요약까지 붙으면 팀장은 아침에 다섯 줄로 어제를 파악할 수 있습니다. 여기에 번역이 붙으면 다른 나라 지사와 같은 기록을 나누기도 쉬워집니다. 음성 에이전트로 가면 흐름이 더 길어지는데, 사용자가 말하면 받아쓰고, 뜻을 파악하고, 답을 만들고, 다시 음성으로 내보내는 고리가 생깁니다. 이 고리에서 앞단이 흔들리면 뒷단의 답도 흔들리니, 앞단의 품질은 전체 대화의 품질과 직결됩니다.

질문도 바뀌었습니다. 예전에는 받아쓰기를 얼마나 틀리지 않느냐가 질문이었다면, 이제는 받아쓴 다음에 무엇을 할 수 있느냐가 질문이 됩니다. 받아쓰기가 요약의 재료가 되고, 요약이 검색의 재료가 되고, 검색이 에이전트의 기억이 되는 식이죠. 그래서 음성 앞단을 Falcon 곁에 둔다는 말은 단순한 기능 추가가 아니라 앞으로 만들 일들의 재료를 곁에 두겠다는 말로 읽힙니다.

그래서 음성 앞단으로 무엇을 옮길 수 있을까

앞에서 미뤄뒀던 질문으로 돌아올 차례입니다. 이 앞단이 생기면 우리는 무엇을 앞쪽으로 옮길 수 있을까요. 저는 구두점과 시간 정보를 앞쪽으로 옮긴 선택이 오래 남을 것 같습니다. 뒷단에서 아무리 고치려 해도 앞에서 잃어버린 시간 경계와 문장 경계는 되살리기 어렵기 때문입니다. 앞에서 문장을 바로 세워주면 뒤에서는 요약이든 번역이든 훨씬 덜 헤맵니다.

물론 조심할 대목도 남습니다. 열린 대안이라는 표현은 반갑지만, 열려 있다는 말이 곧바로 현장에서 바로 쓸 수 있다는 뜻은 아닙니다. 라이선스 조건과 운영 무게, 실시간 처리 여부, 각 언어와 환경에서의 편차는 따로 확인해야 합니다. 발표 글이 방향을 보여주었다면, 이제는 각자의 자리에서 자기 오디오를 넣어보는 차례입니다. 회의실 녹음과 길거리 인터뷰는 다른 시험지니까요.

제가 앞으로 보고 싶은 것은 두 가지입니다. 하나는 긴 오디오와 시끄러운 환경에서 문장 경계와 시간 경계가 얼마나 매끈하게 유지되는지이고, 다른 하나는 앞단의 출력이 Falcon 언어 모델과 만났을 때 요약과 에이전트 대화에서 어떤 차이를 만드는지입니다. 귀가 바뀌면 대화가 바뀌는지, 대화가 바뀌면 일이 바뀌는지까지 이어서 보고 싶습니다. 그 연결이 확인되는 순간, 이번 공개는 모델 하나가 아니라 일하는 방식의 변화로 기억될 것 같습니다.