오늘 전혀 다른 두 곳에서 같은 결론이 나왔습니다.

하나는 자율주행 업계입니다. 웨이모의 엔지니어링 리드가 강연에서 말했습니다. “데모는 전체 작업의 1%입니다. 나머지 99%는 운영입니다.” 화려한 시연이 아니라, 수천 가지 예외 상황을 처리하는 반복 실행 루프가 자율주행을 실제로 작동하게 만든다는 얘기입니다.

다른 하나는 AI 에이전트 인터페이스 연구입니다. 음성 인터페이스 분석에서 음성이 단순한 입력 채널을 넘어 **병렬 실행의 제어 평면(control plane)**으로 작동하기 시작했다는 신호가 명확해졌습니다.

두 신호가 가리키는 방향은 같습니다. 에이전트 오케스트레이션의 전선이 이동하고 있습니다.

텍스트 오케스트레이션의 구조적 한계

지금까지 대부분의 에이전트 오케스트레이션은 텍스트 기반 순차 실행을 전제로 설계되었습니다. 사용자가 메시지를 입력하면, 오케스트레이터가 해석해 서브 에이전트에 분배하고, 결과를 모아 다시 텍스트로 응답합니다.

이 구조에는 근본적인 한계가 있습니다. 입력이 순차적이면 실행도 순차적으로 흐르기 쉽습니다.

LangGraph나 OpenAI Agents SDK로 병렬 실행을 구현할 수 있는 건 맞습니다. 하지만 텍스트 UI에서 사용자가 “지금 동시에 세 가지 일을 해라”는 의도를 자연스럽게 전달하기는 어렵습니다. 인터페이스 자체가 단일 스레드 대화를 전제로 만들어져 있기 때문입니다.

GPT-Realtime-2와 Parloa 같은 음성 에이전트 제품이 주목받는 이유가 여기에 있습니다.

음성이 바꾸는 것: 병렬 의도의 자연스러운 표현

음성 인터페이스에서 사람은 자연스럽게 병렬 의도를 표현합니다.

“회의실 예약해 주고, 그 사람한테 미리 이메일 보내고, 관련 자료도 찾아놔.”

텍스트로 입력하면 세 개의 분리된 명령처럼 읽히고, 오케스트레이터는 순서대로 처리하려는 경향을 가집니다. 음성으로 말하면 단일 의도 흐름이고, 실행은 자연스럽게 병렬로 분기됩니다.

Andrew Ng이 이미 이 패턴을 설계 원칙으로 정식화했습니다. Vocal Bridge 아키텍처는 음성 레이어를 기존 비주얼 앱 위에 얹는 방식으로, 두 개의 에이전트가 동시에 작동합니다. 하나는 음성을 이해하고, 다른 하나는 화면을 조작합니다. 모달리티가 분리되면 에이전트도 분리되고, 분리된 에이전트는 병렬로 실행됩니다.

젠슨 황이 Alpamayo 2 발표에서 반복 강조한 것도 같은 방향입니다. “행동 전 추론(think-before-act)“이 자율주행과 물리 AI의 기본 백본으로 수렴하고 있다고 했습니다. 음성 명령이 들어오면 에이전트는 먼저 추론하고, 그 추론을 여러 실행 스레드로 분기합니다. 웨이모의 “운영 99%“가 요구하는 것이 바로 이 구조입니다.

딥엑스가 NPU 기반으로 공군 경계감시 시스템을 구축할 때 이 문제를 실제로 풀었습니다. 현장 음성 명령이 들어오면 영상 분석 에이전트, 알림 에이전트, 보고 에이전트가 동시에 구동됩니다. 이 세 에이전트를 어떻게 분기하고 동기화할지가 시스템 신뢰성을 결정했습니다.

PM이 다시 설계해야 하는 것

음성이 병렬 실행의 게이트가 된다면, PM이 설계해야 하는 것이 달라집니다.

첫째, 의도 파싱을 병렬 실행 단위로 쪼개는 레이어가 필요합니다.

“나중에 정리해줘” 같은 모호한 음성 표현이 어떤 에이전트를 언제 트리거할지 결정하는 것이 오케스트레이터의 핵심 역할입니다. 이는 단순한 STT(Speech-to-Text) 이후의 문제가 아닙니다. 추론 레이어가 의도를 분해하고, 실행 우선순위를 결정해야 합니다.

둘째, 드리프트 통제가 텍스트보다 훨씬 중요합니다.

텍스트 기반 오케스트레이션에서는 사용자가 중간에 개입해 흐름을 수정할 수 있습니다. 음성 기반 실행에서는 사용자가 말하는 동안 이미 에이전트가 실행을 시작합니다.

최근 64개 에이전트로 대규모 코드 포팅(Bun Zig→Rust)을 진행한 사례를 보면, 병렬 에이전트 실행에서 명세(spec)와 드리프트 통제가 없으면 600줄의 PORTING.md와 적대적 리뷰 프로세스가 필요해집니다. 음성 환경에서 이 비용은 훨씬 높습니다. 사용자는 “아까 말한 것과 다른 결과가 나왔어요”를 텍스트로 수정하는 게 아니라 다시 말해야 합니다.

셋째, 음성 피드백 루프를 별도로 설계해야 합니다.

음성 에이전트는 “지금 실행 중”이라는 상태를 어떻게 전달해야 할까요? 텍스트 에이전트는 타이핑 인디케이터나 중간 메시지로 진행 상황을 보여줍니다. 음성 에이전트는 그 시간 동안 침묵하거나 진행 상황을 말로 보고해야 합니다.

Parloa가 고객센터 음성 에이전트에서 해결해야 했던 핵심 문제가 이것입니다. 병렬로 정보를 조회하는 동안 어떻게 대화 흐름을 끊지 않고 유지할 것인가. 이는 UI/UX 문제이자 오케스트레이션 설계 문제입니다.

”우리 서비스에 음성 UI를 붙이면 되지 않나요?”

이 질문이 이미 틀린 질문이 됐습니다.

음성은 UI가 아닙니다. 병렬 실행의 제어 평면입니다. 텍스트 오케스트레이션 위에 음성 입력을 얹는 것은 순차 실행 구조를 그대로 두고 인터페이스만 바꾸는 것입니다. 음성이 가진 병렬 의도 표현 능력을 버리는 설계입니다.

웨이모의 “운영 99%“는 에이전트 시대 전체에 적용됩니다. 데모를 만드는 것은 1%입니다. 그 에이전트가 예외 상황을 만나고, 병렬로 실행되고, 드리프트를 통제하면서 반복 동작하게 만드는 것이 99%입니다.

음성은 그 99%가 작동하는 표면을 바꾸고 있습니다.

지금 당신이 만드는 에이전트는 음성 명령 하나로 몇 개의 서브 에이전트를 병렬로 실행합니까?