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

아래는 Peter Steinberger가 X에 올린 글의 캡처입니다. “아직 루프를 이야기하나요, 아니면 그래프로 넘어갔나요?”라는 질문이 보입니다. 하네스와 루프에 이어 그래프라는 표현을 접하면 새로운 도구부터 배워야 할 것 같지만, 먼저 작업의 순서를 그린다고 생각하면 됩니다. 캡처의 조회수는 촬영 당시 표시이며 현재 수치가 아닙니다.

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

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

그림을 읽을 때 필요한 표현은 다음과 같습니다.

• 노드(node): 일을 하는 단위입니다. 에이전트일 수도 있고, 도구 호출이나 사람의 확인 단계일 수도 있습니다.
• 엣지(edge): 노드 사이의 연결선입니다. 어떤 작업 뒤에 무엇을 실행할지 나타냅니다. 필요한 결과를 어떻게 전달할지는 사용하는 도구의 데이터 처리 방식도 함께 정해야 합니다.
• 조건부 엣지(conditional edge): 결과에 따라 다음 경로가 나뉘는 연결선입니다. "검토 통과면 발행으로, 실패면 수정으로" 같은 분기를 그래프 안에 넣을 수 있습니다.

실행 중에는 상태(state)도 관리합니다. 완료한 조사, 모은 자료, 수정 횟수처럼 다음 판단에 필요한 현재 정보를 뜻합니다.

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

어떤 작업을 동시에 진행할 수 있을까요?

작업을 차례대로 실행하는 것을 순차 실행, 여러 작업을 동시에 진행하는 것을 병렬 실행이라고 합니다. A → B → C처럼 한 줄로 연결한 파이프라인도 그래프의 한 형태입니다. B가 A의 결과를 필요로 하고 C가 B의 결과를 필요로 한다면 이 순서가 맞습니다. 그래프를 쓴다는 이유로 병렬 실행으로 바꿀 필요는 없습니다.

반면 서로 독립적인 조사 세 건이라면 병렬로 실행하는 구조를 고려할 수 있습니다. 다만 그림을 나란히 그렸다고 자동으로 동시에 실행되지는 않습니다. 실행 도구의 병렬 처리 설정, 사용 가능한 자원, API 호출 제한이 실제 속도를 좌우합니다. API 호출은 프로그램이 외부 서비스에 요청을 보내는 일입니다.

실패 복구도 별도로 설계합니다. 체크포인트는 중간 상태를 저장해 다시 이어 갈 수 있도록 하는 지점입니다. 저장 설정이 없다면 프로그램이 종료될 때 결과가 사라질 수 있습니다. 실패한 작업만 재시도하도록 만들 수도 있지만, 재시도로 메시지 발송 같은 동작이 두 번 일어나지 않게 해야 합니다. 직렬 파이프라인에도 저장과 복구를 넣을 수 있습니다. Microsoft의 실행 및 저장 설명

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

작업 흐름을 설명할 때 자주 쓰는 모양은 다음과 같습니다.

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

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

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

위 다이어그램처럼 승인 노드에서 흐름이 일시정지되고, 사람이 결정을 입력하면 다음 노드로 진행됩니다. 자동화 흐름 안에 사람의 판단 지점을 필요한 위치에 둘 수 있습니다. 승인 결과를 기다리도록 실제 실행도 설정해야 합니다.

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

프레임워크는 이런 기능을 구현할 때 사용하는 개발용 도구 모음입니다. 아래 도구를 지금 설치할 필요는 없습니다.

개념이 비슷해도 문법과 저장 방식, 오류 처리 방식은 다릅니다. 도구를 바꿀 때는 이 설정을 다시 확인해야 합니다.

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

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

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

예를 들어 이미지 후보를 찾으려면 먼저 사례 조사가 끝나야 하는 작업이라면, 두 일을 순서대로 연결해야 합니다. 겉으로 다른 작업처럼 보여도 입력이 무엇인지 살펴봐야 독립적인지 판단할 수 있습니다.

종이에 다섯 작업을 놓아 봅니다

메모 앱이나 종이에 가상의 주말 나들이 준비를 적어 봅니다. 도구 설치나 AI 호출은 필요하지 않습니다.

• A: 방문할 도서관과 날짜 정하기
• B: 그 도서관의 해당 날짜 운영 시간 확인
• C: 집에서 그 도서관까지 걸리는 예상 도보 시간 확인
• D: 운영 시간과 이동 시간을 합쳐 출발 시각 정하기
• E: 일정표 확인 후 가족에게 보내기

A부터 E까지 상자로 그리고, 앞 작업의 결과가 필요한 곳에 화살표를 그립니다. 기준이 되는 연결은 A → B, A → C, B → D, C → D, D → E입니다. B와 C는 장소와 날짜를 받은 뒤 각자 확인할 수 있습니다. 이 예시의 C는 개관 시간과 관계없이 같은 출발지에서 걸어가는 시간을 확인합니다. D는 두 결과가 모두 있어야 합니다.

이제 B의 결과에 ‘운영 시간 확인 실패’라고 적습니다. C가 끝났더라도 D에서 출발 시각을 확정하면 안 됩니다. 이 연습에서는 B를 한 번 더 확인하고 그래도 실패하면 사람에게 확인을 요청하도록 정합니다. E에서 실제 메시지를 보내지는 않습니다.

혼자 반복할 때는 C의 조건을 ‘도서관 개관 시간에 맞는 버스편 찾기’로 바꿉니다. 이제 C가 B의 결과를 필요로 하므로 A → B → C → D → E 순서가 됩니다. 바뀐 입력 조건 때문에 병렬 작업이 순차 작업으로 달라진 것입니다.

작업이 이미 단순하게 잘 돌아간다면 새 도구를 도입할 필요는 없습니다. 순서, 필요한 입력, 실패했을 때 멈출 위치를 설명할 수 있는 것부터가 시작입니다.

Sources

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