기술 요약: TypeGo: 체화된 에이전트를 위한 OS 런타임

문제 정의

본 논문은 현재의 거대 언어 모델(LLM) 기반 제어 방식과 실시간 물리적 상호작용 요구사항 사이의 근본적인 불일치를 지적한다. LLM을 동기식 요청/응답 오라클(oracle)로 취급하여 크리티컬 패스(critical path)에 배치하는 것은 세 가지 주요 시스템 문제를 야기한다:

1. 지연 시간 대 품질 (Latency vs. Quality): LLM 추론은 실시간 반응을 하기에는 너무 느리며(이로 인해 동작 사이에 일시 정지 발생), 소형 모델은 계획(planning) 능력이 부족하다.
2. 동시성 및 자원 중재 (Concurrency and Resource Arbitration): 현실 세계의 에이전트는 여러 경쟁하는 목표(예: 통신을 하면서 순찰하기)를 처리해야 하며 물리적 액추에이터를 공유해야 한다. 기존의 LLM 문헌들은 선점(preemption) 및 자원 중재라는 고전적인 OS 문제들을 대부분 회피해 왔다.
3. 반사적 규칙 (Reactive Rules): 단발성 자연어 지시는 목표를 정의하는 데는 유용하지만, LLM 호출 주기보다 빠르게 실행되어야 하는 빠른 반응 규칙(예: "물체가 0.2m 이내에 있으면 뒤로 물러나기")을 포착하지 못한다.

모놀리식 플래너(전체 시퀀스를 한 번에 계획)든 단계별 플래너(동작마다 쿼리 수행)든, 현재의 접근 방식들은 높은 초기 지연 시간이나 실행 중 빈번한 스태킹(stalling) 문제를 겪는다.

방법론: TypeGo 런타임

저자들은 TypeGo를 제안한다. 이는 에이전트의 제어 루프를 순차적인 LLM 쿼리 루프가 아닌, 지속적으로 실행되는 비동기 시스템으로 취급하는 운영체제 스타일의 런타임이다. 이 아키텍처는 전통적인 OS 설계와 구조적 유사성을 가진 4개의 비동기 계획 계층(S0–S3)과 Skill Kernel 위에서 구축되었다(표 1 참조).

핵심 아키텍처 구성 요소

1. Skill Kernel (자원 관리자):

   • OS 커널 역할을 수행하며, 타입화된 물리적 서브시스템(예: MOVEMENT, SOUND, DEFAULT)에 대한 접근을 중재한다.
   • 배타적 권한(예: 한 번에 하나의 프로세스만 이동 제어 가능)과 공유 자원에 대한 직렬화를 강제한다.
   • 유계 중단 기술 (Bounded-interruption skills): 기술(skill)은 제한된 시간 $t_s$ 내에 일시 중지되거나 정지될 수 있어, 깔끔한 선점과 상태 복구를 지원한다.

2. 프로세스 추상화 (Process Abstraction):

   • 각 작업(사용자 지시 또는 행동 가이드라인)은 계획 상태, 이력, 상태를 포함하는 프로세스 제어 블록(PCB)을 가진 **프로세스(Process)**로 인스턴스화된다.
   • 출처 의존적 재개 (Source-Dependent Resumption): 수치적 우선순위 스케줄러와 달리, TypeGo는 중단 후 복귀(원래 프로세스가 재개되는 반응적 우회)와 복귀 없는 교체(기존 목표를 영구적으로 대체하는 새로운 사용자 지시)를 구분한다.

3. 4계층 비동기 계획 루프:

   • S3 (프로세스 스케줄러): 가장 느린 계층. 프로세스의 생명주기를 관리하고, 의미론적 가이드라인과 관측치를 바탕으로 어떤 프로세스를 실행할지 결정하며, 선점 로직을 처리한다.
   • S2 (태스크 분해기): 상위 수준의 태스크를 순서가 있는 하위 태스크와 글로벌 이벤트 트리거(조건/응답 쌍)로 분해한다. 주기적으로 이력을 재검토하여 계획을 업데이트한다.
   • S1 (액션 플래너 / 스트리머): 투기적(speculative) 계층. 하위 태스크를 기술 호출(skill calls)의 스트림으로 변환한다. 결정적으로, 현재 단계가 실행되는 동안 미래의 단계를 투기적으로 생성하기 위해 **유계 큐(bounded queue)**를 사용하여 계획 지연 시간을 실행과 중첩시킨다.
   • S0 (반사 계층): 가장 빠른 계층 (100 Hz). 자연어 반사로부터 컴파일된 Python 조건/액션 쌍을 실행한다. 가장 높은 우선순위를 가지며, 경합 중인 서브시스템을 점유하고 있는 모든 프로세스를 중단시킬 수 있다.

4. 프로그래밍 추상화:

   • 처방 (Prescriptions): 자연어 입력. *태스크(Tasks)*는 온라인 플래너(S1–S3)로 라우팅되며, *반사(Reflexes)*는 고주파 S0 핸들러로 오프라인 컴파일된다.
   • 관측 (Observations): 모든 플래너에 노출된 구조화된 연속 데이터 스트림(예: 객체 탐지).
   • 기술 (Skills): 개발자가 작성한(LLM이 합성하는 것이 아닌) 호출 가능한 프리미티브(primitives)로, 저수준 로봇 동작을 구현한다.

주요 기여

1. 체화된 에이전트를 위한 OS 스타일 런타임: 본 논문은 에이전트가 CPU가 하드웨어를 관리하는 것과 같이 동시성, 지연 시간, 자원 중재를 관리할 수 있도록 계획과 실행을 분리하는 런타임 설계를 도입했다.
2. 투기적 기술 스트리밍 (Speculative Skill Streaming): 기술 호출의 룩어헤드(look-ahead) 큐를 유지함으로써, LLM의 계획 지연을 진행 중인 동작 뒤로 숨겨, 다음 계획을 기다리지 않고도 연속적인 실행을 가능하게 한다.
3. 의미론적 스케줄링 (Semantic Scheduling): 스케줄러(S3)는 고정된 수치적 우선순위가 아닌 요청의 출처(사용자 vs. 반응적 가이드라인)에 따라 선점 결정을 내려, 중단된 작업을 자동 재개하는 것과 같은 미묘한 동작을 가능하게 한다.
4. 제1 매체로서의 자연어: 시스템은 비전문가가 상위 수준의 목표와 저지연 반응 규칙을 모두 작성할 수 있게 하며, 시스템은 이를 적절한 지연 시간 계층(S0 vs. S1–S3)으로 자동 라우팅한다.

예비 결과

저자들은 Kalos(Unitree Go2 사족 보행 로봇)에서 TypeGo를 ReAct(단계별 계획) 및 Plan-and-Execute (PAE)(모놀리식 계획)와 비교하여 평가하였다.

• 응답성:
  • 첫 동작 시간 (Time-to-First-Action, TTFA): TypeGo는 PAE 대비 73%, ReAct 대비 40% 감소된 TTFA를 기록했다. 이는 상위 플래너가 숙고하는 동안 S1을 통해 즉각적인 액션을 방출함으로써 달성되었다.
  • 단계당 지연 (Per-Step Delay): TypeGo는 액션 완료와 다음 계획 쿼리 사이의 "스톨(stall)" 현상을 제거함으로써 ReAct 대비 단계당 지연을 50% 줄였다.
• 효과성:
  • TypeGo는 복합적이고 장기적인 과업을 성공적으로 처리했으며, 경로가 차단되었을 때도 (PAE가 무한히 대기하는 것과 달리) 유연하게 대응했다.
  • 글로벌 플랜(예: 검색 전 복도로 이동)이 필요한 특정 작업에서는 PAE가 TypeGo보다 우수한 성능을 보였는데, 이는 단계별 계획이 국소적으로 유망한 행동에 편향될 수 있다는 점을 시사한다.
• 동시성:
  • 시스템은 동시 작업(예: 순찰하며 질문에 답하기)과 반사(예: 장애물 회피)를 성공적으로 관리했다.
  • 오버헤드: 스케줄링 오버헤드는 완만했다 (S3 스케줄링에 약 200ms, S0 반사 핸들링에 약 50ms). 주요 비용은 여러 비동기 루프로 인한 토큰 사용량이며, 이는 응답성과 계산 비용 사이의 트레이드오프를 나타낸다.

의의 및 주장

본 논문은 TypeGo를 완성된 운영체제가 아니라, 체화된 에이전트가 동시성, 지연 시간, 자원 중재를 관리하기 위해 OS 스타일의 런타임이 필요하다는 가설을 검증하는 **개념 증명 프로토타입(proof-of-concept prototype)**으로 위치시킨다.

• 초점의 전환: 저자들은 "어떻게 움직일 것인가"(저수준 제어)에서 "어떻게 결정할 것인가"(의사결정 아키텍처)로 난제가 이동했다고 주장한다.
• 직교성 (Orthogonality): 이 설계는 단순히 단일 LLM 호출을 가속화하려는 노력과는 별개의 것이다. 대신, 투기와 계층적 디스패치를 통해 크리티컬 패스에서 LLM 지연을 숨기는 것을 목표로 한다.
• 향후 방향: 본 논문은 메모리를 다음 핵심 프리미티브로 식별하며, 장기적이고 적응적인 에이전트를 지원하기 위해 파일 시스템 및 가상 메모리와 유사한 메모리 계층(M0–M3+)을 구상한다. 또한, 토큰 예산과 네트워크 제약을 관리하기 위한 더 풍부한 자원 격리 모델과 비용 인식 런타임 정책을 촉구한다.

이 연구는 에이전트를 선형 스크립트가 아닌 멀티태스킹 OS 프로세스로 취급하는 것이 역동적인 환경에서 실시간 응답성과 적응성을 크게 향상시킨다는 것을 입증한다.