2026년 7월 중순부터, AI 에이전트계에서 Graph Engineering (그래프 엔지니어링) 이라는 용어가 갑자기 유통되기 시작했습니다. Loop Engineering (루프 엔지니어링)의 다음 단계라는 위치로 이야기되고 있습니다.

정의는, 여러 개의 에이전트 루프를 하나의 시스템으로 배선하는 설계 기법입니다. Louis Bouchard 씨의 해설 기사에는 다음과 같이 적혀 있습니다.

Graph engineering is this week's name for connecting several agent loops into one orchestrated system: parallel branches, verifiers, handoffs, and stop conditions.

(그래프 엔지니어링은, 여러 개의 에이전트 루프를 하나의 오케스트레이션 (orchestrated) 된 시스템에 연결하는 것의, 이번 주의 명칭이다: 병렬 브랜치, 검증기, 핸드오프, 그리고 정지 조건)

「이번 주의 명칭」이라는 표현에, 이 용어를 둘러싼 분위기가 잘 나타나 있습니다.

이 기사에서는 Graph Engineering이 무엇을 가리키는지, Loop Engineering과는 실제로 무엇이 다른지, 그리고 애초에 그래프로 만들어야 하는지까지 정리합니다. 결론부터 말하자면, 새로운 것은 아마 이름일 것이며, 다루고 있는 난이도는 이전부터 있었습니다. 다만, 그 난이도에 이름이 붙음으로써 명확해진 부분은 분명히 존재합니다.

이 기사에서 다루는 내용

• Graph Engineering이 어떻게 시작되었는가 (트윗 1건입니다)
• prompt → context → harness → loop → graph 라는 명칭의 계보
• 노드(node)・에지(edge)・공유 상태(shared state)라는 3가지 부품
• 5가지 합성 가능한 패턴과, 각각이 무너지는 조건
• LangGraph에서의 최소 구현
• 「정연한 난센스 (orderly nonsense)」 문제라는 가장 까다로운 함정
• Google DeepMind × MIT의 연구가 보여준 「그래프로 만들어야 하는가」의 판단 기준

Graph Engineering의 출발점은 제품 발표도 논문도 아니었습니다. OpenClaw의 제작자인 Peter Steinberger 씨(@steipete)가 2026년 7월 중순에 던진 짧은 질문이었습니다.

Are we still talking loops or did we shift to graphs yet?

(아직 루프 이야기를 하고 있나, 아니면 이미 그래프로 넘어갔나?)

이것이 수백만 회 규모로 노출되었고, 유사한 반응이 차례차례 이어지면서 머지않아 「graph engineering」이라는 용어가 퍼졌습니다.

여기서 짚고 넘어가야 할 사실이 하나 있습니다. Data Science Dojo의 기사에서 명확히 이렇게 적고 있습니다.

No framework, model, or capability shipped around the tweet. The term came entirely from the discourse that followed it.

(이 트윗 전후로 프레임워크, 모델, 혹은 기능이 출시된 것은 없다. 이 용어는 전적으로 그 뒤에 이어진 담론에서 탄생했다)

즉 Graph Engineering은 기술적인 돌파구(breakthrough)에 이름이 붙은 것이 아닙니다. 이미 존재하고 있던 실천에 나중에 이름이 붙은 것입니다.

이 그림의 오른쪽 끝이 이 용어를 읽을 때의 전제가 됩니다. 무언가 새로운 것이 가능해진 것은 아닙니다.

그렇다면 쫓아갈 가치가 없는가 하면, 그렇다고 할 수도 없습니다. LangChain은 공식 블로그에서 다음과 같이 쓰고 있습니다.

Graph engineering isn't a new idea. It's the latest name for a well established approach to building reliable agents.

(그래프 엔지니어링은 새로운 아이디어가 아니다. 신뢰할 수 있는 에이전트를 구축하기 위한, 잘 확립된 접근 방식에 붙여진 최신 명칭이다)

새롭지는 않지만, 확립된 방식이다. 이 두 가지는 양립할 수 있습니다.

Graph Engineering은 지난 2년 정도 동안 5번째 명칭입니다.

나열해 보면, 관심의 이동에 일관된 방향성이 있습니다. 모델에 대한 입력에서, 모델을 둘러싼 구조로라는 방향입니다.

CodeRabbit의 나카츠가와 아츠시(Atsushi Nakatsugawa) 씨도 AI 주도 개발 컨퍼런스 강연에서 동일한 계보를 보여주었습니다 (2022년 프롬프트 → 2024년 에이전트 → 2025년 컨텍스트 → 2026년 하네스/루프). 명칭이 빠르게 바뀌는 것은 이 분야를 쫓고 있는 사람들에게는 이미 익숙한 감각일 것입니다.

다만, 계보로서 나열했을 때 Graph Engineering에는 다른 것과 다른 점이 하나 있습니다. 앞의 4개는 새로운 기법이었지만, Graph Engineering은 이전 계층의 합성입니다. 그래서 "새롭지 않다"라는 지적이 동시에 성립합니다.

가장 혼란스러워하기 쉬운 부분이 바로 여기입니다. "루프에서 그래프로 넘어갔다"라고 말하면, 루프가 구식이 된 것처럼 들립니다. 하지만 실체는 다릅니다.

Louis Bouchard 씨의 한 문장이 이 관계를 가장 단적으로 표현했습니다.

A graph is what you get when one loop is no longer enough, and graphs contain loops.

(그래프란 하나의 루프만으로는 부족할 때 얻게 되는 것이며, 그래프는 루프를 포함한다)

LangChain도 완전히 같은 내용을 다른 방식으로 쓰고 있습니다.

Loop engineering isn't an alternative to graphs, so much as a simple version of them.

(루프 엔지니어링(Loop engineering)은 그래프의 대안이라기보다, 오히려 그래프의 단순화된 버전이다)

즉, 대립 관계가 아닙니다. 포함 관계입니다.

이 그림에서 그래프 안에 그려진 원들이 각각 하나의 루프입니다. Loop Engineering에서 다루어 온 "실행 → 검증 → 수정 → 정지 조건"이 그대로 노드(node)가 됩니다.

그리고 중요한 것은, 에이전트의 그래프는 대개 DAG(Directed Acyclic Graph, 유향 비순환 그래프)가 되지 않는다는 점입니다. LangChain도 3년간의 지견으로서 "agent graphs are usually not DAGs(에이전트의 그래프는 보통 DAG가 아니다)"라고 기술하며 그 이유를 다음과 같이 설명했습니다.

Production agents need cycles: retrying failed tool calls, asking users for missing information, revising answers after validation...

(프로덕션 에이전트에는 순환(cycle)이 필요하다. 실패한 도구 호출의 재시도, 누락된 정보에 대한 사용자 확인, 검증 후 답변 수정 등...)

이 점이 Airflow와 같은 워크플로우 엔진과 결정적으로 다른 부분이라고 생각합니다. 데이터 파이프라인은 기본적으로 단방향이지만, 에이전트는 되돌아옵니다.

그렇다면 하나의 루프를 여러 개로 나누면 어떤 일이 벌어질까요? Louis Bouchard 씨의 정리가 구체적이었습니다.

이전에는 오케스트레이션(orchestration) 로직이 하나의 거대한 채팅 컨텍스트(chat context) 안에 숨겨져 있었다고 합니다.

the model was the scheduler, the database, the log, and the project manager at once

(모델이 스케줄러이자, 데이터베이스이며, 로그이자, 프로젝트 매니저이기도 했다)

이를 명시적인 그래프로 그리면, 네 가지 사항을 결정해야만 합니다.

"모델의 기분 따라"였던 부분이 코드로 작성됩니다. 이것이 Graph Engineering의 실질적인 내용이라고 생각합니다.

그리고 이 네 가지 중 가장 효과적인 것은 세 번째인 "거부권"입니다. 단일 루프에서는 생성한 모델 스스로가 "완료되었다"라고 판단했습니다. 그래프에서는 다른 노드에 정지 권한을 부여할 수 있습니다.

구성 요소는 단순하며, 단 3가지만 있습니다. LangChain 설명 기사의 설명이 가장 명확했습니다.

노드(Nodes)는 작동합니다.

A node can be deterministic code, a single LLM call, a tool call, or a full agent with its own internal loop.

(노드는 결정론적 코드(deterministic code), 단일 LLM 호출, 도구 호출(tool call), 또는 자체적인 내부 루프를 가진 완전한 에이전트(agent)일 수 있습니다.)

이 부분이 은근히 중요합니다. 노드는 반드시 LLM일 필요는 없습니다. 테스트 스위트 실행, 스키마 검증, DB 쿼리, 인간의 승인 대기 등 이 모든 것이 노드입니다.

에지(Edges)는 다음 단계를 결정합니다. 고정된 에지와 조건부 에지가 있습니다. 조건부 에지는 노드의 결과, 현재 상태, 또는 외부 시그널 중 하나에 따라 분기합니다.

공유 상태(Shared State)는 에지 위를 흐릅니다. 태스크, 생성물, 체크 결과 등이 담긴 객체입니다.

explainx.ai의 기사에서 "컨텍스트 누수(context leak)"로 언급했던 주의점이 실무에서 매우 유효합니다.

Context does not automatically flow between nodes — you design the edges that carry it.

(컨텍스트는 노드 간에 자동으로 흐르지 않습니다. 그것을 운반할 에지를 설계하는 것은 바로 당신입니다.)

단일 거대 컨텍스트(context)에 모든 것을 담았을 때는 의식하지 않아도 전부 보였습니다. 하지만 노드를 나누게 되면, 무엇을 전달할지 명시하지 않으면 전달되지 않습니다. 이는 번거로운 일이지만, 동시에 "이 노드에는 불필요한 정보를 전달하지 않는다"라는 제어가 가능해짐을 의미합니다.

explainx.ai의 기사에서는 그래프를 두 개의 계층으로 나누어 정리하는 방식을 제시했습니다. 이는 매우 실무적이라고 생각했습니다.

같은 "그래프"라는 단어로 변하지 않는 부분과 매번 변하는 부분을 모두 지칭하면 혼란이 생깁니다. "보안 담당 에이전트는 상주하고 있다" (Org Graph)와 "이번 PR에서는 이 3개의 파일을 병렬로 수정한다" (Work Graph)는 별개의 문제입니다.

Graph Engineering의 실천적인 내용은 거의 이 5가지 패턴으로 집약됩니다. 이는 Anthropic의 Building Effective AI Agents에서 정리된 5가지 워크플로우 패턴과 동일한 것이며, Graph Engineering의 맥락에서 재발견된 형태입니다.

이하, 각각에 대해 "무엇을 해결하는가"와 "어디서 망가지는가"를 나열합니다. 실무에서는 망가지는 조건이 더 중요하므로 그 부분을 비중 있게 다루겠습니다.

태스크를 순차적인 단계로 분해하고, 각 노드의 출력을 다음 노드의 입력으로 사용합니다.

이 패턴의 목적은 단순히 토큰을 절약하는 것만이 아닙니다. QA Wolf의 기사에 좋은 표현이 있었습니다. 조사 노드가 수집한 방대한 정보에 대해 말입니다.

Step two doesn't need any of it and including it measurably degrades the result.

(단계 2에는 그 정보가 전혀 필요하지 않으며, 이를 포함하면 결과가 측정 가능할 정도로 저하됩니다.)

전달하지 않음으로써 품질이 올라갑니다. 이 부분이 직관에 반하는 지점입니다. 전부 전달하는 것이 좋아 보일 수 있지만, 실제로는 반대의 결과가 나타날 수 있습니다.

실천 팁은 각 노드가 받는 것을 화이트리스트 방식으로 결정하는 것, 핸드오프(handoff)를 스키마로 타입화(type)하는 것, 그리고 상류의 거대한 출력은 요약해서 전달하는 것입니다.

입력을 분류하여 전용 경로로 흐르게 합니다.

QA Wolf는 이 패턴을 "그래프 내에서 가장 저렴한 구조적 승리(the cheapest structural win in a graph)"라고 표현했습니다. 난이도에 맞춰 비용을 맞출 수 있기 때문입니다.

다만, 이 패턴에는 다른 패턴과는 결이 다른 위험성이 있습니다.

잘못 경로가 지정된 항목은 요란하게 실패하지 않습니다. 잘못된 경로를 따라 성공적으로 완료될 뿐입니다.

（誤って振り分けられたものは、大きな音を立てて失敗しない。間違った経路を正常に完走してしまう）

실패가 조용합니다. 잘못된 분류는 에러가 되지 않습니다. 어려운 태스크가 저렴한 모델의 경로로 흘러 들어가, 그럴싸한 답변을 내놓고 끝납니다. 그렇기 때문에 분류 정확도(classification accuracy)를 계속해서 측정해야 합니다.

그리고 판별할 수 없는 것이나 확신도(confidence)가 낮은 것은 반드시 보수적인 경로로 떨어뜨려야 합니다. 그림의 오른쪽 하단 경로가 빠진 구현을 자주 보게 되는데, 이곳이 안전밸브 역할을 합니다.

독립적인 작업을 동시에 실행하고, 합류점에서 하나로 모읍니다.

레이턴시(latency)를 낮추기 위한 목적과, 여러 관점을 얻기 위한 두 가지 용도가 있습니다. 다만 비용 구조에 주의가 필요합니다.

In situations where parallel workers would require the same context in order to complete a task, you would be paying more for lower latency since you'd be processing the context multiple times across each parallel worker.

（병렬 워커가 태스크를 완료하기 위해 동일한 컨텍스트 (context)를 필요로 하는 경우, 각 병렬 워커에서 컨텍스트를 여러 번 처리하게 되므로 레이턴시를 낮추는 대신 더 많은 비용을 지불하게 된다）

— QA Wolf

동일한 컨텍스트 (context)를 5개 병렬로 전달하면, 컨텍스트의 토큰도 5배 청구됩니다.

망가지는 조건은 두 가지입니다. 브랜치 (branch)가 공유 상태에 동시에 쓰기 작업을 수행하는 것(경쟁 상태 (race condition))과, 가장 느린 브랜치가 속도의 상한선을 결정하는 것입니다. 5개 중 단 하나만 극단적으로 느리다면 병렬 처리의 의미가 거의 사라집니다.

구현 시 결정해 두어야 할 것은 실패 정책 (failure policy)입니다. "5개의 정보원 중 3개를 얻으면 진행할 것인가". 브랜치 단위의 타임아웃 (timeout)을 설정하고, 합류 노드 (join node)가 부분적인 결과에도 견딜 수 있도록 작성하며, 어떤 브랜치가 기여했는지를 기록합니다.

실행 시에만 작업 리스트가 확정되는 경우의 패턴입니다. 사령탑이 입력을 조사하여 동적으로 워커 (worker)를 깨웁니다.

API 마이그레이션 (API migration)이 전형적인 예시입니다. 어떤 파일이 오래된 API를 참조하고 있는지는 조사해 보기 전까지는 알 수 없습니다.

이 패턴에는 다른 4가지 패턴에는 없는 구조적인 위험이 두 가지 있습니다.

Fan-out width is unbounded by default.

（팬아웃 (fan-out)의 폭은 기본적으로 무제한이다）

The topology is non-deterministic.

（토폴로지 (topology)가 비결정적이다）

폭이 무제한이라는 것은, 사령탑이 "120개의 파일을 찾았습니다"라고 하면 120개의 워커가 깨어난다는 뜻입니다. 토폴로지가 비결정적이라는 것은, 동일한 입력이라도 다음번에는 다른 형태의 그래프가 된다는 것이므로 재현 가능한 디버깅을 할 수 없다는 뜻입니다.

대책으로 제시된 것은 폭, 깊이, 지출에 명시적인 상한을 두는 것, 서브트리 (subtree) 전체에 토큰 예산을 할당하는 것, 그리고 사령탑이 세운 계획을 영구적인 결과물로 저장하는 것입니다. 마지막 방법이 효과적입니다. 그래프의 형태가 매번 바뀐다면, 해당 회차의 형태를 기록해 두지 않으면 나중에 추적할 수 없습니다.

생성 노드 (generation node)가 만들고, 평가 노드 (evaluation node)가 기준에 비추어 검토하며, 불합격이라면 루프 (loop)를 돌립니다.

이 그림의 오른쪽에 4가지 정지 조건 (stopping condition)을 나열한 이유는, QA Wolf의 기사에서 이 부분을 가장 비중 있게 다루었기 때문입니다. 이 패턴이 망가지는 원인은 거의 정지 조건의 부족 때문입니다.

"최대 5회까지"라고만 설정한 구현을 자주 보게 되지만, 그렇게 하면 진동 (oscillation)을 탐지할 수 없습니다. 동일한 두 상태를 왕복하며 5회를 다 쓰고 종료될 뿐입니다.

또 다른 중요한 지적이 있었습니다. 평가 노드에는 **외부의 결정적인 평가기 (deterministic evaluator)**를 사용해야 한다는 것입니다. 테스트 스위트 (test suite), 스키마 검증 (schema validation), 수치 임계값 (numerical threshold) 등 모델의 판단이 아닌 것들을 말입니다.

이 이유가 다음 섹션의 가장 까다로운 문제로 이어집니다.

이 다섯 가지는 서로 배타적인 것이 아닙니다. Anthropic 스스로도 이것들은 규범이 아니라 "개발자가 유스케이스 (use case)에 맞춰 형태를 바꾸고 조합할 수 있는 공통 패턴"이라고 말합니다. 예를 들어, Routing 뒤에 Prompt Chaining (프롬프트 체이닝)이 이어지거나, Orchestrator-Workers (오케스트레이터-워커)의 워커 계층에 Evaluator-Optimizer (평가자-최적화 도구)가 포함될 수 있으며, Parallelization (병렬화)은 그 어떤 내부에도 배치할 수 있습니다 (이러한 조합 방식은 저자가 정리한 것입니다).

"Graph Engineering (그래프 엔지니어링)"이 실천적 측면에서 가리키는 것은 대개 이러한 합성(composition)을 의미합니다.

개념만으로는 파악하기 어려우므로 구현 사례를 보겠습니다. LangGraph는 Graph Engineering이라는 용어가 생겨나기 2년 전부터 이 모델을 구현해 온 라이브러리입니다 (LangChain 발표 수치에 따르면 월간 6,500만 회 이상 다운로드되고 있습니다).

먼저, 상태 (state)의 정의입니다. 에지 (edge) 위를 흐르는 객체를 여기서 결정합니다.

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver
...

포인트는 세 가지입니다.

• revision_count를 상태에 포함함 — 중단 조건을 판단하기 위해 시도 횟수가 상태로서 흘러가야 합니다.
• evaluator_approved와 human_approved를 분리함 — 기계의 합격과 인간의 승인은 별개의 것입니다.
• total=False — 중간 노드에서는 일부 키 (key)만 채워집니다.

다음으로, 노드 (node)를 정의합니다. 노드는 상태를 받아 업데이트된 부분을 반환하는 함수입니다.

def planner_node(state: ResearchState) -> ResearchState:
    # LLM 호출 등
    return {"plan": response.content, "revision_count": 0}

반환하는 것이 상태의 **차분 (diff)**이지 전체가 아니라는 점이 LangGraph의 사용감입니다.

그리고 배선 (wiring)합니다.

builder = StateGraph(ResearchState)
builder.add_node("planner", planner_node)
builder.add_edge(START, "planner")
...

add_edge가 고정 에지 (fixed edge)이고, add_conditional_edges가 조건부 에지 (conditional edge)입니다. route_function이 상태를 보고 다음 노드 이름을 반환하며, routes_dict가 그 이름을 실제 노드에 대응시킵니다. 이 부분이 바로 앞서 "모델의 기분에 따라 결정되던 부분이 코드가 되는" 지점입니다.

checkpointer를 전달하면 실행 상태가 저장됩니다. 실행 시에는 스레드 ID (thread ID)를 지정합니다.

config = {"configurable": {"thread_id": "workflow-001"}}
result = graph.invoke({"topic": "..."}, config=config)

이를 통해 중간에 멈췄다가 나중에 재개하거나, 상태를 들여다볼 수 있습니다. 장시간 실행되는 에이전트 (agent)의 경우, 이것이 없으면 운영이 어려워집니다.

또 하나, LangGraph에는 Send API라는 메커니즘이 있습니다.

lets a node route work to one or more downstream nodes dynamically, without statically defining every transition

(모든 전이를 정적으로 정의하지 않고도, 노드가 하나 이상의 하류 노드로 작업을 동적으로 라우팅할 수 있게 합니다)

— LangChain

이것이 Orchestrator-Workers 패턴의 구현 수단이 됩니다. "120개의 파일이 발견되었으므로 120개의 워커를 할당한다"는 것을 사전에 작성하지 않고도 실현하기 위한 것입니다 (그렇기 때문에 앞서 언급한 상한선 설정이 필요합니다).

이 부분이 이 글에서 가장 쓰고 싶었던 대목입니다.

그래프로 만들면 검증 노드를 늘릴 수 있습니다. 감사 (audit) 노드도 배치할 수 있습니다. 서로를 체크하는 구조를 만들 수 있습니다. 얼핏 보기에는 견고해진 것처럼 보입니다.

여기에 딱 들어맞는 것이 Carlos E. Perez 씨의 지적입니다. Louis Bouchard 씨는 Perez 씨의 주장을 다음과 같이 요약합니다.

"가장 훌륭한 통찰은 Carlos Perez로부터 나왔으며, 이는 기억할 가치가 있습니다. 에이전트가 에이전트를 체크하는 그래프는 극도로 정돈된 넌센스 (nonsense)를 만들어낼 수 있습니다."

(가장 좋은 지적은 Carlos Perez로부터 왔다. 기억해 둘 가치가 있다. 에이전트가 에이전트를 체크하는 그래프는 극히 정연한 넌센스를 생성할 수 있다)

왜 그렇게 되는 걸까요? Bouchard 씨의 설명에 따르면, 모델은 자신의 출력을 선호하는 경향이 있습니다. 따라서 동일한 모델 위에 구축된 에이전트들이 동일한 결함이 있는 컨텍스트 (context)를 읽게 되면, 추론이 틀렸더라도 서로를 검증해 버리는 것입니다.

Perez 씨 본인은 이를 "순환 그래프 (circular graph)" 문제라고 기술했습니다. 그래프를 구성하는 것만으로는 다음과 같은 상태가 됩니다.

"This graph is circular: an elaborate network of mutual confirmation in which everything is consistent and nothing is verified." (이 그래프는 순환적이다. 모든 것이 일관되지만 아무것도 검증되지 않는, 정교한 상호 확인의 네트워크다)

그리고 이어서 다음과 같이 썼습니다.

"Every loop watches another loop, and no loop touches the ground."

(모든 루프가 다른 루프를 지켜보고 있지만, 어떤 루프도 지면에 닿아 있지 않다)

토폴로지 (topology)만으로는 현실과의 접점을 살 수 없다는 지적입니다.

위의 상자는 모든 노드 (node)가 서로 합격 판정을 내리며 완결되어 있습니다. 대시보드 상으로는 모두 초록색입니다. 아래의 상자에는 논쟁의 여지가 없는 외부 증거와 연결되는 굵은 선이 있습니다.

Perez 씨는 단일 루프가 붕괴되는 4가지 구조적 실패도 정리했습니다. 이는 그래프로 만든다고 해서 사라지지 않습니다.

Perez 씨가 든 예시가 매우 생생하여 인용합니다. 지원 팀이 티켓 해결률을 최적화하는 피드백 루프 (feedback loop)를 봇 (bot)에 구축했습니다.

"The bot learned to resolve tickets by deflecting them: closing conversations quickly, discouraging follow-ups, marking problems solved that were merely abandoned." (봇은 티켓을 회피함으로써 '해결'하는 법을 학습했다. 대화를 빠르게 종료하고, 후속 문의를 저지하며, 단순히 방치된 문제들을 해결된 것으로 표시한다)

갱신율 데이터를 보면 고객들이 이전보다 두 배나 빠른 속도로 이탈하고 있었습니다. 해결률 그래프는 아름답게 계속 상승하고 있었던 것입니다.

그래서 Perez 씨는 그래프 구조로서 다음 4가지를 포함해야 한다고 말합니다.

그리고 토폴로지를 넘어 필요한 것이 바로 **앵커 (anchor)**입니다. 논쟁할 수 없는 측정값. 실제 매출, 테스트 결과, 고객 유지율 등입니다. 추가로, "최적화 루프가 절대로 튜닝 (tuning)해서는 안 되는 규칙"으로서 동결되는 노드가 필요하다고도 적혀 있습니다.

Perez 씨의 결론은 이 용어 논쟁 그 자체에 대한 답이 되어 있었습니다.

이는 지속 가능한 축이 루프(loops) 대 그래프(graphs)의 문제가 전혀 아니었음을 시사합니다. 핵심은 근거가 없는지(ungrounded) 아니면 근거가 있는지(grounded)의 문제입니다. 즉, 개선 메커니즘이 어떤 형태를 취하든, 자신이 개선한다고 주장하는 현실에 계속해서 맞닿아 있는가 하는 점입니다.

루프인지 그래프인지는 본질이 아닙니다. 지면에 닿아 있는지가 본질이라는 것이 Perez 씨의 견해입니다.

Louis Bouchard 씨 또한 같은 결론에 도달했습니다. 수정을 위해서는 시스템 외부에 있는 결정적인 증거가 필요합니다. 실제로 실행된 테스트, 은행에 입금된 돈, 유지된 고객, 혹은 전문가인 인간 리뷰어와 같은 것들 말입니다.

이것이 앞서 Evaluator-Optimizer (평가자-최적화 도구)에서 "평가 노드에는 외부의 결정적인 평가기 (Evaluator)를 사용해야 한다"고 기술한 이유입니다. 모델에게 직접 채점하게 하면, 정돈된 헛소리 (orderly nonsense)로 가는 길을 열어주게 됩니다.