Thinking Machines, AI 협업을 턴제에서 실시간으로 바꾸다
Thinking Machines Interaction Models는 AI가 말하면서 듣고 보는 full-duplex 협업 모델을 제안합니다.
- 무슨 일: Thinking Machines Lab이
Interaction Models연구 프리뷰를 공개했습니다.- 200ms 단위 micro-turn으로 audio, video, text를 동시에 처리하는 실시간 협업 모델입니다.
- 핵심 변화: AI가 사용자의 말이 끝나길 기다리지 않고 듣고, 보고, 말하고, tool을 씁니다.
- 개발자 의미: realtime API는 이제 음성 입출력보다
full-duplexorchestration 문제가 됩니다. - 주의점: 아직 제한적 연구 프리뷰이며, 긴 세션·연결 품질·안전성은 검증 전입니다.
Thinking Machines Lab이 2026년 5월 11일 공개한 Interaction Models는 겉으로 보면 또 하나의 실시간 음성 AI 발표처럼 보입니다. 하지만 이번 발표의 흥미로운 지점은 음성 모델 성능이나 데모 영상 그 자체가 아닙니다. Thinking Machines는 "AI가 언제 듣고 언제 말해야 하는가"라는 인터페이스 문제를 모델 아키텍처 문제로 다시 정의했습니다. 지금까지 많은 AI 제품은 사용자가 한 번 입력하고, 모델이 한 번 응답하고, 다시 사용자가 입력하는 turn-based 구조를 기본값으로 삼았습니다. 음성 모드에서도 형태는 비슷했습니다. 사람이 말을 멈추면 voice activity detection이 turn boundary를 잡고, 모델이 응답을 만든 뒤, TTS가 소리로 내보냅니다.
Thinking Machines가 제안한 interaction model은 이 순서를 깨려 합니다. 사용자가 말하는 동안 모델도 계속 듣고, 사용자가 화면에서 무언가를 보여주는 동안 모델도 계속 보고, 필요하면 사용자의 말이 끝나기 전에 짧게 끼어들거나, 동시에 말하거나, background model에게 더 긴 reasoning과 tool use를 맡깁니다. 공식 발표문은 이를 "interactivity should scale alongside intelligence"라는 문장으로 요약합니다. 모델이 더 똑똑해지는 것만으로는 부족하고, 인간과 함께 일하는 시간 감각도 같이 커져야 한다는 주장입니다.
이 방향은 최근 AI 에이전트 담론과 약간 다른 위치에 있습니다. 2025년과 2026년의 에이전트 경쟁은 대체로 "사람이 목표를 주면 에이전트가 오래 실행한다"는 쪽으로 이동했습니다. 코딩 에이전트는 이슈를 받아 브랜치를 만들고, 테스트를 돌리고, PR을 냅니다. 리서치 에이전트는 몇 분 또는 몇 시간 동안 검색하고 요약합니다. 업무 에이전트는 CRM, 캘린더, 문서, 결제 도구를 연결합니다. 모두 중요합니다. 하지만 이 모델은 사용자가 요구사항을 처음부터 완전히 말할 수 있다는 가정에 크게 기대고 있습니다.
현실의 협업은 그렇게 깔끔하지 않습니다. 좋은 요구사항은 대화하면서 생깁니다. 디자이너는 화면을 보며 "이 부분은 좀 답답합니다"라고 말하고, 개발자는 실행 중인 앱을 가리키며 "여기서 상태가 꼬입니다"라고 말합니다. 의사는 환자의 말뿐 아니라 표정과 멈칫거림을 봅니다. 회의에서는 누군가 말하는 도중 다른 사람이 "잠깐, 그 전제는 틀렸습니다"라고 끼어듭니다. Thinking Machines의 논지는 여기서 출발합니다. 인간이 loop 안에 남아야 하는 일이 많은데, 현재 AI 인터페이스는 그 loop를 너무 좁은 채널로 압축한다는 것입니다.
Turn-based AI의 병목
오늘날의 일반적인 LLM 인터페이스는 텍스트 채팅의 시간 구조를 그대로 가져왔습니다. 사용자의 입력은 하나의 완성된 message가 되고, 모델의 출력도 하나의 완성된 assistant message가 됩니다. 스트리밍 토큰이 있더라도 큰 흐름은 같습니다. 모델은 사용자의 message가 끝난 뒤에야 본격적으로 응답을 시작합니다. 사용자가 중간에 말을 바꾸거나, 화면에서 새로운 일이 일어나거나, 응답 도중 "아니 그게 아니라"라고 말해도 시스템은 별도 interruption handling, turn detector, dialog manager를 붙여 처리합니다.
Thinking Machines는 이 외부 하네스 방식이 확장성에서 불리하다고 봅니다. voice activity detection은 말이 끝났는지 추정할 수 있지만, 사용자가 생각 중인지, 자기 말을 고치고 있는지, 모델에게 들어오라고 신호를 주는지, 아니면 옆 사람과 말하는지까지 깊게 이해하지는 못합니다. 화면 기반 시스템도 비슷합니다. 모델이 사용자의 화면을 주기적으로 캡처해 볼 수는 있지만, "지금 이 시각적 변화에 대해 즉시 말해야 하는가"는 또 다른 정책 계층이 됩니다.
interaction model의 핵심은 이런 정책을 모델 밖에 덧대는 것이 아니라 모델 안에 넣는 것입니다. 발표문은 현재 상용 frontier model들이 현실을 단일 thread로 경험한다고 표현합니다. 사용자가 말하는 동안 모델은 기다리고, 모델이 말하는 동안 모델의 perception은 멈춥니다. 반면 사람이 실제로 협업할 때는 듣기, 보기, 말하기, 기다리기, 끼어들기, 고개 끄덕이기, 작업하기가 동시에 일어납니다. Thinking Machines는 AI도 이 시간 구조를 직접 학습해야 한다고 주장합니다.
200ms micro-turn이라는 설계
이번 프리뷰의 중심 모델은 TML-Interaction-Small입니다. Thinking Machines는 이 모델을 처음부터 interaction model로 훈련했다고 설명합니다. 기본 단위는 200ms입니다. 모델은 200ms worth of input과 200ms worth of output을 micro-turn으로 나누고, audio, video, text 입력과 text/audio 출력을 시간축 위에 interleave합니다. 사용자의 발화가 완성될 때까지 기다렸다가 하나의 turn으로 처리하는 것이 아니라, 아주 작은 시간 조각마다 보고 듣고 응답할 수 있게 만드는 방식입니다.
공식 발표에는 turn-based 구조와 time-aligned micro-turn 구조를 비교하는 그림이 들어 있습니다. turn-based 모델은 input 1, output 1, input 2, output 2처럼 한 줄로 납작해진 token sequence를 봅니다. interaction model은 video frame, audio stream, model output, silence, overlap, interruption이 시간에 정렬된 흐름을 봅니다. 이 차이는 UX에서 크게 나타납니다. 모델이 사용자의 말을 끝까지 기다리지 않고도 backchannel을 줄 수 있고, 사용자가 잘못 말하는 순간 바로 잡을 수 있으며, 사용자가 화면에서 버그를 만드는 순간 음성으로 끼어들 수 있습니다.
기술적으로도 흥미로운 선택이 있습니다. Thinking Machines는 대형 standalone encoder에 크게 의존하지 않는 early fusion 방식을 설명합니다. audio는 dMel 신호로 받아 가벼운 embedding layer를 거치고, 이미지는 40x40 patch로 나누어 hMLP로 encode합니다. audio decoder에는 flow head를 사용하며, 이 구성요소들을 transformer와 함께 처음부터 co-train했다고 밝힙니다. 즉 ASR 모델, LLM, TTS 모델을 이어 붙이는 파이프라인이라기보다, audio/video/text의 시간 동시성을 모델의 기본 입력 구조로 만든 셈입니다.
또 하나의 포인트는 inference입니다. 200ms chunk를 계속 처리하려면 작은 prefill과 decode가 매우 자주 일어납니다. 기존 LLM inference stack은 대량 token 처리에는 강하지만 이런 짧고 빈번한 요청에는 overhead가 큽니다. Thinking Machines는 streaming session을 구현해 client가 200ms chunk를 요청으로 보내면 inference server가 GPU memory의 persistent sequence에 이어 붙이는 식으로 처리했다고 설명합니다. 관련 기능 일부는 SGLang에 upstream했다고도 밝혔습니다. realtime AI는 모델 논문만의 문제가 아니라 serving runtime과 network protocol의 문제라는 점이 여기서 드러납니다.
빠른 모델과 느린 모델의 분업
Thinking Machines의 시스템은 interaction model 하나만으로 모든 일을 끝내지 않습니다. 구조는 두 층입니다. 하나는 사용자의 앞에 계속 남아 있는 빠른 interaction model입니다. 다른 하나는 더 긴 reasoning, tool use, browsing, background work를 맡는 background model입니다. interaction model은 사용자의 말과 화면을 계속 따라가고, 깊은 사고가 필요한 순간 background model에게 context package를 넘깁니다. background model의 결과는 완성된 답변으로 갑자기 삽입되는 것이 아니라, 사용자가 현재 하고 있는 일의 흐름에 맞춰 interaction model이 대화에 섞어 넣습니다.
이 구조는 AI 제품 설계에서 꽤 중요한 힌트를 줍니다. 앞으로의 실시간 에이전트는 "가장 똑똑한 모델 하나를 socket에 붙인다"로 끝나지 않을 가능성이 큽니다. 사용자의 앞에 놓이는 모델은 latency, turn-taking, interruption, sensory grounding에 최적화되어야 합니다. 뒤에서 일하는 모델은 planning, retrieval, tool execution, verification에 최적화될 수 있습니다. 두 모델은 context를 공유해야 하지만, 사용자에게 결과를 보여주는 방식은 앞단의 interaction model이 조율해야 합니다.
이 패턴은 개발자에게 익숙한 frontend/backend 분리와 비슷해 보이지만, 실제로는 더 어렵습니다. frontend model은 단순 UI wrapper가 아닙니다. 그것도 지능을 갖고 있고, 사용자의 현재 attention과 시간 감각을 판단해야 합니다. backend model도 단순 worker가 아닙니다. 그 결과는 실시간 대화 흐름 속에 부분적으로 흘러 들어와야 합니다. 그래서 interaction model은 단순 음성 챗봇이 아니라 agent runtime의 scheduler, narrator, interruption manager 역할까지 일부 가져갑니다.
벤치마크는 무엇을 말하나
Thinking Machines는 TML-Interaction-Small이 intelligence와 interactivity를 동시에 잡는 첫 모델이라고 주장합니다. 공식 표에서 이 모델은 FD-bench v1 turn-taking latency 0.40초를 기록했습니다. 같은 표의 GPT-realtime-2.0 minimal은 1.18초, GPT-realtime-1.5는 0.59초, Gemini 3.1 Flash Live minimal은 0.57초로 제시됩니다. FD-bench v1.5 average에서는 TML-Interaction-Small이 77.8을 기록했고, GPT-realtime-2.0 minimal은 46.8, Gemini 3.1 Flash Live minimal은 54.3으로 제시됐습니다.
다만 이 숫자를 읽을 때는 조심해야 합니다. 첫째, Thinking Machines가 직접 작성한 발표문입니다. 벤치마크 자체가 공개된 항목도 있지만, 실험 조건과 실제 사용자 경험을 독립적으로 충분히 재현하기 전까지는 "우세한 방향의 초기 증거" 정도로 보는 편이 맞습니다. 둘째, realtime 모델의 품질은 latency 하나로 결정되지 않습니다. 음성 품질, 연결 끊김, 회의 소음, 다양한 억양, 화면 캡처 빈도, 개인정보 처리, interruption의 적절성까지 합쳐져야 제품 경험이 됩니다. 셋째, 연구 프리뷰라는 점도 중요합니다. TechCrunch도 이 발표를 다루며 아직 공개 제품이 아니므로 실제 경험은 사람들이 직접 써보기 전까지 알 수 없다고 짚었습니다.
그럼에도 이 벤치마크가 중요한 이유는 "무엇을 평가해야 하는가"를 바꾸기 때문입니다. 기존 모델 평가는 주로 답이 맞는지, 코드를 고치는지, 수학 문제를 푸는지, tool call을 제대로 하는지에 집중했습니다. interaction model은 여기에 "언제 말해야 하는가", "말하지 말아야 할 때 조용히 있을 수 있는가", "사용자가 말하는 중간에 정확히 필요한 말을 할 수 있는가", "화면에서 답이 나타나는 순간 반응할 수 있는가"를 추가합니다. AI가 실제 현장에서 사람과 같이 일하려면 이 질문은 부차적이지 않습니다.
시각적 proactivity가 중요한 이유
이번 발표에서 가장 실무적인 부분은 visual proactivity입니다. 음성 AI는 이미 꽤 자연스러워졌지만, 대부분은 audio-only turn-taking에 가깝습니다. 사용자가 말하면 듣고, 말이 끝나면 답합니다. 그런데 작업 현장은 시각적입니다. 개발자는 에디터, 터미널, 브라우저, 로그, 디자인 시안, 대시보드를 봅니다. 제조 현장과 의료 현장, 교육 현장도 화면이나 실제 장면을 봅니다. 모델이 실시간 협업자가 되려면 사용자가 "지금 봐"라고 말하지 않아도 시각적 변화가 의미 있는 순간을 감지해야 합니다.
Thinking Machines는 이를 평가하기 위해 RepCount-A, ProactiveVideoQA, Charades 같은 영상 기반 benchmark를 streaming 상황으로 바꿨다고 설명합니다. 예를 들어 사용자가 "팔굽혀펴기를 몇 번 하는지 세어줘"라고 말한 뒤 영상만 흘러가면, 모델은 오디오 cue가 없어도 동작을 계속 추적하고 적절한 타이밍에 숫자를 말해야 합니다. 발표문은 GPT-realtime-2.0 minimal이 이런 visual proactivity 영역에서 거의 응답하지 못하거나 잘못 응답한다고 보고합니다. TML-Interaction-Small은 RepCount-A off-by-one 35.4, ProactiveVideoQA 33.5, Charades mIoU 32.4를 기록했다고 합니다.
개발자 도구로 옮겨보면 이 차이는 더 선명합니다. 지금의 코딩 에이전트는 대체로 issue나 prompt를 받아 작업합니다. 하지만 pair programming에서 중요한 순간은 사용자가 설명을 끝낸 뒤만이 아닙니다. 사용자가 테스트 실패 로그를 보며 망설이는 순간, IDE에서 같은 파일을 반복 수정하는 순간, 브라우저에서 UI가 깨진 순간, 모델이 바로 "방금 state update가 두 번 발생했습니다"라고 말할 수 있다면 interaction pattern이 달라집니다. 이것은 단순히 화면을 더 자주 캡처하는 문제가 아닙니다. 언제 말해야 하는지, 언제 조용히 있어야 하는지, 어떤 말은 방해가 되는지까지 학습해야 합니다.
데모가 보여주는 것과 아직 모르는 것
Thinking Machines는 공식 글에 여러 YouTube 데모를 넣었습니다. seamless dialog management, verbal/visual interjection, simultaneous speech, time awareness, simultaneous tool calls and search, generative UI, longer real session 등이 포함됩니다. 이 데모들은 말 그대로 "대화가 끝난 뒤 응답"이 아닌 경험을 보여줍니다. 모델이 사용자의 이야기를 따라가며 적절히 반응하고, 시각적 단서를 보고 끼어들고, 동시에 search와 UI 생성을 진행하는 장면입니다.
하지만 데모는 데모입니다. 실시간 AI 제품의 난점은 아름다운 single session보다 지저분한 일상 세션에 있습니다. 회의실 마이크가 멀고, 배경 소음이 있고, 화면이 계속 바뀌고, 사용자가 반쯤 말하다 멈추고, 민감한 정보가 지나가고, 모델이 끼어들면 안 되는 순간이 많습니다. "proactive"는 좋은 말이지만, 제품에서는 쉽게 "방해"가 됩니다. 특히 개발 도구나 업무 도구에서 AI가 계속 보고 듣는다면, 사용자는 도움이 되는 동료와 감시하는 소프트웨어 사이의 경계를 민감하게 느낄 수 있습니다.
공식 발표도 limitations를 꽤 분명히 적었습니다. continuous audio/video는 context를 빠르게 쌓기 때문에 긴 세션 관리가 어렵습니다. 낮은 latency의 streaming audio/video는 안정적인 연결이 필요하고, 연결 품질이 떨어지면 경험이 크게 나빠질 수 있습니다. realtime interface는 alignment와 safety 문제도 다르게 만듭니다. 텍스트 챗봇의 안전 정책은 한 번의 message를 보고 거절문을 생성하면 되지만, 실시간 음성에서는 거절도 자연스러운 대화 흐름과 동시에 안전해야 합니다. Thinking Machines는 자연스럽지만 단호한 speech refusal을 위해 별도 데이터를 만들었다고 설명합니다.
API와 제품 설계의 변화
이 발표를 AI 개발자 관점에서 보면 질문은 "이 모델을 언제 쓸 수 있나"보다 넓습니다. interaction model이 제품화된다면 API는 기존 chat completion이나 단순 realtime websocket보다 복잡해질 가능성이 큽니다. audio chunk, video frame, text event, tool result, background task update, UI generation event가 모두 시간축 위에서 오가야 합니다. 단순히 messages 배열에 user와 assistant를 번갈아 넣는 구조로는 부족합니다.
첫째, session memory가 중요해집니다. Thinking Machines가 언급한 streaming session처럼 서버는 매우 작은 chunk를 persistent sequence에 이어 붙여야 합니다. 이때 어떤 frame과 audio segment를 얼마나 오래 유지할지, 어떤 정보를 요약해 남길지, 민감한 화면 정보를 어떻게 폐기할지 설계해야 합니다. realtime AI의 context management는 텍스트 long context보다 더 빠르게 비용과 개인정보 문제로 이어집니다.
둘째, tool call의 semantics가 바뀝니다. 기존 tool call은 모델이 응답 중간에 함수를 호출하고 결과를 받아 다음 token을 생성하는 구조였습니다. interaction model에서는 사용자가 계속 말하는 동안 background model이 검색하고, interaction model은 동시에 사용자의 follow-up에 답해야 합니다. tool result가 돌아왔을 때 사용자에게 바로 말할지, 기다릴지, 화면 UI로 보여줄지, background task에만 반영할지 결정해야 합니다. 이는 agent orchestration과 realtime UX가 합쳐지는 지점입니다.
셋째, permission boundary가 더 까다롭습니다. 모델이 항상 보고 듣고 즉시 말할 수 있다면 권한은 더 세밀해야 합니다. 화면 보기, 마이크 듣기, 카메라 보기, web search, 사내 문서 검색, 코드 실행, 외부 메시지 전송은 모두 다른 위험을 갖습니다. interaction model의 장점은 자연스러운 협업이지만, 같은 이유로 사용자는 AI가 무엇을 알고 있고 무엇을 할 수 있는지 계속 이해해야 합니다. 좋은 제품은 "모든 것을 허용하면 더 똑똑합니다"가 아니라, 어떤 상황에서 어떤 감각과 도구를 켤지 명확히 보여줘야 합니다.
경쟁사에는 어떤 압력이 생기나
OpenAI, Google, Anthropic, xAI, Alibaba, NVIDIA 계열 연구팀 모두 realtime, multimodal, agentic workflow를 밀고 있습니다. OpenAI에는 Realtime API와 GPT Realtime 계열이 있고, Google에는 Gemini Live API와 Gemini 3.1 Flash Live가 있습니다. Qwen Omni 계열과 Moshi, Nemotron VoiceChat 같은 full-duplex 또는 audio-native 연구도 있습니다. Thinking Machines의 발표가 이들을 즉시 앞질렀다고 말하기는 이릅니다. 제품 배포, 생태계, 가격, 안정성, developer tooling에서는 기존 대형 플랫폼이 훨씬 강합니다.
하지만 Thinking Machines가 던진 프레임은 경쟁사에게 부담이 됩니다. "실시간 음성 응답이 됩니다"만으로는 부족하고, "모델이 시간과 겹침과 시각적 cue를 native하게 다룹니다"라는 기준이 생겼기 때문입니다. 만약 사용자들이 이 경험에 익숙해지면, 기존 voice assistant의 turn-taking 지연은 더 답답하게 느껴질 수 있습니다. 코딩 에이전트도 마찬가지입니다. 앞으로는 background에서 PR을 만드는 agent뿐 아니라, 사용자가 코드를 읽고 있는 바로 그 순간 같이 화면을 보며 반응하는 agent가 중요해질 수 있습니다.
또 하나의 압력은 benchmark입니다. Thinking Machines는 기존 평가가 interactivity를 충분히 측정하지 못한다고 보고 TimeSpeak, CueSpeak, RepCount-A adaptation, ProactiveVideoQA adaptation, Charades streaming evaluation을 제시했습니다. 이 지표들이 커뮤니티에서 받아들여질지는 아직 모릅니다. 그러나 AI 모델 경쟁이 "답이 맞는가"에서 "언제, 어떻게, 얼마나 방해 없이 같이 일하는가"로 넓어지는 방향은 자연스럽습니다. 사용자가 실제로 느끼는 품질은 정답률만으로 설명되지 않기 때문입니다.
개발팀이 지금 봐야 할 것
당장 TML-Interaction-Small을 production에 넣을 수 있는 것은 아닙니다. Thinking Machines는 몇 달 안에 제한적 research preview를 열고, 올해 말 더 넓은 release를 계획한다고만 밝혔습니다. 그래서 이 글을 "새 API 사용법"으로 읽으면 아직 얻을 것이 많지 않습니다. 대신 제품 구조의 변화를 읽는 편이 낫습니다.
첫째, AI 앱을 만들 때 turn-based chat을 기본값으로 놓고 나중에 음성을 붙이는 방식이 한계에 부딪힐 수 있습니다. 특히 교육, 헬스케어, 디자인 리뷰, 개발자 도구, 현장 작업, 고객 상담처럼 사람의 중간 feedback이 중요한 영역에서는 처음부터 interaction state를 설계해야 합니다. 사용자가 말하는 중인지, 생각 중인지, 화면에서 무엇을 보고 있는지, 모델이 끼어들어도 되는지 같은 상태가 제품의 핵심이 됩니다.
둘째, background agent와 foreground collaborator를 분리해 생각해야 합니다. 긴 작업을 잘하는 agent와 실시간으로 자연스럽게 대화하는 agent는 latency budget이 다릅니다. 하나의 모델이 둘 다 잘할 수도 있지만, 시스템 설계 관점에서는 역할을 분리하는 편이 더 현실적입니다. 사용자 앞의 모델은 즉각적인 응답과 attention management를 맡고, 뒤의 모델은 계획과 검증을 맡습니다.
셋째, proactivity는 기능이 아니라 정책입니다. "AI가 알아서 끼어듭니다"는 데모에서는 강력하지만, 실제 제품에서는 많은 실패를 낳을 수 있습니다. 언제 침묵해야 하는지, 언제 짧게 신호만 줘야 하는지, 언제 길게 설명해야 하는지, 어떤 사용자는 얼마나 자주 개입을 원하는지 설정할 수 있어야 합니다. 개발자 도구라면 test failure, security risk, destructive command, UI regression처럼 개입할 가치가 높은 사건부터 시작하는 것이 현실적입니다.
결론
Thinking Machines의 Interaction Models는 아직 제품보다 연구 신호에 가깝습니다. 공개 API도 제한적이고, 외부 재현도 부족하며, 실제 long session에서 얼마나 안정적인지 모릅니다. 하지만 이 발표는 중요한 방향 전환을 보여줍니다. AI 협업의 다음 단계는 더 긴 context window나 더 강한 autonomous agent만으로 설명되지 않습니다. 사람과 같은 시간축에 머무는 능력, 사용자의 말과 화면을 동시에 따라가는 능력, 필요한 순간만 개입하는 능력도 모델 경쟁의 핵심이 될 수 있습니다.
개발자에게 남는 질문은 단순합니다. 우리가 만드는 AI 제품은 여전히 "입력하면 답하는 시스템"인가, 아니면 "사용자와 같은 장면 안에서 같이 일하는 시스템"인가. Thinking Machines는 후자를 모델 아키텍처의 문제로 제기했습니다. 이 주장이 맞다면, 앞으로 realtime AI 개발은 음성 UI를 붙이는 일이 아니라 시간, 도구, 권한, 안전, attention을 함께 설계하는 일이 됩니다.
출처: