LLM 위키

그래프 엔지니어링

갱신 2026-08-09

한눈에 요약

왜 이런 말이 나왔나

루프까지 오면 에이전트가 알아서 일을 나누고 알아서 돈다. 그런데 알아서 도는 만큼 정확하지 않다. 검증 에이전트를 언제 불러야 하는지 같은 것을 맡겨 두면 원하는 대로 흘러가지 않을 수 있다. 그래서 그 부분만 다시 결정적으로 못박자는 이야기가 나왔다 30.

그래프 엔지니어링은 루프 엔지니어링의 확률적인 경로들을 다시 그래프로 만들어 통제하는 접근이다. 일을 서브 태스크로 잘게 쪼개고, 잘했으면 이쪽 못했으면 저쪽으로 가도록 분기를 하나하나 정해 준다 30.

나온 지 한 달 된 말이다. 루프도 두 달밖에 안 됐다 (2026-08 기준). X(구 트위터)에서 그래프 엔지니어링을 말하는 포스트의 99%가 AI 슬롭처럼 보인다는 혹평이 붙어 있고, "그냥 슬롭"이라는 극단적 의견에도 의미가 있다고 인정된다 30.

부품 넷 — 노드·엣지·스테이트·컨디션

말은 거창하지만 뜯어 보면 부품은 넷뿐이다 31.

부품 무엇인가 예
노드(node) 하나의 작업 경쟁사 조사, 검증, 보고서 작성
엣지(edge) 다음 작업으로 가는 길 조사 노드 → 검증 노드
스테이트(state) 작업 사이에 전달되는 정보 조사 결과, 경쟁사 목록
컨디션(condition) 어느 길로 갈지 정하는 규칙 경쟁사 10개 미만이면 되돌아감

여기서 중요한 건 마지막 줄이다. "한 번 더 조사해야겠다"를 모델의 감에 맡기지 않고, 재시도 조건과 이동 경로를 그래프 자체에 적어 둔다. 그게 루프와 갈리는 지점이다 31.

애매한 판단은 AI, 명확한 규칙은 코드

이 개념에서 가장 실용적인 원칙이다. 모든 판정을 모델에게 물어볼 이유가 없다 31.

그래서 좋은 그래프는 AI가 필요 없는 자리에서 AI를 쓰지 않는다. 비용도 아끼고 실패 지점도 준다.

패턴 4종

자주 쓰이는 모양은 넷으로 정리된다. 하나만 골라 쓰는 게 아니라 섞어 쓴다 31.

패턴 하는 일 이 위키의 관련 개념
라우터 조건을 보고 적합한 에이전트에게 넘김 하네스의 라우터 부품
병렬 실행 여러 조사를 동시에 돌리고 취합 서브에이전트
생성자–평가자 작업 에이전트가 만들고 평가 에이전트가 고침 검증 자동화
사용자 승인 중요한 갈림길에서 멈추고 사람에게 물음 휴먼 인 더 루프

네 번째가 특히 중요하게 지목된다. 사람이 할 영역과 AI가 능동적으로 할 영역을 가르는 지점이기 때문이다 31.

무엇이 좋아지나 — 블랙박스가 열린다

시장 조사, 경쟁사 분석, 보고서 작성, 검증을 한 번에 시킨다고 하자. 결과가 그럴듯해 보여도 문제가 남는다. 계획이 틀렸는지, 검색이 부족했는지, 검증을 건너뛰었는지 알 수 없다. 최종 결과가 틀렸다는 사실만 알 수 있다. 작업 전체가 하나의 거대한 블랙박스로 도는 셈이다 31.

그래프로 쪼개면 달라진다. 조사를 세 노드로 나눠 동시에 돌리고, 노드마다 지켜야 할 조건을 건다. 경쟁사 조사 노드에는 "최소 10개", 시장 조사 노드에는 "수치에 반드시 출처 포함", 고객 조사 노드에는 "실제 사용자 의견 최소 20개" 하는 식이다 31.

결과는 스테이트에 쌓이고, 검증 노드가 조건을 확인한다. 미달이면 보고서를 그냥 완성하지 않고 모자란 그 노드로 되돌아간다. 경쟁사가 5개면 경쟁사 조사 노드로, 출처가 부족하면 시장 조사 노드로 돌아가는 식이다 31.

비유가 하나 쓰인다. 단일 에이전트가 유능한 직원 한 명에게 전부 맡기는 것이라면, 그래프 엔지니어링은 회사 전체를 설계하는 것이다. 누가 무엇을 하고, 누가 검증하고, 어떤 결정을 대표가 직접 승인할지를 미리 조직도로 짜 두는 셈이다 31.

이미 쓰고 있었다

새로 배울 게 많아 보이지만 실은 익숙한 물건이다. 다이나믹 워크플로우가 계획을 짜고, 병렬로 리서치하고, 한 번에 모아 검증하는 흐름 자체가 노드와 엣지로 이어져 스테이트를 주고받는 구조다. 대부분 알게 모르게 이미 그래프를 쓰고 있었다는 것이다 31.

언제 쓰지 말아야 하나

오버 엔지니어링 경고가 뚜렷하다. 간단한 요약이나 툴 콜 한두 번으로 끝날 일까지 그래프로 만들 이유는 없다. 구조가 복잡해지고 디버깅할 지점이 늘고, 에이전트를 더 쓰는 만큼 토큰이 녹는다 (2026-08 기준) 31.

쓸 만한 자리는 조건이 겹칠 때다. 단계가 여럿이고, 조건 분기가 있고, 병렬 처리가 필요하고, 실패하면 되돌아가야 하고, 중간에 사람이 개입해야 하고, 결과를 검증해야 하는 작업이다. 에이전트 루프 하나로는 관리가 안 되기 시작하는 지점이 곧 그래프가 강해지는 지점이다 31.

루프의 반대 방향

앞선 네 단계는 다루는 범위가 계속 바깥으로 넓어졌다. 물어볼 말 → 보여줄 정보 → 일할 환경 → 반복 자체 순이다. 그런데 그래프만 방향이 다르다.

루프 엔지니어링 그래프 엔지니어링
사람이 주는 것 궁극적인 목표 하나 서브 태스크와 분기 조건
에이전트의 몫 경로를 스스로 판단 정해진 노드의 일만
실패를 막는 법 스스로 평가하고 되돌아감 애초에 못 가게 막음

한마디로 루프는 자율성을 주고, 그래프는 그 자율성을 뺏는다 30.

모순③ — 상위 호환인가, 반작용인가

같은 개념을 두 자료가 정반대로 평가한다. 어느 한쪽을 지우지 않고 둘 다 둔다.

상위 호환으로 보는 쪽 반작용으로 보는 쪽
앞 단계와의 관계 자연스러운 연장, 계속 상위 호환 방향이 반대인 되감기
루프와의 관계 각 노드 안에 루프를 넣을 수 있음 루프가 준 자율성을 회수함
지금 배울 가치 이미 쓰고 있으니 설계만 의식하면 됨 하네스까지만 알아도 충분함
근거 31 30

두 평가가 완전히 배타적이지는 않다. 노드 하나하나 안에 루프를 넣거나, 몇 개의 노드와 엣지를 묶어 독립적인 루프로 굴릴 수 있다는 설명은 품는 관계를 말한다 31. 반면 전체 시스템 차원에서 보면 판단 권한이 에이전트에서 사람이 그린 구조로 돌아온 것도 사실이다. 무엇을 층위로 보느냐에 따라 답이 갈리는 셈이다.

2024년으로 되돌아간 것인가

가장 흔한 비판이 이것이다. 2024년 LangGraph가 하던 일이 정확히 이거였다. 에이전트를 믿을 수 없으니 정해진 루트를 따라가게 만들고, 시작부터 끝까지의 길을 사람이 결정론적으로 깔아 주는 방식이다 30.

한 에이전트가 일하고 결과를 받아 다음으로 넘긴다는 구조 자체는 그때와 똑같다. 다만 두 가지가 다르다.

통제하는 이유가 바뀌었다

여기가 이 개념의 가장 흥미로운 대목이다. 예전에는 LLM이 멍청해서, 자꾸 실수하니까 통제했다. 지금은 다르다. 의도한 대로 가게 하려고 통제한다 30.

에이전트가 다른 데로 새는 건 멍청해서가 아니다. 어떻게 해야 할지 지침을 받지 못했기 때문이다. 그 지침을 프롬프트로 주는 대신 정해진 흐름으로 주자는 것이 그래프 쪽 주장이다.

대담에서는 "똑똑해진 학생이 공부 대신 시험지를 미리 빼내려 드는 것을 막는 통제 아니냐"는 리워드 해킹 해석도 나온다. 그렇게 보면 오히려 납득이 간다는 반응이었다 30.

배워야 하나

대담의 결론은 유보에 가깝다. 하네스까지만 배워도 하려는 문제는 대부분 풀린다는 것이다. 다만 하네스로 만든 에이전트를 여러 개 굴리고 통제하려는 순간부터는 루프와 그래프의 영역이 되고, 그건 확실히 어려운 문제다 30.

다른 자료는 조금 더 담담하다. 새 용어에 뒤처진 느낌을 받을 필요가 없다는 것이다. 이미 다이나믹 워크플로우로 쓰고 있던 구조이고, 직접 설계하고 싶다면 크게 어렵지 않다고 본다. 구조를 사람이 처음부터 다 짤 필요도 없다. 메타프롬프팅처럼 AI와 함께 설계해도 된다 31.

전망은 이렇다. 에이전트가 더 복잡한 실무를 맡을수록 개별 에이전트의 성능보다 그래프를 얼마나 잘 설계했느냐가 중요해질 가능성이 높다. 다만 그때가 되면 또 다른 버즈워드가 나올 것이라는 단서가 함께 붙는다 31.

여기서 짚어 둘 게 있다. "똑똑한 AI가 실수하지 않도록 일하는 구조를 설계하는 기술"이라는 이 자료의 정의는 하네스 엔지니어링의 정의와 사실상 같은 문장이다 31. 두 용어가 다른 층위에서 같은 것을 부르고 있다는 방증으로 읽을 수 있다.

함께 읽기

이 문서를 참조하는 문서 9개