Orc Hwang's Wiki

개발 학습 기록과 기술 지식을 체계적으로 관리하는 개인 위키입니다.

Graph Engineering: Loop Engineering 다음, 에이전트의 일을 그래프로 설계하라

articles ai coding-agent llm orchestration
Loop에서 Graph로 — 루프는 그래프의 특수한 경우 Loop Engineering Graph Engineering 루프 단일 사이클 사람 설계 뒤로 향하는 엣지 = 루프 fan-out 조건 조건부 분기 fan-in 시작 노드 노드 합류 체크포인트(노드 경계) HITL 게이트(위험 지점)
레버리지가 "루프를 설계하는 사람"에서 "실행 그래프를 설계하는 사람"으로 한 번 더 이동한다 — 루프(왼쪽)는 사라지지 않고, 그래프의 뒤로 향하는 엣지 하나(오른쪽)로 흡수된다. fan-out·fan-in·조건부 분기·체크포인트·HITL 게이트가 그래프의 프리미티브다.

주요 출처

이 글은 한 편의 아티클 분석이 아니라, 2026년 상반기 Reddit·Hacker News·엔지니어링 블로그에서 “loop engineering 다음” 으로 반복 등장하는 graph engineering 흐름을 조사해 정의하고 정리하는 글이다. 참고한 주요 출처는 다음과 같다.

한 줄 요약 (TL;DR)

Graph engineering이란, 에이전트가 할 일을 하나의 무한 루프가 아니라 노드(node)와 방향 있는 엣지(edge)로 이루어진 명시적 그래프로 모델링하고 운영하는 규율이다. 각 노드는 LLM 호출이나 도구 실행 같은 한 단계이고, 엣지는 “다음에 무엇이 실행될 수 있는가”라는 전이 규칙이다. 여기에 타입된 상태(typed state)·조건부 엣지(conditional edge)·체크포인트(checkpoint)·human-in-the-loop 게이트·서브그래프(subgraph) 라는 다섯 프리미티브가 붙는다. loop engineering이 “에이전트를 프롬프트하는 루프를 설계하라”였다면, graph engineering은 그 루프가 프로덕션에서 부딪히는 벽(동시성 없음·비결정성·재개 불가)을 넘기 위해 루프를 그래프의 특수한 경우로 흡수한다. 핵심 통찰: 데이터 엔지니어링이 이미 10년 전에 파이프라인을 DAG로 다뤄 온 그 규율이, 이제 에이전트 세계에 도착하고 있다.

한눈에 보기

이 글의 척추는 하나의 진화 사슬이다 — 레버리지가 프롬프트에서 컨텍스트로, 루프로, 이제 그래프로 옮겨간다. 각 단계는 앞 단계를 부정하지 않고 감싼다: 그래프의 노드 안에 여전히 프롬프트가 있고, 그래프의 뒤로 향하는 엣지가 곧 루프다.

flowchart TD
    P["Prompt Engineering<br/>한 번의 프롬프트를 다듬는다"] --> C["Context Engineering<br/>모델이 보는 컨텍스트를 설계한다"]
    C --> L["Loop Engineering<br/>에이전트를 프롬프트하는 루프를 설계한다"]
    L --> W["루프가 프로덕션에서 부딪히는 벽<br/>동시성 없음 · 비결정성 · 노드 안에서 상태 유실 · 재개 불가"]
    W --> G["Graph Engineering<br/>일을 노드+엣지의 명시적 그래프로 모델링"]
    G --> G1["Typed State<br/>(계약을 정의 시점에 드러냄)"]
    G --> G2["Conditional Edge<br/>(라우팅을 코드로 명시)"]
    G --> G3["Checkpoint<br/>(노드 경계마다 저장 → 재개)"]
    G --> G4["HITL 게이트<br/>(위험 지점 앞에서 멈춤)"]
    G --> G5["Subgraph<br/>(재사용 가능한 조각)"]
    G1 --> R["루프는 사라지지 않는다<br/>= 뒤로 향하는 엣지 하나 (그래프의 특수 경우)"]
    G2 --> R
    G3 --> R
    G4 --> R
    G5 --> R
    R --> D["결론: 데이터 엔지니어링의 DAG 규율이<br/>에이전트 세계에 도착한다"]

왜 이 주제를 골랐나

나는 loop engineering 글 끝에, 프롬프트 엔지니어링 → AI-assisted engineering → loop engineering으로 레버리지가 이동한다고 정리했다. 그런데 loop engineering을 실제 프로덕션에 밀어 넣은 팀들의 회고가 2026년 상반기에 하나의 방향으로 수렴하기 시작했다 — “무한 루프(while True: prompt → tool → re-prompt)만으로는 프로덕션이 안 된다.” Reddit의 r/LLMDevs, Hacker News의 프레임워크 스레드, 그리고 여러 엔지니어링 블로그가 같은 단어를 꺼냈다: graph.

이 흐름이 흥미로운 이유는 두 가지다. 첫째, 이건 새 발명이 아니라 오래된 규율의 재수입이다. 데이터 엔지니어가 Airflow DAG로 파이프라인을 다뤄 온 방식(오케스트레이션·Airflow DAG)이 거의 그대로 에이전트 실행에 적용된다. 이 위키에 이미 그 토대 글이 있으니, 두 세계를 잇는 정리를 남길 좋은 기회였다. 둘째, loop engineering이 강조한 “검증은 위임되지 않는다”는 명제가 graph engineering에서는 HITL 게이트라는 구조로 굳는다 — 관점이 아니라 아키텍처가 된다.

핵심 내용

Graph Engineering의 정의

여러 출처를 관통하는 정의를 한 문장으로 모으면 이렇다.

Graph engineering은, ad hoc한 에이전트 체인을 타입된 상태·조건부 라우팅·체크포인트 실행·계층적 관찰가능성을 갖춘 명시적 방향 그래프(directed graph)로 대체하는 것이다. (Zylos Research, 2026)

질문 자체가 옮겨갔다. 2023~2024년의 물음은 “에이전트가 복잡한 일을 해낼 수 있는가?”였다. 2026년의 물음은 “우리가 그 실행 그래프를 어떻게 모델링하고 통치(govern)할 것인가?” 다. “할 수 있는가”에서 “어떻게 다스리는가”로의 이동 — 이게 graph engineering이라는 이름이 가리키는 성숙이다.

왜 루프는 벽에 부딪히는가

2023~2024년의 LLM 생태계는 에이전트를 사실상 화려한 for 루프로 다뤘다: 모델을 프롬프트하고, 도구 호출을 파싱하고, 실행하고, 다시 프롬프트한다. 이 패턴은 프로덕션에 들어가는 순간 벽에 부딪힌다. arXiv 2604.11378(From Agent Loops to Structured Graphs)과 여러 현장 회고가 짚는 실패 모드는 일관된다.

  • 동시성 제어가 없다. 순차 루프는 독립적인 작업도 한 줄로 세워 실행한다. 서로 의존하지 않는 두 서브태스크를 병렬로 돌릴 방법이 루프 안에는 없다.
  • 결정성이 없다. 루프는 매번 다른 경로로 흘러 같은 입력에 같은 실행 트레이스를 보장하지 못한다. 디버깅과 검증이 어렵다.
  • 노드 안에서 상태가 유실된다. 체크포인트는 노드 사이의 상태만 저장한다. 한 노드 안의 for 루프가 1만 건을 처리하다 API 레이트리밋이나 파드 축출(pod eviction)로 죽으면, 그 안의 진행분은 통째로 날아간다(Beyond For Loops, Data Science Collective).
  • 재개가 불가능하다. 오래 도는 워크플로가 중간에 죽으면 처음부터 다시 시작한다. 비싼 API 호출이 반복된다.

핵심은 이것이다 — loop engineering이 설계하라던 그 “루프”는, 프리미티브로서는 프로덕션의 무게를 견디지 못한다. 루프는 좋은 개념이지만, 나쁜 실행 모델이다.

노드 안에서 상태가 유실된다 — for 루프 vs fan-out 한 노드 안의 for 루프 fan-out으로 쪼갬 노드 for 1만 건 레이트리밋 · 파드 축출 → 죽음 노드 안 진행분 통째 유실 체크포인트는 노드 *사이*만 저장한다 fan-out 청크 분배 청크 1 청크 2 청크 3 죽음 그 청크만 재개 손실 지점이 노드 *밖*으로 밀려난다
체크포인트는 노드 *사이*의 상태만 저장한다. 그래서 한 노드 안의 for 루프가 1만 건을 돌다 죽으면 그 진행분은 통째로 날아간다(왼쪽). 같은 배치를 fan-out으로 쪼개면 노드 경계마다 체크포인트가 찍혀, 하나가 죽어도 그 청크만 재개하면 되고 손실 지점이 노드 밖으로 밀려난다(오른쪽).

그래프가 사는 것: 다섯 프리미티브

성숙한 프레임워크들(LangGraph, Temporal, Microsoft Agent Framework, Mastra)은 이름은 달라도 같은 다섯 프리미티브로 수렴한다(Zylos Research).

  • Typed State (타입된 상태): 느슨한 딕셔너리 대신 구조화된 상태 객체. 계약 위반을 정의 시점에 드러낸다.
  • Conditional Edge (조건부 엣지): 라우팅을 LLM의 자유 생성에 맡기지 않고, 상태에 대한 함수로 코드에 명시한다. “이 조건이면 리뷰 노드로, 아니면 배포 노드로.”
  • Checkpoint (체크포인트): 모든 노드 실행을 영속 저장소에 기록한다. 크래시 복구와 time-travel 디버깅이 가능해진다.
  • Human-in-the-Loop 인터럽트: 위험한 행동 앞에서 스레드를 잡아먹지 않고 멈춘다. 상태를 통째로 직렬화해 리뷰어에게 맥락을 넘긴다.
  • Subgraph (서브그래프): 재사용 가능한 그래프 조각. 복잡한 워크플로를 분해한다.

그리고 결정적인 사실 — 루프는 사라지지 않는다. 그래프에서 엣지는 뒤로도 향할 수 있고, 뒤로 향하는 엣지가 바로 루프다. 평범한 선형 체인은 루프를 못 만들지만 그래프는 만든다. 즉 graph engineering은 loop engineering을 부정하는 게 아니라, 루프를 그래프의 특수한 경우로 흡수한다.

반복되는 그래프 패턴

현장에서 검증된 패턴들도 이름을 얻었다(Zylos Research).

  • Hybrid Backbone (결정적 뼈대): 결정적 오케스트레이션이 흐름을 잡고, 특정 단계에서만 LLM 지능을 부른다. 완료되면 제어권이 뼈대로 돌아온다. Anthropic 계열 가이드가 “2026년의 승리 패턴”이라 부른 형태다.
  • Orchestrator-Worker: 플래너가 목표를 서브태스크로 쪼개 전문 워커들에게 병렬 분배하고, 결과를 종합한다.
  • Sequential Pipeline + Validation Gate: 각 단계 출력을 다음으로 넘기기 전에 검증하는 게이트. 잘못된 LLM 출력이 하류로 전파되는 걸 막는다.
  • Fan-Out / Fan-In: 청크 병렬화. 지연 시간이 전체 작업량이 아니라 가장 긴 가지의 깊이에 비례한다.
비결정적 노드를 결정적 뼈대로 감싼다 — Hybrid Backbone 특정 단계에서만 LLM 지능을 부른다 (비결정적) LLM 비결정 LLM 비결정 호출 복귀 호출 복귀 단계 1 단계 2 단계 3 단계 4 결정적 뼈대 — 흐름·라우팅은 예측 가능, 제어권은 늘 뼈대로 복귀 지능은 예측 불가능한 채로 두되, 그 지능이 흐르는 물길은 예측 가능하게 판다
Hybrid Backbone: 결정적 오케스트레이션이 흐름을 잡고, 특정 단계에서만 비결정적 LLM을 호출한 뒤 제어권을 뼈대로 되돌린다. graph engineering의 결정성은 노드 *내부*가 아니라 그래프 *구조와 라우팅*의 결정성이다.

현장 신호: 프레임워크와 커뮤니티

이 흐름은 담론이 아니라 코드로 나타나고 있다.

  • LangGraph — 2025년 10월 1.0(파괴적 변경 0), 2026년 4월 기준 GitHub 12.6만 스타. LLM-네이티브 그래프 오케스트레이션의 사실상 표준. durable execution·streaming·HITL·memory를 런타임으로 안정화했다.
  • Temporal — LLM 전용이 아닌 범용 durable execution. 멀티리전 복제에서 99.99% SLA. 엔터프라이즈 크래시 내성의 표준 선택지. (이 위키의 Postgres durable workflow(DBOS) 글이 같은 문제를 중앙 오케스트레이터 없이 푸는 반대편 접근이다.)
  • Microsoft Agent Framework 1.0 — 2026년 4월 GA. AutoGen과 Semantic Kernel을 합쳐 컴파일 타임 타입 안전 방향 그래프 엔진을 제공한다.
  • Hacker News — Statewright(비주얼 상태 기계로 에이전트를 신뢰 가능하게) 가 126포인트를 받았다. 형식적 상태 기계로 에이전트 행동을 제약하고, “실패 경로·재시도 루프·승인 게이트”를 시각적으로 드러낸다는 발상 — graph engineering의 커뮤니티 버전이다.

분석과 인사이트

여기서부터는 출처 요약이 아니라 내 관점이다.

  • 이건 “새 규율”이 아니라 데이터 엔지니어링의 귀환이다. graph engineering의 다섯 프리미티브를 데이터 엔지니어는 다른 이름으로 이미 안다. Typed state = 스키마, conditional edge = 브랜치 오퍼레이터, checkpoint = 태스크 경계 재시도, HITL 게이트 = 수동 승인 태스크, subgraph = SubDAG/TaskGroup. 내가 오케스트레이션 글에서 정리한 “DAG·스케줄링·idempotency·재시도”가 바로 이것이다. Airflow의 backfill·catchup·idempotency가 데이터 파이프라인에서 풀었던 문제를, 에이전트 프레임워크가 지금 다시 발명하고 있다. 에이전트 엔지니어가 배워야 할 다음 교과서는 새 LLM 논문이 아니라, 성숙한 워크플로 오케스트레이션의 20년 규율일지 모른다.

  • 단, 에이전트 그래프는 데이터 DAG와 결정적으로 다르다 — 노드가 비결정적이다. Airflow DAG의 노드는 (대체로) 결정적 함수다. 에이전트 그래프의 노드는 LLM 호출이라 같은 입력에 다른 출력을 낸다. 그래서 arXiv 논문이 강조하는 “결정성”은 노드 내부가 아니라 그래프 구조와 라우팅의 결정성이다. 즉 graph engineering의 진짜 기여는 비결정적 노드를 결정적 뼈대(hybrid backbone)로 감싸는 것 — 지능은 예측 불가능한 채로 두되, 그 지능이 흐르는 물길은 예측 가능하게 판다. 이건 Codex의 agent loop를 펼쳐 본 글에서 본 “하니스가 LLM을 부린다”는 구도의 상위 버전이다.

  • HITL 게이트는 loop engineering의 도덕을 아키텍처로 굳힌 것이다. loop engineering 글의 결론은 “검증·이해·책임은 위임되지 않는다(comprehension debt·cognitive surrender 경계)”였다. 그건 규범적 호소였다. graph engineering에서 그 호소는 그래프의 특정 엣지 앞에 놓인 인터럽트 노드가 된다 — 위험한 행동 앞에서 실행이 구조적으로 멈추고 사람의 승인을 기다린다. 관점을 코드로 강제한다는 점에서, 신뢰할 수 있는 Agentic AI 시스템의 reflection(생성·검증 분리)·guardrail이 그래프의 노드·게이트로 물화(物化)되는 셈이다.

  • maker/checker가 서브그래프가 된다. loop engineering이 말한 “생성 에이전트와 검증 에이전트를 분리하라”는 조언은, 그래프에서 생성 노드 → 검증 게이트 → (실패 시) 뒤로 향하는 엣지라는 재사용 가능한 서브그래프로 표준화된다. 조언이 패턴이 되고, 패턴이 프리미티브가 된다. 이 궤적 자체가 한 분야가 성숙하는 방식이다.

flowchart LR
    In["입력 상태"] --> Gen["생성 노드<br/>(maker · LLM)"]
    Gen --> Gate{"검증 게이트<br/>(checker)"}
    Gate -->|"통과"| Out["다음 노드로 전진"]
    Gate -->|"실패 → 재생성<br/>(뒤로 향하는 엣지 = 루프)"| Gen
    Gate -->|"N회 실패"| HITL["HITL 게이트<br/>(사람 승인)"]
  • 위험은 “그래프 과설계(over-graphing)”다. loop engineering에 loopmaxxing(루프 남발)이 있었듯, graph engineering에는 모든 것을 노드로 쪼개 관리 불가능한 그래프를 만드는 함정이 있다. 출처들의 메타 권고가 일관되게 절제를 말하는 이유다 — “작동하는 가장 단순한 아키텍처에서 시작하고, 충분히 계측하고, 관찰된 실패 모드에 반응해서만 복잡도를 더하라.” 에이전틱 코딩은 함정과 바이브 코딩과 에이전틱 엔지니어링이 경계한 과잉 자동화와 같은 자리다.

적용 포인트

  • 일회성이면 프롬프트, 반복이면 루프, 프로덕션이면 그래프. loop engineering 글의 “반복 가능한가?”에 한 단계를 더한다 — “실패해도 재개돼야 하는가? 병렬로 갈라지는가? 위험한 행동이 있는가?” 셋 중 하나라도 예면 루프가 아니라 그래프로 설계한다.
  • 상태를 딕셔너리가 아니라 타입으로 정의한다. 그래프의 첫 설계 결정은 노드가 아니라 노드들이 주고받는 상태의 스키마다. 여기서 계약을 못 박으면 하류의 절반이 자동으로 정리된다.
  • 라우팅을 LLM에게 맡기지 말고 conditional edge로 코드에 적는다. “매니저 에이전트가 자유 대화로 다음을 정하는” 구조 대신, 상태에 대한 명시적 분기 함수를 둔다. 비결정적 노드는 그대로 두되 물길은 결정적으로.
  • 노드 경계마다 체크포인트를 켜고, 노드 안에서 대량 반복을 돌리지 않는다. 1만 건 배치는 한 노드의 for가 아니라 fan-out으로 쪼갠다. 상태 유실 지점을 노드 밖으로 밀어낸다.
  • 위험한 엣지 앞에 HITL 게이트를 명시한다. 배포·삭제·외부 전송·비용 발생 행동 앞에 인터럽트 노드를 둔다. 검증 책임을 규범이 아니라 구조로 강제한다.
  • 데이터 엔지니어링 오케스트레이션을 교과서로 삼는다. DAG·idempotency·재시도·backfill을 오케스트레이션·Airflow 시리즈에서 먼저 익히면, 에이전트 그래프 프레임워크의 개념 절반은 이미 아는 것이다.
  • 관찰가능성을 처음부터 깐다. 토큰·지연·상태 diff·인터럽트를 노드 단위로 추적한다. 그래프는 계측 없이는 디버깅 불가능한 복잡도를 금세 만든다.

마무리

레버리지는 한 번 더 이동한다 — 프롬프트하는 사람에서, 루프를 설계하는 사람으로, 이제 실행 그래프를 설계하는 사람으로. 하지만 loop engineering이 그랬듯 graph engineering도 일을 줄여주지 않는다. 오히려 설계 대상이 “한 번의 대화”에서 “상태·전이·게이트·재개 정책을 가진 시스템”으로 커진다. 위임할 수 있는 것(생성·반복·병렬 실행)과 위임할 수 없는 것(구조·게이트·책임)을 가르는 안목은 그대로다 — graph engineering은 그 안목을 관점에서 아키텍처로 옮겨 적었을 뿐이다.

그리고 이 이야기의 가장 큰 아이러니는, 가장 새로워 보이는 규율이 사실 가장 오래된 규율의 귀환이라는 점이다. 에이전트를 그래프로 다스리는 법을 배우고 싶다면, 최신 프레임워크 문서를 열기 전에 데이터 엔지니어가 파이프라인을 DAG로 다스려 온 방식을 먼저 읽어라. 새 물결의 이름은 graph engineering이지만, 그 물이 흐르는 강바닥은 오래전에 파여 있었다.

더 읽어보기