생각 기계는 대화 중에 실제로 듣는 AI를 만들고자 한다

기존 LLM은 모두 턴제(turn-taking) 방식의 반이중(half-duplex) 통신 모델로 동작한다. 사용자 입력이 완료되어야(보통 EOS 토큰 또는 음성의 경우 VAD가 발화 종료를 감지해야) 모델이 추론을 시작하고, 모델이 응답을 모두 생성한 후에야 다시 사용자 입력을 받는다. 음성 모드에서도 내부적으로는 STT→LLM→TTS 파이프라인이 순차적으로 돌아가며, GPT-4o의 Realtime API조차도 본질적으로는 발화 단위로 끊어 처리한다. Thinking Machines가 추구하는 것은 진정한 전이중(full-duplex) 모델로, 입력 스트림을 실시간으로 받으면서 동시에 출력 스트림을 생성하는 구조다. 이를 위해서는 입력 인코더와 출력 디코더가 시간축에서 병렬로 동작해야 하며, 모델이 "지금 말을 끊고 끼어들지", "상대가 아직 생각 중인지", "내 답변을 수정해야 할지"를 매 토큰(또는 매 오디오 프레임) 단위로 판단하는 메커니즘이 필요하다. 이는 듀얼 스트림 트랜스포머, 시간 동기화된 크로스 어텐션, 또는 발화자별 분리된 컨텍스트 윈도우 같은 아키텍처적 변화를 요구한다.

엔지니어 입장에서 이 패러다임 전환이 가져올 가장 큰 변화는 음성 에이전트와 실시간 협업 도구 영역이다. 현재 음성 봇이 어색한 가장 큰 이유는 600~1500ms의 응답 지연과 부자연스러운 턴 종료 감지인데, 진정한 풀듀플렉스 모델은 사람이 말하는 중간에 "음", "네" 같은 백채널링을 자연스럽게 삽입하고, 사용자가 말을 바꾸면 즉시 추론 경로를 수정할 수 있다. 코딩 어시스턴트 측면에서도 영향이 크다. 지금의 Cursor·Copilot은 사용자가 타이핑을 멈춰야 제안이 나오지만, 풀듀플렉스 모델은 사용자가 코드를 작성하는 동안 병렬로 다음 라인을 추론하고, 사용자의 키 입력이 추론과 다르면 즉시 경로를 갱신할 수 있다. 다만 이는 동시에 컴퓨팅 비용이 토큰 단위가 아닌 시간 단위로 청구되는 새로운 과금 모델을 요구하며, 인프라 측면에서도 WebSocket이나 WebRTC 기반의 양방향 스트리밍 처리, 그리고 발화 충돌·중단·재개를 다루는 상태 머신 설계가 필수가 된다.

개발자가 지금 준비해야 할 것은 크게 세 가지다. 첫째, 현재 작성 중인 음성·실시간 기능이 있다면 OpenAI Realtime API나 Gemini Live API의 스트리밍 인터페이스에 익숙해져 두는 것이 좋다. 풀듀플렉스 모델이 나와도 결국 클라이언트 측 통합 패턴은 비슷한 양방향 스트림 형태가 될 가능성이 높다. 둘째, 기존 챗봇 UX 설계에서 "턴 경계"를 가정한 상태 관리 로직(예: 메시지 큐, request-response 매칭)은 풀듀플렉스 환경에서 깨질 수 있으므로, 이벤트 기반·시간축 기반 상태 모델로 추상화해 둘 필요가 있다. 셋째, Thinking Machines는 아직 상용 모델을 공개하지 않은 연구 중심 회사(전 OpenAI CTO Mira Murati가 창업)이므로 단기간에 프로덕션 도입은 어렵지만, Kyutai의 Moshi(이미 공개된 오픈소스 풀듀플렉스 음성 모델)나 Meta의 관련 연구를 검토하면 동일한 패러다임을 미리 실험해 볼 수 있다. 풀듀플렉스 모델의 등장은 단순한 성능 개선이 아니라 "AI와의 상호작용"이라는 인터페이스 자체를 재정의하는 변화이므로, 현재의 턴 기반 UX·API 설계 관습을 비판적으로 다시 보는 것이 중요한 시점이다.