Compound Engineering — 알고 보면 이미 하고 있는 AI 개발 방법론

방법론은 강력할수록 전제 조건이 있다. 직접 도입하고 롤백하면서 그 조건을 확인했다.

---

📌 먼저 — 개발 방법론 지형 파악

AI 에이전트 시대에 들어서면서 방법론 이야기가 많아졌다. 새로운 이름들이 쏟아지지만, 각각이 다루는 문제가 다르다.

크게 두 축으로 나눌 수 있다.

AI 이전부터 있던 방법론 — 코드 품질과 요구사항 관리를 다룬다.

방법론 핵심 질문 시작점

TDD	테스트를 먼저 써야 코드가 안전하다	실패하는 테스트 코드
BDD	사용자 행동 기준으로 기능을 정의하자	자연어 시나리오 (Given-When-Then)
SDD	코드 작성 전에 명세를 먼저 정의하자	요구사항 명세서, 스펙 문서

AI 에이전트 시대에 등장한 개념 — AI를 어떻게 활용할 것인가를 다룬다.

개념 설명

Vibe Coding	명확한 명세 없이 프롬프트로 즉흥적으로 개발. 프로토타입에는 빠르지만 프로덕션에서는 예측 불가능성 문제 발생
Compound Engineering	매 사이클의 학습을 CLAUDE.md에 축적해 AI가 점점 더 잘 작동하게 만드는 방법론

이것들은 서로 경쟁하는 관계가 아니다. 다루는 레이어가 다르다.

• TDD/BDD/SDD는 "무엇을, 어떤 기준으로 만들 것인가"
• Compound Engineering은 "AI와 함께 어떻게 축적하며 만들어갈 것인가"

SDD와 Compound Engineering은 특히 자주 혼동된다.

• SDD → 스펙을 먼저 정의해서 AI가 제대로 만들게 한다
• Compound Engineering → 만들고 나서 학습을 기록해 다음에 더 잘 만들게 한다

둘은 함께 쓸 수 있고, 실제로 잘 어울린다. SDD로 스펙을 먼저 정의하고, 그 과정에서 생긴 패턴을 Compound로 축적하는 방식이다.

---

📌 Compound Engineering이란

Every.to의 Kieran Klaassen이 AI 에이전트 기반 개발을 하면서 정립한 방법론으로, 핵심 철학은 하나다.

각 기능 개발이 다음 기능 개발을 더 쉽게 만들어야 한다.

전통적인 코드베이스는 기능이 늘어날수록 복잡성이 쌓이면서 느려진다. Compound Engineering은 이것을 뒤집는다. 기능 하나를 완성할 때마다 그 과정에서 발견한 패턴, 실수, 결정을 문서화해서 AI가 다음 세션에 활용하게 한다.

전통적 개발:   기능1 ── 기능2 ── 기능3 ── 기능4  (선형, 점점 느려짐)

Compound:      기능1 ─→ 기능2 ──→ 기능3 ───→ 기능4  (점진적 가속)
                    학습 축적  학습 축적   학습 축적

사이클 구조는 네 단계다.

Plan → Work → Review → Compound → Repeat
                             ↑
              이번 사이클의 학습을 문서화
              → 다음 사이클의 AI 컨텍스트로 축적

처음 세 단계(Plan, Work, Review)는 어떤 개발 방법론에서도 익숙하다. Compound 단계가 이 방법론의 핵심이다. 이 단계를 건너뛰면 AI 지원을 받는 일반적인 개발과 다름없다.

---

📌 Compound를 "따른다"는 것의 실체

별도로 "compound를 따르겠다"고 선언하는 파일이 있는 게 아니다.

컨텍스트 파일 자체가 compound의 저장소다.

기능 하나 완료
    ↓
이번 사이클의 패턴, 실수, 결정을 컨텍스트 파일에 써넣는다
    ↓
다음 세션에서 AI가 그 파일을 읽고 시작한다
    ↓
이전 학습이 자동으로 반영된다

예를 들어 1사이클에서 페이지네이션 누락 버그가 났다면 이렇게 기록한다.

# CLAUDE.md

## 패턴 및 주의사항

### 페이지네이션
목록 API 응답에는 반드시 meta.total, meta.page를 포함할 것.
1사이클 QA 과정에서 누락으로 지적됨.

다음 세션에서 AI가 이 내용을 읽고 시작하기 때문에 같은 실수를 하지 않는다.

Compound Engineering을 따른다는 건 결국 하나의 습관이다.

기능 하나를 완료할 때마다 컨텍스트 파일을 업데이트한다.

이 파일의 이름은 도구마다 다를 뿐, 역할은 같다.

AI 도구 컨텍스트 파일

Claude Code	CLAUDE.md
Cursor	.cursorrules
GitHub Copilot	.github/copilot-instructions.md
Windsurf	.windsurfrules
Codex	AGENTS.md

---

📌 자동으로 되는 게 아니다

처음 이 방법론을 접했을 때 이렇게 이해했다.

"버그가 수정되면 자동으로 기록되고, 다음 사이클에 AI가 자동으로 반영해주겠구나."

틀렸다. compound 단계는 수동 문서화 작업이다.

• 발견한 패턴을 컨텍스트 파일에 직접 써야 한다
• 어떤 결정을 왜 했는지 직접 기록해야 한다
• AI가 읽을 수 있는 형태로 직접 정리해야 한다

공식 플러그인의 /workflows:compound 커맨드가 이 과정을 도와주긴 하지만, 무엇을 기록할지 판단하는 건 여전히 개발자의 몫이다.

---

📌 알고 보니 이미 하고 있었다??

방법론 이름을 보고 뭔가 거창한 걸 기대했는데, 실제로 파고들면 이런 생각이 든다.

"어? 이거 내가 원래 하던 거 아닌가?"

맞다. CLAUDE.md에 "이 프로젝트에서 에러는 이렇게 처리한다", "API 응답 포맷은 이 구조로 통일한다", "DB는 UUID 기본키를 쓴다" 같은 내용을 적어두고 AI가 참조하게 하는 것, 그게 이미 Compound Engineering이다.

Compound Engineering이 새로운 기술이 아니라는 분석도 있다. 잘하는 개발자들이 이미 직관적으로 해오던 것을 명시적인 사이클로 만든 것이 이 방법론의 실체에 가깝다.

그렇다면 이 방법론의 실제 가치는 뭔가?

"기능 완료 → CLAUDE.md 업데이트 → 다음 기능"이라는 흐름을 빠뜨리지 않고 매번 하도록 구조화하는 것이다. 개발하다 보면 바빠서 기록을 미루게 되는데, 사이클의 마지막 단계로 명문화해두면 습관처럼 따르게 된다.

플러그인의 /workflows:compound 커맨드도 결국 "이번에 뭘 배웠는지 기록하는 걸 빠뜨리지 말라"는 리마인더이자 자동화 도구다.

즉 이미 CLAUDE.md를 관리하고 있다면, 당신은 이미 Compound Engineering을 하고 있는 것이다.

---

📌 플러그인과 명령어

플러그인 없이도 방법론 자체는 적용 가능하다. 컨텍스트 파일을 직접 관리하면 된다.

공식 플러그인(EveryInc/compound-engineering-plugin)은 사이클 전체를 커맨드로 자동화한다.

설치 (Claude Code 기준)

claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering

주요 커맨드

/workflows:brainstorm  # 아이디어 → 요구사항 정리
/workflows:plan        # 구현 계획서 생성
/workflows:work        # 코드 구현
/workflows:review      # 전문 에이전트 병렬 코드 리뷰
/workflows:compound    # 이번 사이클 학습을 컨텍스트 파일에 반영

플러그인은 Claude Code 외 Cursor, Copilot, Codex 등 다른 도구 형식으로도 변환을 지원한다.

---

📌 도입하면서 마주한 한계

compound 효과가 작게 느껴지는 프로젝트가 있다

compound의 핵심은 패턴과 학습의 누적이다. 에러 처리 방식, API 응답 포맷, 공통 유틸리티 같은 것들은 기능이 독립적이더라도 누적될 수 있다.

그러나 각 기능이 서로 다른 도메인을 다루고 공통 패턴이 적은 프로젝트에서는 축적되는 학습의 양이 제한적이다. 인증 → 권한 → 프로필 → 대시보드처럼 이전 기능이 다음 기능의 기반이 되는 구조에서 compound 효과가 가장 크게 나타난다.

프로젝트 초기에 설계됐어야 한다

이미 진행 중인 프로젝트에 중간에 얹으면, 기존 히스토리 없이 시작하는 것과 다르지 않다. 축적이 쌓일 기반 자체가 없다.

compound와 작업 추적을 혼동하게 된다

compound 단계를 운영하다 보면 요구사항 상태를 추가하고 관리하고 싶어진다. 그런데 Compound Engineering이 다루는 건 작업 추적이 아니라 AI를 위한 학습의 누적이다.

작업 추적은 Jira나 WBS가 이미 하고 있는 일이고, compound는 그 위에 AI 컨텍스트 관리라는 별도의 레이어를 더하는 것이다. 이 둘을 혼동하면 compound 단계가 단순한 체크리스트 관리로 전락한다.

---

📌 어떤 프로젝트에 적합한가

구분 효과가 큰 프로젝트 효과가 제한적인 프로젝트

기능 간 관계	순차적 의존 (A → B → C 기반)	독립적인 기능들의 집합
공통 패턴	반복되는 패턴이 많음	기능마다 다른 구조
프로젝트 시점	초기 설계 단계	이미 진행 중
운영 기간	장기 반복 개선 제품	단기 구축 후 유지보수 위주

 

 

Compound Engineering이 특히 빛나는 프로젝트 유형

 

* SaaS 플랫폼 — 기능이 기능 위에 쌓이는 구조

 

e-커머스 플랫폼을 예로 들면, 상품 스키마를 구현하면서 DB 컨벤션(UUID 기본키, created_at/updated_at 포함, 가격은 정수 cents로 저장)을 기록한다. 장바구니는 상품 패턴 위에 쌓이고, 결제는 장바구니 패턴 위에 쌓이고, 주문 내역은 결제 패턴 위에 쌓인다. 각 기능이 이전 기능을 더 빠르게 만드는 구조다.

상품 스키마 구현 → DB 컨벤션 기록
    ↓
장바구니 → 상품 패턴 자동 적용
    ↓
결제 → 장바구니 패턴 자동 적용
    ↓
주문 내역 → 결제 패턴 자동 적용

 

---

📌 결론

방법론을 도입하기 전에 물어볼 한 가지 질문이 있다.

"이번 사이클이 완료됐을 때 다음 사이클이 더 빨라지는가?"

이 질문에 "그렇다"고 답할 수 있다면 도입하라.

그렇지 않다면, compound 레이어 자체가 지금 이 프로젝트에서 필요하지 않은 것이다. 작업 추적은 Jira가, 일정 관리는 WBS가 이미 담당하고 있다. Compound Engineering은 그것들을 대체하는 도구가 아니라, AI 에이전트를 쓸 때 학습을 축적하는 별도의 레이어다.

---

참고 링크

• 공식 플러그인: EveryInc/compound-engineering-plugin
• 방법론 원문 가이드: every.to/guides/compound-engineering