초급

실행부터 메모리까지 완벽한 에이전트 하네스: gstack + 컴파운드 엔지니어링

계획, 실행, 검토, 지식 축적을 모두 아우르는 완벽한 에이전트 하네스로, gstack과 컴파운드 엔지니어링을 결합했습니다.

저는 이전에 두 가지 인기 있는 Claude Code 스킬과 그 사용법을 공유한 적이 있습니다: YC CEO @garrytan의 gstack (전체 팀 시뮬레이션: CEO 리뷰, 아키텍처 리뷰, 브라우저 QA, 주간 보고서 통계)과 Jesse Vincent의 Superpowers (표준화된 브레인스토밍 → 계획 → 실행 → 검토 워크플로우, 120k 스타, 사실상 Claude Code의 기본값).
하지만 이번 주에는 Superpowers를 대체하기 위해 컴파운드 엔지니어링(CE)을 사용하고 있습니다. 여러분도 한번 시도해 보시길 권장합니다.
왜 CE가 120k 스타의 Superpowers보다 더 낫다고 생각할까요? Anthropic 공식 블로그에서 제안한 하네스 아키텍처를 통해 이해할 수 있습니다. 이 프레임워크를 이해하면 비교가 명확해집니다.

Anthropic의 하네스 아키텍처#

Anthropic은 지난 11월과 지난주에 두 편의 엔지니어링 블로그 게시물을 게시하여 에이전트가 여러 컨텍스트 윈도우에서 지속적으로 작업할 수 있는 하네스 아키텍처를 제안했습니다. 핵심은 네 가지 역할로 구성됩니다:
  1. 플래너 에이전트: 큰 작업을 기능 목록으로 분해합니다.
  2. 코딩 에이전트: 한 번에 하나의 기능을 작업하고 구조화된 노트를 남깁니다.
  3. 평가자 에이전트: 독립적으로 검토합니다 (빌더가 자신의 작업을 평가하지 못하도록 함).
  4. 세션 간 브리징: 진행 파일을 사용하여 컨텍스트를 전달합니다.
지난주 두 번째 게시물에서는 생성자-평가자 분리를 도입했습니다. 에이전트가 자신의 작업을 평가하면 지나치게 낙관적인 경향이 있습니다. 실행자와 평가자를 두 개의 독립적인 에이전트로 분리하면 성능이 크게 향상되었습니다. Anthropic은 이 아키텍처를 사용하여 에이전트가 200개 이상의 검증 가능한 기능을 갖춘 완전한 claude.ai 클론을 자율적으로 개발하도록 했습니다.
이 프레임워크를 사용하여 gstack, Superpowers, CE를 살펴보면 명확한 차이점을 알 수 있습니다.

gstack: 플래너 + 브라우저 평가자#

gstack은 하네스에서 두 가지 핵심 역할을 올바르게 수행합니다.
/plan-ceo-review/plan-eng-review는 플래너 에이전트에 해당하며, 제품 및 아키텍처 관점에서 검토를 제공합니다. /qa는 브라우저를 열어 스테이징 URL을 실행하고 실제 사용자처럼 테스트하며, 이는 평가자 에이전트에 해당합니다. Anthropic의 논문에서는 에이전트가 "인간 사용자처럼" 테스트하도록 하는 것이 "성능을 극적으로 향상시켰다"고 명시적으로 밝히고 있습니다.
gstack의 철학은 "호수를 끓여라"입니다: AI 시대에는 완전한 버전을 만드는 한계 비용이 0에 가까워지므로 항상 전체 버전을 수행하라는 것입니다. 계획 + QA의 경우 여전히 최고입니다.
하지만 gstack은 주로 의사 결정 및 테스트 계층을 다룹니다. 구조화된 점진적 실행 워크플로우와 지식 축적 메커니즘이 부족합니다. 이것은 gstack의 결함이 아니라 포지셔닝 때문입니다. 전체 프로세스를 처리하는 것을 목표로 하지 않습니다.

Superpowers: 프로세스는 있지만 깊이는 부족#

Superpowers의 120k 스타는 이미 그 품질을 입증하고 있습니다. 브레인스토밍 → 계획 → 실행 → 검토 워크플로우는 많은 사람들이 "AI와 무작정 채팅하는 것"에서 "프로세스를 가지고 AI를 사용하는 것"으로 업그레이드하는 데 도움이 되었습니다. subagent-driven-development는 생성자-평가자 분리를 구현합니다: 독립적인 사양 검토자 + 코드 품질 검토자. 이것은 많은 스킬보다 낫습니다.
하지만 CE와 비교했을 때 깊이 차이는 세 가지 영역에서 나타납니다.
계획: Superpowers는 현재 컨텍스트에 직접 계획을 작성합니다. CE의 /ce:plan은 병렬로 리서치 에이전트를 생성하여 과거 경험을 검색하고, 코드베이스 패턴을 스캔하며, git 히스토리를 읽습니다. 계획은 현재 프롬프트뿐만 아니라 프로젝트 과거 지식을 기반으로 합니다.
검토: Superpowers에는 2명의 검토자(사양 + 품질)가 있습니다. CE는 6~15명의 전문 검토자를 병렬로 생성합니다: 정확성, 보안, 성능, 테스트, 유지보수성, 적대적(50줄 이상의 diff에서 트리거됨), 학습 연구자, 프로젝트 표준. 각각 독립적인 P0-P3 보고서를 생성합니다.
셋째, 가장 중요한 것은: Superpowers에는 지식 축적 메커니즘이 없습니다. 작업이 끝나면 끝입니다. 다음 세션은 처음부터 다시 시작합니다.
이 세 번째 요점이 제가 Superpowers를 대체한 진짜 이유입니다.

/ce:compound: Anthropic의 하네스 블로그에서도 해결하지 못한 문제, CE가 해결합니다#

Anthropic의 하네스는 세션 간 브리징을 위해 claude-progress.txt를 사용합니다: 세션 A가 작업을 마친 후 노트를 작성하고, 세션 B가 노트를 읽고 계속합니다. 선형적이며 인접한 두 세션에만 서비스를 제공합니다.
CE는 다르게 작동합니다.
기능을 완료하거나 버그를 수정한 후 /ce:compound를 실행합니다. 세 가지 에이전트를 병렬로 생성합니다:
  • 컨텍스트 분석기: 전체 세션 대화를 검토하여 문제 유형, 관련 구성 요소, 증상을 추출합니다.
  • 솔루션 추출기: 디버그 프로세스에서 작동하지 않은 것, 작동한 것, 근본 원인, 향후 방지 방법을 추출합니다.
  • 관련 문서 찾기: 기존 docs/solutions/에서 중복을 검색합니다. 매우 유사한 경우 새 문서를 생성하는 대신 기존 문서를 업데이트합니다.
세 에이전트가 실행된 후 오케스트레이터가 요약하여 구조화된 문서를 docs/solutions/에 작성합니다. 문서 구조는 대략 다음과 같습니다: 문제 (문제를 설명하는 한두 문장), 작동하지 않은 것 (문제 해결 중 시도했지만 작동하지 않은 것), 솔루션 (최종 수정 및 코드), 방지 (향후 방지 방법). 각 문서에는 YAML 프론트매터가 포함되어 있으며, 향후 검색을 쉽게 하기 위해 카테고리별 디렉토리에 저장됩니다.
이 문서는 향후 모든 /ce:plan 호출에서 학습 연구자가 검색합니다. "다음 세션"을 위한 것이 아니라 "모든 미래 세션"을 위한 것입니다.
예를 들어, 에지 런타임 호환성 버그를 수정하면 compound가 이를 기록합니다. 3주 후, 유사한 런타임 문제가 발생하는 다른 기능을 작업할 때 계획 단계 에이전트가 자동으로 해당 학습 내용을 가져와 이전에 발생한 함정과 솔루션을 직접 기록합니다.
Anthropic의 진행 파일은 메모입니다: 이전 교대에서 다음 교대로의 인계입니다.
CE의 docs/solutions/지식 베이스입니다: 모든 세션에서 액세스할 수 있는 프로젝트 메모리입니다.
메모는 연속성을 해결하고, 지식 베이스는 축적을 해결합니다. 하나는 선형적이고 다른 하나는 기하급수적입니다.
이것이 "컴파운드"의 의미입니다: 각 작업의 결과물은 코드뿐만 아니라 다음에 재사용할 수 있는 지식이기도 합니다. 더 많이 사용할수록 에이전트가 프로젝트를 더 잘 이해합니다.
이것이 우리가 논의해 온 "영구적인" 에이전트의 핵심이기도 합니다. "영구적인" 에이전트의 핵심은 24시간 내내 쉬지 않고 작업하는 것이 아니라, 지속적인 작업을 통해 지속적인 자기 개선과 자기 최적화를 달성하고, 반복적인 실수와 낭비를 피하며, 진정한 자기 개선을 달성하는 것입니다.

자동화에 관하여: 탐구할 가치가 있는 질문#

CE 소스 코드를 살펴보던 중 흥미로운 점을 발견했습니다. /lfg 전체 자동화 모드(한 번에 PR을 계획 중)에는 복합(compound) 단계가 포함되어 있지 않습니다. /ce:compound를 수동으로 실행해야 합니다.
왜 작성자는 복합을 자동화하지 않기로 선택했을까요? 저는 이 설계가 합리적이라고 생각합니다. 모든 세션이 복합할 가치가 있는 것은 아닙니다. 오타 수정, CSS 조정, 마이그레이션 실행 등은 새로운 지식을 생성하지 않습니다. 오직 함정을 실제로 디버깅하거나, 패턴을 발견하거나, 예상치 못한 문제를 경험한 세션만이 가치가 있습니다. 모든 세션을 자동으로 복합하면 노이즈가 발생하여 docs/solutions/에 가치가 낮은 문서가 넘쳐나고, 학습-리서처의 검색 품질이 저하됩니다.
하지만 사람들은 잊어버립니다. 이것은 실제 문제입니다.
제가 구축 중인 해결책은 복합 관리자(compound janitor)입니다. 매일 말일이 되면 자동으로 모든 세션의 git diff와 대화를 스캔하여 복합할 가치가 있는 세션을 판별하고, 선택한 후 배치로 실행합니다. 모든 세션을 복합하는 것이 아니라, 관리자 선별을 거친 가치 있는 세션만 복합합니다. 이는 메모리 관리에서 정기적인 검토 및 정리 메커니즘과 유사합니다. 이 기능은 CE에 PR로 기여할 가치가 있을 수 있습니다.

gstack + CE: 완전한 하네스#

Anthropic의 아키텍처에 매핑하면, gstack + CE가 모든 역할을 포괄합니다:
의사 결정 계층:
  • gstack /plan-ceo-review, 제품 관점에서 요구사항 분석
  • gstack /plan-eng-review, 아키텍처 방향 확정
계획 계층:
  • CE /ce:plan, 리서치 에이전트 생성, 과거 학습 내용 조회, 구조화된 계획 수립
실행 계층:
  • CE /ce:work, 계획에 따른 점진적 실행
검토 계층:
  • CE /ce:review, 6-15명의 전문 리뷰어가 병렬로 검토
  • gstack /qa, 브라우저 종단 간 실제 테스트
지식 계층:
  • CE /ce:compound, 검색 가능한 프로젝트 지식 베이스에 기록
gstack은 "할지 말지"와 "실제 테스트"를 담당하고, CE는 "어떻게 할지", "얼마나 잘했는지", "기억하기"를 담당합니다. 중복되는 부분이 없습니다.
Superpowers의 브레인스토밍 → 계획 → 실행 → 검토는 CE에 의해 완전히 포괄되며, 각 단계가 더 깊고 복합이라는 독특한 차원이 추가됩니다. 이를 대체하는 것은 자연스러운 일입니다.
Superpowers의 장점은 기본적인 크로스-툴 호환성으로, 동일한 스킬이 Claude Code, Cursor, Codex CLI에서 작동한다는 점입니다. 하지만 CE가 최근 CLI 변환 도구를 추가하여 10개 이상의 형식으로 변환을 지원합니다. 주로 Claude Code를 사용한다면 이 차이는 크지 않습니다.
Superpowers의 120k 스타는 그 품질을 증명하며, 많은 사람들이 AI 에이전트 워크플로우에 입문하기에 가장 좋은 진입점입니다. 하지만 실제 심층 사용에서는 CE가 더 나은 아키텍처적 깊이를 제공하며, 특히 Superpowers에는 완전히 없는 복합 차원이 두드러집니다.
여러분의 에이전트가 매일 코드를 작성하고, 버그를 수정하고, 테스트를 실행합니다. 작업이 끝난 후, 학습한 내용은 어디로 갈까요?
만약 답이 "여러 세션에 흩어져 있어 다음 번에 다시 밟게 될 것이다"라면, /ce:compound가 필요한 명령어일 수 있습니다.
링크:
  • CE: github.com/EveryInc/compound-engineering-plugin
  • gstack: github.com/garrytan/gstack
  • anthropic.com/engineering/effective-harnesses-for-long-running-agents
  • anthropic.com/engineering/harness-design-long-running-apps