지금 모두가 똑같은 말을 하고 있습니다. 코딩 에이전트(coding agent)에게 프롬프트를 입력하는 것을 멈추고, 대신 당신을 대신해 프롬프트를 입력할 루프(loop)를 설계하여 에이전트가 일을 하게 하라는 것입니다. 저희도 동의합니다. 다만 저희는 이것이 더 이상 예측이 아닌 수준이 될 만큼 충분히 오랫동안 이를 실행해 왔습니다. 자율 루프(autonomous loops)가 몇 주 동안 4개의 프로덕션 리포지토리(production repos)에서 저희의 R&D를 수행해 왔습니다.

구체적인 사례를 하나 소개하겠습니다. 저희의 오픈 소스 게이트웨이인 NyxID에서, 지난주 한 루프가 GitHub 이슈(issue)에 있던 로드 밸런싱(load-balancing) 기능을 머지된 PR(Pull Request)로 만들어냈습니다. 약 1,400줄의 Rust 코드가 작성되었으며, 머지 메타데이터(merge metadata)에는 human_touch_count = 0으로 기록되어 있습니다. 즉, 사람이 디프(diff)를 수정하지 않았음을 의미합니다. 사람이 이슈의 범위를 정하고 머지 버튼을 클릭하긴 했지만, 코드는 루프에서 생성되었으며 아무도 다시 작성하지 않은 채 리뷰를 통과했습니다. (PR #975)

이것이 바로 모두가 열광하는 부분이며, 실제로 일어나고 있는 일입니다. 하지만 이것이 가장 어려운 부분은 아니며, 저희가 이 시스템을 계속 실행해 둘 만큼 신뢰하는 이유도 아닙니다.

어려운 부분은 자율성이 아니라 신뢰입니다

자율 루프(autonomous loop)의 실패 모드(failure mode)는 아무것도 하지 않는 것이 아닙니다. 확신에 차서 틀린 일을 하는 것입니다. 즉, 유지되지 않을 그럴듯한 코드를 작성하거나, 실패하는 테스트를 대충 덮어버리거나, 뒷받침할 수 없는 결과를 주장하며 예산이 다 소진될 때까지 실행되는 것입니다. 단일 모델(single model)은 확신이 없어야 할 때조차 스스로를 확신하며, 단순한 루프(naive loop)는 제동 장치 없이 그 모든 확신을 그대로 물려받습니다. 이것이 대부분의 "에이전트가 10시간 동안 실행됩니다"라는 데모들이 데모로만 남는 진짜 이유입니다.

따라서 저희가 실제로 consensus-loop를 구축하며 목표로 한 것은 "에이전트를 실행시키는 것"이 아닙니다. "당신이 자리를 비워도 될 만큼 에이전트를 신뢰할 수 있게 만드는 것"입니다. 그 방법은 하나의 확신에 찬 모델이 혼자 결정하게 두는 것을 멈추는 것입니다.

작동 방식

consensus-loop는 여러분이 이미 사용 중인 호스트(host)인 Claude Code, Codex, Cursor 또는 Gemini에 주입하는 기술입니다. 리포지토리를 지정하고 해당 리포지토리의 정보가 담긴 host.env 파일 하나를 전달하면, 그 시점부터 루프가 개발 과정을 이어받습니다.

전체 호스트 측 계약(host-side contract)은 몇 가지 사실로 이루어져 있습니다

REPO_ROOT=/path/to/your/repo
GH_REPO_SLUG=your-org/your-repo
...

가장 주목할 만한 세부 사항 하나를 말씀드리자면, 이것이 합의(consensus)가 의미하는 바의 대부분이기 때문입니다. 루프는 두 개의 다른 시스템에 걸쳐 실행됩니다. 설치하는 호스트 — 저희 설정에서는 Claude Code입니다 — 가 컨트롤러 역할을 합니다. 이 컨트롤러는 라우팅하고, GitHub에 게시하며, 커밋하고, 병합하지만, 생각 자체는 하지 않습니다. 사고 과정은 격리된 git 작업 트리(worktrees)에서 생성되는 별도의 Codex 워커(workers)에서 실행됩니다. Claude Code가 구동을 담당하고; Codex가 추론합니다. 루프를 조종하는 에이전트가 작업을 수행하는 주체가 아니며, 그 작업 자체는 서로 볼 수 없는 독립적인 Codex 워커들 사이에 분산되어 있습니다.

작동 방식은 다음과 같습니다:

• 세 개의 Codex 솔버가 격리된 상태에서 논쟁합니다. 하나는 가능한 가장 작은 변경에 편향되어 있고, 하나는 구조적 정확성에, 또 다른 하나는 코드 삭제에 편향되어 있습니다. 이들은 서로의 작업을 보지 않고 각각 계획을 작성하므로, 조용히 같은 잘못된 답으로 수렴하지 않습니다.
• 심사위원(judge)이 이를 수렴시킵니다. 네 번째 역할은 세 가지 계획 모두를 읽고 진리표(truth table)를 실행합니다. 만약 세 개 모두가 동일한 형태의 수정안을 제안한다면, 그것이 합의이며 진행됩니다. 만약 의견이 다르다면, 심사위원은 더 날카로운 질문을 작성하여 다시 라운드를 위해 되돌려 보냅니다.
• 구현하고, 그 후 독립적인 검토자가 이를 거부하려고 시도합니다. 별도의 검토 단계(review passes)가 아키텍처, 품질, 테스트를 확인하며, 의심스러울 때는 '배포'보다는 '재작업' 쪽으로 오류를 범하도록 지시받습니다.
• 의도적으로 포기합니다. 만약 세 번 이상의 라운드가 진행되었는데 진전이 없고 새로운 틀 잡기가 없다면, 해결할 수 없는 문제에 토큰을 소모하며 매달리기보다는 작업을 중단하는 것이 기본값입니다.

여기에 알고리즘적인 새로움은 없으며, 그렇지 않은 척하지도 않겠습니다. 그 이면에는 멀티 에이전트 토론 (multi-agent debate), LLM 판사 (LLM judge), 그리고 자기 일관성 (self-consistency) — 즉, 여러분이 이미 알고 있는 패턴들이 자리 잡고 있습니다. 정말 어렵고, 우리가 실제 리포지토리 (repos)에서 몇 주 동안 디버깅을 거치며 깨달은 것은 루프 (loop) 주변의 신뢰성 공학 (reliability engineering)입니다. 루프를 계속 유지하는 데몬 (daemons), 두 인스턴스가 충돌하는 것을 방지하는 임대 (leases), 릴리스 게이트 (release gates), 그리고 중단 규칙 (stop rules) 같은 것들 말입니다. 아이디어는 저렴합니다. 하지만 그것을 신뢰할 수 있게 만드는 것은 그렇지 않습니다.

만약 데몬 메커니즘 (daemon machinery) 없이 단 하나의 어려운 결정에 대해 합의 (consensus) 아이디어를 시도해보고 싶다면, 몇 개의 격리된 워커 (workers)를 실행하여 다른 관점들을 제공하는 sshx라는 가벼운 스킬 (skill)이 있습니다.

우리가 이것을 신뢰하는 이유: 자신이 무엇을 모르는지 알고 있기 때문

이해관계의 충돌에 대해 솔직하게 말씀드리겠습니다. 아래의 모든 리포지토리 (repos)는 저희의 것이며, consensus-loop는 현재까지 외부 채택 사례가 전혀 없습니다. 이것은 제3자의 검증이 아닌 저희 스스로의 기록입니다. 모든 것은 여러분이 직접 열 수 있는 공개된 이슈 (issue) 또는 PR (Pull Request)입니다.

상단의 NyxID 기능은 루프가 작업을 수행하고 있는 모습입니다. 아래의 사례들은 루프가 작업을 수행하지 않기로 결정한 경우이며, 바로 이러한 동작이 첫 번째 유형을 신뢰할 수 있게 만들어 줍니다.

조작하는 대신 중단했습니다. aevatar에서 솔버 (solvers)들이 합의에 도달했지만, 구현 시점에 워커 (worker)가 변경 사항을 안전하게 적용할 수 있는 실제 외부 증거를 가지고 있지 않았습니다. 무언가를 만들어내기 위해 누락된 부분을 지어내는 대신, 루프는 중단되었고, 아무것도 변경하지 않았으며, 자신이 모르는 부분을 드러냈습니다. 확신에 찬 잘못된 디프 (diff)가 아닌, 깔끔한 중단이었습니다. (#2181)

필요할 때 인간에게 요청했습니다. Ornn에서 하나의 큰 기능이 여러 라운드 후에도 수렴 (converge)하지 않았습니다. 루프는 머지 (merge)를 강제하지 않았습니다. 대신 에스컬레이션 (escalation)을 생성하고, 미완성된 작업을 검토를 위해 남겨두었으며, 사람의 도움이 필요하다고 표시했습니다. (#1061)

그것은 근거를 뒷받침할 수 없는 공로를 인정하기를 거부했습니다. 동일한 유지 관리자(maintainer)가 작성한 우리의 또 다른 프로젝트인 newmath에서, 루프(loop)는 실험을 수행하고 갭 탐지(gap-detection) 벤치마크에서 베이스라인(baseline) 0.463 대비 0.998이라는 실제 결과를 측정했습니다. 그 후 루프는 모델이 더 잘 예측했다는 별도의 결과를 주장하려 했으나, 통계적 게이트(statistical gate)를 통과하지 못했습니다: 양쪽 암(arms)에서 동일한 오류가 발생했기 때문입니다. 그래서 루프는 해당 주장이 거짓임을 표시하고 그 이유를 기록했습니다. 우리가 승리를 간절히 원했을 리포지토리(repo)였음에도 불구하고, 루프는 스스로 뒷받침할 수 없는 결과를 취하지 않았습니다. (#1687)

그 네 가지 사례 중 세 가지는 루프가 행동하지 않기로 선택한 것입니다. 그것이 핵심입니다. 실제로 계속 실행해 둘 수 있는 자율 루프(autonomous loop)는 항상 무언가를 만들어내는 것이 아니라, 확신이 있을 때 생성하고 확신이 없을 때는 멈추는 것입니다.

우리가 여기에 투입한 것

우리는 지난 몇 달 동안 이 루프를 구축하고, 튜닝(tuning)하며, 우리 자신의 리포지토리에서 실제로 실행해 왔습니다. 즉, 프로덕션(production) 환경에서 사용함과 동시에 개선해 온 것입니다. 이것은 주말 동안 만든 프로토타입(prototype)이 아니라, 실제로 1,550억 개의 토큰(tokens)과 160만 번의 모델 호출(model calls)이 이 시스템 내부에서 살아 움직인 결과입니다. 우리는 의도적으로 토큰을 시간과 맞바꾸고 있습니다.

루프 엔지니어링(Loop engineering)은 현재 중요한 전환점을 맞이하고 있으며, 우리는 실제로 작동하는 버전들이 소수의 기업 내부 리포지토리에만 갇혀 있어서는 안 된다고 생각합니다. 그래서 우리는 우리의 것을 공개합니다. 우리와 함께 루프를 실행해 보세요. 여러분의 리포지토리를 대상으로 실행해 보고, 망가뜨려 보고, 어디서 실패하는지 알려주세요. 그리고 이 기술들이 실제로 무엇을 할 수 있는지 함께 알아봅시다.

스스로의 실수를 포착하고 수정합니다

아직 초기 단계이며, 루프가 수행하는 많은 작업은 무언가가 여러분에게 도달하기 전에 스스로를 복구하는 것입니다. 테스트가 실패하거나 리뷰어(reviewer)가 작업을 거부하면, 루프는 오류를 그대로 배포하지 않습니다. 대신 오류를 다시 입력(feed back)하여 수정하고 재점검합니다. 상단의 NyxID 기능은 통과하기 전까지 이 과정을 네 번 거쳤습니다. 그리고 스스로 진정으로 복구할 수 없을 때는, 억지로 추측하며 넘어가는 대신 멈추고 이를 알립니다.

가져가세요

이것은 오픈 소스이며, MIT 라이선스를 따릅니다. 우리는 이것을 판매하지 않으며, 판매하려고 시도하지도 않습니다. 우리가 이 루프(loop)를 구축한 이유는 우리에게 그것이 필요했기 때문이며, 우리는 매일 우리의 자체 제품에 이를 실행하고 있습니다. 그리고 여러분의 제품에서도 실행할 수 있도록 여러분에게 제공합니다. 여러분의 호스트(host)에 주입하고, 하나의 host.env를 작성한 뒤, 리포지토리(repo)를 가리키기만 하면 됩니다.

가서 마음껏 망가뜨려 보세요: https://github.com/ChronoAIProject/consensus-rnd