한 줄 요약
그래프 엔지니어링을 노드·엣지·스테이트·컨디션이라는 네 부품으로 뜯어 설명하고, 시장 조사 과제 하나를 단일 에이전트로 시킬 때와 그래프로 짤 때로 나란히 돌려 차이를 보여 준다.
핵심 내용
- 네 부품 — 노드는 작업, 엣지는 다음 작업으로 가는 길, 스테이트는 작업 사이에 전달되는 정보, 컨디션은 어느 길로 갈지 정하는 규칙이다. 이 넷을 설계하는 것이 그래프 엔지니어링이다.
- 핵심 원칙 한 줄 — 애매한 판단은 AI나 사람이 하고, 명확한 규칙은 코드가 처리한다. 그 둘을 적절히 섞는 작업까지가 그래프 엔지니어링에 포함된다.
- 패턴 4종 — 라우터(조건에 따라 적합한 에이전트로 전달), 병렬 실행, 생성자–평가자, 사용자 승인. 하나만 쓰는 게 아니라 섞어 쓴다.
- 이미 쓰고 있었다 — 다이나믹 워크플로우가 계획 → 병렬 리서치 → 병렬 작업 → 취합 검증으로 도는 것 자체가 노드와 엣지로 이어져 스테이트를 주고받는 구조다. 대부분 알게 모르게 이미 그래프를 쓰고 있었다는 것이다.
- 좋은 그래프는 AI를 덜 쓴다 — "경쟁사가 10개 이상인가", "출처가 3개 이상인가" 같은 판정은 모델에게 물어볼 게 아니라 코드로 세면 된다. AI가 필요 없는 자리에서 AI를 쓰지 않아야 비용과 효율이 함께 잡힌다.
- 오버 엔지니어링 경고 — 간단한 요약이나 툴 콜 한두 번으로 끝날 일까지 그래프로 만들 필요는 없다. 구조가 복잡해지고 디버깅 지점이 늘고 토큰이 녹는다 (2026-08 기준).
- 네 단계의 설계 대상 — 프롬프트는 AI가 무슨 말을 듣는지, 컨텍스트는 무엇을 아는지, 루프는 어떻게 반복해서 행동하는지, 그래프는 여러 AI가 어떤 구조 안에서 함께 움직이는지를 설계한다.
주요 주장 / 데이터
- 단일 에이전트의 한계는 성능이 아니라 불투명함이다 — 시장 조사·경쟁사 분석·보고서 작성·검증을 한 번에 시키면 결과가 틀렸다는 사실만 알 수 있고, 계획이 틀렸는지 검색이 부족했는지 검증을 건너뛰었는지는 알 수 없다. 작업 전체가 하나의 거대한 블랙박스로 작동한다.
- 노드마다 책임을 못박는다 — 경쟁사 조사 노드에는 "최소 10개", 시장 조사 노드에는 "수치에 반드시 출처 포함", 고객 조사 노드에는 "실제 사용자 의견 최소 20개" 같은 규칙을 건다. 검증 노드가 이 조건들을 확인하고, 미달이면 해당 노드로 되돌아간다.
- 감이 아니라 정의된 경로 — "한 번 더 조사해야겠다"를 모델의 감에 맡기지 않고, 재시도 조건과 이동 경로를 그래프 자체에 명시해 둔다는 것이 핵심이라고 강조한다.
- 회사 비유 — 단일 에이전트가 유능한 직원 한 명에게 전부 맡기는 것이라면, 그래프 엔지니어링은 회사 전체를 설계하는 것이다. 누가 무엇을 하고, 누가 검증하고, 어떤 결정을 대표가 직접 승인할지를 미리 구조로 짜 둔다.
- 정의 — "AI를 더 똑똑하게 만드는 기술이라기보다, 똑똑한 AI가 실수하지 않도록 일하는 구조를 설계하는 기술"이라고 정리한다.
- 전망 — 에이전트가 더 복잡한 실무를 맡을수록 개별 에이전트의 성능보다 그래프를 얼마나 잘 설계했느냐가 중요해질 가능성이 높다고 본다. 다만 그때가 되면 또 다른 버즈워드가 나올 것이라는 단서를 함께 단다.
- AI와 함께 설계해도 된다 — 그래프 구조를 사람이 처음부터 다 짜야 하는 건 아니다. 메타프롬프팅이나 다이나믹 워크플로우처럼 AI와 같이 설계하는 방식도 가능하다고 본다.
출처 정보
- URL: https://www.youtube.com/watch?v=SBLDc4R1d_E
- 채널: 코드팩토리 (2026-08-09 oEmbed 조회로 확인)
- 수집일: 2026-08-09
- transcript_lang: ko (자동생성 자막 — 오탈자·오인식 주의. "이게프 엔지니어링"·"그래픽 엔지니어링"·"휴먼드"는 각각 그래프 엔지니어링·휴먼 인 더 루프의 오인식으로 읽었다)