또다른 트렌드 Graph Engineering 알려드림

URL: https://www.youtube.com/watch?v=SBLDc4R1d_E 날짜: 2026-08-08 채널: 코드팩토리

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

AI 시대 엔지니어링 방법론이 어떻게 진화하고 있는가? 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 루프 엔지니어링을 거쳐, 이제는 **그래프 엔지니어링(Graph Engineering)**이 새로운 패러다임으로 떠오르고 있다. 하나의 AI를 더 똑똑하게 만드는 것이 아니라, 여러 AI와 코드, 사람을 하나의 그래프 구조로 설계해 실수를 줄이고 통제 가능한 시스템을 만드는 방법이 핵심이다.

• 프롬프트 엔지니어링: AI가 무슨 말을 듣는지 설계
• 컨텍스트 엔지니어링: AI가 무엇을 알고 있는지 설계
• 루프 엔지니어링: AI가 어떻게 반복하는지 설계
• 그래프 엔지니어링: 여러 AI가 어떤 구조 안에서 함께 움직이는지 설계

---

1. AI 엔지니어링의 4단계 진화

1.1. 프롬프트 엔지니어링(Prompt Engineering)

1. AI 초기에는 "어떤 말을 해야 더 좋은 답을 얻을 수 있는가"가 가장 중요했다.
2. 단일 프롬프트의 문법과 형식을 다듬는 것에 집중.
3. 모델이 무엇을 하는지를 설계하는 1세대 방법론.

1.2. 컨텍스트 엔지니어링(Context Engineering)

1. 프롬프트 한 줄보다는 모델에게 어떤 정보, 기억, 도구를 제공하는지가 중요해졌다.
2. RAG(Retrieval-Augmented Generation), 메모리, 툴 사용이 핵심.
3. AI가 무엇을 알고 있는지 설계하는 2세대 방법론.

1.3. 루프 엔지니어링(Loop Engineering)

1. AI 에이전트가 등장하면서 AI가 계획→실행→확인→수정을 반복하는 구조에 집중.
2. 비교적 최근의 트렌드로, 반복적인 자기개선 구조를 설계.
3. AI가 어떻게 반복해서 행동하는지 설계하는 3세대 방법론.

1.4. 그래프 엔지니어링(Graph Engineering)

1. 하나의 AI를 더 똑똑하게 만드는 것만으로는 부족해졌다.
2. 어떤 AI가 먼저 움직일지, 어떤 작업을 동시에 처리할지, 실패하면 어디로 돌아갈지, 어떤 순간에 사람이 개입할지를 하나의 구조로 설계.
3. AI가 움직이는 길을 그래프로 설계하는 4세대 방법론.
4. 프롬프트 → 컨텍스트 → 루프 → 그래프로 자연스럽게 상위 호환된다.

---

2. 그래프 엔지니어링의 핵심 개념

2.1. 4가지 구성 요소

1. 노드(Node): 작업(Task)을 의미한다.
   • 예: 시장 조사, 경쟁사 조사, 고객 조사, 검증, 사용자 승인
2. 엣지(Edge): 다음 작업으로 이동하는 길(Path)을 의미한다.
   • 노드 간의 연결과 흐름을 표현.
3. 스테이트(State): 작업 사이에서 전달되는 정보를 의미한다.
   • 예: 시장 조사 결과, 경쟁사 목록, 고객 페인포인트
4. 컨디션(Condition): 어느 길로 갈지 결정하는 규칙.
   • 예: 경쟁사가 10개 이상인가?, 시장 규모 출처가 3개 이상인가?

2.2. 기존 개발자에게 익숙한 구조

1. 그래프는 노드와 엣지로 연결된 시스템을 의미.
2. 다이나믹 워크플로우(Dynamic Workflow)를 이미 사용한 개발자라면 쉽게 이해할 수 있다.
3. 계획 → 병렬 리서치 → 병렬 작업 → 검증 → 취합의 흐름이 노드와 엣지, 스테이트로 구성된 그래프라는 관점.
4. 즉, 많은 개발자가 이미 알게 모르게 그래프 엔지니어링을 사용하고 있었다.

---

3. 단일 에이전트의 한계

3.1. 블랙박스 문제

1. 단일 AI에게 시장 조사, 경쟁사 분석, 보고서 작성, 검증까지 전부 맡기면 모든 책임이 하나의 모델 안에 들어간다.
2. 결과가 틀렸을 때 어디서 잘못됐는지 알기 어렵다.
   • 계획을 잘못 세웠는가?
   • 검색을 잘못했는가?
   • 정보를 잘못 해석했는가?
   • 검증을 건너뛰었는가?
3. 최종 결과가 틀렸다는 사실만 알 수 있고, 내부 과정을 통제하기 어렵다.
4. 작업 전체가 하나의 거대한 블랙박스처럼 작동한다.

3.2. 복잡한 작업에서의 부적합

1. 단순한 질의응답이나 한두 번의 툴콜로 끝나는 작업에는 단일 에이전트가 적합.
2. 하지만 복잡한 시장 조사, 제안서 작성, 다단계 검증이 필요한 업무에서는 한계가 명확.
3. AI가 모든 판단을 내부적으로 하므로, 사람이 중간에 개입하거나 품질을 통제하기 어렵다.

---

4. 그래프 엔지니어링의 4가지 대표 패턴

4.1. 라우터 패턴(Router Pattern)

1. 조건에 따라 적합한 에이전트에게 액션을 전달하는 방식.
2. 예: 요청 유형(기술 질문 / 영업 질문 / 지원 요청)에 따라 서로 다른 노드로 라우팅.
3. 코드 기반의 명확한 분기 규칙과 AI 기반의 애매한 판단을 조합.

4.2. 병렬 실행 패턴(Parallel Execution)

1. 하나의 요청이 들어오면 여러 하위 작업을 동시에 실행.
2. 예: 시장 조사, 경쟁사 조사, 고객 조사를 동시에 진행하고 결과를 취합.
3. 단순히 빨라지는 것뿐 아니라, 각 노드의 책임과 결과가 명확해진다.
4. Dynamic Workflow에서 자주 사용하는 패턴.

4.3. 생성자-평가자 패턴(Generator-Evaluator / Critic Loop)

1. 작업 에이전트가 결과물을 만들면, 평가 에이전트가 확인하고 수정을 진행.
2. 일종의 루프 엔지니어링을 그래프 안에 내재화한 형태.
3. 예: 보고서 작성 노드 → 품질 검증 노드 → 부족하면 다시 작성 노드로 회귀.
4. AI가 스스로 검증하는 구조를 코드로 명확히 설계.

4.4. 사용자 승인 패턴(Human-in-the-Loop / Human Approval)

1. 그래프 엔지니어링에서 가장 중요한 요소 중 하나.
2. 사람이 작업할 영역과 AI가 능동적으로 할 영역을 효율적으로 나누는 지점.
3. 예: AI가 제품 기획 방향을 제안하면, 그래프를 멈추고 사용자에게 "이 방향으로 진행할까요?"라고 묻는다.
4. 사용자가 승인하면 다음 노드로, 거절하면 다시 아이디어 생성 노드로 돌아간다.
5. 중요한 결정권은 사람에게 넘기고, 반복적 실행은 AI에게 맡긴다.

---

5. 실제 사례: AI 자동화 SaaS 시장 조사

5.1. 단일 에이전트 방식의 문제

1. "한국에서 AI 자동화 SaaS를 만들려고 하는데 시장 규모, 주요 경쟁자, 고객 페인포인트를 조사하고 어떤 제품을 만들어야 하는지 제안해줘"라고 하나의 에이전트에게 요청.
2. 겉으로는 잘하는 것처럼 보이지만, 내부적으로 무슨 일이 일어났는지 통제하기 어렵다.
3. 시장 조사를 충분히 했는지, 경쟁사를 몇 개나 조사했는지, 어떤 기준으로 충분하다고 판단했는지, 틀린 정보를 그냥 넘어갔는지 알 수 없다.

5.2. 그래프 엔지니어링 방식

1. 요청 분석 노드: 사용자 요청을 분석.
2. 계획 노드: 작업을 몇 개의 하위 작업으로 나눌지 계획.
3. 병렬 조사 노드:
   • 시장 조사 노드: 시장 규모 수치에 반드시 출처 포함.
   • 경쟁사 조사 노드: 최소 10개의 경쟁사 조사.
   • 고객 조사 노드: 최소 20개의 실제 사용자 의견 수집.
4. 스테이트 전달: 시장 조사 결과, 경쟁사 목록, 고객 페인포인트를 하나의 스테이트에 쌓는다.
5. 검증 노드: 결과를 확인.
   • 출처가 충분한가?
   • 경쟁사 수가 조건을 만족하는가?
   • 시장 규모 수치끼리 충돌하지 않는가?
   • 고객 페인포인트가 실제 데이터에서 나온 것인가?
6. 조건부 회귀: 조건을 만족하지 못하면 해당 노드로 다시 돌아간다.
   • 경쟁사가 5개밖에 안 나왔다 → 경쟁사 조사 노드로 회귀.
   • 시장 규모 출처가 부족하면 → 시장 조사 노드로 회귀.
7. 사용자 승인: "한국 중소 병원을 위한 AI 전화 상담 자동화 SaaS를 만드는 것이 가장 좋은 기회입니다. 이 방향으로 제품 기획을 진행할까요?"
   • 승인 → 개발/기획 다음 노드로.
   • 거절 → 아이디어 생성 노드로 회귀.

5.3. 얻을 수 있는 효과

1. 각 노드의 책임이 명확해진다.
2. 중간 결과를 독립적으로 확인할 수 있다.
3. 조건에 따라 실패 지점으로 회귀하는 경로가 코드로 정의된다.
4. 사람의 승인이 필요한 지점을 명확히 설계할 수 있다.
5. 단순히 빨라지는 것이 아니라 통제 가능하고 검증 가능한 시스템이 된다.

---

6. AI vs 코드 vs 사람: 적절한 역할 분배

6.1. AI가 필요하지 않은 곳에는 코드를 쓴다

1. 좋은 그래프는 AI가 필요하지 않은 곳에서는 AI를 쓰지 않는다.
2. 예: 경쟁사가 10개 이상인가? → 코드로 숫자 세면 된다.
3. 예: 시장 규모 출처가 3개 이상인가? → 코드로 확인하면 된다.
4. 명확한 규칙은 코드가 처리하는 것이 비용도 아끼고 효율도 높다.

6.2. 애매한 판단은 AI나 사람이 한다

1. "두 시장 중 어떤 시장이 더 매력적인가?" → 정답이 명확하지 않으므로 AI에게 맡긴다.
2. 최종 제품 방향 결정 → 중요한 결정이므로 사람에게 넘긴다.
3. 그래프 엔지니어링은 명확한 규칙(코드)과 애매한 판단(AI/사람)을 적절히 섞는 기술.

6.3. 회사 설계에 비유

1. 단일 에이전트: 유능한 직원 한 명에게 모든 업무를 맡기는 것.
2. 그래프 엔지니어링: 회사 전체를 설계하는 것.
   • 누가 시장 조사를 하고,
   • 누가 경쟁사를 조사하고,
   • 누가 결과를 검증하고,
   • 어떤 상황에서 다시 일을 시키고,
   • 어떤 결정은 대표가 직접 승인할지를 미리 구조화.
3. AI를 더 똑똑하게 만드는 기술이 아니라, 똑똑한 AI가 실수하지 않도록 일하는 구조를 설계하는 기술.

---

7. 그래프 엔지니어링을 써야 할 때와 쓰지 말아야 할 때

7.1. 써야 할 때

1. 작업 자체가 복잡할 때.
2. 복잡한 구조를 설계하고 그 패턴을 만들어놓고 싶을 때.
3. 여러 단계가 있고, 조건 분기가 필요할 때.
4. 병렬 처리가 필요할 때.
5. 실패했을 때 다시 돌아가야 할 때.
6. 중간에 사람이 개입해야 할 때.
7. 결과를 검증해야 할 때.
8. 거버넌스를 통해 통제해야 할 때.

7.2. 쓰지 말아야 할 때

1. 간단한 질의응답.
2. 간단한 질문-답변 한두 번의 툴콜로 끝날 수 있는 작업.
3. 작업이 단순해서 그래프 구조가 오히려 복잡도만 높이는 경우.
4. 오버엔지니어링의 위험.
   • 구조가 복잡해지고,
   • 디버깅해야 할 지점이 늘어나고,
   • 비용도 더 들어갈 수 있다.
5. Dynamic Workflow를 써보면 토큰이 막 녹는 것을 경험할 수 있다.

---

8. 미래 전망: 구조 설계자의 시대

8.1. 모델 성능 vs 구조 설계

1. 앞으로 AI 에이전트가 더 복잡한 실제 업무를 맡기 시작하면, 개별 에이전트의 성능보다는 그래프를 얼마나 잘 설계했느냐가 더 중요해질 가능성이 높다.
2. 모델은 계속 좋아질 것이고, 프롬프트도 AI가 알아서 잘 만들어줄 것이며, 컨텍스트와 루프도 더 똑똑해질 것이다.
3. 하지만 여전히 누군가가 결정해야 할 것들이 있다.
   • 어떤 작업을 나눌지
   • 어디서 병렬로 실행할지
   • 어디서 검증할지
   • 실패하면 어디로 돌아갈지
   • 어디서 사람에게 결정권을 넘길지
4. 이런 구조를 설계하는 사람이 AI 시스템의 품질을 결정하게 될 것이다.

8.2. AI와 함께 설계하기

1. 그래프 구조를 사람이 처음부터 모두 설계할 필요는 없다.
2. 메타프롬프팅처럼 AI와 함께 다이나믹 워크플로우를 설계하는 것도 충분히 가능.
3. AI가 제안하는 구조를 바탕으로 사람이 검증하고 수정하는 방식.

---

9. 핵심 요약 (20줄)

1. AI 엔지니어링은 프롬프트 → 컨텍스트 → 루프 → 그래프로 진화하고 있으며, 그래프 엔지니어링이 새로운 패러다임으로 떠오르고 있다.
2. 그래프 엔지니어링은 하나의 AI를 더 똑똑하게 만드는 것이 아니라, 여러 AI와 코드, 사람이 함께 움직이는 구조를 설계하는 방법이다.
3. 핵심 구성 요소는 노드(작업), 엣지(이동 경로), 스테이트(전달 정보), 컨디션(분기 규칙)이다.
4. 단일 에이전트는 시장 조사, 경쟁사 분석, 보고서 작성, 검증 등을 한 번에 맡기면 블랙박스처럼 작동해 어디서 잘못됐는지 알기 어렵다.
5. 그래프 엔지니어링은 작업을 여러 노드로 나누고, 각 노드의 책임을 명확히 하며, 중간 결과를 독립적으로 확인할 수 있게 한다.
6. 라우터 패턴은 조건에 따라 적합한 에이전트에게 액션을 전달하는 방식이다.
7. 병렬 실행 패턴은 시장 조사, 경쟁사 조사, 고객 조사를 동시에 진행하고 결과를 취합한다.
8. 생성자-평가자 패턴은 작업 에이전트가 만들고 평가 에이전트가 확인한 뒤, 필요하면 다시 작성 노드로 회귀한다.
9. 사용자 승인 패턴은 중요한 결정 지점에서 그래프를 멈추고 사람의 선택을 받는다.
10. 단일 에이전트 방식으로 한국 AI 자동화 SaaS 시장 조사를 시키면 내부 과정을 통제하기 어렵다.
11. 그래프 방식에서는 요청 분석 → 계획 → 병렬 조사 → 스테이트 취합 → 검증 → 조건부 회귀 → 사용자 승인의 흐름으로 작업을 설계한다.
12. 각 노드에 명확한 규칙을 줄 수 있다. 예: 경쟁사 조사 노드는 최소 10개, 시장 조사 노드는 출처 포함, 고객 조사 노드는 최소 20개 의견.
13. 검증 노드에서 조건을 만족하지 못하면 해당 조사 노드로 다시 돌아가도록 경로를 설계한다.
14. AI가 필요하지 않은 곳에서는 코드를 사용해야 비용과 효율 측면에서 유리하다.
15. 경쟁사가 10개 이상인지, 출처가 3개 이상인지 같은 명확한 규칙은 코드로 처리하는 것이 좋다.
16. "두 시장 중 어떤 시장이 더 매력적인가"처럼 정답이 명확하지 않은 판단은 AI나 사람에게 맡기는 것이 적절하다.
17. 그래프 엔지니어링은 회사 전체를 설계하는 것과 같다. 누가 무엇을 하고, 어떤 상황에서 다시 일을 시키고, 어떤 결정은 대표가 승인할지를 구조화한다.
18. 단순한 질의응답이나 한두 번의 툴콜로 끝나는 작업까지 굳이 그래프로 만들 필요는 없다. 오버엔지니어링은 피해야 한다.
19. 앞으로 개별 에이전트 성능보다 그래프를 얼마나 잘 설계했느냐가 AI 시스템의 품질을 결정할 가능성이 높다.
20. AI가 좋은 답을 하게 하는 시대에서 이제는 AI가 좋은 방식으로 일하게 만드는 시대로 넘어가고 있으며, 그 설계 방법이 그래프 엔지니어링이다.