LangGraph를 쓰며 생긴 의문: Graph Engineering은 워크플로우 엔진과 무엇이 다른가
LangGraph를 쓰면서 이상하게 느낀 점이 있었습니다.
먼저 그림으로 잡을 핵심: 왼쪽 주황색 Loop에서는 모델이 생각하고 행동하고 관찰하며 다음 행동을 고릅니다. 오른쪽 파란색 Graph에서는 시스템이 허용된 순서, 검증, 사람 승인을 관리합니다. Graph Engineering의 질문은 “어느 쪽이 더 좋은가?”가 아니라 가운데 경계를 어디에 둘 것인가입니다.
처음에는 agent의 자율성이 중요하다고 생각했습니다. 모델이 상황을 보고 도구를 고르고, 계획을 바꾸고, 필요하면 다시 시도하게 만드는 것이 agent다운 설계라고 봤습니다. 그런데 실제 서비스를 만들수록 반대 방향으로 움직이게 됐습니다.
출처가 부족하면 다음 단계로 넘어가지 못하게 했습니다. 검증에 실패했을 때 돌아갈 곳과 재시도 횟수를 정했습니다. 사람의 승인이 없으면 발행이나 배포를 하지 못하게 막았습니다. 자율적인 agent를 만들려고 시작했는데, 운영 규칙은 점점 더 고정된 graph가 됐습니다.
그러면 이런 질문이 남습니다.
그래프를 고정할수록 기존 워크플로우 엔진과 비슷해지는데, Graph Engineering은 대체 무엇이 다른가?
관련 자료와 구현 사례를 따라가 보니 핵심은 그래프의 모양이 아니었습니다. 어떤 판단을 모델에게 맡기고, 어떤 판단은 시스템이나 사람이 통제할지 정하는 일에 가까웠습니다.
이 관점에서는 node도 단순한 기능 묶음으로만 보이지 않습니다. 중요한 node는 결정권의 주인이 바뀌는 경계입니다. 모델이 탐색할 구간, 코드가 규칙을 강제할 구간, 사람이 최종 책임을 질 구간을 나누는 것입니다.
이 글에서는 이 생각이 어디까지 맞는지 살펴보고, Loop·Graph·기존 워크플로우 엔진·Claude Code·Harness의 관계를 코드로 풀어보겠습니다.
갑자기 등장했지만, 갑자기 발명된 것은 아니다
2026년 7월 22일 LangChain은 Graph Engineering을 다룬 공식 글을 공개했습니다. 흥미롭게도 LangChain부터 이 표현이 X에서 등장한 최신 buzzword라는 점을 인정합니다. Agent system을 graph로 표현하는 발상도 새롭지 않다고 말합니다.
대신 한 가지 실질적인 변화를 짚습니다. 예전에는 graph의 node 하나가 함수나 단일 LLM 호출인 경우가 많았습니다. 이제는 Claude Code 같은 coding agent나 deep research agent 전체를 node 하나로 넣을 수 있을 만큼 agent가 유용해졌다는 것입니다.
과거
함수 → LLM 호출 → 도구 호출 → 결과
현재
자료 수집 코드
→ [스스로 계획하고 도구를 쓰는 research agent]
→ 검증 코드
→ [코드를 수정하고 테스트하는 coding agent]
→ 사람 승인Graph가 새로워진 것이 아니라 graph 안에 넣을 수 있는 부품의 수준이 달라진 셈입니다.
학술 연구에서는 Graph Engineering 대신 Agentic Computation Graph 같은 표현이 더 명확합니다. 2026년 워크플로우 최적화 조사 논문은 LLM 호출, 검색, 도구 사용, 코드 실행, 메모리, 검증이 연결된 실행 구조를 Graph로 봅니다.
지금의 Graph Engineering은 엄밀한 표준명이라기보다 여러 agent 설계 문제를 한꺼번에 가리키는 산업 용어로 보는 편이 정확합니다.
시간대로 보면: Loop가 커지면서 Graph가 보이기 시작했다
Graph Engineering이라는 이름이 2026년에 유행했다고 해서 관련 기술이 그때 생긴 것은 아닙니다. 흐름을 간단히 줄이면 이렇습니다.
| 시기 | 당시의 중심 질문 | 구조의 변화 |
|---|---|---|
| 2022~2023 | 모델이 생각만 하지 않고 실제 행동하게 하려면? | ReAct식 판단 → tool → 관찰 loop, reflection과 tree search |
| 2024 | 여러 tool과 agent를 어떻게 조합하고 평가할까? | routing, parallel worker, evaluator, node·edge 표현 |
| 2024~2025 | 사람이 짠 실행 흐름을 어떻게 개선하고 오래 실행할까? | 실행 흐름 탐색, 중간 저장, 작업 대기 목록, 사람의 검토 |
| 2025 | 요청마다 달라지는 작업을 어떻게 병렬 처리할까? | 실행 중 만들어지는 작업 Graph와 선후 관계를 아는 작업 배분기 |
| 2026 | 설계와 실제 실행을 어떻게 구분하고 관찰할까? | 기본 Graph, 요청별 Graph, 실제 실행 기록 분리; Graph Engineering 용어 확산 |
그림을 읽는 법: 2022년부터 2026년까지 모델 자체만 발전한 것이 아닙니다. ReAct는 모델의 판단과 도구 사용을 반복문으로 연결했습니다. 이후 연구들은 평가, 도구의 선후 관계, 병렬 작업, 중간 저장, 실행별 Graph를 반복문 바깥의 구조로 꺼냈습니다. 그래서 2026년의 Graph Engineering은 갑자기 생긴 새 알고리즘보다, 커진 Agent Loop를 운영하기 위한 설계 문제에 붙은 이름에 가깝습니다.
ReAct의 최초 제출일은 2022년 10월입니다. 2024년 GPTSwarm은 agent를 개선할 수 있는 단계와 연결선으로 표현했습니다. 2026년 ACG survey는 여러 실행에 재사용하는 기본 Graph, 이번 요청에서 만들어진 Graph, 실제 실행 기록을 구분했습니다. 2026년 7월에는 MyAG와 LangChain의 Graph Engineering 글이 연이어 나왔습니다.
즉 시대의 흐름은 loop를 버리고 graph로 교체가 아닙니다. Loop가 유용해져 더 큰 일을 맡기자, loop 바깥의 분기·검증·병렬 실행·재개를 명시적으로 설계할 필요가 커진 것입니다.
여기서 말하는 graph는 무엇인가
가장 단순한 graph는 세 가지로 구성됩니다.
State: 지금까지 무엇을 알고 있고 어떤 단계까지 왔는가Node: 실제로 어떤 일을 수행하는가Edge: 다음에는 어디로 갈 것인가
LangGraph 공식 문서도 이 세 요소로 agent의 실행 흐름을 설명합니다. Node는 현재 상태값을 받아 일을 하고 상태를 바꿉니다. Edge는 그 결과를 보고 다음 단계를 정합니다.
기존 워크플로우 엔진과 다른 점은 무엇일까
LangGraph를 쓰다 보면 자연스럽게 이런 의문이 생깁니다. 서비스를 안정화할수록 그래프를 고정하게 된다면, 기존 워크플로우 엔진과 무엇이 다를까요?
짧게 답하면 기술의 뿌리는 크게 다르지 않습니다. 상태, 실행 순서, 조건 분기, 재시도, 중단 후 재개는 기존 워크플로우 엔진도 오래 다뤄온 문제입니다. Graph Engineering을 완전히 새로운 실행 엔진의 종류라고 말하면 과장입니다.
강조점은 다릅니다. 기존 워크플로우는 대개 정해진 작업을 믿을 수 있게 실행하는 데서 출발합니다. Agent graph는 그 흐름 안에 결과를 완전히 예측하기 어려운 모델의 판단이 들어온다는 데서 출발합니다. 그래서 “다음에 무엇을 실행할까?”뿐 아니라 “이 판단을 모델에게 맡겨도 될까?”를 함께 정해야 합니다.
LangGraph의 Workflows and agents 문서는 workflow를 미리 정한 코드 경로로, agent를 스스로 절차와 도구 사용을 정하는 구조로 설명합니다. Anthropic의 Building effective agents도 비슷하게 workflow와 agent를 구분합니다. 이 두 자료를 함께 보면 Graph Engineering은 기존 워크플로우 엔진과 전혀 다른 기술이라기보다, 정해진 경로와 모델의 자율 판단을 한 시스템 안에서 어디까지 섞을지 다루는 설계 관점이라고 해석하는 편이 자연스럽습니다.
| 비교할 점 | 일반적인 워크플로우 설계 | Agent graph 설계에서 더 강조되는 것 |
|---|---|---|
| 중심 문제 | 정해진 작업을 빠짐없이 실행 | 불확실한 모델 판단을 어디까지 허용할지 결정 |
| 다음 단계 | 코드와 작업 정의가 주로 결정 | 모델이 고르는 구간과 코드가 강제하는 구간이 섞임 |
| 단계 안의 작업 | 함수, API 호출, 배치 작업 | 함수뿐 아니라 도구를 쓰는 agent 전체도 들어감 |
| 품질 확인 | 성공·실패, 반환값, 시스템 오류 | 근거 부족, 잘못된 판단, 규칙 위반까지 따로 검증 |
| 운영 기록 | 작업 상태와 오류 | 어떤 판단을 내렸고 왜 그 경로로 갔는지도 기록 |
이 표는 두 기술의 기능을 딱 잘라 나누려는 것이 아닙니다. 기존 워크플로우 엔진도 모델 작업을 실행할 수 있고, LangGraph도 평범한 함수를 실행할 수 있습니다. 차이는 무엇을 가장 먼저 설계 질문으로 삼느냐에 있습니다.
Node를 ‘의사결정 권한 단위’로 본다는 뜻
기능만 보고 나누면 다음과 같은 graph가 나옵니다.
조사 → 작성 → 검토 → 발행이 구조는 무슨 일을 하는지는 보여주지만, 누가 중요한 결정을 내리는지는 감춥니다. 결정권을 기준으로 다시 나누면 경계가 더 분명해집니다.
[모델] 조사 방법과 검색어 선택
→ [시스템] 출처 수와 허용 도메인 확인
→ [모델] 근거를 바탕으로 초안 작성
→ [독립 검증] 근거 없는 주장 판정
→ [시스템] 재시도 횟수와 다음 경로 결정
→ [사람] 최종 승인
→ [코드] 발행 실행| 단계의 성격 | 결정권을 가진 주체 | 맡기기 좋은 판단 |
|---|---|---|
| 탐색 단계 | 모델 | 검색어 선택, 조사 순서, 코드 수정 방법 |
| 규칙 확인 단계 | 시스템 코드 | 최소 출처 수, 허용 경로, 비용·재시도 상한 |
| 품질 검증 단계 | 별도 모델 또는 규칙 코드 | 근거 일치, 테스트 결과, 작성자와 다른 관점의 검토 |
| 승인 단계 | 사람 | 법적·사업적 책임이 따르는 최종 판단 |
| 외부 실행 단계 | 시스템 코드 | 발행, 배포, 결제, 메일 발송 |
모든 node가 결정권의 경계일 필요는 없습니다. 데이터를 변환하거나 파일을 읽는 평범한 기능 단계도 필요합니다. 다만 비용·보안·승인·외부 실행과 연결된 판단은 누가 결정하고 누가 뒤집을 수 있는지 코드에 보여야 합니다.
예를 들어 기술 블로그를 만드는 과정을 graph로 표현하면 다음과 같습니다.
flowchart TD
A[사람: 목표와 금지선 결정] --> B[모델: 조사 방법 선택]
B --> C[시스템: 출처 기준 확인]
C -->|근거 부족| B
C -->|충분함| D[모델: 초안 작성]
D --> E[별도 검증: 근거와 품질 판정]
E -->|수정 필요| H[시스템: 재시도 가능 여부 확인]
H -->|가능| D
H -->|초과| I[차단 또는 사람에게 전달]
E -->|통과| F[사람: 최종 승인]
F --> G[코드: 발행 실행]
flowchart TD
A[사람: 목표와 금지선 결정] --> B[모델: 조사 방법 선택]
B --> C[시스템: 출처 기준 확인]
C -->|근거 부족| B
C -->|충분함| D[모델: 초안 작성]
D --> E[별도 검증: 근거와 품질 판정]
E -->|수정 필요| H[시스템: 재시도 가능 여부 확인]
H -->|가능| D
H -->|초과| I[차단 또는 사람에게 전달]
E -->|통과| F[사람: 최종 승인]
F --> G[코드: 발행 실행]이 그림의 핵심은 선이 많다는 데 있지 않습니다. 각 단계의 앞말, 즉 사람·모델·시스템·검증자가 어떤 결정을 맡는지가 중요합니다. 검증에서 반려된 글을 다시 고치는 반복도 생기므로, Agent graph는 한 방향으로만 흐르는 작업표보다 상태 머신에 가깝습니다.
Loop와 Graph는 적이 아니다
여기서 가장 헷갈리는 부분이 있습니다. Graph 실행기도 결국 반복해서 단계를 실행합니다. 차이는 반복문의 존재가 아닙니다.
Agent Loop에서는 모델이 다음 행동을 고릅니다. Graph에서는 모델이 고를 수 있는 범위와 시스템이 직접 결정할 구간을 나눕니다.
그림을 읽는 법: 왼쪽 Loop의 화살표는 모델의 다음 판단으로 이어집니다. 오른쪽 Graph의 화살표는 상태값과 전이 규칙이 허용한 경로로만 이어집니다. 둘 다 반복하지만, 다음 행동의 선택권이 어디에 있느냐가 다릅니다. LangGraph 공식 문서도 Graph를 State, Node, Edge로 설명하고, Edge가 현재 상태에 따라 다음 Node를 정한다고 명시합니다.
개발할 때 묻기: “이 판단을 모델이 틀려도 다시 고치면 되는가, 아니면 코드가 처음부터 금지해야 하는가?” 전자라면 Loop 안에 둘 수 있습니다. 승인 없는 발행, 예산 초과, 권한 밖 도구 실행처럼 후자가 중요하면 Graph의 허용 경로로 빼야 합니다.
같은 “근거를 조사해 기술 블로그를 쓰고 승인 후 발행하는 작업”을 코드로 비교해 보겠습니다.
하나의 agent loop가 전부 맡는 경우
TOOLS = {
"search": search_web,
"read": read_source,
"save_draft": save_draft,
"publish": publish_post,
}
history = [{"role": "user", "content": GOAL}]
for step in range(20):
action = agent.decide(history, tools=list(TOOLS))
if action.name == "finish":
return action.output
result = TOOLS[action.name](**action.args)
history += [action.as_message(), tool_message(result)]이 구조는 짧고 유연합니다. Agent는 검색을 몇 번 할지, 어떤 논문을 더 읽을지 스스로 정할 수 있습니다. Claude Code도 파일 읽기, 수정, 테스트를 이런 식의 관찰 loop로 이어갑니다.
그런데 코드만 보면 다음을 누가 보장하는지 불분명합니다.
- 출처가 하나뿐인데 초안을 쓰지 않았는가?
- 작성 agent가 자기 글을 스스로 통과시키지 않았는가?
- 사람 승인 전에
publish를 호출하지 않았는가? - 검토가 세 번 실패했을 때 무한히 수정하지 않는가?
- 18번째 step에서 process가 죽으면 어디서 재개하는가?
Prompt에 “반드시 지켜”라고 적을 수는 있습니다. 하지만 그 규칙은 model이 기억하고 따라주길 기대하는 상태입니다.
같은 작업을 graph-ready하게 만든 경우
먼저 각 단계가 누구의 판단을 따르는지 적어두면 설계가 선명해집니다.
class NodeRule(TypedDict):
decision_owner: Literal["model", "system", "human"]
allowed_results: set[str]
may_change_external_system: bool
RULES = {
"collect": NodeRule(
decision_owner="model",
allowed_results={"enough", "need_more", "blocked"},
may_change_external_system=False,
),
"source_gate": NodeRule(
decision_owner="system",
allowed_results={"pass", "blocked"},
may_change_external_system=False,
),
"publish": NodeRule(
decision_owner="system",
allowed_results={"published", "failed"},
may_change_external_system=True,
),
}decision_owner는 누가 자유롭게 판단하는지를 나타냅니다. allowed_results는 결과를 정해진 선택지 안에 가두고, may_change_external_system은 발행·배포처럼 되돌리기 어려운 작업을 따로 표시합니다. 실제 구현에서는 여기에 시간 제한, 비용 상한, 필요한 승인도 함께 둡니다.
그다음 실행 중 보존할 상태값을 정의합니다.
class State(TypedDict):
sources: list[SourceRef]
draft: ArtifactRef | None
review: Literal["unknown", "pass", "revise", "blocked"]
approved: bool
attempts: dict[str, int]
def collect(state: State) -> dict:
# 결정권: 모델. 이 단계 안에서는 자유롭게 조사한다.
return {"sources": research_agent.run(min_primary_sources=3)}
def verify(state: State) -> dict:
# 결정권: 별도 검증자. 결과는 정해진 판정값으로만 반환한다.
verdict = independent_verifier.check(
draft=state["draft"],
sources=state["sources"],
)
return {"review": verdict}
def publish(state: State) -> dict:
# 결정권: 시스템과 사람. 모델이 직접 호출하지 못하게 한다.
assert state["review"] == "pass"
assert state["approved"] is True
publish_post(state["draft"], idempotency_key=run_id)
return {"status": "published"}다음 경로는 모델의 자유 응답이 아니라 코드로 제한합니다.
def next_node(current: str, state: State) -> str:
if current == "collect":
return "write" if len(state["sources"]) >= 3 else "blocked"
if current == "verify":
if state["review"] == "pass":
return "human_approval"
if state["review"] == "revise" and state["attempts"]["write"] < 2:
return "write"
return "blocked"
if current == "human_approval":
return "publish" if state["approved"] else "waiting"
raise IllegalTransition(current)Graph 실행기도 보통 아래와 같이 각 단계를 반복 실행합니다.
while current not in {"done", "blocked", "waiting"}:
state |= NODES[current](state)
save_checkpoint(run_id, current, state)
current = next_node(current, state)둘의 차이가 이제 선명해집니다.
| 비교 | Agent Loop | Graph 실행기 |
|---|---|---|
| 반복 단위 | 모델 판단 → 도구 실행 → 결과 관찰 | 단계 실행 → 상태 변경 → 허용 경로 확인 |
| 다음 행동 | 모델이 도구 중 선택 | 전이 코드가 허용된 경로만 선택 |
| 상태 | 주로 대화 기록 | 항목과 형식이 정해진 상태값과 결과물 위치 |
| 실패 | 대화 안에서 스스로 복구 | 실패 종류별로 돌아갈 단계와 횟수를 제한 |
| 재개 | 세션과 대화 기록 복원에 의존 | 중간 저장 지점부터 재개 |
| 외부 작업 | 도구를 고르면 바로 실행될 수 있음 | 승인과 중복 실행 방지를 통과한 단계만 실행 |
한 줄로 줄이면 이렇습니다.
프롬프트로 부탁하던 순서와 금지 규칙을 상태값, 허용 경로, 중간 저장, 승인 코드로 옮기는 것.
Coding agent가 어떤 파일을 읽고 몇 번 테스트할지는 agent loop에 맡기면 됩니다. 다만 테스트를 통과하지 못한 코드는 PR을 만들 수 없고, 보안 변경은 사람 승인을 받아야 한다는 규칙은 graph 바깥 구조가 강제합니다.
요청 분류
→ [Claude Code의 자유로운 coding loop]
→ 테스트 gate
→ 보안 review gate
→ 사람 승인
→ PR 생성실무에서는 graph냐 loop냐를 고르는 것이 아니라, graph의 안전한 node 안에 agent loop를 넣습니다.
그림을 읽는 법: 바깥 Graph는 입력, 결과 형식, 검증, 승인, 실패 경로를 관리합니다. 안쪽 Loop는 조사나 코딩처럼 세부 경로를 미리 정하기 어려운 일을 맡습니다. LangChain도 현재의 변화로 “하나의 Node 안에 도구를 쓰고 스스로 반복하는 Agent 전체를 넣을 수 있게 됐다”는 점을 짚습니다. Anthropic 역시 효과적인 Agent 구축 가이드에서 정해진 코드 경로를 따르는 workflow와 모델이 절차와 도구 사용을 정하는 agent를 구분하고, 필요한 만큼만 복잡성을 늘리라고 권합니다.
개발할 때 묻기: Node 안의 Agent가 반환해야 할 결과 형식은 무엇인가? 몇 번까지 도구를 써도 되는가? 결과가 기준을 충족했는지는 누가 독립적으로 확인하는가? 이 세 질문에 답하지 못하면 Agent를 Node로 감쌌어도 통제 경계가 생긴 것은 아닙니다.
Claude Code와 Graph Engineering의 차이
Claude Code 공식 설명에 따르면 Claude Code는 모델이 실제 개발 도구를 쓸 수 있게 해주는 agent harness입니다. 모델 혼자서는 답을 만들 뿐이지만 Claude Code 안에서는 파일을 읽고, 코드를 수정하고, 명령과 테스트를 실행할 수 있습니다.
역할을 나누면 차이가 선명해집니다.
그림을 읽는 법: Claude 모델은 판단합니다. Claude Code와 Harness는 파일·명령·도구·권한이 있는 실행 환경을 제공합니다. Graph Engineering은 여러 실행을 어떤 순서로 연결하고 어디서 검증·중단·재개할지 정합니다. 세 개는 경쟁 제품이 아니라 서로 다른 질문을 다룹니다.
개발할 때 묻기: Agent가 일을 못 하는 원인이 모델의 추론 능력인지, 도구·권한·작업 정보가 부족한 Harness 문제인지, 잘못된 실행 순서와 검증 부재라는 Graph 문제인지 먼저 구분해야 합니다. 원인을 구분하지 않고 Graph Node만 늘리면 비용과 지연 시간만 커질 수 있습니다.
| 개념 | 주로 해결하는 문제 |
|---|---|
| Claude 모델 | 현재 상황에서 무엇을 판단할 것인가 |
| Claude Code | 모델의 판단을 파일 수정·명령 실행·테스트로 어떻게 옮길 것인가 |
| Agent Harness | 도구·권한·작업 정보·세션·비용 한도를 어떻게 제공할 것인가 |
| Graph Engineering | 여러 코드 단계와 Agent Loop를 어떤 순서·분기·검증으로 연결할 것인가 |
| LangGraph | 이 구조를 오래 실행하고 중단 지점부터 재개하는 데 쓸 수 있는 도구 |
즉 Claude Code는 Graph Engineering과 경쟁하지 않습니다. Graph 안에서 어려운 개발 작업을 담당하는 강력한 node가 될 수 있습니다.
Claude Agent SDK를 쓰면 Claude Code의 Agent Loop와 기본 도구를 Python이나 TypeScript 애플리케이션에 넣을 수 있습니다. Graph의 코딩 단계가 Agent SDK를 호출하고, 결과물과 상태만 다음 검증 단계로 넘기는 식으로 조합할 수 있습니다.
Harness Engineering과는 무엇이 다른가
Harness Engineering은 agent가 실제 환경에서 안전하고 꾸준하게 일하도록 작업 조건을 만드는 일입니다.
Anthropic은 장시간 실행 agent를 위한 harness 사례에서 대화 내용을 줄여 보관하는 것만으로는 부족하다고 설명합니다. 첫 세션에서 환경을 준비하는 agent, 전체 기능 목록, 작업 진행 파일, Git 기록이 있어야 다음 세션이 이전 작업을 제대로 이어갈 수 있었습니다.
Harness가 이런 질문을 다룬다면,
- 어떤 도구를 허용할까?
- 위험한 명령은 어떻게 막을까?
- 작업 정보가 너무 많아지면 무엇을 보존할까?
- 이전 세션의 진척을 어떻게 넘길까?
- agent가 끝났다고 말했을 때 무엇으로 확인할까?
Graph Engineering은 이런 질문을 다룹니다.
- 환경을 준비하는 agent 다음에는 어떤 단계가 실행될까?
- coding agent가 끝나면 누가 검증할까?
- 테스트에 실패하면 어디로 돌아갈까?
- 몇 번 실패하면 사람에게 넘길까?
- 승인 전에는 어떤 외부 작업도 막아야 할까?
Harness가 “agent 한 명이 일할 작업실”을 만드는 일이라면, Graph는 여러 작업실과 검사대, 승인 창구를 어떻게 연결할지 정하는 일에 가깝습니다. 다만 실제 시스템에서는 Graph 실행기가 중간 저장과 권한 관리 같은 Harness 기능도 제공하므로 두 영역은 상당히 겹칩니다.
논문들은 어떤 불편에서 출발했을까
이 분야의 논문을 시간순으로 보면 “갑자기 graph가 좋아졌다”기보다 agent loop가 커지며 생긴 불편을 하나씩 구조로 꺼낸 과정에 가깝습니다.
- ReAct는 생각과 행동을 번갈아 실행해 외부 환경의 관찰을 다음 판단에 넣었습니다.
- Reflexion은 실패 평가를 언어 memory로 남겨 다음 시도에 사용했습니다.
- LATS는 한 경로만 전진하지 않고 후보들을 tree로 보존해 탐색하고 되돌아가게 했습니다.
- ControlLLM과 ToolNet은 도구가 많을 때 모든 설명과 순서 판단을 model에게 떠넘기지 않고, 도구의 입력·출력 관계와 가능한 다음 도구를 graph로 제한했습니다.
- GPTSwarm은 agent의 prompt와 정보 흐름을 node와 edge로 표현해 연결 구조도 최적화 대상으로 만들었습니다.
- ADAS와 AFlow은 사람이 workflow를 직접 조립하는 비용을 줄이기 위해 agent code나 workflow code 자체를 평가하며 탐색했습니다.
- DynTaskMAS는 여러 작업의 선후 관계와 병렬 실행을 dynamic task graph와 scheduler 문제로 다뤘습니다.
이 흐름에서 가장 중요한 변화는 agent 수가 아닙니다. 대화 기록 하나가 떠안던 책임을 형식이 정해진 상태값, 평가 결과, 후보 경로, 도구의 선후 관계, 작업 대기 목록, 중간 저장으로 나눈 것입니다.
Graph of Thoughts도 자주 함께 언급되지만 구분이 필요합니다. 이 연구의 Graph는 여러 중간 생각을 합치고 개선하는 추론 결과 Graph입니다. 서비스의 실행 순서와 재개를 담당하는 Graph와 관련은 있지만 같은 것은 아닙니다.
개발자가 실제로 만들어야 하는 것
Graph를 예쁘게 그리는 것부터 시작하면 실패하기 쉽습니다. 먼저 각 판단의 주인을 정하고, 그 경계를 상태값과 코드 규칙으로 만들어야 합니다.
새 단계를 만들 때는 네 가지를 먼저 묻는 편이 좋습니다.
- 이 단계에서 실제로 판단하는 주체는 모델, 코드, 사람 중 누구인가?
- 결과를 몇 개의 정해진 선택지로 제한할 수 있는가?
- 실패하면 어디로 돌아가며 몇 번까지 다시 시도하는가?
- 이 단계가 발행·배포·결제처럼 외부 상태를 바꾸는가?
구현 전에 답해야 할 질문
| 설계 질문 | Loop 안에 두기 쉬운 경우 | Graph·코드·사람이 통제해야 하는 경우 |
|---|---|---|
| 경로를 미리 아는가? | 조사·코딩처럼 다음 행동을 미리 모름 | 승인·배포처럼 순서가 정해져 있음 |
| 틀려도 되돌릴 수 있는가? | 검색어 선택, 초안 표현 | 결제, 발행, 권한 변경 |
| 실패를 코드로 판정할 수 있는가? | 정성 평가가 중심 | 테스트·출처 수·정책 규칙으로 판정 가능 |
| 누가 최종 책임을 지는가? | 모델의 제안으로 충분 | 법률·보안·사업 판단에 사람 책임 필요 |
| 중단되면 무엇을 보존해야 하는가? | 짧아 처음부터 다시 실행 가능 | 결과물·승인·시도 횟수에서 재개해야 함 |
| 같은 단계를 다시 실행해도 안전한가? | 읽기·분석만 수행 | 메일·배포·DB 변경이 중복될 수 있음 |
| 무엇을 관찰해야 하는가? | 최종 답만 보면 됨 | 단계별 비용·지연·판단 경로를 감사해야 함 |
이 표에서 오른쪽 답이 늘어날수록 단일 Agent Loop만으로 운영하기 어렵습니다. 다만 곧바로 LangGraph를 써야 한다는 뜻은 아닙니다. Python 조건문과 상태 머신으로 먼저 경계를 검증한 뒤, 장기 중단·부분 재실행·병렬 분기가 복잡해질 때 전용 실행기를 도입할 수 있습니다. 이는 Anthropic이 권하는 “단순한 조합부터 시작하고 필요할 때만 복잡성을 늘린다”는 원칙과도 맞습니다.
1. 상태값 규칙
실행을 중단했다가 다시 시작하려면 무엇이 남아 있어야 할까요?
class RunState(TypedDict):
run_id: str
objective: str
sources: list[str]
artifacts: list[str]
status: str
retry_count: dict[str, int]
approvals: dict[str, bool]
errors: list[dict]대화 전문을 상태값에 모두 넣기보다, 원문은 별도 파일이나 저장소에 보존하고 상태값에는 위치와 해시를 두는 편이 좋습니다.
2. 단계별 규칙
각 단계에는 입력, 출력, 판단 주체, 성공 조건, 시간 제한, 재시도, 비용 한도가 필요합니다.
Node: semantic_review
Decision owner: independent verifier
Input: draft artifact, source references
Output: review artifact, pass/fail
Retry: transient API error만 2회
Success: unsupported claim 0개
Failure route: editorial_agent
Timeout: 10분Agent 단계도 “알아서 잘 해줘”가 아니라 항목과 형식이 정해진 결과를 반환해야 합니다. 메일 발송이나 DB 변경처럼 외부 상태를 바꾸는 일은 agent가 바로 수행하지 않고, 별도 코드 단계가 조건을 확인한 뒤 실행하는 편이 안전합니다.
3. 허용 경로 규칙
다음 경로를 모델이 제안하게 할 수는 있지만 선택지는 제한해야 합니다.
Route = Literal[
"collect_more",
"write_draft",
"human_review",
"blocked",
]무한 수정 loop를 막기 위해 반복 횟수와 비용 상한도 필요합니다. blocked나 failed를 성공처럼 포장하지 않는 것도 중요합니다.
4. 실행과 재개 규칙
실제 서비스에서는 Graph 모양보다 다음 기능이 더 중요합니다.
- 실패한 지점부터 다시 시작하는 중간 저장
- 사람의 응답을 오래 기다린 뒤 이어서 실행하기
- 병렬 실행과 결과 합치기
- 같은 외부 작업이 두 번 실행되지 않게 막기
- 단계별 실행 기록, 비용, 지연 시간
- 프로세스가 재시작돼도 이어지는 상태값
그림을 읽는 법: 대화 기록만 복원한 Loop는 모델이 “다음에 무엇을 해야 했는지” 다시 판단해야 합니다. Graph는 완료한 단계, 결과물 위치, 승인 상태, 시도 횟수를 중간 저장해 정해진 지점에서 재개합니다. LangGraph의 Persistence 문서는 각 실행의 상태를 checkpoint로 저장하고, 장애 이후 같은 상태에서 이어서 실행하는 방식을 설명합니다.
개발할 때 묻기: 프로세스가 이 줄에서 죽으면 어디서 다시 시작할 것인가? 이미 발행·결제·메일 발송이 끝났다면 다시 실행해도 안전한가? 코드나 프레임워크를 고르기 전에 이 두 질문에 답해야 합니다.
LangChain도 LangGraph 실행기 설계 글에서 병렬 실행, 중간 결과 전달, 작업 대기 목록, 중간 저장, 사람의 개입, 실행 기록 같은 운영 문제를 강조합니다.
처음부터 LangGraph를 도입해야 할까
꼭 그렇지는 않습니다.
단계가 몇 개 없고 실행이 짧다면 Python 함수와 명시적인 상태 머신만으로도 충분합니다. 프로그램이 중간에 멈춰도 처음부터 다시 실행하면 되고, 사람의 승인을 오래 기다릴 필요도 없다면 전용 Graph 실행기는 과할 수 있습니다.
반대로 다음 조건이 늘어나면 Graph 실행기가 유리해집니다.
- 조건 분기와 수정 반복이 많다.
- 요청마다 병렬 작업 수가 달라진다.
- 중간 결과부터 부분 재실행해야 한다.
- 사람 응답을 수시간 또는 수일 기다린다.
- 다른 컴퓨터나 프로세스에서 중간 저장을 이어받는다.
- 병렬 단계의 결과를 충돌 없이 합쳐야 한다.
좋은 순서는 다음과 같습니다.
한 agent loop로 baseline 만들기
→ 실패 기록 수집
→ 반복되는 실패 지점에 통과 조건 추가
→ 독립 작업만 병렬화
→ 중간 저장과 재개가 필요해질 때 실행기 도입
→ 충분한 평가 자료가 생긴 뒤 연결 구조 개선코드 관점에서는 다음 차이가 생깁니다.
기존 loop
messages + all_tools + while not done
graph-ready 구조
형식이 정해진 상태값
+ 단계별 입력·출력 규칙
+ 현재 상태에서 허용되는 경로
+ 재시도 상한과 검증 판정
+ 작업 순서를 아는 대기 목록과 결과 합치기
+ 중간 저장, 실행별 graph, 사건 기록Claude Code 같은 Agent Loop는 이 구조에서 사라지지 않습니다. 조사나 코딩처럼 세부 경로를 미리 알 수 없는 단계 안에 그대로 들어갑니다. 대신 그 단계의 바깥에서 입력 범위, 결과 형식, 검증, 비용, 외부 작업을 통제합니다.
처음부터 agent를 다섯 개 만들고 선으로 연결하면 멋있어 보일 수는 있습니다. 하지만 비용과 latency가 커지고, 누가 잘못했는지 추적하기 어려워질 가능성이 큽니다.
내가 쓰던 Harness에도 이미 Graph가 있었다
문서 조사와 발행을 돕는 Harness를 다시 살펴보니, LangGraph를 쓰지 않았을 뿐 이미 Graph에 가까운 구조가 들어 있었습니다.
source catalog
→ 주제 설계 검사
→ URL 검증과 수집
→ 원문 근거와 진행 상태 저장
→ 편집 agent의 결과물
→ 코드로 정한 품질 조건
→ 독립적인 내용 검토
→ Markdown/HTML 만들기
→ 발행 전 검사
→ 사람 승인
→ 초안 저장 또는 발송agent_artifact_required, semantic_review_required, delivery_ready 같은 상태 이름은 사실상 Graph의 경로를 나타냅니다. mail_ready=false이면 발송 단계로 갈 수 없고, 사용자가 명시적으로 승인하기 전에는 메일을 보낼 수 없습니다.
이 시스템은 LangGraph로 작성하지 않았습니다. Python의 조건문과 상태 규칙으로 Graph를 표현합니다. 프레임워크를 바꾸기 전에 현재의 허용 경로부터 분명히 적어야 합니다.
- 허용되는 상태 변화를 하나의 규칙표로 만든다.
- 각 단계의 입력과 출력 결과물을 기록한다.
- 실행 ID, 단계 ID, 시도 횟수, 결과물 해시를 실행 기록에 남긴다.
- 단계를 다시 실행해도 발행·발송이 중복되지 않는지 확인한다.
- Claude Code나 Agent SDK를 호출하는 방식을 한 가지 형태로 맞춘다.
이렇게 했는데도 병렬 경로, 긴 중단, 부분 재실행이 복잡해질 때 LangGraph 같은 실행기를 검토하면 됩니다.
결국 Graph Engineering의 실체는 무엇인가
Graph Engineering은 agent 여러 개를 선으로 연결하는 그림이 아닙니다. 결과를 완전히 예측하기 어렵고 비용도 큰 AI agent를 일반 소프트웨어가 통제할 수 있는 구조 안에 넣는 작업입니다. 그래프를 잘 그리는 것보다 모델의 결정권이 어디서 시작하고 끝나는지 정하는 일이 더 중요합니다.
개발자 입장에서 기억할 것은 세 가지면 충분합니다.
- 탐색과 작성처럼 정답 경로를 미리 알 수 없는 일은 Agent Loop에 맡깁니다.
- 출처 기준, 재시도 상한, 승인, 발행처럼 반드시 지켜야 할 규칙은 코드와 사람이 통제합니다.
- Node를 기능별로만 나누지 말고, 중요한 결정의 주인이 바뀌는 경계를 드러냅니다.
이 기준으로 보면 Graph Engineering은 완전히 새로운 분야라기보다, agent가 실제 일을 하기 시작하면서 다시 중요해진 소프트웨어 설계의 오래된 질문입니다.
“어디까지 자유롭게 맡기고, 어디부터 확실하게 통제할 것인가?”
Graph Engineering은 그 질문에 상태값, 단계, 허용 경로, 실행 기록으로 답하는 방법입니다.
참고 자료
이 글은 세 종류의 근거를 나눠 사용했습니다. LangGraph·Claude Code의 현재 동작은 각 제품의 공식 문서로 확인했습니다. 기술 흐름과 개념 구분은 원 논문과 조사 논문을 따랐습니다. “결정권의 경계로 Node를 본다”는 표현은 이 자료들을 개발 관점에서 종합한 해석이며, 학계가 합의한 공식 정의는 아닙니다. LangChain 자료는 프레임워크 제작사의 관점이라는 점도 함께 고려해야 합니다.
- 3 Years of Graph Engineering with LangGraph, LangChain, 2026-07-22
- Building effective agents, Anthropic, 2024-12-19
- Graph API overview, LangChain Docs
- Workflows and agents, LangChain Docs
- Building LangGraph: Designing an Agent Runtime from first principles, LangChain, 2025-09-04
- How Claude Code works, Anthropic Docs
- How the agent loop works, Anthropic Docs
- Agent SDK overview, Anthropic Docs
- Effective harnesses for long-running agents, Anthropic, 2025-11-26
- From Static Templates to Dynamic Runtime Graphs, arXiv:2603.22386, 2026
- Persistence, LangGraph Docs
- ReAct, Yao 외, ICLR 2023
- Language Agents as Optimizable Graphs, Zhuge 외, ICML 2024
- AFlow, Zhang 외, 2024
'관심있는 주제 > 탐구 노트' 카테고리의 다른 글
| AI 시대의 개발자는 왜 Latency Numbers를 알아야 하는가 (0) | 2026.08.17 |
|---|---|
| pgGraph 완전 가이드: PostgreSQL 데이터를 CSR 그래프로 만들고 검색·탐색하는 법 (0) | 2026.08.06 |
| 일정을 못 잡는 개발자를 위한 WBS 실전 가이드 (1) | 2026.07.25 |
| 지식 자산화와 OKF: 개인 노트에서 기업 AI 지식 인프라까지 (0) | 2026.07.19 |
| Ilya Sutskever가 추천했다고 알려진 30 Papers로 보는 AI의 큰 그림 (0) | 2026.07.12 |