말하면서 생각한다: 실시간 음성 AI StepAudio 3 Realtime 심층 분석

StepAudio 3 Realtime은 '말하는 동안 속으로 추론'하는 구조로 실시간 음성 대화의 반응 속도와 깊은 사고를 함께 노린 오디오-언어 기반 모델이다.
English  ·  日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 09월 17일 수정 2026.10.16 읽기 10분 조회 4

StepAudio 3 Realtime은 사람처럼 실시간으로 대화하면서도 깊은 추론을 놓치지 않으려는 오디오-언어 기반 모델(audio-language foundation model)이다. 핵심은 '말하면서 동시에 속으로 생각하기'(Think-While-Speaking)로, 답변을 음성으로 내보내는 그 순간에도 겉으로 드러나지 않는 사적 추론(private reasoning)을 병렬로 돌린다. 지연을 감수하고 깊이를 얻거나, 깊이를 포기하고 속도를 얻는 기존의 맞교환을 피하려는 설계다.

StepAudio 3 Realtime이 겨냥한 문제

사람끼리 전화 통화를 떠올려 보자. 우리는 상대가 말하는 도중에도 다음 대답을 준비하고, "음", "그렇죠" 같은 맞장구(backchannel)를 끼워 넣고, 필요하면 말을 끊고 들어간다. 잠깐의 침묵도 자연스럽게 넘긴다. 이 모든 게 거의 동시에, 지연 없이 일어난다.

기존 음성 AI는 여기서 두 가지 긴장에 부딪혔다. 하나는 '깊이 생각하기'와 '빨리 대답하기'의 충돌이다. 좋은 답에는 추론 시간이 필요한데, 실시간 대화에서는 조금만 뜸을 들여도 어색해진다. 그래서 많은 시스템이 '빠르지만 얕은 답'과 '느리지만 깊은 답' 중 하나를 골라야 했다. 다른 하나는 대화의 흐름(turn-taking) 자체다. 침묵을 대화 종료로 오해하거나, 사용자가 끼어들어도 자기 말을 계속하거나, 맞장구조차 넣지 못하는 문제다. StepAudio 3 Realtime은 이 두 긴장을 정면으로 겨냥한다.

네 가지 구성 요소

이 모델은 '듣기-대화-생각-행동'(listen-converse-think-act)이 끊기지 않고 도는 순환 고리로 설계됐다. 초록이 드는 구성 요소는 넷이다.

  • Deep Perception(깊은 지각) — 단어의 뜻만이 아니라 목소리의 떨림·빠르기·억양 같은 음향 단서(acoustic cues)를 함께 읽어 의도를 파악한다. 같은 "괜찮아요"가 안심한 톤인지 참는 톤인지를 구분하려는 시도다.
  • Seamless Duplex(매끄러운 양방향 처리) — 모델의 음성과 사용자의 음성이라는 두 오디오 스트림을 동기화해, 침묵·맞장구·끼어들기(interruption)를 다룬다. 사용자가 말을 자르고 들어와도 흐름이 무너지지 않는다.
  • Think-While-Speaking(말하면서 생각하기) — 이 논문의 핵심 발상이다. 노련한 발표자가 입으로는 이번 문장을 말하면서 머릿속으로는 다음 말을 정리하듯, 음성을 내보내는(spoken delivery) 동안 병렬로 사적 추론을 돌린다. 초록은 이 방식으로 전용 추론 모델(dedicated reasoning models)에 견줄 대화·추론 성능을 실시간으로 말하면서 달성했다고 주장한다.
  • Voice Agent(음성 에이전트) — 도구 실행(tool execution)을 비동기(asynchronous)로 처리한다. 무언가를 조회하는 작업이 백그라운드에서 도는 동안에도 대화는 멈추지 않는다.

넷은 각각 잘 듣고, 끊김 없이 주고받고, 말하면서 생각하고, 대화를 방해하지 않고 일을 처리하는 축이다. 그중 실제 반응 경험을 가르는 건 뒤의 둘 — 말하는 중에 추론이 돌고, 도구가 배경에서 도는 부분이다. 이걸 사람이 체감할 수 있는 한 장면으로 내려 보면 구조가 선명해진다.

AI PM의 일정 변경 요청 처리 — 한 장면 분석

온틀은 고객 프로젝트마다 AI 프로젝트 매니저(PM)를 파견하는 SaaS다. AI PM에게 고객이 "다음 주 마일스톤을 이틀 당길 수 있을까요?"라고 묻는 상황을 놓고, 순차 방식과 병렬 방식을 같은 장면에서 비교해 보자. 논문은 음성이지만, 벌어지는 일은 텍스트 PM 챗에도 그대로 옮겨진다.

순차 방식. 요청을 받은 PM은 "확인해 보겠습니다"라고 답한 뒤 침묵한다. 그동안 일정 문서와 의존 작업(디자인 검수, QA 기간 등)을 조회한다. 조회가 끝나야 비로소 답이 나온다. 조회에 걸리는 시간만큼 대화는 얼어붙고, 고객은 '기다리게 하는 도구' 앞에 앉아 있게 된다.

병렬 방식. 요청을 받자마자 PM은 말을 시작하면서 동시에 속으로 문서를 조회한다. 여기서 세 가지를 구분해야 한다.

  • 조회 결과가 나오기 전에 말해도 되는 것: 요청을 접수했다는 확인, 무엇을 확인하려는지(어떤 산출물과 의존 작업을 볼지), 확정이 아닌 일반 맥락(앞당기면 검수·QA에 쓸 시간이 줄어든다는 원리). 이건 조회 없이도 참인 내용이라 먼저 내보내도 안전하다.
  • 확정하면 안 되는 것: "가능합니다", "이틀 당기겠습니다" 같은 확약. 아직 의존 작업을 보지 않았으므로, 이 발화는 조회 뒤에야 나와야 한다.
  • 후속 결과가 앞선 발화와 충돌할 때: 조회 결과가 "이틀을 당기면 디자인 검수 일정과 겹친다"로 나왔다고 하자. 앞서 낙관적인 뉘앙스를 이미 흘렸다면, 정정 발화가 필요하다. "확인해 보니 검수와 겹쳐 이틀은 어렵고 하루는 가능합니다." 이 정정 문제는 제품에 얹힐 때 새로 생기는 게 아니라 논문 구조에 이미 들어 있다 — 논문은 추론이 끝나기 전에 발화를 시작하고, 마지막 후속 발화로 앞선 답을 보완하거나 정정할 수 있다고 명시한다(§6.3). 에이전트가 이미 밖으로 낸 말과 나중 결과가 어긋나면 조용히 고쳐 쓸 수 없고, 앞말을 번복하는 비용을 대화 위에서 치러야 한다. 온틀 같은 제품에 얹힐 때는 이 번복 비용이 그대로 사용자 경험 위에 드러난다.

그래서 개선 여부는 감이 아니라 지표로 판단해야 한다. 첫 응답까지의 지연(고객이 첫 글자를 받기까지 걸린 시간), 내보낸 말 중 나중에 번복된 비율(정정 빈도), 조회 전에 확약을 내버린 확약 오류율 — 이 셋을 같이 본다. 지연만 줄고 정정 빈도가 함께 오르면, 그건 '빨라진' 게 아니라 '섣불러진' 것이다.

여기까지가 논문에 담긴 것과 온틀의 적용 가설이 갈리는 지점이다. 논문이 보여 준 것은 음성 모델이 발화 중 병렬 추론과 비동기 도구 실행으로 지연을 줄였다는 결과다. 그 값어치를 텍스트 PM 챗에서 회수하려면, 위 세 지표로 '말해도 되는 것과 확정하면 안 되는 것의 경계'를 관리하는 일이 남는다. 이 경계 설계는 논문이 대신 풀어 주지 않는, 우리 쪽 숙제다.

수치를 어떻게 읽을까

초록이 제시한 값은 아래와 같다. 모두 초록 기준이며, 각 벤치마크의 세부 조건은 원문을 확인해야 한다. 점수들은 대체로 0~100 눈금 위에 있어, 90대 값은 눈금 위쪽에 자리한다는 정도로 읽으면 된다.

항목 점수 설명(초록 기준)
StepAudioChat (추론 모드) 73.0 매크로 평균 추론 모드에서의 대화 성능
MMSU 벤치마크 90.6 음성 언어 이해를 재는 지표, 눈금 상단에 근접
Artificial Analysis Full-Duplex Bench 98.9 (Overall) 양방향 대화 처리 종합 점수
τ-Voice 56.0% (매크로 과제 성공률) 음성 기반 과제 수행 성공률

의미 있는 대목은 단일 지표의 높이보다 조합이다. Think-While-Speaking을 켠 채로 전용 추론 모델에 견줄 성능을 실시간으로 냈다는 주장이 초록의 중심이다. 다만 τ-Voice의 성공률은 성격이 다르다. 그럴듯하게 대화하는 데서 나아가 음성 에이전트가 실제 과제를 수행해 끝내는 능력을 재는데, 56.0%는 절반을 조금 넘는 수준이다. 완성된 자동화라기보다 실용 가능성의 초기 신호로 읽는 편이 맞고, 앞 장면에서 본 '확약 오류'가 어디서 새는지를 이 수치가 간접적으로 말해 준다.

한계와 남은 질문

초록만으로는 확인할 수 없는 부분이 많다.

  • 절대 성능의 해석: τ-Voice 56.0%는 실패율이 여전히 높다는 뜻이고, 어떤 유형의 과제에서 실패하는지는 초록에 없다.
  • 평가 조건의 불투명성: 각 벤치마크가 어떤 언어·도메인·난이도로 구성됐는지, 지연을 몇 밀리초까지 줄였는지는 초록에 수치로 없다. "실시간"의 정량 기준은 원문에서 확인해야 한다.
  • Think-While-Speaking의 대가: 발화와 병렬로 추론할 때 드는 연산·메모리는 초록만으로는 알 수 없다. 발화 중 앞선 답이 어긋나면 논문은 마지막 후속 발화로 보완·정정한다고 밝히지만(§6.3), 그 정정이 실제 대화에서 얼마나 자주·자연스럽게 일어나는지는 초록에 수치로 없다.
  • 비교 대상의 모호함: "전용 추론 모델에 견줄 만하다"에서 어떤 모델과 어떤 조건에서 동등한지는 명시돼 있지 않다.

이 항목들은 원문 본문에서 근거를 확인해야 하는 지점이다.

병렬 추론을 켜면 응답이 빨라지는데, 왜 그냥 좋은 게 아닌가요?

지연이 줄어도 조회 전에 내보낸 말이 나중 결과와 충돌하면 번복 비용이 생기기 때문입니다. 속도만 보지 말고 정정 빈도와 확약 오류율을 함께 봐야, 빨라진 것인지 섣불러진 것인지 구분됩니다.

텍스트 기반 AI PM에 이 발상을 지금 적용할 수 있나요?

설계 원리는 옮겨집니다. 다만 핵심은 '결과 전에 말해도 되는 것(접수·확인 항목·일반 맥락)'과 '확정하면 안 되는 것(가능 여부 확약)'의 경계를 먼저 정하는 일입니다. τ-Voice 성공률이 초기 신호 수준인 만큼, 초반에는 사람 검수(human-in-the-loop)를 함께 두는 편이 현실적입니다.

참고자료