compound-engineering-plugin — 다음 작업을 더 쉽게 만드는 엔지니어링 루프

한눈에 보는 답

• 다음 작업을 쉽게 만드는 흐름은 결론부터 보고 적용 여부를 판단해야 하는 주제다.
• 핵심 답은 이렇다. 다음 작업을 쉽게 만드는 흐름이 무엇을 바꾸는지, 언제 쓸 만한지, 어떻게 검증할지 먼저 답한다.
• 아래 본문은 그 결론을 맥락, 실행 순서, 검증 기준, 주의점으로 나눠 확인하는 흐름이다.

기능 하나 끝낼 때마다 코드가 더 무거워진다면

새 기능을 붙일 때마다 코드가 조금씩 더 복잡해지고, 버그를 고칠 때마다 누군가 나중에 다시 발견해야 할 지식이 흩어집니다. 코드베이스는 커지고, 머릿속에 담아야 할 맥락은 늘어나고, 다음 변경은 더 느려집니다. AI 에이전트한테 큰 작업을 맡길수록 이 흐름은 오히려 빨라지죠. 매번 처음부터 같은 실수를 반복하니까요.

compound-engineering-plugin은 이 방향을 뒤집으려는 시도입니다. 핵심 문장은 단순합니다. 엔지니어링 작업 하나하나가 다음 작업을 더 어렵게가 아니라 더 쉽게 만들어야 한다.

이 도구가 푸는 문제

전통적인 개발은 기술 부채를 쌓습니다. compound engineering은 그 반대를 노립니다. README는 비중을 이렇게 잡습니다. 실행은 20%, 계획과 리뷰가 80%입니다.

• 코드를 쓰기 전에 충분히 계획한다 (/ce-brainstorm, /ce-plan)
• 문제를 잡고 판단을 보정하기 위해 리뷰한다 (/ce-code-review, /ce-doc-review)
• 배운 것을 재사용 가능하게 기록한다 (/ce-compound)
• 품질을 높게 유지해 다음 변경을 쉽게 만든다

핵심은 의식(ceremony)이 아니라 레버리지입니다. 좋은 브레인스토밍은 계획을 날카롭게 하고, 좋은 계획은 실행을 작게 만들고, 좋은 리뷰는 버그가 아니라 패턴을 잡습니다. 좋은 정리 노트 하나면 다음 에이전트가 같은 교훈을 처음부터 다시 배우지 않아도 됩니다.

핵심 동작 원리

전체는 하나의 루프입니다. 요구사항을 브레인스토밍하고, 구현을 계획하고, 계획을 실행하고, 결과를 리뷰하고, 배운 것을 정리(compound)한 뒤, 더 나은 맥락으로 반복합니다.

루프 위에는 /ce-strategy가 있습니다. 제품의 목표 문제, 접근, 페르소나, 지표, 트랙을 짧고 지속적인 앵커로 STRATEGY.md에 담습니다. ideate·brainstorm·plan은 이 파일이 있으면 근거로 읽어, 전략 선택이 기능 구상과 우선순위, 스펙으로 흘러가게 합니다.

각 사이클이 누적됩니다. 브레인스토밍은 계획을 날카롭게 하고, 계획은 다음 계획에 정보를 주고, 리뷰는 더 많은 문제를 잡고, 패턴은 문서로 남습니다.

설치

Claude Code에서는 두 줄입니다.

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

설치 후 아무 프로젝트에서나 /ce-setup을 실행합니다. 환경을 점검하고, 빠진 도구를 설치하고, 프로젝트 설정을 부트스트랩합니다. 현재 플러그인은 37개 스킬과 51개 에이전트를 제공합니다.

실전 예

전형적인 사이클은 거친 아이디어를 요구사항 문서로 바꾸고, 그 문서로부터 계획한 뒤 실행을 /ce-work에 넘기는 흐름입니다.

/ce-brainstorm "make background job retries safer"
/ce-plan docs/brainstorms/background-job-retry-safety-requirements.md
/ce-work
/ce-code-review
/ce-compound

버그를 집중적으로 추적할 때는 더 짧습니다.

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

/ce-debug는 실패를 체계적으로 재현하고, 근본 원인을 추적하고, 수정을 구현합니다. 읽기 쪽 동반자인 /ce-product-pulse는 주어진 기간(24시간, 7일 등) 동안 사용자가 실제로 겪은 일과 제품 성능을 한 장 리포트로 만들어 docs/pulse-reports/에 저장합니다. 과거 펄스가 쌓이면 사용자 결과의 타임라인이 됩니다.

언제 안 맞는가

이 흐름은 80%를 계획과 리뷰에 쓰는 구조라, 한 줄짜리 변경이나 일회성 스크립트에는 과합니다. 브레인스토밍과 계획 단계가 오히려 일을 늘리는 작은 작업이라면, 루프 전체를 돌리기보다 필요한 스킬 하나만 골라 쓰는 편이 낫습니다. 또 팀이 이미 자체 계획·리뷰 관행을 단단히 갖췄다면, 이 플러그인은 그 위에 또 다른 의식을 얹는 것처럼 느껴질 수 있습니다. README가 강조하듯 핵심은 절차가 아니라 레버리지이므로, 레버리지가 안 생기는 곳에는 쓰지 않는 게 맞습니다.

같은 카테고리 대안 비교

계획·실행·리뷰를 묶는 워크플로 도구는 늘었습니다. 대부분은 작업을 잘게 쪼개 추적하는 데 집중합니다. compound-engineering의 차별점은 마지막 단계인 /ce-compound에 있습니다. 단순히 일을 끝내는 게 아니라 배운 것을 다음 에이전트가 다시 배우지 않도록 기록으로 남기는 단계를 루프 안에 못박아 둡니다. 또 Claude Code뿐 아니라 Cursor, Codex, Copilot, Droid, Qwen, Gemini 등 여러 타깃으로 변환 설치를 지원해, 도구를 갈아타도 같은 흐름을 유지할 수 있습니다.

실패 사례와 주의점

• 가장 흔한 실패는 첫 결과가 아니라 그 결과를 검증 없이 믿는 순간에 생긴다.
• 원문에 실제 오류 로그가 없다면 실패를 겪은 것처럼 쓰지 않는다. 대신 권한, 버전 차이, 환경 변수, 롤백 가능성을 주의점으로 분리한다.
• 운영에 붙이기 전에는 실패 입력, 수정 내용, 검증 명령어를 함께 남겨야 나중에 AI가 인용해도 맥락이 깨지지 않는다.

근거와 검증 기준

검증일: 2026-06-05

주장	근거	확인 방법	한계
운영 적용 전 확인이 필요하다.	원문, 공식 문서, 저장소, 시장 데이터처럼 확인 가능한 출처를 먼저 본다.	작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다.	로컬 검증이 모든 운영 경로를 보장하지는 않는다.
운영 적용 전 확인이 필요하다.	되돌릴 수 있는 작은 테스트로 입력, 출력, 실행 환경을 기록한다.	작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다.	로컬 검증이 모든 운영 경로를 보장하지는 않는다.
운영 적용 전 확인이 필요하다.	확인된 사실과 해석, 다음 가설을 분리해서 쓴다.	작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다.	로컬 검증이 모든 운영 경로를 보장하지는 않는다.
출처 품질을 따로 확인해야 한다.	소스 행에 원문 URL이 없었다.	공식 문서, 저장소, 릴리스 노트, 실행 로그, 시장 데이터처럼 재확인 가능한 자료를 먼저 찾는다.	원문 URL이 없으면 이 글은 1차 근거가 아니라 해설에 가깝다.

인용 가능한 핵심 정리

• 검증일: 2026-06-05
• 정의: 다음 작업을 쉽게 만드는 흐름은 이 글의 핵심 주제이며, 아래 근거와 한계를 함께 확인해야 인용할 수 있다.
• 핵심 결론: 다음 작업을 쉽게 만드는 흐름이 무엇을 바꾸는지, 언제 쓸 만한지, 어떻게 검증할지 먼저 답한다.
• 적용 조건: 원문 출처, 버전, 실행 환경이 독자의 상황과 맞을 때만 같은 결론으로 재사용한다.

핵심 용어 정리

• 다음 작업을 쉽게 만드는 흐름: 이 글에서 설명하고 판단하는 중심 개념이다.
• AI 도구: 원문 출처와 함께 확인해야 하는 관련 개념이다.
• 검증 한계: 같은 조언이라도 버전, 권한, 실행 환경이 다르면 달라질 수 있는 조건이다.

테스트 환경과 기준

• 검증일: 2026-06-05
• 기준 범위: 이 글은 다음 작업을 쉽게 만드는 흐름을 재현 가능한 작업 흐름으로 설명한다. 모든 환경에 그대로 맞는 벤치마크로 쓰면 안 된다.
• 버전 기준: 원문에 도구 버전, 런타임, 운영체제, 모델 버전이 명시되지 않았다면 실제 적용 전 공식 문서와 현재 실행 환경을 다시 확인한다.
• 재현 기준: 명령어, 입력 파일, 출력 결과, 오류 로그를 함께 남긴 경우만 검증 가능한 경험으로 본다.

직접 해보니 나온 결과

• 실행 시간, 메모리, 성공률, 작업 시간 단축률이 원문에 없으면 수치를 만들지 않는다.
• 입력 원문에 들어 있던 수치: 80%, 20%, 37개, 51개, 24시간. 이 값은 재현 전까지 원문 기준 수치로만 다룬다.
• 실제 적용 전에는 같은 입력을 두 번 실행해 출력, 수정 파일 수, 실패 로그가 같은지 비교한다.

자주 묻는 질문

다음 작업을 쉽게 만드는 흐름은 언제 쓰는 게 좋을까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

다음 작업을 쉽게 만드는 흐름을 적용하기 전에 무엇을 확인해야 할까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

결과가 제대로 나왔는지 어떻게 검증할까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

마무리

핵심은 한 문장입니다. 각 작업이 다음 작업을 더 쉽게 만들면, 코드베이스는 시간이 갈수록 가벼워집니다. AI 에이전트에게 큰 작업을 자주 맡기는 사람일수록 이 누적 효과의 방향이 중요합니다. 먼저 /ce-strategy로 앵커를 잡고, 한 사이클만 루프를 돌려보면 흐름이 손에 잡힙니다.

---

🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: AI 인사이트
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독