보통 소프트웨어 개발은 이렇다.
기능 하나 추가한다. 잘 동작한다. 기능 하나 더 추가한다. 첫 번째 기능이랑 충돌한다. 셋째 기능을 추가하면 첫째와 둘째 둘 다 건드려야 한다.
코드가 쌓일수록 새로운 기능은 점점 어려워진다. 엣지 케이스가 늘고, 의존성이 꼬이고, 모르는 사이드 이펙트가 터진다. 10년 된 코드베이스에서 일해본 사람이면 안다. 새 기능 만드는 시간보다 기존 코드 파악하는 시간이 더 길다.
이걸 뒤집겠다는 게 Compound Engineering이다.
뭔데
Compound Engineering은 2025년 12월, Every(미디어+소프트웨어 회사)의 CEO Dan Shipper와 CTO Kieran Klaassen이 제안한 방법론이다.
핵심 철학은 한 줄이다.
각 작업 단위가 다음 작업을 더 쉽게 만들어야 한다.
기존 엔지니어링에서는 기능이 추가될수록 복잡도가 올라간다. Compound Engineering에서는 기능이 추가될수록 에이전트의 학습이 축적되어 다음 기능이 더 빨라진다.
이자가 이자를 낳는 복리(compound interest)처럼, 엔지니어링 작업이 쌓이면서 생산성이 복리로 증가한다는 의미다.
왜 지금 나왔나
AI 코딩 에이전트가 강력해졌다. Every에서는 이미 아무도 수동으로 코드를 타이핑하지 않는다. 5개의 소프트웨어 제품을 운영하는데, 각 제품의 개발과 운영을 한 명이 담당한다. 몇 년 전 같으면 다섯 명이 할 일을 한 명이 한다고 한다.
근데 문제가 있다. AI 에이전트는 같은 실수를 반복한다. 어제 잡은 버그를 오늘 또 만든다. 지난주에 발견한 성능 이슈를 이번 주에 같은 패턴으로 다시 일으킨다.
왜? 학습이 체계적으로 기록되지 않으니까. 컨텍스트 윈도우가 리셋되면 에이전트는 처음부터 다시 시작한다.
Compound Engineering은 이 문제를 해결한다.
4단계 워크플로우
Compound Engineering은 Plan → Work → Review → Compound의 4단계 루프다.
1. Plan (계획) — 전체 시간의 약 40%
에이전트에게 "이거 구현해"라고 바로 시키지 않는다.
먼저 기존 코드베이스 구조를 분석시킨다. 커밋 히스토리를 읽게 한다. 관련 외부 모범 사례를 조사시킨다. 그 결과를 종합해서 상세한 구현 계획서를 작성하게 한다.
이 계획서에는 아키텍처 결정, 코드 패턴, 성공 기준이 포함된다.
개발자의 역할은 이 계획서를 검토하고 승인하는 것이다. 코드를 타이핑하는 게 아니라, 방향을 잡는 것.
2. Work (실행) — 전체 시간의 약 10%
에이전트가 실제로 코드를 작성한다. 계획이 충분히 상세하면 이 단계가 놀라울 정도로 짧다.
3. Review (검토) — 전체 시간의 약 30%
여기가 재밌다. 사람이 직접 코드 리뷰를 한 줄씩 하는 게 아니다.
다중 에이전트가 병렬로 코드를 검토한다. Every에서는 Compound Engineering 플러그인이 12개의 서브 에이전트를 동시에 돌린다.
- 보안 이슈 체크
- 성능 문제 체크
- 오버 엔지니어링 체크
- 코드 복잡도 체크
- 일관성 체크
각 관점별로 검토 결과가 종합되고, 개발자는 뭘 고칠지, 뭘 무시할지 판단한다.
이전에 작성한 "Mole" 글에서 비유하자면 mo clean --dry-run처럼 미리 확인하고 결정하는 것과 비슷하다. 무조건 삭제하는 게 아니라, 뭘 할지 보여주고 판단은 사람이 한다.
그리고 당연히 린터, 유닛 테스트 같은 전통적인 도구도 같이 쓴다.
4. Compound (축적) — 전체 시간의 약 20%
이 단계가 핵심이다. 다른 방법론과 차별화되는 지점이기도 하다.
코드 리뷰에서 나온 피드백을 에이전트에게 요약시킨다. 그 결과를 CLAUDE.md나 AGENTS.md에 기록한다.
"이 프로젝트에서 인증 로직은 항상 미들웨어에서 처리한다." "이 테이블의 timestamp는 UTC로 저장한다." "이 컴포넌트에서 상태 관리는 Zustand를 쓴다."
이런 학습들이 파일로 축적된다. 다음 루프에서 에이전트는 이 파일을 읽고 시작한다. 같은 실수를 반복하지 않게 된다.
한 명이 발견한 교훈이 팀 전체에 자동으로 배포된다. 코드베이스에 프롬프트와 컨벤션으로 들어가 있으니까. 새로 합류한 사람도 첫날부터 같은 수준의 가드레일을 적용받는다.
기존 방식과 뭐가 다른가
| 기존 엔지니어링 | Compound Engineering | |
| 기능 추가 시 | 복잡도 증가 | 학습 축적으로 생산성 증가 |
| 코드 품질 노하우 | 시니어 개발자 머릿속에 있음 | 문서화되어 에이전트가 참조 |
| 코드 리뷰 | 수동 라인별 검토 | 자동화 검증 + 사람의 판단 |
| 신규 팀원 온보딩 | 수개월 걸림 | 축적된 학습으로 즉시 적용 |
| 개발자 역할 | 코드 작성자 | 기술 디렉터 |
현실적인 이야기
솔직히, 이 방법론이 완전히 새로운 건 아니다.
"실수에서 배우고 문서화하자"는 원래 좋은 엔지니어링 조직이 해오던 것이다. 코드 리뷰 가이드라인, 아키텍처 의사결정 기록(ADR), 스타일 가이드 같은 것들.
Compound Engineering이 다른 점은, 이 문서화의 소비자가 사람이 아니라 AI 에이전트라는 것이다. 사람은 긴 스타일 가이드를 읽다가 지치고 까먹는다. AI는 매번 정확히 읽고 따른다. 그래서 문서화의 ROI가 극적으로 달라진다.
그리고 모든 팀에 바로 적용할 수 있는 건 아니다. AI 코딩 에이전트를 실제로 개발 파이프라인에 통합한 팀이어야 의미가 있다. Claude Code 써본 적 없는 팀이 Compound Engineering을 도입한다는 건 좀 순서가 뒤바뀐 것이다.
Ralph Loop와의 관계
이전 글에서 다룬 Ralph Loop와 Compound Engineering은 상호보완적이다.
Ralph Loop는 실행 패턴이다. 에이전트를 루프에 넣고 반복 실행한다. 매 루프마다 컨텍스트를 리셋해서 context rot를 방지한다.
Compound Engineering은 그 루프 위에 학습 계층을 올린다. 매 루프에서 발생한 실패와 교훈을 기록하고, 다음 루프의 에이전트가 더 나은 상태에서 시작하게 만든다.
Ralph Loop 없이 Compound Engineering만 하면? 에이전트가 긴 세션에서 context rot에 빠져서 축적된 학습을 제대로 활용하지 못할 수 있다.
Compound Engineering 없이 Ralph Loop만 하면? 같은 실수를 매 루프마다 반복할 수 있다.
시작하기
관심 있다면 Every가 공개한 Compound Engineering 플러그인이 있다. GitHub에서 오픈소스로 관리되고 있고, Claude Code 기반이다.
# Claude Code에서 플러그인 설치
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering
설치 후 프로젝트에서 /ce-setup을 실행하면 환경을 점검하고, 필요한 도구를 설치하고, 프로젝트 설정을 부트스트랩한다.
Claude Code 외에도 Codex, Gemini CLI, GitHub Copilot, Cursor 등 다양한 도구로 변환 가능하다.
# Codex 형식으로 변환
bunx @every-env/compound-plugin install compound-engineering --to codex
# GitHub Copilot 형식으로 변환
bunx @every-env/compound-plugin install compound-engineering --to copilot
전체 파이프라인을 한 명령어로 실행할 수도 있다.
plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
계획 승인에서 한 번 멈추고, 이후 자율 실행. 전체 과정에서 50개 이상의 에이전트가 동시에 작동한다.
이걸 한 명의 개발자가 관리한다.
정리
Compound Engineering의 핵심 아이디어는 세 가지다.
- 작업마다 학습을 문서로 축적한다. CLAUDE.md, AGENTS.md 같은 파일에 컨벤션, 패턴, 실수 교훈을 쌓는다.
- 맛(taste)은 시스템에 넣는다. 시니어 개발자의 판단을 코드 리뷰 때마다 전수하는 게 아니라, 에이전트가 읽을 수 있는 설정과 규칙으로 인코딩한다.
- 시스템을 가르치는 데 시간을 쓴다. 코드를 직접 타이핑하는 시간은 10%. 나머지 90%는 계획, 검토, 학습 축적이다.
결국 개발자의 역할이 바뀐다는 것이다. 코드를 쓰는 사람에서, 코드를 쓰는 시스템을 설계하는 사람으로
참고:
- Every 블로그 (원문): https://every.to/chain-of-thought/compound-engineering-how-every-codes-with-agents
- Compound Engineering 가이드: https://every.to/guides/compound-engineering
- 플러그인 GitHub: https://github.com/EveryInc/compound-engineering-plugin
'IT' 카테고리의 다른 글
| Claude Mythos Preview System Card - Anthropic이 자사 최강 모델을 공개하지 않기로 한 이유 (3) | 2026.04.14 |
|---|---|
| Harness Engineering - 모델을 바꾸지 않고 코딩 에이전트 성능을 52%에서 66%로 올렸다 (0) | 2026.04.14 |
| Ralph Loop - AI 코딩 에이전트를 Bash 루프에 넣었더니 자고 일어나면 코드가 완성돼 있다 (0) | 2026.04.14 |
| Mac 청소, 터미널에서 한 번에 끝내기 (0) | 2026.02.24 |
| OpenClaw에 Claude API 대신 Groq를 쓰는 이유 (0) | 2026.02.10 |
