WebRTC AEC로 해결되지 않는 에코 문제, 어떻게 해결하나요?

WebRTC AEC로 해결되지 않는 에코 문제는 대부분 구조적인 원인입니다. WebRTC의 에코 제거기(AEC3)는 다채널 콘텐츠가 감지되지 않으면 에코 참조를 한 채널로 줄여 처리하도록 만들어져 있어, 스피커가 여러 개인 제품의 에코는 남을 수밖에 없습니다. 해결책은 다채널 참조를 채널별로 처리하는 전용 에코 제거를 음성인식 앞단에 두는 것이고, 그때 음성인식 엔진은 바꾸지 않습니다.

이 글은 오픈소스를 깎아내리는 글이 아닙니다. WebRTC AEC가 어디까지 잘하는지를 먼저 적고, 에코가 남는 네 가지 구조적 원인과 그 경계를 넘는 제품이 무엇을 기준으로 다음 선택을 해야 하는지를 정리합니다.

• WebRTC AEC3는 다채널 콘텐츠가 감지되지 않으면 에코 참조를 한 채널로 처리합니다 — 공식 소스코드에 그 처리가 있습니다 [1].
• 스피커의 비선형 왜곡은 선형 필터로 잡히지 않는 에코를 만들며, 업계 표준 평가(ICASSP AEC Challenge)가 그 조건을 시나리오에 포함할 만큼 흔합니다 [2].
• 안내음 도중에 사용자가 말하는 더블토크는 통화용 에코 제거기가 가장 약한 구간이고, 키오스크·로봇에서는 그것이 기본 상황입니다 [3].
• 기존 음성인식 엔진을 교체하거나 재학습하지 않고 전처리만 바꾸는 것이 도입 저항이 가장 낮은 경로입니다 — 기존 음성인식 엔진을 바꾸지 않고 인식률만 높일 수 있나요?

WebRTC AEC는 어디까지 해결해 주나요?

WebRTC의 에코 제거기(AEC3)는 1:1 화상통화라는 본래 목적 안에서는 잘 작동합니다. 노트북이나 스마트폰처럼 스피커가 1~2개이고, 상대방 목소리가 참조 신호로 명확히 주어지며, 처리 결과를 사람이 듣는 상황이 설계 전제입니다. 참조 신호와 마이크 신호 사이의 지연을 스스로 추정하고, 라이선스 비용 없이 바로 쓸 수 있습니다.

문제는 이 전제를 벗어나는 순간 시작됩니다. 키오스크 안내음, 로봇의 음성 출력, 차량의 6~8개 스피커, 매장 배경음악처럼 실제 제품 환경은 화상통화와 조건이 전혀 다릅니다. WebRTC AEC가 “안 되는” 게 아니라, 애초에 그 환경을 위해 만들어지지 않은 것입니다. 설정 문제가 아니라 적용 범위의 문제인 경우가 많습니다.

왜 WebRTC AEC로도 에코가 남나요? — 4가지 구조적 원인

결론부터 말하면, 남는 에코의 원인은 거의 항상 다음 넷 중 하나입니다.

1. 참조 신호가 한 채널로 합쳐집니다

AEC3는 다채널 스피커 출력을 그대로 처리하지 않습니다. 적절한 다채널 콘텐츠가 감지되지 않으면 참조 채널을 한 개로 줄이는 처리가 공식 소스코드에 들어 있습니다 [1]. 스피커마다 다른 소리를 내는 5.1채널이나 차량 환경에서는 합쳐진 참조와 실제 에코 경로가 어긋나므로, 지울 수 없는 에코가 구조적으로 발생합니다.

2. 스피커의 비선형 왜곡

소형 스피커를 큰 음량으로 구동하면 출력 신호가 원본의 선형 변환이 아니게 됩니다. 선형 적응 필터는 이 성분을 모델링하지 못합니다. ICASSP 2021 AEC Challenge는 합성 평가 시나리오에 스피커 비선형 왜곡을 포함시켰습니다 [2] — 업계 표준 평가가 그 조건을 반영할 만큼 실제 기기에서 보편적인 문제라는 뜻입니다.

3. 지연과 클럭 드리프트

참조 신호와 마이크 입력 사이의 지연이 크거나 흔들리면 적응 필터가 에코 경로를 따라가지 못합니다. 재생 버퍼가 긴 임베디드 오디오 스택, 블루투스 경로, 별도 앰프를 거치는 구조에서 자주 발생합니다.

4. 더블토크(동시 발화)

안내음이 나가는 도중 사용자가 말하는 상황 — 키오스크와 로봇에서는 이것이 기본 상황입니다 — 에서 필터 적응이 흐트러지며 에코가 새거나 사용자 음성이 깎입니다. 통화용 에코 제거기는 이 구간을 더블토크로 감지해 억제를 강하게 걸거나 적응을 멈추는 방식으로 대응하는데, 사람이 듣는 통화에서는 잠깐의 억제가 허용되지만 음성인식에는 그 잠깐이 곧 인식 실패입니다 [3].

다채널 스피커 환경에서는 왜 실패하나요?

가장 오해가 많은 지점이라 따로 다룹니다. 에코 제거의 원리는 “스피커로 내보낸 신호(참조)를 알고 있으니, 마이크에 되돌아온 만큼을 계산해서 빼는 것”입니다. 이 원리가 성립하려면 어떤 스피커에서 어떤 신호가 나갔는지를 알아야 합니다.

스피커가 6개면 에코 경로도 6개입니다. 참조를 하나로 합쳐 버리면 6개 경로의 서로 다른 지연·잔향·크기가 뭉개진 “평균 에코”만 추정할 수 있고, 실제 마이크에 도달한 에코와의 차이는 그대로 남습니다. 홈시어터 입체음향이나 차량처럼 채널별 콘텐츠가 다른 환경일수록 잔여 에코는 커집니다.

mpAEC는 반향 채널 수에 제한을 두지 않고(3개 이상 지원) 스테레오·5.1채널·차량 6~8개 스피커 환경에 대응합니다. 다만 채널이 늘수록 계산 복잡도가 커지고 성능 저하가 있을 수 있어, 실제 스피커 배치와 연산 플랫폼으로 확인합니다. 그 연산을 제품의 하드웨어 예산 안에서 실시간으로 처리할 수 있는가가 관건이고, 이것이 실시간 처리인수(RTF) 같은 지표를 조건과 함께 읽어야 하는 이유입니다. 원리와 조건은 mpAEC에 정리돼 있습니다.

남은 에코는 음성인식(ASR)에 어떤 영향을 주나요?

잔여 에코는 통화에서는 “거슬리는 소리”지만, 음성인식 앞단에서는 인식 오류가 됩니다. 남은 에코는 잡음이 아니라 ‘말’입니다 — 제품이 내보낸 안내 음성이 그대로 마이크에 들어오므로 인식 엔진은 그것을 사용자의 발화로 받아 적습니다. 키오스크가 자기 안내음을 주문으로 알아듣고, 호출어 감지기가 스피커 소리에 깨어납니다.

더 나쁜 경우는 과도한 억제입니다. 에코를 잡으려고 서프레서를 세게 걸면 사용자 음성까지 깎이고, 사람 귀에는 깨끗하게 들려도 인식률은 오히려 떨어집니다. 에코 제거기가 통화 품질(사람 청취) 기준으로 튜닝되어 있을 때 흔히 생기는 일입니다. 로봇이 자기 소리 때문에 사람 말을 놓치는 문제도 같은 구조입니다.

그래서 음성인식용 전처리는 “얼마나 지웠는가”가 아니라 “목표 음성을 얼마나 보존했는가”를 기준으로 설계되어야 합니다. mpWAV가 에코 제거(mpAEC)와 빔포밍(mpBeamforming)을 결합한 전처리 mpAB에서 목표 음성의 왜곡을 억제하는 선별 제거를 설계 기준으로 두는 이유입니다.

WebRTC AEC로 안 되는 에코는 어떻게 해결하나요?

해결 경로는 세 단계입니다. 순서대로 점검하면 불필요한 투자를 피할 수 있습니다.

1단계 — 원인을 특정합니다

잔여 에코가 나는 조건을 좁힙니다. 음량을 올릴 때만 나는가(비선형), 특정 콘텐츠에서만 나는가(다채널), 말이 겹칠 때만 나는가(더블토크), 기기를 옮기면 달라지는가(지연·경로 변화). 원인별로 대책이 전혀 다르기 때문에 이 단계를 건너뛰면 안 됩니다.

2단계 — 참조 신호 경로를 확보합니다

어떤 에코 제거를 쓰든, 스피커로 나가는 신호를 채널별로 깨끗하게 참조로 받을 수 있어야 상한 성능이 나옵니다. 오디오 스택에서 루프백 참조를 뽑을 수 있는지, 지연이 안정적인지 먼저 확인하십시오. 이것이 안 되는 구조라면 마이크 어레이 입출력을 함께 처리하는 모듈형 하드웨어가 현실적인 답이 됩니다.

3단계 — 환경에 맞는 전용 에코 제거로 교체합니다

다채널 스피커, 고음량 비선형, 상시 더블토크 중 하나라도 해당하면 범용 라이브러리 튜닝으로는 한계가 있습니다. 이때는 다채널 참조를 채널별로 처리하는 전용 에코 제거를 음성인식 앞단에 배치하는 것이 정석입니다. mpAEC는 근단 신호가 있어도 안정적으로 에코를 제거하도록 만들어져 더블토크 검출 단계가 필요 없고, 원단 신호를 무상관화하는 처리도 필요 없으며, 수렴이 빠릅니다. 한국·미국·중국에 등록된 특허 기술이며, DSP 포팅 모듈·AP용 소프트웨어·FPGA 세 가지 형태로 제품 하드웨어 조건에 맞춰 도입할 수 있습니다.

중요한 것은 이 교체가 음성인식 엔진에 손대지 않고 이루어진다는 점입니다. 전처리가 목표 음성을 왜곡하지 않으면, 보유한 인식 엔진의 재학습 없이 입력 품질 개선분만큼 인식률이 오릅니다. 로보케어의 생활 소음 속 돌봄 로봇에 마이크 어레이와 전처리를 적용했고, ETRI(한국전자통신연구원)와는 로봇 탑재 마이크 어레이 잡음 제거를 연구했습니다.

WebRTC AEC3와 전용 다채널 에코 제거는 무엇이 다른가요?

공정하게 덧붙이면, WebRTC AEC3는 오픈소스 프로젝트로서 훌륭한 엔지니어링이며 화상회의 소프트웨어라는 본래 용도에는 여전히 좋은 선택입니다. 문제는 용도가 다른 곳에 가져다 쓸 때 생깁니다.

어떤 경우에는 WebRTC AEC로 충분한가요?

모든 경우에 전용 솔루션이 필요한 것은 아닙니다. 스피커가 1~2개이고 채널별로 다른 콘텐츠를 재생하지 않는 경우, 적정 음량으로 구동해 비선형 왜곡이 작은 경우, 참조 신호 지연이 안정적인 일반 PC·모바일 오디오 스택인 경우, 그리고 처리 결과를 사람이 듣는 통화·회의 용도인 경우 — 이 조건을 모두 만족하면 WebRTC AEC로 충분할 가능성이 높습니다.

반대로 다채널 스피커, 고음량 소형 스피커, 상시 안내음 위의 더블토크, 음성인식 앞단 중 하나라도 해당하면 범용 에코 제거의 적용 범위를 벗어난 것입니다. 이 경우 튜닝에 시간을 쓰기보다 전용 전처리를 검토하는 편이 개발 일정상 빠릅니다. 이 기준은 PoC 전 체크리스트의 항목이기도 해서, 문의 전에 스스로 가려 보실 수 있습니다.

성능은 어떻게 검증해야 하나요?

벤더가 “에코 ○○dB 억제”를 제시하면 반드시 조건을 물어야 합니다. 에코 억제량(ERLE)은 배경 소음이 없는 조용한 방의 단일 발화에서 잰 값이기 쉽고, 억제량이 높아도 더블토크에서 목표 음성이 깎이면 인식률은 떨어집니다. 억제량과 사람이 느끼는 품질이 반드시 같이 가지 않는다는 것이 표준 평가에서도 드러난 사실입니다 [3].

실무 검증 순서는 이렇습니다. 첫째, 자사 제품의 실제 환경(스피커 배치·음량·소음)에서 녹음한 데이터로 평가합니다. 둘째, 억제량이 아니라 처리 후 인식률(WER 등)을 최종 지표로 삼습니다. 셋째, 수치에는 입력 SNR·잔향·음량 조건이 병기되어야 합니다. 지표를 읽는 방법은 SI-SDR·SNR·RTF 읽는 법에, mpWAV의 제3자 시험 실측값은 기술 페이지의 성능 표에 시험 조건과 함께 있습니다. 상세 시험 문서와 특허 청구항은 비밀유지계약 뒤에 제공하며, 도입 판단은 고객 환경 데이터 기반 PoC로 확인합니다.

참고자료

• [1] WebRTC Project, 「echo_canceller3.cc」 (AEC3 구현), webrtc.googlesource.com
• [2] K. Sridhar, R. Cutler, A. Saabas, T. Parnamaa, M. Loide, H. Gamper, S. Braun, R. Aichner, and S. Srinivasan, 「ICASSP 2021 Acoustic Echo Cancellation Challenge: Datasets, Testing Framework, and Results」, IEEE ICASSP, 2021
• [3] R. Cutler, A. Saabas, T. Parnamaa, M. Purin, E. Indenbom, N.-C. Ristea, J. Gužvin, H. Gamper, S. Braun, and R. Aichner, 「ICASSP 2023 Acoustic Echo Cancellation Challenge」, IEEE ICASSP, 2023