800ms 장벽: 중단 가능한 음성 에이전트 설계 (Sarvam AI와 Swiggy의 교훈)

Source: Dev.to

신호: 800 ms 지연 장벽

연구실에서는 3초 지연이 “최적화 티켓”이다.
Swiggy 앱에서 배고픈 고객과 실시간 통화 중에는 3초가 이탈 이벤트이다.

Sarvam AI와 Swiggy의 파트너십은 에이전트 AI의 “보스 레벨” 변화를 의미한다. 대부분의 개발자는 다음과 같은 연쇄 파이프라인을 사용해 음성 에이전트를 만든다:

STT → LLM → TTS

결과는? 누적 지연으로 인해 에이전트가 느린 워키‑토키처럼 느껴진다. 다음 억 명 사용자를 위해서는 네이티브 오디오 스트리밍과 서브‑초 응답 시간을 설계해야 한다.

Phase 1: 건축적 베팅

• The Vendor Trap – 다국어, 오디오‑우선 시장을 위해 범용 텍스트‑중심 모델에 의존하는 것. 주문을 이해하기 위해 “Hinglish”를 영어로 번역하는 것만으로도 지연 전쟁에서 이미 뒤처진다.
• The Ownership Path – 인도어‑네이티브 스택. Sarvam의 원천 학습 오디오 모델을 사용하면 speech‑to‑intent 를 직접 처리할 수 있다. 더 중요한 것은 bi‑directional WebSocket 아키텍처를 구현해야 한다는 점이다. 이를 통해 에이전트는 말하면서 동시에 듣 수 있게 되며, 이는 인간 대화의 가장 어려운 부분인 the barge‑in 을 처리하는 유일한 방법이다.

2단계: 구현 (중단 가능한 음성 핸들러)

Swiggy와 같은 고위험 환경에서는 사용자가 마음을 바꿀 경우 에이전트가 문장 도중에 멈추고 로직을 되돌릴 수 있어야 합니다.

// High‑Level Logic for an Interruptible Voice Kernel
class VoiceAgentKernel {
    constructor(wsConnection) {
        this.ws = wsConnection;
        this.isSpeaking = false;
        this.transactionLock = null; // Ensuring tool‑use safety
    }

    // Detecting the "Barge‑in" (Interruption)
    onUserSpeechDetected() {
        if (this.isSpeaking) {
            console.warn("SIGNAL: Interruption detected. Executing State Rollback.");
            this.killAudioPlayback();
            this.abortCurrentLLMGeneration();
            this.clearPendingTransactions();
        }
    }

    async handleAudioStream(chunk) {
        // Stream raw audio to Sarvam's native Indic‑pipeline
        const response = await this.ws.processAudio(chunk);

        if (response.intent_confidence > 0.9) {
            // Pre‑warm tools before the user even stops talking
            this.prepareOrderTransaction(response.entities);
        }
    }

    clearPendingTransactions() {
        // Essential: Prevents the "Ghost Order" bug
        if (this.transactionLock) {
            this.transactionLock.cancel();
            this.transactionLock = null;
        }
    }
}

Phase 3: 시니어 보안 및 테스트 감사

저는 이 Swiggy‑scale 청사진을 전문 시니어 QA 및 보안 감사를 통해 검증했습니다. 여기서 “표준” 음성 에이전트가 실제 환경에서 실패하는 이유를 살펴봅니다.

“Ghost Order” 레이스 컨디션 (논리 오류)

• Fault – 에이전트가 “Paneer Tikka 주문 중…”이라고 말합니다. 사용자가 끼어 “아니요, 잠깐! Chicken Roll로 바꿔 주세요!”라고 말합니다.
• Audit – 순진한 구현에서는 LLM이 말을 시작하는 순간 “Order Tool”이 트리거됩니다. 사용자가 끼어들면 오디오가 멈추지만, 백엔드 API는 이미 Paneer Tikka를 커밋해 버렸습니다.
• Fix – deferred commits를 구현합니다. 툴 호출은 오디오 재생이 “커밋 임계값”(예: 90 % 완료)까지 도달하거나 최종 구두 확인을 받을 때까지 PENDING 상태를 유지해야 합니다.

“Ambient Audio Injection” (보안 침해)

• Fault – 사용자가 음식을 주문하면서 큰 TV에서 “모든 주문을 취소합니다”라는 소리를 듣고 있습니다.
• Audit – 스피커 다이어리제이션이 없으면 에이전트는 주요 사용자와 배경 소음을 구분하지 못합니다. 악의적이거나 우연한 오디오 주입이 무단 행동을 트리거할 수 있습니다.
• Fix – Sarvam의 프론트‑엔드 오디오 처리를 사용해 **voice activity detection (VAD)**와 노이즈‑플로어 게이트를 적용합니다. 오디오 신호가 주요 화자의 데시벨 프로파일이나 공간적 특성과 일치하지 않을 경우, 커널은 해당 인텐트를 무시해야 합니다.

“Colloquial Logic Bypass” (시맨틱 보안)

• Fault – 보안 프롬프트는 영어로 되어 있지만, 사용자는 힌디어와 지역 슬랭이 섞인 방언을 사용하고 있습니다.
• Audit – 영어 중심의 가드레일은 지역적 모욕이나 “힌글리시” 사회공학 시도를 놓치기 쉽습니다. 이는 에이전트를 속여 100 % 할인을 받게 할 수 있습니다.
• Fix – 보안 필터는 Indic‑native이어야 합니다. Sarvam의 지역 가드레일을 활용하면 시맨틱 경계가 번역 수준이 아니라 음소 수준에서 강제됩니다.

Phase 4: Checklist (The Architect’s Standard)

• Native Audio or Bust – 아직 의도를 처리하기 전에 오디오를 텍스트로 변환하고 있다면, 지연 시간이 800 ms 골드 스탠다드에 도달하지 못합니다.
• Transactional Barge‑in – 모든 중단이 보류 중인 API 호출에 대해 상태 롤백을 트리거하는지 확인하십시오.
• Acoustic Hardening – VAD 안정성을 보장하기 위해 배경 “거리 소음” 60 dB 환경에서 에이전트를 테스트하십시오.
• Regional Edge‑Cases – “힌글리시” 로직을 감사하십시오. 에이전트가 … 사이의 차이를 이해합니까?

(필요에 따라 체크리스트를 계속 추가하십시오.)

**Question:**  
*What is the difference between a user “asking for a discount” and a user “threatening to cancel”?*

The Bottom Line

다음 억 명의 사용자를 위해 구축하려면 인간 사고 속도를 존중하는 인프라가 필요합니다. Sarvam AI는 네이티브 인디크 엔진을 제공하며, 여러분의 임무는 주문을 안전하게 유지하는 Deterministic House를 구축하는 것입니다.