그래프 엔지니어링의 등장
루프 엔지니어링(Loop Engineering)이라는 말이 등장한 지 얼마 지나지 않았지만, AI 업계에서는 벌써 ‘그래프 엔지니어링(Graph Engineering)’이라는 새로운 용어가 등장했습니다.
AI 개발자들이 각각의 루프를 서로 연결해 더 큰 시스템을 만들기 시작하며, 이 구조를 그래프 엔지니어링이고 부르고 있습니다.
먼저 루프 엔지니어링부터 살펴볼 필요가 있습니다. 루프 엔지니어링은 에이전트에게 매 순간 무엇을 해야 할지 일일이 지시하는 대신, 하나의 목표와 결과를 스스로 점검할 방법, 그리고 일이 끝날 때까지 반복할 수 있는 사이클을 부여하는 방식입니다.
루프는 쉽게 말해 ‘에이전트가 일을 처리하는 기본 사이클’입니다. 다음에 할 일을 찾고, 계획을 세우고, 실행하고, 결과를 확인한 뒤 계속 진행할지 멈출지를 결정합니다. 작업이 복잡하지 않다면 이 정도 구조만으로도 충분합니다.
그러나 업무가 복잡해지면 상황이 달라집니다. 어떤 작업은 여러 갈래로 나눠 동시에 처리해야 하고, 어떤 단계에서는 코딩 모델이 필요하지만 다른 단계에서는 검색이나 별도의 분석 모델이 필요할 수 있습니다. 한 에이전트가 만든 결과를 다른 에이전트가 검증하거나 반박해야 할 수도 있습니다. 일부 결정은 자동으로 처리할 수 있지만, 중요한 의사결정은 반드시 사람의 승인을 거쳐야 할 수도 있습니다.
여기까지 오면 하나의 루프를 잘 만드는 것만으로는 부족합니다. 서로 다른 작업과 모델, 도구, 사람의 판단을 어떤 순서로 연결할지, 어떤 조건에서 다음 단계로 이동시킬지까지 설계해야 합니다. 이 더 큰 구조를 ‘그래프’라고 생각할 수 있습니다.
그래프 자체는 낯선 개념이 아닙니다. 일반적으로 그래프는 노드(node), 엣지(edge), 상태(state)로 구성됩니다. 노드는 하나의 작업 단위입니다. 에이전트일 수도 있고, 모델 호출이나 코드, 사람의 결정일 수도 있습니다. 엣지는 다음에 어떤 작업으로 이동할지를 정하고, 상태는 한 단계에서 생성된 정보를 다음 단계로 전달합니다.
엄밀히 말하면 루프도 그래프의 한 형태입니다. 특정 경로가 이전 노드로 되돌아가도록 연결된 그래프이기 때문입니다.
더구나 이러한 구조가 소프트웨어 엔지니어링에서 완전히 새로운 것도 아닙니다. 상태 기계(state machine), DAG(Directed Acyclic Graph), 워크플로 엔진, 오케스트레이션 시스템은 오랫동안 복잡한 작업을 연결하고 제어하는 데 활용되어 왔습니다. LangChain이 2024년 공개한 LangGraph 역시 개발자가 상태를 유지하는(stateful) 에이전트 워크플로를 만들 수 있도록 설계된 프레임워크입니다.
그렇다면 지금 달라진 것은 무엇일까요.
핵심은 ‘그래프 자체’보다 이 구조 안에서 모델에게 어떤 역할을 맡길 것인가에 있습니다.
그래프 엔지니어링의 핵심은 ‘역할의 분리’에 있다
초기 에이전트 시스템에서는 모델에게 상당히 많은 결정을 맡기는 경우가 많았습니다. 다음에 무엇을 할지 결정하고, 어떤 도구를 사용할지 선택하고, 결과를 해석하고, 계획을 수정하고, 언제 작업을 종료할지까지 모델이 판단했습니다.
짧은 데모나 비교적 단순한 작업에서는 이런 방식이 효과적으로 작동할 수 있습니다. 그러나 실제 기업 환경의 길고 복잡한 워크플로에 적용하면 다양한 실패 가능성이 함께 나타납니다.
에이전트가 별다른 이유 없이 같은 작업을 반복하거나, 반드시 지켜야 할 비즈니스 로직을 건너뛸 수 있습니다. 이전 단계의 상태를 놓치거나, 도구에서 생성된 방대한 출력으로 컨텍스트를 불필요하게 소모하는 문제도 발생할 수 있습니다.
구글은 Agent Development Kit(ADK) 2.0을 설명하면서 이 문제에 대한 하나의 원칙을 제시합니다. 어떤 순서로 움직여야 하는지, 어떤 조건에서 다음 단계로 넘어가야 하는지가 이미 정해져 있다면 이를 코드로 처리하고, 상황을 해석하거나 판단해야 하는 부분만 모델에 맡기는 방식입니다.
예를 들어 “검토가 끝나면 승인 단계로 이동한다”는 것은 정해진 업무 규칙이므로 코드가 처리할 수 있습니다. 반면 “이 결과에 문제가 있는가?”와 같이 문맥을 이해하고 판단해야 하는 질문은 모델이 담당하는 것이 적합합니다.
돌이켜 보면 자연스러운 구분입니다. 하지만 에이전트가 처음 주목받기 시작했을 때는 모델이 다음 작업을 선택하고, 도구를 결정하며, 계획을 바꾸고, 종료 시점까지 스스로 판단해야 비로소 ‘에이전트답다’고 보는 시각이 강했습니다. 그 결과 모델의 판단이 필요한 영역뿐 아니라 정해진 규칙에 따라 처리할 수 있는 과정까지 모델에 맡기는 경우가 많았습니다.
앤트로픽 역시 유사한 문제를 다른 방식으로 풀고 있습니다. Claude Code의 다이내믹 워크플로우(dynamic workflows)는 Claude가 자바스크립트로 작업의 진행 방식을 먼저 구성하도록 합니다. 어떤 작업을 병렬로 수행할지, 각각의 작업을 어떤 서브에이전트에게 배정할지, 결과를 어떤 순서로 취합할지를 코드로 정의하는 방식입니다.
이 구조에서는 작업이 시작된 이후 모델이 매 단계마다 “다음에는 무엇을 해야 하는가”를 다시 판단할 필요가 없습니다. 처음에 전체 실행 방식을 설계하더라도 실제 수행 과정은 미리 정의된 코드에 따라 진행됩니다. 불필요한 모델 호출을 줄일 수 있고, 작업 경로 역시 보다 명확하게 파악할 수 있습니다.
이런 방식이 현재 이야기되는 ‘그래프 엔지니어링’의 현실적인 모습에 가깝습니다.
중요한 것은 에이전트에 더 많은 자유를 주는 것이 아닙니다. 모델이 판단해야 할 부분과 코드·도구·사람이 책임져야 할 부분을 분리하고, 이들을 적절하게 연결하는 것입니다.
상황에 따라 답이 달라질 수 있고 맥락을 읽어야 하는 문제는 모델에 맡길 수 있습니다. 반대로 반드시 지켜야 할 순서와 규칙, 승인 절차, 접근 권한과 같은 요소는 코드와 시스템으로 통제해야 합니다.
이렇게 보면 모델은 전체 과정을 혼자 이끄는 존재라기보다, 더 큰 시스템 안에서 ‘판단이 필요한 업무’를 담당하는 하나의 구성 요소에 가깝습니다.
따라서 기업이 신뢰할 수 있는 에이전트 시스템을 구축하려면 프롬프트만 잘 작성해서는 충분하지 않습니다. 어떤 작업을 어디로 보낼 것인지, 앞 단계의 정보를 다음 단계에 어떻게 전달할 것인지, 결과의 품질을 어떻게 검증할 것인지, 오류가 발생했을 때 어떤 방식으로 복구할 것인지까지 함께 설계해야 합니다.
프롬프트의 중요성이 낮아진 것은 아닙니다. 다만 이제는 좋은 프롬프트를 만드는 것만큼이나 그 프롬프트와 모델이 안정적으로 작동할 수 있는 시스템 환경을 설계하는 것이 중요해지고 있습니다.
‘그래프’라는 말이 무엇을 의미하는지 먼저 확인해야 한다
그래프 엔지니어링을 이해할 때 주의해야 할 점도 있습니다. 현재 업계에서 모두 ‘그래프’를 이야기하고 있지만, 정작 같은 대상을 의미하는 것은 아니기 때문입니다.
가장 먼저 생각할 수 있는 것은 컨트롤 그래프(control graph)입니다. 워크플로가 어떤 단계로 구성되어 있고, 어떤 조건에서 다음 단계로 넘어가는지를 정의하는 구조입니다. 쉽게 말하면 업무가 어떤 순서와 규칙에 따라 진행되는지를 나타내는 실행 지도입니다.
다른 맥락에서 그래프는 지식 그래프(knowledge graph)를 의미하기도 합니다. 정보를 개체(entity)와 그 사이의 관계(relationship)로 정리하는 방식입니다. 마이크로소프트의 GraphRAG가 대표적인 사례입니다. GraphRAG는 문서에서 개체와 관계를 추출해 그래프를 만들고, 정보 검색 과정에서 이 구조를 활용합니다.
실행 트레이스(execution trace)를 그래프 형태로 표현하기도 합니다. 에이전트가 하나의 작업을 수행하는 동안 어떤 도구를 사용했고, 어떤 판단을 거쳤으며, 어느 단계에서 문제가 발생했는지를 기록한 실행 이력입니다.
‘Intuition Machine’의 카를로스 페레즈(Carlos Perez)는 또 다른 관점에서 여러 개선 루프를 하나의 그래프로 바라보는 방식을 제안하기도 했습니다. 하나의 루프가 특정 지표를 개선한다면, 다른 루프는 그 과정에서 악화될 수 있는 견제 지표(counter-metric)를 점검하고, 또 다른 루프는 애초에 설정한 지표가 실제 목표를 제대로 반영하고 있는지를 확인하는 식입니다.
이런 구조는 자가 개선 시스템에서 특히 중요할 수 있습니다. 하나의 지표만 지속적으로 최적화하면 해당 지표가 실제 비즈니스 목표와 점차 멀어져도 시스템은 계속 같은 방향으로 최적화를 진행할 수 있기 때문입니다. 개선을 위한 루프뿐 아니라 ‘올바른 방향으로 개선되고 있는가’를 확인하는 별도의 루프가 필요하다는 의미입니다.
이처럼 모두 ‘그래프’라는 용어를 사용하지만 각각이 해결하려는 문제는 다릅니다.
따라서 누군가 “그래프 엔지니어링을 도입해 정확도가 nn% 향상됐다”고 이야기한다면 최소한 세 가지를 확인할 필요가 있습니다. 어떤 종류의 그래프인지, 무엇과 비교한 결과인지, 그리고 해당 수치가 어떤 방식으로 측정됐는지입니다.
그래프 엔지니어링이라는 새로운 용어보다 실제 적용 대상과 효과를 구체적으로 확인해야 하는 이유입니다.
모든 에이전트에 그래프가 필요한 것은 아니다
또 하나 주의할 점은 모든 에이전트 시스템을 그래프로 만들어야 하는 것은 아니라는 점입니다.
새로운 기술 개념이 등장하면 기존 시스템 전체를 새로운 방식으로 다시 설계하려는 유혹이 생길 수 있습니다. 그러나 상당수의 업무는 여전히 하나의 모델과 몇 개의 도구, 단순한 루프와 명확한 종료 조건만으로 충분히 처리할 수 있습니다.
그래프 프레임워크를 추가하면 그에 따른 비용도 발생합니다. 상태를 관리해야 하고, 작업 경로를 설계하는 코드가 추가되며, 디버깅해야 할 지점과 워크플로가 실패할 수 있는 지점 역시 증가합니다.
그래프가 필요한 것은 업무 자체의 구조가 복잡한 경우입니다. 여러 작업을 동시에 진행해야 하거나, 생성된 결과를 별도의 모델이나 에이전트가 검증해야 하는 경우가 대표적입니다. 단계마다 서로 다른 모델과 도구가 필요하거나, 중요한 행동을 실행하기 전에 반드시 사람의 승인을 거쳐야 하는 업무에서도 그래프 구조가 효과적일 수 있습니다.
반대로 처음부터 끝까지 순차적으로 처리할 수 있고 예외 상황도 많지 않은 업무라면 단순한 구조를 유지하는 편이 오히려 효율적입니다.
복잡한 워크플로 다이어그램 자체가 에이전트의 성능을 보장하지는 않습니다. 시스템의 복잡성을 필요 이상으로 높이면 오히려 운영과 장애 대응, 비용 관리가 더 어려워질 수 있습니다.
따라서 기업이 물어야 할 질문은 “그래프 엔지니어링을 도입해야 하는가”가 아니라 “우리 업무의 복잡성이 그래프 구조를 필요로 하는가”에 가깝습니다.
중요한 것은 새로운 이름이 아니라 시스템 설계다
최근 에이전트 기술의 발전이 향하고 있는 방향은 비교적 분명합니다. 에이전트를 만드는 일의 범위가 프롬프트를 넘어 계속 확장되고 있다는 점입니다.
개발자들의 관심은 좋은 프롬프트를 만드는 것에서 모델에 필요한 정보를 어떻게 구성할 것인지로 이동했고, 다시 모델이 안정적으로 일할 수 있는 하네스(harness)와 루프를 설계하는 문제로 확장됐습니다. 이제는 모델과 도구, 평가자(evaluator), 코드, 그리고 사람의 판단을 어떤 구조로 연결할 것인지가 중요한 설계 과제가 되고 있습니다.
이미 일부에서는 ‘메타그래프 엔지니어링(metagraph engineering)’이라는 표현까지 등장하고 있습니다. 앞으로도 새로운 용어는 계속 나타날 가능성이 높습니다.
그러나 기업이 해결해야 할 문제는 크게 달라지지 않습니다.
업무를 어디까지 나눌 것인지, 실행 과정을 어떻게 통제할 것인지, 모델이 만든 결과를 어떻게 독립적으로 검증할 것인지, 다음 단계에 필요한 정보를 어떻게 보존할 것인지, 그리고 사람이 결정해야 하는 업무를 어떻게 사람의 통제 아래 둘 것인지에 대한 문제입니다.
결국 좋은 에이전트 시스템은 AI에게 가능한 한 많은 판단을 맡기는 시스템이 아닙니다.
AI가 판단해야 할 부분과 코드·도구·사람이 책임져야 할 부분을 명확하게 구분하고, 각각을 필요한 방식으로 연결한 시스템입니다.
루프는 이러한 시스템을 구성하는 하나의 단위이고, 그래프는 그보다 더 큰 구조를 설계하고 관리하기 위한 방법 중 하나입니다.
따라서 ‘그래프 엔지니어링’이라는 새로운 용어 자체를 따라가기보다, 기업의 업무 구조와 위험 수준에 맞게 어떤 판단을 AI에 맡기고 어떤 통제를 시스템에 남겨둘 것인지를 결정하는 것이 더 중요합니다.
Writer: Turing Post – Ksenia Se & Ben Eum
Edit: Metanet
