또다른 트렌드 Graph Engineering 알려드림
📺 원본 영상: 또다른 트렌드 Graph Engineering 알려드림
🎙️ 채널: 코드팩토리
📅 정리 일자: 2026-08-08
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
이 영상은 AI 시스템 설계의 관심사가 Prompt Engineering에서 Context Engineering, Loop Engineering을 거쳐 Graph Engineering으로 확장되고 있다는 흐름을 설명합니다. 강연자는 Graph Engineering을 단순한 유행어가 아니라, 여러 AI 작업과 코드 규칙, 사용자 승인 절차를 하나의 구조 안에서 연결하는 설계 방식으로 정의합니다. 핵심은 AI를 더 똑똑하게 만드는 것이 아니라, 이미 충분히 강력해진 AI가 실수하지 않도록 일하는 구조를 설계하는 데 있습니다.
프롬프트에서 그래프로 이동하는 AI 설계의 진화
강연자는 AI 활용의 초기 단계에서 가장 중요한 기술이 Prompt Engineering이었다고 설명합니다. 이 시기에는 AI에게 어떤 문장을 입력해야 더 좋은 답을 얻을 수 있는지가 핵심이었고, 사용자는 모델의 응답 품질을 끌어올리기 위해 표현 방식과 지시문을 다듬는 데 집중했습니다. 그러나 모델이 복잡한 작업을 수행하기 시작하면서 단순한 프롬프트 한 줄보다, 모델에게 어떤 정보와 기억, 도구를 제공할 것인지가 더 중요해졌고, 이 흐름이 Context Engineering으로 이어졌습니다.
그 다음 단계로 등장한 것이 Loop Engineering입니다. Loop Engineering은 AI가 한 번 답하고 끝나는 것이 아니라, 계획을 세우고 실행하고 결과를 확인한 뒤 다시 수정하는 반복 구조를 설계하는 방식입니다. 이는 AI Agent가 본격적으로 활용되면서 자연스럽게 중요해졌는데, 실제 업무에서는 한 번의 응답보다 여러 번의 시도와 검증을 거친 결과가 더 신뢰할 만하기 때문입니다. 하지만 강연자는 이제 이 루프만으로는 충분하지 않은 시점이 오고 있다고 봅니다.
Graph Engineering은 이 흐름의 다음 단계로 제시됩니다. 이제 중요한 것은 하나의 AI가 얼마나 똑똑한지가 아니라, 어떤 AI 또는 작업 노드가 먼저 움직이고, 어떤 작업을 동시에 처리하며, 실패했을 때 어디로 돌아가고, 어느 순간에 사람이 개입해야 하는지를 설계하는 것입니다. 즉 Graph Engineering은 AI가 움직이는 경로 자체를 설계하는 방법이며, 단일 에이전트 중심 사고에서 시스템 구조 중심 사고로 넘어가는 전환점이라고 볼 수 있습니다.
Graph Engineering의 기본 구조: Node, Edge, State, Condition
강연자는 Graph Engineering을 이해하기 위한 기본 구성 요소로 Node, Edge, State, Condition을 제시합니다. 여기서 Node는 하나의 작업 단위를 의미하고, Edge는 다음 작업으로 이동하는 경로를 뜻합니다. State는 작업 사이에서 전달되는 정보이며, Condition은 어느 경로로 이동할지를 결정하는 규칙입니다. 이 네 가지 개념을 조합하면 AI 워크플로우는 단순한 순차 실행이 아니라, 조건에 따라 분기하고 병렬로 실행되며 필요할 때 되돌아가는 구조가 됩니다.
01:57 - Graph Engineering의 핵심 구성 요소인 Node, Edge, State, Condition을 설명하는 구간
이 관점에서 보면 Graph Engineering은 완전히 낯선 개념이라기보다, 이미 개발자들이 익숙하게 다뤄온 Dynamic Workflow와 매우 닮아 있습니다. 예를 들어 하나의 큰 요청을 받아 계획을 세우고, 여러 리서치 작업을 병렬로 수행한 뒤, 결과를 모아 검증하고 최종 산출물을 만드는 구조는 이미 Node와 Edge, State를 가진 그래프 형태입니다. 강연자는 많은 사용자가 자신도 모르게 이미 Graph Engineering적 구조를 사용하고 있었다고 설명합니다.
중요한 점은 Graph Engineering이 단순히 작업을 여러 단계로 나누는 것에 그치지 않는다는 점입니다. 각 단계가 어떤 책임을 갖는지, 어떤 조건을 만족해야 다음 단계로 갈 수 있는지, 실패했을 때 어느 단계로 돌아가야 하는지를 명시적으로 설계한다는 데 차이가 있습니다. 이 때문에 Graph Engineering은 복잡한 AI 업무를 블랙박스가 아니라 관찰 가능하고 통제 가능한 시스템으로 바꾸는 역할을 합니다.
단일 에이전트의 한계와 블랙박스 문제
강연자는 단일 에이전트 방식의 한계를 시장 조사, 경쟁사 분석, 보고서 작성, 검증을 한 번에 맡기는 예시로 설명합니다. 사용자가 하나의 AI에게 “시장을 조사하고 경쟁사를 분석하고 보고서를 작성한 뒤 틀린 정보가 없는지 검증해 달라”고 요청하면, 겉으로는 그럴듯한 결과물이 나올 수 있습니다. 그러나 그 안에서 계획이 적절했는지, 검색을 충분히 했는지, 정보를 제대로 해석했는지, 검증을 실제로 수행했는지는 확인하기 어렵습니다.
이 구조의 문제는 최종 결과가 틀렸다는 사실만 사후적으로 알 수 있다는 데 있습니다. 시장 조사가 부족했는지, 경쟁사를 충분히 찾지 않았는지, 고객 조사와 경쟁사 조사를 순차적으로만 처리해 시간이 낭비됐는지, 혹은 검증 단계를 건너뛰었는지 알 수 없습니다. 결국 모든 판단과 실행이 모델 내부에 묶여 있기 때문에, 사용자는 결과물을 받기 전까지 작업 과정에 개입하거나 통제하기 어렵습니다.
Graph Engineering은 이 문제를 구조적으로 해결하려는 접근입니다. AI가 검색어 생성, 문서 요약, 결과 작성처럼 애매하고 언어적인 판단이 필요한 작업을 맡고, 최대 재시도 횟수, 필수 출처 존재 여부, 지출 한도, 사용자 승인 필요 여부 같은 명확한 규칙은 코드가 맡도록 나누는 방식입니다. 강연자의 표현을 정리하면, 애매한 판단은 AI에게 맡기되 반드시 지켜야 하는 규칙은 코드에 맡기는 혼합 구조가 Graph Engineering의 실용적 핵심입니다.
03:44 - AI가 맡을 판단과 코드가 맡을 규칙을 구분하는 Graph Engineering의 통제 구조 설명
대표적인 Graph Pattern: 라우터, 병렬 실행, 생성자-평가자, 사용자 승인
강연자는 Graph Engineering에서 자주 쓰이는 대표 패턴으로 Router Pattern, Parallel Execution, Generator-Evaluator Pattern, User Approval Pattern을 소개합니다. Router Pattern은 요청의 성격이나 조건에 따라 적합한 Agent 또는 작업 노드로 요청을 전달하는 방식입니다. 예를 들어 사용자의 요청이 법률 문서 검토인지, 시장 조사인지, 코드 작성인지에 따라 서로 다른 전문 노드로 보내는 구조를 만들 수 있습니다.
04:42 - Router Pattern, Parallel Execution, Generator-Evaluator Pattern, User Approval Pattern 등 대표 그래프 패턴 설명
Parallel Execution은 여러 작업을 동시에 수행하는 패턴입니다. 강연자가 예로 든 것처럼, 하나의 기획 요청이 들어왔을 때 시장 조사, 경쟁사 조사, 고객 조사를 동시에 진행하면 전체 처리 시간이 줄어듭니다. 그러나 이 패턴의 장점은 속도만이 아닙니다. 각 작업이 독립된 책임을 갖기 때문에, 나중에 어떤 부분이 부족했는지 추적하기 쉬워지고, 각 결과를 독립적으로 검증할 수 있게 됩니다.
Generator-Evaluator Pattern은 작업 Agent가 결과물을 만들고, 평가 Agent가 이를 확인한 뒤 수정 여부를 결정하는 구조입니다. 이는 Loop Engineering과도 연결되는 패턴으로, 생성과 검토가 반복되며 품질을 높이는 데 사용됩니다. 여기에 User Approval Pattern이 추가되면, 중요한 의사결정 지점에서 AI가 자동으로 다음 단계로 넘어가지 않고 사람에게 승인 여부를 묻도록 만들 수 있습니다. 강연자는 이 Human-in-the-loop 구조가 Graph Engineering에서 매우 중요한 요소라고 강조합니다.
AI 자동화 SaaS 사례로 보는 Graph Engineering의 실제 작동 방식
강연자는 “한국에서 AI 자동화 SaaS를 만들려고 하는데, 시장 규모를 조사하고 주요 경쟁자를 정리하고 고객의 주요 Pain Point를 찾은 뒤 어떤 제품을 만들어야 하는지 제안해 달라”는 작업을 예시로 듭니다. 이 요청을 단일 Agent에게 맡기면 Agent는 나름대로 조사하고 정리하고 제안하겠지만, 그 과정 전체가 하나의 큰 블랙박스로 작동합니다. 시장 조사를 얼마나 했는지, 경쟁사를 몇 개 조사했는지, 고객 의견을 실제로 확인했는지, 충분하다는 기준이 무엇이었는지는 사용자가 알기 어렵습니다.
Graph Engineering을 적용하면 구조가 달라집니다. 첫 번째 Node에서는 사용자 요청을 분석하고, 다음 Node에서는 작업을 하위 작업으로 나누는 계획을 세웁니다. 이후 시장 조사, 경쟁사 조사, 고객 Pain Point 조사를 각각 별도의 Node로 분리하고 동시에 실행할 수 있습니다. 이렇게 하면 단순히 빨라지는 것뿐 아니라, 각 Node가 무엇을 해야 하는지 명확해지고 결과를 독립적으로 점검할 수 있습니다.
06:47 - AI 자동화 SaaS 사례에서 시장 조사, 경쟁사 조사, 고객 Pain Point 조사를 병렬 Node로 나누는 설명
예를 들어 경쟁사 조사 Node에는 최소 10개의 경쟁사를 조사하라는 규칙을 넣을 수 있고, 시장 조사 Node에는 시장 규모 수치에 반드시 출처를 포함하라는 조건을 둘 수 있습니다. 고객 조사 Node에는 최소 20개의 실제 사용자 의견을 수집하라는 규칙을 부여할 수 있습니다. 이처럼 각 Node에 책임과 기준을 명확히 부여하면, AI의 결과물은 막연한 “좋은 답변”이 아니라 조건을 만족해야 하는 산출물로 바뀝니다.
State와 검증 Node가 만드는 재시도 구조
각 Node가 작업을 마치면 그 결과는 State를 통해 다음 단계로 전달됩니다. 시장 조사 결과, 경쟁사 목록, 고객 Pain Point 같은 정보가 하나의 State에 쌓이고, 다음 Node는 이 정보를 바탕으로 종합 분석을 수행합니다. 이때 Graph Engineering의 강점은 단순히 정보를 모으는 데서 끝나지 않고, 검증 Node를 통해 조건 충족 여부를 확인할 수 있다는 점입니다.
검증 Node는 출처가 충분한지, 경쟁사 수가 조건을 만족하는지, 시장 규모 수치끼리 충돌하지 않는지, 고객 Pain Point가 실제 데이터에서 나온 것인지 확인합니다. 만약 조건을 만족한다면 다음 단계로 넘어가지만, 조건을 만족하지 못한다면 보고서를 억지로 완성하지 않고 필요한 Node로 되돌아갑니다. 경쟁사가 5개밖에 나오지 않았다면 경쟁사 조사 Node로 돌아가고, 시장 규모 출처가 부족하다면 시장 조사 Node로 돌아가는 식입니다.
07:49 - 검증 Node가 출처, 경쟁사 수, 시장 규모 수치 충돌, 고객 Pain Point 근거를 확인하는 구간
이 구조가 Loop Engineering과 Graph Engineering의 관계를 잘 보여줍니다. Graph 안의 특정 Node에서 Loop를 돌릴 수도 있고, 여러 Node와 Edge를 묶어 독립적인 Loop처럼 운영할 수도 있습니다. 따라서 Graph Engineering은 Loop Engineering을 대체한다기보다, 루프를 더 큰 작업 구조 안에 배치하고 조건부 경로와 병렬 처리를 함께 설계하는 상위 구조에 가깝습니다.
Human-in-the-loop: 사람이 개입해야 하는 순간을 설계하기
강연자는 Graph Engineering에서 사용자 승인 패턴을 특히 중요하게 다룹니다. 예를 들어 AI가 “한국 중소병원을 위한 AI 전화 상담 자동화 SaaS를 만드는 것이 가장 좋은 기회”라는 결론을 냈다고 가정합니다. 이 결론은 단순한 중간 계산이 아니라 제품 방향을 결정하는 중요한 판단이기 때문에, 바로 개발 단계로 넘어가기보다 그래프를 멈추고 사용자에게 승인 여부를 묻는 것이 적절합니다.
08:59 - 제품 방향 결정 전에 사용자 승인을 받는 Human-in-the-loop 패턴 설명
사용자가 승인하면 다음 Node로 넘어가고, 거절하면 다시 아이디어 생성 Node로 돌아갈 수 있습니다. 이 구조는 AI가 모든 결정을 자동으로 밀어붙이는 것을 막고, 중요한 비즈니스 판단이나 책임이 따르는 선택에는 사람이 개입할 수 있게 만듭니다. 강연자는 이를 Human-in-the-loop라고 설명하며, 사람이 할 영역과 AI가 능동적으로 할 영역을 나누는 지점으로 봅니다.
이 비유를 확장하면 단일 Agent는 유능한 직원 한 명에게 모든 업무를 맡기는 방식이고, Graph Engineering은 회사 전체의 조직도를 설계하는 방식입니다. 누가 시장 조사를 하고, 누가 경쟁사를 조사하며, 누가 결과를 검증하고, 어떤 상황에서 다시 일을 시키고, 어떤 결정은 대표가 직접 승인할지를 미리 구조화하는 것입니다. 이 때문에 Graph Engineering은 AI의 지능 자체보다 AI가 일하는 조직 구조를 설계하는 기술에 더 가깝습니다.
좋은 Graph는 AI를 덜 쓰는 곳도 설계한다
강연자가 강조하는 중요한 포인트는 Graph Engineering이 모든 것을 AI Agent로 만드는 작업이 아니라는 점입니다. 오히려 좋은 Graph는 AI가 필요하지 않은 곳에서는 AI를 쓰지 않습니다. 예를 들어 경쟁사가 10개 이상인지 확인하는 작업은 AI에게 물어볼 필요가 없고, 코드로 숫자를 세면 됩니다. 시장 규모 출처가 최소 3개 이상인지 확인하는 것도 마찬가지로 코드가 처리하는 편이 더 빠르고 저렴하며 안정적입니다.
10:28 - 명확한 조건은 코드가 처리하고 애매한 판단은 AI 또는 사람이 맡는 역할 분담 설명
반면 두 시장 중 어느 시장이 더 매력적인지 판단하는 문제는 정답이 명확하지 않습니다. 이 경우에는 AI가 여러 요소를 비교해 판단하거나, 더 중요한 사안이라면 사람에게 넘기는 편이 적절합니다. 결국 Graph Engineering은 AI, 코드, 사람의 역할을 구분하고 각각에게 맞는 책임을 배치하는 설계 작업입니다.
이 원칙은 비용과 품질 모두에 영향을 줍니다. 모든 검증을 AI에게 맡기면 토큰 비용이 늘어나고 결과의 일관성도 떨어질 수 있지만, 명확한 조건을 코드로 처리하면 예측 가능성과 효율이 높아집니다. 따라서 Graph Engineering의 성숙도는 얼마나 많은 Agent를 붙였는지가 아니라, 어떤 판단을 AI에게 맡기고 어떤 규칙을 코드로 고정하며 어떤 결정권을 사람에게 넘겼는지를 얼마나 잘 설계했는지로 평가해야 합니다.
언제 Graph Engineering이 필요한가
강연자는 모든 AI 앱을 Graph로 만들 필요는 없다고 선을 긋습니다. 간단한 요약, 단순 질의응답, 한두 번의 Tool Call로 끝나는 작업까지 굳이 Graph로 만들면 구조가 복잡해지고 디버깅 지점이 늘어나며 비용도 증가할 수 있습니다. 이는 AI 이전의 소프트웨어 개발에서도 마찬가지였던 Over-engineering 문제이며, AI 시대에도 동일하게 적용됩니다.
Graph Engineering이 진짜 필요한 순간은 작업 자체가 복잡할 때입니다. 여러 단계가 있고, 조건 분기가 필요하며, 병렬 처리가 유용하고, 실패했을 때 특정 단계로 돌아가야 하며, 중간에 사람이 개입해야 하고, 결과 검증이 필요한 업무라면 Graph 구조가 강력해집니다. 특히 이 모든 흐름을 Governance 관점에서 통제해야 하는 조직 환경에서는 단일 Agent나 단순 Loop만으로 관리하기 어려워집니다.
따라서 Graph Engineering은 복잡한 업무를 안정적으로 자동화하려는 단계에서 의미가 커집니다. 단순히 “AI에게 시킨다”가 아니라 “AI가 어떤 절차와 규칙 안에서 일하게 할 것인가”를 설계해야 하는 상황에서 필요합니다. 강연자는 앞으로 AI Agent가 실제 업무를 더 많이 맡게 될수록, 개별 Agent의 성능보다 Graph를 얼마나 잘 설계했는지가 시스템 품질을 좌우할 가능성이 높다고 전망합니다.
AI 시스템 품질을 결정하는 새로운 설계 역량
강연자는 Prompt Engineering, Context Engineering, Loop Engineering, Graph Engineering의 흐름을 하나의 자연스러운 진화로 봅니다. Prompt Engineering은 AI가 무슨 말을 듣는지를 설계했고, Context Engineering은 AI가 무엇을 알고 있는지를 설계했습니다. Loop Engineering은 AI가 어떻게 반복해서 행동하는지를 설계했으며, Graph Engineering은 여러 AI와 작업이 어떤 구조 안에서 함께 움직일지를 설계합니다.
이 변화는 AI가 발전했기 때문에 발생합니다. 모델은 계속 좋아지고, 프롬프트 역시 AI가 스스로 개선하는 Meta Prompting 방식으로 보완될 수 있습니다. Context 관리와 Loop 실행도 점점 더 자동화될 가능성이 큽니다. 하지만 어떤 작업을 나눌지, 어디서 병렬로 실행할지, 어디서 검증할지, 실패하면 어디로 돌아갈지, 어디서 사람에게 결정권을 넘길지는 여전히 설계가 필요한 문제입니다.
물론 이 구조를 사람이 처음부터 전부 손으로 설계해야 하는 것은 아닙니다. 강연자는 Meta Prompting이나 Dynamic Workflow처럼 AI와 함께 Graph를 설계하는 것도 충분히 가능하다고 봅니다. 다만 중요한 것은 사고의 중심이 “AI에게 좋은 답을 하게 만드는 것”에서 “AI가 좋은 방식으로 일하게 만드는 것”으로 이동하고 있다는 점입니다. Graph Engineering은 바로 이 전환을 설명하는 이름입니다.
마무리 / 핵심 정리
이 영상의 핵심 메시지는 Graph Engineering이 새로운 유행어처럼 보일 수 있지만, 실제로는 복잡한 AI 업무를 구조화하기 위한 자연스러운 설계 방식이라는 점입니다. Prompt Engineering이 입력 문장을 다듬는 기술이었다면, Graph Engineering은 작업의 순서, 분기, 병렬성, 검증, 재시도, 사람의 개입 지점을 설계하는 기술입니다. 이는 AI가 더 많은 실제 업무를 맡게 될수록 더욱 중요해질 가능성이 큽니다.
강연자는 Graph Engineering을 AI를 더 똑똑하게 만드는 기술이라기보다, 똑똑한 AI가 실수하지 않도록 일하는 구조를 설계하는 기술로 봅니다. 이 관점은 실무적으로 중요합니다. 좋은 AI 시스템은 모든 것을 AI에게 맡기는 시스템이 아니라, 코드가 잘할 수 있는 일은 코드가 처리하고, AI가 잘할 수 있는 판단은 AI가 맡으며, 책임 있는 결정은 사람이 개입하는 구조를 갖추기 때문입니다.
결국 앞으로의 AI 시스템 설계자는 프롬프트를 잘 쓰는 사람을 넘어, 작업 흐름을 잘 나누고 연결하며 검증 가능한 구조로 만드는 사람에 가까워질 것입니다. Graph Engineering은 그 방향성을 설명하는 개념이며, 이미 많은 Dynamic Workflow와 Agent 기반 자동화에서 실질적으로 사용되고 있는 패턴이기도 합니다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 또다른 트렌드 Graph Engineering 알려드림 |
| 채널 | 코드팩토리 |
| 리포트 작성 | 2026-08-08 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.