가이드된 런타임(Guided runtime) — 당겨오기(pull)가 아닌 밀어주기(push).

상태: Dev.to를 위한 공개 초안. 공개 가능한 수준. 초기 관찰 증거를 포함한 하나의 _논제(thesis)_이며, 검증된 결과는 아닙니다. 통제된 실험은 끝부분에 있으며, 수치는 그 뒤를 따를 것입니다.

내 에이전트가 서서히 맥락을 놓치는 것을 지켜보며

저는 점점 복잡해지는 시스템을 구축하고 있습니다. 많은 진입점(entry points). 인터페이스가 인터페이스를 호출하는 구조. 리포지토리(repo) 전반에 흩어져 있는 문서, 계약(contracts), 그리고 관례(conventions). 코드가 어떻게 맞물려 돌아가는지 기억하려면 _잠시 생각할 시간_이 필요한 그런 종류의 코드베이스입니다.

그래서 저는 에이전트에게 작업을 맡기고 지켜보았습니다. 처음에는 잘 시작했습니다. 그러다 십여 단계가 지나면, 에이전트는 미끄러지기 시작했습니다 — 자신이 어디에 있었는지 다시 유도(re-deriving)하고, 이미 보았던 인터페이스를 놓치고, 한 시간 전에 읽었던 문서를 grep으로 찾고, 증상만을 패치(patching)하고, 같은 벽에 부딪히고, 다시 패치합니다. 에이전트는 자신의 접근 방식 전체가 잘못되었는지 묻기 위해 멈추지 않았습니다. 그저 갈 길이 다할 때까지 국소적으로(locally) 계속해서 갈아 넣을 뿐이었습니다.

저는 당연한 일을 했습니다. 컨텍스트(context)를 개선했습니다: 더 나은 인덱싱(indexing), 임베딩(embeddings), 검색(retrieval), 리포지토리 맵(repo map), 검색 도구(search tool). 에이전트가 필요한 것을 찾을 수 있는 더 많은 방법을 제공했습니다.

그것은 거의 도움이 되지 않았습니다. 그리고 그때 저는 제가 잘못된 문제를 풀고 있다는 것을 깨달았습니다.

모두가 잘못된 문제를 풀고 있다

Grep, RAG, 리포지토리 맵(repo-maps), 시맨틱 검색(semantic search) — 이것들은 유용합니다. 저도 여전히 사용합니다. 하지만 이것들은 주로 더 많은 **정보(information)**를 사용할 수 있게 해줄 뿐입니다. 그리고 지배적인 가정은 에이전트가 시스템에 대해 충분히 알지 못하기 때문에 실패한다는 것입니다.

하지만 유능한 모델이 긴 작업을 수행하다 실패하는 것을 지켜보면, 그것은 당신이 생각하는 것과 다릅니다. 적절한 프레임(frame)이 주어지면, 동일한 모델은 불평 없이 길고 정확하며 절제된 체인(chains)을 실행합니다. 모델은 지능이 부족한 것이 아니며, 제 코드베이스에서 정보가 부족했던 것도 아니었습니다 — 모든 것을 가리키는 검색 도구가 이미 있었습니다.

그것은 복잡한 시스템 내에서 긴 시간 지평(long horizon) 동안 자신의 위치를 유지할 수 없기 때문에 길을 잃습니다. 이는 단순한 정보의 문제가 아니라 주의력 (attention) 문제입니다. 검색 (Retrieval)은 사실 계층 (fact layer)을 도와줄 뿐, 그 자체로 주의력을 제어하지는 못합니다. 더 나쁜 것은, '당겨오기 (pull)' 방식은 이미 표류하고 있는 모델에게 표류가 훼손시킨 바로 그 작업—시스템을 탐색하고, 무엇이 관련 있는지 결정하며, 스스로 컨텍스트를 조립하는 일—을 수행하라고 요구한다는 점입니다. 에이전트에게 정밀한 구조적 도구를 쥐여주고 그것을 선택 사항으로 남겨두면, 에이전트는 종종 그것을 사용하려는 시도조차 하지 않습니다. 그들은 길을 잃습니다. 길을 잃는 상태가 바로 무엇을 가져와야 할지 알 수 없게 만드는 원인입니다.

우리는 잘못된 질문에 답해왔습니다.

반전: 당기지 말고 밀어주세요 (push, not pull)

만약 에이전트가 스스로 컨텍스트를 '찾을' 것이라고 신뢰할 수 없다면, 그렇게 만들기를 중단하십시오. 대신 런타임 (runtime)이 다음 단계를 계산하여 에이전트가 행동하기 전에 루프 안으로 밀어넣도록 (push it) 하십시오.

이것이 핵심적인 변화입니다: 당기지 말고 밀어주세요 (push, not pull). 저는 에이전트가 검색할 더 나은 라이브러리를 만드는 것을 멈추고, 매 단계마다 에이전트에게 현재 위치가 어디인지, 다음에 무엇이 허용되는지를 알려주는 무언가를 만들기 시작했습니다. 저는 이를 **가이드형 런타임 (guided runtime)**이라고 부릅니다.

이것은 무엇이 '아닌지'로 정의됩니다:

• 제어 루프로서의 검색 (retrieval)이 아닙니다. 검색은 여전히 존재하지만, 사실 계층 (fact-layer)을 위한 도구가 됩니다. 에이전트는 표류하는 동안 매 행동 전에 어떤 컨텍스트를 조립할지 스스로 결정할 필요가 없어야 합니다.
• 오류 피드백 (사후적, post-hoc)이 아닙니다. "테스트를 실행했고 실패했으니 수정하라"는 방식이 아닙니다. 이는 궤도에서 벗어난 뒤에 다시 끌어오는 것이 아니라, 궤도를 유지하기 위해 행동이 일어나기 전에 발생합니다.
• 일회성 계획 (one-shot plan)이 아닙니다. 시작할 때 한 번 작성된 계획을 읽는 것이 아니라, 현재 상태로부터 매 단계마다 재계산됩니다.

메커니즘 — 사실 (Facts) + 규칙 (Rules) → 가이드 (Guide)

가이드형 런타임은 세 가지 계층으로 구성됩니다. 외부의 두 계층만이 도메인 특화적(domain-specific)이며, 중간의 엔진은 재사용이 가능합니다.

• Facts (사실) — 최신의, 쿼리 가능한 진실 모델 (ground truth model). 코드의 경우, 커밋에 종속된 (commit-bound) 의존성/심볼 그래프입니다. 일반적으로는 추가 전용(append-only) 이벤트 로그에 대한 투영(projection)입니다 (이벤트 소싱 (event sourcing)). 현재 상태는 명시적인 워터마크 (watermark)에 고정된 이벤트들의 폴드 (fold)입니다. 만약 세상이 해당 워터마크를 넘어섰다면, 런타임은 자신의 스냅샷이 전지전능한 척하는 대신 그 사실을 말할 수 있습니다.
• Rules (규칙) — 검증 가능한 (checkable) 무언가로 컴파일된 계획입니다. 이것이 핵심적인 아이디어입니다: 계약 (contract)이란 검증 가능하게 만들어진 계획입니다. 계획이 "기능을 구현하고 테스트를 추가하라"라고 말한다면, 계약은 다음과 같이 말합니다: 이 파일들은 울타리이며, 이러한 수락 술어 (acceptance predicates)가 반드시 성립해야 하고, 이러한 동작은 허용되며 저러한 동작은 금지되며, 완료 전에는 반드시 이러한 증거가 존재해야 한다.
• Guide (가이드) — guide = rules ∘ facts. 사실(facts)을 바탕으로 규칙(rules)을 평가하고 조향 신호 (steering signal)를 방출합니다: 다음의 합법적 동작, 누락된 조각, 드리프트 경고 (drift alert), 차단된 동작 등입니다. 가이드는 알려주고, 게이트 (gates)는 강제합니다. 증거는 여전히 적절한 행위자 (actor)에 의해 작성되어야 하며, 권한을 가진 게이트가 무엇을 종료할 수 있는지 결정합니다.

이것이 익숙하게 느껴진다면 좋은 징조입니다. 이것은 고전적인 facts + rules → inference (추론) 아키텍처입니다. 즉, 프로덕션 규칙 엔진 (production rule engines), 정책 코드화 (policy-as-code) (입력된 사실에 대해 정책을 평가 → 결정), 이벤트 소싱 (event sourcing) / CQRS와 같습니다. 엔진은 수십 년간 검증된 토대 위에 놓여 있습니다. 참신함은 엔진에 있는 것이 아닙니다.

런타임은 실제로 무엇을 밀어줄까요? 단순히 조언 한 단락을 주는 것이 아닙니다. 사용 가능한 가이드는 봉투와 같은 형태를 띱니다: 현재의 계약 ID, 행위자 역할, 허용 및 차단된 동작, 다음 합법적 동작, 요구되는 증거, 페이로드 스켈레톤 (payload skeleton), 계산의 근거가 된 상태 워터마크 (state watermark), 그리고 이를 검증할 게이트 (gate) 등이 포함됩니다. 중요한 점은 에이전트가 더 이상 "나는 어디에 있고 지금 무엇이 합법적인가?"를 처음부터 다시 추론할 필요가 없다는 것입니다.

내가 예상하지 못했던 부분: 이것은 코드에 관한 것이 아닙니다

가이드 엔진 — rules ∘ facts — 은 **도메인 독립적 (domain-independent)**입니다. 코드는 사실 계층 (fact layer)을 구축하기 쉬운 하나의 사례 (커밋과 그 의존성 그래프는 비용이 들지 않으므로)일 뿐입니다.

어떠한 복잡한 에이전트 워크플로 (agent-workflow) 도메인 — 운영 런북 (ops runbook), 보험 청구 파이프라인, 다단계 비즈니스 프로세스 등 — 에서든 가이드된 런타임 (guided runtime)을 구축하기 위해, 당신은 정확히 다음 두 가지만 제공하면 됩니다:

1. 사실 계층 도구 (fact-layer tool): 이벤트 소싱된 프로젝션 (event-sourced projection)으로서의 그라운드 트루스 (ground truth)를 추출하는 도구 (대부분의 비즈니스 상태는 코드보다 변화율 (churn)이 낮습니다. 즉, 모델링 가능한 불연속적인 전환점에서 변화하므로, 사실 계층을 구축하는 것이 코드보다 더 어렵지 않고 오히려 더 저렴합니다).
2. 규칙 (rules): 검증 가능한 계약 (checkable contracts)으로 컴파일된 해당 도메인의 계획.

그러면 동일한 가이드된 런타임이 에이전트를 조종합니다. 적절한 다음 단계를 밀어주고 (pushes), 적절한 게이트 (gate)가 결과를 검증하며, 계약 (contract)으로 해결할 수 없을 때만 시스템이 에스컬레이션 (escalate)합니다. 어려운 부분이자 도메인별로 발생하는 유일한 비용은 바로 _모델링 (modeling)_입니다. 즉, 이벤트를 선택하고 검증 가능한 규칙을 작성하는 것입니다. 그 외의 모든 것은 재사용됩니다. 기계는 범용적이며, 인간의 판단이 들어가는 곳은 바로 모델링 단계입니다.

이것이 바로 이 방식이 단순한 코딩 기술 그 이상이 되게 만드는 핵심적인 가설입니다: 가이드된 런타임은 사실 (facts) + 규칙 (rules)로 모델링할 수 있는 그 어떤 복잡한 비즈니스에서도 에이전트가 궤도 (trajectory)를 유지하게 만드는 범용적인 방법입니다.

참신함에 대해 솔직해지겠습니다

모든 구성 요소는 기존 기술 (prior art)입니다. 구조에서 유도된 연속적인 다음 행동 조종 (steering)은 오래된 개념입니다 (그라운디드 디코딩 (grounded decoding), 로보틱스에서의 가치 유도 행동 선택 (value-guided action selection)). 상태 머신 (state-machine) 기반의 LLM 컨텍스트 주입 (context injection)도 오래된 방식입니다. 사실+규칙 엔진은 더 오래되었습니다. 이벤트 소싱 (event sourcing)은 수십 년 된 기술입니다.

핵심적인 베팅은 바로 **합성 (synthesis)**입니다: 신선도(freshness)가 고정된 이벤트 투영 사실 모델 (event-projected fact model) 위에서, (당겨오는 것이 아닌) 밀어주는 방식(push)과 계약(contract)으로부터 유도된 구조를 결합하여 자율 에이전트(autonomous agent)를 위한 _주요 드리프트 방지 제어 (primary anti-drift control)_로 사용하는 것입니다. 제가 찾은 바로는, 정확히 이 요소들을 융합한 사례는 없으며, 현재 여러 연구 흐름이 이 지점으로 수렴하고 있습니다. 저는 이를 프레임워크가 올바르다는 신호로 받아들입니다.

이것이 작동하는가?

여기서부터는 저 자신에게 솔직해지려 합니다. 인터넷에는 "새로운 패러다임이 모든 것을 해결한다"는 식의 게시물이 넘쳐나며, 저 또한 그런 글을 쓰고 싶지 않기 때문입니다.

저는 이것을 코딩 에이전트(coding agents)를 위한 거버넌스 계층(governance layer)으로 구축했습니다 — Aming Claw (공개 프로젝트이며, 스스로를 테스트하는 dogfooding 중이므로 잦은 변경이 있을 수 있습니다) — 그리고 이를 아주 혹독하게 dogfooding했습니다. 관찰된 신호는 진심으로 고무적입니다. 런타임(runtime)이 안정화됨에 따라, 병리적인 무한 루프(stuck-loops)가 더 일찍 가시화되었고, 반복적인 차단 요소(blockers)로 인해 실패하던 여러 경로가 깔끔하게 수렴하기 시작했습니다. 운영자(operator)의 기억력에 의존하던 고통스러운 멀티 워커(multi-worker) 경로들이 계약(contract)을 통해 실행되기 시작했습니다.

하지만 저는 이것이 검증되었다(not validated)고 말하지 않겠습니다. 이는 통제된 실험이 아닌 관찰 결과일 뿐입니다. 이 작업은 종단적(longitudinal)으로 진행되었습니다. 아키텍처, 버그 수정, 그리고 저 자신의 가이드가 동시에 변했기 때문에, 아직 _런타임(runtime)_의 효과를 _운영자(operator)_의 효과와 깔끔하게 분리할 수 없습니다. 고무적인 궤적(trajectory)이지만, 입증된 인과관계(causality)는 아닙니다. 만약 누군가 당신에게 이런 추세를 보여주며 자신의 패러다임이 "검증되었다"고 말한다면, 그들은 물건을 팔고 있는 것입니다.

현재의 실제 상황: 풀(pull)에서 푸시(push)로 전환되는 과도기. 이 가이드가 아직 모든 법적(legal) 단계를 계산하는 것은 아닙니다. 계약(contract)이 상황을 모델링하지 못한 곳에서는, 에이전트가 여전히 컨텍스트를 직접 가져와(pulling context) 추론을 통해 해결하는 방식으로 회귀합니다. 이는 구축 과정에서 의도된 설계입니다. 푸시(push)가 풀(pull)을 폐지하는 것은 아닙니다. 푸시는 그것을 '조준(aim)'하는 것이며, 현재 많은 영역이 여전히 조준되지 않은 상태입니다. 더 많은 것이 사실(facts)과 규칙(rules)으로 모델링됨에 따라, 각 반복(iteration)을 통해 더 많은 부분이 *에이전트-풀(agent-pulls)*에서 *런타임-푸시(runtime-pushes)*로 이동하고 있습니다. 저는 이 논지를 반복 과정의 중간 단계이자 공개적으로 불안정한 상태에서 발표하고 있습니다. 푸시 경로가 수렴하고 풀(pull) 방식의 회귀가 진정으로 새로운(genuinely-novel) 경계 영역으로 축소되면, 저는 **안정적인 릴리스(stable release)**를 내놓을 것입니다. 그리고 오늘날의 움직이는 목표가 아니라, 바로 그 안정적인 버전을 대상으로 아래의 실험을 진행할 것입니다.

제가 다음에 진행할 실험과 발표할 수치는 다음과 같습니다:

1. 운영자 없는(Operator-free), 그렇게 기록된 방식 — 런타임의 효과가 저의 개입으로부터 격리되도록 합니다.
2. 동일한 모델, 가이드된 런타임(guided runtime)의 On/Off 여부, 그리고 강력한 베이스라인 스캐폴드(scaffold) — 고정된 모델의 절제 실험(ablation)을 통해, 변화량(delta)이 모델이 아닌 하네스(harness)에 기인함을 증명합니다.
3. 제3자 지표와 검증된 궤적(trajectories)을 가진 외부의 객관적 벤치마크 — 저만의 성공 기준이 아닌 방식입니다.
4. 작업 길이에 따라 계층화된 드리프트/완성도 변화량(Drift/completion delta) — 왜냐하면 이 논지의 핵심은 오버헤드가 짧은 작업에서는 손해를 보지만, 안티-드리프트(anti-drift)는 긴 작업에서 승리한다는 것이기 때문입니다. 이 교차점(crossover)이 바로 저의 주장입니다.

만약 실험 결과가 제가 생각하는 대로 나온다면, 그 수치를 게시하겠습니다. 그렇지 않더라도, 그 사실 또한 알 가치가 있습니다.

프레임워크를 한 줄로 요약하자면

당신의 에이전트가 길을 잃는 이유는 컨텍스트가 부족해서가 아닙니다. 자신의 위치를 유지할 수 없기 때문입니다. 그러니 검색(search)을 제어 루프(control loop)로 만들지 마세요. 당겨오지 말고 밀어주세요(push, not pull). 다음 단계를 rules ∘ facts로 계산하여 에이전트가 행동하기 전에 전달하는 가이드된 런타임을 구축하십시오. 이것은 오늘날 코드 작업에서 작동합니다. 동일한 형태는 사실(facts)과 규칙(rules)으로 모델링할 수 있는 모든 복잡한 워크플로우에서도 작동해야 합니다.

제 생각이 틀렸다면 어디가 틀렸는지 말씀해 주세요.