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)을 교체하지 않는다'라는 보수적인 설계로 도전한다.

TL;DR

작가는 누구인가: @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 계열은 로컬 용도로 실용 단계에 있으나, 풀 에이전트 플랫폼을 표방하는 것은 아니다.

계기는 'goal-harness'의 실험

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)만 밖으로 꺼낸다'는 분리 설계.

개념 해설: LoopX란 무엇인가

한마디로 말하면 '에이전트를 위한 로컬 칸반(Kanban) 커널로, 인간이 관리할 수 있는 경계를 정의하는 것'이다.

Before: 에이전트 루프가 안고 있는 문제

현재의 에이전트 루프는 대개 다음과 같은 구조를 가진다.

여기서의 문제는:

• 목표·판단·증거가 채팅 이력에만 남는다
• 에이전트 전환 시 문맥(Context)이 손실된다
• '다음에 무엇을 해야 할지'를 매번 인간이 재정의해야 한다
• 언제 에이전트를 멈춰야 할지에 대한 규칙이 없다

After: LoopX를 통한 루프 설계

핵심 포인트는 3가지다:

상태는 커널이 보유한다: 채팅 이력도, 에이전트의 메모리도 아닌, .loopx/ 디렉토리에 영속화된다. -
에이전트는 1턴만 실행한다: 무제한 루프가 아니라, 쿼터(Quota)로 경계가 정해진 '슬라이스(Slice)'를 실행한다. -
칸반은 프로젝션(Projection)일 뿐이다: Lark 등으로의 외부 투영은 어디까지나 표시일 뿐이며, 상태의 쓰기는 커널이 일원 관리한다.

생생한 목소리를 1차 정보의 확실성과 함께 확인하기

신뢰도: 높음 (저자 본인 및 공식 문서로 확인 완료)

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)로 구성된다.

또한, 런타임(Runtime)의 책임은 4가지로 분리된다.

• Agent: 계획 · 분석 · 도구 사용 · 1턴의 실행
• Provider: 외부 시스템 호출 및 관측 결과 반환
• Capability: 호출자를 위한 아웃컴(Outcome) 계약 · 도메인 정책 · 타입 지정 트랜지션(Typed transition) 제안
• Kernel: Todo · 게이트 · 쿼터 · 클레임 · 스케줄링의 일원 관리

실전 도구 · 설치 예시

기본 설치 (macOS / Linux)

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"

커스텀 러너(Custom runner)의 기본 틱 (5단계)

loopx quota should-run # 이 에이전트는 지금 움직여야 하는가?
loopx todo claim # 이 슬라이스(Slice)의 소유권을 획득
loopx todo update # 변경 내용을 기록
...

Claude Code 연동

/loopx <task>

명령어를 사용한 후, /loop로 LoopX가 게이트(Gate)하는 네이티브 루프(Native loop)를 기동한다.

소스 코드와 문서는 github.com/huangruiteng/loopx 에서 공개되어 있다 (MIT 라이선스). 사용자 매뉴얼은 Feishu/Lark 상에 공개되어 있다 (영어 · 중국어).

주의사항: 만능이 아닌 이유

1. 「오래 작동시키는 것」 자체가 목적은 아니다

공식 문서에서는 명시적으로 경고하고 있다. "상태(state) 없이 길게 루프를 돌리면 드리프트(drift)만 커질 뿐이다. 프로덕트는 지속적인 백그라운드 동작이 아니라, 복구 가능한 작업이다". LoopX를 도입하더라도 목표 설계가 허술하다면 문제는 해결되지 않는다.

2. 프로덕션 컨트롤러(Production Controller)가 아니다

README 상의 "LoopX is not an autonomous production controller"라는 기술은 명시적인 제약 사항이다. 위험한 권한 부여, 프로덕션 데이터 쓰기, 공개 작업 실행은 여전히 인간이 담당해야 한다.

3. 채팅 이력의 대체재가 아니다

"요약이 writeback(쓰기 작업)을 대신할 수 있다"는 함정(pitfall)이 공식적으로 기재되어 있다. 루트(Route)·할 일(Todo)·게이트(Gate)·교훈·우선순위가 채팅창에만 존재하는 상태라면, 다음 에이전트가 이를 놓칠 가능성이 높다. LoopX를 도입하더라도 상태를 적절히 기록하는 운영 습관이 필요하다.

4. 성숙도에 대한 과신 주의

v0.4.x 계열은 로컬 이용으로서 실용 단계로 간주되지만, 공식 Release Readiness 문서에서는 "상태와 CLI의 컨트랙트(contract)가 안정된 코어"이며, 호스트 연동의 일부는 옵션·기본값 Off·실험적 단계라고 명시하고 있다. 프로덕션 워크플로우로의 통합에는 단계적인 접근 방식이 권장된다.

5. 벤치마크 결과의 해석

"Auto ML 200시간 루프" 등의 실적은 연속된 계산 시간(computation time)의 주장이 아니라 경과 시간(wall-clock time)임을 명시하고 있다. 저자 스스로 벤치마크 점수의 개선을 증거로 받아들이기보다, "장기 실행 에이전트 작업의 검사·조종·복구·비교가 용이해진다"는 제한적인 주장으로 받아들여야 한다고 언급했다.

요약

• LoopX는 "에이전트 런타임(Agent Runtime)을 대체하지 않고, 세션을 넘나드는 상태 관리(state management)를 제공하는" 로컬 컨트롤 플레인(control plane)이다.
• 핵심은 6레이어의 내구 상태 커널(durable state kernel)과 "쿼터(quota)·게이트(gate)·클레임(claim)"을 통한 경계 설계에 있다.
• Codex / Claude Code / Cursor 등 기존 런타임과의 연동을 전제로 하며, 단독으로는 동작하지 않는다.
• "오래 작동시키는 것"보다 "인간이 관리할 수 있는 상태로 계속 작동시키는 것"이 설계 철학의 핵심이다.
• v0.4.x 단계에서는 실용적이지만, 자율적인 프로덕션 제어를 표방하는 것이 아니므로 용도와 한계를 이해한 후 사용해야 한다.

관련 기사

참고 링크

• huangruiteng/loopx — GitHub (공식 리포지토리)
• Loop Engineering Principles and Pitfalls (공식 문서)
• Architecture (공식 문서)
• LoopX 공식 홈페이지
• 사용자 매뉴얼 (Feishu/Lark)
• Discord 커뮤니티

게시물은 개인적인 견해이며, 소속 조직을 대표하지 않습니다.

Discussion