통화가 클라우드를 안 거치게: 온디바이스·엣지 S2S와 프라이버시

우리는 음성 AI를 이야기할 때 거의 자동으로 클라우드를 떠올립니다. 사용자의 말소리가 서버로 올라가고, 거대한 모델이 그 음성을 듣고 답을 만들어 다시 내려보내는 그림입니다. 그런데 음성은 우리가 다루는 데이터 중에서도 가장 민감한 축에 속합니다. 목소리에는 말의 내용뿐 아니라 누구인지, 어떤 상태인지까지 담깁니다. 그렇다면 모든 통화를 굳이 클라우드까지 보내야만 할까요. 이번 글에서는 실시간 음성 대 음성(Speech-to-Speech, 이하 S2S) 모델을 기기 안이나 가까운 엣지에서 돌리는 선택지를 정리합니다. 클라우드로 보낸 뒤 어떻게 보호할지(암호화·마스킹)는 다른 편의 주제이고, 여기서는 아예 클라우드를 거치지 않는 쪽의 이야기를 합니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 6-5편

← 이전: 6-4 SIP·PSTN 전화망 연동 / 다음 → 7-1 음성 결제와 멀티모달의 한계

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

왜 엣지인가: 지연·프라이버시·비용·오프라인

엣지(edge)는 데이터가 발생하는 곳에 가까운 위치, 즉 사용자의 단말이나 통신 경로 앞단을 가리킵니다. 음성 처리를 이 위치로 끌어오면 네 가지 이점이 생깁니다.

첫째는 지연입니다. 음성을 서버로 올렸다가 다시 받아오는 네트워크 왕복이 사라지면, 그만큼 응답이 빨라집니다. 실시간 대화에서는 이 짧은 시간이 자연스러움을 좌우합니다. 둘째는 프라이버시입니다. 원본 음성이 기기를 떠나지 않으면, 전송 중 노출이나 서버 보관에서 생기는 위험 자체가 줄어듭니다. 셋째는 비용입니다. 음성을 매번 클라우드 모델로 보내 처리하면 호출이 쌓일수록 부담이 커지는데, 일부를 기기에서 처리하면 그만큼 외부 호출을 아낄 수 있습니다. 넷째는 오프라인 동작입니다. 네트워크가 불안정하거나 끊긴 환경에서도 기본 기능이 멈추지 않습니다.

다만 이 이점들은 공짜가 아닙니다. 그 대가가 무엇인지부터 보겠습니다.

온디바이스 음성 AI의 제약: 모델 크기·연산·발열

온디바이스(on-device)로 음성 AI를 돌린다는 것은, 클라우드의 넉넉한 자원 대신 손안의 한정된 자원으로 같은 일을 한다는 뜻입니다. 여기에는 분명한 한계가 있습니다.

가장 먼저 부딪히는 것은 모델 크기입니다. 대형 음성 모델은 메모리를 많이 요구하는데, 모바일이나 임베디드 기기의 메모리는 제한적입니다. 그래서 가중치의 정밀도를 낮추는 양자화(quantization), 더 작은 모델로 지식을 옮기는 증류, 불필요한 연결을 걷어내는 가지치기 같은 경량화 기법이 동원됩니다. 다음은 연산입니다. 실시간 음성은 끊임없이 들어오는 신호를 지연 없이 처리해야 하므로 한정된 연산 자원에 부담이 됩니다. 마지막은 전력과 발열입니다. 작은 기기에서 모델을 계속 돌리면 배터리가 빨리 닳고 기기가 뜨거워지며, 그러면 성능이 스스로 낮아지기도 합니다.

핵심은 이 모든 절약이 품질과 맞바꿔진다는 점입니다. 모델을 줄이면 인식이나 생성의 정확도가 떨어질 수 있고, 대형 클라우드 모델이 보여주는 수준에는 못 미치는 경우가 많습니다. 그래서 현실적인 답은 둘 중 하나를 고르는 것이 아니라, 둘을 섞는 데 있습니다.

온디바이스로 음성 기능을 붙이기로 결정하는 순간을 떠올려보면, 그 시작은 대개 화려한 아키텍처 고민이 아니라 사소한 질문 하나입니다. "이 기기는 네트워크가 끊겨도 최소한의 응답을 해야 하는가." 이 질문에 그렇다고 답하는 순간부터 모델 크기·양자화·발열 같은 제약들이 갑자기 현실적인 무게로 다가옵니다. 여러 프로젝트에서 반복되는 패턴은, 처음엔 온디바이스와 클라우드 중 하나를 고르는 문제로 접근했다가 결국 두 자원을 상황별로 나눠 쓰는 하이브리드 설계로 수렴한다는 점입니다.

하이브리드 구조: 엣지와 클라우드의 역할 분담

하이브리드는 가벼운 일은 엣지가, 무거운 일은 클라우드가 맡는 구조입니다. 음성 처리는 여러 단계로 나뉘는데, 단계마다 요구되는 능력이 다릅니다. 호출어를 감지하는 웨이크워드, 말이 시작되고 끝나는 지점을 잡는 음성 활동 감지(VAD), 간단한 명령어 인식 정도는 가벼우므로 엣지에 두기 좋습니다. 반대로 긴 맥락을 이해하고 복잡한 답을 생성하는 작업은 클라우드의 큰 모델이 유리합니다.

문제는 "이 발화를 엣지에서 끝낼까, 클라우드로 넘길까"를 매번 판단하는 일입니다. 보통 두 가지 축으로 결정합니다. 하나는 민감도입니다. 개인정보가 짙은 발화일수록 기기 밖으로 내보내지 않는 편이 안전합니다. 다른 하나는 연산량입니다. 단순한 요청이면 엣지에서 끝내고, 복잡하면 클라우드로 보냅니다.

입력_발화 = 마이크에서 받은 음성 구간

민감도 = 추정(개인정보 포함 여부, 도메인)
복잡도 = 추정(요청 길이, 추론 난이도)

if 네트워크_불가:
    엣지에서 처리   # 오프라인 폴백
elif 민감도 == "높음":
    엣지에서 처리   # 원본은 기기 밖으로 내보내지 않음
elif 복잡도 == "낮음":
    엣지에서 처리   # 왕복 비용 절약
else:
    엣지에서 텍스트/임베딩으로 변환 후 클라우드로 전달
    클라우드 응답을 받아 엣지에서 음성으로 출력

이 분기는 고정된 규칙이라기보다, 상황에 따라 조정하는 정책에 가깝습니다. 민감도와 복잡도를 어떻게 추정하느냐가 설계의 품질을 가릅니다.

프라이버시 설계: 원본 음성을 서버로 보내지 않기

프라이버시 관점에서 가장 중요한 원칙은 단순합니다. 원본 파형, 즉 사용자의 실제 목소리를 가능한 한 기기 밖으로 내보내지 않는 것입니다. 클라우드의 도움이 필요하더라도, 음성 그대로가 아니라 한 단계 가공한 형태로 보내는 설계가 가능합니다.

대표적인 방법은 엣지에서 먼저 변환하는 것입니다. 기기 안에서 음성을 텍스트로 옮기거나, 모델이 이해할 수 있는 임베딩 형태로 바꾼 뒤 그 결과만 전송합니다. 이렇게 하면 목소리 자체는 떠나지 않습니다. 여기에 더해, 텍스트 안의 전화번호나 주민등록번호 같은 식별 정보를 엣지에서 미리 가립니다. 처리에 꼭 필요한 만큼만 보내고, 끝나면 남기지 않는 것이 기본입니다.

데이터 형태	전송 위험	비고
원본 음성 파형	가장 높음	화자 식별·감정까지 노출
텍스트 변환본	중간	식별 정보 마스킹 필요
임베딩/특징	상대적으로 낮음	복원 가능성은 별도 검토

다만 임베딩이 안전하다고 단정해서는 안 됩니다. 변환된 표현에서도 원래 정보를 일부 되살릴 여지가 있을 수 있으므로, "원본만 아니면 괜찮다"가 아니라 각 형태의 위험을 따로 평가하는 태도가 필요합니다.

규제(개인정보)와 데이터 주권

음성은 개인정보입니다. 그래서 보이스봇을 다룰 때는 기술적 효율만큼이나 제도적 요구를 함께 보아야 합니다. 일반적으로 강조되는 원칙은 수집 최소화입니다. 꼭 필요한 데이터만, 필요한 동안만 다루라는 것입니다. 온디바이스 처리는 이 원칙과 잘 맞습니다. 원본을 서버에 쌓지 않으니, 보관과 폐기를 둘러싼 부담이 애초에 줄어듭니다.

또 하나는 데이터 주권입니다. 데이터가 어느 위치에서 처리되고 어디에 보관되는지를 통제하려는 요구로, 특정 지역 밖으로 데이터가 나가지 않게 하려는 경우가 여기에 해당합니다. 처리를 엣지나 한정된 권역 안에 묶어 두면 이런 요구에 답하기 쉬워집니다. 구체적인 법적 기준은 지역과 산업에 따라 다르므로, 실제 적용은 해당 환경의 규정을 직접 확인해야 합니다. 다만 방향만 놓고 보면, 처리 위치를 사용자 가까이 둘수록 통제권은 강해집니다.

트레이드오프와 선택 기준

지금까지의 이야기는 결국 하나의 질문으로 모입니다. 이 음성 기능을 어디에서 돌릴 것인가. 정답은 한 곳이 아니라, 요구사항에 따라 달라집니다.

기준	클라우드	온디바이스	하이브리드
모델 품질	가장 높음	제한적	작업별로 선택
지연	네트워크 의존	낮음	작업별로 다름
프라이버시	보호책 필요	가장 유리	설계로 조절
오프라인	불가	가능	부분 가능
단말 부담	낮음	높음(발열)	중간

선택 기준은 이렇게 정리할 수 있습니다. 응답이 아주 빨라야 하거나, 네트워크가 불안정하거나, 다루는 음성이 민감하다면 엣지 쪽으로 무게를 둡니다. 반대로 복잡한 이해와 생성 품질이 핵심이고 단말 부담을 피하고 싶다면 클라우드가 맞습니다. 대부분의 현실적인 서비스는 그 사이에서 둘을 나눠 쓰는 하이브리드로 수렴합니다. 중요한 것은 "무조건 클라우드"라는 기본값을 의심해 보는 일입니다. 클라우드 말고도 선택지가 있다는 사실 자체가, 더 나은 설계로 가는 첫걸음입니다.

엣지 S2S의 진짜 가치는 연결 품질이 아니라 개인정보 신뢰에 달려 있습니다. 아무리 빠른 응답도, 원본 목소리가 어디에 저장되는지 모른다면 사용자에게 온전히 받아들여지지 않습니다. 기기 밖으로 내보내지 않는다는 사실 자체가, 어떤 암호화 정책보다 직관적인 신뢰의 근거가 됩니다. 엣지 배포의 제약이 아직 크다고 하더라도, 그 방향을 선택하는 이유가 여기에 있습니다.

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링