TL;DR

LoopX는 장기 실행 AI 에이전트 작업을 위해 목표·게이트·todo·증거·쿼터·핸드오프 같은 내구 상태를 로컬에 보관하는 경량 제어 플레인입니다. Python 3.11+ 기반의 CLI로 Codex, Claude Code, Cursor 같은 런타임과 어댑터로 연동하며 에이전트 실행 자체를 대체하지 않습니다. quota 기반의 should-run 판단, 타입화된 todo 소유권, 증거 기반 writeback과 안전한 fallback을 통해 여러 턴에 걸친 작업을 재시작·검토·핸드오프하기 쉽게 만듭니다. 현재 v0.4.x는 초기 사용 가능 단계이며 운영 전 호스트 패키징·권한 경계·터미널 수용성 등을 검토할 필요가 있습니다.

핵심 포인트

• LoopX는 목표(objective), 게이트(gates), todo, 증거(evidence), 쿼터(quota), 그리고 핸드오프 상태를 경량의 내구성 있는 상태 커널에 보관하여 장기 실행 에이전트 작업의 지속성과 가시성을 유지합니다. 로컬 CLI와 프로젝트 내 .loopx 디렉터리 기반으로 상태를 읽기 우선(read-first) 방식으로 관리하며 quota should-run, todo claim/update 등의 작은 핵심 명령을 통해 다음 실행 주체를 결정합니다. 이 접근은 여러 턴에 걸친 작업을 재시작하거나 소유자를 교체할 때 발생하는 증거 소실과 범위 불일치를 줄여 주는 목적을 가집니다.
• 런타임에는 종속되지 않으며 Codex, Claude Code, Cursor 및 커스텀 러너를 어댑터/브리지로 연결할 수 있습니다. 통합 방식은 호스트 명령 레지스트리와 worker-bridge 같은 계약을 통해 에이전트가 LoopX의 quota·gate 신호를 읽고 한정된 턴을 실행하도록 하는 형태입니다. 따라서 LoopX는 에이전트 런타임을 대체하지 않고 제어판(control plane) 역할만 수행하며, 위험한 권한이나 자동 게시 권한은 인간 소유자에게 남깁니다.
• 핵심 원시(primitives)로서 타입화된 todo, claim/lease 소유권, 증거 기반 writeback, quota 기반 스케줄링과 안전한 fallback을 제공합니다. Capability가 제공자(provider)로부터 읽은 결과를 정규화하고 transition을 제안하면 Kernel이 영속 상태를 소유하는 실행-제어 흐름(Agent -> Capability -> Provider, Provider readback -> Capability transition -> Kernel)이 작동합니다. 이 구조는 반복 가능한 작업 레인(issue-fix, ml-experiment, explore 등)을 표준화해 소유자 검토와 승격/정지 결정을 명확히 남기도록 설계되어 있습니다.
• 설치 요구사항은 Python 3.11+와 macOS/Linux 셸이며 런타임 의존성은 표준 라이브러리 밖에 없습니다. curl 하나로 설치 스크립트를 실행한 뒤 loopx doctor, loopx connect, loopx status 같은 CLI를 통해 빠르게 프로젝트에 연결하고 guided start나 preset을 통해 초깃값을 구성할 수 있습니다. 스타 수와 포크 수(1103 / 78)는 커뮤니티 관심을 시사하며, v0.4.x 라인은 ‘초기 사용 가능(early but usable)’ 상태로 명시되어 있어 생산 환경 전면 도입 전 운영/패키징 경로를 검토해야 합니다.

이미지 분석