「루프 다음은 그래프」라는 말을 들어도, 그리 놀랍지 않았다

AI 에이전트의 문맥에서,

루프 다음은 그래프다

라는 화제가 움직이기 시작했다. 발단은 Loop Engineering이라는 용어의 유래가 된 6월의 게시물과 동일한 Peter Steinberger 씨가, 2026년 7월 18일에 X에 던진 한 줄의 질문——"Are we still talking loops or did we shift to graphs yet?"——이다[1]. 본고는 이 질문에 대해 제어 공학(Control Engineering) 측면에서 답을 내놓으려는 시도이다.

여기서 말하는 그래프는 지식 그래프(Knowledge Graph)도 GraphRAG도 아니다. 처리 노드(Node)와 전이 조건(Transition Condition)을 가진, **폐로(Closed Loop)를 허용하는 유향 상태 전이 그래프(Directed State Transition Graph)**이다.

단순한 AI 실행 루프의 구조는 다음과 같다.

구현
↓
테스트
...

폐로가 하나 존재한다. 전전편(A)에서 해부한 것은 바로 이 단일 폐로의 반복계였다.

하지만 실제 소프트웨어 개발은 이 형태에 담기지 않는다.

분기(Branch)가 있다. 여러 개의 되돌아가는 지점이 있다. 사람에게 이관(Delegation)하는 과정이 있다.

다만, 여기까지는 도형의 이야기이며 비교적 자명하다. 분기와 여러 개의 되돌아가는 지점을 더하면, 루프가 도표상에서 그래프가 되는 것은 당연하다. 본고의 주장은 그곳에 있지 않다.

그래프화의 본질은 루프를 복잡하게 배선하는 것이 아니다. AI로부터 상태 전이의 결정권을 분리하여, 관측 가능한 증거에 기반한 외부의 감독계(Supervisory System)로 옮기는 것이다.

배선은 결과일 뿐이다. 결정권의 분리가 원인이다. 본고의 나머지 내용은 이 문장의 전개가 될 것이다.

솔직히 말하자면, 이 「루프가 그래프로 스며드는」 현상은 전편(B) 속에서 이미 일어나고 있었다. B의 훅(Hook) 설계도를 다시 확인해 보길 바란다——계약 FIX, 회전(Iteration), gate, 수리 검사, 수리와 거부의 분기, 비동기 드리프트(Drift) 감시, 정체 시의 독립 진단으로의 분기. 루프를 진지하게 운용하려고 한 시점에서, 도표는 저절로 그래프가 되어 있었다. 그리고 그 원인도 방금 언급한 것과 같다. 수리 검사와 정체 진단이라는 판정을 생성(Generation)의 외부로 뺐기 때문이다.

제어계 엔지니어의 관점에서 보면 순서가 반대로 보인다

임베디드 제어(Embedded Control)를 업으로 하는 입장에서 보면,

루프를 만들었다 → 복잡해졌다 → 그래서 그래프로 나아간다

라는 서사에는 조금 이상한 점이 있다.

제어 장치를 설계할 때는 처음부터 다음을 생각한다.

• 정상 상태 / 초기화 상태 / 대待 상태 / 실행 상태
• 이상 상태 / 복구 상태 / 정지 상태 / 수동 개입 상태
• 각 상태 간의 전이 조건

루프는 상태 전이 그래프 안에 존재하는 폐로 중 하나일 뿐이다.

따라서 AI 개발 세계에서 일어나고 있는 일은 새로운 실행 구조의 발견이라기보다,

단발적인 LLM 호출로는 실무를 표현할 수 없게 되어, 기존의 제어계가 처음부터 가지고 있었던 구조에 가까워지고 있다

라고 보인다. 순서가 반대인 것이다. 그래프가 나중에 발명된 것이 아니라, 루프가 먼저 너무 단순화되어 있었던 것이다.

한 가지 한정해 두자. 여기서 말하는 「제어」는 PID 제어와 같은 연속값의 피드백 제어(Feedback Control)가 아니다. 이산적인 이벤트 열(결과물의 생성, 검사의 합격 여부, 타임아웃)을 관측하고, 허용하는 상태 전이를 외부에서 제한하는——Ramadge–Wonham 방식의, 이산 사건계의 감독 제어(Supervisory Control)에 가깝다[2]. 「제어 공학」이라는 용어를 분위기상 사용하는 것이 아니라, 대응되는 이론은 이것이다.

제어 대상은 AI 단체가 아니다 —— plant는 개발 실행계 전체이다

📐 도출

제어계 엔지니어가 AI 개발 기반을 생각할 때, 소박하게는 다음과 같은 치환을 하고 싶어진다.

기존의 제어 대상 → AI 에이전트

나도 처음에는 그렇게 두었다. 하지만 이것은 너무 좁다. AI 자체는 결과물을 보유하지 않는다. 도구를 통해 코드베이스나 환경을 변경하며, 회전 사이에 지속되는 상태는 AI의 내부가 아니라 결과물·이벤트 이력·실행 환경·외부 서비스 측에 있다(전전편의 구멍 2에서 보았듯이, /clear로 지워지는 것은 AI 측의 추론 문맥뿐이며, 지워지지 않는 층은 전부 이쪽에 있다).

따라서 제어 대상(plant)은,

AI 실행 주체 ＋ 도구 ＋ 샌드박스(Sandbox) ＋ 영구 결과물 ＋ 외부 서비스

로 구성된 개발 실행계 전체이다. 감독 제어의 어휘와의 대응은 다음과 같다.

이 대응표의 최하단 행이 요점이다. 다만 정확하게 세 단계로 나누어 두어야 한다. 생성의 분포에는 개입할 수 있다——프롬프트, 모델 선택, 입력 결과물, 도구의 제한은 분포를 움직인다(전고 B에서 썼듯이, 분포는 움직인다). 하지만 개별 호출에서 어떤 출력이 실현될지, 그 출력의 정확성은 강제할 수 없다. 그리고 출력 후의 수리는 제어할 수 있다. 감독 제어 (Supervisory Control)의 프레임워크는 이 중간 단계를 제어 불가능한 사건으로 처음부터 포기하고, 양 끝——사전 분포에 대한 개입과 사후 수리——만을 설계한다. 이를 AI 언어로 번역하면 다음과 같다.

감독계는 AI에게 올바른 출력을 강제할 수 없다. 할 수 있는 것은 관측된 결과에 따라 어떤 상태 전이 (State Transition)를 허용할지 제한하는 것뿐이다.

이는 앞선 세 편의 글의 중심 명제——생성을 속박하는 것이 아니라, 수리를 속박한다——와 완전히 일치한다. 전고 B에서는 확률적 생성기 (Probabilistic Generator)의 성질(동일성·약속·보증의 결여)로부터 도출한 결론에, 감독 제어는 '제어 가능한 사건과 제어 불가능한 사건의 분할'이라는 설계 원칙의 측면에서 도달한다. 두 분야가 서로를 모른 채 같은 선을 긋고 있는 것이다.

plant 안의 AI는 어떤 성질을 갖는가

📐 도출 (전전고 A의 각 도출을 재진술)

plant 전체 중에서 AI 실행 주체는 어떤 구성 요소인가. 운용하다 보면 다음과 같은 성질을 띠게 된다.

• 동일한 지시에도 출력이 흔들림
• 지시의 의미 해석이 변함
• 내부 상태를 직접 관측할 수 없음
• 제약 사항의 일부를 잊어버림
• 완료되지 않았음에도 완료되었다고 보고함
• 잘못된 전제로부터 일관적인 결과물을 만듦
• 동일한 수정과 실패를 반복함

이 목록은 전전고(A)에서 주사위 모델의 세 가지 오류로서 도출한 것과 일대일로 대응된다.

한 줄로 요약하자.

내부 상태를 충분히 관측할 수 없고, 특성이 실행마다 변동하며, 관측값의 일부를 자기 보고하는 구성 요소

제어의 상식으로서, 이러한 요소를 자기 보고만으로 제어할 수는 없다. 전전고가 주사위 비유로 말했던 것(1이 나와도 판면에는 7이라고 표시됨)을 제어 어휘로 다시 표현한 것이다.

왜 '필연적으로' 그래프인가 —— 조건부 도출

📐 도출

'실제 공정은 복잡하니까 그래프가 된다'는 것은 경험칙에 불과하다. 필연적이라고 말하기 위해서는 조건을 명시해야 한다. 다음 세 가지 조건을 둔다.

• 공정 상태가 순환을 넘어 지속된다 (결과물과 이력이 다음의 입력이 됨)
• 평가 결과에 따라 전이 대상이 여러 개 존재한다 (계속, 재시도, 설계로의 되돌리기, 사람에게 이양)
• 전이 대상을 실행 주체 이외의 존재가 결정한다 (전절까지의 귀결)

이때 계(System)를 기술하는 데 필요한 것은 다음과 같은 상태 전이 함수 (State Transition Function)이다.

다음 상태 = δ(현재 상태, 관측 이벤트)

전이 대상이 항상 한 종류라면 이 함수는 선형 열(또는 단일 루프)로 퇴화하며, 그래프를 끌어들일 필요가 없다. 조건 2에 의해 전이 대상이 여러 개가 되는 순간, 상태와 조건부 전이를 제1급 대상 (First-class object)으로 다룰 수밖에 없게 되며, 그 명시적인 표현이 바로 상태 집합과 라벨이 붙은 전이를 가진 유향 그래프 (Directed Graph)가 된다 (전이표나 전이 함수의 열거로도 같은 계를 쓸 수 있지만, 필연적인 것은 그래프라는 그리기 형식이 아니라 상태와 조건부 전이의 제1급화이다). 폐로(Cycle)는 재시도와 되돌리기가 있는 한 자연스럽게 발생한다. 따라서 '폐로를 허용하는 유향 상태 전이 그래프'이며, 다중 폐로는 설계의 결과이지 정의의 요건은 아니다.

즉, '루프 다음은 그래프'는 유행이 아니라 세 가지 조건을 만족하는 계의 자연스러운 표현에 관한 이야기다. 조건 1과 2는 실무적 요청이며, 조건 3은 전절에서 도출한 감독 제어의 요청이다. 그래프는 이 세 가지 합류점에 나타난다.

공정 상태를 '결과물'이라는 관측점으로 읽기

📐 도출

AI의 내부 상태는 관측할 수 없다. 그래서 관측 대상을 바꾼다——관측하는 것은 AI가 참여하고 있는 개발 공정의 상태이다.

이를 위해 각 공정에서 AI가 출력해야 할 결과물을 정의해 둔다.

요구 분석 상태 → 요구 목록, 제약 목록, 미확정 사항 목록
설계 상태 → 로버스트니스 다이어그램, 시퀀스 다이어그램, 인터페이스 정의
구현 상태 → 소스 코드, 변경 차분, 빌드 결과
...

전체 공정에서는 중간 산출물(Intermediate Artifacts)의 열이 그대로 관측점(Observation Points)의 열이 된다.

SPEC(요구 사양) → UC(유스케이스) → RBA(로버스트니스 분석)
→ SEQD(시퀀스 설계) → DD(상세 설계) → TS(테스트 사양)
→ TC(테스트 케이스) → SRC(소스 코드)

각 산출물은 본래의 작업 결과인 동시에,

• 어느 공정에 도달했는가
• 전 공정의 정보가 계승되고 있는가
• 어디에서 의미가 변질되었는가
• 어느 공정으로 되돌아가야 하는가

를 외부에서 판단하기 위한 관측점으로서 기능한다. 설계서가 존재한다고 해서 설계가 완료된 것이 아니다. 감독계(Supervisory System)가 「필요 산출물의 존재 + 형식 + 전 단계 산출물과의 대응 + 완료 조건」을 확인했을 때만, 다음 상태로의 전이를 **인정(Certify)**한다.

산출물을 만들지 않고 대화 이력만으로 공정을 진행하면, 외부에서 상태를 관측할 수 없어 현재 위치도 되돌아갈 지점도 판단할 수 없게 된다. /clear로 끊어낼 수 없는 층(산출물)에 문제가 거주한다면, 그 층을 처음부터 관측 가능한 형태로 설계해 두는 것이 이치에 맞다. AI에게 장시간 일을 시킬수록 중간 산출물의 역할은 커진다.

덧붙여, 이 관측점이 관측하게 하는 것은 산출물에 투영되는 범위의 일탈뿐이다. 투영되지 않는 것에 대해서는 후술할 「보증하지 않는 것」에서 다룬다.

AI의 출력은 상태가 아니라, 전이 요구 이벤트이다

📐 도출 / ⬜ 스키마 상세는 미검증

산출물을 고정한다고 해서 매번 같은 문장을 출력하게 하는 것은 아니다. 고정하는 것은 출력물의 계약(Contract)——산출물의 종류, 입력 산출물, 식별자, 필수 항목, 미결 사항, 검사 결과, 에러 정보, 전이 요구——이다.

여기서 표현에 주의가 필요하다. 처음에 나는 AI에게 "reported_state": "design_completed"와 같은 **상태(State)**를 보고하도록 하는 설계를 생각했다. 하지만 이는 본고 스스로가 그은 선——AI가 주장하는 상태 ≠ 시스템이 인정한 상태——과 맞지 않는다. AI가 가질 수 있는 것은 추론상의 내부 상태일 뿐, 공정상의 인정된 상태가 아니다. 인정된 공정 상태를 확정하는 권한은 감독계만이 가지며, AI 실행 주체에게는 부여하지 않는다. 따라서 AI가 낼 수 있는 것은 상태의 선언이 아니라, **상태 전이를 요구하는 이벤트(Event)**이다.

{
"event": "DESIGN_COMPLETION_REPORTED",
"from_state": "designing",
...

이 이벤트를 받아 감독계가 산출물의 실재와 수락 조건을 독립적으로 검사하고, 통과하면

DESIGN_ACCEPTED

를 발행하여, 비로소 인정 상태를 업데이트한다. 책임의 귀속은 다음과 같다.

AI가 내는 것 : 현상과 신고 (항상 claimed)
평가기가 내는 것 : 검사 결과
상태 관리자가 가진 것: 인정된 현재 상태

이는 전고(B)의 「신고와 재판의 분리」와 같은 수이다. B에서는 에지(Edge)에 claimed / mechanically-checked / semantically-sampled라는 검증 상태의 타입을 부여했다. 본고의 어휘로 말하자면, AI의 이벤트는 항상 claimed이며, 상태 전이의 실행을 위해서는 감독계에 의한 재판(Arbitration)으로의 승격이 필요하다——자기 작업의 올바름에 대한 신고를 본인이 독점하게 하지 않는다. 동일한 규율이 에지에도, 이벤트에도 적용된다.

상태 전이를 AI 스스로 결정하게 하지 않는다

📐 도출

AI에게 「구현한다 → 스스로 평가한다 → 스스로 완료를 선언한다 → 다음 공정으로 진행한다」라는 책임을 한꺼번에 맡기면, 제어 대상과 평가기와 상태 관리자가 동일해진다.

제어 기기로 말하자면, 액추에이터(Actuator)가 자기 자신을 측정하고, 스스로 정상 판정을 내리며, 스스로 인터록(Interlock)을 해제하는 구성이다. 오해 없도록 말하자면, 자기 진단 그 자체는 실제 안전 관련 시스템에도 존재하는 유용한 보조 관측이다. 문제는 자기 진단의 존재가 아니라, 실행 주체의 자기 신고만으로 정상 판정과 인터록 해제까지 완결되어, 독립된 보호층이 존재하지 않는다는 점에 있다. 그것은 보호가 없는 단일 장애점(Single Point of Failure)이다.

따라서 적어도 논리적으로는 다음의 책임을 나눈다.

실행 주체 ≠ 평가 주체 ≠ 상태 전이 결정 주체

이는 AI 에이전트라기보다, AI를 포함한 플랜트(Plant)를 대상으로 한 감독 제어 시스템이다. 전고 B의 언어라면, 규범의 위탁처를 생성기의 준수에서 수락 조건으로 옮기는 「재대상화(Re-addressing)」의 제어 공학적 표현이 이 삼분할이 된다.

전이 이력을 이벤트로 남긴다

📐 도출 / ⬜ 구현은 미착수

상태 전이를 더욱 명확히 하려면, 결과물의 생성이나 검사를 **이벤트 (Event)**로서 추가 전용(append-only)으로 기록한다.

SPEC_ACCEPTED
RBA_GENERATED
RBA_VALIDATION_FAILED
...

이벤트 열이 있다면 현재 상태뿐만 아니라 그곳에 이르는 경로도 재구성할 수 있다. 몇 번 실패했는가. 어디로 되돌아갔는가. 어떤 모델을 사용했는가. 어떤 결과물을 근거로 전이했는가. 어느 시점에 사람이 개입했는가.

이것이 필요해지는 이유는 전전고(前前稿)의 '구멍 3'이 보여준 바와 같다. 계통 오차(Systematic error)의 누적은 단일 회차의 국소 검사에는 원리적으로 나타나지 않으며, 오직 **주회 횡단 궤적 (Cross-cycle trajectory)**에만 나타난다. 이벤트 이력은 그 궤적을 제1급 감사 대상으로 만들기 위한 기록이며, 전고 B의 비동기 드리프트 감시(계통 a~d)가 읽는 것도 바로 이 이력이다.

구현의 언어로 말하자면, 이것은 새로운 구조가 아니라 이벤트 소싱 (Event Sourcing)적인 추가 전용 로그(이벤트 열을 정본으로 삼아 상태를 재구성한다——감사를 담당한다)와, durable execution의 재개 메커니즘(중단이나 장애 이후에 실행을 지속·재개한다——실행 보증을 담당한다)을 결합한 구조에 가깝다. 둘은 서로 다른 개념이지만, 동일한 추가 전용 로그 위에 올라간다. 실례도 있다. Anthropic의 Managed Agents는 세션(session)을 '발생한 모든 일의 추가 전용 로그'로서 외부화하며, harness나 sandbox가 다운되어도 이벤트 이력으로부터 재개하는 구조를 채택하고 있다 [3]. 상태 전이 이력의 외부화는 감사를 위한 것뿐만 아니라, 실행 보증을 위한 인프라이기도 하다.

고장 모드를 두 종류로 나누기

📐 도출 / ⬜ 고장의 체계적 채집은 미완료

공정을 상태 전이 그래프로 파악하면, 실패를 **고장 모드 (Failure mode)**로 정의할 수 있게 된다. 다만 이를 통칭하여 'AI 고유'라고 부르는 것은 정확하지 않다. 두 종류로 나뉜다.

기존 계통으로부터 이어받은 고장 — 워크플로우 엔진이나 분산 시스템에 예전부터 존재하던 것:

• 타임아웃 (Timeout) / 데드락 (Deadlock) / 라이브락 (Livelock)
• 부분 업데이트 / 재시도 폭풍 (Retry storm)
• 권한 일탈 / 자원 고갈

AI에 의해 현재화·증폭되는 의미적 고장 — 본 3부작이 주로 다루어 온 것:

• 그럴싸한 가짜 완료 (필요한 결과물이나 검사 결과를 갖추지 못한 채 완료를 보고함)
• 잘못된 전제에 대한 고착 (같은 벽에 부딪히는 반복. 라이브락의 의미론적 버전)
• 상위 목적으로부터의 의미 드리프트 (Semantic drift) (국소 처리는 성립하고 있으나, 요구사항으로부터 표류함)
• 실행기와 평가기의 사각지대 상관관계 (동일 계열 모델이 같은 오전제를 공유함)
• 테스트의 구현 추종 (검증기가 피검증물 쪽으로 치우침)
• 검토되지 않은 대안 (변화로서가 아니라, 불변으로서 나타나는 편향)

전자에는 기존의 대책——시도 횟수 상한, 타임아웃, 변경량 상한, 비용 상한, 체크포인트 (Checkpoint), 롤백 (Rollback), 권한 분리——가 그대로 유효하다. 이는 완전히 이상 처리 설계의 영역이다. 후자가 본 3부작에서 계측(수락 검사, 드리프트 통계, 독립 평가, 샘플링 판정)을 구성해 온 영역이며, AI 개발 기반의 독자적인 부분은 바로 여기에 있다.

한 가지, 자신의 과거 원고에 대한 정정을 포함하여 한정한다. scope의 경로 대조가 기계적으로 차단되는 것은 허가 범위 외의 변경뿐이며, 동일한 허가 파일 내에서 정상적인 부분까지 망가뜨리는 과도한 수정은 막을 수 없다. 그것을 담당하는 것은 변경량 상한과 독립 평가·샘플링 판정 측이다. 기계적 대조의 보증 범위는 정의된 클래스의 내부로 한정된다——전고 B에서 내가 썼던 한정을 여기서도 적용한다.

그리고 또 하나의 구별. 위의 대책 목록 대부분은 방호 (Protection) (피해의 유계화)에 속하며, 계측 (Measurement) (일탈의 관측)에 속하는 것은 독립 평가와 이벤트 감사뿐이다. 방호와 계측은 대체 관계가 아니다. 고장 모드 표가 채워졌다고 해서 방호를 약화시키는 것은, 별고 C에서 경고했던 '센서가 있으니까 방화벽을 얇게 만든다'는 오류의 그래프 버전이 된다.

AI가 고성능이 되고 위임 범위가 넓어질수록, 외부의 제어 구조는 필요해진다

📐 도출 (위임 확대를 전제로 하는 조건부 주장)

AI의 성능이 올라가면 외부의 제어 구조는 불필요해지는 것일까.

먼저 솔직히 인정하자면, 내부 harness의 일부는 불필요해질 수 있다. 특정 모델의 약점을 보완하기 위해 도입했던 장치들——강제적인 컨텍스트 리셋, 세밀한 재시도 제어——는 다음 모델에서는 불필요한 짐이 되었다는 보고를 Anthropic 스스로가 하고 있다. 모델의 성장은 내부의 목발을 치우게 만든다.

하지만 본고의 주장은 내부의 이야기가 아니다. 여기서는 모델 성능의 향상에 따라 위임하는 책무와 권한도 확대된다는 운용을 전제로 한다. 성능이 올라갈수록, 더 장시간 작동할 수 있다. 더 넓은 범위를 변경할 수 있다. 더 많은 도구를 조작할 수 있다. 더 큰 책무를 맡길 수 있다. —— 그 결과, 이상 발생 시의 영향 범위도 확대된다.

단발적인 코드 보완(Code Completion)이라면, 틀리더라도 사람이 그 자리에서 알아챌 수 있다. 하지만 수 시간 동안 동작하며 여러 리포지토리(Repository)나 환경을 조작하는 AI에게 일을 맡긴다면, 감시, 제한, 상태 관리, 복구 설계가 필요해진다.

AI가 똑똑해질수록 제어가 불필요해지는 것이 아니다.

똑똑해진 만큼 더 넓은 범위를 위임한다면, 그 위임 범위에 비례하여 외부의 방호와 감독은 두터워지는 것이다.

제어 공학(Control Engineering)에서는 익숙한 관계다. 출력이 큰 액추에이터(Actuator)일수록 인터록(Interlock)은 엄중해진다. 얇아지는 것은 내부의 목발이고, 두터워지는 것은 외부의 울타리다 —— 이 두 가지를 혼동하면, "모델이 똑똑해졌으니 울타리를 치워도 된다"라는 잘못된 추론에 이르게 된다.

「루프의 다음」에 오는 것은 그래프만이 아니다 —— 실행 보증

⬜ 미검증(과제의 나열일 뿐, 해답은 아님)

공정이 그래프에 도달하면, 다음에 문제가 되는 것은 그래프를 그리는 방법이 아니다. **실행 보증(Execution Guarantee)**이다.

• 노드는 재실행 가능한가? 처리는 멱등(Idempotent)한가
• 중단 후 어디서부터 재개할 것인가? 부분적인 성과물을 어떻게 다룰 것인가
• 이벤트의 중복 전달을 전제로, at-least-once 실행을 어떻게 흡수할 것인가
• 외부로 향하는 비가역적 조작을, 롤백(Rollback)이 아닌 보상 처리(Compensating Transaction)로 어떻게 다룰 것인가
• 워크플로우(Workflow) 정의를 업데이트했을 때, 실행 중인 인스턴스를 어떻게 이행할 것인가
• 여러 AI 간에 상태를 어떻게 공유할 것인가
• 데드락(Deadlock)/라이브락(Livelock)을 어떻게 검출할 것인가? 자원 고갈을 어떻게 방지할 것인가
• 평가기(Evaluator) 자체의 이상을 어떻게 검출할 것인가
• 상태와 성과물의 불일치를 어떻게 수복할 것인가

분산 시스템(Distributed System) 경험자에게는 어디선가 본 듯한 문제들이 나열되어 있다. 다만 「평가기 자체의 이상」만은 기존의 분산 시스템보다 한 단계 더 깊다. 평가기가 LLM인 한, 그 이상 검출은 "확률적인 계(System)에서 확률적인 계를 감시하는" 재귀 안에 있으며, 결정론적인(Deterministic) 감시만으로는 닫히지 않는다(별고 C의 선언 3).

향후의 AI 에이전트 기반은 모델을 호출하기 위한 얇은 래퍼(Wrapper)가 아니라,

불확실한 실행 주체를 안전하게 장시간 운전하기 위한 런타임(Runtime)

으로 변화해 갈 것이라고 생각한다.

이 제어 구조가 보증하지 않는 것

📐 도출(별고 C의 요약)

제어의 언어로 번역하더라도, 별고 C에서 선언한 한계는 하나도 사라지지 않는다. 본고의 구조가 보증하지 않는 것들을 정리해 둔다.

• 관측점은 비치는 것만을 비춘다. 중간 성과물이라는 관측점을 「센서(Sensor)」라고 부르고 싶어지지만, 그것이 관측하게 하는 것은 성과물에 투영되는 범위의 일탈뿐이다. 투영되지 않는 의미 변화(질적 조건의 삭제, 경계 조건의 조용한 완화)는 어떤 관측점도 그냥 지나칠 수 있다(C 선언 1). 관측점은 예지 장치가 아니라, 검역의 창이다(C 선언 4).
• 차분에 나타나지 않는 편향은 이벤트 이력에도 나타나지 않는다. "수행되지 않은 변경", "검토되지 않은 대안"은 아무리 정밀한 이벤트 로그에도 기록되지 않는다(C 선언 2). 방어는 기록이 아니라 다양화(계통이 다른 평가기, 인간의 리뷰)이지만, 책무를 분리해도 사각지대의 상관관계는 제로가 되지 않는다.
• 평가의 중심에는 의미 판정이 남는다. 감독계가 결정론으로 무장되는 것은 주변부(존재, 형식, Scope, 수량)까지이며, "이 성과물은 요구사항의 올바른 구현인가"를 판정하는 자는 인간이든 LLM이든, 어찌 되었든 오류를 범할 수 있다(C 선언 3). 분리가 보증하는 것은 판정의 독립성 구조이지, 판정의 정확성이 아니다.
• 예후는 아직 말할 수 없다. 본고의 고장 모드 분류는 병리학의 목차 안일 뿐이며, "이 사건의 나열 뒤에 이 고장이 온다"라는 서명과 결과의 대응표는 비어 있다(C 선언 5).

요약 —— 두 갈래 길이 같은 구조로 수렴한다

AI에게 일을 반복하게 하는 것뿐이라면 루프로 충분하다. 하지만 상태가 회차를 넘어 지속되고, 평가 결과에 따라 전이 대상이 분기하며, 그 전이 대상을 실행 주체 이외의 존재가 결정한다면, 상태와 조건부 전이를 일급 객체(First-class object)로 다룰 수밖에 없으며, 그 자연스러운 표현은 폐로(Cycle)를 허용하는 유향 상태 전이 그래프(Directed State Transition Graph)가 된다.

따라서 구조는 다음과 같은 형태가 된다.

• 각 공정에서 출력하는 성과물을 **계약(Contract)**으로서 정의한다.
• AI의 출력을 **전이 요구 이벤트(Transition Request Event)**로서 받아들인다(신고).
• 성과물을 **독립 평가기(Independent Evaluator)**로 검사한다(판정).
• 검사 결과에 기반하여, **상태 관리자(State Manager)**가 공정 상태를 인정·갱신하고 전이 대상을 결정한다.
• 전이 이력을 추가 전용 **이벤트(Event)**로서 저장한다.

그리고 이 구조의 핵심은 배선(Wiring)이 아니다.

그래프화(Graphization)의 본질은 AI로부터 상태 전이(State Transition)의 결정권을 분리하여, 관측 가능한 증거에 기반한 외부의 감독계(Supervisory System)로 옮기는 것이다. 감독계는 AI에게 올바른 출력을 강제할 수 없다. 할 수 있는 것은 어떤 전이를 허용할 것인지에 대한 제한뿐이다.

앞선 세 편의 글은 통계와 계측의 측면에서 이와 동일한 지점에 도달했다. 즉, 생성기(Generator)의 약속에 맡기지 않고, 결과물 간의 관계와 수락 조건(Acceptance Condition)에 맡기는 것이다. 본고는 감독 제어(Supervisory Control)의 측면에서 그 지점에 도달했다. 개별 생성 결과의 실현을 처음부터 제어 불가능한 사건으로 포기하고, 제어 가능한 양 끝단(사전 분포에 대한 개입과 사후 수락·전이)만을 설계하는 것이다. 그리고 제안하는 측면에서도 같은 곳으로 움직이고 있다. Osmani는 후속작인 「Own the Outer Loop」에서 완료 판정을 모델의 자기 보고(Self-reporting)가 아닌 독립적인 검사(Inspection)에 두고, 외부의 판단 경계를 엔지니어가 소유하는 구조를 명시했다 [4]. 출발점이 다른 여러 관점이 동일한 하나의 구조를 요구하고 있다. 나에게 있어 이러한 수렴은 개별적인 설계 판단보다 더 강력한 확신의 근거가 된다.

모델의 내부(Inside)는 새롭다. 하지만 그 외부(Outside)에서 필요로 하는 것은 상태(State), 전이(Transition), 모니터링(Monitoring), 평가(Evaluation), 이상(Anomaly), 복구(Recovery), 인터록(Interlock)이다.

AI 에이전트 시대에 다시금 필요해지는 것은 AI를 똑똑하게 만드는 기술만이 아니다.

똑똑하지만 불확실한 대상을 포함하는 계(System)를 어떻게 운전할 것인가를 설계하는 기술

이라고 생각한다.

부록: 앞선 세 편의 글과의 대응표

본문에서는 내부 참조를 최소화했다. 네 번째 글부터 읽기 시작한 독자를 위해 대응 관계를 여기에 정리한다.

참고 문헌

• Addy Osmani, "Loop Engineering" (2026-06-07). https://addyosmani.com/blog/loop-engineering/

• Addy Osmani, "Own the Outer Loop" (2026-07-15). https://addyosmani.com/blog/own-the-outer-loop/

• Peter Steinberger, X 게시물 (2026-07-18) — 「루프 다음은 그래프」라는 질문의 원본 (URL은 공개 시 추가)

• Ramadge & Wonham, "Supervisory Control of a Class of Discrete Event Processes" (SIAM Journal on Control and Optimization, 1987)

• Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands". https://www.anthropic.com/engineering/managed-agents

• Anthropic, "Effective harnesses for long-running agents" (2025-11-26). https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

• 전전편 A 「Loop Engineering이 암묵적으로 가정하고 있는 것」 / 전편 B (대책편) / 별편 C (한계 선언편) — 링크는 공개 후 추가

Peter Steinberger, X 게시물 (2026-07-18). 「아직 루프 이야기를 하고 있는가, 아니면 이미 그래프로 이행했는가」라는 취지의 질문 ↩︎

Ramadge & Wonham, "Supervisory Control of a Class of Discrete Event Processes" (SIAM J. Control Optim., 1987) ↩︎

Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands". https://www.anthropic.com/engineering/managed-agents ↩︎

Addy Osmani, "Own the Outer Loop" (2026-07-15). https://addyosmani.com/blog/own-the-outer-loop/ ↩︎

Discussion