2026년 7월 28일

Graph Engineering 이란

하나의 AI 에이전트를 반복시키는 루프를 넘어, 여러 작업과 에이전트가 협력하는 구조를 어떻게 설계해야 하는지 쉽게 설명합니다.

AI에게 일을 맡기는 방식은 빠르게 바뀌고 있습니다. 처음에는 좋은 답을 얻기 위해 프롬프트를 다듬었습니다. 이후에는 어떤 문서와 기억을 보여줄지, 어떤 도구를 쓸 수 있게 할지, 결과가 틀렸을 때 어떻게 다시 시도하게 할지를 설계하기 시작했습니다.

최근 등장한 Graph Engineering이라는 표현은 이 변화의 다음 단계를 가리킵니다. 하나의 AI가 혼자 잘 일하도록 만드는 데서 더 나아가, 여러 작업과 에이전트가 어떤 순서로 연결되고, 무엇을 공유하며, 누가 누구를 검증할지 설계하는 것입니다.

먼저 주의할 점이 있습니다. Graph Engineering은 아직 정의가 완전히 합의된 학문명이나 표준 직무는 아닙니다. 이 글에서는 이 용어를 AI 에이전트의 실행 구조를 명시적인 그래프로 설계하는 실천이라는 뜻으로 사용합니다. 이름은 새롭지만, 그 안에는 워크플로, 상태 머신, 분산 시스템, 조직 설계에서 오랫동안 다뤄 온 문제가 들어 있습니다.

이름이 퍼진 시점과 기술이 탄생한 시점도 구분해야 합니다. Graph Engineering이라는 표현은 2026년 7월 중순 Hamel Husain의 글을 계기로 빠르게 확산됐고, LangChain은 같은 달 22일 이를 “새로운 이름이 붙은 오래된 접근”에 가깝게 설명했습니다. 에이전트를 순환 그래프와 상태 머신으로 구성하는 방식은 이미 사용되고 있었기 때문입니다.

다만 최근 달라진 점은 있습니다. 과거의 노드가 주로 일반 코드나 한 번의 LLM 호출이었다면, 이제는 도구를 사용하고 스스로 반복하는 완전한 에이전트 하나를 노드로 넣는 방식이 실용적인 선택지가 됐습니다. Graph Engineering은 바로 그 강력한 노드들을 예측 가능한 구조 안에 배치하려는 시도입니다.

한 명의 유능한 사람에서 잘 움직이는 팀으로

한 명의 유능한 직원에게 시장 조사 보고서를 맡긴다고 생각해 보겠습니다. 그 직원은 자료를 검색하고, 초안을 쓰고, 스스로 검토한 뒤 결과를 제출합니다. 이것이 잘 설계된 단일 에이전트의 모습과 비슷합니다.

하지만 조사 범위가 커지면 상황이 달라집니다. 한 사람이 경쟁사, 기술, 고객, 법률 자료를 모두 깊게 조사하기는 어렵습니다. 그래서 실제 조직에서는 일을 나눕니다.

조사 책임자가 질문을 작은 단위로 나눕니다.
여러 조사자가 서로 다른 영역을 동시에 살펴봅니다.
편집자가 결과를 하나의 문서로 합칩니다.
검토자가 근거와 빠진 내용을 확인합니다.
중요한 판단은 사람이 승인합니다.

사람 수만 늘린다고 좋은 팀이 되지는 않습니다. 역할이 겹치거나 전달 방식이 불분명하면 회의만 늘고 책임은 사라집니다. AI 에이전트도 같습니다. Graph Engineering의 핵심은 에이전트를 많이 사용하는 것이 아니라 협업의 구조를 설계하는 것입니다.

먼저 Loop Engineering을 이해해야 한다

AI 에이전트의 가장 기본적인 구조는 루프입니다.

목표 확인 → 다음 행동 선택 → 도구 실행 → 결과 관찰 → 목표 달성 여부 판단
    ↑                                                   │
    └──────────────── 미완료라면 다시 시도 ─────────────┘

예를 들어 코딩 에이전트는 파일을 읽고, 코드를 수정하고, 테스트를 실행합니다. 테스트가 실패하면 오류 메시지를 보고 다시 수정합니다. 성공하거나 정해진 횟수를 모두 사용하면 멈춥니다.

여기서 중요한 것은 단순한 반복이 아닙니다. 안정적인 루프에는 최소한 다음 요소가 필요합니다.

목표: 무엇을 완료로 볼 것인가
상태: 지금까지 무엇을 했고 무엇이 남았는가
도구: 검색, 코드 실행, 파일 수정처럼 환경에 영향을 주는 수단
검증기: 테스트, 규칙, 점수, 사람의 판단처럼 결과를 확인하는 기준
종료 조건: 성공, 실패, 시간 초과, 비용 한도 중 언제 멈출 것인가

Anthropic은 에이전트를 환경의 피드백을 받으며 도구를 사용하는 반복 구조로 설명합니다. OpenAI의 에이전트 가이드도 while 루프가 에이전트 작동의 중심이라고 설명합니다. 즉, Loop Engineering은 “같은 프롬프트를 여러 번 보내는 기술”보다 AI가 관찰하고 행동하고 수정하는 사이클을 통제하는 기술에 가깝습니다.

하나의 루프가 복잡해질 때 생기는 문제

단일 루프는 단순하고 관찰하기 쉽습니다. 웬만한 작업은 좋은 모델, 명확한 도구, 충분한 컨텍스트를 가진 단일 에이전트로 먼저 해결하는 편이 낫습니다.

문제는 하나의 루프가 너무 많은 책임을 맡을 때 시작됩니다.

컨텍스트가 뒤섞인다

조사 메모, 사용자 요구, 코드, 검토 의견, 도구 결과가 한 대화에 계속 쌓이면 무엇이 중요한지 구분하기 어려워집니다. 오래된 가정이 새로운 사실보다 더 강하게 남거나, 한 영역의 지시가 다른 영역에 잘못 적용될 수 있습니다.

생성자와 검증자가 같은 관점에 갇힌다

초안을 만든 에이전트가 같은 컨텍스트 안에서 자기 결과를 검토하면 처음의 가정을 그대로 반복할 가능성이 큽니다. “작성”과 “검증”이라는 이름만 나누고 실제 정보와 기준을 분리하지 않으면 독립적인 검증이 되지 않습니다.

병렬화할 수 있는 일을 순서대로 처리한다

서로 의존하지 않는 조사 다섯 개를 하나의 에이전트가 차례로 처리하면 시간이 오래 걸립니다. 각 조사 결과가 긴 경우에는 뒤쪽 작업을 시작하기 전에 컨텍스트가 이미 가득 찰 수도 있습니다.

권한이 지나치게 넓어진다

검색만 하면 되는 작업에도 데이터 수정 권한이 있고, 초안만 만드는 에이전트에도 배포 권한이 있다면 실수의 영향 범위가 커집니다. 복잡한 단일 에이전트는 편리하지만 최소 권한 원칙을 적용하기 어렵습니다.

이때 필요한 질문은 “더 좋은 프롬프트를 쓸까?”가 아니라 “이 책임들을 계속 한 루프에 두는 것이 맞을까?”입니다.

Graph Engineering은 무엇을 설계하는가

그래프는 점과 선으로 관계를 표현하는 구조입니다. AI 시스템에서는 보통 다음 세 가지가 핵심입니다.

노드: 일을 수행하는 단위

노드는 반드시 AI 에이전트일 필요가 없습니다.

문서를 조사하는 에이전트
데이터를 정규화하는 일반 함수
요청 종류를 판별하는 라우터
여러 결과를 합치는 편집기
규칙에 따라 결과를 검사하는 검증기
사람의 승인을 기다리는 체크포인트

LLM이 잘하는 모호한 판단에는 에이전트를 쓰고, 계산·형식 검사·권한 확인처럼 답이 정해진 일에는 일반 코드를 쓰는 편이 더 안정적입니다. 모든 노드를 AI로 만들 이유는 없습니다.

엣지: 다음에 어디로 갈지 정하는 규칙

엣지는 노드 사이의 이동 경로입니다. 단순히 A 다음에 B를 실행할 수도 있고, 결과에 따라 다른 곳으로 보낼 수도 있습니다.

검증 통과 → 게시
검증 실패 → 수정
근거 부족 → 추가 조사
위험 작업 → 사람 승인
예산 초과 → 중단

좋은 그래프에서는 “다음 에이전트가 알아서 하겠지”가 아니라 어떤 조건에서 어느 경로를 선택하는지 확인할 수 있습니다.

여기에 한 가지가 더 필요합니다. 엣지는 이동 경로인 동시에 인수인계 규칙입니다. 다음 노드에 전체 대화를 넘길지, 핵심 주장과 출처만 넘길지, 다음 노드가 어떤 상태를 수정할 수 있는지까지 정해야 합니다.

목표: 경쟁사 가격 정책 검증
완료된 작업: 공식 가격 페이지 4개 확인
전달할 정보: 핵심 주장, 출처, 불확실한 부분
남은 질문: 지역별 가격 차이가 있는가
다음 노드의 권한: 추가 조사 가능, 원문 수정 불가
종료 조건: 1차 출처 3개 이상 또는 조사 예산 소진

이처럼 구조화된 인수인계가 없으면 에이전트 수가 늘어날수록 정보 누락과 책임 혼선도 커집니다. 좋은 엣지는 단순히 “누구에게 보낼지”뿐 아니라 무엇을 얼마나 압축해, 어떤 근거와 권한을 함께 넘길지 결정합니다.

상태: 노드 사이에 전달되는 작업 기록

상태는 그래프가 현재 어디에 있는지 보여주는 데이터입니다. 흔히 모든 대화 내용을 그대로 공유 상태로 사용하지만, 규모가 커질수록 문제가 생깁니다.

더 나은 방법은 필요한 항목을 구조화하는 것입니다.

작업 ID
사용자 요청
확정된 계획
조사 결과와 출처
현재 초안
검증 결과
남은 재시도 횟수
사용한 비용
승인 상태

각 노드는 필요한 정보만 읽고, 자신이 책임지는 항목만 수정해야 합니다. 공유 상태는 거대한 단체 채팅방보다 정해진 칸이 있는 업무 보드에 가까워야 합니다.

Join: 여러 결과를 합치는 것도 하나의 작업이다

병렬로 일한 결과는 단순히 이어 붙인다고 하나의 답이 되지 않습니다. 세 조사 노드가 같은 기업의 매출을 서로 다르게 보고했다면 다수결로 숫자를 선택할 수도 없습니다. 기준 기간, 통화, 단위, 정정 공시 여부가 다른지 먼저 확인해야 합니다.

그래서 병렬 작업이 다시 만나는 지점에는 별도의 Join 노드가 필요합니다. 이 노드는 누락된 작업을 찾고, 중복을 제거하고, 서로 충돌하는 결과를 표시하고, 어떤 출처를 우선할지 결정합니다. 해결되지 않은 충돌은 억지로 합의시키지 않고 추가 조사나 사람 검토로 보내야 합니다.

그래프는 지식 그래프와 다르다

이름 때문에 지식 그래프와 혼동하기 쉽습니다.

지식 그래프는 사람, 회사, 제품, 사건 같은 정보와 그 관계를 표현합니다. “무엇을 알고 있는가”에 가깝습니다.
에이전트 실행 그래프는 조사, 작성, 검증, 승인 같은 작업과 실행 순서를 표현합니다. “어떻게 일하는가”에 가깝습니다.

두 그래프는 함께 사용할 수 있습니다. 조사 에이전트가 지식 그래프에서 정보를 찾고, 실행 그래프가 그 조사 결과를 검토 노드로 보내는 식입니다. 하지만 해결하는 문제는 다릅니다.

자주 쓰이는 여섯 가지 그래프 패턴

Graph Engineering을 이해하는 가장 쉬운 방법은 실제 연결 형태를 보는 것입니다.

좌우로 밀어 표 전체 보기

패턴	구조	적합한 상황	주의할 점
순차 파이프라인	A → B → C	단계와 순서가 고정된 작업	앞 단계의 오류가 뒤로 전파됨
라우터	분류 → A 또는 B	요청 종류마다 도구와 규칙이 다를 때	잘못된 분류의 복구 경로가 필요함
병렬 분산·수집	A → B·C·D → E	독립적인 조사나 비교를 동시에 할 때	중복 조사와 비용 증가
오케스트레이터·워커	관리자가 작업을 나누고 워커를 생성	하위 작업을 미리 정확히 알 수 없을 때	관리자의 분해 능력에 크게 의존
생성자·검증자	생성 → 평가 → 수정	품질 기준을 비교적 명확히 정의할 수 있을 때	종료 조건이 없으면 무한 수정
인간 승인	작업 → 승인 대기 → 실행	결제, 배포, 삭제처럼 되돌리기 어려운 행동	승인에 필요한 근거를 함께 보여줘야 함

실제 시스템은 이 패턴들을 조합합니다. 예를 들어 리서치 시스템은 먼저 라우터가 질문을 분류하고, 오케스트레이터가 조사 영역을 나눈 뒤, 여러 워커가 병렬로 검색합니다. 편집 노드가 결과를 합치고, 검증 노드가 출처를 검사합니다. 근거가 부족하면 조사 단계로 돌아가고, 충분하면 최종 결과를 만듭니다.

사용자 질문
    │
    ▼
계획·분해 노드
    │
    ├──── 기술 조사 ────┐
    ├──── 사례 조사 ────┼── 편집 ── 근거 검증 ── 결과
    └──── 반론 조사 ────┘                │
                                        └── 부족하면 추가 조사

LangGraph는 이런 구조를 State, Node, Edge로 표현합니다. OpenAI Agents SDK는 중앙 관리자가 전문 에이전트를 도구처럼 호출하는 방식과, 전문 에이전트에게 대화를 넘기는 핸드오프 방식을 구분합니다. 구현 도구는 달라도 핵심 질문은 같습니다. 누가 일을 하고, 어떤 상태를 받아, 어떤 조건으로 다음 단계에 넘기는가입니다.

Graph Engineering이 실제로 유리한 경우

여러 에이전트를 사용한다고 항상 결과가 좋아지는 것은 아닙니다. 다음 조건이 분명할 때 그래프의 가치가 커집니다.

독립적인 하위 작업이 많다

시장·기술·법률·사용자 반응처럼 서로 다른 영역을 동시에 조사할 수 있다면 병렬화의 이점이 큽니다. 각 워커가 별도의 컨텍스트를 사용하므로 하나의 창에 모든 자료를 넣지 않아도 됩니다.

전문 도구나 권한을 분리해야 한다

재무 데이터는 읽을 수 있지만 수정은 못 하는 노드, 코드는 작성하지만 배포는 못 하는 노드처럼 역할마다 권한을 좁힐 수 있습니다. 이는 실수를 완전히 막지는 못하지만 피해 범위를 줄입니다.

생성과 검증을 독립시켜야 한다

보고서를 작성하는 노드와 출처를 확인하는 노드를 나누고, 서로 다른 지시와 입력을 제공하면 같은 오류를 반복할 가능성을 낮출 수 있습니다. 검증 노드는 “더 자연스럽게 써라”가 아니라 “모든 수치에 출처가 있는가”처럼 판정 가능한 기준을 가져야 합니다.

실행 과정을 감사해야 한다

어떤 노드가 어떤 자료를 읽었고, 어느 경로를 선택했으며, 비용을 얼마나 사용했는지 남겨야 하는 업무라면 명시적인 그래프가 유리합니다. 오류가 생겼을 때 전체 대화를 읽는 대신 실패한 노드와 입력 상태를 찾을 수 있습니다.

Anthropic의 멀티 에이전트 리서치 시스템은 이런 장점이 잘 맞는 사례입니다. 리드 에이전트가 질문을 나누고 여러 서브에이전트가 서로 다른 방향을 병렬 조사합니다. Anthropic의 내부 리서치 평가에서는 이 구성이 단일 에이전트보다 90.2% 높은 성능을 보였습니다.

그러나 이 숫자를 모든 업무에 일반화해서는 안 됩니다. 같은 글에서 Anthropic은 멀티 에이전트 시스템이 일반 채팅보다 약 15배 많은 토큰을 사용했고, 많은 정보를 병렬로 탐색하는 고가치 작업에 특히 적합했다고 설명합니다. 서로 강하게 의존하는 작업이나 대부분의 코딩 작업에는 병렬화 이점이 작을 수 있다고도 밝혔습니다.

여러 에이전트는 왜 함께 실패하는가

에이전트가 여러 개라고 해서 서로의 오류를 자동으로 고쳐주는 것은 아닙니다. 잘못된 가정을 공유하거나, 중요한 정보를 다음 에이전트에게 전달하지 않거나, 검증 노드가 형식만 확인한 채 너무 일찍 종료할 수 있습니다.

멀티 에이전트 실패를 분석한 MAST 연구는 7개 시스템의 1,642개 실행 기록에서 14개의 세부 실패 유형을 찾고, 이를 크게 세 범주로 정리했습니다.

요구사항과 역할, 작업 단계가 불명확한 시스템 설계 실패
잘못된 가정과 정보 누락이 이어지는 에이전트 간 정렬 실패
조기 종료나 불완전한 확인이 발생하는 검증·종료 실패

이 결과가 보여주는 것은 단순합니다. 멀티 에이전트의 실패는 모델이 충분히 똑똑하지 않아서만 생기지 않습니다. 역할, 상태, 인수인계, 검증 구조가 나쁘면 강한 모델을 여러 개 사용해도 같은 방향으로 함께 실패할 수 있습니다.

그래프로 만들지 않는 편이 나은 경우

다음 상황에서는 단일 에이전트나 일반 코드가 더 낫습니다.

한 번의 모델 호출과 검색만으로 충분한 질문
순서와 규칙이 완전히 정해진 단순 자동화
모든 단계가 동일한 긴 컨텍스트를 반드시 공유해야 하는 작업
하위 작업들이 서로 강하게 의존해 병렬화할 수 없는 작업
필요한 탐색 경로를 사전에 거의 예측할 수 없는 개방형 작업
추가 비용과 지연이 결과의 가치보다 큰 작업
무엇을 성공으로 볼지 아직 정하지 못한 실험

OpenAI는 먼저 단일 에이전트의 능력을 최대한 활용하고, 복잡한 조건문이나 비슷한 도구가 너무 많아 안정성이 떨어질 때 분리를 고려하라고 권합니다. Anthropic도 가장 단순한 해법에서 시작하고, 측정 가능한 개선이 있을 때만 복잡성을 더하라고 강조합니다.

특히 범용 심층 조사처럼 다음 행동이 앞선 발견에 따라 계속 달라지는 작업은 경로를 미리 고정할수록 탐색을 방해할 수 있습니다. 이런 경우에는 바깥에 예산·권한·승인 같은 최소한의 경계만 두고, 핵심 탐색은 하나의 유연한 에이전트 루프에 맡기는 편이 나을 수 있습니다.

Graph Engineering은 발전 단계의 훈장처럼 “반드시 도달해야 하는 것”이 아닙니다. 복잡성을 줄이기 위한 그래프가 오히려 새로운 복잡성을 만들 수 있기 때문입니다.

좋은 그래프를 설계하는 일곱 가지 원칙

1. 노드를 역할이 아니라 계약으로 정의한다

“리서처”, “전문가”처럼 멋진 이름만 붙이면 책임이 모호합니다. 각 노드에 입력, 출력, 사용 가능한 도구, 성공 기준을 적어야 합니다.

입력: 조사 질문 1개, 허용된 도메인 목록
출력: 핵심 주장 5개 이하, 각 주장별 출처 URL
도구: 웹 검색, 페이지 열기
금지: 최종 결론 작성, 파일 수정
종료: 출처가 3개 이상이거나 검색 예산 소진

이렇게 정의하면 노드를 독립적으로 테스트하고 다른 그래프에서도 재사용할 수 있습니다.

2. 자연어보다 구조화된 상태를 전달한다

“알아서 다음 담당자에게 잘 설명해 줘”라는 요청은 정보 손실을 만들기 쉽습니다. 결과를 정해진 필드에 넣고, 필수 항목이 없으면 다음 노드로 넘어가지 않게 해야 합니다.

다만 구조화가 지나치면 유용한 맥락을 잃을 수 있습니다. 원문 근거와 구조화된 요약을 함께 보관하고, 다음 노드에는 필요한 범위만 전달하는 방식이 현실적입니다.

3. 결정적 경로와 AI 판단을 구분한다

날짜 형식 확인, 권한 검사, 예산 비교 같은 일은 코드로 처리할 수 있습니다. 모호한 질문 분류나 조사 계획처럼 판단이 필요한 곳에만 LLM을 사용합니다.

그래프의 모든 엣지를 AI가 선택하게 하면 유연하지만 예측하기 어렵습니다. 반대로 모든 경로를 코드로 고정하면 안정적이지만 새로운 상황에 약합니다. 실전에서는 두 방식을 섞되, 결제·삭제·배포처럼 위험한 경로는 결정적 규칙과 인간 승인으로 보호하는 편이 좋습니다.

4. 생성자와 검증자의 정보·기준을 분리한다

검증 노드가 생성 노드의 자기평가를 그대로 읽으면 독립성이 약해집니다. 검증자는 원래 요구사항, 결과물, 외부 근거를 중심으로 판단해야 합니다.

검증 결과도 “별로임” 같은 감상이 아니라 다음 행동으로 연결되는 형태여야 합니다.

판정: 수정 필요
실패 기준: 출처 없는 수치 2개
대상 위치: 3번째 문단, 비교 표
다음 경로: 추가 조사 → 부분 수정 → 재검증

5. 성공보다 실패 경로를 먼저 그린다

정상 흐름만 그린 그래프는 데모에서는 잘 작동하지만 운영에서 멈춥니다.

도구 호출이 실패하면 몇 번 재시도할 것인가
일부 워커만 실패하면 전체를 취소할 것인가
같은 노드를 반복하면 언제 중단할 것인가
상태가 손상되면 어디까지 되돌릴 것인가
사람이 응답하지 않으면 언제 만료할 것인가

재시도 횟수, 시간, 토큰, 비용에 상한을 두고 실패를 사용자에게 설명할 수 있는 종료 상태를 만들어야 합니다.

장시간 실행되거나 외부 시스템을 변경하는 그래프에서는 다음 세 가지가 특히 중요합니다.

체크포인트는 각 단계의 상태를 저장해 장애가 발생해도 처음부터 다시 시작하지 않게 합니다.
멱등성은 같은 작업을 여러 번 실행해도 결과가 한 번 실행한 것과 같도록 만듭니다.
Backpressure는 워커 수와 도구 호출이 처리 능력보다 빠르게 늘어나는 것을 막습니다.

예를 들어 글 초안을 두 번 만드는 것은 비용 낭비로 끝날 수 있지만, 이메일 발송이나 결제가 두 번 실행되면 실제 피해가 생깁니다. 외부 행동에는 작업 ID + 행동 종류 + 대상처럼 중복을 판별할 수 있는 키를 붙이고, 이미 성공한 행동은 재시도 과정에서 다시 실행하지 않아야 합니다.

체크포인트만 있다고 안전한 것도 아닙니다. 저장 지점 이후의 작업은 복구 과정에서 다시 실행될 수 있으므로, 체크포인트와 멱등성을 함께 설계해야 합니다. 동시에 하나의 관리자가 만들 수 있는 워커 수, 전체 동시 실행 수, 도구 호출 횟수와 비용에도 상한을 둬야 합니다.

6. 관측 가능성을 결과물의 일부로 본다

최종 답만 저장하면 왜 그렇게 되었는지 알 수 없습니다. 최소한 다음 정보는 한 실행 단위로 연결되어야 합니다.

run_id와 node_id
노드별 입력과 구조화된 출력
선택한 엣지와 선택 이유
모델, 도구 호출, 지연 시간, 토큰과 비용
재시도와 오류
인간 승인 기록

그래프를 화면에 예쁘게 그리는 것보다, 실패한 실행을 재현할 수 있는 로그가 더 중요합니다.

7. 그래프 전체를 평가한다

개별 노드가 그럴듯한 답을 쓰는지와 전체 시스템이 목표를 달성하는지는 다릅니다. 노드 단위 평가와 끝에서 끝까지의 평가를 함께 운영해야 합니다.

예를 들어 리서치 그래프라면 출처 정확도, 핵심 정보 회수율, 중복 조사 비율, 최종 답변 품질, 처리 시간, 성공 1건당 비용을 봅니다. 새 노드를 추가한 뒤 품질은 2% 올랐지만 비용이 두 배가 되었다면 좋은 설계라고 보기 어렵습니다.

최종 문장만 읽는 평가도 충분하지 않습니다. 에이전트가 “예약을 완료했습니다”라고 답했는지가 아니라 실제 예약 데이터가 생성됐는지 확인해야 합니다. 이를 **출력(Output)**이 아니라 **결과 상태(Outcome)**를 평가한다고 표현할 수 있습니다.

또한 같은 입력에도 실행 결과가 달라질 수 있으므로 한 번의 성공만으로 안정성을 판단해서는 안 됩니다. 같은 대표 작업을 여러 번 실행하면서 성공률과 일관성을 확인하고, 최종 결과뿐 아니라 라우팅 정확도, 정보 누락, 반복 횟수, 복구 성공률, 사람의 수정 비율도 함께 측정해야 합니다.

처음 만드는 사람을 위한 실전 순서

Graph Engineering을 시작할 때 프레임워크부터 고를 필요는 없습니다. 먼저 종이에 실행 흐름을 그려도 충분합니다.

1단계: 현재 단일 루프의 기준선을 만든다

대표 작업 20~50개를 모으고 단일 에이전트의 성공률, 시간, 비용, 자주 발생하는 실패를 기록합니다. 기준선이 없으면 그래프가 실제로 나아졌는지 판단할 수 없습니다.

2단계: 반복되는 실패 하나만 분리한다

출처 누락이 가장 큰 문제라면 별도의 출처 검증 노드를 추가합니다. 도구 선택 오류가 문제라면 라우터를 추가합니다. 처음부터 여러 에이전트를 만드는 대신 관찰된 실패에 대응하는 노드 하나를 추가합니다.

3단계: 공유 상태의 스키마를 먼저 정한다

노드 구현보다 먼저 무엇을 전달할지 정합니다. 필수 필드, 작성 책임자, 갱신 규칙을 정의합니다. 여러 노드가 같은 배열에 결과를 동시에 추가한다면 병합 규칙도 필요합니다.

4단계: 엣지와 종료 조건을 코드로 명시한다

성공, 재시도, 추가 조사, 인간 승인, 실패 종료 경로를 모두 그립니다. 특히 루프백에는 최대 반복 횟수와 예산을 둡니다. 외부 행동 전후에는 체크포인트를 저장하고, 재실행해도 중복 부작용이 생기지 않는지 확인합니다.

5단계: 노드를 독립적으로 평가한다

라우터의 분류 정확도, 조사 노드의 출처 품질, 검증 노드의 오류 탐지율을 따로 측정합니다. 그래야 전체 결과가 나빠졌을 때 어느 노드가 원인인지 찾을 수 있습니다.

6단계: 실제 실패를 그래프에 되먹임한다

운영 로그에서 반복되는 실패를 모으고, 프롬프트를 고칠지, 도구 설명을 바꿀지, 상태를 추가할지, 그래프 구조를 바꿀지 결정합니다. Graph Engineering은 그래프를 한 번 그리는 일이 아니라 관측된 실패에 맞춰 구조를 계속 수정하는 과정입니다.

프레임워크보다 중요한 것

LangGraph, OpenAI Agents SDK, AutoGen, Google ADK 같은 도구는 노드, 상태, 핸드오프, 병렬 실행, 체크포인트를 구현하는 데 도움을 줍니다. 하지만 프레임워크가 다음 질문에 답해주지는 않습니다.

이 작업을 정말 나눠야 하는가
어느 단계에 AI 판단이 필요한가
누가 최종 결과의 품질을 책임지는가
어떤 실패는 재시도하고 어떤 실패는 즉시 멈출 것인가
추가된 비용과 지연이 가치 있는가

도구는 그래프를 실행하지만, 어떤 그래프를 실행할지는 사람이 설계합니다.

결국 설계 대상은 관계다

Prompt Engineering은 한 번의 요청을 다듬는 일에 가깝습니다. Context Engineering은 모델이 보는 정보를, Harness Engineering은 모델이 사용할 수 있는 환경과 도구를 설계합니다. Loop Engineering은 한 에이전트가 목표를 향해 반복하는 방법을 다룹니다.

Graph Engineering은 이 요소들을 버리지 않습니다. 잘 설계된 프롬프트, 컨텍스트, 도구, 루프를 노드로 삼아 그 사이의 관계를 설계합니다.

그래서 “Loop Engineering은 끝났고 Graph Engineering이 시작됐다”는 표현은 절반만 맞습니다. 루프는 사라지지 않습니다. 그래프 안에서 일을 수행하는 기본 단위로 남습니다. 달라지는 것은 관심의 범위입니다.

한 에이전트가 얼마나 똑똑한가에서, 여러 실행 단위가 어떻게 책임을 나누고 서로의 오류를 발견하며 안전하게 멈추는가로 시선이 이동합니다. Graph Engineering의 본질은 더 많은 AI가 아니라 더 명확한 구조, 더 좁은 권한, 더 좋은 검증, 더 관찰 가능한 협업입니다.