AI 에이전트 그래프 오케스트레이션, 노드와 엣지로 흐름 제어하기

게시 2026.07.20 · 약 6분 분량

AI 에이전트 그래프 오케스트레이션은 여러 단계로 이뤄진 에이전트 작업을 노드(작업 단위)와 엣지(단계 사이의 연결)로 그린 그래프로 표현해, 분기와 반복, 재시도, 사람 승인 같은 흐름을 코드로 제어하는 방식이다. 한 줄로 쭉 이어지는 체인과 달리 조건에 따라 갈라지고 이전 단계로 되돌아갈 수 있다는 점이 핵심이다. LangChain의 LangGraph 공식 문서는 이 방식을 '애플리케이션을 그래프로 표현하는 저수준 오케스트레이션 계층'으로 설명한다. 이 글은 2026년 7월 기준으로 LangGraph의 개념과 용어를 중심에 두되, 특정 서비스의 요금이나 배포 인프라 세부까지는 다루지 않는다. 파이썬으로 에이전트 흐름을 짜 본 개발자를 독자로 상정한다.

선형 체인은 왜 한계에 부딪히나

선형 체인은 A→B→C처럼 단계를 한 방향으로만 잇는 구조다. 요약이나 단순 질의응답에는 이걸로 충분하다. 문제는 흐름이 복잡해질 때 생긴다. B 단계가 잘못된 값을 내놓으면 C가 그대로 받아 오류가 번지고, 중간에서 조건에 따라 경로를 바꾸거나 결과가 기준에 못 미칠 때 앞 단계로 돌아가 다시 시도하는 일을 담기 어렵다.

그래프는 이 지점에서 갈라진다. 단계를 노드로, 단계 사이의 이동을 엣지로 분리하면 흐름을 자유롭게 그릴 수 있다. 조건에 따라 다른 노드로 분기하고, 서로 독립적인 작업을 나란히 돌리고, 필요하면 이전 노드로 되돌아간다. 한 방향으로만 흐르던 파이프가 갈림길과 되돌아오는 길을 갖게 되는 셈이다.

루프 엔지니어링에서 그래프 엔지니어링으로

선형 체인의 한계를 처음 메운 것은 루프였다. 에이전트가 한 번 답하고 끝나는 대신 관찰하고, 행동하고, 결과를 검증하고, 실패하면 복구하는 과정을 목표에 닿을 때까지 반복하게 만드는 것 — 이 반복 회로를 설계하는 일을 두고 루프 엔지니어링(loop engineering)이라 부른다. 프롬프트 한 줄을 다듬는 프롬프트 엔지니어링을 넘어, 에이전트가 스스로 도는 루프 자체를 설계 대상으로 삼는 관점이다.

문제는 매니저 에이전트가 자유형 대화로 다음 행동을 매번 정하는 열린 루프가 커질수록 디버깅도, 재현도, 조직의 제약을 지키기도 어렵다는 데 있다. 그래서 최근 프로덕션 시스템은 이 흐름을 명시적인 그래프로 고정하는 쪽으로 옮겨간다. 노드는 툴 호출이나 LLM 호출을, 엣지는 허용된 전이만 담는 상태 기계로 워크플로를 못 박는 것이다. 2026년 공개된 논문 「From Agent Loops to Deterministic Graphs」도 자유형 에이전트 루프를 결정적 그래프로 옮겨 실행 계보(lineage)를 남기면 재현 가능한 작업이 된다고 정리한다. 루프를 어떻게 도느냐에서 그래프를 어떻게 그리느냐로 무게중심이 옮겨간 셈이다. 아래 세 요소가 그 그래프를 이룬다.

노드·엣지·상태, 그래프를 이루는 세 요소

그래프 오케스트레이션은 세 조각으로 이뤄진다. 노드(node)는 실제 일을 하는 단위다. LLM 호출, 도구 실행, 값 검사 같은 함수 하나가 노드가 된다. 엣지(edge)는 한 노드에서 다음 노드로 넘어가는 연결이다. 상태(state)는 그래프 전체를 흐르며 각 노드가 읽고 갱신하는 공용 데이터다. 노드는 이 상태를 입력으로 받아 일부를 바꿔 돌려주고, 그 값이 다음 노드로 이어진다.

LangGraph를 예로 들면 StateGraph 객체에 add_node로 노드를, add_edge로 연결을 등록하고 compile()로 실행 가능한 그래프를 만든다. START와 END는 흐름의 시작과 끝을 가리키는 특수 지점이다.

from langgraph.graph import StateGraph, START, END, MessagesState

builder = StateGraph(MessagesState)
builder.add_node("plan", plan_step)  # 계획 노드
builder.add_node("act", act_step)  # 실행 노드
builder.add_edge(START, "plan")
builder.add_conditional_edges("plan", route) # 상태 보고 분기
builder.add_edge("act", "plan")   # 다시 계획으로: 순환
graph = builder.compile()

여기서 각 노드(plan_step, act_step)와 분기 함수 route는 직접 짜는 코드다. 프레임워크는 흐름을 엮어 줄 뿐, 노드 안에서 무엇을 하는지는 개발자 몫이다. 에이전트 자체를 어떤 종류로 나눌지는 LLM 에이전트를 세 축으로 구분한 글에서 다뤘고, 여기서는 그 에이전트들을 하나의 흐름으로 엮는 쪽에 집중한다.

조건부 엣지와 순환은 무엇을 가능하게 하나

조건부 엣지는 현재 상태를 보고 다음 노드를 골라 준다. 위 코드의 add_conditional_edges가 그 역할이다. route 함수가 상태를 검사해 '도구를 더 써야 한다'면 act 노드로, '답이 완성됐다'면 END로 보내는 식이다. if 문을 그래프 구조 안으로 끌어들인 셈이다.

순환(cycle)은 엣지가 이전 노드로 되돌아가는 구조다. 위 예시에서 act가 다시 plan으로 향하는 엣지가 순환을 만든다. 검증 노드가 결과를 퇴짜 놓으면 생성 노드로 다시 보내 다듬게 하는 재시도·자기수정 루프가 대표적이다. 이 재시도 구조는 검증기가 결과를 걸러내고 다시 시키는 자기개선 흐름과 맞닿아 있다. LangGraph 공식 문서는 이런 순환 그래프를 정식으로 지원한다고 설명한다. 방향은 있지만 되돌아오는 길이 없는 DAG(순환 없는 방향 그래프)와 갈리는 지점이다.

체크포인트와 사람 개입(HITL)

오래 도는 에이전트는 중간에 프로세스가 죽거나 사람 확인을 기다려야 하는 순간을 만난다. LangGraph 공식 문서는 체크포인트로 상태를 저장해 두면 실패한 지점부터 이어서 다시 실행할 수 있다고 설명한다. 처음부터 전 과정을 되돌릴 필요가 없다는 뜻이다.

사람 개입(human-in-the-loop, HITL)은 실행을 잠시 멈추고 사람이 에이전트 상태를 들여다보거나 고친 뒤 이어 가는 장치다. 결제나 외부 발송처럼 되돌리기 어려운 작업 앞에 승인 노드를 두고, 사람이 확인해야 다음 노드로 넘어가게 짤 수 있다. 그래프에서는 이런 승인 지점도 노드 하나로 표현된다.

어떤 프레임워크를 고를까

그래프 방식만 있는 건 아니다. 실무에서 자주 갈리는 세 갈래를 정리하면 이렇다.

LangChain은 LangGraph를 명시적 상태 그래프와 체크포인트·스트리밍·사람 개입을 갖춘 오케스트레이션 런타임으로 소개한다. CrewAI 공식 사이트는 에이전트에 역할을 부여해 협업 크루를 꾸리고 적은 코드로 구성한다는 점을 내세운다. 흐름에 순환과 조건 분기가 많고 감사 추적이나 되돌리기 지점이 필요하면 그래프 구조가 잘 맞고, 작업이 역할별로 깔끔하게 쪼개지면 역할 기반 크루가 코드를 줄여 준다. 두 도구의 원본은 LangGraph GitHub 저장소와 LangChain 공식 문서에서 확인할 수 있다.

결국 그래프 오케스트레이션의 가치는 흐름을 그림으로 드러낸다는 데 있다. 어느 노드에서 갈라지고 어디로 되돌아오는지가 코드에 명시되면, 에이전트가 왜 그 경로를 탔는지 추적하고 실패 지점을 좁히기 쉬워진다.