"에이전트가 완료될 때까지 실행하게 두세요." 유혹적인 말이며, 그럴 만한 이유도 있습니다. 많은 작업은 단 한 번의 통과보다는 "완료"를 향해 반복하는 성격을 띠기 때문입니다. 하지만 거버넌스(Governance)가 없다면, 루프는 끝없는 실행, 예산 소진, 또는 에이전트 스스로 "완료"를 정의해 버리는 상황으로 가는 가장 빠른 경로가 됩니다.

이 사례 연구는 우리가 실제로 루프를 어떻게 배치했는지, 루프가 사전에 반드시 계약해야 하는 사항은 무엇인지, 그리고 운영 경험이 어떻게 방법론의 공식적인 수정 사항이 되었는지를 설명합니다.

우리에게 루프란 무엇인가

루프는 에이전트가 완료 약속(completion promise)을 충족하거나, 예산을 모두 소진하거나, 정체되기 시작할 때까지 동일한 의도(intent)를 반복하는 **실행 모드 (execution mode)**입니다. 이는 단순히 "에이전트가 계속 실행되는 것"이 아니라, 다음과 같은 네 가지 필수 요소를 가진 **위임된 작업의 단위 (unit of delegated work)**입니다:

• completion_promise — 이진(binary) 형태의, 기계가 테스트 가능한 약속입니다. "17개 테스트 모두 통과(green)": 예. "품질을 유의미하게 개선할 것": 아니오. 테스트할 수 없는 것은 루프에 맡길 수 없습니다.
• max_iterations 및 예산 — 엄격한 상한선(반복 횟수, 토큰, 시간)입니다. "무한대"는 값이 아닙니다. 상한선을 초과하면 중단하고 보고(escalate)해야 하며, 절대 조용히 계속 진행해서는 안 됩니다.
• 독립적인 평가자 (An independent evaluator) — 약속의 이행 여부는 작업을 수행한 사람에 의해 판단되지 않습니다. 실행자(Executors)는 체계적으로 자신의 작업을 과대평가합니다. 이는 성격 결함이 아니라 통계적인 현상입니다.
• 모든 반복의 추적 (A trace of every iteration) — 루프는 감사 기록(audit record)에 이벤트를 방출합니다. 정체(진전 없이 N회 반복)가 발생하면 자동으로 일시 중단(Suspend) 및 드리프트(drift) 신호로 이어집니다.

인간의 제어는 모든 반복 과정에 개입하는 것이 아니라, **시작 전 의도의 결정화 (crystallization of the intent)**와 **약속이 충족된 후의 검증 게이트 (Validation Gate)**로 이동합니다. 그 사이 기간 동안 인간은 방해하지 않고 물러나 있습니다.

Diagram: the loop lifecycle — intent crystallization, iterations emitting LOOP events, checking the completion promise, hand-off to the Validation Gate; on the right the safeguards: max_iterations, loop_budget, an independent evaluator, stagnation detection

실제 실행

2026년 7월, 우리는 라이브 개발 서버에서 이 모드를 엔드 투 엔드 (end-to-end)로 검증했습니다. 에이전트는 기계가 확인 가능한 완료 약속 (completion promise)이 포함된 의도 (intent)를 수신했고, 제어된 루프 (loop) 내에서 반복 수행되었으며, 첫 번째 반복에서 약속을 이행하고 모든 단계를 거버넌스 기록 (governance record)에 기록했습니다. 게이트 (gate)는 스토리텔링이 아닌 증거 — 아티팩트 (artifact), 반복 로그 (iteration log), 충족된 약속 — 를 바탕으로 결정했습니다.

실행 과정이 스스로에 대해 드러낸 정보 또한 매우 가치 있었습니다. 루프가 필요로 하는 인프라 의존성 (적절한 권한을 가진 라이브 작업 환경)과 헤드리스 실행 (headless runs) 이후의 정리 작업의 필요성 등이 그것입니다. 이 또한 단순한 세부 사항이 아닌 거버넌스 (governance) 차원의 교훈입니다.

작동하지 않았던 것

• 초기 시도에서는 전형적인 실패 모드인 기계가 평가할 수 없도록 표현된 약속 (promise) 가 나타났습니다. 해결책은 "더 열심히 노력하는 것"이 아니라 규칙을 세우는 것이었습니다: 테스트 불가능한 약속 = 해당 의도는 실행 승인을 받을 수 없음.
• 평가자 (evaluator)는 중간 위험 수준 이상부터는 필수적이어야 한다는 점이 명확해졌습니다. 사소한 루프 (trivial loops)에는 보정 (calibration)만으로 충분하지만, 그보다 더 심각한 경우에는 독립적인 판단이 필수적입니다.

실무에서 방법론으로

루프에 대한 운영 경험은 방법론 (v0.95)에 대한 공식적인 수정안으로 구체화되었습니다. 즉, 루프를 다음과 같은 특징을 가진 공인된 실행 모드 (execution mode)로 정의합니다: 의무적인 런타임 계약 (runtime contract), 실행자 (executor)에 의한 수락 기준 (acceptance criteria) 수정 방지 (테스트를 통과하는 가장 저렴한 방법은 테스트를 삭제하는 것이기에, 이를 금지하고 감사 (audit)합니다), 그리고 인간 큐레이터 (human curator)로부터 형식적인 절차를 걸러내면서도 결정권은 그들에게 남겨두는 기계적 사전 게이트 (machine pre-gate).

이것이 바로 GALDUR의 핵심입니다. 방법론은 선언이 아니라 실무에 근거한 수정 (amendments)을 통해 변화합니다.

시사점

• 기계 테스트가 가능한 약속(promise)이 없는 루프는 자율성(autonomy)이 아닙니다. 그것은 도박입니다.
• 예산(Budgets)과 상한선(caps)은 에이전트에 대한 불신이 아니라, 신뢰를 확장할 수 있는 조건 그 자체입니다.
• 독립적인 평가(Independent evaluation)는 관료주의가 아닙니다. 그것은 실행자 스스로의 평가에 대항하는 유일한 방어책입니다.
• 인간의 통제는 루프의 매 순간이 아니라, 시작점(결정화, crystallization)과 끝점(게이트, gate)에 속합니다.

_본 사례 연구는 GALDUR가 v1.0 버전에서 스스로에게 설정한 조건 중 하나입니다(