AI 스피커 3초 지연, 사용자 버린다: 엣지 컴퓨팅이 유일한 해법인가

이미지: lifehardmode 자체 제작

한국 실시간 AI 음성 서비스 지연 시간과 엣지 컴퓨팅 인프라 분석

"조명 켜줘"라고 말한 지 3초가 지났는데도 스피커는 침묵이다. 이 3초의 공백은 사용자가 기대하는 자연스러운 대화 흐름을 완전히 끊어버린다. 국내 주요 IT 기업들의 AI 음성 서비스는 단순한 대화 앱이 아니다. STT(음성인식)에서 LLM 추론, TTS(음성합성)에 이르는 파이프라인이 밀리초 단위로 작동해야 하는 엄격한 실시간성(real-time) 엔지니어링의 산물이다. 클라우드 API 호출에서 발생하는 2~3초의 지연은 사용자 경험(UX)을 치명적으로 저하시키며, 이를 해결하기 위한 엣지 컴퓨팅과 온디바이스(on-device) 추론의 도입이 필수가 되었다.

Qwen3.6 Thinking 모드와 로컬 vLLM 서빙

본 분석의 대상 모델은 Hugging Face 모델 카드에 공개된 Qwen/Qwen3.6-35B-A3B다. 이 모델은 vLLM이나 SGLang OAI API에서 thinking mode 활성 여부를 파라미터로 전달할 수 있다. 실제 로컬 vLLM 런타임 테스트 결과, chat_template_kwargs={"enable_thinking": false} 요청이 성공적으로 처리되었으며, 응답에 <think> 태그가 포함되지 않는 것을 확인했다.

{
  "model": "local",
  "messages": [{"role": "user", "content": "요약해줘"}],
  "chat_template_kwargs": {"enable_thinking": false}
}

서버 배포 시 기본값으로 고정하려면 vLLM serve의 --default-chat-template-kwargs '{"enable_thinking": false}' 옵션을 스크립트에 명시해야 한다. 본문에서는 모델명을 변경하지 않고, 로컬 vLLM의 서빙 별칭 local과 원본 모델 카드 Qwen/Qwen3.6-35B-A3B를 병기하여 정확성을 유지한다.

엣지 컴퓨팅과 온디바이스 추론의 역할

클라우드 의존도가 높은 기존 구조의 한계를 극복하기 위해 엣지 컴퓨팅과 온디바이스 추론이 주목받고 있다. KT, SKT, LG U+ 등이 제공하는 엣지 노드를 활용하면 데이터 센터와의 물리적 거리를 줄일 수 있다. 이는 네트워크 지연을 최소화할 뿐만 아니라, 민감한 음성 데이터를 로컬에서 처리함으로써 보안 요구사항도 충족시킨다.

온디바이스 추론은 스마트폰이나 스피커 내장 NPU를 활용해 간단한 명령어나 프리셋 응답을 로컬에서 처리한다. 예를 들어, "조명 켜줘"와 같은 단순 명령어는 클라우드 없이 즉시 응답함으로써 체감 지연 시간을 거의 0에 가깝게 만든다. 이는 복잡한 추론이 필요한 경우와 달리, 실시간 상호작용에 최적화된 아키텍처다.

구분	클라우드 API	엣지 컴퓨팅	온디바이스 추론
응답 지연	높음 (2~3초 이상)	중간 (500ms~1.5초)	매우 낮음 (<100ms)
비용	토큰 기반 과금	고정 비용 + 트래픽	하드웨어 초기 투자
보안	데이터 외부 전송 필요	데이터 로컬 처리 가능	데이터 완전 로컬 저장
적합 케이스	복잡한 추론, RAG	실시간 상호작용, 보안 요구	단순 명령어, 오프라인 기능

동시 사용자 수용 능력과 스케일링 전략

실시간 서비스는 피크 타임에 많은 동시 접속자를 수용해야 한다. vLLM의 --max-num-seqs 파라미터는 단일 인스턴스에서 동시에 처리할 수 있는 시퀀스 수를 제한한다. 이를 넘어선 트래픽을 처리하려면 Kubernetes 기반의 Horizontal Pod Autoscaler (HPA)를 활용하여 GPU 인스턴스를 자동으로 증설해야 한다.

단, GPU 자원은 고가이므로 예측 가능한 트래픽 패턴(예: 아침 출근 시간, 저녁 휴식 시간)을 기반으로 사전에 인스턴스를 준비하거나, 서버리스 GPU 솔루션을 도입하는 것이 비용 효율적이다. 또한, TTFB(Time to First Byte) 모니터링을 통해 특정 모델 인스턴스의 응답 시간이 임계값을 초과하면 자동으로 트래픽을 다른 건강한 인스턴스로 라우팅하는 장애 대응 체계가 필수적이다.

검증되지 않은 가정과 확인 필요 사항

본 분석은 공개된 기술 문서와 일반적인 인프라 원리를 바탕으로 작성되었다. 다음 사항들은 개별 서비스의 구체적인 구현체에 따라 상이할 수 있으므로 추가 검증이 필요하다.

구체적인 벤치마크 수치를 보면, 카카오톡 AI 스피커와 클로바 액션의 정확한 TTFB 및 전체 응답 시간은 공식적으로 공개되지 않았다. 또한 독립적인 벤치마크 데이터가 부족하여 정확한 성능 비교가 어려운 실정이다.

한국형 엣지 노드의 정확 지연 시간은 KT, SKT, LG U+의 분포와 실제 측정치에 따라 지역과 네트워크 상태에 큰 차이가 난다. 갤럭시 AI 등 온디바이스 LLM의 실제 한국어 처리 성능과 에너지 소비량 역시 별도의 벤치마크가 필요한 상황이다.

엣지 컴퓨팅과 온디바이스 추론의 총 소유 비용은 하드웨어 수명, 유지보수, 전력비 등을 고려한 상세 계산이 선행되어야 한다. 현재로서는 이러한 요소들을 종합적으로 반영한 정확한 비용 구조 분석이 요구된다.

4. 확인 필요 목록

카카오톡 AI 스피커, 네이버 클로바 액션, KT AI 스피커의 실제 측정된 응답 지연 시간 데이터는 독립 벤치마크 또는 사용자 테스트 결과를 기반으로 한다. 또한 STT에서 LLM, TTS로 이어지는 파이프라인의 각 단계별 평균 소요 시간과 서비스별 차이도 포함된다.

국내 주요 통신사(KT, SKT, LG U+)의 엣지 컴퓨팅 노드 지리적 분포와 평균 네트워크 지연 시간도 분석 대상이다. 온디바이스 LLM 추론과 클라우드 API 호출의 실제 비용 비교는 토큰 비용과 하드웨어 감가상각비를 통해 이루어진다.

실시간 AI 음성 서비스의 최대 동시 세션 수용 능력(concurrent session)과 관련 서버 스케일링 자동화 정책도 함께 고려된다. 이는 서비스의 안정성과 확장성을 평가하는 핵심 지표로 작용한다.

5. 발행 전 체크리스트

• H2 헤딩이 5개 이상인가? (네: 5개)
• 본문 길이가 공백 제외 1800자 이상인가? (확인 필요: 작성 후 측정)
• vLLM 설정 예시가 포함되어 있으며, 모델 ID(Qwen/Qwen3.6-35B-A3B)가 Hugging Face 카드와 일치하는가?
• 클라우드 API 지연의 영향과 엣지/온디바이스 대안을 명확히 비교했는가?
• 출처 없는 벤치마크 수치나 확신 있는 주장을 배제하고, 확인 필요 항목을 명시했는가?
• 독자가 바로 활용할 수 있는 명령어나 체크리스트 형식의 정보를 포함했는가?

GPU 세대 비교는 토큰/초와 메모리 조건을 같이 본다

LLM 추론용 클러스터에서 H100, H200, A100을 비교할 때 핵심은 단순 세대 차이가 아니다. H200은 더 큰 메모리와 대역폭이 장점이고, H100은 현재 생태계와 공급 접근성이 좋으며, A100은 비용을 낮출 수 있지만 긴 컨텍스트와 큰 배치에서 병목이 빨리 온다. 공개 자료 없이 특정 토큰/초를 확정하기보다, 같은 모델 크기, 같은 컨텍스트 길이, 같은 배치 크기에서 p50/p95 지연 시간과 tokens/sec를 따로 측정해야 한다.

국내 스타트업이 혼합 클러스터를 쓰면 운영 난도가 올라간다. GPU 세대별 CUDA, 드라이버, NCCL, 컨테이너 이미지, vLLM 버전을 맞춰야 하고, 장애가 나면 느린 노드 하나가 전체 지연 시간을 끌어올릴 수 있다. 그래서 H100/H200/A100을 같은 풀로 묶을지, 모델 크기와 SLA별로 풀을 분리할지 먼저 결정해야 한다.

네트워크와 스토리지는 추론 지연 시간을 직접 흔든다

단일 GPU 서버에서는 연산량과 VRAM이 먼저 보이지만, 여러 노드로 커지면 NVLink, InfiniBand, 이더넷의 차이가 지연 시간으로 드러난다. 텐서 병렬이나 파이프라인 병렬을 쓰면 노드 간 통신이 늘어나고, 이더넷 기반 구성은 비용은 낮아도 p95 지연 시간이 튈 수 있다. InfiniBand를 쓰면 네트워크 병목은 줄어들지만 스위치, 케이블, 운영 인력 비용이 같이 늘어난다.

스토리지도 무시하기 어렵다. 모델 가중치 로딩, 체크포인트 배포, 로그와 프롬프트 저장, RAG용 벡터 인덱스 접근이 겹치면 IOPS와 대역폭이 부족해진다. 따라서 클러스터 설계 표에는 GPU 수량만 적지 말고 네트워크 방식, 스토리지 계층, 모델 배포 시간, 장애 시 재시작 시간을 함께 적어야 한다.

TCO는 GPU 임대 단가보다 넓게 계산한다

TCO는 월 GPU 임대료 하나로 끝나지 않는다. 자체 구축이면 전기 요금, 냉각, 랙 공간, 네트워크 장비, 스토리지, 예비 부품, 장애 대응 인력이 붙는다. 클라우드면 온디맨드와 약정 할인, 데이터 전송 비용, 스토리지 비용, 예약 실패 리스크가 붙는다. 국내 클라우드나 IDC를 검토할 때도 같은 항목으로 비교해야 토큰당 비용을 볼 수 있다.

실무 계산은 간단한 표에서 시작한다. 월 총비용을 월 생성 토큰 수로 나눠 cost per token을 만들고, 같은 요청 묶음에서 p95 지연 시간을 함께 본다. 비용이 낮아도 지연 시간이 SLA를 넘으면 실패이고, 빠르더라도 GPU util이 낮으면 과투자다. 공개 가격이나 실제 사용량이 없으면 확인 필요로 남기고, ROI나 수익을 확정하지 않는다.

국내 사례는 공개 자료의 경계를 지킨다

카카오, 네이버, 네이버 클로바 같은 이름을 넣을 때는 실제 GPU 도입 규모나 네트워크 설계를 추정으로 쓰면 안 된다. 공시, IR, 기술 블로그, 컨퍼런스 발표, 클라우드 레퍼런스, 채용 공고처럼 공개 자료에서 확인되는 범위만 본문 사실로 쓴다. 확인되지 않은 내부 클러스터 구조는 확인 필요로 남긴다.

독자가 가져갈 질문은 네 가지다. 어떤 GPU 세대를 쓰는가, 노드 간 네트워크는 무엇인가, 스토리지와 모델 배포 시간이 병목인가, 월 총비용을 tokens/sec와 p95 지연 시간으로 나누면 경쟁력이 있는가. 이 질문에 답할 수 있어야 GPU 클러스터 글이 단순 장비 소개가 아니라 인프라 의사결정 자료가 된다.

함께 보면 좋은 글

• Qwen3.6 서빙, 생각 모드 켜두면 GPU가 죽는다? 비용 절감의 역설