현재 GitHub에서는 멀티 에이전트 워크플로우가 대세를 이루고 있습니다. 개발자들은 대규모 언어 모델을 서로 연결하고, 각 에이전트에 좁은 전문 분야를 할당하며, 단일 모델로는 처리할 수 없는 작업을 해결하기 위해 그 출력값들을 오케스트레이션(orchestration)하고 있습니다. 결과는 인상적일 수 있습니다. 한 에이전트는 조사하고, 다른 에이전트는 초안을 작성하며, 세 번째 에이전트는 사실 관계를 확인하고, 네 번째 에이전트는 최종 출력을 형식에 맞게 정리합니다. 하지만 이러한 모든 조정 과정 아래에는 취약한 의존성이 숨어 있습니다. 인간의 입력을 기계가 읽을 수 있는 명령어로 변환하는 첫 번째 단계가 느리거나 부정확하면 전체 체인이 무너집니다. 다운스트림 에이전트는 잘못된 데이터(garbage)를 수정할 수 없습니다. 단지 그것을 전파할 뿐입니다.

이 병목 현상을 해결하기 위해 Iflytek/domux가 등장합니다. 이는 정확히 하나의 중요한 작업, 즉 빠른 명령 이해를 위해 구축된 오픈 소스 모델입니다. 에세이를 생성하거나 개방형 대화를 나누는 대신, domux는 자연어를 파싱하여 다른 에이전트가 즉시 사용할 수 있는 엄격하고 구조화된 데이터를 내보냅니다. 스마트 홈 허브부터 산업용 제어 패널에 이르기까지 실시간 구조화된 입력이 필요한 모든 시스템이 이를 인지 레이어(perception layer)로 사용할 수 있습니다.

체인의 가장 약한 고리

사용자가 "여기 좀 더 밝게 해줘"와 같은 간단한 명령을 내릴 때 어떤 일이 발생하는지 생각해 보십시오. 멀티 에이전트 설정에서 이 발화는 조명 컨트롤러, 에너지 모니터, 보안 로거를 거쳐야 할 수도 있습니다. 만약 초기 파서가 "사용자가 더 많은 빛을 원함"과 같이 모호한 문장을 반환한다면, 이후의 모든 에이전트는 그 의미를 다시 해석해야 합니다. 어떤 에이전트는 정확한 매개변수를 기다리며 멈춰 설 수도 있고, 다른 에이전트는 방이나 밝기 수준을 추측하다가 틀릴 수도 있습니다. 결국 워크플로우는 중단됩니다.

지연 시간(Latency)은 문제를 더욱 악화시킵니다. 진입점에서 수백 밀리초의 파싱 지연이 추가되면, 정보가 세 번째 에이전트에 도달할 때쯤 시스템은 이미 고장 난 것처럼 느껴집니다. 실시간 환경은 느린 시작을 용납하지 않습니다. 개발자들은 오케스트레이션 프레임워크가 아키텍처 다이어그램상으로는 아름다워 보이지만, 모호하거나 느린 입력이 들어오면 무너진다는 사실을 깨닫고 있습니다. 워크플로우의 나머지 부분이 사고를 시작하기도 전에 명령을 표준화하는 전용 레이어가 필요합니다.

Domux는 바로 그 레이어가 되도록 설계되었습니다. Domux는 난잡한 인간의 언어를 받아들여 다운스트림 에이전트가 그라운드 트루스(ground truth)로 취급할 수 있는 깔끔한 스키마로 변환합니다.

속도, 구조, 그리고 정확도

이 프로젝트는 실제 운영 환경의 동작에 직접적인 영향을 미치는 세 가지 특징을 내세웁니다.

첫째, 150밀리초 미만으로 응답합니다. 이 임계값은 매우 중요합니다. 대화형 환경에서 0.25초 미만의 응답은 즉각적인 것처럼 느껴지지만, 1초에 가까워지면 사용자는 도구 사용을 포기하게 됩니다. 입력이 음성이든 채팅 인터페이스든, domux는 파이프라인을 계속 작동하게 유지합니다.

둘째, 입력을 엄격한 7개 필드 스키마로 매핑합니다. 다운스트림 시스템이 해독해야 할 자유 형식의 텍스트는 없습니다. 모든 명령은 예측 가능한 열(column)에 배치됩니다.

셋째, 98.37%의 정확도와 100%의 형식 준수(format compliance)를 주장합니다. 정확도는 모델이 대개 사용자를 올바르게 이해한다는 것을 의미합니다. 형식 준수는 출력이 매번 구조적으로 유효함을 의미합니다. 정확도가 99%라 하더라도 가끔 필드를 누락하거나 새로운 필드를 만들어내는 파서는 자동화된 체인에서 위험 요소가 됩니다. 잘못된 형식의 행 하나가 소비자 에이전트를 중단시킬 수 있기 때문입니다.

실제 출력 결과는 다음과 같습니다. 모델이 명령을 처리하면 파이프 구분자(pipe-delimited)로 된 레코드를 반환합니다:

action|device|attribute|value|unit|room|floor
turnOn|light|brightness|80|percent|living room|ground floor

이 형식은 의도된 것입니다. 파이프 구분자 텍스트는 무거운 의존성 없이도 어떤 프로그래밍 언어에서든 파싱하기가 매우 쉽습니다. JSON의 비대함(bloat)과 중첩된 직렬화(nested serialization)로 인한 지연을 피할 수 있습니다. 조명 에이전트는 action과 device 열을 읽고 즉시 동작할 수 있습니다. 로깅 에이전트는 별도의 추론 과정을 거치지 않고도 room과 floor를 추출할 수 있습니다. 이 구조는 설계 단계부터 모호성을 제거합니다.

난잡한 인간의 의도 처리하기

실제 사람들은 API 문서처럼 말하지 않습니다. "좀 더 밝게 해줘" 또는 "여기 좀 따뜻하게 해줘"라고 말합니다. 취약한 파서는 이런 상황에서 실패할 것입니다. Domux는 의도를 조정 동작(adjustment action)으로 매핑하고, 정확한 값은 다운스트림 시스템이 결정하도록 하여 모호성을 처리합니다. 누군가 "좀 더 밝게 해줘"라고 말하면, 모델은 해당 동작을 밝기 증가로 식별합니다. 구체적인 수치 레벨은 현재 측정값, 시간대 또는