The Era of Compound Engineering — Kieran Klaassen, Every/Cora

한 줄 핵심

코드를 직접 많이 읽거나 쓰지 않아도, 계획·판단·교정 학습을 누적하는 ‘compound engineering’ 체계를 만들면 1인으로도 AI 제품을 지속적으로 출시할 수 있다고 주장한다.

시간별 요약

1. 0:00
   코드를 거의 보지 않고도 출시하기 올해는 거의 코드를 쓰지 않았고 대부분의 코드를 읽지도 않았지만, 실제로는 수천 명이 쓰는 이메일 제품을 계속 출시하고 있다고 설명한다. 핵심은 자신의 생각과 취향을 시스템에 누적시켜 시간이 지날수록 더 큰 성과를 내는 방식이며, 유행보다 오래 가는 작업 방식을 공유하겠다는 목표를 제시한다.
2. 2:52
   일부러 혼자 이메일 클라이언트를 만들기 Cora를 1인으로 만들되 디자인, 데이터베이스, 지원 같은 일부 영역만 도움을 받는 구조를 의도적으로 택했다. AI가 어디까지 팀 확장 없이 제품 개발을 밀어줄 수 있는지 실험하려는 선택이며, 처음에는 코드가 병목이었지만 점점 계획, 판단, 문제 정의가 병목으로 이동했다고 정리한다.
3. 4:40
   병목은 코드에서 계획, 그다음 판단으로 이동했다 코드 품질과 계획 수립이 좋아지자, 이제는 무엇을 만들지 결정하는 판단이 더 중요한 병목이 되었다. 반복해서 설명해야 하는 내용을 기억시키기 위해 메모리 시스템이 필요해졌고, 여기서 ‘compound engineering’이 출발했다.
4. 5:30
   compound engineering이 나온 배경 구현 자체는 점점 해결되고 있지만, 진짜 어려운 부분은 판단과 취향이며, 사람의 사고를 언제 개입시키고 언제 모델에 맡길지의 경계라고 본다. 생각·브레인스토밍·반복 과정에서 나온 판단을 시스템에 추출해 두면 다음번에는 더 큰 문제에 집중할 수 있다고 설명한다.
5. 6:25
   루프와 양쪽 끝의 인간 브레인스토밍, 계획, 작업, 검토, 다듬기, 누적, 반복으로 이어지는 루프가 핵심이며, 인간은 시작과 끝에서 개입해야 한다고 정리한다. 시작에서는 무엇을 풀지 정의하고, 끝에서는 결과의 기준을 높이며, 중간은 밤새 병렬로 돌아가도 되도록 시스템을 만들어야 한다.
6. 8:10
   절반의 시간은 시스템의 실수를 가르치는 데 쓰기 기능을 만드는 데 50%, 시스템이 틀린 부분을 가르치고 학습시키는 데 50%를 써야 다음번 결과가 좋아진다고 말한다. 반복해서 설명한 지식과 해결책을 repository의 solution documents로 저장하면, 장기적으로는 검토와 재조사에 드는 토큰을 줄일 수 있다.
7. 9:03
   저장된 해결책이 토큰을 더 아껴 준다 AI는 바뀌지만 사람의 판단은 고정적이기 때문에, 중간 과정을 계속 추출해 시스템이 스스로 잘 동작하게 만드는 것이 목표라고 본다. 이를 위해 compound engineering plugin을 만들었고, Codex, Claude, Cursor 등 여러 도구에서 설치해 쓸 수 있게 했다.
8. 9:55
   플러그인과 제품을 함께 만들기 플러그인은 제품을 만드는 과정에서 같이 만들어졌고, 지금은 수많은 사람들이 매일 쓰는 도구가 되었다. 이 개념은 엔지니어뿐 아니라 PM, 디자이너, 지식 노동자에게도 유용하며, 저장된 전략과 과거 학습을 바탕으로 아이디어를 더 잘 압축하고 확장할 수 있다고 설명한다.
9. 10:45
   백로그를 논쟁 가능한 아이디어 묶음으로 바꾸기 CE IDEATE는 열린 이슈, Linear, GitHub, Slack, Intercom 같은 흩어진 일을 모아 구조화하고, 무엇을 먼저 해야 하는지 논리적으로 주장하는 문서를 만든다. 기존 실험, 학습, OKR과 연결해 아이디어를 채점하므로, 단순 목록이 아니라 전략에 맞는 우선순위 도구가 된다.
10. 12:26
    문서에 날카로운 질문을 적당한 양만 던지기 CE doc review는 PRD나 문서를 넣으면 빠뜨린 부분을 찌르는 질문을 돌려주고, 그 답을 다시 시스템에 누적해 다음번에는 같은 질문이 반복되지 않게 한다. CE brainstorm은 큰 아이디어를 다룰 때 맥락과 페르소나를 넣어 꼭 필요한 만큼만 질문하도록 설계되어 있다.
11. 15:01
    밤새 도는 루프와 기준을 높이는 다듬기 {slash} LFG는 계획, 검토, 테스트, PR 생성, dogfooding, 수정, before/after 영상 분석까지 밤새 돌릴 수 있는 자동화 루프다. 마지막 다듬기 단계에서는 결과를 확인하며 단순 QA가 아니라 기준을 높이는 작업을 하고, 발견한 차이를 다시 시스템에 학습시켜 루프를 닫는다.
12. 17:33
    플러그인 없이도 같은 방식으로 하기 핵심은 플러그인이 아니라 반복되는 생각을 문서화하고, 코드보다 판단의 이유를 남기며, postmortem을 통해 다음번 행동을 바꾸는 습관이라고 정리한다. 구현은 점점 싸지지만 판단은 싸지지 않으므로, 미래 시스템은 사람의 취향과 기준에 접근할 수 있어야 한다고 본다.
13. 19:14
    다음 기능은 이번 기능보다 쉬워야 한다 AI에 생각을 넘기지 말고 시작에서는 문제를 깊이 이해하고, 끝에서는 기준을 더 높여야 하며, 결과물은 단지 작동하는 수준이 아니라 더 나은 다음 기능을 가능하게 해야 한다. 이번 기능을 통해 복잡도가 늘어나는 것이 아니라 오히려 다음 기능이 더 쉬워져야 한다는 원칙으로 마무리한다.

실무 인사이트

• 반복 설명하는 내용은 즉시 문서나 파일로 추출해 저장하면, 다음 작업부터는 계획·검토·설명 비용을 줄일 수 있다.
• AI 활용의 핵심 병목은 코드 작성이 아니라 무엇을 만들지 정하는 판단과 기준 설정이므로, 브레인스토밍과 최종 검수를 사람 중심으로 남겨 두는 편이 효과적이다.
• 밤새 돌아가는 자동화 루프를 만들더라도 마지막에는 결과 예시와 실패 사례를 다시 학습시켜야, 다음 기능이 더 쉬워지는 누적 효과가 생긴다.