최근, AI 에이전트(Agent) 개발 문맥에서 Graph Engineering이라는 말을 자주 접하게 되었다.

2026년 7월에는 「Loop에서 Graph로 옮겨갔는가」라는 논의가 실무자들 사이에서 주목받고 있으며, LangGraph를 개발하는 LangChain도 Graph Engineering을 테마로 한 기사를 공개하고 있다. 다만, 해당 기사 자체에서도 Agent 시스템을 Graph로 표현하는 사고방식은 이전부터 존재해 왔으며, Graph Engineering은 새로운 이름일 뿐 새로운 발상은 아니라고 설명하고 있다. (langchain.com)

당초 나는 다음과 같은 기술을 상상하고 있었다.

여러 Agent를 Node로 연결하면, 단일 Agent Loop보다 자율성이 높아지고 인간의 개입을 줄일 수 있지 않을까.

하지만 관련 연구나 구현의 역사를 추적해 보니, 그렇게 단순한 진화 관계는 아니었다.

Graph Engineering은 Agent를 더욱 자유롭게 움직이기 위한 생각일 뿐만이 아니다.

오히려 Agent, 도구(Tool), 코드로 규정하는 처리, 검증, 인간의 판단 등을 포함하는 복잡한 시스템에 대해, 실행 구조 그 자체를 설계·관측·평가·개선의 대상으로 다루는 관점이라고 생각하면 이해하기 쉽다.

Graph Engineering이라는 말이 가리키는 범위는 현시점에서 자료마다 다르다. 이번에 확인한 범위 내에서는 AI 에이전트 분야에서 널리 합의된 정의나 표준 사양은 찾을 수 없었다.

LangGraph의 개발사인 LangChain은 단일 Agent의 순환적인 처리나, 코드로 실행 경로를 규정한 처리와 Agent에 의한 판단을 조합한 구조를 포함하여, Agent 시스템을 Graph로 표현하는 사고방식을 넓은 의미의 Graph Engineering으로 파악하고 있다. (langchain.com)

한편, 개인이 공개한 큐레이션 자료인 Awesome Graph Engineering은 Graph Engineering을 신흥 비표준 용어라고 명시한 상태에서, 여러 개의 독립된 Agent, 명시적인 협조 관계, 검사 가능한 Graph 구조를 최소 조건으로 하는 더 좁은 작업 정의를 채택하고 있다. (GitHub)

다만, 후자는 분야 전체에서 합의된 정의가 아니라 큐레이터가 자료를 정리하기 위해 설정한 작업 정의이다. 여기서는 같은 시기의 자료 사이에서도 Graph Engineering이 가리키는 대상 범위가 일치하지 않는 한 사례로서 참조하고 있다.

이번에 확인한 자료의 범위에서는 적어도 다음과 같은 점들이 일치하지 않는다.

• 단일 Agent 내부의 Graph를 포함할 것인가
• 복수 Agent가 필수인가
• 설계도로서의 Graph까지 포함할 것인가
• 실행 가능한 Graph만을 대상으로 할 것인가
• 고정된 Graph뿐만 아니라, 동적으로 생성되는 Graph도 포함할 것인가

따라서 본 기사에서는 특정 정의를 정답이라 하지 않고, 다음과 같이 넓게 정의한다.

LLM을 포함한 실행 시스템의 구성 요소와 관계를 Graph로 나타내고, 그 구조를 설계·실행·관측·평가·개선하는 실천.

참고로 이는 업계 표준으로 확립된 정의가 아니라, 본 기사의 논의를 정리하기 위한 작업 정의이다.

Graph Engineering이라는 명칭이 주목받은 것은 최근이지만, 그 배경에 있는 기술은 단계적으로 발전해 왔다.

단순한 일직선은 아니지만, 대략 다음과 같은 관심의 확산으로 볼 수 있다.

단일 Agent의 사고와 행동
↓
복수 Agent나 도구의 협조
...

2022년에 프리프린트(preprint)가 공개되고 ICLR 2023에서 발표된 ReAct는, LLM에 의한 추론과 외부 환경에 대한 행동을 교대로 실행하는 방법을 제시했다.

Agent가 상황을 관찰하고, 생각하고, 도구를 사용하고, 그 결과를 다시 관찰한다는, 현재의 Agent Loop로 이어지는 대표적인 연구이다. (ICLR 2023)

생각한다
↓
행동한다
...

이 구조에서는 다음에 무엇을 할지의 대부분을 하나의 모델이 판단한다.

유연성은 높지만, 모든 판단을 모델에 맡기기 때문에 특정 순서를 지키게 하고 싶거나 권한, 검증, 정지 조건을 엄격하게 제어하고 싶은 경우에는 추가적인 메커니즘이 필요하다.

2023년에 프리프린트가 공개되고 COLM 2024에서 발표된 AutoGen은, LLM, 도구, 인간 등을 조합한 복수 Agent가 대화를 통해 협조하는 프레임워크를 제시했다.

고정된 대화 순서뿐만 아니라, LLM이 다음에 호출할 Agent를 선택하는 동적인 구성도 다루고 있다. (COLM 2024)

마찬가지로 2023년에 공개된 DyLAN은 Agent를 네트워크상의 Node, Agent 간의 메시지를 Edge로 표현하며, 태스크에 따른 Agent 선택이나 조기 종료를 통해 협조 구조를 동적으로 변화시키는 방법을 연구하고 있다. (arXiv)

이 단계에 이르면 문제는 개별 Agent의 능력에만 국한되지 않는다.

• 어떤 Agent를 참여시킬 것인가
• 누가 누구에게 정보를 전달할 것인가
• 어떤 순서로 처리할 것인가
• 어디에서 합의나 검증을 수행할 것인가
• 언제 처리를 종료할 것인가

이러한 Agent 간의 관계 또한 시스템 전체의 성능을 좌우한다.

LangGraph는 2024년 1월, Agent Runtime에서 필요로 하는 순환적인 처리를 공유 State, Node, Edge를 가진 Graph로 구축하기 위해 공개되었다.

단순한 Agent Loop에 모든 판단을 맡기는 것이 아니라, 다음과 같은 제어를 가하기 쉽게 만드는 것이 당초 목적이라고 설명되어 있다. (langchain.com)

• 특정 도구 (Tool)를 먼저 호출하게 함
• 출력 형식을 고정함
• 검증 프로세스를 통과하게 함
• 인간의 확인을 거치게 함
• 재시도 횟수에 상한을 둠

여기서 중요한 점은 Graph가 반드시 DAG (Directed Acyclic Graph)는 아니라는 것이다.

Agent 시스템에서는 재시도, 추가 조사, 수정, 사용자 확인 등이 필요하다. 따라서 실제 Graph에는 순환 (Cycle)이 포함되는 경우가 많다.

LangChain 또한 Agent Graph는 일반적으로 DAG가 아닐 수 있으며, Loop는 순환 Graph의 단순한 형태로 이해될 수 있다고 설명한다. (langchain.com)

2024년 ICML에서 발표된 GPTSwarm은 LLM 호출이나 도구 이용을 Node로, 처리 및 통신 관계를 Edge로 나타내어, Agent 및 다중 Agent 구성을 최적화 가능한 Graph로 다루었다.

Prompt뿐만 아니라 Node, Edge, Agent 간의 연결 구조 그 자체를 진화적 기법이나 강화학습 (RL) 등을 통해 개선하는 방향성을 제시하고 있다. (ICML 2024)

2026년에 공개된 Workflow Optimization에 관한 서베이 (프리프린트)에서는 LLM 호출, 검색, 도구 이용, 코드 실행, 메모리 업데이트, 검증 등을 조합한 Workflow를 Agentic Computation Graph로 통합하여 정리하고 있다.

그곳에서는 고정된 Graph뿐만 아니라 다음과 같은 메커니즘까지 연구 대상에 포함되어 있다. (arXiv)

• 실행 전에 Graph를 생성함
• 태스크에 따라 Graph를 선택함
• 실행 도중에 Graph 구조를 변경함
• 실행 결과에 기반하여 Graph를 개선함

이러한 흐름을 고려하면, Graph Engineering은 갑자기 나타난 신기술이라기보다,

Agent Loop, Multi-Agent 협조, Stateful Workflow, Workflow 구조의 최적화라는 흐름을 Graph라는 공통된 관점으로 재정의하는 움직임

이라고 이해하는 것이 가까울 것이다.

초기 Agent에서는 하나의 모델이 도구를 사용하며 Loop를 돌리는 구성만으로도 많은 것을 시도할 수 있었다.

하지만 Agent 시스템이 실무로 확장됨에 따라 다음과 같은 구성 요소들이 늘어나고 있다.

• LLM에 의한 의미 판단
• 코드로 처리 절차나 판정 조건을 규정한 처리
• 검색이나 코드 실행 등의 도구 (Tool)
• 장시간 처리를 위한 State나 Memory
• 전문성이 다른 Agent
• 출력을 확인하는 Verifier
• 인간에 의한 승인
• 실패 시의 재시도나 에스컬레이션 (Escalation)

2026년의 Workflow Optimization 서베이도 현재의 Agent 시스템에서는 개별 모델 호출뿐만 아니라, 무엇을, 언제 호출하고, 어떻게 정보를 흐르게 할 것인가라는 Workflow 구조가 품질과 효율 양측 모두에 영향을 미친다고 정리하고 있다. (arXiv)

나아가 LangChain은 최근의 변화로서, Graph의 Node에 단순한 LLM 호출뿐만 아니라 독자적인 Loop를 가진 Agent 전체를 배치할 수 있게 되었다는 점을 언급하고 있다.

즉, 현재는 "처리를 Graph로 만드는 것"뿐만 아니라, 자율적으로 움직이는 Agent들끼리를 Graph로서 조합하는 것이 현실적인 선택지가 되어가고 있다. (langchain.com)

이러한 복잡화로 인해 관심의 대상이 Agent 단체에서 시스템 전체로 확장되었다.

Agent 단체를 어떻게 똑똑하게 만들 것인가
↓
Agent나 처리를 어떻게 조합할 것인가
...

이것이 Graph Engineering이라는 용어가 지금 다시금 주목받고 있는 배경이라고 생각된다.

Graph Engineering의 목적은 단순히 Node나 Agent를 늘리는 것이 아니다.

본 기사에서는 이를 다음과 같이 파악하고 있다.

Agent 시스템의 실행 구조를 일급 설계 대상(First-class design object)으로 삼고, Agent, 코드로 규정하는 처리, 도구(Tool), 상태(State), 검증, 인간의 판단을 적절한 관계와 경계로 조합하는 것.

개념적으로는 다음과 같은 구성이 된다.

여기서 중요한 것은 Agent와 코드가 Graph의 입구에서 이지선다(二者択一) 형태가 아니라는 점이다.

하나의 태스크는 정규화, 계획, 조사, 집계, 초안, 검증, 리뷰라는 단계를 거치며 양자를 수없이 오간다. Subgraph 내부에서는 Agent가 자신만의 루프(Loop)를 돌리고 있다.

이 Graph에는 성질이 다른 처리들이 혼재되어 있다.

• 모호한 의미 판단은 LLM에 맡긴다
• 절차나 판정 조건을 명시할 수 있는 처리는 코드로 실행한다
• Agent에는 필요한 범위만큼만 자율성을 부여한다
• 중요한 처리에는 검증이나 인간의 승인을 배치한다
• State를 사용하여 중단, 재개, 재시도를 관리한다

되돌아가는 지점도 하나가 아니다. 검증에서 탈락했을 때는 초안 단계로, 리뷰에서 방침이 문제라고 판단되었을 때는 계획 단계로 되돌리는 것처럼, 실패의 종류에 따라 재시도의 입도(Granularity)를 바꿀 수 있다.

Graph Engineering의 가치는 Agent를 늘리는 것보다, 어디에 어느 정도의 자율성을 배치할 것인가를 시스템 전체 관점에서 생각할 수 있다는 데 있다.

다음은 Graph를 채택한다고 해서 자동으로 실현되는 효과는 아니다.

Graph와 실행 기반을 적절히 설계했을 때, 접근하기 쉬워지는 요소로서 정리한다.

Agent 시스템의 실패는 개별 Prompt나 모델의 능력만이 원인인 것은 아니다.

예를 들어, 다음과 같은 문제를 생각할 수 있다.

• 필요한 정보가 후속 Agent에게 전달되지 않음
• 동일한 처리가 여러 Agent에서 중복됨
• Verifier(검증자)가 필요한 위치에 존재하지 않음
• 잘못된 Agent에게 태스크가 할당됨
• 종료 조건이 부적절하여 처리가 너무 오래 지속됨
• 하나의 Agent에게 권한이나 책무가 너무 집중됨

NeurIPS 2025에서 발표된 Multi-Agent System Failure Taxonomy 연구에서는 여러 Multi-Agent 프레임워크의 실행 Trace를 분석하여, 시스템 설계, Agent 간의 불일치, 태스크 검증에 관한 실패 패턴을 분류하고 있다. (NeurIPS 2025)

이러한 실패는 개별 Prompt를 개선하는 것만으로는 해소할 수 없을 가능성이 있다.

Graph로서 관계를 표현하면 문제를 Node 단독이 아니라 다음과 같은 구조로부터 분석할 수 있다.

• 정보의 경로
• 역할 분담
• 검증을 배치하는 위치
• 권한의 경계
• 재시도 경로
• 종료 조건

Agent 시스템의 모든 것을 LLM에 맡길 필요는 없다.

예를 들어, 다음 처리들은 일반적으로 LLM에게 판단을 맡기기보다 코드로 구현하는 것이 더 적합하다.

• Schema 검증
• 수치 계산
• 파일 존재 확인
• 테스트 실행
• 권한 체크
• 집계
• 조건 판정

이들은 처리 절차나 합격 조건을 명시하기 쉽다.

코드로 구현함으로써 LLM에게 실행하게 하는 경우보다 일반적으로 다음과 같은 특성을 얻기 쉽다.

• 저비용
• 고속
• 재현 용이
• 테스트 용이
• 실패 원인 추적 용이
• 입출력 조건 명시 용이

단, 코드로 구현한다고 해서 항상 옳은 것은 아니다.

구현상의 결함, 외부 상태에 대한 의존, 사양(Specification)의 오류는 발생한다. 여기서의 논점은 정확성의 보장이 아니라, 처리 절차와 판정 조건을 명시하고 검증 가능한 형태로 구현할 수 있는가이다.

LangChain 역시 Graph를 이용하는 가치 중 하나로, 모델에 의한 추론이 필요한 부분과 코드로 처리하는 부분을 조합할 수 있다는 점을 꼽고 있다. (langchain.com)

Graph로 설계함으로써 어디에서 Agent를 사용하지 않을 것인가도 명시적으로 생각하기 쉬워진다.

Node마다 다음과 같은 경계를 정의할 수 있다.

• 무엇을 입력으로 받는가
• 무엇을 변경할 수 있는가
• 어떤 정보를 공유하는가
• 어떤 정보를 격리하는가
• 무엇을 출력으로 남기는가
• 어떤 Node가 공식적인 상태(State)를 소유하는가

State의 공유 방법은 하나가 아니다.

• 공유 객체 (Shared Object)
• 파일
• 데이터베이스
• 결과물에 대한 참조
• 검색 가능한 외부 메모리

중요한 것은 모든 것을 무조건적으로 공유하는 것이 아니다.

어떤 정보를, 어떤 Node에게, 어떤 입도로 전달할 것인가를 설계하는 것이 중요해진다.

Graph에는 Agent 이외의 처리도 포함될 수 있다.

• 자동 테스트 (Automated Test)
• 스키마 (Schema) 검증
• 룰 기반 게이트 (Rule-based Gate)
• 독립 리뷰어 (Independent Reviewer)
• 인간 승인 (Human Approval)
• 예산이나 실행 횟수의 상한

이러한 요소들을 개별적인 주의사항으로서 프롬프트 (Prompt)에 작성할 뿐만 아니라, 실행 경로를 제약하는 메커니즘으로서 배치할 수 있다.

특히, 생성하는 에이전트 (Agent)와는 별도로 검증하는 프로세스를 둠으로써, 작성자 자신만을 최종 평가자로 만들지 않는 구성을 만들 수 있다.

Graph Engineering의 특징적인 관점은, 개별 에이전트 (Agent)나 프롬프트 (Prompt)뿐만 아니라, 워크플로 (Workflow) 구조 그 자체를 개선 대상으로 삼는 것이다.

예를 들어, 다음과 같은 변경 사항을 비교할 수 있다.

• 검증기 (Verifier)를 추가한다
• 불필요한 에이전트 (Agent) 간 통신을 줄인다
• 에이전트 (Agent)의 실행 순서를 변경한다
• 일부 LLM 노드 (Node)를 코드 처리로 대체한다
• 태스크 (Task)에 따라 사용하는 서브그래프 (Subgraph)를 변경한다
• 가치가 낮은 에이전트 (Agent)를 실행 시점에 제외한다

2026년 서베이 (Survey)에서는 워크플로 (Workflow)를 다음 세 가지로 나누어 품질, 비용, 견고성, 구조 변화를 평가하는 프레임워크를 제시하고 있다. (arXiv)

• 재사용 가능한 템플릿 (Template)
• 실행 시마다 구체화되는 그래프 (Graph)
• 실제 실행 트레이스 (Trace)

즉, 그래프 (Graph)는 단순한 구현 형식이 아니라, 측정하고 개선할 수 있는 결과물이 될 수 있다.

Graph Engineering을 평가할 때는 양방향의 오해를 피할 필요가 있다.

그래프 (Graph)는 실행 구조이며, 개별 에이전트 (Agent)의 능력을 자동으로 높여주는 것이 아니다.

부적절한 에이전트 (Agent), 모호한 책임, 약한 검증을 연결하면 실패가 복잡해질 뿐일지도 모른다.

LangChain은 범용적인 딥 리서치 (Deep Research)와 같이, 사전에 처리 경로를 결정하기 어려운 태스크 (Task)의 예로, GPT Researcher가 정의된 그래프 (Defined Graph)에서 계획, 위임, 컨텍스트 (Context) 관리를 에이전트 (Agent)에게 맡기는 구성으로 이행한 사례를 소개하고 있다. (langchain.com)

그래프 (Graph)는 실행 경로를 규정하여 제어권을 얻는 경우도 있고, 동적인 라우팅 (Routing)을 통해 유연성을 남겨두는 경우도 있다.

어느 쪽이 적절한지는 태스크 (Task)에 따라 다르다.

다중 에이전트 (Multi-Agent)는 전문화, 병렬화, 독립 평가 등의 가치를 가질 수 있다.

반면, 멀티 에이전트 시스템 (Multi-Agent System)의 성능 향상이 미미한 케이스나 다음과 같은 실패도 보고되고 있다. (NeurIPS 2025)

• 에이전트 (Agent) 간의 정보 결손
• 역할에서의 이탈
• 중복 실행
• 조정 비용의 증대
• 검증 부족

Anthropic이 자사의 멀티 에이전트 리서치 (Multi-Agent Research) 시스템에 대해 공개한 구현 보고에 따르면, 병렬 조사나 단일 컨텍스트 윈도우 (Context Window)를 초과하는 정보량을 다룰 수 있는 이점을 얻은 반면, 해당 회사의 측정 조건에서는 일반적인 채팅의 약 15배에 달하는 토큰 (Token)을 사용했다고 밝혔다.

또한, 모든 에이전트 (Agent)가 동일한 컨텍스트 (Context)를 필요로 하는 태스크 (Task)나, 에이전트 (Agent) 간의 의존 관계가 많은 태스크 (Task)에는 적합하지 않다고도 설명하고 있다. (Anthropic)

다만, 이는 특정 리서치 (Research) 시스템에서의 결과이며, Graph Engineering 전반의 비용을 나타내는 것은 아니다.

소비량은 주로 다음과 같은 설계에 따라 달라진다.

• LLM을 사용하는 노드 (Node)의 수
• 각 노드 (Node)로 전달하는 컨텍스트 (Context) 양
• 재시도 횟수
• 에이전트 (Agent) 간의 통신량
• 평가 및 통합 처리의 수
• LLM을 사용하지 않고 코드로 처리하는 범위

노드 (Node) 간에 컨텍스트 (Context)를 공유할 수 없는 것은 아니다.

공유 상태 (Shared State)나 외부 결과물을 사용하면 필요한 정보를 인계할 수 있다.

반면, 모든 노드 (Node)에 대량의 정보를 전달하면 입력이 늘어나고, 너무 과하게 요약하면 필요한 배경 정보가 손실될 가능성이 있다.

이는 그래프 (Graph) 고유의 결함이라기보다, 여러 실행 단위를 가진 시스템 전반의 컨텍스트 (Context) 설계 문제이다.

Anthropic 또한 큰 결과물을 파일 등으로 저장하고, 에이전트 (Agent) 간에는 경량화된 참조를 전달함으로써 정보 손실과 토큰 (Token) 전송을 억제하는 방법을 소개하고 있다. (Anthropic)

그래프 (Graph), 상태 (State), 워크플로 (Workflow), 멀티 에이전트 (Multi-Agent)와 같은 개별 기술은 이전부터 존재해 왔다.

그런 의미에서 Graph Engineering을 완전히 새로운 기술 분야로 간주하기는 어렵다.

다만, 현재의 논의에서는 다음 사항들이 하나의 관점으로 정리되어 있다.

• 에이전트 (Agent) 전체를 노드 (Node)로 취급한다
• 에이전트 (Agent) 간의 관계를 계약 (Contract)으로서 설계한다
• 고정 구조와 동적 구조를 혼재시킨다
• 실행 트레이스 (Execution Trace)로부터 구조를 평가한다
• 그래프 (Graph) 자체를 생성, 선택, 최적화한다

특히 워크플로 (Workflow) 구조 그 자체를 품질과 비용의 최적화 대상으로 다루는 연구가 늘어나고 있다. (arXiv)

따라서 Graph Engineering을 "기존 기술의 이름만 바꾼 것"이라며 치부하는 것도 다소 좁은 시각이 될 수 있다.

Graph Engineering을 조사하면서, Agent 시스템을 설계할 때 새삼 중요하다고 느낀 생각들이 여러 가지 있었다.

이것들은 모두 완전히 새로운 것이 아니라, 소프트웨어 설계 (Software Design), 워크플로 (Workflow), 분산 시스템 (Distributed Systems), Agent Engineering 등에서 다뤄져 온 개념들이다.

다만, 출력이나 실행 경로가 변동될 수 있는 Agent와, 여러 처리 과정을 연결하는 시스템으로서 다시 정의함으로써 그 중요성이 더욱 구체적으로 보이기 시작했다.

각 Agent에 대해 무엇을 담당할지뿐만 아니라, 무엇을 담당하지 않을지도 정의한다.

responsibility:
- 인증·인가 문제를 확인한다
- 근거가 되는 코드 위치를 나타낸다
...

Agent를 분리한다면 역할뿐만 아니라 Context, 도구 (Tool), 변경 권한, 판단 권한의 경계에도 의미가 필요하다.

Agent가 참조하는 정보를 무제한으로 두지 않는다.

inputs:
required:
- target-diff
...

입력 범위를 정함으로써 불필요한 탐색을 줄이고, 무엇을 근거로 판단했는지도 추적하기 쉬워진다.

후속 처리가 이용하는 출력에는 필요한 항목을 정의한다.

{
"decision": "needs_revision",
"findings": [
...

반드시 JSON일 필요는 없다.

사람이 읽는 결과물이라면 필수 헤더를 가진 Markdown 템플릿이어도 좋다.

중요한 것은 후속 Agent나 코드 처리가 출력의 의미를 매번 추측할 필요가 없게 만드는 것이다.

목적, 진척, 판단, 근거, 미결 사항을 대화 이력 (Conversation History)에만 의존하게 하지 않는다.

goal: 변경 내용의 안전성을 확인한다
status: in_progress
completed:
...

그 바탕 위에서 다음 사항들을 정한다.

• 어떤 정보가 공식적인 상태 (State)인가
• 어떤 노드 (Node)가 업데이트할 수 있는가
• 변경 이력을 어디에 남길 것인가
• 여러 노드의 변경을 어떻게 통합할 것인가

Agent에는 시작 조건뿐만 아니라 종료 조건도 필요하다.

• 무엇이 갖춰지면 완료인가
• 몇 회까지 재시도할 것인가
• 진전이 없을 경우 어떻게 정지할 것인가
• 어떤 조건에서 인간에게 판단을 넘길 것인가
• 어떤 실패를 허용하지 않을 것인가

Agent의 자율성을 높이는 것과 무제한적인 탐색이나 반복을 허용하는 것은 별개다.

의미 이해, 가설 생성, 여러 타당한 해석이 존재할 수 있는 평가는 LLM의 능력을 활용하기 쉽다.

반면, 타입 검증 (Type Verification), 계산, 테스트, 집계, 존재 확인, 권한 판정 등 처리 절차나 판정 조건을 명시할 수 있는 것은 원칙적으로 코드로 처리하는 것이 적합하다.

의미 이해·가설 생성·모호한 평가
→ LLM에 의한 판단
타입 검증·계산·테스트·조건 판정
...

노드를 늘릴 때 모든 것을 LLM 노드로 만들어 버리면 비용과 불확실성도 쌓이게 된다.

판단 기준은 단순히 "알고리즘으로 다룰 수 있는가"가 아니다.

기존의 방법으로 필요한 품질의 결과를 필요한 시간과 비용으로 얻을 수 있는가

를 고민해야 한다.

코드로 실용적인 처리가 가능하다면 계산 그 자체를 LLM에 맡길 필요성은 낮다.

반면, 처리 절차를 사전에 고정하기 어렵거나 의미 이해, 탐색, 가설 생성이 필요한 경우에는 LLM을 이용할 가치가 생긴다.

Agent를 나누는 것 자체에 가치가 있는 것은 아니다.

다음과 같은 이유가 있을 때 분리를 검토한다.

• 서로 다른 전문성이 필요함
• 서로 다른 Context를 부여하고 싶음
• 서로 다른 도구나 권한을 주고 싶음
• 독립적인 평가에 의미가 있음
• 병렬화를 통한 효과를 기대할 수 있음
• 실패나 영향 범위를 국소화하고 싶음

이유를 설명할 수 없다면 단일 Agent의 루프 (Loop)나 Agent를 사용하지 않는 코드 처리가 더 단순할 가능성이 높다.

개별 Agent의 출력뿐만 아니라 다음과 같은 지표도 살펴볼 필요가 있다.

• 어떤 경로를 거쳤는가
• 몇 번 재시도했는가
• 어디서 실패했는가
• Agent 간에 무엇을 주고받았는가
• 어떤 노드가 비용을 사용했는가
• 검증기 (Verifier)가 무엇을 거부했는가
• Graph 변경에 의해 품질과 비용이 어떻게 변했는가

Graph Engineering에서 특히 재인식한 것은, Agent 시스템에서는

국소적으로 우수한 Agent를 나열하는 것

과

전체적으로 우수한 시스템을 만드는 것

은 같지 않다는 점이다.

모든 Agent 시스템을 Graph화할 필요는 없다.

한편, Graph Engineering을 단순한 유행어로 무시하기에는 이르다고 생각한다.

다음 조건 중 여러 개가 해당되는 경우에는 작은 Graph(그래프)부터 검증할 가치가 있다.

• 여러 책임(Responsibility)이나 권한 경계가 있는 경우
• 독립적인 검증이나 반증이 중요한 경우
• 병렬로 처리할 수 있는 작업이 있는 경우
• 장시간 처리의 중단 및 재개가 필요한 경우
• 실행 경로(Execution Path)나 판단 이력을 추적하고 싶은 경우
• 동일한 구조를 반복해서 사용하는 경우
• 실패 원인이 Agent(에이전트) 단독이 아니라 구조에 있다고 판단되는 경우
• 고가치 태스크(Task)로서 추가 비용을 정당화할 수 있는 경우
• Workflow(워크플로우) 구조를 평가 및 최적화하고 싶은 경우

처음부터 대규모 Multi-Agent System(멀티 에이전트 시스템)을 만들 필요는 없다.

예를 들어, 다음과 같은 정도의 규모에서도 Graph적인 설계를 검증할 수 있다.

[IMG:1]

이 작은 구성에서도 다음과 같은 논점들이 나타난다.

• Node(노드)의 책임
• 입출력 계약 (Input/Output Contract)
• State(상태) 관리
• 검증 기준
• 재시도 횟수
• 인간에게 되돌리는 조건
• 품질과 비용의 측정

실제 운영 환경(Production) 도입은 구체적인 과제와 비용 대비 효과(ROI)를 바탕으로 판단해야 한다.

다만, 기술 검증을 위해 문제가 발생할 때까지 기다릴 필요는 없다.

Graph Engineering(그래프 엔지니어링)이라는 명칭은 새로우며, 이번에 확인한 자료의 범위 내에서는 지칭하는 대상도 아직 확정되지 않았다.

반면, 그 배경이 되는 다음 분야에는 이미 일정 수준의 연구와 구현 축적이 이루어져 있다.

• Agent Loop (에이전트 루프)
• Multi-Agent 협업
• Stateful Workflow (상태 유지 워크플로우)
• Graph형 Runtime (그래프형 런타임)
• Workflow Optimization (워크플로우 최적화)

따라서 Graph Engineering을,

"Loop Engineering (루프 엔지니어링) 다음에 오는 만능 자율화 기법"

이라고 파악하는 것은 적절하지 않아 보인다.

Loop와 Graph는 단순한 성숙 단계의 차이가 아니라, 다루는 문제의 범위가 다르다.

• Loop는 하나의 실행 주체가 시간 축상에서 어떻게 반복하는지를 다룬다.
• Graph는 여러 처리나 실행 주체가 어떻게 관계를 맺는지를 다룬다.
• 실제 Agent 시스템에서는 Graph의 Node 내부에서 Loop가 동작한다.

한편, Graph Engineering을 기존 Workflow의 단순한 다른 이름으로 취급하는 것도 불충분하다.

현재 Graph Engineering에 관한 논의에서는, Agent를 포함한 Workflow 구조 그 자체를 설계, 관측, 평가, 생성, 최적화의 대상으로 다루는 관점이 강화되고 있다.

Graph를 채택한다고 해서 Agent 시스템이 자동으로 똑똑해지거나, 안전해지거나, 저렴해지는 것은 아니다.

그럼에도 불구하고, Agent 단독뿐만 아니라 Agent 간의 관계, State(상태), 권한, 검증, 비용까지 포함하여 시스템을 설계하는 관점은 충분히 도전할 가치가 있다.

Graph를 만드는 것 자체를 목적으로 삼지 말고, Agent 시스템의 구조를 어디까지 명시·측정·개선할 필요가 있는지를 고민해야 한다.

Graph Engineering으로부터 얻은 가장 중요한 시사점은 바로 이 질문 그 자체라고 느낀다.

정보원에 따라 검증 방식이 다르므로, 종류를 병기한다.