쉽게 이해하는 AI 그래프 엔지니어링

2026년 7월 18일, OpenClaw를 만든 Peter Steinberger가 짧은 질문 하나를 올렸습니다. "우리 아직 루프 얘기 중인가요, 아니면 벌써 그래프로 넘어갔나요?" 이 글은 170만 회가량 조회되며 다음 화두를 예고했습니다. 프롬프트, 컨텍스트, 하네스, 루프로 이어져 온 AI 업계의 용어 흐름에서 다음 차례로 언급되기 시작한 것이 그래프입니다. 이 글은 트렌드 계보는 여기까지만 짚고, 그래프 엔지니어링 자체를 기초부터 정리합니다.

그래프 엔지니어링은 무엇을 말하는 걸까요?

그래프 엔지니어링이라는 표현이 앞선 용어들보다 상대적으로 낯설 수 있습니다. 쉽게 말하면 여러 에이전트가 하는 일들을 노드(작업 단위)와 엣지(연결선)로 그려서, 무엇이 무엇 뒤에 와야 하고 무엇은 동시에 해도 되는지를 설계하는 일입니다. 요리 워크플로우 순서를 정리한 표와 비슷합니다. 재료 손질 세 가지는 동시에 진행해도 되지만, 조리는 손질이 끝나야 시작할 수 있고, 플레이팅은 조리가 끝나야 가능합니다. 이 순서와 의존 관계를 그림으로 정리한 것이 그래프입니다.

구성 요소는 세 가지로 정리됩니다.

• 노드(node): 일을 하는 단위입니다. 에이전트일 수도 있고, 도구 호출이나 사람의 확인 단계일 수도 있습니다.
• 엣지(edge): 노드 사이의 연결선입니다. 앞 노드의 결과물이 뒷 노드의 입력으로 전달됩니다.
• 조건부 엣지(conditional edge): 결과에 따라 다음 경로가 갈리는 연결선입니다. "검토 통과면 발행으로, 실패면 수정으로" 같은 분기를 그래프 안에 넣을 수 있습니다.

위 이미지는 Microsoft Agent Framework 공식 문서에 실린 워크플로 개요 그림입니다. 갈라졌다가 다시 모이고, 일부 구간은 되돌아가기도 하는 이런 모양이 그래프 엔지니어링이 다루는 설계 대상입니다.

왜 한 줄로 잇지 않고 그래프로 설계할까요?

에이전트 작업을 A 다음 B, B 다음 C처럼 한 줄로 이어도 동작은 합니다. 문제는 규모가 커질 때 생길 수 있습니다. 직렬 연결의 약점으로 지적되는 것은 세 가지입니다.

• 불필요한 줄서기: 서로 관계없는 작업까지 차례를 기다립니다. 동시에 해도 되는 조사 세 건을 한 줄로 세우면 시간이 그만큼 늘어납니다.
• 하나가 멈추면 전부 멈춤: 중간 단계가 실패하면 뒤 단계 전체가 막히고, 이미 끝난 작업의 결과도 버려지기 쉽습니다.
• 분기를 넣기 어려움: "결과가 나쁘면 다시 시도" 같은 갈림길을 표현하려면 흐름 바깥에 별도 코드를 덧대야 합니다.

그래프로 바꾸면 이 세 가지가 구조적으로 풀립니다. 의존 관계가 없는 노드는 기본적으로 동시에 실행되고, 조건부 엣지가 갈림길을 그래프 안에 담고, 실패해도 영향을 받는 가지만 다시 실행하면 됩니다. 중간 저장(체크포인트)을 두면 마지막 성공 지점부터 이어서 재개할 수도 있습니다. 병렬 비중이 큰 작업에서는 전체 시간이 3분의 1 이상 줄었다는 사례들이 보고되고 있습니다. 반대로 원래 순서대로만 해야 하는 일이라면 그래프로 바꿔도 얻는 것이 거의 없다는 점도 같이 언급됩니다.

실제 그래프에는 어떤 모양이 있을까요?

현업에서 반복적으로 쓰이는 모양은 몇 가지로 수렴합니다.

• 파이프라인: 조사 → 초안 → 검토 → 발행처럼 순서가 필요한 일을 한 줄로 잇는 기본형
• 팬아웃/팬인(fan-out/fan-in): 독립적인 작업을 여러 노드에 동시에 맡겼다가, 전부 끝나면 종합 노드가 결과를 모으는 형태
• 조건 분기: 결과 평가에 따라 통과, 재시도, 사람 호출로 경로가 갈리는 형태
• 피드백 순환: 작성 노드와 비평 노드가 결과를 주고받는 형태. 무한 반복을 막는 횟수 제한과 함께 씁니다

위 다이어그램은 Microsoft 공식 블로그에 실린 팬아웃/팬인의 예시입니다. 질문을 물리학자 에이전트와 화학자 에이전트에게 동시에 보내고, 종합 노드가 두 답을 모읍니다. 주의할 점은 하나입니다. 병렬로 묶은 가지들은 서로의 결과가 필요 없어야 합니다. B가 A의 결과를 쓴다면 그 둘은 병렬이 아니라 파이프라인으로 이어야 합니다.

사람의 승인이 필요한 일도 그래프의 노드로 들어갑니다.

위 다이어그램처럼 승인 노드에서 흐름이 일시정지되고, 사람이 결정을 입력하면 다음 노드로 진행됩니다. 자동화 흐름 안에 사람의 판단 지점을 정확한 위치에 박아 넣을 수 있다는 점이 그래프 설계의 장점으로 꼽힙니다.

어떤 도구로 만들 수 있을까요?

2026년 7월 기준으로 그래프 방식을 지원하는 대표 도구를 정리하면 다음과 같습니다.

도구마다 문법은 다르지만 노드를 정의하고, 엣지로 잇고, 조건을 달고, 실행 상태를 저장한다는 뼈대는 같습니다. 하나로 개념을 익히면 다른 도구로 옮기는 부담은 크지 않은 편입니다.

우리는 무엇부터 해 보면 될까요?

실무 흐름 하나로 예를 들어 설명하겠습니다. 블로그 글 하나를 만드는 과정을 그래프로 옮기면 이렇게 됩니다.

1. 노드 나누기: 통계 조사, 사례 조사, 이미지 후보 수집을 각각의 노드로 정의합니다. 셋은 서로의 결과가 필요 없으므로 병렬 가지입니다.
2. 팬인 지점 만들기: 세 조사가 끝나면 초안 작성 노드가 결과를 모아 글을 씁니다.
3. 조건 분기 달기: 검토 노드가 기준 미달로 판정하면 초안 노드로 되돌리고, 재시도 2회를 넘으면 사람에게 넘깁니다.
4. 사람 승인 노드 두기: 발행 직전에 흐름이 멈추고, 사람이 확인한 뒤에만 발행 노드가 실행됩니다.

한 줄 파이프라인이었다면 조사 세 건이 차례를 기다렸을 텐데, 그래프에서는 동시에 진행되고 실패한 가지만 다시 돌리면 됩니다.

마지막으로 균형을 잡자면, 용어가 루프에서 그래프로 옮겨 가는 분위기라고 해서 지금 방식을 바꿔야 하는 것은 아닙니다. 에이전트 하나와 대화하며 일하는 방식은 여전히 유효하고, 그래프 설계는 병렬로 처리할 작업이 실제로 쌓였을 때 의미가 생깁니다. 시작한다면 팬아웃/팬인 하나를 작게 만들어 보는 것으로 충분합니다.

3줄 요약:

• 그래프 엔지니어링은 여러 에이전트의 작업을 노드와 엣지로 그려 순서, 병렬, 분기, 사람 승인 지점을 설계하는 방식으로, 2026년 중반부터 루프에 이어 다음 화두로 언급되고 있습니다.
• 직렬 연결과 달리 독립 작업은 동시에 실행되고, 조건부 엣지로 갈림길을 담고, 실패한 가지만 다시 실행할 수 있다는 것이 그래프 구조의 장점입니다.
• LangGraph, Microsoft Agent Framework 등 도구는 달라도 노드, 엣지, 조건, 상태 저장이라는 뼈대는 같으며, 시작은 팬아웃/팬인 패턴 하나면 충분합니다.

Sources

• Microsoft Agent Framework Workflows 공식 문서
• Durable Workflows in the Microsoft Agent Framework (.NET 공식 블로그)
• LangGraph Graph API 공식 문서
• Strands Agents Graph 패턴 공식 문서