Loop는 죽고 Graph가 떴다? AI 에이전트 오케스트레이션의 진짜 변화 짚어보기
한 줄 요약
요즘 개발자 커뮤니티에서 "Loop Engineering은 끝났고 이제 Graph Engineering의 시대"라는 말이 유행처럼 돌고 있는데요, 실제로 들여다보면 완전히 새로운 개념이 등장한 게 아니라 여러 개의 Agent Loop를 하나의 작업 흐름으로 엮는 오케스트레이션 방식이 구체화된 것에 가깝습니다. Loop와 Graph는 경쟁 관계가 아니라, Loop가 쌓이면 자연스럽게 Graph가 되는 구조예요.
Loop Engineering, 기본부터 짚고 가기
Loop Engineering은 아주 단순한 구조에서 출발합니다.
- Agent가 하나의 목표를 향해 작업을 수행하고
- 외부 Verifier(검증자)가 결과를 확인하고
- 실패하면 다시 Agent에게 돌려보내고
- 테스트 통과 같은 명확한 조건을 만족하면 종료
코드 작업이라면 "테스트가 통과할 때까지 Agent가 수정과 검토를 반복하게 만드는 것"이 대표적인 예시죠. 간단한 Loop라면 별도 프레임워크 없이 프롬프트만으로도 충분히 만들 수 있습니다.
Graph는 언제, 왜 필요해질까
문제는 작업이 복잡해질 때입니다. 예를 들어 코드 리뷰 시스템을 생각해보면,
- Codex가 변경 사항을 만들고 PR을 생성
- 여러 감사(audit) Agent가 병렬로 PR을 검사
- Verifier가 발견된 이슈를 모아 진짜 문제인지 확인
- 확인된 문제를 Fixer에게 전달
- 테스트 실행 → 실패하면 수정 단계로 복귀, 통과하면 완료
이건 하나의 Loop로는 처리하기 어렵습니다. 여러 작업자가 역할을 나눠 맡고, 결과를 서로 인계하고 검토하는 인간 조직과 비슷한 구조가 필요해지죠. 이게 바로 Graph입니다. 즉 Graph는 Loop를 대체하는 게 아니라, 여러 Loop와 작업 단계를 연결하다 보면 자연스럽게 생겨나는 결과물이에요.
사실 Graph 자체는 새로운 게 아니다
Agent 시스템에서 쓰이는 Graph 패턴 대부분은 이미 오래전부터 소프트웨어 업계에 존재했습니다.
- Anthropic이 2024년에 정리한 Agent 패턴에도 Chaining, Routing, Parallelization, Orchestrator-Workers, Evaluator-Optimizer 같은 구조가 이미 포함되어 있었고
- 더 넓게 보면 Workflow Engine, DAG Scheduler, State Machine이 수십 년간 다뤄온 문제이며
- Airflow가 Task Graph를 관리하는 대표적인 사례입니다
그러니까 "Graph Engineering의 새로움"은 Graph라는 구조 자체에 있는 게 아닙니다.
진짜 달라진 건 '노드'의 정체
핵심은 여기 있습니다. 기존 Workflow의 각 단계는 정해진 규칙을 그대로 실행하는 결정론적 코드였습니다. 하지만 이제 그 노드 자리에 지시를 해석하고 스스로 판단하는 확률적인 LLM Agent가 들어갔어요.
그 결과 다음과 같은 문제가 생깁니다.
- 지시를 잘못 이해할 수 있음
- 같은 입력에서도 실행마다 다른 결정을 내릴 수 있음
- 예상 못한 도구나 경로를 선택할 수 있음
작은 작업이라면 하나의 Chat Context가 Scheduler, Database, Log, Project Manager 역할까지 다 떠맡을 수 있지만, 작업이 여러 시간·여러 저장소·여러 Agent에 걸쳐지면 하나의 컨텍스트만으로는 상태와 제어 흐름을 관리하기 어려워집니다. 그래서 Graph Engineering이 실제로 요구하는 건 고정된 작업 단계 대신 확률적인 실행자를 연결하고 통제하는 설계 능력입니다.
Graph가 드러내는 진짜 질문들
작업 흐름을 Graph로 쪼개는 순간, 이전에는 Chat Context 안에서 대충 넘어갈 수 있었던 질문들에 명시적으로 답해야 합니다.
- 어떤 작업을 병렬로 실행할 것인가
- 어떤 상태를 다음 노드에 전달할 것인가
- 누가 다른 Agent의 결과를 거부할 권한을 갖는가
- 실패하면 어느 단계로 되돌아갈 것인가
- 비용과 반복 횟수는 어디서 제한할 것인가
- 어떤 조건에서 전체 작업을 종료할 것인가
이 질문들은 Graph Engineering이 새로 만든 게 아니라 원래부터 시스템 설계에 존재했던 문제입니다. Graph의 실질적인 가치는 이런 작업 인계와 제어 규칙을 시스템 수준에서 명시적으로 드러내는 것에 있습니다. LangGraph 같은 전용 프레임워크가 없어도, 지금 쓰는 코딩 Agent와 일반 Workflow 도구를 조합하면 같은 구조를 충분히 만들 수 있어요.
Agent끼리 합의했다고 검증이 끝난 게 아니다
여기서 짚고 넘어가야 할 중요한 함정이 있습니다. Agent 수를 늘린다고 결과의 신뢰도가 자동으로 올라가지 않는다는 점이에요.
- 같은 모델, 잘못된 컨텍스트를 쓰는 Reviewer들은 오류가 서로 연관되어 나타날 수 있음
- 여러 Agent가 같은 결론을 냈다는 사실 자체가 독립적 검증을 의미하지 않으며, 오히려 그럴듯하게 정리된 잘못된 결과를 만들 수도 있음
그래서 여러 Agent를 쓸 때는 판단 구조를 의도적으로 분리해야 합니다.
- 서로 다른 모델을 Reviewer로 사용
- Reviewer에게 새로운(독립된) 컨텍스트 제공
- 중요한 변경에는 사람의 검토와 거부 권한 추가
- 최종 판단은 실제 테스트, 완료된 거래, 사용자의 실제 행동, 독립된 전문가 판단처럼 Agent 시스템 바깥의 증거로 확인
모든 검증을 다시 Agent에게 맡기는 완전 자동화에는 명백한 한계가 있습니다.
그래서 어떻게 시작해야 할까: Loop → Graph 순서로
유행을 따라 처음부터 수십 개 Agent가 밤새 돌아가는 거대한 Graph를 만들 필요는 없습니다. 다음 요소를 갖춘 단순한 Loop 하나로 시작하는 게 정석이에요.
- 반복해서 수행할 실제 작업
- 결과를 확인할 Verifier
- 사람이 확인 가능한 상태
- 빠르게 볼 수 있는 지표/UI
- 명확한 중단 조건
실제로 운영하면서 실패 패턴을 파악한 뒤에, 필요한 구조만 하나씩 추가하면 됩니다.
- 독립된 Reviewer
- 병렬 Branch
- Security Agent의 Veto(거부권)
- 상태 저장과 실패 재시도
- 사람의 승인 단계
이렇게 실제 작업의 복잡성이 커지는 만큼 구조를 하나씩 얹다 보면, 결과적으로 그게 바로 Graph가 되는 것입니다.
결국 이름은 중요하지 않다
"Loop Engineering은 죽고 Graph Engineering이 등장했다"는 문장은 사실 AI 업계가 새 용어를 끊임없이 만들어내는 현상을 비꼬는 농담에서 퍼진 표현입니다. 진짜 변화는 새로운 Graph 구조가 발명된 게 아니라, 여러 Agent를 장시간 자율적으로 실행하면서 오케스트레이션을 명시적으로 설계해야 할 필요성이 커졌다는 점이에요.
결국 지속적으로 중요한 건 어떤 Graph 프레임워크를 고르느냐가 아니라,
- 어떤 작업을 확률적인 Agent에게 맡길지
- 어떤 작업은 단순하고 결정적인 코드로 남길지
- 어디에 실제 검증과 사람의 판단을 넣을지
를 결정하는 능력입니다. 유행어에 휘둘리기보다는 이 원칙을 기준으로 시스템을 설계해보는 게 훨씬 남는 장사일 것 같네요.