Compound Engineering: AI 코딩 에이전트를 시간이 지날수록 더 똑똑하게 만드는 플러그인

AI 코딩 도구를 사용하는 대부분의 개발자들은 결국 동일한 한계에 부딪힙니다. 에이전트가 코드를 작성하면 사용자가 이를 수락하거나 거절하며, 다음번에는 다시 처음부터 시작해야 합니다. 무엇이 효과적이었는지에 대한 기억도, 코드베이스에 대한 축적된 판단력도, 세션 간의 개선도 없습니다. 사용자는 빨라지고 있지만, 도구는 사용자를 구체적으로 돕는 능력이 향상되지 않습니다.

Compound Engineering은 이 문제를 해결하려는 플러그인입니다. Every.to에서 제작하였으며 Claude Code, Cursor, Codex, GitHub Copilot 및 점점 늘어나는 다른 도구들에서 사용할 수 있습니다. 이 플러그인은 '각 엔지니어링 작업 단위가 다음 작업을 더 쉽게 만들어야 한다'는 단순한 원칙을 중심으로 설계된 구조화된 워크플로우 (workflow)를 도입합니다.

핵심 아이디어 (The Core Idea)

전통적인 개발 방식은 기술 부채 (technical debt)를 축적합니다. 기능이 추가될수록 복잡성이 증가하고, 버그 수정 과정에서 아무도 기록하지 않은 지식들이 남겨지며, 코드베이스는 서서히 변경하기 어려워집니다.

Compound Engineering 철학은 이 비율을 뒤집습니다. 노력의 80%를 계획 (planning)과 검토 (review)에 투입하고, 20%를 실행 (execution)에 투입합니다. 날카로운 계획이 더 작고 깔끔한 구현을 만들어낸다는 생각입니다. 훌륭한 코드 리뷰 (code review)는 단순한 특정 버그가 아니라 패턴을 잡아냅니다. 문서화된 학습 (documented learning)은 에이전트가 다음 주에 동일한 제약 사항을 다시 발견할 필요가 없음을 의미합니다.

이 플러그인은 AI 코딩 도구 내부에서 실행할 수 있는 슬래시 명령어 (slash commands) 형태로 이 워크플로우를 구현하는 37개의 기술 (skills)과 51개의 에이전트 (agents)를 제공합니다.

워크플로우 루프 (The Workflow Loop)

핵심 루프는 다음과 같습니다:

/ce-brainstorm "add retry logic to background jobs"
/ce-plan docs/brainstorms/background-job-retry-requirements.md
/ce-work
...

각 단계가 실제로 수행하는 작업은 다음과 같습니다:

**/ce-brainstorm**은 대화형 질의응답 (Q&A) 세션을 실행합니다. 기능이나 문제에 대해 명확히 하는 질문을 던진 후, 적절한 규모의 요구사항 문서 (requirements document)를 생성합니다. 출력물은 다음 단계로 직접 전달할 수 있는 파일 형태입니다.

**/ce-plan**은 해당 요구사항 문서를 가져와 상세한 구현 계획 (implementation plan)으로 변환합니다. 무엇을 변경할지, 무엇을 테스트할지, 엣지 케이스 (edge cases)는 무엇인지 등을 포함합니다.

**/ce-work**는 계획을 실행합니다. 격리 (isolation)를 위해 워크트리 (worktrees)를 사용하며, 진행 과정에 따라 작업 (tasks)을 추적합니다.

**/ce-code-review**는 병합 (merge) 전 수행하는 멀티 에이전트 리뷰 단계입니다. 문제를 찾아낼 뿐만 아니라, 더 중요한 것은 단순히 수정하는 것을 넘어 문서화할 가치가 있는 반복되는 문제 패턴을 포착하려고 시도한다는 점입니다.

**/ce-compound**는 복리 효과 (compounding)가 발생하는 지점입니다. 이번 사이클에서 얻은 학습 내용을 기록하여, 다음에 유사한 작업을 할 때 에이전트가 더 나은 컨텍스트 (context)를 가질 수 있도록 합니다.

또한 핵심 루프 외부에 존재하는 두 가지 명령어가 있습니다:

**/ce-strategy**는 제품의 목표 문제, 접근 방식, 페르소나 (personas), 그리고 핵심 지표 (key metrics)를 담은 STRATEGY.md 파일을 생성하고 유지 관리합니다. 이 파일이 존재하면, 브레인스토밍 (brainstorm) 및 계획 (plan) 명령어들이 이를 근거 (grounding)로 읽어 들여, 전략적 선택이 기능 결정으로 자연스럽게 이어지게 합니다.

**/ce-ideate**는 더 큰 질문들을 다루기 위해 브레인스토밍 단계의 상류 (upstream)에 위치합니다. 요구사항 (requirements)으로 바로 뛰어드는 대신, 여러 아이디어를 생성하고 비판적으로 평가한 다음, 가장 강력한 아이디어를 브레인스토밍 단계로 전달합니다.

**/ce-debug**는 버그 조사용입니다. 실패를 체계적으로 재현하고, 근본 원인 (root cause)을 추적하며, 단순히 증상만을 패치하는 것이 아니라 해결책을 구현합니다.

**/ce-product-pulse**는 사용량, 성능, 그리고 에러에 대한 시간 범위별 보고서를 생성합니다. 보고서는 docs/pulse-reports/에 저장되어 제품이 실제로 어떻게 작동하고 있는지에 대한 탐색 가능한 이력으로 축적됩니다.

설치 (Installation)

Claude Code (가장 간단한 방법)

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Bun은 필요하지 않습니다. 설치 후, /ce-setup을 실행하여 환경을 점검하고 프로젝트 설정을 부트스트랩 (bootstrap) 하세요.

Cursor

Cursor Agent 채팅에서:

/add-plugin compound-engineering

또는 플러그인 마켓플레이스에서 "compound engineering"을 검색하세요.

GitHub Copilot (VS Code)

VS Code 명령 팔레트(command palette)를 엽니다.
Chat: Install Plugin from Source를 실행합니다.
리포지토리(repo)로 EveryInc/compound-engineering-plugin을 입력합니다.
VS Code에 사용 가능한 플러그인이 표시되면 compound-engineering을 선택합니다.

Codex (3단계 필요)

Codex는 현재 네이티브 플러그인 사양(plugin spec)이 스킬(skills)은 처리하지만 커스텀 에이전트(custom agents)는 처리하지 못하기 때문에 추가 단계가 필요합니다. 에이전트는 /ce-code-review나 /ce-plan과 같은 명령어를 구동하는 핵심 요소입니다.

# 1단계: 마켓플레이스 등록
codex plugin marketplace add EveryInc/compound-engineering-plugin

...

세 단계가 모두 필요합니다. Bun 단계를 건너뛰면 위임 기반 스킬(delegation-based skills)에서 에이전트가 누락되었다는 보고가 발생합니다.

Gemini CLI, OpenCode, Kiro, Pi

bunx @every-env/compound-plugin install compound-engineering --to gemini
bunx @every-env/compound-plugin install compound-engineering --to opencode
bunx @every-env/compound-plugin install compound-engineering --to kiro
...

전형적인 버그 조사 과정

디버깅을 위한 흐름은 더 짧습니다:

/ce-debug "checkout webhook sometimes creates duplicate invoices"
/ce-code-review
/ce-compound

/ce-debug는 단순히 수정 단계로 바로 넘어가지 않습니다. 먼저 실패 상황을 재현하고, 그것이 어디서 기인하는지 추적한 다음, 타겟팅된 수정 사항을 구현합니다. 리뷰와 컴파운드(compound) 단계를 거친 후, 해당 인보이스(invoicing) 예외 케이스에 대한 지식은 이제 프로젝트의 축적된 컨텍스트(context)의 일부가 됩니다.

실제로 디스크에 기록되는 것들

이 부분은 이해해 둘 가치가 있습니다. Compound Engineering은 단순히 프롬프트(prompts)에 관한 것이 아닙니다. 여러분의 프로젝트에 다음과 같은 파일들을 생성합니다:

STRATEGY.md — /ce-strategy를 사용하는 경우 생성되는 제품 앵커 문서(product anchor document)
docs/brainstorms/ — /ce-brainstorm에서 생성된 요구사항 문서(requirements documents)
docs/pulse-reports/ — /ce-product-pulse에서 생성된 제품 성능 보고서(product performance reports)
/ce-compound에 의해 작성된 Compound 노트 — 플러그인이 저장하도록 설정된 위치에 저장됩니다

이 파일들은 세션 전반에 걸쳐 지속되도록 설계되었으며, 향후 에이전트 상호작용을 위한 근거가 되는 컨텍스트 (grounding context)가 됩니다. 핵심은 각 사이클이 처음부터 다시 시작하는 것이 아니라, 더 많은 정보를 바탕으로 한 다음 사이클을 향해 구축되어 간다는 점입니다.

사용할 가치가 있을까요?

이 플러그인은 실제 문제를 해결하려는 진정한 시도입니다. AI 코딩 에이전트는 기본적으로 상태가 없는 (stateless) 특성을 가지며, 컨텍스트 (context)를 능동적으로 관리하지 않으면 복잡한 프로젝트가 진행됨에 따라 그 유용성이 저하됩니다.

이런 경우라면 시도해 볼 가치가 있습니다:

결정 사항에 이력이 있고 컨텍스트 (context)가 중요한, 단순하지 않은 코드베이스 (codebase)에서 작업하는 경우
매 세션마다 에이전트에게 동일한 아키텍처 제약 사항을 다시 설명하고 있는 자신을 발견할 때
단순히 "이 코드가 작동하는가"를 넘어선, 더 구조화된 리뷰를 원하는 경우
Claude Code, Cursor 또는 Copilot을 사용 중이며, 단순한 채팅 인터페이스가 아닌 워크플로 (workflow)를 원하는 경우

이런 경우라면 과할 수 있습니다:

작고 독립적인 스크립트나 프로토타입을 작업하는 경우
축적된 컨텍스트 (context)가 중요하지 않을 정도로 세션이 충분히 격리되어 있는 경우
더 가벼운 워크플로 (workflow)를 선호하며, 브레인스토밍/계획/복합 (brainstorm/plan/compound) 절차가 번거롭게 느껴지는 경우

기여 정책 또한 알아둘 가치가 있습니다. 저자는 외부 기여를 명시적으로 거부하며, 이슈 (issues)와 PR (Pull Requests)을 직접 검토하는 대신 자신의 에이전트를 통해 검토합니다. 이는 오픈 소스 도구로서는 이례적인 선택이지만, 명확하게 명시되어 있으며 릴리스 주기 (153회 릴리스, 최신은 2026년 5월)를 볼 때 그럼에도 불구하고 활발하게 유지 관리되고 있음을 시사합니다.

솔직한 조언을 하나 드리자면: 이 플러그인의 가치는 전체 루프 (full loop)를 얼마나 일관되게 실행하느냐에 따라 달라집니다. 만약 /ce-work만 사용하고 /ce-compound를 건너뛴다면, 가장 중요한 부분을 놓치고 있는 것입니다. 복합 (compounding)은 사이클을 완료했을 때만 발생합니다.

빠른 참조

명령	기능
`/ce-setup`	최초 설정 및 환경 점검
...

GitHub: https://github.com/EveryInc/compound-engineering-plugin