Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
LoopX는 장기 실행 AI 에이전트를 위한 로컬 컨트롤 플레인(Control Plane)입니다. 기존 에이전트 런타임을 유지하면서 목표, 게이트, 상태 등을 별도의 커널로 관리하여 인간이 에이전트의 작업 범위를 제어할 수 있게 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기
MIT 라이선스로 이용 가능 (https://github.com/huangruiteng/loopx/blob/main/docs/assets/control-plane-board.svg)
Keep the loop moving. Keep the judgment human.
AI 코딩 에이전트는 '하나의 태스크를 하나의 세션에서 끝내는 것'에는 능숙하다. 하지만 현실의 개발은 다르다. 목표는 변하고, 인간의 판단이 필요하며, 증거(Evidence)는 노후화되고, 여러 에이전트가 동일한 태스크를 두고 경쟁한다. 채팅 이력과 타이머만으로는 그 복잡성을 도저히 제어할 수 없다.
역설적인 것은, 에이전트가 똑똑해질수록 '어디까지 무엇을 하게 할 것인가'라는 제어(Control) 문제가 심각해진다는 점이다. LoopX는 이 문제에 대해 '에이전트 런타임(Agent Runtime)을 교체하지 않는다'라는 보수적인 설계로 도전한다.
작가는 누구인가: @huangruiteng (GitHub).
2026년 5월 31일에 공개, 같은 해 6월에 'goal-harness'에서 개명. v0.4.2 시점에서 스타 수 3.1k, Trendshift 진입. -
무엇을 만들었나: 장기 실행 AI 에이전트용 로컬 컨트롤 플레인(Control Plane). 목표(Goal), 게이트(Gate), Todo, 스코프(Scope), 증거(Evidence), 쿼터(Quota)를 하나의 상태 커널(State Kernel)로 관리한다. -
본질은 무엇인가: '에이전트 런타임(Codex / Claude Code / Cursor)은 그대로 계속 사용하면서, 세션을 넘나드는 상태를 인간이 확인·수정할 수 있는 형태로 영속화한다'는 사상. -
대응하는 런타임: Codex App / Codex CLI / Claude Code / OpenCode / Pi / TraeX / 커스텀 쉘 등 10종 이상. Python 3.11+ 지원, 런타임 의존성 없음. -
주의사항: 자율형 프로덕션 컨트롤러가 아니다. 위험한 권한 부여, 운영 환경(Production) 쓰기, 공개 작업은 계속해서 인간이 담당한다. -
현재 위치: v0.4.x 계열은 로컬 용도로 실용 단계에 있으나, 풀 에이전트 플랫폼을 표방하는 것은 아니다.
2026년 5월 31일, @huangruiteng이 GitHub에 리포지토리를 공개했다. 당초 이름은 'goal-harness'였다. 몇 주간의 실험을 거쳐 6월 21일에 'LoopX'로 개명되었다.
배경에 깔린 문제의식은 명확하다. Codex나 Claude Code와 같은 에이전트는 단일 세션 내에서의 완결을 전제로 설계되어 있다. 하지만 며칠에 걸친 엔지니어링 목표, 지속적인 오픈 소스 기여 활동, AutoML 실험 관리와 같은 '라이프타임 골(Lifetime Goal)'은 그 틀에 담기지 않는다.
유사한 문제의식은 과거에도 존재했다.
Langchain / AutoGPT 시대 (2023년경): 에이전트를 '반복해서 구동하는 것'에 대한 관심. 다만 상태의 외부화는 미비했음. -
Agentive / CrewAI (2024~2025년): 다중 에이전트 협업에 대한 시도. 다만 '인간이 개입하는 지점'의 설계는 모호한 채 구현된 경우가 많음. -
LoopX (2026년): '에이전트 런타임에는 손을 대지 않고, 상태 커널(State Kernel)만 밖으로 꺼낸다'는 분리 설계.
한마디로 말하면 '에이전트를 위한 로컬 칸반(Kanban) 커널로, 인간이 관리할 수 있는 경계를 정의하는 것'이다.
현재의 에이전트 루프는 대개 다음과 같은 구조를 가진다.
여기서의 문제는:
핵심 포인트는 3가지다:
상태는 커널이 보유한다: 채팅 이력도, 에이전트의 메모리도 아닌, .loopx/ 디렉토리에 영속화된다. -
에이전트는 1턴만 실행한다: 무제한 루프가 아니라, 쿼터(Quota)로 경계가 정해진 '슬라이스(Slice)'를 실행한다. -
칸반은 프로젝션(Projection)일 뿐이다: Lark 등으로의 외부 투영은 어디까지나 표시일 뿐이며, 상태의 쓰기는 커널이 일원 관리한다.
LoopX의 README로부터:
"Chat memory and a timer are not enough to govern that."
(출처: huangruiteng/loopx README)
「Loop Engineering Principles and Pitfalls」 문서(공식 리포지토리 내 docs/product/foundations/)에서 저자의 설계 사상이 가장 단적으로 나타난 구절을 요약한다. 정적인 프롬프트(Prompt)는 짧은 태스크에는 충분하지만, 장기 실행되는 루프 에이전트(Loop Agent)에는 목표 상태(Goal state), 사용자 게이트(User gate), 할 일(Todo), 클레임(Claim), 스코프(Scope), 에비던스(Evidence), 실행 이력(Execution history), 쿼터(Quota), 핸드오프(Handoff)를 배치할 수 있는 내구성 있는 장소가 필요하며, "채팅 메모리는 컨트롤 플레인(Control plane)이 아니다"라고 명시되어 있다. (출처: 해당 문서, 확인 완료)
공식 문서(docs/architecture.md, 확인 완료)에는 턴(Turn) 계약의 타입 지정 어휘(Typed vocabulary)로서 LoopXTurnRoute(실행 전)와 LoopXTurnResultKind(실행 후)라는 두 개의 enum이 정의되어 있으며, "deliver/wait/ask/replan"과 같은 산문적인 표현이 아니라 코드상에서 다룰 수 있는 타입(Type)으로서 의사결정을 표현하고 있음을 확인할 수 있다.
LoopX의 컨트롤 플레인(Control plane)은 6개의 내구 레이어(Durability layer)로 구성된다.
| 레이어 | 역할 |
|---|---|
| Registry | 알려진 목표(Goal), 해당 리포지토리, 어댑터(Adapter), 권한 소스, 상태, 가드(Guard)를 목록화 (.loopx/registry.json) |
| Goal state | 하나의 목표에 대한 활성 상태 파일 (ACTIVE_GOAL_STATE.md) |
| Run log | 목표마다 저장되는 JSON 및 Markdown 리포트 |
| Run history | 에이전트, 하트비트(Heartbeat), UI가 소비하는 컴팩트한 인덱스 |
| Status / attention queue | "다음에 누가 움직여야 하는가"에 대한 퍼스트 뷰(First view) 요약 |
| Compute quota | 각 목표가 자동 에이전트 컴퓨팅을 얼마나 소비할 수 있는지에 대한 로컬 정책 (Duty cycle 0.0–1.0) |
또한, 런타임(Runtime)의 책임은 4가지로 분리된다.
curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctor
cd /path/to/your-project
loopx connect
loopx status
loopx start-goal --guided --project . --goal-text "Your long-running objective"
loopx quota should-run # 이 에이전트는 지금 움직여야 하는가?
loopx todo claim # 이 슬라이스(Slice)의 소유권을 획득
loopx todo update # 변경 내용을 기록
...
/loopx <task>
명령어를 사용한 후, /loop로 LoopX가 게이트(Gate)하는 네이티브 루프(Native loop)를 기동한다.
소스 코드와 문서는 github.com/huangruiteng/loopx 에서 공개되어 있다 (MIT 라이선스). 사용자 매뉴얼은 Feishu/Lark 상에 공개되어 있다 (영어 · 중국어).
공식 문서에서는 명시적으로 경고하고 있다. "상태(state) 없이 길게 루프를 돌리면 드리프트(drift)만 커질 뿐이다. 프로덕트는 지속적인 백그라운드 동작이 아니라, 복구 가능한 작업이다". LoopX를 도입하더라도 목표 설계가 허술하다면 문제는 해결되지 않는다.
README 상의 "LoopX is not an autonomous production controller"라는 기술은 명시적인 제약 사항이다. 위험한 권한 부여, 프로덕션 데이터 쓰기, 공개 작업 실행은 여전히 인간이 담당해야 한다.
"요약이 writeback(쓰기 작업)을 대신할 수 있다"는 함정(pitfall)이 공식적으로 기재되어 있다. 루트(Route)·할 일(Todo)·게이트(Gate)·교훈·우선순위가 채팅창에만 존재하는 상태라면, 다음 에이전트가 이를 놓칠 가능성이 높다. LoopX를 도입하더라도 상태를 적절히 기록하는 운영 습관이 필요하다.
v0.4.x 계열은 로컬 이용으로서 실용 단계로 간주되지만, 공식 Release Readiness 문서에서는 "상태와 CLI의 컨트랙트(contract)가 안정된 코어"이며, 호스트 연동의 일부는 옵션·기본값 Off·실험적 단계라고 명시하고 있다. 프로덕션 워크플로우로의 통합에는 단계적인 접근 방식이 권장된다.
"Auto ML 200시간 루프" 등의 실적은 연속된 계산 시간(computation time)의 주장이 아니라 경과 시간(wall-clock time)임을 명시하고 있다. 저자 스스로 벤치마크 점수의 개선을 증거로 받아들이기보다, "장기 실행 에이전트 작업의 검사·조종·복구·비교가 용이해진다"는 제한적인 주장으로 받아들여야 한다고 언급했다.
게시물은 개인적인 견해이며, 소속 조직을 대표하지 않습니다.
