배경 및 맥락

최근 AI 코딩에서 병목은 "코드를 쓰는 속도"보다 "무엇을 만들지 정하는 일", "잘못된 구현을 빨리 잡는 일", "한 번 배운 교훈을 다음 세션에서도 재사용하는 일" 쪽으로 이동하고 있다.

Compound engineering은 이 변화에 대한 개발 방법론적 답변이다. 핵심 문장은 간단하다: 각 엔지니어링 작업이 다음 작업을 더 쉽게 만들어야 한다.

Every는 이 철학을 바탕으로 단순 프롬프트-응답식 코딩이 아니라, 계획·실행·검토·지식 축적이 하나의 반복 루프로 이어지는 작업 체계를 제안한다.

핵심 내용

Compound engineering의 기본 루프는 다음과 같다.

1. Plan — 코드베이스, 요구사항, 제약, 외부 문서를 조사하고 구현 계획을 만든다.
2. Work — 에이전트가 계획에 따라 구현하고, 테스트·lint·type check를 반복한다.
3. Review — 여러 전문 리뷰어가 병렬로 결과를 검토하고 우선순위를 매긴다.
4. Compound — 이번 작업에서 배운 교훈을 문서화하고, 다음 세션에서 다시 찾고 재사용할 수 있게 만든다.

이 방법론의 차별점은 4단계다. 보통 AI 코딩은 구현이 끝나면 종료되지만, compound engineering은 문제 해결 과정 자체를 검색 가능한 팀 기억으로 바꾸는 것을 핵심 산출물로 본다.

Every는 이를 plugin 형태로도 배포하고 있으며, CLAUDE.md, docs/solutions/, docs/plans/, todos/ 같은 구조를 통해 에이전트가 매 세션마다 프로젝트의 장기 기억을 다시 읽게 하는 방식을 제안한다.

왜 이 글이 괜찮은가

이 글이 좋은 이유는 단순한 생산성 찬양이 아니라, AI 시대의 엔지니어링 병목이 어디로 이동하는지를 정확히 짚기 때문이다.

핵심 주장은 "AI가 코드를 더 빨리 쓰게 해준다"가 아니다. 오히려 앞으로의 경쟁력은:

• 더 좋은 계획을 만드는 능력
• 더 빠른 검증 루프를 설계하는 능력
• 반복되는 실수를 구조적으로 다시 안 나오게 만드는 능력
• 에이전트가 읽을 수 있는 형태로 팀 지식을 축적하는 능력

에 달려 있다는 것이다.

즉, 개발자의 역할을 코드 작성자에서 시스템 설계자 / 검증 루프 설계자 / 장기 기억 관리자로 재정의한다는 점에서 통찰이 있다.

실전 검증 관점

개념만 보면 추상적으로 느껴질 수 있지만, 후속 실전 사례들도 이 철학이 왜 먹히는지 보여준다.

대표적으로 solo 개발자가 CalcMark를 개발하며 정리한 사례에서는 bug fix와 아키텍처 리뷰, solution docs를 누적하면서 반복되는 문제를 더 빨리 잡는 구조를 만들었다. 여기서 중요한 포인트는 속도 자체보다 문서화된 해결책이 다음 오류를 예방하는 기억 장치로 작동했다는 점이다.

이 관점은 에이전트 시대에 특히 중요하다. 모델은 기본적으로 장기 기억이 약하기 때문에, solution docs, CLAUDE.md, 리뷰 기록 같은 외부 메모리가 있어야만 품질이 누적된다.

실무 적용 포인트

실무에 바로 옮기려면 거창한 체계보다 아래 4가지를 먼저 고정하는 편이 좋다.

• 계획 먼저: 기능 구현 전에 affected files, edge cases, acceptance criteria를 먼저 적는다.
• 격리 실행: branch/worktree 단위로 작업을 분리해 에이전트의 폭주를 막는다.
• 병렬 리뷰: 보안, 성능, 타입 안정성, 아키텍처 관점을 분리해 검토한다.
• 교훈 축적: 버그 원인, 예방 규칙, 리팩터링 이유를 docs/solutions/ 같은 형태로 남긴다.

특히 마지막 단계가 중요하다. "이번에 해결했다"에서 끝나지 않고, **"다음번엔 시스템이 자동으로 더 잘하게 만들었는가"**를 기준으로 보면 compound engineering의 의미가 살아난다.

한 줄 판단

AI 코딩을 더 많이 하게 만드는 글이라기보다, AI 코딩을 오래 지속 가능하게 만드는 운영 철학을 설명하는 글이다. 에이전트 기반 개발을 단순 자동완성의 연장선이 아니라, 계획·검증·기억의 체계로 보려는 사람에게 특히 유용하다.