루프의 다음 병목은 상태다 — 루프가 스스로 만든 도구, LoopX

깃허브에서 이런 숫자를 만나면 잠깐 멈추게 된다. 저장소 생성 2026년 5월 31일. 오늘까지 10주. 커밋 4,037개, PR 번호는 #2867까지 갔고, 어제 하루에만 PR 30개가 머지됐다. 사람 손의 속도가 아니다. 그리고 이 저장소의 공식 쇼케이스 문서에는 이렇게 적혀 있다 — 이 repo 자체가 이 도구의 루프로 개발되고 있다고.

LoopX다. 바이트댄스 AML 엔지니어가 만든 오픈소스로, 스스로를 “장시간 실행 에이전트를 위한 상태 커널”이라고 부른다. 스타는 10주 만에 3,400개를 넘겼다. #25에서 loop engineering이라는 말의 절반은 재탕이고 절반은 진짜라고 썼는데, 그 진짜 절반 — 바깥 루프, 정지조건, 사람의 판단 — 이 제품으로 넘어오면 어떤 모양이 되는지는 이 물건을 보면 안다.

말이 먼저 생기고, 6주 뒤 구현체가 나왔다

타임라인이 재미있다. 이 저장소는 5월 31일에 “goal-harness scaffold”라는 밋밋한 이름으로 시작했다. 그리고 6월, Boris Cherny(Claude Code 창시자)의 “이제 Claude에 프롬프트를 안 쓴다, Claude에 프롬프트하는 루프를 쓴다”는 발언이 바이럴을 탔고 Addy Osmani가 정리 에세이를 썼고, Slashdot이 “프롬프트 엔지니어링은 잊어라”라고 받았다. 저장소가 LoopX라는 이름으로 개명한 날이 6월 21일 — 바이럴이 정점을 찍던 바로 그 주다. repo topics에 loop-engineering을 박고, 첫 화면에 “Keep the loop moving. Keep the judgment human”을 걸었다.

버즈워드에 올라탄 것 아니냐고 물으면, 절반은 맞다. 그런데 #25 때와 같은 구도다 — 이름은 마케팅이어도 까보면 실체가 있는지가 문제다. 그래서 까봤다.

실체: 루프가 아니라, 루프 사이에 살아남는 상태

LoopX가 파는 건 에이전트 프레임워크가 아니다. README 스스로 “런타임을 대체하지 않는다”고 못박는다. Codex든 Claude Code든 Cursor든, 일하는 건 기존 에이전트다. LoopX가 쥐는 건 한 턴이 끝나고 다음 턴이 시작될 때까지 살아남아야 하는 것들이다. 문제 정의가 정확하다.

에이전트는 한 세션에서 task를 끝낼 수 있다. 장시간 작업은 다르다. 목표가 바뀌고, 오너의 결정이 필요해지고, 증거가 낡고, 에이전트가 동료에게 일을 넘기고, 스케줄러는 유용한 전이가 남아 있지 않은데도 돈을 계속 쓴다. 채팅 메모리와 타이머로는 이걸 다스릴 수 없다.

그래서 상태를 다섯 개의 질문으로 접는다. 지금 목표가 뭔가(objective와 scope). 다음에 뭘 하나(순서 있는 todo와 소유권). 뭐가 사람의 판단을 기다리나(구체적인 user gate). 무슨 증거가 바뀌었나(run history와 writeback). 루프가 계속 돌아도 되나(쿼터와 정지조건). 에이전트가 한 턴을 돌 때마다 이 다섯 질문에 답이 갱신되고, 그 답이 채팅 로그가 아니라 프로젝트의 .loopx/ 상태로 남는다.

핵심 사이클은 다섯 명령이 전부다.

loopx quota should-run      # 이 에이전트가 지금 움직여도 되나?
loopx todo claim            # 이 조각은 누가 소유하나?
loopx todo update           # 뭐가 바뀌었나?
loopx refresh-state         # 다음 턴은 뭘 봐야 하나?
loopx quota spend-slot      # 검증된 조각만 예산에서 차감

#25에서 무인 루프의 진짜 난제는 시작이 아니라 멈춤이라고 썼다. LoopX의 답이 흥미로운 건 정지조건을 프롬프트가 아니라 타입 있는 상태 객체로 만들었다는 점이다. 세 가지가 특히 그렇다.

첫째, 게이트가 구체적인 질문이다. “오너 승인 대기 중” 같은 모호한 상태 대신, 사람에게 던질 질문을 게이트에 박아 둔다. 판단이 필요하면 루프는 구체적으로 묻고 기다린다. 한 레인이 게이트에 막혀도, 별도로 감사된 안전한 우회 작업은 계속 돌 수 있다 — 단 게이트를 우회해서는 안 된다.

둘째, 쿼터가 검증과 묶여 있다. 자동 턴은 반드시 쿼터 확인부터 하고, 예산 차감은 검증된 writeback 뒤에만 붙는다. 조용히 스킵한 턴, preflight 실패, dry-run은 예산을 쓰지 않는다. “스케줄러가 유용한 전이 없이 돈을 계속 쓴다”는 무인 루프의 고전적 사고를, 회계 규칙으로 막는 설계다.

셋째, 에이전트가 피어다. 리더 에이전트가 없다. 등록된 에이전트들이 claim과 lease로 todo 조각의 소유권을 잡고, 능력과 쿼터가 누가 다음에 움직일지를 정한다. #49에서 다룬 크로스 에이전트 협업의 소유권·핸드오프 문제를, 대화가 아니라 상태로 푸는 접근이다.

README가 제안하는 비유는 “에이전트 네이티브 칸반”이다. 카드가 신원·권한·증거·계속 조건을 들고 다니고, 칸반 보드는 투영일 뿐 진실은 상태 커널에 있다. 파이썬 표준 라이브러리만 쓰고 외부 의존성이 없고 MIT다.

메타사례: 루프가 자기 도구를 만든다

여기까지면 잘 설계된 신생 도구 하나다. 이 저장소가 소재로 흥미로워지는 건 다음 지점부터다. LoopX는 LoopX의 루프로 개발되고 있고, 그걸 커밋으로 증명하는 공식 문서가 있다.

쇼케이스 카탈로그의 셀프 이터레이션 케이스를 보면, 공개 첫 19.6일 동안 커밋 801개, 6월 19일 하루에만 공개 커밋 74개가 찍혀 있다. 그 속도로 벤치마크 어댑터, 컨트롤 플레인 수정, 대시보드, 공개 문서가 같은 창에서 움직였다. 저장소의 AGENTS.md는 사람이 아니라 에이전트에게 쓴 작업 규정집이다 — 깨끗한 worktree에서만 작업하라, git add .를 쓰지 마라, 커밋은 리뷰어 논리로 쪼개라, 자가 머지는 이런 조건에서만 하라. #18에서 “AI로 개발된 도구”를 메타사례로 다뤘는데, 이건 그보다 한 바퀴 더 돈다. 루프를 관리하는 도구가, 자기가 관리하는 루프의 산출물이다.

그 흔적은 코드에도 남아 있다. 루트 패키지에 모듈이 100개 넘게 깔려 있고, benchmark_ledger.py는 150KB, status.py는 124KB짜리 단일 파일이다. 사람이 짰다면 리뷰에서 반려됐을 구조가, 에이전트 루프의 산출물에서는 그냥 쌓인다. 10주짜리 코드베이스가 이미 이 모양이라는 건, 에이전트 생산 속도가 코드베이스 위생을 앞지른다는 #31의 명제가 저장소 하나에 압축돼 있다.

가장 묘한 건 README의 문체다. 이 문서는 자기 주장에 증거 등급을 스스로 붙인다. “200시간+ 루프”를 자랑한 문단 바로 뒤에 “이건 벽시계 기준 경과 시간이지, 모델이 200시간 연속 실행됐다는 뜻이 아니다”라고 적는다. 사용자 사례에는 “귀속과 토큰 규모는 사용자 보고일 뿐”이라고 달고, 스타 히스토리 차트에는 “깃허브 공식 타임스탬프에서 6시간마다 생성되며, 현재 스타 수와 일치할 때만 발행된다”는 각주가 붙는다. 처음엔 변호사가 썼나 싶었는데, 저장소를 보면 답이 나온다. 발행 전에 loopx check --scan-path README.md를 돌리는 공개/비공개 경계 검사가 파이프라인에 들어 있다. 증거 규율이 문서 스타일이 아니라 제품의 게이트다. 자기 마케팅 문서에 자기 검증기를 물렸다.

경고 신호도 같은 자리에서 나온다. 커밋 로그에는 “verified star history 발행”, “컨트롤 플레인 서사 다듬기”, “public launch readiness” 같은 항목이 즐비하다. 루프에 내구성 있는 목표를 주면 루프는 그걸 집요하게 최적화하는데, 이 저장소에서는 성장 자체가 루프의 목표로 들어가 있다. 스타 3,400개 중 얼마가 제품이고 얼마가 유행의 파도인지는 아직 갈리지 않았다. 버전은 아직 v0.4.x다. 검증된 건 “만든 사람이 잘 쓰고 있다”까지다. 독립 사용자 사례 세 건이 README에 올라 있지만, 그 문서조차 “사용자 보고”라는 라벨을 스스로 붙이고 있다.

내장 /loop 시대에 서드파티 커널이 필요한가

실전 질문으로 내려오자. Claude Code에는 이미 /loop과 워크플로우가 있고, Codex 앱에는 자동화가 있다. 하네스가 루프 기능을 내장하기 시작한 시대에, 바깥에 상태 커널을 따로 두는 게 언제 말이 되나.

LoopX 문서의 Claude Code 연동 항목에 힌트가 있다 — “네이티브 /loop을 LoopX가 게이트한다”. 루프를 도는 건 하네스고, 돌아도 되는지를 판정하는 층이 따로 있다. 이 분리가 값을 하는 조건은 대략 세 가지다.

런타임이 여러 개일 때. Codex가 구현하고 Claude가 리뷰하는 #49식 구성에서, 소유권·핸드오프·예산을 어느 한쪽 하네스에 둘 수 없다. 공유 상태는 중립 지대에 있어야 하고, 그게 상태 커널의 존재 이유다. 하네스 내장 루프는 자기 세션 안에서만 왕이다.
작업이 세션보다 오래 살 때. 며칠짜리 목표, 오너 게이트, 낡아가는 증거. 세션이 죽어도 남아야 하는 상태가 있다면 채팅 로그 바깥에 집이 필요하다. 단일 세션에서 검증 가능한 정지조건으로 끝나는 일이라면 내장 /loop으로 충분하고, 커널은 과잉이다.
모델을 갈아탈 때. #44의 프레임 그대로다. 모델은 빌리는 것이고 남는 건 자산인데, 목표·게이트·증거·todo가 특정 하네스의 세션 포맷에 묶여 있으면 그건 자산이 아니라 부채다. 프로바이더 중립 상태는 이사할 때 값이 드러난다.

도구 자체를 지금 도입할지는 별개 문제다. v0.4.x고 설치가 curl | bash다. 문서 일부는 Feishu 위키에 있고, 코드베이스는 위에서 본 그 모양이다. 나라면 도구보다 먼저 다섯 질문을 체크리스트로 가져오겠다. 지금 돌리는 루프에서 목표는 어디 적혀 있나, 사람 판단이 필요한 지점은 구체적 질문으로 존재하나, 증거는 어디 남나, 예산 차감은 검증과 묶여 있나. 이 질문들에 대한 답이 전부 “채팅 스크롤백 어딘가”라면, 도구를 쓰든 직접 만들든 LoopX가 이름 붙인 그 문제를 이미 갖고 있다.

남는 것

loop engineering의 다음 문장은 프롬프트도 루프도 아니고 상태 스키마다. 목표·게이트·증거·쿼터를 타입 있는 객체로 만들면, “언제 멈추나”가 프롬프트 기교에서 회계 규칙으로 바뀐다.
“Keep the judgment human”의 실체는 구호가 아니라 구체적 질문이 담긴 게이트 객체다. 모호한 “대기 중”은 판단을 사람에게 남기는 게 아니라 방치하는 것이다.
루프가 자기 도구를 만드는 시대의 신뢰 문제에 대한 이 저장소의 답은 증거에 등급을 붙이는 규율을 게이트로 강제하는 것이었다. 스스로 검증기를 문 마케팅 문서는, 에이전트 산출물의 신뢰가 어디서 나와야 하는지에 대한 힌트다.
같은 구조가 경고이기도 하다. 성장이 루프의 목표로 들어가면 커밋 로그와 스타 차트도 최적화 대상이 된다. 에이전트가 만든 프로젝트의 지표는 그 자체로 산출물일 수 있다.
도입 판단의 기준선은 도구가 아니라 다섯 질문이다. 목표는 어디 살고, 게이트는 질문인가, 증거는 남나, 예산은 검증과 묶였나, 그리고 이 상태는 하네스가 바뀌어도 살아남나.

10주 전 이 저장소의 이름은 goal-harness scaffold였다. 업계가 loop engineering이라는 이름을 만들자 저장소가 그 이름을 입었고, 지금은 그 말이 옳았는지를 저장소 스스로가 실험하고 있다. 하루 74커밋을 만드는 루프와, 그 루프에게 “아직 멈추지 마”라고 답하는 상태 커널. 판단은 아직 사람 몫이라는 저 구호가 지켜지는지는, 앞으로 몇 달치 커밋 로그에 가장 정직하게 남을 것이다.

참고: huangruiteng/loopx (스타·커밋·PR 수치 2026-08-08 조회, 코드·README·AGENTS.md·쇼케이스 문서는 같은 날 클론 기준), LoopX Project History, 셀프 이터레이션 쇼케이스, The New Stack — Boris Cherny와 loop engineering, Slashdot (2026-06-25), Addy Osmani — Loop Engineering. 용어의 계보는 #25 참고. 이 글은 특정 도구의 도입 권고가 아니라 상태 커널이라는 설계 수요에 대한 논평이다.