Graph & Loop Engineering — 한 프롬프트를 키우지 말고 분기·검사·반복하라
Google의 무료 2시간 강의는 하나의 프롬프트에서 에이전트 그래프, 100개 에이전트 병렬 fan-out, 제어 루프, 자기개선 워크플로까지 이어집니다. 지속되는 기법은 '에이전트를 더 많이'가 아니라 **분기·검사·재시도·재구성을 런타임 제어 흐름으로 명시하는 것**입니다.
이 페이지는 카드에 적힌 내용을 펼쳐 보여줄 뿐입니다 — 돌아가는 코드도, 열어볼 데모도 아직 없습니다. 무엇을 왜 만들려는지가 아래에 있습니다.
강의를 다섯 체크포인트로 따라가되, '100개 에이전트' 헤드라인을 복제하지 말고 작은 그래프 하나를 출하합니다: 0:35 처음부터 그래프 엔지니어링, 31:17 첫 에이전트 그래프, 43:40 수백 에이전트 병렬 실행, 1:04:58 루프 엔지니어링(route, check, repeat), 1:30:09 자기개선 그래프. planner → worker → checker 세 노드로 만들고, 타입이 있는 handoff 하나, 횟수가 제한된 재시도 하나, 기록되는 실패 이유 하나를 둡니다. checker가 나쁜 결과를 거부하고 merge 단계가 충돌한 결과를 조정할 수 있게 된 뒤에만 병렬 fan-out을 추가합니다. 노트에 강의 링크가 없으므로, 인용 자료로 쓰기 전 Google 공식 출처 링크를 붙여 확인합니다.
기술 노트
각 항목이 실제로 무엇을 보여주고 어떻게 동작하는지 — 위 카드보다 자세한 기술 설명입니다.
목적: 대부분의 에이전트 시스템은 오케스트레이션을 산문으로 만들어 실패합니다. 프롬프트 하나에 계획·실행·검증·복구·종료 판단을 모두 시킵니다. 지시를 더할 때마다 같은 컨텍스트와 같은 실패 표면을 공유하므로, 계획의 오류가 조용히 검증의 전제가 될 수 있습니다. 그래프는 이 책임들을 명시적인 edge와 state를 가진 별도 노드로 나누고, 루프는 실패를 '주의해서 확인해'라는 문장 하나가 아니라 **상태 전이**로 만듭니다. 둘의 차이가 중요합니다. 그래프는 **다음 작업이 어디로 가는가?**에 답하고, 루프는 **어떤 증거가 진행을 허용하며, 증거가 실패하면 무슨 일이 일어나는가?**에 답합니다. 병렬 실행은 fan-out과 fan-in이라는 그래프 모양일 뿐입니다. checker와 merge 정책을 정의하기 전에 에이전트 수부터 늘리면 의견 불일치·비용·상관된 오류가 함께 늘어납니다. 100개 에이전트는 작업이 충분히 독립적이고 결과를 결정론적으로 또는 좁은 규칙으로 합칠 수 있을 때만 쓸모가 있습니다. 자기개선도 좁게 읽어야 합니다. 안전한 버전은 워크플로가 경계 없이 자신을 다시 쓰게 하지 않습니다. 실패를 기록하고, 그래프 변경안을 만들고, 고정된 하네스로 후보를 평가한 뒤, 게이트를 통과한 것만 승격합니다. 즉 개선 루프는 **graph → run → trace → evaluate → propose → gated replacement**입니다. 평가기와 예산은 개선 대상 그래프 바깥에 남습니다 — 에이전트의 지출 상한이 에이전트 바깥에 있어야 하는 것과 같습니다. 거대한 프롬프트 하나보다 나은 진짜 이유는 구호로서의 자율성이 아니라 **관찰 가능한 제어 흐름과 제한된 실패**입니다.
동작 방식: ### 강의 지도 | 진행률 | 타임스탬프 | 단계 | |---|---:|---| | **0%** | **0:35** | 처음부터 Graph engineering | | **30%** | **31:17** | 첫 에이전트 그래프 만들기 | | **45%** | **43:40** | 수백 에이전트 병렬 실행 | | **75%** | **1:04:58** | Loop engineering: route, check, repeat | | **100%** | **1:30:09** | 자는 동안 작동하는 자기개선 그래프 | ### 최소로 쓸모 있는 그래프 ```text 요청 → planner → worker → checker ──통과──→ 결과 ↑ │ └─재시도──┘ (횟수 제한) ``` 각 edge는 타입이 있는 상태를 전달합니다. checker는 `pass` 또는 구조화된 실패 이유를 반환하고, 재시도 edge에는 시도 횟수와 비용의 단단한 상한이 있습니다. 최종 실패는 무한 루프가 아니라 예상된 상태입니다. ### 제어면을 만든 뒤에만 확장 | 추가 요소 | 먼저 필요한 통제 | 없으면 | |---|---|---| | **병렬 fan-out** | 독립적인 작업 경계 | 중복되거나 충돌하는 작업 | | **Fan-in** | 병합·충돌 정책 | 한 에이전트가 다른 결과를 조용히 덮어씀 | | **재시도 루프** | 종료 조건 + 시도/비용 예산 | 무한 지출 | | **동적 라우팅** | 타입이 있는 분기 이유 + trace | 모습을 바꾼 불투명 프롬프트 | | **자기개선** | 고정 평가기 + 승격 게이트 + 롤백 | 그래프가 자기 숙제를 자기가 채점 | ### 런타임 규칙 복구를 한 에이전트 프롬프트의 문단 하나로 넣지 않습니다. 추적·계수·제한·테스트할 수 있는 edge로 만듭니다: **route → check → repeat 또는 rebuild**. 관련: `the-harness-not-the-model`(결정론적 제어 계층), `agentic-intent-veto`(경계는 에이전트 바깥에 둠).