그래프 엔지니어링: AI 에이전트 워크플로를 구조화하는 설계 원칙

그래프 엔지니어링(Graph Engineering)은 AI 모델 하나의 답변 품질만 높이는 대신, 여러 작업과 도구가 어떤 순서와 조건으로 실행되는지 설계하는 접근법이다. 복잡한 업무를 노드와 연결 관계로 표현하면 각 단계의 입력·출력, 실패 원인, 재시도 경로와 사람의 승인 지점을 분리해 관리할 수 있다.

다만 이 표현은 아직 업계 전체가 합의한 단일 표준 용어가 아니다. 에이전트 워크플로 설계, 그래프 기반 오케스트레이션, 멀티 에이전트 제어를 포괄하는 실무적 개념으로 이해하는 것이 정확하다.

AI 엔지니어링에서 그래프가 등장한 배경

AI 애플리케이션의 설계 관심사는 다음과 같이 확장해 왔다. 이것은 모든 조직이 동일하게 거치는 공식 발전 단계라기보다 서로 보완되는 설계 계층이다.

프롬프트와 컨텍스트는 그래프 안에서도 계속 필요하다. 루프 역시 그래프의 순환 엣지로 표현할 수 있다. 따라서 그래프 엔지니어링은 앞선 기법을 폐기하는 기술이 아니라, 이들을 실행 구조 안에 배치하는 상위 수준의 설계 관점에 가깝다.

그래프 엔지니어링의 구성 요소

노드

노드(Node)는 하나의 명확한 책임을 가진 작업 단위다. LLM 호출뿐 아니라 데이터베이스 조회, 검색 API 호출, 형식 검증, 계산, 사용자 승인 대기 같은 일반 코드도 노드가 될 수 있다.

좋은 노드는 입력과 출력이 명확하고 독립적으로 시험할 수 있다. 시장 조사처럼 범위가 넓은 이름보다 지정 산업의 최근 자료 수집, 출처 중복 제거, 주장별 근거 검사처럼 책임을 좁히는 편이 디버깅에 유리하다.

엣지

엣지(Edge)는 한 노드에서 다음 노드로 이동하는 전이다. 항상 같은 다음 단계로 이동하는 고정 엣지, 상태를 검사해 경로를 선택하는 조건부 엣지, 여러 작업을 동시에 시작하는 분기 엣지가 있다.

상태

상태(State)는 그래프가 실행되는 동안 공유되는 데이터다. 사용자 요청, 중간 산출물, 검색 출처, 오류 코드, 승인 결과, 반복 횟수 등이 포함될 수 있다.

상태는 단순한 대화 기록과 다르다. 어떤 필드가 필수인지, 누가 수정할 수 있는지, 병렬 결과를 어떻게 합칠지, 민감정보를 언제 삭제할지를 스키마와 규칙으로 정의해야 한다.

조건

조건(Condition)은 다음 경로를 선택하는 규칙이다. 출처가 세 개 이상인가와 같은 결정적 조건은 코드로 판정할 수 있다. 반면 근거가 결론을 충분히 뒷받침하는가처럼 의미 판단이 필요한 조건은 모델 평가나 사람의 검토가 필요할 수 있다.

단일 에이전트보다 통제하기 쉬운 이유

하나의 에이전트에 조사, 분석, 작성, 검증을 모두 맡기면 결과가 잘못되었을 때 원인을 구분하기 어렵다. 계획 오류인지, 검색 누락인지, 도구 호출 실패인지, 근거 없는 생성인지가 하나의 실행 기록에 섞이기 때문이다.

작업을 그래프로 분해하면 다음 항목을 단계별로 관리할 수 있다.

• 노드마다 허용된 도구와 데이터 접근 권한을 제한한다.
• 중간 산출물을 저장하고 독립적으로 평가한다.
• 실패한 노드만 재실행해 비용과 시간을 줄인다.
• 중요한 외부 동작 직전에 사람의 승인을 받는다.
• 실행 경로, 지연 시간, 토큰 사용량과 오류를 추적한다.

그러나 노드를 많이 나눈다고 자동으로 신뢰성이 높아지는 것은 아니다. 상태 전달이 부정확하거나 평가 기준이 모호하면 오류가 여러 단계에 걸쳐 증폭될 수 있다.

대표적인 그래프 활용 패턴

라우터 패턴

라우터는 요청의 유형이나 위험도에 따라 다른 경로를 선택한다. 예를 들어 환불 문의는 정책 검색 노드로, 기술 장애는 진단 노드로 보낼 수 있다.

라우팅 기준이 단순한 키워드나 계정 상태라면 코드가 적합하다. 문맥을 해석해야 한다면 모델 분류를 사용할 수 있지만, 신뢰도가 낮을 때 기본 경로나 사람 검토로 보내는 안전장치가 필요하다.

병렬 실행 패턴

서로 의존하지 않는 작업을 동시에 수행한 뒤 집계 노드에서 결합한다. 시장, 고객, 경쟁사 조사를 병렬로 실행하는 방식이 대표적이다.

병렬화는 지연 시간을 줄일 수 있지만 호출 수와 순간 비용은 늘어난다. 결과가 같은 상태 필드를 동시에 수정한다면 충돌 해결 규칙과 병합 순서도 정해야 한다.

생성자·평가자 패턴

생성자가 초안을 만들고 평가자가 기준에 따라 통과, 수정 또는 재작성을 결정한다. 평가 결과가 생성자에게 돌아가므로 그래프 안에 루프가 형성된다.

평가자 역시 LLM이면 잘못된 판정을 할 수 있다. 가능한 항목은 스키마 검사, 테스트 실행, 인용 URL 확인 같은 결정적 검증으로 보완하고, 최대 반복 횟수를 설정해야 무한 반복을 막을 수 있다.

사용자 승인 패턴

외부 시스템 변경, 메시지 발송, 결제, 배포처럼 되돌리기 어렵거나 책임이 큰 동작 전에 실행을 중단하고 사람의 판단을 기다린다. 승인 화면에는 최종 결과만 보여주기보다 실행할 동작, 사용 데이터, 예상 영향과 되돌리기 방법을 함께 제시하는 편이 안전하다.

관리자·전문가 패턴

관리자 노드가 작업을 분해하고 검색, 분석, 작성 등 전문 노드에 배정한 뒤 결과를 취합한다. 역할 분리는 유용하지만 에이전트 수를 늘리는 것 자체가 목표가 되어서는 안 된다. 고정된 절차는 명시적 워크플로가 더 예측 가능할 수 있다.

AI, 코드, 사람의 역할을 나누는 원칙

규칙이 명확한데도 LLM을 사용하면 비용, 지연, 비결정성이 불필요하게 증가한다. 반대로 모든 판단을 코드 규칙으로 고정하면 표현이 다양한 실제 입력을 처리하기 어렵다. 좋은 그래프는 세 수단의 장점을 결합하고 각 경계에서 입력과 출력을 검증한다.

지식 그래프와 그래프 엔지니어링의 차이

두 개념은 관련될 수 있지만 동일하지 않다.

• 지식 그래프는 사람, 조직, 문서, 개념 같은 엔티티와 그 관계를 구조화한 데이터 표현이다.
• 에이전트 실행 그래프는 작업이 어떤 순서와 조건으로 실행되는지를 표현한다.
• 그래프 엔지니어링은 실행 그래프의 구조, 상태, 제어, 검증과 운영 방식을 설계하는 실무를 가리킬 수 있다.

지식 그래프 검색을 하나의 노드로 연결할 수는 있지만 그래프 엔지니어링에 지식 그래프가 반드시 필요한 것은 아니다. 반대로 지식 그래프를 구축한다고 해서 재시도와 승인 경로를 갖춘 에이전트 워크플로가 자동으로 만들어지는 것도 아니다.

운영 품질을 결정하는 숨은 설계 요소

그래프 그림만으로는 프로덕션 시스템이 완성되지 않는다. 실제 신뢰성을 좌우하는 요소는 실행 의미론과 운영 계약이다.

상태 계약과 버전 관리

각 노드의 입력·출력 스키마, 필수 필드, 데이터 출처와 갱신 권한을 정의해야 한다. 그래프를 변경한 뒤 이미 중단되어 있던 실행을 재개할 수 있도록 상태 스키마와 워크플로 버전의 호환성도 관리해야 한다.

실패 복구와 멱등성

네트워크 오류 뒤 노드를 재실행하면 이메일 발송이나 결제가 중복될 수 있다. 외부 부작용이 있는 작업에는 멱등성 키, 실행 전 확인, 보상 작업 또는 중복 방지 저장소가 필요하다.

실패도 모두 같지 않다. 일시적 API 오류는 재시도하고, 잘못된 입력은 사용자에게 돌려보내며, 정책 위반은 즉시 중단하는 식으로 오류 유형별 경로를 구분해야 한다.

종료 조건과 비용 예산

생성자·평가자 루프에는 최대 반복 횟수, 시간 제한, 토큰 또는 비용 한도를 둬야 한다. 품질 향상이 미미하면 종료하거나 사람에게 넘기는 조건도 필요하다.

그래프의 총비용은 개별 모델 호출 비용뿐 아니라 재시도, 병렬 호출, 상태 저장, 외부 도구와 관측 시스템까지 포함해 계산해야 한다.

관측성과 평가

운영 기록에는 어떤 노드와 모델이 실행되었는지, 어떤 경로가 선택되었는지, 입력·출력과 오류가 무엇이었는지 남겨야 한다. 다만 개인정보, 인증정보와 민감한 업무 데이터가 로그에 그대로 저장되지 않도록 마스킹과 보존 기간을 적용해야 한다.

평가는 최종 답변 점수만으로 끝나지 않는다. 라우팅 정확도, 도구 성공률, 근거 충족률, 승인 전 위험 탐지율, 평균 재시도 횟수처럼 노드와 경로별 지표를 함께 측정해야 병목을 찾을 수 있다.

보안과 권한 경계

검색 문서나 사용자 입력에 포함된 지시가 시스템 규칙을 바꾸는 프롬프트 인젝션을 고려해야 한다. 모델이 생성한 도구 인수는 실행 전에 검증하고, 각 노드에는 업무 수행에 필요한 최소 권한만 부여한다. 읽기, 쓰기, 삭제, 외부 발송 권한을 분리하면 한 노드의 오류가 전체 시스템 사고로 번지는 것을 줄일 수 있다.

그래프 엔지니어링이 적합한 경우

다음 조건이 여러 개 겹칠수록 그래프 구조의 효용이 커진다.

• 입력에 따라 다른 전문 처리 경로가 필요하다.
• 독립 작업을 병렬로 실행할 수 있다.
• 특정 단계가 실패하면 정해진 지점으로 돌아가야 한다.
• 중간 산출물을 검증하거나 감사해야 한다.
• 외부 시스템을 변경하기 전에 승인이 필요하다.
• 실행이 길어 중단 후 재개하거나 상태를 보존해야 한다.
• 도구별 권한과 데이터 접근 범위를 분리해야 한다.

단순 요약, 한 번의 분류, 짧은 질의응답에는 단일 모델 호출이나 짧은 순차 파이프라인이 더 낫다. 그래프 도입으로 생기는 상태 관리, 테스트, 관측과 배포 부담이 얻는 이익보다 크다면 오버 엔지니어링이다.

설계 검토 체크리스트

1. 최종 결과와 성공 기준을 측정 가능한 형태로 정의한다.
2. 각 노드를 한 가지 책임과 시험 가능한 입출력으로 제한한다.
3. 명확한 규칙은 코드로 구현하고 LLM 판단 범위를 최소화한다.
4. 상태 스키마와 병렬 결과의 병합 규칙을 정의한다.
5. 재시도 가능 오류와 즉시 중단할 오류를 구분한다.
6. 반복 횟수, 실행 시간과 비용의 상한을 설정한다.
7. 외부 부작용이 있는 노드에 중복 실행 방지 장치를 둔다.
8. 고위험 동작 앞에 사람의 승인과 충분한 설명을 배치한다.
9. 노드·경로별 로그, 평가 지표와 개인정보 보호 규칙을 마련한다.
10. 더 단순한 구조로 같은 신뢰성을 달성할 수 없는지 다시 확인한다.

핵심 정리

단일 에이전트가 유능한 직원 한 명에게 여러 업무를 한꺼번에 맡기는 방식이라면, 그래프 엔지니어링은 조직의 역할, 업무 전달 경로, 검수 절차와 결재선을 설계하는 일에 가깝다.

핵심은 에이전트 수가 아니라 통제 가능한 구조다. 어떤 단계에서 AI가 판단하고, 어디에서 코드가 검증하며, 언제 사람이 책임 있는 결정을 내리는지가 명확해야 한다. 여기에 상태 계약, 실패 복구, 관측성, 권한 통제와 비용 한도가 갖춰져야 그래프가 단순한 다이어그램을 넘어 운영 가능한 AI 시스템이 된다.