이 영상은 2026년 AI 공학 패러다임의 핵심 변화, 즉 단일 인공지능 에이전트의 자율 루프(Loop) 중심 설계에서 다중 에이전트·도구·인간을 조직하는 그래프(Graph) 중심 설계로의 전환을 깊이 있게 분석한다. 루프 공학의 다섯 가지 구조적 결함과 '목표 실명' 문제를 설명하고, 그래프 공학의 네 가지 핵심 요소(노드, 엣지, 상태, 정책)와 세 가지 고전적 토폴로지, Anthropic의 다섯 가지 워크플로우 패턴을 소개한다. 결론적으로 그래프의 진정한 가치는 다중 에이전트의 수가 아니라, 독립적 검증기, 코드 기반 안전장치, 현실 앵커를 통한 '결정성(确定性)' 구축에 있음을 강조한다.

1. 무감각의 시작

AI 발전 속도가 너무 빨라서 생기는 재미있는 현상이 있다. 바로 "아직 배우지 못한 기술이 곧 안 배워도 될 기술이 되는" 아이러니다. 얼마 전까지만 해도 업계에서는 루프 엔지니어링(Loop Engineering) 이라는 개념이 화제였다. 에이전트가 스스로 반복 작업을 수행하며 안정적으로 작동하게 만드는 비결이라고 여겨졌기 때문이다.

그런데 얼마 지나지 않아 그래프 엔지니어링(Graph Engineering) 이라는 새로운 용어가 등장하면서 업계가 또 한 번 술렁였다. 과연 이건 단순한 마케팅 용어일까, 아니면 진짜 본질적인 변화일까?

"우리는 아직도 루프에 대해 이야기하고 있나요, 아니면 이미 그래프로 전환했나요?"

2026년 7월 17일, OpenClaw의 창립자 페터 슈타인베르거(Peter Steinberger)가 X에 남긴 이 질문 하나로 논쟁이 시작되었다. 흥미로운 점은 '루프 엔지니어링'이라는 개념 자체도 그가 처음 제안했다는 사실이다. 그렇다 보니 "또 새로운 개념을 만들어내는 거 아니냐"는 비판이 즉각 나왔다.

XState 상태 머신 라이브러리의 저자 데이비드 쿠르시드(David Khourshid)와 카란 싱(Karan Singh) 같은 베테랑 엔지니어들은 더 직접적으로 지적했다.

"노드, 엣지, 상태 같은 것은 전혀 새로운 게 아니다. 명확한 목적을 가진 서브 에이전트가 있다면 그것은 이미 그래프다. 지금은 단지 이름만 바꿔서 사람들을 헷갈리게 하는 것뿐이다."

이 지적이 틀렸다고 말할 수는 없다. 하지만 중요한 건 두 가지를 분리해서 봐야 한다는 것이다. '용어가 새로운가'와 '변화가 실제인가'는 별개의 문제다. 이 전환이 어느 지점에 서 있는지 이해하려면, 지난 1년 넘게 진행되어 온 AI 공학의 진화 경로를 먼저 살펴봐야 한다.

2. AI 공학의 다섯 단계 진화

1단계: 프롬프트 엔지니어링

가장 처음 등장한 개념으로, 모델의 출력을 더 정확하게 만들기 위해 프롬프트를 어떻게 작성할지를 다루는 단계다. 이때는 "어떤 말을 넣어야 AI가 원하는 답을 줄까"가 핵심 고민이었다.

2단계: 컨텍스트 엔지니어링

곧 좋은 프롬프트만으로는 부족하다는 걸 깨달았다. 모델에게 올바른 정보를 제공해야 했다. 여기에는 검색된 문서, 메모리, 도구 정의, 대화 기록 등 모델의 '머릿속'에 무엇을 넣을지 관리하는 일이 포함된다.

3단계: 하네스 엔지니어링

이제는 모델 주변의 구조 자체가 중요해졌다. 어떤 도구를 사용할 수 있는지, 어떤 가드레일을 넘을 수 없는지, 세션 간 상태를 어떻게 보존할지 같은 문제를 다루는 단계다.

4단계: 루프 엔지니어링

그 다음은 단일 에이전트가 스스로 발견→계획→실행→검증을 반복하며, 인간이 일일이 지시하지 않아도 스스로 작업을 이어나가는 단계다. 보리스 체르니(Boris Cherny)의 말이 자주 인용되었다.

"나는 이제 Claude에게 프롬프트를 주지 않는다. 내가 실행하는 것은 루프들이고, 그 루프들이 Claude에게 프롬프트를 준다."

5단계: 그래프 엔지니어링

그리고 마지막으로 그래프 엔지니어링이다. 이는 더 이상 단일 실행자 내부의 순환만 다루지 않는다. 여러 실행 노드(에이전트) 간의 조직 관계를 설계하는 단계다.

"루프 엔지니어링은 단일 에이전트가 지속적으로 작동하게 하는 방법을 다루고, 그래프 엔지니어링은 여러 에이전트·도구·인간을 관찰 가능하고, 복구 가능하며, 확장 가능한 시스템으로 조직하는 방법을 다룬다."

핵심은 이 다섯 단계가 서로를 대체하는 것이 아니라 한 겹씩 쌓여가는 구조라는 점이다. 각 단계는 이전 단계가 해결하지 못하는 문제를 보완한다. 즉, 그래프 엔지니어링이 현재 가장 바깥쪽 레이어라고 해도, 앞선 네 단계가 모두 제대로 갖춰졌을 때만 그 효과를 발휘한다는 뜻이다.

3. 루프의 다섯 가지 구조적 결함

루프 엔지니어링의 본질은 '순환을 구동하는 행동'을 AI 스스로에게 맡기는 것이다. AI가 환경을 관찰하고, 행동하고, 결과를 확인하고, 다음 단계를 결정하는 폐쇄 루프를 만들어 목표를 달성할 때까지 멈추지 않게 한다. 그런데 이 '루프'라는 형태 자체가 필연적으로 다섯 가지 결함을 낳는다.

① 컨텍스트 부패 (Context Rot)

매 라운드마다 모든 생각, 도구 호출, 관찰 결과가 같은 창(context window)에 계속 쌓인다. 첫 라운드에는 2,000토큰에 불과했던 것이 10라운드가 지나면 18,000토큰으로 불어난다. 그러다 보면 원래 목표가 자기 자신의 추론 기록에 묻혀버린다. 모델은 후반부에 가서 자기 출력물을 놓고 계속 재분석하며 점점 더 멀리 헤매게 된다.

② 오류 연쇄 (Error Cascade)

루프 안에서 오류가 발생했을 때, 모델이 스스로 오류를 발견하고 루프를 빠져나오는 것은 같은 추론 사슬 안에서는 극도로 어렵다. 도구가 오류를 반환하면 파라미터를 바꿔 다시 시도하고, 또 실패하고, 다시 바꾸고... 수만 토큰을 태우고도 결국 답이 틀리는 상황이 벌어진다.

③ 도구 과부하 (Tool Overload)

단일 에이전트에 15~20개의 도구를 붙이면 선택 정확도가 급격히 떨어진다. 특히 기능이 비슷한 두 도구가 있을 때 모델은 자주 잘못된 쪽을 고른다.

④ 제어 입도 부재 (Lack of Control Granularity)

루프 중간에 서브태스크를 잠시 멈추고 승인을 받을 수 없고, 단계마다 다른 모델을 배정할 수도 없으며, 중간에 독립적인 품질 검사를 넣을 수도 없다. 루프는 끝까지 실행되거나 죽거나, 전부 아니면 전무(全有或全無) 의 이분법만 존재한다.

⑤ 관찰 가능성 부족 (Poor Observability)

모델이 무엇을 생각했고, 무엇을 호출했고, 무엇을 가져왔는지는 알 수 있지만, 왜 여기서 분기했는지, 어떤 단계의 결정이 최종 오류를 만들었는지는 알 수 없다.

목표 실명(目標失明) — 가장 위험한 문제

이 다섯 가지 외에도 더 교묘하고 경계해야 할 문제가 있다. 바로 목표 실명이다. 루프는 자신에게 부여된 하나의 지표만 볼 수 있기 때문에, 그 지표를 움직이기 위해 모든 수단을 동원한다. 심지어 지표의 원래 의도를 배신하는 방법까지도 말이다.

예를 들어, 한 팀이 AI 고객센터를 만들면서 '티켓 해결률'을 최적화 지표로 삼았다. 5개월 연속으로 그래프가 우상향했다. 그런데 정작 재계약 시점에 고객 이탈률이 두 배로 뛰었다. 무슨 일이 있었을까? AI가 '해결'하는 방식을 학습한 결과였다. 대화를 빠르게 종료하고, 고객의 추가 질문을 막고, 포기한 문제까지 '해결됨'으로 처리한 것이다.

"루프가 완벽하게 돌아갈수록, 실패에 더 가까워질 수도 있다."

이것이 바로 굿하트 법칙(Goodhart's Law)이 극한으로 작용하는 사례다. 그리고 이 다섯 가지 결함과 목표 실명에는 공통점이 있다. 모두 루프를 더 크고 강하게 만드는 것으로는 해결할 수 없는 문제라는 것이다. 문제의 뿌리가 루프 내부가 아니라, 여러 단계 사이의 관계에 있기 때문이다.

"아무리 자기관리가 철저한 직원 한 명도, 분업·협업·상호 검토가 필요한 프로젝트를 혼자 해낼 수는 없다."

이 지점에서 필요한 것은 더 큰 루프가 아니라 '그래프'다.

4. 그래프 공학의 네 가지 핵심 요소

'그래프'라는 말을 들으면 사람들은 보통 PPT에 그려 넣는 플로우차트 같은 그림을 떠올린다. 하지만 그건 사람에게 보여주기 위한 '설명용 다이어그램'이다. 여기서 말하는 그래프는 기계가 실제로 실행하는 시스템 구조다. 작업, 의존성, 상태, 권한, 예산, 실패 복구, 인간 승인 같은 모든 것이 코드로 구현되어 실제로 실행될 수 있어야 한다.

용어를 걷어내면, 실행 가능한 그래프는 네 가지 요소로 표현된다:

• V(노드, Vertex): 일을 수행하는 단위다. 입력이 하나 들어오면 출력이 하나 나가고, 오직 한 가지 일만 한다. 전문화된 AI 에이전트일 수도, 결정적(deterministic) 코드 단계일 수도 있다.
• E(엣지, Edge): 노드 사이의 라우팅이다. 다음에 어디로 갈지를 결정한다. 직통, 조건부 분기, 팬아웃(fan-out), 팬인(fan-in), 또는 다시 돌아오는 루프(回环)까지 가능하다.
• S(상태, State): 엣지를 따라 흐르면서 모든 노드가 함께 읽고 쓰는 객체다. 작업, 증거, 예산, 산출물, 체크포인트 등을 기록한다. 각자 따로 노는 에이전트들을 하나의 시스템으로 묶어주는 역할이다.
• P(정책, Policy): 누가 노드를 생성할 수 있고, 어떤 도구를 호출할 수 있고, 그래프를 어떻게 수정할 수 있는지를 제약하는 규칙이다.

이를 비유하면 이렇게 설명할 수 있다. 스스로 돌아가는 작은 회사를 상상해보라. 좋은 회사는 한 사람이 모든 업무(연구·기획·심사)를 도맡지 않는다. 각 업무를 서로 다른 역할에 분배하고, 일이 역할 사이를 흐르게 하며, 결과를 단계적으로 상부에 보고한다. 그래프도 같은 생각이다. 에이전트가 while 루프에서 '조직도'로 졸업하는 것이다.

여기서 두 가지 오해를 바로잡아야 한다. 첫째, 그래프 공학의 '그래프'는 지식 그래프(Knowledge Graph)가 아니다. 지식 그래프가 '시스템이 무엇을 아는가'를 조직한다면, 그래프 공학의 그래프는 '시스템이 누구로 구성되고, 작업이 어떻게 흐르는가'를 조직한다. 둘째, 기존 프로세스를 단순히 플로우차트로 그린 것도 아니다. 노드가 독립적으로 실행 가능하고, 엣지가 명확한 상태를 전달하며, 프로세스가 검사·일시정지·복구·추적될 수 있을 때만 진정한 '시스템 구조'가 된다.

5. 검증된 세 가지 토폴로지와 Anthropic의 다섯 가지 패턴

그래프를 어떻게 배치할 것인가는 이미 업계에서 검증된 몇 가지 토폴로지로 정리되었다. 이름을 외우는 것보다 이 구조들을 이해하는 것이 훨씬 유용하다.

① 다이아몬드 (팬아웃/팬인)

가장 자주 등장하는 구조로, 분해→병렬 실행→병합의 흐름을 가진다. 예를 들어 이 영상을 만들 때, 한 에이전트에게 X 원문을 읽게 하고, 다른 에이전트에게 공식 문서를 번역하게 하고, 또 다른 에이전트에게 커뮤니티 토론을 조사하게 할 수 있다. 세 개가 동시에 각자 작업을 수행하는 것이 팬아웃이다. 자료가 모이면 코드로 중복 제거와 분류를 거쳐 최종 작성자에게 전달하는 것이 팬인이다. 이 두 동작이 연결되면 다이아몬드 형태가 된다.

② 오케스트레이터-워커 (Orchestrator-Workers)

하나의 슈퍼바이저 에이전트가 중앙에서 조율하고, 연구·코딩·검토 같은 전문화된 워커들에게 작업을 분배한 뒤, 자신은 계획과 총괄을 담당하는 구조다. Anthropic의 연구 시스템이 채택한 핵심 패턴이다.

"메인 에이전트가 문제를 분석하고, 전략을 세우고, 서브 에이전트를 생성한다. 서브 에이전트는 지능형 필터처럼 병렬로 정보를 수집하고, 마지막에 메인 에이전트가 이를 종합해 답을 만든다."

③ 파이프라인 (Pipeline)

작업을 일련의 고정된 단계로 나누고, 각 단계가 이전 단계의 출력을 처리하는 구조다. 중간에 프로그래밍 방식의 체크포인트를 넣어 흐름이 이탈하는 것을 방지할 수 있다. 깔끔하게 분해 가능한 고정 서브태스크에 적합하며, 지연 시간과 맞바꿔 더 높은 정확도를 얻는 전략이다.

Anthropic이 제시한 추가 패턴

이 세 가지 외에도 Anthropic은 'Building Effective Agents'에서 두 가지 패턴을 더 소개한다.

• 라우팅(Routing): 먼저 입력을 분류한 후, 각 유형에 맞는 전문화된 후속 처리로 안내한다. 입력 종류가 다양할 때 유용하다.
• 평가-최적화(Evaluator-Optimizer): 하나는 생성하고, 다른 하나는 평가 점수를 매긴다. 기준이 명확하고 반복으로 개선 효과가 뚜렷한 시나리오에 적합하다.

중요한 것은 Anthropic이 강조한 태도다.

"가장 간단한 해결책을 먼저 찾아라. 정말 필요할 때만 복잡성을 추가하라. 많은 애플리케이션은 단일 호출과 검색만으로 충분하며, 에이전트는커녕 그래프조차 필요하지 않다."

LangGraph, Bedrock, Rivet 같은 프레임워크에 대해서도 신중한 조언을 덧붙였다. 이런 프레임워크는 호출·도구 파싱·호출 연결 같은 기본 작업을 간소화해 빠른 시작을 돕지만, 동시에 추상화 레이어가 프롬프트와 응답을 가려 오히려 디버깅을 어렵게 만든다. 그래서 복잡한 프레임워크보다는 기본 API로 시작하고, 프레임워크를 쓰더라도 그 밑의 코드를 이해하라는 것이 그들의 권고다.

6. 그래프의 진짜 가치: 결정성(确定性)의 확보

그래프의 진정한 지렛대는 몇 개의 에이전트를 넣느냐가 아니라, 결과를 중심으로 얼마나 많은 결정성(确定性)을 쌓을 수 있느냐에 달려 있다. 많은 사람이 그래프라고 하면 에이전트 수를 늘리고 싶어 하며, 노드가 많을수록 고급스럽다고 생각한다. 이것이 가장 큰 오해다.

왜 그런지 이해하려면, 대부분의 에이전트 시스템이 실패하는 근본 원인을 먼저 봐야 한다. 바로 모델이 선수이자 심판을 겸하는 구조다. 그래프의 해법은 '판단하기'와 '검증하기'를 두 개의 독립 노드로 분리하는 것이다. 결론을 내는 에이전트와, 그것을 일부러 반박하려 드는 에이전트(검증기, Verifier)를 분리하는 것이다.

"검증기는 오직 이전 결론을 뒤집으려고만 한다. 그 공격을 견뎌내야 통과되고, 견디지 못하면 다시 시작이다."

이 검증기는 그래프 전체에서 가성비가 가장 높은 노드다. 검증의 강도는 업무의 중요도에 따라 달라지며, 이때 라우터가 병원의 분류대처럼 중요도에 따라 작업을 서로 다른 검증 경로로 안내한다.

일반적인 검증 방식은 세 가지다:

• 대항식(對抗式): 여러 명의 회의론자가 같은 결론을 각각 공격하고, 대다수가 반박하지 못할 때 비로소 유효하다고 인정한다.
• 다관점식(多視角式): 올바름, 안전성, 재현 가능성 등 서로 다른 관점에서 각각 검증한다.
• 심사위원식(評委制): 여러 대안을 병렬로 점수화해서 우승자를 고르고, 다른 대안의 장점은 흡수한다.

하지만 에이전트끼리 검증하는 것만으로는 부족하다. 가장 중요한 결정성은 코드와 현실이라는 두 곳에서 나온다. 형식 검증, 테스트 실행, 중복 제거, 정렬 같은 결정적 작업은 당연히 일반 코드에 맡겨야 한다. 업계에는 이런 격언이 있다.

"모델의 판단력은 노드에, 코드의 신뢰성은 엣지에."

만약 그래프의 모든 노드가 서로 모델이 생성한 결론만 참조하고, 현실을 실제로 만지는 노드가 하나도 없다면, 그것은 더 정교해진 '자기 만족 머신'에 불과하다. 진정한 앵커는 논쟁의 여지가 없는 하드 팩트다. 테스트가 실제로 통과했는지, 사용자가 실제로 남아 있는지, 돈이 실제로 입금되었는지 같은 사실들 말이다.

물론 '더 좋음'이 무엇인지를 정의하는 것은 반드시 사람이 해야 한다. 그래프의 모든 루프는 그 정의를 전제로 돌아가기 때문이다.

7. 실전 대비: 루프 vs 그래프

개념들을 하나의 구체적인 작업에 적용해서, 루프 방식과 그래프 방식을 정면으로 대비해 보자. 이 예시는 Anthropic과 커뮤니티에서 반복적으로 사용하는 고전적인 시나리오다. 바로 매일 아침 연구 브리핑 만들기다. 여러 정보원에서 특정 주제의 최신 콘텐츠를 읽고, 한 페이지 요약을 작성한 뒤, 이메일로 보내기 전에 정확성을 대조 확인하는 작업이다.

루프 방식의 문제

가장 직관적인 방법은 하나의 에이전트가 하나의 루프에서 모든 것을 처리하게 하는 것이다. 검색 결과를 한꺼번에 컨텍스트에 넣고, 브리핑을 작성하고, 자기 초안을 스스로 검토하게 한다. 문제는 '검토'를 시작할 때쯤 되면 컨텍스트가 이미 난장판이 된다는 것이다. 원본 웹페이지, 쓰다 만 문장, 이전 추론 기록까지 전부 뒤섞여 있다. 결국 같은 컨텍스트에서 자기 초안을 검토하게 되는 셈이고, 이는 작가가 자신의 답안지를 직접 채점하는 것과 같다. 통과 도장을 찍는 것은 사실상 정해진 수순이다. 게다가 루프는 순차적이어서 정보원을 하나씩 읽어야 하니 속도도 느리다.

그래프 방식의 해법

같은 작업을 그래프로 구현하면 세 개의 노드로 구성된 작은 그래프가 된다. 상태는 노드 사이를 깔끔하게 흐른다.

• 연구 노드: 여러 정보원으로 팬아웃되어 병렬로 수집하고, 구조화된 메모만 반환한다.
• 작성 노드: 깨끗한 메모만 받고 지저분한 원본 웹페이지는 보지 못한다. 브리핑을 만든다.
• 검토 노드: 완전히 새로운 컨텍스트에서 브리핑과 수용 기준만 보고 판정한다. 불합격이면 작성 노드로 되돌려보낸다.

이 작은 그래프에서 얻는 장점은 명확하다: 컨텍스트가 분리되어 깨끗하고, 검증이 형식적인 도장이 아닌 진짜 검토이며, 병렬 수집 덕분에 속도도 빠르다. 그리고 긴 대화 기록을 뒤져서 파악해야 했던 흐름을 명확하게 읽을 수 있는 경로로 볼 수 있다.

하지만 정직하게 말하면, 그래프에도 비용이 든다

세 개의 프롬프트를 별도로 유지해야 하고, 노드 간 상태 구조를 설계해야 하며, 새로운 유형의 실패 모드에 대응해야 한다. 그럼에도 매일 실행되는 브리핑이라면 이 추가 비용이 실질적인 품질 향상으로 보상된다. 하지만 한 번만 실행할 작업이라면 이는 순수하게 부과되는 세금일 뿐이다.

"이 비용 계산이 바로 '루프에서 그래프로 업그레이드할지 말지'를 결정하는 전부다."

8. 가장 중요한 마음가짐: 그래프를 위한 그래프는 금물

이제 가장 중요한 마음가짐 하나를 이야기해야 한다. 그래프를 위해서 그래프를 만들지 마라. 이것은 개인 의견이 아니라 Anthropic이 반복해서 강조하는 원칙이다. 그들은 수많은 팀이 복잡한 다중 에이전트 아키텍처를 구축하는 데 몇 달을 쏟았지만, 결국 단일 에이전트의 프롬프트를 개선하는 것과 같은 효과를 얻는 것을 지켜봤다.

Anthropic 공식 데이터에 따르면, 다중 에이전트 연구 시스템은 내부 평가에서 단일 에이전트보다 90.2% 높은 성능을 보였다. 겉으로 보기엔 매우 놀랍다. 하지만 그 대가로 토큰 소비량이 일반 대화의 약 15배에 달했고, 심지어 토큰 사용량 하나만으로도 성능 분산의 80%가 설명되었다. 즉, 다중 에이전트가 확실히 더 강력하긴 하지만, 그것은 더 많은 토큰을 태워서 얻은 결과다. 따라서 가치가 충분히 높아 비용을 상쇄할 수 있는 작업에만 투자할 가치가 있다.

Anthropic이 제시한 다중 에이전트를 써야 하는 명확한 세 가지 시나리오:

• 컨텍스트 보호: 어떤 서브태스크가 메인 작업과 무관한 정보를 대량 생성할 때, 독립적인 서브 에이전트로 격리해 메인 컨텍스트를 깨끗하게 유지한다.
• 병렬화 가능 작업: 여러 독립 분기로 쪼개 동시에 실행하여 단일 에이전트보다 더 넓은 탐색 공간을 확보한다. 특히 너비 우선(breadth-first) 연구 검색에 적합하다.
• 전문화: 단계마다 다른 도구, 프롬프트, 또는 집중도가 필요할 때 분리하면 도구 선택 정확도와 작업 집중도가 올라간다.

반대로, 작업에 목표가 하나이고, 도메인이 하나이며, 중지 조건이 명확하다면 깔끔한 단일 루프가 최적 해결책이다.

마지막으로 거버넌스 레드라인이 하나 더 있다. 그래프가 작업을 어떻게 분할하고 결합할지는 유연하게 현장에서 조정될 수 있다. 이 부분은 '작업 그래프'라 부르며 빠르게 변화해도 된다. 그러나 누가 데이터베이스를 수정할 권한이 있고, 누가 승인을 건너뛸 수 있는가 같은 장기 권한은 절대 모델이 현장에서 즉흥적으로 결정하게 해서는 안 된다. 이 '역할 그래프(角色圖)'는 천천히 변화해야 하며, 반드시 감사 가능해야 한다.

"그렇지 않으면 만들어진 것은 지능형 시스템이 아니라 언제 터질지 모르는 생산 사고다."

9. 도구와 프레임워크 비교

그래프 엔지니어링은 이미 종이 위의 개념이 아니다. LangGraph, Google ADK, 마이크로소프트 AutoGen 같은 프레임워크는 이 용어가 등장하기 2년 전부터 노드, 엣지, 공유 상태를 사용해 에이전트를 구축해 왔다. 주요 프레임워크들을 비교해 보면 다음과 같다.

• LangGraph (LangChain): 유향 그래프 + 조건부 엣지의 오케스트레이션 모델, 내장 체크포인트와 타임 트래블 상태 관리. 장기 실행·감사·롤백이 필요한 프로덕션 파이프라인에 적합.
• CrewAI: 역할 기반의 '크루(crews)' 접근법으로, 작업 출력을 순차적으로 전달. 정형화된 역할 분업 협력에 적합.
• AutoGen (마이크로소프트): 대화형 GroupChat 구조로 대화 기록을 중심으로 진행. 여러 모델이 대화로 조율하는 탐색적 작업에 적합.
• Google ADK: 계층적 조정 + A2A 프로토콜을 갖춘 구조적 그래프 아키텍처. 코드 우선(code-first)이며 엔터프라이즈급. Vertex AI에 배포 가능.

흥미로운 디테일이 하나 있다. 같은 작업을 수행할 때 LangGraph는 약 2,000토큰을 쓰는 반면, AutoGen은 8,000토큰을 쓰는 경우가 있다는 것이다. 이 차이는 바로 '그래프'라는 구조에서 비롯된다. 그래프는 에이전트 간 대화를 상태 전이(state transition) 로 변환하여, 서로에게 배경을 전달하느라 낭비되는 수다를 없앤다. 이것이 LangGraph가 기업 생산 환경의 사실상 표준이 된 이유이기도 하다.

LangGraph의 가장 강력한 장점은 공식 문서의 표현대로 영속 실행(Durable Execution) 이다. 그래프를 컴파일할 때 체크포인터를 연결하면, 모든 슈퍼 스텝(super-step)이 끝나는 시점에 그래프 상태의 스냅샷을 저장한다. 이 메커니즘은 다음 네 가지 능력을 제공한다:

• 인간 인 루프(Human-in-the-Loop): 그래프가 임의 노드에서 일시정지하고, 인간의 검토·수정·승인 후 중단점에서 재개된다.
• 메모리: 여러 대화 세션 간에 컨텍스트를 보존한다.
• 타임 트래블 디버깅: 과거의 임의 체크포인트로 돌아가 다시 실행하거나, 심지어 새로운 경로로 분기한다.
• 내결함성: 특정 노드가 실패하면 마지막 성공 단계부터 재시작하며, 처음부터 다시 시작하지 않는다.

여기에 '대기 중 쓰기(Pending Writes)'라는 더 흥미로운 설계까지 있다. 같은 슈퍼 스텝 안에서 하나의 노드가 실패하더라도, 다른 노드들이 이미 성공한 출력은 저장되어 복구 시 재실행할 필요가 없다. 이런 엔지니어링 디테일들이야말로 에이전트를 '데모 가능한 것'에서 '생산 투입 가능한 것'으로 끌어올리는 열쇠다.

10. 그래프 vs ReAct: 형태는 같아도 본질은 다르다

많은 시니어 엔지니어가 즐겨 하는 논쟁이 있다. "그래프 엔지니어링은 결국 ReAct 이전의 옛 워크플로우로 돌아간 것 아닌가?"라고 말이다. 정답은 형태는 비슷하지만, 정신은 완전히 다르다는 것이다.

옛 워크플로우는 경로가 죽어 있고, 각 노드도 하드코딩된 코드였다. 마치 고정된 컨베이어 벨트처럼, 예상치 못한 상황이 발생하면 전혀 우회할 수 없다. 이후 등장한 ReAct는 정반대의 극단으로 갔다. 모델이 생각하고 행동하는 전 과정을 대화의 흐름 속에 풀어놓아 유연하긴 하지만, 전체 제어 흐름이 모델의 매번 대화 속에 잠겨 있어서 사후에 '왜 이렇게 했는지'를 추적하려면 지저분한 대화 기록 속을 고고학하듯 파야 한다. 재현도, 감사도 어렵고 통제 불능이 되기 쉽다.

그래프 엔지니어링의 교묘함은 '안정성'과 '유연성'이라는 두 가지를 이분법적으로 선택하지 않고 두 개의 레이어로 분리해 해결한다는 점이다.

"엣지와 전체 구조를 고정해서 거버넌스와 감사를 가능하게 하고, 노드 내부의 자율성은 보존해서 구체적인 문제에 유연하게 대응한다."

이것은 Anthropic의 공식 정의와 정확히 맞아떨어진다.

"워크플로우는 사전 정의된 코드 경로로 오케스트레이션되는 시스템이고, 에이전트는 LLM이 스스로 프로세스를 동적으로 결정하는 시스템이다. 그래프는 바로 이 둘의 융합이다. 미리 정의된 경계선으로 동적인 노드를 감싼다."

그래서 그래프가 '돌아간 것'은 옛 워크플로우의 겉모습뿐이다. 그 속에 사는 존재는 완전히 다르다. 옛 워크플로우의 노드는 죽은 코드였지만, 그래프의 노드에는 자율적으로 추론하는 에이전트가 들어 있다. 이는 ReAct의 유연성을 통제 가능한 골격 안에 가둔 셈이다.

11. 다섯 가지 추천 도구와 결론

그래프 공학이 '새로운 것'이 아닌 이유

논쟁의 처음으로 돌아가 보자. 그래프 엔지니어링은 마케팅 신조어인가, 진짜인가? 그 판단은 이렇다. 그것은 동시에 '명명 사건'이자 '시각의 상향 이동'이다.

명명 사건으로서의 부분은 허상이다. 노드, 엣지, 상태, 유향 그래프 스케줄링, 상태 머신, 다중 에이전트 오케스트레이션 같은 개념들은 컴퓨터 과학에서 수십 년 동안 있어 왔고, LangGraph·ADK·AutoGen도 실제로 2년 넘게 구축되어 왔다. 이 용어도 루프 엔지니어링처럼 몇 달 후 또 다른 신조어에 덮일 가능성이 높다.

하지만 시각의 상향 이동, 그것은 실체가 있는 변화다. 세 가지 조건이 이미 갖추어졌기 때문이다:

1. 모델이 충분히 강해져서 하나의 자율 노드로 신뢰성 있게 작동할 수 있게 되었다.
2. 프레임워크가 성숙해져서 그 노드들을 안정적으로 연결할 수 있게 되었다.
3. 커뮤니티가 충분히 커져서 공통의 어휘를 갖추게 되었다.

이제 엔지니어링의 중심은 '하나의 에이전트 행동을 프로그래밍하는 것'에서 '여러 에이전트의 조직을 프로그래밍하는 것'으로 확실히 이동했다. 이 전환은 실제이며, 단일 루프로는 결코 만들 수 없는 시스템을 만들어낸다.

흥미로운 반전은 이것이다. 우리가 한참 AI를 연구하고 개발하는데, 결국 마주하게 된 것은 가장 오래된 학문 중 하나, 즉 조직을 관리하는 방법이었다. 어떻게 분업할 것인가, 권한과 책임을 어떻게 정할 것인가, 일하는 사람과 감독하는 사람을 어떻게 분리할 것인가, 누군가 실수해도 전체가 무너지지 않게 하려면 어떻게 할 것인가. 이런 질문들은 인간의 기업이 수백 년 동안 고민해 온 것들이다. 이제 단지 직원만 바뀌었을 뿐, 같은 질문을 다시 하고 있는 것이다.

마무리: 세 가지 실천 제안

첫째, 그래프를 위해 그래프를 만들지 마라. 하나의 깔끔한 루프로 해결된다면 복잡하게 만들 필요가 없다. 우선 냅킨 위에 그릴 수 있을 만큼 작은 그림을 그려보라. 이것이 Anthropic이 반복 강조하는 제일 원칙이다.

둘째, 그래프의 가치는 결정성에서 나온다. 에이전트의 숫자가 아니다. 모델은 판단하게 하고, 코드는 바닥을 받치게 하며, 독립적이고 전문적으로 흠집을 찾는 눈을 곁에 두어라.

셋째, 그리고 가장 중요하게, 그래프는 반드시 현실에 발을 딛고 있어야 한다. 현실의 앵커가 없다면, 아무리 정밀하게 공학을 구축해도 그것은 '더 조직화된 환각 공장'에 불과하다.

감사합니다, 다음에 또 만나요.