Compound Engineering 사용법: AI 코딩 에이전트 워크플로 가이드
Compound Engineering 사용법: AI 코딩 에이전트 워크플로 가이드
Compound Engineering은 Claude Code, Codex, Cursor 같은 AI 코딩 에이전트에 brainstorm → plan → work → review → compound 루프를 붙이는 오픈소스 플러그인입니다. AI가 코드를 한 번 만들고 끝나는 것이 아니라, 요구사항·계획·리뷰·학습 문서를 다음 작업의 자산으로 남기게 만드는 도구입니다.
AI 코딩 에이전트를 쓰다 보면 이상한 역설을 만납니다. Claude Code나 Codex가 코드를 꽤 잘 짜주는데, 작업이 끝날 때마다 팀의 지식은 생각보다 많이 남지 않습니다. 오늘 고친 버그의 원인, 리뷰에서 발견한 패턴, 다음에 피해야 할 우회책이 대화창 안에서 흩어지고 끝납니다. Compound Engineering 사용법의 핵심은 이 문제를 정면으로 다루는 데 있습니다.

이 글은 Compound Engineering을 단순한 “프롬프트 모음”으로 소개하지 않습니다. 어떤 문제를 풀려는지, Claude Code와 Codex에서 어떻게 설치하는지, 실제 팀에 넣기 전에 어떤 트레이드오프를 봐야 하는지까지 한 번에 정리합니다.
AI 코딩 에이전트 운영 흐름을 더 넓게 보고 싶다면 Daily Info Lab의 Orca 사용법, Davia 사용법, Ponytail 사용법 글도 함께 볼 만합니다. Orca가 여러 에이전트를 병렬로 굴리는 작업판이라면, Compound Engineering은 에이전트가 따라야 할 작업 루프에 가깝습니다.
확인일은 2026년 7월 20일입니다. GitHub API 기준 EveryInc/compound-engineering-plugin은 TypeScript 기반 MIT 라이선스 프로젝트이며, 23,249 stars와 1,798 forks를 기록했습니다. 최신 GitHub Release는 compound-engineering-v3.19.0이고, 플러그인 매니페스트 버전도 3.19.0입니다.
Compound Engineering 사용법 핵심 요약
Compound Engineering은 코드를 직접 생성하는 새 모델이 아닙니다. 이미 쓰고 있는 Claude Code, Codex, Cursor, OpenCode, Kimi, Grok, Devin, Copilot 같은 AI 코딩 도구에 “일하는 방식”을 주입하는 플러그인에 가깝습니다. 그래서 Compound Engineering 사용법은 모델 선택보다 작업 순서와 검증 기준을 정하는 데 더 가깝습니다.
가장 잘 맞는 사용자는 이런 사람입니다.
- AI 코딩 에이전트를 이미 실무에 쓰고 있다.
- 에이전트가 만든 코드의 품질 편차가 고민이다.
- 기능 하나를 만들 때 요구사항, 계획, 리뷰, 회고가 자꾸 흩어진다.
docs/plans/,docs/solutions/같은 문서 기반 작업 기록을 팀 자산으로 남기고 싶다.- Claude Code와 Codex를 둘 다 쓰는데, 각 도구마다 다른 워크플로를 반복해서 설명하기 싫다.
반대로 AI 코딩 에이전트를 거의 쓰지 않거나, 작은 개인 스크립트를 가끔 고치는 정도라면 바로 설치할 필요는 없습니다. Compound Engineering은 “한 번의 코드 생성”보다 “반복되는 엔지니어링 루프”에 가치를 둔 도구입니다.
Compound Engineering은 무엇이고 누가 만들었나
Compound Engineering은 EveryInc가 공개한 공식 AI 코딩 에이전트용 skills 플러그인입니다. GitHub 저장소 설명은 “Official Compound Engineering plugin for Claude Code, Codex, Cursor, and more”입니다.
Every가 말하는 철학은 한 문장으로 요약됩니다.
Each unit of engineering work should make subsequent units easier, not harder.
보통 개발은 시간이 지날수록 복잡해집니다. 기능을 추가할수록 코드가 커지고, 버그를 고칠수록 로컬 지식이 사람 머릿속이나 대화 로그에 남습니다. Compound Engineering은 이 흐름을 뒤집으려고 합니다. 한 번의 작업이 다음 작업을 더 쉽게 만들어야 한다는 관점입니다.
구조는 플러그인 하나와 31개의 skill로 되어 있습니다. README 기준 현재 “31 skills and 0 standalone agents”를 제공합니다. 즉 독립 실행되는 백그라운드 에이전트 묶음이라기보다, 사용자가 /ce-plan, /ce-code-review처럼 호출하는 작업 절차와 프롬프트 자산의 모음에 가깝습니다.
가격: 플러그인은 무료, 비용은 연결한 AI 도구 쪽
Compound Engineering 자체는 MIT 라이선스 오픈소스입니다. 저장소를 clone해서 볼 수 있고, 각 플랫폼의 플러그인/skills 경로로 설치할 수 있습니다. 별도 구독료나 시트당 요금은 README에서 확인되지 않았습니다.
하지만 실제 실행 비용은 연결한 AI 코딩 도구에서 발생합니다.
- Claude Code를 쓰면 Anthropic/Claude 쪽 사용량과 구독 정책을 따릅니다.
- Codex를 쓰면 OpenAI/Codex CLI 설정과 계정 정책을 따릅니다.
- Cursor, Copilot, Devin, Grok 등도 각자의 계정과 모델 비용 구조를 따릅니다.
특히 /ce-code-review, /ce-simplify-code, /lfg처럼 여러 관점의 리뷰어나 하위 작업을 돌리는 skill은 단일 프롬프트보다 토큰과 실행 시간이 늘 수 있습니다. 플러그인은 무료지만, 더 체계적으로 일하게 만드는 만큼 모델 사용량은 늘어날 수 있습니다.
지금 얼마나 성장했나 (2026-07-20 기준)
GitHub API와 저장소 파일 기준으로 확인한 상태는 다음과 같습니다.
| 항목 | 확인 내용 |
|---|---|
| 저장소 | EveryInc/compound-engineering-plugin |
| 설명 | Claude Code, Codex, Cursor 등을 위한 공식 Compound Engineering 플러그인 |
| 주 언어 | TypeScript |
| 라이선스 | MIT License |
| GitHub stars / forks | 23,249 stars / 1,798 forks |
| 생성일 | 2025-10-09 |
| 최근 push | 2026-07-20 |
| 최신 릴리스 | compound-engineering-v3.19.0, 2026-07-08 공개 |
| 플러그인 버전 | 3.19.0 |
| skill 수 | 31개 |
저장소가 만들어진 지 약 283일 만에 2만 개가 넘는 stars를 모았습니다. 단순히 README만 있는 아이디어 저장소가 아니라, Claude Code, Cursor, Codex, Kimi, Grok, Devin, Copilot, OpenCode, Pi, Antigravity 등 여러 플랫폼용 매니페스트와 설치 문서를 함께 관리하고 있습니다.
핵심 기능 10가지
Compound Engineering이 흥미로운 이유는 “좋은 프롬프트 몇 개”가 아니라, AI 코딩 작업 전체를 단계로 나눈다는 점입니다.
-
/ce-brainstorm: 요구사항을 먼저 정리
기능이나 문제를 바로 구현하지 않고, 무엇이 되어야 하는지부터 질문과 답변으로 좁힙니다. 결과는 요구사항 중심의 unified plan으로 이어집니다. -
/ce-plan: 구현 전 guardrail 생성
어떤 파일, 어떤 범위, 어떤 테스트, 어떤 리스크가 있는지 정리합니다. 공식 문서의 표현처럼 계획은 HOW가 아니라 WHAT을 담는 문서입니다. -
/ce-work: 계획을 기준으로 구현
구현 에이전트가 코드를 보면서 HOW를 결정합니다. 계획의 범위와 테스트 기준을 벗어나지 않도록 하는 쪽에 초점을 둡니다. -
/ce-simplify-code: 방금 만든 코드 정리
새 코드가 기존 유틸을 중복하지 않았는지, 품질이 떨어지는 우회가 없는지, 더 단순하게 만들 수 있는지 확인합니다. -
/ce-code-review: 다중 관점 코드 리뷰
diff를 보고 맞는 reviewer persona를 골라 병렬로 리뷰한 뒤, finding을 병합·중복 제거합니다. 기본은 report-only이고, 로컬 수정은 명시적으로 요청해야 합니다. -
/ce-doc-review: 요구사항과 계획 문서 리뷰
코드를 리뷰하기 전에 문서 자체가 말이 되는지 봅니다. 범위가 너무 넓거나, 결정을 숨기거나, 테스트 기준이 빠진 계획을 초기에 잡는 용도입니다. -
/ce-compound: 배운 것을docs/solutions/에 저장
해결한 문제의 증상, 원인, 실패한 접근, 실제 해결책, 예방책을 문서로 남깁니다. 다음/ce-brainstorm과/ce-plan이 이 지식을 다시 읽는 구조입니다. -
/ce-debug: 원인 추적형 디버깅
증상만 덮는 수정을 피하고, 트리거에서 증상까지의 causal chain을 설명할 때까지 원인을 추적하는 방식입니다. -
/lfg: hands-off 파이프라인
요구사항이 어느 정도 정리된 상태에서 계획, 구현, 단순화, 리뷰, 테스트, 커밋, PR, CI 대응까지 긴 파이프라인을 한 번에 돌리는 자동화 skill입니다. -
여러 AI 코딩 도구 지원
Claude Code, Cursor, Codex, Kimi, Cline, Grok, Devin, Copilot, Droid, Qwen, OpenCode, Pi, Antigravity 등 다양한 환경에서 설치 경로를 제공합니다.
왜 하필 지금 이런 도구가 필요한가
AI 코딩의 병목은 점점 “코드를 만들 수 있느냐”에서 “만든 코드를 믿고 누적할 수 있느냐”로 이동하고 있습니다.
에이전트 하나가 작은 기능을 만드는 것은 이제 특별하지 않습니다. 문제는 다음입니다.
- 요구사항이 애매한 상태에서 바로 코드를 고친다.
- 계획 없이 작업하다가 범위가 커진다.
- 리뷰가 대화창 요약에만 남는다.
- 같은 버그 패턴을 다음 달에 다시 조사한다.
- AI가 만든 코드를 사람이 이해하지 못한 채 merge한다.
Compound Engineering은 이 문제를 “더 똑똑한 모델 하나”로 풀려고 하지 않습니다. 대신 작업 절차를 강제합니다. 먼저 생각하고, 계획하고, 구현하고, 검토하고, 배운 것을 남기라는 식입니다.
이 점에서 Orca 같은 병렬 에이전트 도구와도 방향이 조금 다릅니다. Orca가 여러 에이전트를 동시에 굴리는 작업판이라면, Compound Engineering은 한 에이전트 또는 여러 에이전트가 따라야 할 작업 루프입니다. 둘은 경쟁 관계라기보다 같이 쓸 수 있는 층이 다릅니다.
Compound Engineering 설치 방법: Claude Code와 Codex부터
이 글에서는 실제 설치 명령을 실행하지 않았습니다. 이유는 간단합니다. Claude Code나 Codex 플러그인 설치는 사용자의 전역 설정을 바꾸는 작업이기 때문입니다. 대신 공식 README의 설치 명령과 로컬 CLI 존재 여부를 확인했습니다.
이 환경에서는 다음 버전이 확인됐습니다.
claude --version
2.1.211 (Claude Code)
codex --version
codex-cli 0.142.5
가장 짧은 설치 흐름만 보면 다음 순서입니다.
# Claude Code
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering
/ce-setup
# Codex CLI
codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin
설치 후 바로 큰 작업을 맡기기보다 /ce-setup으로 플러그인 상태를 확인하고, 작은 기능 하나를 /ce-brainstorm → /ce-plan → /ce-work 순서로 실험하는 편이 안전합니다.
Claude Code 설치
Claude Code에서는 플러그인 marketplace를 추가하고 설치합니다.
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering
이미 예전 버전을 설치했다면 주의할 점이 있습니다. README에 따르면 Compound Engineering은 root-native layout으로 이동했기 때문에, 단순 /plugin update만 실행하면 오래된 marketplace snapshot에 머물 수 있습니다. 기존 설치자는 먼저 marketplace를 갱신해야 합니다.
/plugin marketplace update compound-engineering-plugin
/plugin update compound-engineering
Cursor 설치
Cursor Agent chat에서는 다음 명령을 씁니다.
/add-plugin compound-engineering
또는 플러그인 marketplace에서 “compound engineering”을 검색해 설치합니다.
Codex App 설치
Codex App 내장 marketplace에 아직 없다면 custom marketplace로 추가합니다.
| Field | Value |
|---|---|
| Source | EveryInc/compound-engineering-plugin |
| Git ref | main |
| Sparse paths | 비워둠 |
그다음 Compound Engineering을 선택해 compound-engineering 플러그인을 설치하고 Codex를 재시작합니다.
Codex CLI 설치
Codex CLI에서는 marketplace 등록과 플러그인 설치를 나눠 실행합니다.
codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin
Codex profile을 따로 쓰는 경우에는 같은 CODEX_HOME으로 두 명령을 실행해야 합니다.
CODEX_HOME="$HOME/.codex/profiles/work" codex plugin marketplace add EveryInc/compound-engineering-plugin
CODEX_HOME="$HOME/.codex/profiles/work" codex plugin add compound-engineering@compound-engineering-plugin
OpenCode 설치
OpenCode는 opencode.json의 plugin 배열에 GitHub URL을 넣습니다.
{
"plugin": ["compound-engineering@git+https://github.com/EveryInc/compound-engineering-plugin.git"]
}
설정 후 OpenCode를 재시작합니다.
Cline 설치
Cline은 skills 기능을 켠 뒤, 저장소의 skills를 global 또는 project로 연결합니다.
git clone https://github.com/EveryInc/compound-engineering-plugin
./compound-engineering-plugin/.cline/scripts/install-skills.sh --global
프로젝트 단위로만 쓰고 싶다면 --project를 사용합니다.
./compound-engineering-plugin/.cline/scripts/install-skills.sh --project
Compound Engineering 사용법: 처음 실행할 때 추천하는 흐름
설치가 끝났다면 바로 /lfg부터 돌리기보다 작은 루프부터 확인하는 편이 안전합니다.
1단계: 프로젝트 상태 확인
먼저 작업 중인 변경사항이 없는지 봅니다.
git status --short
변경사항이 많다면 커밋하거나 stash하고 시작하세요. AI 코딩 에이전트 워크플로는 기준 상태가 깨끗할수록 추적하기 쉽습니다.
2단계: 플러그인 건강 상태 확인
설치 후 README가 추천하는 첫 명령은 /ce-setup입니다.
/ce-setup
이 skill은 repo-local config, optional tool capability, machine-local 설정이 git에 들어가지 않는지 등을 점검합니다.
3단계: 작은 기능을 brainstorm한다
처음에는 큰 리팩터링보다 작은 기능이나 버그가 좋습니다.
/ce-brainstorm add a retry button to failed invoice sync jobs
여기서 목표는 코드를 쓰는 것이 아니라 요구사항을 좁히는 것입니다. 어떤 사용자가 언제 버튼을 보고, 어떤 실패 상태에서 재시도할 수 있고, 중복 실행은 어떻게 막을지 같은 질문이 먼저 나와야 합니다.
4단계: 계획으로 바꾼다
brainstorm 결과가 충분해지면 계획을 만듭니다.
/ce-plan
좋은 계획은 다음을 포함해야 합니다.
- 포함 범위와 제외 범위
- 바뀔 가능성이 높은 파일
- 테스트 시나리오
- 리스크와 완화 방법
- 구현 단위
5단계: 구현하고 리뷰한다
작업은 /ce-work로 넘깁니다.
/ce-work
작업 후에는 바로 merge하지 말고 단순화와 리뷰를 거칩니다.
/ce-simplify-code
/ce-code-review
마지막으로 배운 것이 있으면 남깁니다.
/ce-compound
이 루프가 Compound Engineering의 핵심입니다. 한 번의 feature가 끝났을 때 코드만 남는 것이 아니라, 다음 에이전트가 읽을 수 있는 계획과 solution도 남습니다.
실제로 어떤 skill이 있나
전체 31개 skill 중 실무에서 먼저 볼 만한 것만 분류하면 이렇습니다.
| 분류 | 주요 skill | 쓰는 순간 |
|---|---|---|
| 핵심 루프 | /ce-brainstorm, /ce-plan, /ce-work, /ce-compound |
기능을 정의하고 구현하고 학습을 남길 때 |
| 품질 관리 | /ce-simplify-code, /ce-code-review, /ce-doc-review |
PR 전후로 품질과 문서 일관성을 볼 때 |
| 디버깅 | /ce-debug |
원인 추적이 필요한 버그를 다룰 때 |
| 자동화 | /lfg, /ce-babysit-pr, /ce-commit-push-pr |
구현부터 PR, CI 대응까지 길게 맡길 때 |
| 제품/전략 | /ce-strategy, /ce-product-pulse, /ce-ideate |
무엇을 만들지, 왜 만들지 정리할 때 |
| 협업/문서 | /ce-explain, /ce-proof, /ce-handoff |
설명, 공유, 세션 이어받기가 필요할 때 |
| 테스트/UX | /ce-test-browser, /ce-test-xcode, /ce-polish, /ce-dogfood |
브라우저/iOS/UX 검증을 붙일 때 |
모든 skill을 매번 쓸 필요는 없습니다. 처음에는 다음 5개만 써도 충분합니다.
/ce-brainstorm
/ce-plan
/ce-work
/ce-code-review
/ce-compound
수동 프롬프트 운영과 비교
Compound Engineering 없이도 비슷한 흐름은 만들 수 있습니다. 팀이 직접 프롬프트 템플릿을 만들어 “먼저 요구사항 물어봐”, “계획부터 써”, “리뷰해”라고 말하면 됩니다.
차이는 반복성과 일관성입니다.
| 방식 | 장점 | 단점 |
|---|---|---|
| 수동 프롬프트 | 가볍고 자유롭다 | 매번 설명해야 하고 결과 형식이 흔들린다 |
| 팀 내부 문서 | 팀 맥락에 맞게 조정 가능 | 에이전트가 문서를 매번 읽는다는 보장이 약하다 |
| Compound Engineering | 설치 후 slash command로 루프를 반복하기 쉽다 | 워크플로가 꽤 opinionated하다 |
작은 개인 프로젝트라면 수동 프롬프트가 충분할 수 있습니다. 하지만 여러 명이 같은 저장소에서 AI 코딩 에이전트를 쓰거나, PR 품질을 일정하게 유지하고 싶다면 플러그인화된 workflow의 가치가 커집니다.
Compound Engineering 도입 전에 알아둘 트레이드오프
좋은 얘기만 보면 판단이 흐려집니다. 실제 도입 전에 봐야 할 제약도 있습니다.
1. 가벼운 도구는 아니다
Compound Engineering은 “한 줄 프롬프트로 바로 코드 생성”과 반대편에 있습니다. 요구사항, 계획, 리뷰, 학습 문서까지 챙기기 때문에 작은 수정에는 과하게 느껴질 수 있습니다.
오타 수정, 한 줄 import 수정, README 링크 수정 같은 작업에 매번 전체 루프를 돌릴 필요는 없습니다.
2. 토큰과 시간이 늘 수 있다
여러 reviewer persona를 돌리거나, plan과 solution 문서를 읽게 하면 모델 사용량이 늘어납니다. 특히 /lfg는 긴 자동화 파이프라인이므로 작은 작업에 습관적으로 돌리면 비효율적일 수 있습니다.
3. host AI 도구의 데이터 정책을 따른다
PRIVACY.md에 따르면 플러그인 자체는 telemetry나 analytics 코드를 포함하지 않고, 백그라운드 서비스가 자동으로 저장소 내용을 업로드하지 않습니다. 하지만 실제 prompts, context, code는 Claude Code, Codex, Cursor 같은 host 도구와 그 모델 provider 정책을 따릅니다.
즉 보안 검토는 “Compound Engineering만 안전한가”가 아니라 “우리 팀이 쓰는 AI 코딩 도구와 모델 provider가 어떤 데이터를 처리하는가”까지 포함해야 합니다.
4. 기존 설치자는 업데이트 순서를 주의해야 한다
README는 root-native layout 전환 때문에 기존 marketplace cache가 오래된 경로를 가리킬 수 있다고 설명합니다. Claude Code 사용자는 marketplace update 후 plugin update를 해야 하고, Codex CLI 사용자는 marketplace upgrade 후 plugin add를 다시 실행해야 합니다.
5. opinionated한 방식이 팀 문화와 맞아야 한다
Every의 방식은 명확합니다. “작업 하나가 다음 작업을 쉽게 만들어야 한다”는 철학에 맞춰 계획과 리뷰, 문서화를 강조합니다. 빠르게 던지고 빠르게 버리는 실험 문화가 강한 팀에서는 처음에 답답할 수 있습니다.
작은 팀을 위한 활용법
작은 팀이나 1인 개발자에게 Compound Engineering이 가장 잘 맞는 순간은 “AI가 코드는 잘 짜는데, 내가 계속 PM·리뷰어·기록자 역할을 동시에 하느라 지치는” 경우입니다.
추천 운영 규칙은 단순합니다.
작은 버그: /ce-debug 또는 바로 /ce-work
중간 기능: /ce-brainstorm → /ce-plan → /ce-work
PR 전 정리: /ce-simplify-code → /ce-code-review
반복될 문제를 해결한 뒤: /ce-compound
정말 맡겨도 되는 잘 정의된 작업: /lfg
처음부터 모든 것을 자동화하려고 하지 마세요. 첫 주에는 /ce-plan과 /ce-code-review만 써도 충분합니다. 계획 품질과 리뷰 품질이 실제로 좋아지는지 보는 것이 먼저입니다.
특히 효과가 큰 작업은 다음입니다.
- 오래된 모듈에 작은 기능을 넣어야 할 때
- 여러 파일을 건드리는 변경인데 범위가 불안할 때
- 리뷰에서 같은 지적이 반복될 때
- 버그 원인을 대화창에만 남기고 싶지 않을 때
- PR 설명이 매번 부실해지는 팀
반대로 이런 상황에서는 우선순위가 낮습니다.
- 테스트가 거의 없다.
- AI 코딩 에이전트를 거의 쓰지 않는다.
- 저장소가 너무 작고, 한 사람이 모든 맥락을 기억한다.
- 빠른 throwaway prototype이 목적이다.
문제 해결
설치 후 command가 안 보인다
먼저 설치한 host 도구를 재시작하세요. README의 여러 설치 경로가 “새 세션을 시작”하거나 “재시작”하라고 안내합니다.
Claude Code라면 marketplace와 plugin 설치 상태를 다시 확인합니다.
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering
Codex CLI라면 marketplace 등록과 plugin add가 모두 필요합니다.
codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin
Codex profile에서 설치했는데 기본 Codex에는 안 보인다
CODEX_HOME을 썼다면 같은 profile로 Codex를 실행해야 합니다. 설치할 때와 실행할 때의 CODEX_HOME이 다르면 다른 홈 디렉터리를 보고 있는 것입니다.
CODEX_HOME="$HOME/.codex/profiles/work" codex plugin marketplace add EveryInc/compound-engineering-plugin
CODEX_HOME="$HOME/.codex/profiles/work" codex plugin add compound-engineering@compound-engineering-plugin
예전 Codex 설치 후 이상한 tool map이 남았다
README는 pre-native install 경로에서 $CODEX_HOME/AGENTS.md에 다음 sentinel 블록이 남아 있을 수 있다고 설명합니다.
<!-- BEGIN COMPOUND CODEX TOOL MAP -->
...
<!-- END COMPOUND CODEX TOOL MAP -->
native plugin install은 이 블록을 추가하지 않습니다. 예전 설치 흔적이 있다면 해당 BEGIN부터 END까지의 span만 삭제해야 합니다. 다른 사용자 작성 내용은 지우면 안 됩니다.
/lfg가 너무 크게 느껴진다
정상입니다. /lfg는 계획부터 PR과 CI 대응까지 긴 파이프라인을 돌리는 skill입니다. 처음에는 /ce-brainstorm, /ce-plan, /ce-work를 나눠서 쓰는 편이 낫습니다.
리뷰 결과가 너무 많다
작업 범위가 넓거나, plan이 충분히 좁혀지지 않았을 수 있습니다. 다음 작업에서는 /ce-brainstorm에서 범위와 제외 조건을 더 분명히 하고, /ce-plan에서 테스트 시나리오를 좁히세요.
Compound Engineering을 쓰면 좋은 경우
Compound Engineering은 “AI가 코드를 대신 짜준다”보다 한 단계 뒤의 문제를 다룹니다. AI가 만든 코드를 어떻게 계획하고, 검토하고, 다음 작업에 재사용할지의 문제입니다.
특히 이런 팀에 추천합니다.
- AI 코딩 에이전트를 매일 쓴다.
- 코드 리뷰 품질을 일정하게 만들고 싶다.
- 기능 요구사항이 자주 흔들린다.
- 버그 수정 지식이 Slack이나 대화창에 흩어진다.
- Claude Code, Codex, Cursor 등 여러 도구를 혼용한다.
- PR마다 테스트와 설명을 더 엄격히 챙기고 싶다.
반대로 이런 팀은 천천히 봐도 됩니다.
- 아직 AI 코딩 도구를 실험 중이다.
- 대부분의 작업이 아주 작은 수정이다.
- 코드베이스에 테스트가 거의 없다.
- 문서화보다 빠른 throwaway 실험이 더 중요하다.
Compound Engineering FAQ
Compound Engineering은 무료인가요?
저장소는 MIT 라이선스 오픈소스입니다. 별도 플러그인 구독료는 확인되지 않았습니다. 다만 Claude Code, Codex, Cursor 등 실제 host AI 도구의 사용량 비용은 별도입니다.
Compound Engineering이 직접 코드를 작성하나요?
직접 코드를 작성하는 것은 연결한 AI 코딩 에이전트입니다. Compound Engineering은 brainstorm, plan, work, review, compound 같은 절차와 skill 프롬프트 자산을 제공합니다.
Claude Code에서만 쓸 수 있나요?
아닙니다. 공식 README 기준 Claude Code, Cursor, Codex App/CLI, Kimi, Cline, Grok, Devin, Copilot, Droid, Qwen, OpenCode, Pi, Antigravity 등을 지원합니다. 다만 플랫폼마다 설치 방식과 지원 수준은 다릅니다.
Bun이 꼭 필요한가요?
일반 설치에는 필요하지 않습니다. README의 FAQ는 Bun이 repo development와 converter maintenance 용도라고 설명합니다. 실제 사용자 설치는 각 host의 plugin/skills 경로를 따릅니다.
/lfg부터 써도 되나요?
가능은 하지만 처음에는 추천하지 않습니다. /lfg는 긴 hands-off 파이프라인입니다. 먼저 /ce-setup, /ce-brainstorm, /ce-plan, /ce-work, /ce-code-review를 나눠 써보고 팀에 맞는지 확인하는 편이 안전합니다.
보안상 안전한가요?
PRIVACY.md 기준 플러그인 자체는 telemetry나 자동 업로드 백그라운드 서비스를 포함하지 않습니다. 하지만 실제 코드와 프롬프트는 사용하는 host AI 도구와 모델 provider 정책을 따릅니다. 회사 코드에 도입한다면 Claude Code, Codex, Cursor 등 각 도구의 데이터 처리 정책까지 함께 검토해야 합니다.
마무리
Compound Engineering은 새 코딩 모델이 아니라, AI 코딩 에이전트를 실무 엔지니어링 루프로 묶는 플러그인입니다. 좋은 점은 분명합니다. 요구사항, 계획, 구현, 리뷰, 학습 기록이 한 번의 대화에서 사라지지 않고 다음 작업으로 이어집니다.
하지만 모든 작업에 필요한 도구는 아닙니다. 작은 수정에는 무겁고, 여러 skill을 돌리면 시간과 토큰도 더 씁니다. 이 도구가 빛나는 지점은 “AI 코딩을 이미 자주 쓰고 있고, 이제는 품질과 누적 지식이 병목이 된 팀”입니다.
처음 시작한다면 큰 기능을 맡기지 마세요. 작은 기능 하나를 골라 /ce-brainstorm → /ce-plan → /ce-work → /ce-code-review → /ce-compound 루프를 한 번만 끝까지 돌려보면 됩니다. 그 결과 다음 작업이 실제로 쉬워졌다면, Compound Engineering이 팀에 맞는 신호입니다.
참고자료
- Compound Engineering GitHub 저장소
- Compound Engineering 공식 가이드 — Every
- Compound Engineering: How Every Codes With Agents
- My AI Had Already Fixed the Code Before I Saw It
- Compound Engineering skill documentation catalog
- Compound Engineering GitHub Releases
- Compound Engineering Privacy & Data Handling
- Compound Engineering Security Policy
AI/IT도구에서 이어서 보면 좋은 글
한 번 더 클릭하게 만드는 내부 링크 구간입니다. 같은 주제의 실용 글로 이동시키고, 카테고리 허브로도 연결합니다.
Robyn 사용법 2026: Rust 런타임 Python 웹 프레임워크 빠른 시작
Robyn 사용법을 설치부터 최소 앱 실행, CLI 옵션, OpenAPI 확인, FastAPI·Flask와의 차이까지 로컬 검증 결과 중심으로 정리했습니다.
Dub 사용법 2026: 오픈소스 링크 어트리뷰션 플랫폼 셀프호스팅 가이드
Dub 사용법 핵심은 짧은 링크 생성보다 전환 추적, 실시간 분석, 파트너 프로그램까지 한 흐름으로 묶는 것입니다. 셀프호스팅 전 체크할 점도 정리했습니다.
Zappa 사용법 2026: Python 웹앱 AWS Lambda 서버리스 배포 가이드
Zappa 사용법을 기준으로 Flask·Django·FastAPI Python 웹앱을 AWS Lambda와 API Gateway에 배포하는 방법을 정리했습니다. 설치, zappa_settings.json 설정, 패키징 검증, 비용과 한계까지 한 번에 확인하세요.