말하는 AI 아바타는 모델 하나가 아니다 — STT · LLM · TTS 끝에 얼굴을 붙인 파이프라인, 적은 지연의 합

말하는 AI 아바타를 처음 보면 거대한 모델 하나가 듣고 생각하고 얼굴까지 움직이는 것처럼 보인다. 뜯어보면 아니다. 평범한 음성 에이전트 끝에 얼굴 생성기를 하나 붙인 파이프라인이다.

그래서 체감 품질을 정하는 건 얼굴이 얼마나 사실적이냐보다 네 단계 지연의 합이다. 이 글을 읽으면 아바타가 왜 느린지, 어디부터 줄여야 하는지 순서가 잡힌다.

네 단계

① STT(음성을 글자로) ② LLM(대답 만들기) ③ TTS(대답을 음성으로) ④ 얼굴(음성을 입모양 · 표정 프레임으로). 사용자가 말을 끝냈는지는 VAD(음성 구간 감지)가 판단하고, 결과 영상은 WebRTC 로 양방향 스트리밍한다.

앞의 셋은 음성 비서와 똑같다. 새로운 건 ④ 하나다. 음성 에이전트를 만들어 봤다면 거기에 ④ 만 얹는다고 보면 된다. 텍스트 챗봇만 해 봤다면 지연을 걱정할 곳이 LLM 하나에서 넷으로 늘어난다.

순서대로 기다리면 느리다

네 단계를 하나씩 끝내고 넘기면 사용자는 네 단계 시간을 다 더한 만큼 기다린다. 그래서 실제 서비스는 구간을 겹친다. LLM 이 첫 문장을 내면 바로 TTS 를 시작하고, 음성이 조금이라도 나오면 바로 얼굴 생성을 시작한다.

아래 줄이 겹친 모양이다. 사람이 느끼는 건 「첫 소리가 나오기까지」 다. 그게 확 당겨진다. 막대 길이는 설명용이고 잰 값이 아니다.

끼어들기도 파이프라인 문제다

대화 중에 사용자가 말을 끊으면(barge-in) ②③④ 를 전부 멈춰야 한다. 얼굴만 멈추고 TTS 가 계속 돌면 입은 닫았는데 소리가 난다.

Anam SDK 에는 이걸 위한 TALK_STREAM_INTERRUPTED 이벤트와 interruptPersona() 가 따로 있다. Anam API 문서에는 transcription → LLM → TTS → 첫 오디오까지를 단계별 p50 / p90 / p99 로 돌려주는 세션 분석 엔드포인트도 있다. 지연은 단계별로 보라는 이야기를 벤더 스스로 하는 셈이다. 이 엔드포인트는 아직 실제로 불러 보진 않았다.

직접 떼어 보려고 만든 것

app10 에 STT → LLM → TTS → 얼굴을 한 단계씩 따로 돌리고 단계마다 ms 를 찍는 페이지(/avatar_pipeline)를 만들었다. Anam 은 단계를 떼어 낼 수 있어서 이런 실험이 된다. llmId 를 CUSTOMER_CLIENT_V1 로 주면 ② 를 우리가 맡고, enableAudioPassthrough 를 켜면 ②③ 까지 우리가 맡는다. Anam 은 ④ 만 한다.

실제 키로 돌린 수치는 아직 없다. 짐작으로 채우지 않으려고 표는 비워 뒀다. 재 보면 내 파이프라인이 불리하게 나올 것도 알고 있다. 단계마다 서버를 거쳐 왕복하고, 스트리밍으로 겹치지 않기 때문이다. 그 차이가 얼마인지는 재고 나서 덧붙이겠다.

어디부터 줄이나

얼굴 모델을 더 좋은 걸로 바꾸는 건 맨 나중이다. 먼저 단계별 ms 를 잰다. 겹칠 수 있는 곳을 스트리밍으로 겹친다. 끼어들기를 넣는다. 그래도 느리면 그때 가장 긴 단계를 바꾼다.

아바타나 음성 에이전트를 서비스에 붙이다가 지연에서 막혔다면 negabaro 에 물어봐도 된다 (문의).