아는 워크플로는 스웜이 아니라 그래프다
구글의 '그래프 엔지니어링'은 에이전트 시스템을 노드들의 조직도로 봅니다 — 일부는 LLM 에이전트, 일부는 결정론적 함수 — 명시적 엣지와 공유 상태로 엮인. 붙들 주장: **워크플로를 이미 알 때, 그것을 그래프로 고정하면** 단일 루프나 창발적 스웜이 포기하는 **예측 가능성·디버깅 가능성·통제**를 사옵니다. 팬아웃·조인·라우터는 각각 병렬화·배리어·switch 문이 새 이름을 쓴 것일 뿐입니다.
이 페이지는 카드에 적힌 내용을 펼쳐 보여줄 뿐입니다 — 돌아가는 코드도, 열어볼 데모도 아직 없습니다. 무엇을 왜 만들려는지가 아래에 있습니다.
아직 범위 미정 — 산출물은 만들기가 아니라 결정입니다. 실제로 돌리는 워크플로 하나(PR 리뷰, 다이제스트 분류)에 대해, 먼저 영상이 구분하는 세 범위를 분리하세요: *하네스*(한 에이전트의 환경 — 도구·메모리·가드레일), *루프*(그 에이전트가 목표 달성까지 추론 → 행동 → 관찰), *그래프*(공유 상태를 통해 에이전트·루프·결정론적 함수를 조율하는 다중 노드 오케스트레이션). 그다음 **경로를 얼마나 미리 아는지**로 형태를 고릅니다: 단순 반복 작업이면 단일 *루프*, 단계가 알려져 있고 예측 가능하길 원하면 *그래프*, 경로가 진짜로 열려 있을 때만 *스웜*. 출처: Google Cloud Tech, 'Graph Engineering 101'(youtube.com/watch?v=IrW0_f-w4kA) — 에이전트 대 함수 노드, ADK 공유 상태, 팬아웃/조인/라우터로 지은 PR 리뷰 파이프라인, 루프 대 그래프 대 스웜 트레이드오프 표. 타이밍·용어는 영상으로 확인.
기술 노트
각 항목이 실제로 무엇을 보여주고 어떻게 동작하는지 — 위 카드보다 자세한 기술 설명입니다.
목적: **세 범위가 모두 '에이전트'라 불리고, 헷갈리는 논쟁 대부분은 두 사람이 서로 다른 범위를 뜻하는 것입니다.** 셋은 중첩됩니다: *하네스*는 한 모델의 환경(도구·메모리·가드레일); *루프*는 그 하네스가 도는 것 — 추론·행동·관찰 — 목표 달성까지; *그래프*는 그런 루프 여럿에 결정론적 함수를 더해, 공유 상태로 하나의 워크플로로 엮은 것. '에이전트가 X를 하게 하라'는 어느 범위가 X를 소유하는지 말하기 전엔 모호합니다. 셋에 이름 붙이는 것이 가치의 대부분입니다. **그래프 엔지니어링은 평범한 컴퓨터과학 제어 흐름이고, 노드 일부가 LLM일 뿐입니다.** PR 리뷰 예가 구체화합니다: **팬아웃**은 병렬화(다섯을 차례로 대신 한 번에 — 지연 감소); **조인**은 배리어(가장 느린 가지를 기다렸다가 취합); **라우터**는 switch 문(종합 결과로 분기 — 실패 → fixer 에이전트, 통과 → 사람 승인). 새로운 건 없습니다; 새로운 건 노드가 **비결정론적 추론자**일 수 있다는 것뿐. 그래서 이 규율은 오래된 자료구조·제어흐름을, 더 이상 결정론적이지 않은 부분에 적용한 것입니다. **지식 그래프가 아니며, 같은 단어가 차이를 가립니다.** 지식 그래프는 *데이터 모델* — 엔티티·관계·검색(graph RAG). 그래프 엔지니어링은 *제어 흐름* — 무엇이, 어떤 순서로, 결과에 따라 어디로. 같은 명사, 직교하는 축: 하나는 시스템이 **아는 것**을, 다른 하나는 시스템이 **하는 것**을 기술합니다. **진짜 결정은 루프냐 그래프냐 스웜이냐이고, 이는 경로를 얼마나 이미 아는지에 대한 베팅입니다.** **스웜**(성격과 느슨한 지시를 가진 에이전트들이 고정 엣지 없이 협업)은 열린 문제에 유연성을 사옵니다 — 예측 가능성을 대가로. **그래프**는 가진 지식을 씁니다 — 모든 노드·엣지·전이를 사전 정의 — 예측 가능성·디버깅 가능성·책임 격리를 사려고. 흔한 실수는 워크플로가 사실 알려진 DAG인데 스웜에 손을 뻗는 것입니다: 포기할 필요 없던 결정성을 내주고, 그걸 되찾으려 창발 시스템을 디버깅합니다. 반대 실수는 진짜로 열린 문제에 경직된 그래프를 강요해, 갖지 않은 확실성을 가진 척하는 것. 이건 코딩 에이전트가 매일 하는 하네스/워크플로 선택 그대로입니다 — 서브에이전트 루프 하나냐, 조인과 라우터가 달린 팬아웃 워크플로냐 — 그래서 이 카드는 프레임워크가 아니라 결정 규칙입니다.
동작 방식: 데모가 아니라 정독 노트입니다. ### 사람들이 뭉뚱그리는 세 중첩 범위 | 범위 | 정체 | 소유하는 한 질문 | |---|---|---| | **하네스** | 한 모델의 환경: 도구·메모리·가드레일 | 이 에이전트가 무엇을 보고 할 수 있나? | | **루프** | 그 하네스가 도는 것: 추론 → 행동 → 관찰, 목표까지 | 이 에이전트는 다 됐나? | | **그래프** | 루프 여럿 + 결정론적 함수, 공유 상태로 | 다음에 무엇이, 어떤 순서로 도나? | ### PR 리뷰 패턴은 오래된 제어 흐름 | 패턴 | 고전 CS 이름 | 하는 일 | |---|---|---| | **팬아웃** | 병렬화 | 다섯 검사를 순차가 아니라 한 번에 — 지연 감소 | | **조인** | 배리어 | 가장 느린 가지를 기다렸다가 취합 + 종합 | | **라우터** | switch 문 | 결과로 분기: 실패 → fixer 에이전트, 통과 → 사람 머지 | ### 선택은 얼마나 아는지에 대한 베팅 | 형태 | 사전 정의? | 최적 상황 | 사는 것 | 포기하는 것 | |---|---|---|---|---| | **루프** | 에이전트 하나, 반복 | 단순·단일 목표 작업 | 단순함 | 다단계 구조 | | **그래프** | 모든 노드·엣지 | 워크플로를 미리 앎 | 예측·디버깅·통제 | 유연성 | | **스웜** | 성격·느슨한 규칙 | 경로가 열려 있음 | 탐색 | 결정성 | 실패 모드는 범주 오류입니다: **알려진 DAG에 스웜**(필요 없던 결정성을 버림) 또는 **열린 문제에 그래프**(갖지 않은 확실성을 꾸밈). 교차: `the-harness-not-the-model`(하네스는 여기서 가장 안쪽 범위 — 다시 짓지 말고 다스려라), `ai-engineering-is-framing-non-determinism`(그래프는 비결정성을 특정 노드에 고정하고 엣지를 결정론적으로 만든다), `agent-ask-not-write`(라우터의 실패 가지가 사람에게 묻는 자리), `cli-batch-vs-mcp-interactive`(그래프는 열린 대화보다 산출물을 남기는 배치 단계를 선호).