웨이크워드 음성 비서 웹서비스: 상시 마이크는 어디까지 브라우저에서 처리할까?

"시리야"라고 부르면 그때부터 듣고 반응하는 기능은 서로 다른 두 문제로 나뉩니다. 하나는 호출어를 알아듣는 일이고, 다른 하나는 호출어 뒤의 명령을 알아듣는 일입니다. 둘을 같은 음성 인식으로 풀려고 하면 구조가 어긋납니다.

상시 듣기와 명령 인식을 한 모델로 풀 수 없는 이유

하루 종일 켜 두는 쪽은 "이 소리가 호출어인가"만 판단하면 됩니다. 이 모델은 작아도 되고, 기기 안에서 돌아야 합니다. 호출어 뒤의 문장을 받아 적는 일은 크고 정확한 모델이 필요하지만, 몇 초만 돌리면 됩니다.

저는 이 둘을 한 모델로 합치는 설계가 가장 흔한 실수라고 봅니다. 큰 모델을 계속 돌리면 비용과 전력이 문제가 되고, 작은 모델로 명령까지 받으면 인식률이 떨어집니다.

마이크를 계속 열어 두는 조건: 보안 컨텍스트와 앞에 열린 탭

브라우저는 getUserMedia로 마이크 스트림을 엽니다. HTTPS 또는 localhost에서만 동작하는 보안 컨텍스트 기능입니다. 암호화 없이 사설 IP 주소로 연 페이지에서는 마이크 권한 창 자체가 뜨지 않습니다.

탭이 백그라운드로 가면 타이머와 오디오 처리가 제한될 수 있고, 모바일 브라우저는 화면이 꺼지면 스트림이 끊기기도 합니다. 상시 수집은 "앞에 열려 있는 화면 하나"를 전제로 설계하는 편이 안전합니다.

호출어 감지 후보 세 가지와 음성이 밖으로 나가는 후보

후보	처리 위치	고려할 점
Porcupine	브라우저(WASM)	웹용 SDK를 제공합니다. 커스텀 호출어와 사용 조건은 제공사 약관을 확인해야 합니다
openWakeWord	서버가 기본, 브라우저 이식도 있음	오픈소스이고 호출어를 직접 학습시킬 수 있습니다
Web Speech API	브라우저	가장 간단합니다. 크롬에서는 음성이 외부 서버로 가는 구조입니다

마지막 후보가 특히 걸립니다. 호출어를 기다리는 동안의 음성까지 밖으로 나가기 때문입니다.

호출어 이전의 음성을 남기지 않는 구조

상시 마이크 서비스의 신뢰는 이 한 가지에서 갈립니다. 호출어 감지는 기기 안에서 끝내고, 감지된 뒤의 짧은 구간만 서버로 보냅니다. 그 이전의 소리는 메모리의 짧은 링 버퍼에만 있다가 덮어씌워집니다.

지금 듣는 중인지, 호출어를 잡아서 녹음 중인지도 화면에 보여야 합니다.

호출어는 서비스 이름으로

"시리야"는 실제 Siri와 겹쳐서 주변 기기까지 깨울 수 있습니다. 음절이 길고 일상 대화에서 잘 나오지 않는 단어가 오탐이 적습니다. 저라면 서비스 이름을 부르는 형태로 정하겠습니다.

명령 이후는 텍스트 입력과 같은 길

호출어 뒤의 음성은 Whisper 계열 모델로 텍스트로 바꿉니다. 이 모델을 운영하는 서버에서 돌리면 음성이 제3자에게 나가지 않습니다. 이후는 텍스트 입력과 같습니다. 의도를 해석하고, 도구를 호출하고, 응답을 화면이나 음성으로 돌려줍니다.

이 구간의 지연은 직접 재 보기 전에는 말할 수 없어서 이 글에서는 수치를 적지 않았습니다.