Peter의 지속형 Claude Code 작업 그래프

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Peter는 Claude Code의 자율 빌드를 역할 그래프와 지속형 작업 그래프로 분리해 구현·품질 게이트·감사·수리를 관리하는 MIT-licensed skill입니다. 공개 실행에서 테스트 33/33과 E2E 검사 9/9를 통과하고 수동 개입 없이 완료했으며, 감사 결과 네 건은 생성 fixture에 남겼습니다. ESON은 다섯 문서 인수인계 코퍼스를 compact JSON보다 28% 적은 토큰으로 처리했고, Honey 벤치마크에서는 출력 29%와 LOC 43% 감소가 관찰됐지만 총비용 절감은 통계적으로 유의하지 않았습니다. 통제 실행 부재와 대규모 JSONL·감사자 독립성 문제 때문에 end-to-end 비용 절감은 아직 입증되지 않았습니다.

합의점 vs 논쟁점

논쟁점

그래프를 역할과 작업 상태로 분리하는 설계가 복잡한 multi-agent workflow에서도 유지될지는 아직 검증되지 않았습니다. 특히 수리 단계가 여러 번 반복되면 감사자가 독립적인 평가자 역할을 계속 유지할 수 있는지가 쟁점입니다. 작업 수가 커질 때 JSONL의 저장 구조와 역할 그래프·작업 그래프의 분리 역시 의견이 갈릴 수 있는 부분입니다.

실용적 조언

durable multi-agent workflow를 평가할 때는 구현 결과만 보지 말고 의존성, 근거, 커밋, 종료 상태를 지속적으로 기록하는지 함께 확인해야 합니다. 감사자가 평가 대상 코드를 수정하지 못하게 권한을 분리하면 수리 과정과 품질 판정의 책임을 구분할 수 있습니다. 토큰이나 비용 절감률을 보고할 때는 Honey·ESON을 사용하지 않은 통제 실행과 함께 비교해야 하며, 통계적 유의성이 없는 총비용 수치는 확정적인 절감으로 해석하지 않아야 합니다.

섹션별 상세

Peter Steinberger가 에이전트 빌더에게 루프와 그래프 중 무엇을 사용하는지 물었지만, 글 작성자는 질문의 의미를 단정하지 않고 설계 프롬프트로 해석했습니다. 그 결과물인 Peter는 GraphRAG나 지식 그래프가 아니라 에이전트 오케스트레이션과 작업 상태를 위한 그래프를 채택했습니다. 글은 graph engineering이라는 용어가 여러 개념을 가리키는 상황에서 이 구분이 설계 판단에 중요하다고 봅니다.

Peter는 역할 그래프와 작업 그래프를 분리합니다. 역할 그래프는 부모 오케스트레이터, 범위가 제한된 백엔드·프론트엔드 빌더, 독립 보안·UI 감사자로 권한을 나누며 감사자는 평가 대상 코드를 수정하지 않습니다. 작업 그래프는 의존성·상태·근거·커밋을 JSONL로 보존하고, 각 노드 안에서 구현 → 게이트 → 감사 → 수리 순서를 실행해 컨텍스트 변경과 명시적 종료 상태를 처리합니다.

공개 실행에서는 테스트 33/33, E2E 검사 9/9를 통과했고 수동 개입 없이 완료됐습니다. 생성된 fixture에는 차단하지 않는 감사 결과 네 건을 의도적으로 남겨 검증 결과를 숨기지 않았습니다. 토큰 구성요소를 따로 측정한 결과 ESON은 다섯 문서 인수인계 코퍼스를 3,151토큰으로 줄여 compact JSON의 4,395토큰보다 28% 적게 사용했고, Honey의 23개 작업·세 번 실행한 Opus 4.8 벤치마크에서는 출력이 29%, LOC가 43% 감소했지만 총비용 추정치는 통계적으로 유의하지 않았습니다.

글은 토큰 감소와 코드량 감소를 곧바로 전체 비용 절감으로 확대하지 않습니다. Honey와 ESON을 사용하지 않은 통제 실행이 없기 때문에 Peter의 end-to-end 비용 절감은 입증됐다고 말하지 않으며, 더 큰 작업 수에서 JSONL이 충분한지와 복잡한 수리 순환에서도 감사자 독립성이 유지되는지를 열린 문제로 남깁니다. 역할 그래프와 작업 그래프를 계속 분리할지 역시 실제 durable multi-agent workflow에서 확인해야 할 설계 쟁점입니다.

용어 해설

역할 그래프(Role Graph): — 역할 그래프는 여러 에이전트의 책임과 권한을 연결하는 구조입니다. 이 구현에서는 부모 오케스트레이터가 백엔드·프론트엔드 빌더에게 범위를 나누고, 보안·UI 감사자는 독립적으로 결과를 검사합니다. 감사자는 자신이 평가하는 코드를 직접 수정할 수 없습니다.
작업 그래프(Work Graph): — 작업 그래프는 에이전트가 처리할 작업의 순서와 상태를 저장하는 구조입니다. Peter는 의존성·상태·근거·커밋을 JSONL 작업 항목에 기록하고, 노드 안에서 구현·품질 게이트·감사·수리를 이어 갑니다. 이를 통해 컨텍스트가 바뀌어도 작업 상태와 종료 조건을 유지합니다.
JSONL: — JSONL은 한 줄마다 하나의 JSON 객체를 저장하는 형식입니다. Peter에서는 작업별 의존성, 진행 상태, 검증 근거, 커밋 정보를 지속적으로 기록하는 데 사용됩니다. 글은 더 큰 작업 수에서도 이 형식이 충분한지 확인해야 한다는 과제를 남깁니다.
GraphRAG: — GraphRAG는 그래프 구조를 검색과 생성에 활용하는 접근법입니다. 이 글의 그래프는 외부 지식 검색이나 지식 그래프가 아니라 에이전트 오케스트레이션과 작업 상태 관리에 쓰입니다. 같은 graph engineering이라는 표현이 서로 다른 개념을 가리킬 수 있어 구분이 필요합니다.
E2E 검사(E2E checks): — E2E 검사는 시스템의 시작부터 최종 결과까지 전체 실행 흐름을 점검하는 테스트입니다. 공개 실행에서는 9/9 E2E checks가 통과했고, 별도로 33/33 테스트도 통과했습니다. 자동화된 빌드가 수동 개입 없이 끝났는지 확인하는 근거로 쓰였습니다.
ESON: — ESON은 에이전트 인수인계 문서를 더 적은 토큰으로 저장하기 위해 글에서 측정한 인코딩 구성요소입니다. 다섯 개 문서로 구성된 코퍼스를 3,151토큰으로 인코딩해 compact JSON의 4,395토큰보다 28% 줄였고, 손실 없는 왕복 변환과 29개 테스트 통과를 함께 기록했습니다.