Graph Engineering - AI 에이전트 시스템 구축 방법

https://whrrari.substack.com/p/graph-engineering-how-to-build-ai

2026.8.13
[Graph Engineering: How to Build AI Agent Systems That Don't Break at Scale]

이 글은 단순한 프롬프트 작성 방식을 넘어, 인공지능 에이전트 시스템을 명확한 실행 지도인 그래프 형태로 설계하는 방법을 다루고 있습니다. 저자는 모든 작업을 하나의 긴 직선형 흐름으로 처리하면 시스템이 느려지고 비용이 낭비된다고 지적하며, 이를 해결하기 위해 작업 단위를 뜻하는 노드와 데이터 흐름을 정의하는 엣지를 활용할 것을 제안합니다. 특히 독립적인 작업을 동시에 처리하는 병렬성과 명확한 검증 단계를 도입함으로써, 대규모 환경에서도 안정적으로 작동하고 오류를 국소화할 수 있는 프로덕션 시스템 구축 방법을 체계적으로 설명하고 있습니다.

 

핵심 논지: 이 글에서 그래프 엔지니어링은 지식그래프나 그래프 데이터베이스 구축이 아닙니다. AI 에이전트의 작업을 명시적인 실행 그래프로 설계하는 일입니다. 무엇을 병렬로 실행하고, 어떤 결과를 다음 단계에 넘기며, 어디서 검증·재시도·중단·사람의 승인을 요구할지를 모델의 즉흥적 판단에만 맡기지 말자는 주장입니다. 아래의 ‘원문 요지’와 ‘분석·보완’은 구분해서 읽는 것이 좋습니다. 원문

도입 — 문제는 프롬프트보다 ‘일의 형태’에 있다

원문 요지. 많은 에이전트가 조사 → 작성 → 검토 → 배포처럼 일렬로 동작합니다. 앞 단계의 결과가 필요하지 않은 작업까지 기다리고, 모든 이력을 하나의 컨텍스트에 누적해 지연·비용·혼란을 키웁니다. 저자는 이를 프롬프트의 문제가 아니라 작업 간 의존성 설계의 문제로 봅니다.

분석·보완. 적절한 문제 제기지만 선형 실행 자체가 결함은 아닙니다. 검토가 실제 작성물을 읽어야 한다면 순서는 필수입니다. 설계 대상은 ‘단계를 없애는 것’이 아니라 필수 의존성과 관성적으로 붙인 순서를 구별하는 것입니다.

 

개념 정의 — 노드, 엣지, 상태, 라우터, 게이트

요소	원문의 의미	설계 시 확인할 질문
노드	경계가 정해진 작업 단위	입력·출력·실패를 독립적으로 정의할 수 있는가?
엣지	작업 사이의 실제 의존성	어떤 데이터 또는 실행 권한이 넘어가는가?
상태	노드 사이에 보존되는 데이터	중단 후 어디서 재개할 수 있는가?
라우터	다음 경로를 고르는 규칙	경로 선택 사유를 기록·설명할 수 있는가?
게이트	계속 진행해도 되는지 판정하는 검사	실패 시 수리·중단·승인 중 무엇을 하는가?

노드는 반드시 LLM 에이전트일 필요가 없습니다. 코드 함수, 도구 호출, 검증기, 사람의 승인도 노드입니다. 이 구분이 중요합니다. 모든 일을 에이전트에게 시키는 구조가 아니라, 판단이 필요한 곳에만 모델을 배치하는 구조이기 때문입니다.

 

1. 모든 ‘그리고 나서’를 의존성으로 취급하지 말라

원문 요지. 시장자료 수집, 저장소 점검, 경쟁사 가격 확인이 서로의 출력을 읽지 않는다면 동시에 수행한 뒤 종합할 수 있습니다. 판단 기준은 “다음 작업이 이전 작업의 출력을 실제로 읽는가?”입니다.

분석·보완. 실행 순서를 의존성 그래프로 바꾸는 첫 단계입니다. 다만 데이터 의존성이 없어도 공유 자원 의존성은 있을 수 있습니다. 같은 파일을 수정하거나, 동일 API의 호출 한도를 공유하거나, 앞선 단계의 승인 없이는 조회할 수 없는 작업은 무조건 병렬화하면 안 됩니다. 병렬 가능성은 입력뿐 아니라 권한·부작용·자원 경합까지 확인해야 합니다.

 

2. 각 노드에 계약을 부여하라

원문 요지. 노드는 하나의 임무, 명시적 입력, 구조화된 출력, 분명한 실패 상태를 가져야 합니다. 글의 source_researcher 예시는 주제와 1차 출처 유형을 입력받아 주장·출처 URL·신뢰도를 반환하거나 no_primary_source_found로 실패합니다.

분석·보완. 이 계약이 있어야 노드를 개별 테스트하고 모델이나 도구를 교체할 수 있습니다. 다만 JSON 형식에 맞는 출력과 사실상 신뢰할 수 있는 출력은 다릅니다. URL 필드가 존재해도 링크가 깨졌거나 주장을 뒷받침하지 않을 수 있습니다. 따라서 스키마 검증과 출처 내용 검증은 별도 게이트여야 합니다. confidence: high 역시 모델의 자기평가만으로 확정하지 않는 편이 안전합니다.

 

3. 엣지는 화살표가 아니라 데이터 계약이다

원문 요지. A → B는 단순히 B가 A 뒤에 실행된다는 뜻이 아니라, A가 만든 특정 데이터를 B가 소비할 수 있다는 뜻이어야 합니다. 배열 평탄화, 중복 제거, null 제거, 상태 확인은 모델 호출 대신 결정론적 코드로 처리하라고 권합니다.

분석·보완. ‘판단은 모델, 배관 작업은 코드’라는 실용적인 원칙입니다. 단, 예시처럼 source_url만으로 중복 제거하면 동일 URL에 담긴 서로 다른 주장까지 하나로 합칠 위험이 있습니다. 데이터 계약에는 필드 형식뿐 아니라 식별 기준, 버전, 출처 위치, 결측 처리, 중복 판정 기준까지 포함하는 것이 좋습니다.

 

4. 네 가지 기본 형태를 익혀라

• 체인 A → B → C: 각 단계가 바로 앞 결과를 필요로 할 때 적합합니다.
• 다이아몬드: 독립적인 가지로 분할·병렬 실행한 뒤 하나로 합칩니다.
• 라우터: 위험도나 작업 종류에 따라 간단한 경로와 정밀 경로 중 선택합니다.
• 통제된 순환: 작업 결과를 검증하고, 실패 근거가 있을 때만 피드백을 받아 다시 수행합니다.

분석·보완. 네 형태는 복잡한 워크플로를 설명하기 좋은 기본 어휘입니다. 그러나 형태만 그려서는 운영 설계가 끝나지 않습니다. 특히 다이아몬드에는 합류 조건, 라우터에는 오분류 대응, 순환에는 종료 조건과 예산이 필요합니다. 원문의 요점도 “그래프를 복잡하게 그리라”가 아니라, 실제 의존성에 맞는 최소 구조를 선택하라는 데 있습니다.

 

5. 독립 작업은 펼치되, 합류는 의도적으로 배치하라

원문 요지. 독립적인 조사 노드는 병렬 실행할 수 있습니다. 글은 Promise.allSettled를 사용해 일부 가지가 실패해도 성공한 결과를 회수하는 예를 제시합니다. 전체 결과가 필요한 중복 제거·비교·포괄성 판단 단계에서만 합류 장벽을 두고, 각 항목이 독립적으로 이어질 수 있다면 스트리밍하라고 합니다.

분석·보완. allSettled는 부분 실패를 견디는 수단이지, 부분 결과가 충분하다는 보증은 아닙니다. 세 출처 중 하나가 실패했는데 나머지만 종합하면 핵심 견해가 빠질 수 있습니다. 합류 지점에는 “필수 출처가 모두 도착했는가”, “최소 커버리지를 충족했는가”, “실패한 가지를 명시할 것인가” 같은 조건을 둬야 합니다. 병렬 실행의 이익은 가장 느린 필수 가지와 합류 장벽의 위치에 의해 제한됩니다.

 

6. 라우팅 결정을 점검 가능하게 만들라

원문 요지. 모델이 변경 사항의 위험도를 판단하더라도, 실제 허용 경로는 코드가 제한해야 합니다. 예시는 low → 간이 검토, high → 전면 병렬 감사, 그 외 → 사람 검토입니다. 즉 확률적인 분류와 결정론적인 실행 권한을 분리합니다.

분석·보완. 감사 가능성과 권한 통제에 유용한 설계입니다. 다만 저위험 오분류가 곧 검토 누락이 될 수 있으므로, 분류 기준·근거·모델 버전을 기록하고 경계 사례를 사람에게 보내는 정책이 필요합니다.

중요한 사실관계 보정: 원문은 OpenAI의 시각적 Agent Builder를 이러한 흐름의 사례로 소개합니다. 하지만 OpenAI의 공식 안내에는 2026년 6월 3일 업데이트로 Agent Builder와 Evals 제품을 단계적으로 종료하며, 2026년 11월 30일부터 플랫폼에서 이용할 수 없게 된다고 명시되어 있습니다. 따라서 설계 원칙의 예시는 될 수 있어도, 현 시점의 신규 구축 도구 추천으로 받아들이면 안 됩니다.

 

7. 검증을 다음 단계로 넘어가는 경계에 놓아라

원문 요지. 검증기는 새로운 내용을 생산하지 않아도 잘못된 결과의 전파를 막습니다. 주장별 출처 존재 여부, 출처의 실제 지지 여부, 코드 테스트, 출력 스키마, 독립 경로의 결론 일치 등을 확인합니다. 생성·승인·공개를 같은 에이전트의 동일 컨텍스트에 맡기지 말라고 권합니다.

분석·보완. 여기서 핵심은 역할 분리보다 판정 기준의 독립성입니다. 생성기와 검증기를 다른 프롬프트로 실행해도 둘 다 같은 잘못된 자료만 읽는다면 오류가 반복됩니다. 기계적으로 판정할 수 있는 것은 테스트·스키마 검사로, 의미 판정은 원문 대조와 독립 증거로, 고위험 공개는 사람의 승인으로 분리하는 편이 강합니다. 글이 인용한 Anthropic의 연구 시스템 설명은 병렬 하위 에이전트의 조사 후 별도 CitationAgent가 인용 위치를 붙이는 구조를 실제로 설명합니다.

 

8. 다이어그램에 가려진 핵심은 지속 상태다

원문 요지. 운영 그래프에는 작업 ID, 현재·완료 노드, 산출물, 결정, 증거, 예산, 재시도 횟수, 사람의 승인 상태가 남아야 합니다. 노드 사이에 긴 대화록을 계속 복사하기보다 산출물의 경로·ID·구조화된 요약을 넘기라고 합니다.

분석·보완. 장애 복구와 추적성을 위해 매우 중요한 부분입니다. 운영 상태는 최소한 “무엇이 끝났는가 / 왜 이 경로를 택했는가 / 어디서 안전하게 재개하는가”에 답해야 합니다. 한 단계 더 나아가 산출물 참조에는 버전·무결성 식별자·접근권한을 붙여야 합니다. 그렇지 않으면 재개한 노드가 이전 검증 때와 다른 파일을 읽을 수 있습니다. 대화록을 줄이는 것은 유익하지만, 요약만 전달하다 중요한 근거가 손실되지 않도록 원본 산출물 접근 경로를 유지해야 합니다.

 

9. 수렴하는 순환만 허용하라

원문 요지. “좋아질 때까지 반복”은 종료 조건이 아닙니다. 글의 발견 루프는 새 발견이 없는 회차와 최대 반복 횟수를 세고, 이미 본 항목을 기억해 같은 실패 후보를 다시 찾지 않도록 합니다. 모든 순환에는 완료 판정, 최대 횟수, 비용 예산, 시도 기록, 미수렴 시 상향 경로가 필요합니다.

분석·보완. 발견 작업과 수정 작업의 수렴 지표는 달라야 합니다. 조사라면 새롭고 검증된 근거의 증가, 코드 수정이라면 실패 테스트의 감소와 회귀 여부가 지표가 될 수 있습니다. 원문의 예시 코드는 ‘새 항목이 없는 회차’를 세는 개념 예시이지, 발견한 항목의 품질까지 검증하는 구현은 아닙니다. 중복 기억 장치 역시 ‘이미 보았음’과 ‘검증을 통과했음’을 별도로 기록해야 재발견 방지와 결과 품질 관리를 함께 할 수 있습니다.

 

10. 실패를 가능한 한 국소화하라

원문 요지. 노드 실패마다 정책을 정합니다. 일시 장애는 RETRY, 대체 모델·출처는 FALLBACK, 선택적 가지는 SKIP, 형식 오류는 REPAIR, 높은 위험·불확실성은 ESCALATE, 예산·안전·권한 경계는 STOP입니다. 비싼 노드 뒤에 체크포인트를 두고, 재시도 가능한 쓰기는 멱등적으로 설계하라고 합니다.

분석·보완. 특히 읽기 재시도와 쓰기 재시도는 다릅니다. 조회를 다시 하는 것은 대체로 안전하지만 메일 발송·결제·게시·레코드 생성은 중복 부작용을 낳을 수 있습니다. 이런 노드에는 멱등성 키, 실행 결과 조회, 승인 범위가 필요합니다. 파일을 변경하는 병렬 작업자에게 격리된 작업 공간을 주라는 제안도 충돌을 줄이지만, 마지막 병합·검증 책임까지 없애지는 않습니다.

 

11. 그래프의 형태가 비용 구조다

원문 요지. 에이전트를 많이 띄운다고 반드시 빠르거나 저렴해지지 않습니다. 단순 요청은 짧은 경로와 가벼운 모델로, 복잡한 요청은 계획·전문 작업·검증·종합·사람 승인 경로로 보냅니다. 병렬화·전문화·독립 검증의 가치가 조정 비용을 상쇄할 때만 큰 그래프를 사용하라는 취지입니다.

근거와 해석. Anthropic의 자체 보고에 따르면 자사 내부 연구 평가에서 멀티에이전트 구성이 단일 에이전트보다 특정 폭넓은 탐색 과제에서 우수했고, 토큰 사용량은 채팅 대비 멀티에이전트가 약 15배였습니다. 이는 해당 시스템·평가 조건의 관측값이지, 모든 그래프가 그만큼 성능을 높이거나 비용을 쓴다는 일반 법칙이 아닙니다. 설계 시에는 토큰 비용과 함께 실행 지연, 실패 재처리, 사람 검토 비용을 같은 표에서 비교해야 합니다.

 

12. 조사·발행용 운영 그래프 예시

원문 흐름: 주제 설정 → 범위·완료 기준 설정 → 독립 조사 경로로 분해 → 기업 자료·논문·전문가 글 병렬 수집 → 결정론적 중복 제거 → 근거에 기반한 초안 → 주장·인용·누락 검사 → 필요한 부분만 수정 → 사람 승인 → 발행.

분석·보완. 이 예시의 강점은 재작업의 범위를 좁힌다는 점입니다. 인용 하나가 틀렸다면 전체 조사를 처음부터 반복할 필요 없이 해당 주장과 문단을 수정합니다. 그러나 기업 자료·논문·전문가 글은 서로 대체 가능한 동등 증거가 아닙니다. 기업의 제품 설명은 1차 자료일 수 있지만 성능에 관한 독립 검증은 아닐 수 있습니다. 발행 게이트에는 주장별 증거 유형, 출처 신뢰도, 반례 검토, 승인자를 남기는 것이 적절합니다.

 

마무리 — 그래프가 오히려 틀린 답인 경우

저자는 작업이 짧고, 하나의 컨텍스트에 필요한 정보가 들어가며, 독립 가지가 없고, 실패 비용이 낮고, 사람이 최종 결과를 쉽게 검토할 수 있다면 단일 에이전트·단일 루프를 유지하라고 합니다. 반대로 병렬 작업, 도구·권한 분리, 독립 검증, 장애 후 재개, 공유 상태, 경로별 비용·권한 통제가 필요할 때 그래프가 가치 있습니다.

마지막의 프롬프트 → 컨텍스트 → 하네스 → 루프 → 그래프는 기술의 엄격한 성숙도 단계라기보다 설계 관심사의 범위를 넓혀 보여주는 도식으로 읽는 편이 정확합니다. 좋은 프롬프트가 그래프를 대체하지 못하듯, 좋은 그래프도 부정확한 자료나 약한 검증 기준을 자동으로 고쳐주지는 않습니다.

 

실무 적용 시 핵심 판정표

설계 결정	먼저 정할 기준
병렬화	입력뿐 아니라 파일·API 한도·권한·부작용도 독립적인가?
합류	전체 결과가 필수인가, 최소 커버리지로 진행 가능한가?
노드 계약	입력·출력·실패 코드·버전·산출물 참조가 명시됐는가?
검증	형식 검사와 사실·근거 검사를 분리했는가?
재시도	외부 쓰기가 중복 실행돼도 안전한가?
순환	수렴 지표·반복 상한·비용 상한·미수렴 시 조치가 있는가?
운영	경로 선택 이유와 안전한 재개 지점을 재현할 수 있는가?

 

종합 평가: 이 글의 가장 유용한 메시지는 “멀티에이전트를 도입하라”가 아닙니다. 실제 의존성만 연결하고, 판단·검증·권한·상태를 명시적으로 분리하라는 것입니다. 다만 원문은 설계 패턴 중심의 글이므로 성능·비용의 보편적 입증이나 완전한 운영 명세로 취급해서는 안 됩니다. 특히 현재는 원문에 등장하는 Agent Builder의 종료 안내까지 반영해, 제품 사례와 지속 가능한 아키텍처 원칙을 구별할 필요가 있습니다.

 

이미지는 AI 에이전트의 작업 흐름을 설계할 때 쓰는 네 가지 기본 구조를 보여줍니다. 상자는 작업, 화살표는 다음 작업으로 넘어가는 흐름입니다.

구조	그림의 흐름	의미와 적합한 경우
① 체인(Chain)	A → B → C	엄격한 순차 의존성. B가 A의 결과를, C가 B의 결과를 반드시 필요로 할 때 사용합니다. 예: 자료 추출 → 분석 → 보고서 작성.
② 다이아몬드(Diamond)	A → B1·B2·B3 → C	A 이후 독립 작업을 병렬로 실행하고 합칩니다. 예: 같은 과제를 법률·기술·보안 관점에서 각각 검토한 뒤 종합. 합류 지점 C는 필요한 결과가 도착했는지 확인해야 합니다.
③ 라우터(Router)	CLASSIFY → QUICK PATH 또는 FULL AUDIT	작업의 상태나 위험도를 분류해 필요한 경로만 선택합니다. 예: 단순 수정은 간이 검토, 고위험 변경은 전면 감사.
④ 통제된 순환(Controlled Cycle)	WORK → VERIFY → PASS? → 통과 시 EXIT, 실패 시 FEEDBACK → WORK	결과를 검증하고 실패한 경우에만 수정·재검증합니다. 그림 아래의 repeat with limits처럼 반복 횟수와 비용의 상한을 둬야 무한 루프를 막을 수 있습니다.

 

핵심은 네 구조를 무조건 모두 쓰는 것이 아닙니다. 실제 의존성이 있으면 체인, 독립 작업이면 다이아몬드, 위험도에 따라 작업량을 달리해야 하면 라우터, 검증 후 보완이 필요하면 통제된 순환을 선택하거나 조합하는 것입니다.

 

이 그림의 제목은 “Verification Belongs on the Edge”, 즉 검증은 결과가 다음 단계로 넘어가는 경계에 있어야 한다는 뜻입니다. 부제인 “Weak work stops before it moves downstream”은 품질이 부족한 결과를 후속 작업으로 전파하지 말라는 의미입니다.

생성 → 형식 검사 → 근거 검사 → 독립 검토 → 통과 게이트

├─ YES → 종합

└─ NO → 실패 부분 수정 → 생성 단계로 복귀

단계	그림의 표기	확인하는 내용
결과 생성	GENERATOR	초안·분석 결과 등 작업 산출물을 만듭니다.
형식 검사	SCHEMA CHECK	필수 항목, 데이터 형식, 지정된 출력 구조를 충족하는지 확인합니다.
근거 검사	EVIDENCE CHECK	[출처] 가 존재하는지뿐 아니라 해당 출처가 실제로 주장을 뒷받침하는지 확인합니다.
독립 검토	INDEPENDENT REVIEW	생성 작업과 분리된 검토자가 오류·누락·편향을 점검합니다.
통과 판정	PASS GATE	기준을 충족한 결과만 다음 단계로 보냅니다.
종합	SYNTHESIZER	검증을 통과한 결과를 모아 최종 산출물을 만듭니다.
수정	REPAIR	실패한 작업만 보완합니다. 그림에도 “only failed work returns”라고 적혀 있습니다.

 

근거가 틀린 항목 하나 때문에 통과한 나머지 항목까지 다시 작성하지 않는 것이 이 그림의 운영상 핵심입니다.

단, 그림의 되돌림 화살표는 개념도입니다. 실제 구현에서는 어느 검사에서 왜 실패했는지를 수정 단계에 전달하고, 수정 후에는 영향을 받은 검사를 다시 수행해야 합니다. 반복 횟수의 상한도 별도로 정해야 합니다.

 

 

이 그림은 하나의 주제를 근거가 검증된 글로 발행하기까지의 운영용 작업 그래프입니다. 부제 “Independent research lanes merge into one verified artifact”는 독립적인 조사 경로를 하나의 검증된 산출물로 합친다는 뜻입니다.

 

주제 → 범위 설정 → 조사 과제 분해

                    ├─ 기업 자료 조사 ─┐

                    ├─ 연구논문 조사 ──┼→ 중복 제거 → 초안 → 최종 검사

                    └─ 전문가 글 조사 ─┘                    ├─ 통과 → 사람 승인 → 발행

                                                                          └─ 실패 → 해당 부분 수정 → 초안

단계별 의미

1. TOPIC → SCOPE → DECOMPOSE 무엇을 쓸지 정한 뒤, 대상 독자·조사 범위·완료 기준을 확정하고 독립적으로 조사할 수 있는 과제로 나눕니다. 범위가 정해지지 않으면 조사 경로가 서로 중복되거나 중요한 쟁점을 빠뜨리기 쉽습니다.

1. COMPANY SOURCES / RESEARCH PAPERS / EXPERT POSTS 기업 자료, 연구논문, 전문가 글을 각각 조사합니다. 서로의 결과를 기다릴 필요가 없다면 병렬로 진행합니다. 다만 세 자료 유형의 증거력은 같지 않습니다. 예를 들어 기업의 성능 주장을 확인하려면 기업 자료만으로는 부족할 수 있습니다.

1. DEDUPE → DRAFT 수집 결과에서 같은 자료나 동일한 주장의 중복을 정리한 뒤, 남은 근거를 사용해 초안을 작성합니다. 중복 제거는 단순히 URL만 비교하기보다 주장과 출처 위치까지 고려해야 합니다.

1. FINAL CHECK 초안의 주장·인용·누락·형식 등을 검사합니다. PASS면 사람 승인으로, FAIL이면 그림 아래의 REPAIR SECTION으로 이동합니다. 점선 화살표가 보여주듯 실패한 부분을 수정해 초안 단계로 되돌리는 것이지, 모든 조사를 처음부터 다시 하는 구조는 아닙니다.

1. HUMAN APPROVAL → PUBLISH 자동 검사를 통과해도 곧바로 발행하지 않습니다. 사람이 최종 내용을 확인하고 승인한 뒤 발행합니다. 이 단계는 글의 대외 공개에 대한 책임과 권한의 경계입니다.

아래쪽 ‘SHARED STATE’가 중요한 이유

그림 하단에는 모든 단계가 참조할 수 있는 공유 상태로 TASK ID(작업 식별자), SOURCES(출처), ARTIFACTS(산출물), DECISIONS(결정), BUDGET(예산), CHECKPOINTS(재개 지점)가 표시돼 있습니다. 이는 단순한 기록 목록이 아닙니다. 중단 후 재개할 때 어떤 자료를 사용했는지, 왜 그 결정을 했는지, 어디까지 완료했는지를 확인하게 해주는 운영 기반입니다.

요점: 이 그래프는 ‘에이전트를 많이 투입하는 방법’보다 조사는 병렬화하고, 근거는 정리하며, 오류는 국소적으로 수정하고, 공개는 사람에게 승인받는 방법을 설명합니다.