코드를 짜면 지는 겁니다

저는 코드를 잘 짜는 게 좋은 개발자의 조건이라고 생각했어요. 근데 요즘 이 생각이 흔들립니다. Every라는 회사가 "Compound Engineering"이라는 AI 네이티브 개발 철학을 공개했는데요. 이거 읽으면서 좀 머리를 맞은 느낌이었어요.

한 줄 요약하면 이거예요. "코드를 짜는 게 일이 아니라, 코드를 잘 짜는 시스템을 만드는 게 일이다." 매번 코드를 직접 치는 게 아니라, AI 에이전트가 알아서 잘 짜도록 시스템을 세팅하라는 거예요. 그리고 그 시스템이 쓸수록 좋아지게 만들라는 거예요. 복리처럼요.

솔직히 처음 들었을 때 "또 AI 만능론이네" 싶었어요. 근데 읽어보니까 만능론이 아니었어요. 오히려 개발자가 더 많이 생각해야 한다는 이야기였거든요. 오늘은 이 Compound Engineering이 뭔지, 그리고 현실에서 어떻게 쓸 수 있는지 정리해볼게요.

AI 네이티브 엔지니어링 개발 환경

왜 지금 이 얘기가 나오는 건가

Every라는 회사가 있어요. Cora라는 AI 비서 제품을 만드는 곳인데요. 이 팀이 특이해요. 제품 5개를 거의 1인 엔지니어링 팀으로 운영하고 있거든요. 한 명이 한 제품을 맡아요. 보통 이러면 유지보수도 못 할 텐데, 이 팀은 오히려 빠르게 기능을 찍어내고 있어요.

비밀이 뭘까요. AI 에이전트를 써서요? 그건 요즘 다 하잖아요. 이 팀이 다른 건 "AI와 일하는 시스템" 자체를 만들었다는 거예요. 그냥 Claude Code 쓰는 게 아니라, 26개 전문 에이전트, 23개 워크플로우 커맨드, 13개 스킬을 묶어서 플러그인으로 배포했어요. Claude Code에 설치하면 바로 쓸 수 있어요.

근데 플러그인 자체보다 더 중요한 게 있어요. 이 팀이 기존 개발의 8가지 통념을 버려야 한다고 선언한 거예요. "코드는 손으로 짜야 한다", "모든 라인을 직접 리뷰해야 한다" 같은 것들이요. 이건 단순한 도구 소개가 아니라 개발 철학 자체를 바꾸자는 제안이에요.

긱뉴스에서도 37포인트를 받으면서 꽤 주목받았는데요. 댓글 반응을 보면 공감하는 사람도 있고, "현실과 동떨어졌다"는 시각도 있어요. 저도 읽으면서 동의하는 부분과 "글쎄..."한 부분이 있었어요. 그래서 오늘은 원문을 그대로 전달하는 게 아니라, 현업에서 쓸 수 있는 것과 조심해야 할 것을 구분해서 정리했어요.

Compound Engineering의 핵심 — 4단계 루프

원문이 굉장히 긴데요. 핵심은 이 4단계 루프예요.

Plan → Work → Review → Compound

처음 세 단계는 익숙하죠. 계획하고, 실행하고, 리뷰한다. 모든 개발 방법론이 하는 거예요. 근데 네 번째 "Compound"가 이 철학의 차별점이에요.

눈에 띄는 게 있죠. Plan과 Review에 80%를 쓰라고 해요. 실제로 코드를 짜는 Work는 10%밖에 안 돼요. 이전 뉴스레터에서 "AI 잘 쓰는 사람은 처음에 느리다"고 했는데, 정확히 같은 맥락이에요. 코드를 빨리 짜는 게 핵심이 아니라, 계획과 리뷰에 시간을 쓰는 게 핵심이라는 거죠.

Plan — 계획이 곧 코드다

Every 팀은 "계획이 새로운 코드"라고까지 말해요. 좀 과하다 싶지만, 논리는 이래요.

AI 시대에 계획 문서가 가장 중요한 산출물인 이유

예전에는 코드를 먼저 짜고 나중에 문서화했잖아요. 이제는 순서가 바뀌어요. 계획을 먼저 작성하면, 그게 에이전트가 코드를 생성하고 테스트하는 소스 오브 트루스(source of truth)가 돼요.

왜 이게 유리하냐면요. 종이 위에서 아이디어를 고치는 게, 코드에서 고치는 것보다 훨씬 싸기 때문이에요. 계획 단계에서 "이 접근법은 안 될 것 같아"라고 판단하면 코드 한 줄 안 짜고 방향을 바꿀 수 있어요. 구현 후에 바꾸면? 다 갈아엎어야 해요.

제 강의 Ch3에서 "탐색 → 설계 → 구현 → 커밋" 순서를 가르치는데요. 정확히 같은 원리예요. 설계 없이 "만들어줘"라고 하면 AI가 교과서적인 코드를 뱉어요. 그리고 그건 현실에서 거의 안 맞아요.

Every 팀은 여기서 한 단계 더 나가요. /workflows:plan 커맨드를 치면 3개의 리서치 에이전트가 동시에 돌아요.

그리고 ultrathink 모드를 켜면 40개 이상의 리서치 에이전트가 병렬로 가동된다고 해요. 이건 솔직히 좀 과하다 싶긴 한데, 핵심은 "계획 단계에서 조사에 투자하라"는 거예요.

이전 뉴스레터에서 Boris Cherny가 "Plan Mode를 빼면 Claude Code를 절반만 쓰는 거"라고 했잖아요. Every 팀은 그 Plan Mode를 시스템화한 거예요. 사람이 매번 "일단 조사해봐"라고 치는 게 아니라, 커맨드 하나로 자동화한 거죠.

Work — 에이전트가 구현한다

계획이 끝나면 /workflows:work로 구현에 들어가요. 여기서 핵심은 "계획을 신뢰하면 코드를 한 줄 한 줄 감시할 필요 없다"는 거예요.

Git Worktree로 격리 환경 만들기

Every 팀은 모든 작업을 Git Worktree로 격리해요. 워크트리가 뭐냐면, 하나의 레포에서 격리된 복사본을 만드는 거예요. 이전 뉴스레터에서 Boris Cherny 팀이 "3~5개 워크트리를 동시에 돌린다"고 했죠. Every 팀도 같은 패턴이에요.

# 워크트리 생성
git worktree add ../myapp-feature-a feature-a

# 이 워크트리에서 Claude Code 실행
cd ../myapp-feature-a && claude

이렇게 하면 메인 코드베이스를 건드리지 않고 실험할 수 있어요. 망하면? 워크트리만 삭제하면 돼요. 본 프로젝트는 깨끗해요.

실행 후 자동 검증

Every 팀이 강조하는 게 "변경 후마다 테스트, 린팅, 타입 체크를 돌리라"는 거예요. 이건 제 이전 뉴스레터 "AI가 짠 코드를 믿지 마라"에서 한 이야기와 100% 같아요. AI가 만든 코드를 그대로 믿으면 안 돼요. 자동 검증 시스템이 있어야 해요.

Review — 14개 에이전트가 동시에 리뷰한다

이 부분이 제일 인상적이었어요. /workflows:review를 치면 14개 이상의 전문 리뷰 에이전트가 병렬로 코드를 분석해요.

그리고 발견된 이슈를 P1(필수 수정), P2(권장 수정), P3(개선 사항)으로 분류해요. P1은 반드시 고쳐야 하고, P3는 "시간 되면 해"인 거죠.

이게 왜 중요하냐면요. 이전 뉴스레터에서 "Writer/Reviewer 패턴"을 다뤘잖아요. AI가 코드를 짜면, 다른 AI가 검증하는 패턴이요. Every 팀은 이걸 극한까지 밀어붙인 거예요. Reviewer를 1개가 아니라 14개를 돌리고, 각각 전문 분야를 나눠서요.

솔직히 개인 프로젝트에서 14개 에이전트를 돌리는 건 과할 수 있어요. 근데 핵심은 "리뷰를 자동화할 수 있다"는 사고방식이에요. 보안 리뷰어 하나, 성능 리뷰어 하나, 이 정도만 만들어도 코드 품질이 확 올라가요.

협업과 리뷰 프로세스

Compound — 진짜 차별점

4단계 중 마지막이면서 가장 중요한 단계예요. 대부분의 개발은 3단계(리뷰)에서 끝나요. 기능 만들고, 리뷰하고, 머지하고 끝. 근데 Every 팀은 여기서 한 단계를 더 추가해요.

"오늘의 삽질이 내일의 자산이 되게 하라"

Compound 단계에서 하는 일은 이거예요:

이건 이전 뉴스레터에서 다뤘던 것들과 맥이 통해요. Boris Cherny가 "CLAUDE.md를 AI가 직접 쓰게 하라"고 했잖아요. Mitchell Hashimoto의 "하네스 엔지니어링"도 같은 원리예요. 실수를 시스템으로 막아라.

Every 팀은 이걸 커맨드 하나로 자동화한 거예요. /workflows:compound를 치면 6개의 서브에이전트가 돌면서:

이 문서가 docs/solutions/에 쌓여요. 그러면 나중에 비슷한 문제가 생겼을 때, 에이전트가 과거 해결책을 자동으로 참조할 수 있어요. 이게 "복리"예요. 오늘 해결한 문제가 내일의 해결 속도를 높여주는 거죠.

전통적인 개발에서는 이런 지식이 어디 있었냐면요. 사람 머릿속에 있었어요. "이거 Sarah한테 물어봐, auth 잘 알아" 이런 식이었잖아요. Sarah가 회사를 떠나면? 그 지식은 사라져요. Compound 단계는 이런 부족 지식(tribal knowledge)을 시스템에 축적하는 거예요.

버려야 할 8가지 믿음

Every 팀이 제시한 것 중에서 가장 논쟁적인 파트예요. 기존 개발자의 핵심 신념을 정면으로 부정하거든요.

핵심만 뽑으면 이거예요

채택해야 할 새로운 믿음

Every 팀이 제시하는 대안은 이거예요:

1. 취향을 시스템에 인코딩하라

네이밍 규칙, 에러 처리 패턴, 테스트 접근 방식... 이런 "취향"이 보통 시니어 머릿속에만 있잖아요. 코드 리뷰할 때 "이건 우리 스타일이 아니야"라고 말하면서 전달되는 거요. 이걸 CLAUDE.md에 써놓으면 AI가 처음부터 "우리 스타일"로 코드를 짜요.

2. 50/50 규칙

시간의 50%는 기능 개발, 50%는 시스템 개선에 쓰라는 거예요. 전통적으로는 90%가 기능이고 10%가 나머지잖아요. 근데 리뷰 에이전트 1시간 투자가 1년간 10시간의 리뷰 시간을 절약한다는 논리예요.

3. 계획이 새로운 코드다

코드 먼저 짜고 문서화하는 게 아니라, 계획을 먼저 쓰면 에이전트가 코드를 생성하고 테스트하는 소스 오브 트루스로 활용해요.

개발자 성장 5단계 — 나는 어디에 있나?

Every 팀이 개발자의 AI 도입 수준을 0~5단계로 나눴어요. 이게 꽤 유용해요. 자기가 어디에 있는지 알아야 다음 단계로 갈 수 있으니까요.

Every 팀은 대부분의 개발자가 Stage 2에서 정체된다고 해요. Claude Code를 쓰긴 하는데, AI가 제안하는 모든 것을 하나하나 승인/거절하면서 게이트키퍼 역할을 하는 거죠. 이러면 AI의 속도 이점을 못 누려요.

진짜 전환은 Stage 3에서 일어나요. 계획을 먼저 세우고, AI한테 구현을 맡기고, PR 수준에서 리뷰하는 거예요. 라인별로 감시하지 않고요. 그리고 Compound Engineering이 여기서부터 시작돼요. 매 사이클이 시스템을 학습시키니까요.

각 단계를 올라가는 핵심

2 → 3 (가장 중요한 전환):

3 → 4:

Every 팀은 레벨업이 순차적이어야 한다고 강조해요. 단계를 건너뛰면 도구를 불신하게 되고, 결국 포기한다고요. 이건 이전 뉴스레터 "AI 잘 쓰는 사람은 처음에 느리다"에서 Mitchell Hashimoto가 한 말과 정확히 같아요. 처음에 느리더라도 단계를 밟아야 해요.

AI 산출물 승인 전 3가지 질문

어떤 단계에 있든 이 3가지를 물어보면 품질이 올라간다고 해요:

이건 바로 써먹을 수 있는 팁이에요. 특별한 세팅 없이, 프롬프트 3줄만 추가하면 돼요.

팀 협업과 시스템 빌딩

에피의 시선 — 솔직히 이렇게 느꼈습니다

이 글을 읽으면서 솔직히 감정이 왔다 갔다 했어요.

공감한 부분부터 말하면요. "코드를 짜는 게 일이 아니라 시스템을 짜는 게 일이다"는 맞다고 생각해요. 저도 현업에서 CLAUDE.md를 세팅하고, 워크트리를 나누고, 검증 프로세스를 만들면서 "이게 진짜 일이구나"를 느끼거든요. 코드를 치는 시간보다 계획하고 리뷰하는 시간이 더 길어졌어요. 그리고 그게 결과적으로 더 좋은 코드를 만들어요.

"첫 시도 불량률 95%"라는 것도 진짜예요. AI가 만든 코드가 한 번에 완벽한 경우는 거의 없어요. 근데 이게 AI의 한계가 아니라 프로세스라는 관점은 처음 들었는데 설득력 있어요. 첫 시도가 별로인 걸 탓하지 말고, 세 번째 시도가 빨리 나오게 시스템을 만들라는 거잖아요.

근데 좀 동의 못 하는 부분도 있어요.

"모든 라인을 직접 리뷰하지 않아도 된다"는 건... 글쎄요. Every 팀은 14개 리뷰 에이전트를 병렬로 돌리니까 가능한 얘기예요. 자동화된 안전망이 탄탄하니까요. 근데 대부분의 개발자는 그 수준의 안전망이 없잖아요. 리뷰 에이전트 하나 없는 상태에서 "직접 리뷰하지 마라"를 따르면 사고가 나요. 순서가 중요해요. 안전망을 먼저 만들고, 그 다음에 직접 리뷰를 줄이는 거지, 안전망 없이 손을 놓으면 안 돼요.

"코드는 자기 표현이 아니다"라는 것도요. 논리적으로는 맞아요. 코드는 팀의 것이고 사용자의 것이죠. 근데 현실에서 좋은 코드를 쓰는 사람들은 대부분 코드에 애착이 있는 사람들이에요. 그 애착이 꼼꼼함을 만들거든요. "어차피 에이전트가 짠 거니까"라는 태도가 퍼지면, 리뷰의 질도 떨어질 수 있어요. 코드에 대한 책임감과 AI 위임 사이의 균형을 찾는 게 중요하다고 생각해요.

그리고 50/50 규칙은 이상적이긴 한데요. 시간의 50%를 시스템 개선에 쓰라는 건... 스타트업에서 기능을 빠르게 찍어내야 하는 상황에서는 현실적으로 어려워요. Every 팀이 1인 엔지니어링 팀이라 가능한 거지, 10명짜리 팀에서 모두가 50%를 시스템 개선에 쓰면 PM이 가만 안 있을 거예요. 현실적으로는 20~30% 정도가 적당하지 않을까 생각해요.

결론적으로, 이 글은 "방향성"으로는 맞아요. AI와 일하는 시스템을 만들어야 한다, 매 작업이 다음 작업을 쉽게 만들어야 한다. 이건 진짜예요. 근데 "수위"는 각자 조절해야 해요. Every 팀처럼 14개 에이전트를 한 번에 돌릴 필요는 없어요. CLAUDE.md 하나 잘 세팅하는 것부터 시작해도 충분히 복리 효과를 느낄 수 있어요.

오늘 바로 해보세요

원문이 엄청 길고 컨셉도 방대하지만, 당장 쓸 수 있는 건 세 가지예요.

1. AI 산출물에 3가지 질문하기 (1분)

다음 작업에서 AI가 코드를 만들면, 머지하기 전에 이걸 물어보세요:

1. "여기서 가장 어려운 결정은 뭐였어?"
2. "어떤 대안을 거부했고, 왜?"
3. "가장 확신이 없는 부분은?"

특별한 세팅 필요 없어요. 프롬프트 3줄이면 돼요. 근데 AI가 자기 결정의 근거를 드러내면, 리뷰할 때 어디를 집중적으로 봐야 하는지가 보여요.

2. Compound 습관 만들기 (5분)

작업이 끝날 때마다 이 한 마디를 추가하세요:

"지금 해결한 문제를 CLAUDE.md에 기록해. 
다음에 비슷한 문제가 생기면 참고할 수 있게."

이전 뉴스레터에서 "CLAUDE.md를 AI가 직접 쓰게 하라"고 했죠. 그걸 해결한 문제 기록으로 확장하는 거예요. 일주일만 해보세요. CLAUDE.md에 프로젝트 고유의 노하우가 쌓이는 게 보일 거예요.

3. 리뷰 프롬프트 하나 만들기 (10분)

.claude/skills/ 디렉토리에 리뷰어 하나만 만들어보세요:

<!-- .claude/skills/security-review.md -->
# 보안 리뷰

## 체크할 것
1. SQL 인젝션 가능성 — 사용자 입력이 쿼리에 직접 들어가는지
2. 인증/인가 — 권한 체크가 빠진 엔드포인트가 있는지  
3. 민감 정보 노출 — 로그에 비밀번호나 토큰이 찍히는지
4. XSS — 사용자 입력이 HTML에 이스케이프 없이 렌더링되는지

## 출력 형식
- P1 (필수 수정): 보안 위험이 있는 것
- P2 (권장 수정): 잠재적 위험이 있는 것
- P3 (개선 사항): 베스트 프랙티스와 다른 것

Every 팀이 14개 에이전트를 돌린다고 했잖아요. 여러분은 하나만 만들면 돼요. 보안이든 성능이든, 가장 신경 쓰이는 영역 하나. 이게 Compound Engineering의 시작이에요.

마무리

Compound Engineering을 한 줄로 요약하면요:

사실 이 개념은 새로운 게 아니에요. "일하는 방식을 개선하라"는 건 도요타 생산 시스템부터 있던 거예요. 근데 AI 에이전트가 나오면서 이게 소프트웨어 개발에서도 진짜 가능해진 거예요. CLAUDE.md에 규칙을 추가하면 다음 세션부터 바로 적용되고, Skill을 만들면 반복 작업이 사라지고, 해결한 문제를 기록하면 다음에 같은 문제를 안 겪어요.

모든 걸 한 번에 적용할 필요는 없어요. CLAUDE.md에 오늘의 실수 하나를 기록하는 것부터 시작하세요. 그게 복리예요.

다음 뉴스레터에서도 바이브 코딩과 Claude Code 관련 실전 인사이트를 가져오겠습니다.

레퍼런스