온디바이스 음성인식과 클라우드, 언제 무엇을 써야 하나?
네트워크 지연을 감당할 수 없거나, 음성 데이터가 기기 밖으로 나가면 안 되거나, 대당 통신 비용이 누적되는 제품이라면 온디바이스가 답입니다. 온디바이스 음성 처리란 무엇인가 온디바이스 음성 처리는 전처리·음성인식·이해·응답 중 일부 또는 전부를 제품 안에서 실행하는 방식입니다. 전처리는 잡음·반향·간섭을 줄이고, 인식은 신호를 텍스트로 바꾸며, 이해·응답

네트워크 지연을 감당할 수 없거나, 음성 데이터가 기기 밖으로 나가면 안 되거나, 대당 통신 비용이 누적되는 제품이라면 온디바이스가 답입니다.
온디바이스 음성 처리란 무엇인가
온디바이스 음성 처리는 전처리·음성인식·이해·응답 중 일부 또는 전부를 제품 안에서 실행하는 방식입니다. 전처리는 잡음·반향·간섭을 줄이고, 인식은 신호를 텍스트로 바꾸며, 이해·응답은 의도를 해석합니다. 세 단계는 같은 장소에서 실행할 필요가 없으므로, 전처리만 기기에서 수행하고 인식과 이해는 클라우드에 두는 하이브리드 구성이 가능합니다.
기기 전처리는 입력 품질 계층을 인식 엔진과 분리합니다. 따라서 인식 엔진을 유지하거나 교체하더라도, 마이크 배열과 음향 환경에 맞춘 전처리 계층을 독립적으로 검토할 수 있습니다. 다채널 환경의 전처리 범위와 구현 방식은 음성 전처리 기술에서 확인할 수 있습니다.

클라우드 API는 언제 더 나은가
클라우드 API는 대규모 어휘, 다국어, 잦은 모델 갱신, 짧은 초기 통합 기간이 우선일 때 더 나은 선택입니다. 상품명·신조어·법령처럼 인식 또는 이해 모델을 자주 바꿔야 하는 도메인에서는 서버 쪽 모델을 일괄 갱신하는 운영 방식이 유리합니다. 다국어 지원 범위가 넓고 제품별 사용 언어가 계속 늘어나는 경우에도 기기별 모델 용량과 배포 절차를 관리하는 부담을 줄일 수 있습니다.
반대로 클라우드의 장점은 안정적인 연결, 음성 전송·처리 경로, 데이터 처리 체계가 이미 갖춰졌을 때 가장 잘 작동합니다. 초기 통합에서는 API 연동으로 기능 검증을 빠르게 시작할 수 있지만, 양산 이후에는 네트워크 품질과 데이터 경로를 제품 요구사항에 맞춰 계속 관리해야 합니다. 선택 기준은 인식 방식의 우열이 아니라, 제품이 무엇을 자주 바꾸고 무엇을 통제해야 하는지입니다.
| 기준 | 온디바이스 | 클라우드 |
|---|---|---|
| 지연 | 기기 내부 처리 시간 중심 | 전송·서버 처리·응답 전송이 합산 |
| 네트워크 의존 | 기능에 따라 독립 운용 가능 | 연결 품질과 경로에 영향 |
| 데이터 위치 | 기기 유지 설계 가능 | 전송·처리·보관 경로 관리 필요 |
| 비용 구조 | 개발·포팅·검증에 집중 | 사용량과 통신에 따라 누적 |
| 어휘·갱신 | 메모리 제약과 배포 절차 고려 | 대규모 어휘·일괄 갱신에 유리 |
지연 시간은 얼마나 차이 나는가
온디바이스는 네트워크 구간이 없으므로 지연이 기기 처리 시간으로 수렴하고, 클라우드는 여기에 왕복 전송과 서버 처리가 더해집니다. 따라서 같은 음성 처리 단계라면 구조적으로 클라우드 경로의 지연 예산이 더 크며, 특히 제품은 평균 연결 상태가 아니라 최악 연결 상태에서 응답 요구를 충족하는지 확인해야 합니다. 클라우드 구간의 지연은 서비스·네트워크·지역에 따라 편차가 커서, 하나의 공통 수치로 제시하지 않습니다.
자연 대화 10개 언어 분석에서는 응답 전환의 최빈 구간이 0~200 ms, 전체 평균 오프셋이 208 ms였습니다. 이 값은 음성 시스템의 절대 목표가 아니라, 짧은 공백도 대화 경험에 영향을 줄 수 있음을 보여 주는 사람 간 대화의 기준선입니다. (출처: PNAS, 2009) [1]
| 지연 예산 구간 | 온디바이스 | 클라우드 |
|---|---|---|
| 기기 전처리 | 기기 처리 시간 | 기기 처리 시간 |
| 업링크 전송 | 없음 | 네트워크 상태에 따라 추가 |
| 서버 처리 | 없음 | 서비스 처리 시간이 추가 |
| 다운링크·응답 전달 | 없음 | 네트워크 상태에 따라 추가 |
| 설계 판단 | 기기 처리 시간에 수렴 | 전송·서버 처리까지 포함해 최악 조건 확인 |
RTF(실시간 처리인수)는 입력 음성 길이 대비 처리 시간입니다. mpAB의 RTF는 0.852이며, 85.17%로 표기하기도 합니다. 소수와 백분율은 같은 값의 두 표기입니다. mpAB의 0.852는 중기부 디딤돌 TTA 시험성적서에 기재된 값이고, ClearSense Audio v1.1.0의 0.33562는 TTA-25-1103 동일 시험(2025-06-09~12)에서 확인한 값입니다. 두 값 모두 공인시험기관이 측정했습니다. RTF는 네트워크·인식·응답을 합친 체감 지연이 아니므로, 지연 예산의 한 항목으로만 사용해야 합니다.
| 측정 또는 기준 | 값 | 조건·출처 |
|---|---|---|
| 자연 대화 응답 전환 최빈 구간 | 0~200 ms | 10개 언어 자연 대화 분석, PNAS, 2009 [1] |
| 자연 대화 응답 전환 평균 오프셋 | 208 ms | 10개 언어 자연 대화 분석, PNAS, 2009 [1] |
| mpAB 실시간 처리인수 | 0.852 | 중기부 디딤돌 TTA 시험성적서 |
| ClearSense Audio v1.1.0 실시간 처리인수 | 0.33562 | TTA-25-1103 동일 시험, 2025-06-09~12 |
데이터가 기기 밖으로 나가면 무엇이 문제인가
음성의 외부 전송은 데이터 분류, 처리 경로, 고지의 문제입니다. 개인정보 포털은 음성을 신체적 정보의 예시로 들며, 개인정보 해당 여부는 구체적 상황과 맥락에 따라 판단해야 한다고 안내합니다. 가정·의료·차량 실내처럼 발화 내용과 주변 소리가 함께 수집될 수 있는 제품은 전송 전후의 경로를 설계 단계에서 확인해야 합니다. (출처: 개인정보 포털, 확인일 2026-08-20) [2]
국외에서 제공·조회·처리위탁·보관하는 구조는 개인정보 보호법의 국외 이전 요건과 보호조치를 검토해야 할 수 있습니다. EU 시장에서 음성 특징을 고유 식별에 쓰는 경우에는 GDPR의 생체정보 및 특별범주 데이터 요건도 별도로 검토해야 합니다. 온디바이스 처리는 이 검토를 자동으로 면제하지 않지만, 원음의 외부 전송 자체를 줄이는 설계 선택지가 됩니다. (출처: 국가법령정보센터, 2026; EUR-Lex, 2016) [3] [4]
비용은 언제 역전되는가
비용은 출하 대수와 사용량을 함께 놓고 판단합니다. 클라우드에서는 월간 발화 건수, 건당 처리 시간, 통신 모듈과 데이터 연결, 장애 대응, 특정 서비스에 대한 의존도를 계산 항목으로 둬야 합니다. 온디바이스에서는 모델 경량화, 포팅 공수, 검증 시험, 인증, 펌웨어 배포 체계를 계산 항목으로 둬야 합니다.
클라우드는 음성 처리와 연결에 따른 운영 비용이 출하 후에도 누적되고, 온디바이스는 개발·검증 단계에 비용이 먼저 집중됩니다. 그러므로 손익 판단은 하나의 값으로 끝나지 않습니다. 출하 계획, 월간 발화량, 연결 조건, 유지보수 체계를 분리해 민감도를 비교해야 합니다.

어느 정도 사양이면 온디바이스가 가능한가
온디바이스 실행 가능 여부는 NPU 유무만으로 판단할 수 없고, 모델·메모리·실시간 요구사항을 함께 봐야 합니다. Arm은 Cortex-M용 CMSIS-NN이 신경망 커널의 성능과 메모리 사용량을 최적화하도록 설계됐다고 설명하고, 간단한 실시간 키워드 스폿팅은 Cortex-M3에서도 가능하다고 안내합니다. NPU는 선택지이지만 모든 음성 처리의 필수 조건은 아닙니다. (출처: Arm, 2026) [5]
mpAB 전처리는 자사 측정 기준 64 MHz 동작주파수와 SRAM 0.571 MB를 사용합니다. 543,620 bytes(약 543 KB)는 중기부 디딤돌 TTA 시험성적서에 기재된 mpAB 바이너리 크기입니다. 이 값은 전처리 실행 사양이지 온디바이스 음성인식 전체의 요구량을 뜻하지 않습니다. 제공 형태는 소프트웨어 라이브러리, 다채널 오디오 입출력 전처리 모듈, DSP·FPGA·AP 포팅, 기술 라이선스로 구성됩니다.
| 항목 | 값 | 조건·출처 |
|---|---|---|
| 동작주파수 | 64 MHz | 자사 측정 |
| SRAM 요구량 | 0.571 MB | 자사 측정 |
| 바이너리 크기 | 543,620 bytes | 중기부 디딤돌 TTA 시험성적서; mpAB |
| 실시간 처리인수 | 0.852 | 중기부 디딤돌 TTA 시험성적서 |
| 소음 저감량 | 42.088 dB | 중기부 디딤돌 TTA 시험성적서; mpAB (목표 40 dB 이상) |
둘을 함께 쓸 수는 없는가
전처리는 기기에서 수행하고, 인식과 이해는 연결 상태·데이터 정책·기능 요구에 따라 나누는 하이브리드 구성이 현실적인 답입니다. mpWAV 전처리는 언어에 따른 수정이 필요 없고, 2~8개 마이크는 개수와 배치가 바뀌어도 재튜닝 없이 적용할 수 있습니다. 로보케어(ROBOCARE)의 AI 돌봄 로봇 ‘케미프렌즈(Cami-friends)’에는 다채널 오디오 입출력 모듈을 공급했고, ETRI(한국전자통신연구원)와는 휴머노이드 로봇 원거리 음성인식 공동연구를 수행했습니다. 상세는 고객 사례에서 확인할 수 있습니다.
결론은 둘 중 하나를 고르는 문제가 아니라 어느 단계를 어디에 둘지 정하는 문제입니다. 네트워크 불확실성, 데이터 경로, 출하량을 먼저 고정한 뒤 전처리·인식·이해의 배치를 결정해야 합니다.
자주 묻는 질문
온디바이스로 돌리려면 NPU가 필요한가요?
아니요. NPU는 추론 효율을 높이는 선택지일 뿐 필수 조건은 아닙니다. mpAB 전처리의 자사 측정 기준은 64 MHz와 SRAM 0.571 MB이고, 543,620 bytes(약 543 KB) 바이너리는 중기부 디딤돌 TTA 시험성적서에 기재된 mpAB 바이너리 크기입니다.
기존 클라우드 엔진을 쓰면서 전처리만 기기에서 할 수 있나요?
네. 전처리는 인식 엔진과 분리된 입력 품질 계층으로 둘 수 있습니다. 기기에서 잡음·반향을 처리한 뒤 기존 클라우드 인식 엔진으로 보낼 수 있습니다.
온디바이스는 인식률이 떨어지지 않나요?
인식 품질은 처리 위치 하나로 결정되지 않습니다. 전처리가 잡음·반향·간섭을 줄이면 기기 또는 클라우드 인식 엔진 모두에 유리한 입력 조건을 만들 수 있습니다. 최종 평가는 실제 마이크 구성과 소음 환경에서 해야 합니다.
참고자료
- [1] Stivers et al., 「Universals and cultural variation in turn-taking in conversation」, PNAS, 2009
- [2] 개인정보 포털, 「개인정보의 종류」
- [3] 국가법령정보센터, 「개인정보 보호법」 제28조의8
- [4] EUR-Lex, Regulation (EU) 2016/679 (General Data Protection Regulation)
- [5] Arm, 「CMSIS-NN Software Library」 및 「ML software development for Arm Cortex-M processors」