실시간 AI 어시스턴트가 구현하기 어려운 이유 — 그리고 Wan-Streamer v0.1이 변화시키는 것

실시간 AI는 상상하기는 쉽지만 구축하기는 어렵습니다. 사용자가 말을 하면, 시스템이 잠시 생각한 뒤 적절한 단어와 동기화된 목소리 또는 아바타로 답변합니다. 실제로 이러한 경험은 대개 별개의 구성 요소들의 체인(chain)을 이어 붙여 만들어집니다: 음성 활동 감지 (Voice Activity Detection, VAD), 음성 인식 (Speech Recognition), 언어 모델 (Language Model, LM), 텍스트 음성 변환 (Text-to-Speech, TTS), 그리고 일종의 애니메이션 또는 비디오 렌더러 (Video Renderer) 등이 그것입니다. 모든 데이터 전달 단계는 지연 시간 (Latency)을 추가합니다. 모든 경계는 타이밍 오류가 스며들 수 있는 또 다른 지점을 만듭니다.

이것이 바로 Wan-Streamer v0.1이 흥미로운 이유입니다. Wan-Streamer 프로젝트 페이지는 다른 아이디어를 제시합니다: 오디오, 비디오, 텍스트를 별개의 서비스로 취급하는 대신, 하나의 스트리밍 트랜스포머 (Streaming Transformer)를 사용하여 이를 단일 상호작용 루프 (Interaction Loop)로 처리하는 것입니다. 다시 말해, 이 모델은 단순히 더 빠르게 응답하는 것이 아니라, 상호작용이 연속적이고, 인과적이며, 전이중 (Full-duplex) 방식이라는 가정하에 구축되었습니다.

진짜 문제: 파이프라인 (Pipelines)은 느리다

표준적인 멀티모달 (Multimodal) 어시스턴트는 흔히 다음과 같은 구조를 가집니다:

1. 사용자 오디오가 입력됩니다.
2. ASR (Automatic Speech Recognition)이 음성을 텍스트로 변환합니다.
3. 언어 모델 (Language Model)이 텍스트를 생성합니다.
4. TTS (Text-to-Speech)가 해당 텍스트를 다시 음성으로 바꿉니다.
5. 렌더러 (Renderer) 또는 아바타 시스템이 얼굴과 입 모양의 동기화를 유지하려고 시도합니다.

이 방식은 작동하지만, 취약합니다. 만약 ASR 단계가 늦어지면, 이후의 모든 단계가 대기하게 됩니다. 만약 TTS 시스템이 너무 일찍 또는 너무 늦게 시작하면, 아바타가 부자연스럽게 보일 수 있습니다. 만약 사용자가 말을 가로막으면(Interrupt), 시스템이 이를 충분히 빠르게 알아차리지 못할 수도 있습니다.

이것이 Wan-Streamer가 해결하고자 하는 설계 문제입니다. 이 모델은 데이터를 여러 하위 시스템 사이에서 주고받는 대신, 하나의 인과적 스트림 (Causal Stream) 내에서 인지하고 응답하도록 설계되었습니다.

모듈의 체인이 아닌, 하나의 트랜스포머 (Transformer)

핵심 아이디어는 말하기는 간단하지만 실행하기는 더 어렵습니다. 즉, 단일 트랜스포머 (Transformer) 내부에서 언어, 오디오, 비디오를 함께 모델링하는 것입니다. Hugging Face 논문 페이지는 이 접근 방식을 잘 요약하고 있습니다. 텍스트, 오디오, 비디오 토큰이 서로 교차(interleaved)되어 블록 인과적 어텐션 (block-causal attention)으로 처리되므로, 모델은 각 단계에서 내부 상태를 업데이트하면서도 유효한 스트리밍 이력을 유지할 수 있습니다.

이것이 왜 중요할까요? 모델이 행동하기 전에 전체 대화 차례(turn)가 끝날 때까지 기다리지 않기 때문입니다. 모델은 지속적으로 업데이트될 수 있습니다. 이는 인간이 실시간으로 상호작용하는 방식에 더 가깝습니다. 우리는 응답을 계획하는 동안 경청하며, 상대방이 말을 마치기 전에도 방해(interruption)에 반응할 수 있습니다.

프로젝트 페이지는 또한 유용한 시스템 아이디어인 사고자-수행자 (thinker–performer) 분리를 설명합니다. 사고자(thinker)는 인지, 상태 업데이트, 그리고 이전 유닛의 렌더링을 담당합니다. 수행자(performer)는 다음 유닛의 잠재 표현 (latent generation)을 담당합니다. 이러한 중첩은 매우 중요한데, 낮은 지연 시간 (low latency)은 단순히 하나의 모델을 더 빠르게 만드는 것만이 아니기 때문입니다. 스트리밍 루프의 서로 다른 부분들이 서로를 차단(blocking)하지 않도록 유지하는 것도 중요합니다.

모델이 스트림을 계속 움직이게 하는 방법

Wan-Streamer는 처음부터 인과성 (causality)을 중심으로 구축되었습니다. 이는 모든 새로운 정보가 시간 순서를 존중하는 방식으로 처리됨을 의미합니다. 시스템은 인과적 인코더 (causal encoders)와 디코더 (decoders)를 사용하며, 출력 측은 하나의 큰 배치 (batch)가 아닌 작은 스트리밍 유닛 단위로 생성됩니다.

가장 유용한 상위 수준의 멘탈 모델은 다음과 같습니다:

• 입력 스트림이 지속적으로 인코딩됨
• 모델이 상호작용 이력으로부터 공유 상태 (shared state)를 업데이트함
• 해당 상태로부터 다음 응답을 예측함
• 오디오와 비디오가 잠재 표현 (latent representations)으로부터 생성됨
• 생성된 출력이 다시 이력에 추가됨

이것이 중요한 이유는 전체 상호작용을 하나의 루프로 전환하기 때문입니다. 모델은 단순히 프롬프트에 답하는 것이 아니라, 관찰, 응답, 그리고 업데이트된 컨텍스트 (context)의 연속체 속에서 살아가는 것입니다.

arXiv 초록은 몇 가지 구체적인 세부 사항을 추가합니다. Wan-Streamer는 시각(visual), 오디오(audio), 텍스트 토큰(text tokens)이 교차된 형태를 사용하며, 점진적 스트리밍(incremental streaming)을 위한 블록 인과적 어텐션(block-causal attention), 그리고 약 160ms의 스트리밍 단위를 지원하는 저지연 스케줄링(low-latency scheduling)을 사용합니다. 프로젝트 페이지에 따르면, 이 시스템은 모델 측면의 지연 시간(model-side latency)은 약 200ms에 달하며, 네트워크 지연(network delay)을 포함한 전체 상호작용 지연 시간(total interaction latency)은 약 550ms에 이릅니다.

이것이 단순한 벤치마크 수치 그 이상인 이유

지연 시간(Latency) 수치는 허영 지표(vanity metrics)로 취급하기 쉽지만, 상호작용 시스템에서는 사용자 경험(user experience)을 직접적으로 형성합니다. 응답 시간이 1초 미만으로 떨어지면 대화는 실시간처럼 느껴지기 시작합니다. 시스템이 오디오와 비디오를 동기화(synchronized)할 수 있다면, 단순한 도구(gadget)라기보다 참여자(participant)처럼 행동할 수 있습니다.

이는 몇 가지 제품 카테고리에서 매우 중요합니다:

• 고객 지원 아바타 (Customer support avatars): 시선 맞춤과 얼굴 타이밍을 유지하면서 자연스럽게 응답해야 합니다.
• 튜터링 에이전트 (Tutoring agents): 어색한 일시 정지 없이 동일한 세션 내에서 듣고, 설명하고, 적응할 수 있어야 합니다.
• 텔레프레즌스 도구 (Telepresence tools): 에이전트의 음성, 입 모양 움직임, 장면 전환이 모두 동시에 전달되어야 합니다.
• 인터랙티브 데모 (Interactive demos): "작동한다"와 "반응성이 느껴진다" 사이의 차이가 주로 시스템 문제인 경우입니다.

그런 의미에서 Wan-Streamer는 챗봇이 말하게 만드는 것보다 인터페이스의 구조를 재고하는 것에 더 가깝습니다. 모델은 차례 지키기(turn-taking), 중단(interruption), 타이밍(timing)을 일급 시민(first-class) 동작으로서 인지해야 합니다.

주의해야 할 점

여전히 몇 가지 주의 사항이 있습니다.

첫째, 이것은 v0.1 시스템이며, 데모 품질은 분명히 여전히 발전 중입니다. 프로젝트 페이지는 192p 수준의 개념 증명(proof-of-concept)을 보여주는데, 이는 해상도와 완성도가 아키텍처(architecture)만으로 해결되는 것이 아님을 말해줍니다.

둘째, 공개된 지연 시간 비교 수치는 주의해서 읽어야 합니다. 어떤 시스템은 엔드 투 엔드(end-to-end)로 측정되는 반면, 다른 시스템은 렌더링 단계(rendering-stage)의 지연 시간만을 보고합니다. 이 둘은 같은 것이 아닙니다.

셋째, 단일 스트리밍 Transformer (streaming Transformer)가 안전성(safety), 견고성(robustness), 또는 장기적 일관성(long-horizon consistency)이라는 난제들을 제거해 주는 것은 아닙니다. 이는 특정 유형의 시스템 병목 현상(bottlenecks)을 줄여줄 뿐, 정렬(alignment)이나 신뢰성(reliability) 문제를 마법처럼 해결해 주지는 않습니다.

마지막으로, 사고자(thinker)–수행자(performer)의 분리는 영리한 방식이지만, 실시간 멀티모달(multimodal) AI가 하드웨어 집약적(hardware-heavy)일 수 있음을 상기시켜 주기도 합니다. 루프(loop)를 엔지니어링하는 것은 부수적인 세부 사항이 아니라 작업의 핵심적인 부분입니다.

개발자가 얻어야 할 교훈

Wan-Streamer가 주는 가장 큰 교훈은 단순히 "모델을 더 크게 만들라"거나 "더 빠르게 만들라"는 것이 아닙니다. 그것은 바로 상호작용 루프(interaction loop)의 형태가 중요하다는 점입니다.

만약 실시간 AI 제품을 구축하고 있다면, 다음과 같은 다른 질문들을 던져보아야 합니다.

• 시스템에 정말로 별도의 모듈이 필요한가, 아니면 그중 일부를 하나의 인과적 백본(causal backbone)으로 통합할 수 있는가?
• 파이프라인(pipeline)에서 피할 수 없는 대기 시간은 어디인가?
• 경험이 연속적으로 느껴지게 하려면 턴(turn) 사이에 어떤 상태(state)를 유지해야 하는가?
• 시스템의 어떤 부분들이 서로를 차단(blocking)하는 대신 중첩(overlap)될 수 있는가?

이러한 질문들은 완전한 오디오-비디오 에이전트(audio-video agent)를 구축하지 않더라도 적용됩니다. 음성 어시스턴트, 스트리밍 전사(transcription) 도구, 멀티모달 코파일럿(multimodal copilots), 그리고 협업 창작 앱에도 똑같이 유효합니다.

맺음말

Wan-Streamer v0.1은 많은 "AI 경험" 문제들이 실제로는 시스템 설계(systems design) 문제라는 점을 유용한 시사점으로 던져줍니다. 모델이 실시간처럼 느껴져야 한다면, 아키텍처(architecture) 또한 실시간이어야 합니다. 이 프로젝트는 하나의 전진 경로를 보여줍니다. 즉, 모듈식이고 배치 지향적(batch-oriented)이며 사후에 짜깁기된 방식이 아닌, 인과적(causal)이고 스트리밍 방식이며 통합된(unified) 방식입니다.

이것이 모든 팀이 정확히 동일한 설계를 복제해야 한다는 의미는 아닙니다. 다만 여러분의 제품이 자연스러운 상호작용에 의존한다면, 정보가 시스템을 통해 어떻게 이동하는지에 세심한 주의를 기울여야 한다는 뜻입니다. 실시간 AI에서 입력부터 응답에 이르는 경로는 종종 그 자체로 제품이 됩니다.