콘텐츠로 이동

Advisor–Worker vs 그래프 엔지니어링

질문

"Advisor–Worker에서 그래프 엔지니어링이 개선된 건가?" — 둘이 유사하게 느껴지는 것이 자연스럽습니다. 결론부터: 개선(후속 버전)이 아니라 축이 다른 관계이고, 유사하게 느껴지는 이유는 실제로 같은 DNA — "일을 역할로 쪼개고, 부탁 대신 구조로 통제한다" — 를 공유하기 때문입니다.

축이 어떻게 다른가

Advisor–Worker (concept-advisor-worker) 그래프 엔지니어링 (concept-graph-engineering)
답하는 질문 역할을 어떻게 나누나 (판단 vs 구현) 흐름을 어떻게 강제하나 (이동·복구·상한)
오케스트레이터 Advisor — LLM + 프롬프트 규율 코드 — 컨디션 함수·조건부 엣지
규칙이 사는 층 프롬프트 (해석의 여지 있음) 코드 (해석의 여지 없음)
규모 2역할, 태스크 단위 위임 N노드 — 병렬·라우터·복구·승인·재개
도입 비용 에이전트 정의 2개 + 규율 문구 스테이트 스키마 + 그래프 정의 (+ 프레임워크)

관계는 대체가 아니라 포함입니다: 그래프 관점에서 Advisor–Worker는 "2노드 + 검증 게이트(조건부 엣지)"의 최소 그래프 — 이미 그래프의 한 인스턴스입니다.

실질적인 차이는 딱 하나 — 규율 위반이 사후에 잡히나, 사전에 불가능하나

이 위키의 실측 사례가 정확히 그 지점을 보여줍니다.

Advisor–Worker (실측: 심화편 장면 1) 그래프 (실측: 실습 데모)
규칙 "한두 줄 수정은 직접 처리" 프롬프트 규율 if (테스트 기대값 변경) → worker 컨디션
위반 형태 Advisor가 2회 모두 직접 Edit — 규율을 "해석"해서 우회 위반 경로 자체가 없음 — report 노드에 도달 불가
교정 방식 규율 문구를 3차까지 고쳐서야 위임 재현 (사후 검증·교정) 교정할 일 없음 (사전 강제)
실측 출처 guide-advisor-worker-advanced 장면 1 (2026-07-12 검증) guide-graph-engineering-demo — 블랙박스 20회 중 13회 오답-완료 vs 그래프 0회 (2026-08-10 검증)

LLM이 규칙을 해석하는 한 어기는 경로가 항상 남습니다. 그래프는 그 규칙을 해석 불가능한 층(코드)으로 내립니다 — 이것이 두 패턴 사이의 유일한 공학적 델타입니다.

그 델타에는 비용이 있다

규칙이 코드로 내려가는 대신 스테이트 스키마·그래프 정의·(프로덕션이면) 프레임워크가 붙습니다. 그래서 선택 기준은:

상황 선택
판단·구현 분리로 끝나는 일상 위임 작업 Advisor–Worker — 더 가벼운 정답
프롬프트 규율 위반이 실제로 반복해서 아픈 상태 규칙만 코드 게이트로 승격 (부분 그래프화)
다단계 + 병렬 + 선택적 복구 + 중간 재개가 얽힘 그래프 — 최소 그래프(노드 2~3개)부터

concept-graph-engineering의 오버엔지니어링 경계가 그대로 적용됩니다: 규율 위반이 아프기 전까지는 가벼운 쪽이 정답입니다.

관련 페이지