컴파운드 엔지니어링

AI 코딩 에이전트 시대에 등장한 소프트웨어 개발 철학이자 워크플로. “Compounding Engineering”이라는 이름으로도 불리며, 2025년 8월 무렵 Every(every.to)의 엔지니어 Kieran Klaassen과 공동창업자 Dan Shipper가 정립하고 확산시킨 개념입니다.

개요
용어의 등장과 역사
핵심 철학
핵심 루프: Plan → Work → Review → Compound
도입 성숙도 사다리 (5단계)
에이전트 네이티브(Agent-Native) 환경
작업 산출물과 저장소 구조
Compound Engineering Plugin
팀 단위 적용
다른 영역으로의 확장
인접 개념과의 비교
평가와 한계
참고 자료

개요

**Compound Engineering(컴파운드 엔지니어링)**은 “엔지니어링 작업의 각 단위가 다음 작업을 더 쉽게 만들어야 한다”는 원칙을 중심으로, AI 코딩 에이전트(Claude Code 등)와 협업하는 방식을 체계화한 소프트웨어 개발 방법론입니다.

전통적인 개발에서는 기능이 추가될수록 코드베이스가 복잡해지고 유지보수가 어려워지는 경향이 있습니다. Compound Engineering은 이 흐름을 반대로 뒤집어, 매 작업이 끝날 때마다 배운 점을 문서·규칙·스킬 형태로 코드베이스와 에이전트 설정에 축적시킴으로써 시간이 지날수록 개발 속도와 품질이 오히려 향상되도록 설계된 시스템입니다. “복리(compound interest)“처럼 학습이 누적되어 기하급수적으로 쌓인다는 점에서 이름이 유래했습니다.

이 개념은 AI 이메일 비서 제품 Cora를 만드는 과정에서 실전 경험을 통해 도출되었으며, 현재는 Claude Code, Cursor, Codex 등 여러 AI 코딩 도구에서 사용할 수 있는 오픈소스 플러그인(compound-engineering-plugin)으로 공개되어 있습니다.

용어의 등장과 역사

출처 기업: Every, Inc. — AI 뉴스레터를 발행하고 Cora(AI 수신함 비서), Monologue, Sparkle, Spiral 등 AI 제품을 만드는 미디어 겸 제품 스튜디오. 대부분의 제품을 1~2인 규모의 엔지니어링 팀으로 운영합니다.
핵심 인물
- Kieran Klaassen — Cora의 제너럴 매니저(시니어 엔지니어). “Compounding Engineering”이라는 용어를 처음 만든 인물로 알려져 있습니다.
- Dan Shipper — Every의 공동창업자 겸 CEO. Klaassen의 아이디어를 정리하고 대중적으로 알리는 데 크게 기여했습니다.
타임라인
- 2025년 8월 18일: Dan Shipper가 X(트위터)에서 “Claude Code 덕분에 Every의 엔지니어링 철학을 완전히 바꾸었다”며 “Compounding Engineering”을 소개하고, Klaassen이 쓴 최초의 상세 가이드를 공유.
- 2025년 10월: Claude Code용 “compounding engineering plugin”을 공개적으로 시연.
- 2025년 12월 11일: Klaassen과 Shipper가 공동으로 “Compound Engineering: How Every Codes With Agents”라는 정본(definitive) 에세이를 every.to에 게재. 4단계 루프, 채택 성숙도 사다리, 에이전트 네이티브 체크리스트 등 방법론의 뼈대를 공식화.
- 2025년 말~2026년: 커뮤니티 확산. Anthropic Claude Code 팀원(Boris Cherny 등)이 언급하며 재확산되었고, 개발자 블로그·미디엄·유튜브 등에서 다수의 해설·적용 사례가 등장.
- 2026년 상반기: compound-engineering-plugin이 Claude Code 외에 Cursor, Codex, GitHub Copilot, Factory Droid 등 다양한 도구를 지원하도록 확장되었고, 내부 구조도 “에이전트+스킬” 혼합 구조에서 “스킬 전용” 구조로 리팩터링되는 등 빠르게 진화.

참고: 이 개념은 등장한 지 1년이 채 되지 않은 신생 용어로, 정의와 도구 구성이 현재도 활발히 바뀌고 있습니다. 최신 상태는 공식 GitHub 저장소를 확인하는 것이 가장 정확합니다.

핵심 철학

“각 단위의 엔지니어링 작업은 다음 작업을 더 쉽게 만들어야지, 어렵게 만들어서는 안 된다.”

전통적인 코드베이스는 시간이 지날수록 다루기 어려워지는 경향이 있습니다. 기능이 하나씩 추가될 때마다 복잡도가 늘어나고, 10년쯤 지난 시스템에서는 팀이 새 기능을 만드는 시간보다 기존 시스템과 씨름하는 시간이 더 많아지곤 합니다.

Compound Engineering은 이 구조를 뒤집습니다.

새 기능은 시스템에 복잡성을 더하는 대신 새로운 능력을 가르치는 계기가 됩니다.
버그 수정은 해당 버그 하나만이 아니라 그 부류의 버그 전체를 제거하는 규칙으로 codify(성문화)됩니다.
반복되는 패턴은 향후 작업에 재사용 가능한 **도구(스킬·에이전트·명령어)**로 전환됩니다.

이 과정이 누적되면 코드베이스와 에이전트 설정은 시간이 지날수록 이해하기 쉽고, 수정하기 쉽고, 신뢰하기 쉬운 상태로 수렴합니다.

핵심 루프: Plan → Work → Review → Compound

Every가 제시한 기본 루프는 4단계로 구성됩니다.

단계	내용	비고
Plan (계획)	리서치와 구현을 분리한다. 요구사항·접근법·엣지 케이스를 먼저 명시적으로 정리하고, 에이전트가 코드베이스를 조사해 패턴과 접근법을 제안하게 한다.	Claude Code의 plan mode처럼 이미 널리 쓰이는 패턴
Work (실행)	확정된 계획을 실제로 구현한다.	에이전틱 코딩의 핵심으로, 이미 잘 알려진 패턴
Review (검토)	에이전트에게 변경 사항을 팀의 베스트 프랙티스에 비추어 검토하고 개선점을 찾게 한다.	많은 실무자가 일부 형태로 이미 수행하지만 표준화 수준은 낮음
Compound (축적)	이번 작업에서 얻은 배움을 잘 정의된 구조(사실상 사내 위키)로 요약해 남긴다. 이 문서는 다음번 Plan 단계에서 다시 참조된다.	Compound Engineering을 다른 방법론과 구분 짓는 핵심 단계

80/20 원칙: Plan과 Review에 전체 시간의 약 80%를, Work와 Compound에 나머지 20%를 씁니다. 즉 코드가 작성되기 전과 후에 대부분의 사고가 이루어져야 한다는 것이 핵심입니다.

Compound 단계를 생략하면 “AI의 도움을 받는 전통적 개발”에 머무르게 되며, 이 마지막 고리가 있어야 Plan과 Review 단계의 품질이 반복될수록 함께 향상됩니다.

이후 공식 플러그인에서는 이 루프가 brainstorm → plan → work → simplify(코드 단순화) → review → compound의 6단계로 확장되었습니다. 요구사항을 다지는 brainstorm 단계와, 리뷰 전에 코드를 정리하는 simplify 단계가 추가된 형태입니다.

도입 성숙도 사다리 (5단계)

Every는 팀이나 개인이 Compound Engineering을 점진적으로 도입할 수 있도록 5단계 모델을 제시합니다.

에이전트 들이기 — 파일 시스템 접근 권한을 주고, “이 함수에 테스트를 추가해줘” 같은 좁은 범위의 작업부터 시작. 매 행동을 직접 승인하며 신뢰를 쌓는 단계. 축적 포인트: CLAUDE.md를 만들어 선호와 교정 사항을 기록.
계획을 신뢰하기 — 요구사항·접근법·엣지 케이스에 투자하고, 에이전트가 리서치하게 하며, 계획을 문서로 명시. 구현이 끝나면 개별 단계가 아닌 PR 단위로 검토. 축적 포인트: 계획이 놓친 부분을 기록해 다음 계획을 더 빠르게 만듦.
결과만 말하기 — “새 댓글에 대한 이메일 알림을 추가해줘”처럼 결과(outcome)만 제시하고 계획 수립 자체를 에이전트에게 맡김. 사람은 접근 방식만 승인. 축적 포인트: 효과가 검증된 결과 지향 지시문을 라이브러리로 축적.
모든 것을 병렬화하기 — 실행을 클라우드로 옮기고, 여러 에이전트에게 서로 다른 기능을 동시에 맡기며, 아이디어·버그·개선 사항을 큐에 쌓아 에이전트가 순서대로 처리. 에이전트가 사용자 피드백을 모니터링하고 능동적으로 기능을 제안하기도 함. 축적 포인트: 어떤 작업이 병렬화 가능한지 문서화.

이 사다리는 “에이전트에게 얼마나 많은 자율성과 인프라 접근권을 부여하는가”를 기준으로 삼습니다. 사람이 가진 권한을 에이전트에게 얼마나 넘겨주지 않느냐가 곧 사람이 직접 해야 할 일의 양이 됩니다.

에이전트 네이티브(Agent-Native) 환경

Compound Engineering이 전제하는 인프라 조건은 “에이전트가 사람과 동일한 능력을 갖추는 것”입니다. 아래는 이를 점검하는 체크리스트입니다.

개발 환경: 로컬 앱 실행, 테스트 스위트 실행, 린터·타입체커 실행, DB 마이그레이션, 개발용 데이터 시딩
Git 작업: 브랜치 생성, 커밋, 푸시, PR 생성, PR 코멘트 읽기
디버깅: 로컬/프로덕션(읽기 전용) 로그 열람, UI 스크린샷 촬영, 네트워크 요청 검사, 에러 트래킹(Sentry 등) 접근

이 능력들은 **1단계(기본 개발) → 2단계(완전한 로컬 환경) → 3단계(프로덕션 가시성) → 4단계(완전 통합)**로 점진적으로 확장할 수 있습니다.

이와 맞물려 자주 언급되는 실무 관행이 Claude Code의 --dangerously-skip-permissions 플래그입니다. 매 행동마다 승인을 요구하는 기본 동작을 끄는 옵션으로, Every는 다음 조건에서만 사용을 권장합니다.

사용할 것: 계획·리뷰 체계가 신뢰할 만할 때, 실제 사용자에게 영향이 없는 안전한(샌드박스) 환경일 때, 속도가 중요할 때
사용하지 말 것: 아직 학습 중일 때, 프로덕션 코드를 다룰 때, 되돌리기(rollback) 수단이 부족할 때

권한 확인 절차 없이 작업할 때는 Git 히스토리, 테스트, 병합 전 리뷰, Git worktree를 통한 작업 격리가 대체 안전장치로 제시됩니다.

작업 산출물과 저장소 구조

Compound Engineering을 실천하는 프로젝트는 보통 아래와 같은 파일 구조를 갖습니다.

your-project/
├── CLAUDE.md              # 에이전트 지침, 선호, 패턴 (매 세션 읽힘)
├── docs/
│   ├── brainstorms/       # 요구사항 탐색 결과
│   ├── solutions/         # 해결한 문제의 축적된 지식 (사내 위키 역할)
│   └── plans/             # 구현 계획 문서
└── todos/                 # 우선순위와 상태가 있는 작업 항목
    ├── 001-ready-p1-fix-auth.md
    └── 002-pending-p2-add-tests.md

CLAUDE.md: 에이전트가 매 세션 읽는 가장 중요한 파일. 선호·패턴·프로젝트 맥락을 담아두고, 에이전트가 실수할 때마다 이곳에 메모를 추가해 다음번엔 같은 실수를 반복하지 않게 합니다.
docs/solutions/: 해결된 문제 하나하나가 검색 가능한 문서가 되어 조직의 암묵지(tribal knowledge)를 형성합니다.
todos/: 리뷰 단계에서 발견된 이슈를 우선순위와 함께 추적합니다.

Compound Engineering Plugin

Every는 이 방법론을 실제 도구로 구현한 오픈소스 플러그인 **EveryInc/compound-engineering-plugin**을 GitHub에 공개하고 있습니다(MIT 라이선스).

지원 도구: Claude Code, Cursor, Codex(App/CLI), Kimi Code CLI, Cline, Grok Build CLI, Devin CLI, GitHub Copilot, Factory Droid, Qwen Code, OpenCode, Pi, Antigravity CLI 등 폭넓은 AI 코딩 하네스를 지원합니다.

설치(Claude Code 기준):

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

구조: 별도의 독립 에이전트 없이, 32개의 스킬(skill)이 리뷰어·리서처·워크플로 역할을 스킬 내부의 프롬프트 자산으로 내장하는 방식으로 리팩터링되었습니다. (초기 버전은 별도의 서브에이전트 다수를 포함하는 구조였으나, 이후 스킬 전용 구조로 단순화되었습니다. 이 구조는 계속 바뀌고 있어 최신 내용은 공식 저장소 확인이 필요합니다.)

핵심 루프에 대응하는 주요 스킬(명령어)은 다음과 같습니다.

명령어	역할
`/ce-brainstorm`	요구사항을 대화형으로 탐색하고 요구사항 문서를 작성
`/ce-plan`	아이디어나 요구사항 문서를 구현 가능한 계획으로 구체화
`/ce-work`	계획을 실제로 실행
`/ce-simplify-code`	리뷰 전에 방금 작성한 코드를 정리·단순화
`/ce-code-review`	계획 대비 변경 사항을 다중 에이전트 관점에서 리포트 형태로 검토
`/ce-compound`	해결한 문제를 `docs/solutions/`에 문서화해 팀 지식으로 축적

이 외에도 전략 문서 관리(/ce-strategy), 아이디어 발굴(/ce-ideate), 제품 사용 현황 리포트(/ce-product-pulse), 버그 재현·수정(/ce-debug), 세션 인수인계(/ce-handoff), 완전 자동화 파이프라인(/lfg, “브레인스토밍부터 PR까지” 전 과정을 자동 수행) 등 필요할 때만 꺼내 쓰는 보조 스킬들이 함께 제공됩니다.

팀 단위 적용

AI가 구현을 상당 부분 맡게 되면서, Every는 팀 협업 방식도 다음과 같이 재정의할 것을 제안합니다.

	전통적 방식	Compound Engineering 방식
흐름	사람 A가 코드 작성 → 사람 B가 리뷰 → PR 코멘트로 논의 → 승인 후 병합	사람 A가 계획 작성 → AI가 구현 → AI 에이전트가 리뷰 → 사람 B가 AI 리뷰를 검토 → 사람 승인 후 병합

주요 팀 규범으로는 다음이 제시됩니다.

계획 승인: 침묵은 승인이 아니며, 구현 전 명시적 사인오프가 필요합니다.
PR 소유권: 코드를 누가(또는 무엇이) 작성했는지와 무관하게, 작업을 시작한 사람이 PR의 품질과 병합 후 영향까지 책임집니다.
사람 리뷰의 초점: AI 리뷰 에이전트가 이미 문법 오류·보안 취약점·스타일을 검사했으므로, 사람은 “합의한 대로 만들어졌는가”, “접근 방식이 타당한가” 같은 의도(intent) 중심으로 리뷰합니다.
비동기 기본 소통: 회의 대신 계획 문서에 코멘트를 남기는 방식을 기본으로 삼습니다.
Compound 문서 = 암묵지의 형식화: “인증 로직은 Sarah에게 물어봐”라는 방식 대신, Sarah가 /ce-compound를 실행해 그 지식을 문서로 남기면 누구나 찾아볼 수 있게 됩니다.

다른 영역으로의 확장

Every의 확장된 가이드는 이 루프를 코딩 외의 영역까지 적용할 것을 제안합니다.

디자인: 프로덕션 코드와 분리된 “베이비 앱(baby app)“에서 자유롭게 디자인을 실험한 뒤 패턴만 추출해 본 프로젝트로 옮기는 방식, Figma 목업을 계획에 링크해 구현과 목업의 일치 여부를 에이전트가 자동으로 검증하는 figma-design-sync 같은 패턴, 팀의 디자인 취향을 스킬 파일로 성문화하는 방법 등을 제시합니다.
바이브 코딩(Vibe Coding)과의 접점: 코드 품질에 관심이 없고 결과물만 필요한 경우(프로토타입, 개인 프로젝트, 내부 도구 등)를 위한 “빠른 경로”로 /lfg 같은 완전 자동화 명령을 제시합니다. 다만 프로덕션 시스템, 보안 민감 앱에는 권장하지 않습니다.
리서치: 인터뷰 노트를 AI가 활용하기 쉬운 구조(인사이트, 인용, 확신도)로 정리하고, 페르소나 문서를 만들어 계획 단계에서 참조하게 함으로써 리서치와 구현 사이의 단절을 줄입니다.
제품 사용 패턴 감지: 과다 사용 패턴, 어려움을 겪는 패턴(반복 실패), 우회 사용 패턴(수동으로 데이터를 옮기는 등), 이탈 패턴을 관찰해 이를 기능 제안으로 연결하는 접근을 소개합니다.
카피/보이스: UX 카피를 계획 단계부터 포함시키고, 팀의 보이스를 스킬로 성문화하며, 코드 리뷰처럼 카피도 별도 에이전트가 검토하게 합니다.
마케팅/출시: 계획과 구현 내용을 바탕으로 릴리스 노트·체인지로그·소셜 포스트·스크린샷을 자동 생성해, 기능 개발과 공지 작업을 한 흐름으로 연결합니다.

인접 개념과의 비교

개념	핵심 아이디어	Compound Engineering과의 관계
바이브 코딩 (Vibe Coding)	결과만 설명하고 세부 구현은 전적으로 AI에 맡기는 가볍고 빠른 접근	Compound Engineering의 4단계 사다리 중 최상단(3~4단계)과 유사하지만, 계획·리뷰·지식 축적 없이 결과만 취하는 경우가 많음. Every는 바이브 코딩을 “발견”에, 정식 루프를 “구현”에 쓰는 조합을 권장
스펙 주도 개발 (Spec-Driven Development)	구현 전에 상세한 명세를 철저히 작성해 리스크를 줄이는 접근	Compound Engineering의 Plan 단계와 철학적으로 맞닿아 있으나, 스펙 자체보다 “학습을 축적해 다음 스펙 작성을 더 쉽게 만드는 피드백 고리”에 방점이 있음
Ralph Loop	Geoffrey Huntley가 2025년 중반 고안한 패턴. 매 반복마다 새 컨텍스트로 에이전트를 재기동해 “컨텍스트 오염(context rot)“을 피하고, 테스트·린터 같은 외부 검증 기준을 통과할 때까지 반복시키는 단순한 셸 스크립트 패턴	Compound Engineering과 상호보완적으로 자주 언급됨. `AGENTS.md`/`CLAUDE.md`에 축적된 학습을 Ralph Loop의 매 반복이 읽어들이는 식으로 결합되어 쓰이는 경우가 많음
컨텍스트 엔지니어링 (Context Engineering)	에이전트에게 어떤 정보를 언제 제공할지를 설계하는 더 넓은 상위 분야	Compound Engineering이 다루는 `CLAUDE.md`, `docs/solutions/` 등의 지식 축적 구조는 컨텍스트 엔지니어링의 한 응용 사례로 볼 수 있음

평가와 한계

Compound Engineering은 2025년 말 이후 빠르게 확산되었지만, 아직 검증이 진행 중인 신생 개념이라는 점에서 다음과 같은 관점도 함께 고려할 필요가 있습니다.

“완전히 새로운 것은 아니다”라는 시각: 엔지니어링 리더십 저술가 Will Larson은 Compound Engineering을 “이미 잘 알려진 패턴 두 가지(Plan, Work), 어느 정도 알려진 패턴 하나(Review), 그리고 많은 실무자가 암묵적으로는 해왔지만 일관된 실행 수단은 없었던 패턴 하나(Compound)의 조합”이라고 평가했습니다. 그는 이 네 단계 자체는 “충격적일 만큼 새롭지는 않지만” 암묵적 베스트 프랙티스를 몇 개의 명령어와 AGENTS.md 규칙으로 구체화한다는 점에서 실용적 가치가 크다고 보았고, 동시에 이런 관행들이 향후 Claude Code나 Cursor 같은 도구 자체에 흡수되어 “명시적으로 이 방법론을 쓰고 있다는 인식조차 없어질 것”이라는 전망도 함께 제시했습니다.
생산성 수치에 대한 신중한 해석 필요: 일부 커뮤니티 글에서는 “기존 대비 300~700% 빠른 개발”과 같은 수치가 언급되지만, 이는 독립적으로 검증된 통계라기보다 실천자 개인이나 특정 팀의 경험담·추정치에 가깝습니다. AI 코딩 도구 전반의 생산성 향상 폭에 대해서는 업계 내에서도 의견이 엇갈리며, 장기적인 효율 개선을 체감하지 못했다고 말하는 개발자들의 사례도 함께 보고되고 있습니다.
--dangerously-skip-permissions 등 속도 최적화의 위험: 승인 절차를 건너뛰는 관행은 견고한 테스트·롤백 체계와 프로덕션과 분리된 안전한 작업 환경을 전제로 합니다. 이 전제가 갖춰지지 않은 팀이 그대로 적용할 경우 리스크가 커질 수 있습니다.
특정 벤더의 견해가 강하게 반영된 프레임워크: 공식 플러그인 저장소 스스로도 “의도적으로 견해가 뚜렷한(opinionated) 프로젝트”라고 밝히고 있으며, 유지관리자(Klaassen 등)의 관점에 맞지 않는 기여는 채택되지 않을 수 있다고 명시합니다. 즉 보편적 표준이라기보다는 Every라는 특정 조직의 실전 경험에서 나온 견해에 가깝습니다.
용어와 도구 구조 자체가 유동적: 실제로 공식 플러그인은 짧은 기간 안에 “다수의 서브에이전트 + 스킬” 구조에서 “스킬 전용” 구조로 리팩터링되는 등 세부 구현이 계속 바뀌고 있어, 이 문서에 기술된 세부 사항도 시간이 지나면 달라질 수 있습니다.

참고 자료

Kieran Klaassen & Dan Shipper, “Compound Engineering: How Every Codes With Agents”, Every, 2025.12.11.
Every, “Compound Engineering” 가이드 페이지
EveryInc, compound-engineering-plugin GitHub 저장소
Will Larson, “Learning from Every’s Compound Engineering”, Irrational Exuberance, 2026.01.19.
Kieran Klaassen, “My AI Had Already Fixed the Code Before I Saw It”, Every.
Kieran Klaassen, “Stop Coding and Start Planning”, Every.
Vinci Rufus, “How the Ralph Loop Plays a Key Role in Compound Engineering”
Dan Shipper (@danshipper), Kieran Klaassen (@kieranklaassen) X(트위터) 게시물, 2025.08~2026.01.
NPR, “Tech CEOs say the era of ‘code by AI’ is here. Some software engineers are skeptical”, 2025.10.21.

본 문서는 2026년 7월 기준 공개된 자료를 바탕으로 작성되었습니다. Compound Engineering은 현재도 빠르게 발전 중인 개념이므로, 세부 도구 구성이나 통계는 공식 저장소·원문을 통해 최신 상태를 재확인하는 것을 권장합니다.

목차

개요