컴파운드 엔지니어링으로 AI와 지식을 복리화하는 법

URL: https://www.youtube.com/watch?v=m8pBazNPvZE 날짜: 2026-08-22 채널: Tech Bridge

---

메타데이터

• 원제: [한영자막] 컴파운드 엔지니어링의 시대입니다 — Kieran Klaassen, Every/Cora
• 발표자: Kieran Klaassen
• 소속/제품: Every AI Lab, Cora
• 영상 ID: m8pBazNPvZE
• 길이: 19분 26초(자막은 19분 27초 부근에서 마지막 문장이 끊김)
• 주제: 컴파운드 엔지니어링(Compound Engineering), AI 에이전트, 지식 복리화, 판단과 취향의 시스템화
• 상태: published

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==구현(implementation)이 계속 저렴해지는 시대에는 인간의 판단(judgment)과 취향(taste)을 반복 가능한 시스템으로 추출해 AI의 작업 루프에 주입해야 한다.==

• AI에게 코드를 맡기는 것만으로는 충분하지 않으며, 무엇을 만들지 결정하고 결과의 기준을 정하는 인간의 두뇌가 루프의 양 끝에 있어야 한다.
• 사람이 반복해서 설명하는 지식·결정·실패를 저장하면 다음 작업의 브레인스토밍·계획·구현·검토가 더 좋아진다.
• 목표는 사람이 중간 과정에서 계속 개입하는 것이 아니라, 계획·작업·검토·테스트를 수행하는 AI의 중간부가 세 시간 이상 자율적으로 실행되어도 항상 좋은 결과를 내는 상태다.

Kieran Klaassen은 1인 엔지니어 체제로 수천 명이 신뢰하는 이메일 제품 Cora를 만들며, 코드를 직접 입력하는 시간보다 판단과 취향을 시스템으로 추출하는 데 집중해 왔다. 그가 말하는 컴파운드 엔지니어링은 브레인스토밍→계획→작업→검토→다듬기→복리화(compounding)→반복의 루프다. 인간은 시작과 끝에서 문제·목표·품질을 판단하고, AI는 잘 설정된 중간 과정을 병렬로 수행하며, 매번 얻은 학습은 다음 루프의 입력으로 저장된다.

1. 한 명의 엔지니어가 AI와 함께 제품을 만드는 방식

구현 인력을 늘리는 대신 자신의 사고와 취향을 시스템에 축적하면 작은 팀도 더 큰 문제를 다룰 수 있다.

1.1. 코드를 쓰지 않고도 제품을 출하하는 1인 체제

1. 올해 코드 한 줄 없이도 제품을 운영하다

   1. Kieran은 올해 코드 한 줄을 쓰지 않았고 아직 대부분의 코드를 직접 살펴보지도 않았다고 말한다.
   2. 그럼에도 수천 명이 이메일 받은편지함을 맡길 만큼 신뢰하는 제품을 출하하고 있으며, 자신이 만든 코드와 제품을 자랑스럽게 여긴다.

2. 사고와 취향을 복리화하는 목표

   1. 지난 2년 동안 자신의 thinking(사고)과 taste(취향)를 시간이 지날수록 좋아지는 시스템으로 추출해 왔다.
   2. 유행하는 “factory”, “dark factory” 같은 이름이나 새 도구 목록을 권하는 대신, 유행이 지나도 남고 더 크고 새로운 모델에도 적용되는 실제 작업 방식을 공유하려 한다.

1.2. Every와 Cora의 배경

1. Every의 미래 노동 연구

   1. Every는 “what’s next?”를 묻는 AI Lab이며, 미래의 일에 관해 쓰고 가르치고 직접 만든다.
   2. Every의 스튜디오에는 대체로 한 문제에 깊이 관심을 가진 단일 엔지니어링 팀이 있고, AI로 제품을 만들며 축적된 지식(compounded knowledge)을 활용한다.

2. Cora의 에이전트 네이티브 구조

   1. Cora는 Kieran이 컴파운드 엔지니어링을 발명한 계기가 된 완전한 AI 이메일 받은편지함(complete AI email inbox)이다.
   2. 에이전트가 할 수 있는 일이 곧 제품이 할 수 있는 일이며, 데스크톱·휴대폰·CLI·Insight·Codex·MCP에서 실행된다.
   3. Kieran은 Cora v2를 다시 만들고 있으며 곧 베타 접근을 열 예정이라고 말한다.

3. 지원은 받되 소유권은 혼자 갖는 구조

   1. 한 명의 엔지니어로 제품 전체를 만들고, 디자인 지원·데이터베이스의 고난도 엔지니어링 지원·제품 지원을 일부 받는다.
   2. 백엔드는 Ruby/Rails, 프런트엔드는 React를 사용하며, 제품에 대한 최종 책임은 Kieran이 진다. 장애가 발생하면 사용자와 직접 이야기하고 해결할 사람도 자신이다.
   3. 전직 VP of Engineering이자 창업자인 Kieran은 팀을 채용하고 키우는 방법을 알고 있지만, Sonnet 3.5에서 가능성이 열렸다고 느껴 팀을 키우기 전에 AI가 어디까지 갈 수 있는지 반대로 실험했다.

2. 기술이 좋아질수록 이동하는 병목

AI 활용의 핵심 문제는 고정되어 있지 않다. 코드가 좋아지면 계획이 병목이 되고, 계획이 좋아지면 무엇을 만들지가 병목이 된다.

2.1. 코드에서 계획으로 이동한 병목

1. 첫 번째 병목: 작동하지 않는 코드

   1. 약 2년 전 시작했을 때 AI가 만들어내는 나쁜 코드와 환각(hallucination)이 가장 큰 문제였다.
   2. Kieran은 에이전트와 스킬을 추가하고 결과를 검토하면서 코드 품질을 끌어올렸다.

2. 두 번째 병목: 계획의 품질

   1. 코드가 좋아지자 더 이상 작은 코드 변경 자체가 문제가 아니었고, 큰 일을 맡길 수 있는 좋은 계획이 병목이 됐다.
   2. 계획이 충분히 구체적이면 AI는 단순한 수정이 아니라 더 큰 범위의 작업을 수행할 수 있었다.

2.2. 만들 것의 결정과 기억의 필요성

1. 세 번째 병목: 무엇을 만들 것인가

   1. 계획이 좋아지고 범위가 커지자 사용자를 직접 만나고 해결해야 할 문제를 깊이 이해하는 일이 핵심이 됐다.
   2. 자신이 직접 쓰는 제품을 만들면 무엇이 좋은지, 무엇이 불편한지, 누구를 위해 만드는지를 강하게 느낄 수 있다는 장점이 있다.

2. 네 번째 병목: 반복되는 설명

   1. AI가 계획을 쓰는 능력이 좋아질수록 Kieran은 같은 판단을 계속 반복해서 설명해야 했고, 이것이 매우 성가셨다.
   2. 처음에는 지식을 CLAUDE.md에 저장했지만 파일이 어느 순간 너무 커졌다.
   3. 반복되는 설명을 기억해 두고 다음 작업에 적용하는 시스템을 직접 만들었고, 그 지점에서 컴파운드 엔지니어링이 출발했다.

3. 구현보다 판단과 취향을 시스템화하기

AI 시대에 사람의 레버리지는 키보드 입력량이 아니라 언제 직접 생각하고 어떤 기준으로 결과를 평가하는지에 달려 있다.

3.1. 타이핑에서 판단으로의 이동

1. 구현은 대부분 해결됐지만 기준은 해결되지 않았다

   1. Kieran은 점점 더 적게 타이핑하고, 더 많이 판단하고 취향을 적용하는 방향으로 이동했다고 말한다.
   2. 오케스트레이션(orchestration)과 다크 팩토리(dark factory)는 실제로 어느 정도 작동하지만, 인간의 judgment와 taste까지 자동으로 만들어주지는 않는다.

2. AI에 맡길 것과 두뇌를 켤 때를 분리하다

   1. 사람이 해야 하는 핵심 질문은 “어디에서 내 두뇌를 켤 것인가, 언제 모델을 활용할 것인가”다.
   2. 생각하고, 반복하고, 잼(jam)하고, 브레인스토밍하는 과정에서 얻은 판단을 시스템에 추출하면 다음 브레인스토밍부터 이미 그 사고가 포함된다.

3. 복리 시스템을 가진 1인의 우위

   1. Kieran은 컴파운딩 시스템을 가진 한 명의 엔지니어가 그런 시스템 없이 AI를 쓰는 완전한 팀보다 강해질 수 있다고 본다.
   2. 이유는 매 작업이 단발성 산출물로 끝나지 않고, 다음 작업의 품질을 높이는 지식과 기준을 추가하기 때문이다.

3.2. 휴먼-AI 샌드위치 루프

1. 전체 루프

   1. 브레인스토밍(brainstorming)으로 시작해 계획(planning), 작업(working), 검토(reviewing), 다듬기(polishing), 복리화(compounding)를 거쳐 다시 반복한다.
   2. AI가 중간에서 작업하더라도 전체 루프의 주체는 인간이며, 매번 시스템을 개선해야 한다.

2. 인간은 빵, AI는 가운데

   1. Kieran은 이를 “human AI sandwich”라고 부른다. 인간이 양쪽 빵이고 AI가 가운데 재료다.
   2. 시작에서는 무엇을 만들지, 어떤 문제가 진짜 문제인지, 무엇을 해결하려는지 인간이 결정한다.
   3. 끝에서는 결과가 정말 좋은지, 더 높은 기준이 필요한지, 더 빠르고 산뜻한지, 낙관적이고 즐거운지, 즉 delight가 있는지를 인간의 취향으로 판단한다.

3. 중간은 자율적으로 돌아가야 한다

   1. 시작과 끝이 잘 설정되지 않으면 AI가 실행하는 중간 과정도 제대로 돌아가지 않는다.
   2. 중간이 올바르게 세팅되면 사람은 밤새 여러 작업을 병렬로 실행해 “machine rip” 상태로 둘 수 있다.

4. 매 작업의 절반을 시스템 교육에 쓰기

기능을 만든 시간과 시스템을 더 똑똑하게 만든 시간을 함께 투자해야 속도가 누적된다.

4.1. 50/50 규칙과 저장 방식

1. 기능 구현에 50%

   1. 기능이 실제로 만들어졌는지 확인한다.
   2. 처음 정한 가치가 사용자에게 전달됐는지 확인한다.

2. 시스템 교육에 50%

   1. AI가 잘못한 것이 무엇인지, 그 실패에서 무엇을 배울 수 있는지, 다음에는 무엇을 가르쳐야 하는지 기록한다.
   2. 이 과정은 당장 “잘 작동하니 넘어가자”고 말하고 싶은 순간에 가장 하기 어렵지만, 다음 작업을 개선하는 핵심이다.

3. 저장된 해법은 장기적으로 토큰을 절약한다

   1. Kieran은 추출된 지식을 저장소(repository)의 solution document로 보관한다.
   2. 지식을 미리 토큰 안에 넣으면 검토·수정·인터넷을 가로지르는 심층 리서치가 줄어들어 장기적으로는 오히려 토큰 효율이 좋아진다.
   3. 필요한 답과 해법을 더 빨리 찾아 연구량을 줄일 수 있다.

4.2. 완전히 스스로 돌아가는 중간부

1. 고정된 인간의 뇌와 덜 고정된 AI

   1. 이 방식이 작동하는 진짜 이유는 인간의 뇌는 비교적 고정되어 있지만 AI 시스템은 계속 바뀌고 개선될 수 있기 때문이다.
   2. AI가 놀라울 정도로 좋은 중간부를 실행할 때까지 판단과 학습을 계속 추출해야 한다.

2. 반복을 발견하면 추출한다

   1. 같은 설명을 두 번 하는 순간을 감지하고 지식으로 저장한다.
   2. 사람이 여전히 중간 루프에 필요하면 그 부분을 수동으로 실행하면서 어디가 어긋나는지 느끼고 계속 반복해 고친다.
   3. 세 시간 동안 실행해도 매번 좋은 결과가 나오는 시점이 자율 루프의 도달점이다.

5. Compound Engineering 플러그인과 작업 명령

Kieran은 자신의 제품을 만들며 정리한 시스템을 플러그인으로 공개했고, 엔지니어뿐 아니라 제품·디자인·지식 노동에도 적용되는 범용 흐름으로 확장했다.

5.1. 플러그인의 성격과 범용성

1. 도구에 종속되지 않는 지식 저장

   1. Compound Engineering 플러그인은 Codex, Claude Code, Cursor를 비롯해 10개가 넘는 도구에서 설치할 수 있다.
   2. 수십만 명이 매일 사용하고 있으며, Kieran은 유행을 만들기 위해 시작한 것이 아니라 자신이 코드를 출하하는 과정에서 사용하다가 공유한 것이라고 설명한다.
   3. 플러그인을 쓰지 않아도 파일에 정보를 저장하는 방식으로 같은 원리를 직접 구현할 수 있다.

2. Compound Product로의 확장

   1. 제품 감각과 제품 배경을 가진 공동 기여자 Trevan Chowo가 합류해 제품 사고를 보탰다.
   2. 이 개념은 엔지니어뿐 아니라 PM, 디자이너, Every 내부의 지식 노동자에게도 적용된다.
   3. 출발점은 엔지니어링이지만 핵심은 지식의 복리화라는 보편적 원리다.

5.2. C ideate: 흩어진 이슈에서 전략에 맞는 다음 일 찾기

1. 오픈 티켓을 구조화하다

   1. C ideate는 “무엇을 해야 할지 모르겠다”는 상황에서 실행하는 명령이다.
   2. Linear·GitHub·Slack·Intercom 등에 흩어진 오픈 이슈를 모두 읽고, 뒤섞인 요청을 구조화한다.
   3. 어떤 일을 먼저 할 가치가 있는지와 어떤 일은 지금 하지 않는 편이 좋은지 논거를 붙여 판단한다.

2. 전략과 과거 학습을 연결하다

   1. 결과는 팀과 공유할 수 있는 깔끔한 HTML 페이지로 생성된다.
   2. OKR을 연결하면 아이디어가 전략과 맞는지 판단할 수 있다.
   3. CE strategy로 만든 전략 문서, 과거 실험, 과거 학습을 저장소에 넣어두면 각 아이디어가 기존 지식에 비추어 점수화된다.
   4. 이 문서를 Claude의 디자인 기능에 넣어 파워포인트를 만들면, OKR에 맞는 최적 지점을 XY 매트릭스로 보여주는 발표 자료도 만들 수 있다.

5.3. C doc review: 질문을 저장해 다음 문서에 반영하기

1. PRD를 답이 아니라 질문으로 검토하다

   1. PRD나 다른 문서를 받으면 C doc review를 실행한다.
   2. 결과는 날카로운 질문이며, 미처 생각하지 못한 좋은 질문을 발견하게 한다.

2. 질문과 답변을 복리화하다

   1. 질문을 동료에게 전달하거나 문서 작성자에게 답을 요청한다.
   2. 답변이 나오면 C compound로 그 지식을 저장한다.
   3. 다음번에는 시스템이 답을 이미 알고 있으므로 같은 질문을 다시 묻지 않고 문서 품질을 높인다.
   4. 이 흐름은 Claude Code에 국한되지 않고 Co-work 등 어디서나 실행할 수 있다.

5.4. C brainstorm: 큰 일을 시작하기 위한 두뇌 켜기

1. 큰 아이디어 앞에서 집중 시간을 확보하다

   1. 설명하기 어려울 만큼 큰 일에는 C brainstorm을 사용한다.
   2. Kora v1에서 v2로 업그레이드하는 것처럼 범위가 큰 작업을 앞두고 시간을 블록으로 잡고 멀티태스킹을 하지 않는다.

2. 필요한 질문만 묻다

   1. 시스템은 저장된 컴파운드 지식을 불러오고, Kora v1과 v2의 차이를 분석하며, 설정된 사용자 페르소나를 확인한다.
   2. 페르소나마다 필요한 것이 다르다는 점을 반영해 작업에 필요한 질문을 한다.
   3. 질문을 많이 받는 것이 성과가 아니다. 30개 질문에 답하면 많이 한 것처럼 느껴질 수 있지만 목표는 질문에 답하는 것이 아니라 최고의 결과를 얻는 것이다.
   4. 필요한 만큼만 묻도록 조정된 질문의 양과 품질 사이에 균형이 필요하다.

3. 브레인스토밍 자체를 다음 입력으로 남기다

   1. 결과는 계획으로 정리되고 브레인스토밍 문서로 저장된다.
   2. 그 문서도 컴파운드 지식에 포함되어 다음 작업의 기준이 된다.

5.5. /LFG: 몇 시간 동안 병렬 실행되는 자동화 루프

1. 계획부터 PR까지 이어지는 중간부

   1. /LFG는 Kieran이 가장 좋아하는 루프 명령이며, 바이브 코딩을 좋아하는 사람도 사용할 수 있다.
   2. 몇 시간 동안 계획·작업·검토·테스트를 진행하고, 풀 리퀘스트(PR)를 열고, 직접 도그푸딩(dogfooding)한다.
   3. 문제가 보이면 수정하고, 풀 리퀘스트 안에 전후 영상과 스크린샷을 남긴다.
   4. 밤새 여러 작업을 병렬 실행할 수 있어 아침에 무엇이 바뀌었는지 쉽게 확인할 수 있다.

2. C polish로 인간의 기준을 다시 켜다

   1. /LFG가 만든 PR을 C polish에 넘기면 왼쪽에는 해당 변경을 만든 LFG 흐름이, 오른쪽에는 실제 제품이 표시된다.
   2. Kieran은 Cursor에서 이 좌우 구성을 선호한다. 변경의 원인과 실제 결과를 함께 보며 무엇이 만들어졌는지 빠르게 이해할 수 있기 때문이다.
   3. LFG에 제품의 영상 녹화를 넣으면 시스템이 영상을 처리·분석해 무엇이 잘못됐는지 찾는다.
   4. C polish는 QA가 아니라 기준을 끌어올리는 단계다. 기능이 작동하지 않으면 LFG 흐름이 실패한 것이고, 기능이 작동하더라도 더 나은 경험을 만들 수 있는지 판단한다.

3. 작은 디자인 실수도 규칙으로 바꾸다

   1. 한 화면에 로고 마크가 두 번 표시된 사례는 기술적으로 오류는 아니지만 Kieran의 취향에는 맞지 않았다.
   2. “한 페이지에는 언제나 하나의 마크만 두라”는 규칙을 C compound로 추출한다.
   3. 다음 디자인 작업에서 시스템이 해당 지식 파일을 찾아 태그를 올바르게 붙이고 같은 실수를 반복하지 않는다.
   4. PR을 병합하고 학습을 저장하는 순간 작업 루프가 닫힌다.

6. 직접 구현할 때의 운영 원칙

컴파운드 엔지니어링은 새 도구 이름보다 반복을 제거하고 자율 실행 가능한 중간부를 만드는 운영 습관에 가깝다.

6.1. “반복하지 말고 추출하라”

1. 반복을 신호로 삼다

   1. 같은 설명·수정·판단을 반복하는 순간을 발견하면 어떤 형식으로든 지식으로 추출한다.
   2. 다음 작업에서 같은 일이 다시 일어나지 않도록 시스템이 읽을 수 있는 위치에 둔다.

2. 중간부를 지루하게 만들다

   1. 계획·작업·검토가 들어 있는 중간부는 재미있거나 영리해 보일 필요 없이 “그냥 작동”해야 한다.
   2. 사람이 여전히 개입한다면 잘못된 부분을 수동으로 실행하고 감각을 얻은 뒤, 그 차이를 다시 시스템에 반영한다.

6.2. 코드를 문서화하기보다 사고를 문서화하다

1. 코드는 이미 산출물이다

   1. 개발자는 코드 자체가 문서이므로 별도 문서화가 필요 없다고 생각하기 쉽다.
   2. Kieran은 코드가 아니라 왜 그렇게 결정했는지에 대한 reasoning(추론)을 일반화해 남겨야 한다고 본다.

2. 실패의 흔적을 학습으로 바꾸다

   1. 나쁜 trace라도 사후 분석(postmortem)에서 무슨 일이 일어났는지, 누가 또는 어떤 에이전트가 어떤 결정을 내렸는지 추적할 단서가 된다.
   2. 그 결정을 다음 행동을 바꾸는 학습으로 전환하면 같은 실패를 반복하지 않는 시스템이 된다.
   3. Kieran은 특히 postmortem에서 이 방법이 매우 잘 작동하는 것을 경험했다고 말한다.

7. 구현은 싸지고 판단은 비싸지는 미래

AI의 발전은 구현 자체를 병목에서 밀어내며, 인간의 문제 이해와 품질 기준을 가장 중요한 자산으로 만든다.

7.1. 미래 모델에 인간의 기준을 연결하기

1. 핵심 베팅

   1. 구현 비용은 계속 낮아지지만 판단 비용은 낮아지지 않는다.
   2. 앞으로의 모델과 시스템은 더 큰 레버리지를 얻으려면 인간이 가진 판단과 취향에 접근할 수 있도록 설정돼야 한다.

2. 양 끝에서 두뇌를 활성화하다

   1. 시작할 때 AI에게 사고를 넘기지 말고 실제로 해결하려는 문제를 완전히 이해한다.
   2. 중간에서는 AI가 실행하도록 놓아준다.
   3. 끝에서는 결과를 고치는 수준에 머물지 말고 기준을 높인다. “작동한다”를 넘어 충분히 훌륭하고 만족스러운 결과인지 확인한다.

7.2. 다음 기능은 더 쉬워져야 한다

1. 복리의 실용적 기준

   1. 새 기능을 출하한 뒤 다음 기능은 앞선 기능 덕분에 더 쉬워져야 한다.
   2. 다음 기능이 더 어려워졌다면 코드나 프로세스에 복잡성을 추가한 것이며, 컴파운드 엔지니어링의 방향을 거꾸로 간 것이다.

2. 품질을 낮추지 않는 출하

   1. 자동화가 된다는 이유로 기준을 낮추거나 형편없는 코드를 출하해서는 안 된다.
   2. AI가 중간을 맡을수록 인간은 문제 정의와 최종 품질, 제품의 delight에 더 엄격해야 한다.
   3. 제공된 자동 자막은 “which is normally how engineering works, we're flipping”에서 끝나며, 여기서 문장이 끊긴다. 앞뒤 맥락상 기존 엔지니어링의 복잡성 증가 방식을 뒤집자는 결론으로 이어진다.

주요 발언 모음

“I've been doing this for two years and trying to extract my thinking and my taste into a system that compounds.”

“The real trick here is on both ends. It's kind of the human AI sandwich where the human is the bread and the AI is the middle part.”

“50% of the time should go to teaching the system for anything that it did wrong.”

“If you see yourself repeating yourself, make sure to extract it somehow. Make sure it doesn't happen again.”

“It should be boring. It should just work. You should not be needed.”

“It's important to document the thinking, not the code.”

“The bet is implementation is only getting cheaper and judgment is not.”

“Don't offload the thinking to the AI. Make sure you truly understand what you're doing, the problem.”

“Your standard should be the next feature should be easier because you ship this one.”

핵심 데이터 & 수치

• 수천 명: Kieran이 1인 엔지니어 중심으로 만든 Cora 이메일 제품을 사용하고 신뢰한다.
• 약 2년: Kieran이 AI와 함께 Cora를 만들며 코드→계획→제품 결정→기억 시스템으로 병목을 이동시킨 기간이다.
• 1명 + 지원 인력: 핵심 제품 개발은 한 명의 엔지니어가 맡고 디자인·데이터베이스 등 일부 전문 지원만 받는다.
• 50%/50%: 기능 구현과 시스템 교육에 시간을 균등하게 배분한다.
• 3시간: 중간 루프가 세 시간 동안 자율 실행돼도 계속 좋은 결과를 내면 시스템이 충분히 성숙했다고 판단한다.
• 10개 이상 도구: Compound Engineering 플러그인은 Codex·Claude Code·Cursor 등을 포함해 10개가 넘는 도구에 설치할 수 있다.
• 수십만 명: 공개된 플러그인을 매일 사용하는 이용자 규모로 제시됐다.
• 30개 질문: 질문을 많이 받는 것 자체는 목표가 아니며, 필요한 만큼의 질문으로 최고의 결과를 내야 한다는 예시다.
• 19분 27초: 확보된 자동 자막의 마지막 타임스탬프이며, 마지막 문장은 “we're flipping”에서 중단된다.

결론 및 시사점

1. AI 활용의 다음 경쟁력은 더 빠른 코드 생성이 아니라 개인·팀의 판단과 취향을 다음 작업에 재사용하는 능력이다.
2. 브레인스토밍과 문제 정의, 최종 품질 판단은 인간이 맡고 계획·구현·검토·테스트의 중간 과정은 자율적인 AI 루프로 만든다.
3. 기능이 잘 작동했다는 이유로 넘어가지 말고, 잘못된 결과와 좋은 판단을 모두 solution document·규칙·postmortem으로 추출한다.
4. 같은 설명을 두 번 하는 순간은 기억 시스템을 추가해야 한다는 신호이며, 반복을 제거할수록 한 사람의 레버리지가 커진다.
5. 50%의 시간은 기능을 출하하는 데, 나머지 50%는 AI가 다음번에 더 잘하도록 가르치는 데 투자한다.
6. 자동화된 중간부는 흥미로울 필요 없이 지루할 정도로 안정적으로 작동해야 하며, 사람이 세 시간 동안 개입하지 않아도 결과가 좋아야 한다.
7. 다음 기능이 더 쉬워지지 않고 더 어려워진다면 새 코드가 복잡성을 누적시킨 것이므로, 앞선 작업에서 학습을 추출했는지 점검해야 한다.
8. 구현이 싸지는 미래일수록 인간은 문제를 정확히 이해하고, AI에게 사고를 전가하지 않으며, 최종 결과의 기준을 더 높여야 한다.

핵심 요약 (20줄)

1. Kieran Klaassen은 올해 코드 한 줄을 직접 쓰지 않고도 수천 명이 신뢰하는 이메일 제품 Cora를 운영한다.
2. Kieran은 자신의 사고와 취향을 반복 가능한 시스템으로 추출해 시간이 지날수록 복리로 쌓이게 만든다.
3. Every는 미래의 일에 관해 쓰고 가르치고 만들며 단일 엔지니어링 팀과 AI로 문제를 해결한다.
4. Cora는 에이전트가 할 수 있는 일을 제품이 모두 수행하는 에이전트 네이티브 이메일 받은편지함이다.
5. Kieran은 디자인과 데이터베이스 지원만 일부 받고 Ruby/Rails·React 기반 Cora를 사실상 혼자 소유한다.
6. AI의 첫 병목은 작동하지 않는 코드였고 에이전트·스킬·검토를 추가하자 계획의 품질이 병목이 됐다.
7. 계획이 좋아지자 무엇을 만들지 결정하고 사용자의 문제를 이해하는 일이 새로운 병목으로 떠올랐다.
8. 반복되는 설명을 줄이기 위해 CLAUDE.md를 넘어선 기억 시스템을 만들면서 컴파운드 엔지니어링이 시작됐다.
9. 컴파운드 엔지니어링은 브레인스토밍·계획·작업·검토·다듬기·복리화·반복의 루프다.
10. 인간은 시작과 끝의 빵이고 AI는 계획·구현·검토가 일어나는 가운데 재료인 휴먼-AI 샌드위치를 이룬다.
11. 기능 구현에 50%, 잘못을 학습해 시스템을 가르치는 데 50%의 시간을 배분해야 한다.
12. 저장소의 solution document는 장기적으로 검토·수정·심층 리서치를 줄여 토큰을 절약한다.
13. C ideate는 Linear·GitHub·Slack·Intercom의 이슈를 OKR과 과거 학습에 맞춰 구조화한다.
14. C doc review는 PRD에서 날카로운 질문을 만들고 C compound는 답변을 다음 문서의 지식으로 저장한다.
15. C brainstorm은 큰 작업의 차이·페르소나·기존 지식을 불러와 필요한 만큼만 질문하고 계획을 만든다.
16. /LFG는 밤새 계획·작업·검토·테스트·PR·도그푸딩을 병렬로 실행하고 전후 영상과 스크린샷을 남긴다.
17. C polish는 기능을 검사하는 QA가 아니라 실제 제품을 보며 인간의 취향과 품질 기준을 높이는 단계다.
18. 로고 마크를 한 페이지에 하나만 두라는 작은 취향도 C compound로 저장하면 다음 디자인에 재사용된다.
19. 구현 비용은 낮아지지만 판단과 취향의 가치는 낮아지지 않으므로 미래 시스템은 인간의 기준에 접근해야 한다.
20. 다음 기능이 더 쉬워져야 컴파운딩이 일어난 것이며, 시작의 문제 이해와 끝의 품질 상향은 인간이 끝까지 맡아야 한다.