🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Every는 에이전트가 코드를 작성하는 시대에 개발자의 핵심 역할이 직접 코딩에서 계획·검토·학습 루프 설계로 이동한다고 보고, 이를 ‘컴파운드 엔지니어링’이라고 부른다.

📌 핵심 요약

• Every는 AI 코딩 성능이 강해지면서 내부적으로 사람이 코드를 직접 쓰지 않는 방식의 소프트웨어 개발을 실험하고 있으며, 이 변화가 기존 엔지니어링 관행을 낡게 만들고 있다고 설명한다.
• 컴파운드 엔지니어링은 기능이 늘수록 다음 기능 개발이 더 어려워진다는 전통적 전제를 뒤집고, 버그·실패한 테스트·문제 해결 통찰을 기록해 에이전트와 팀이 함께 학습하게 만드는 접근이다.
• Every는 이 방식으로 내부의 다섯 개 소프트웨어 제품과 추가 인큐베이션 제품을 운영하고 있으며, 각 제품은 주로 한 사람이 만들고 운영하지만 실제 사용자들이 매일 중요한 업무에 사용한다고 주장한다.
• 컴파운드 엔지니어링의 반복 루프는 계획, 작업, 검토, 컴파운드 단계로 구성되며, 에이전트가 병렬로 계획하고 코드를 작성하며 평가하는 동안 엔지니어는 결과와 학습 내용을 검토한다.
• 이 글에서 공개된 본문은 특히 계획 단계의 중요성을 강조하며, 에이전트가 현재 코드베이스와 커밋 기록, 관련 모범 사례를 조사하게 한 뒤 구현 계획을 세우는 것이 핵심이라고 설명한다.

🧩 주요 포인트

1. Every는 AI 코딩 성능이 강해지면서 내부적으로 사람이 코드를 직접 쓰지 않는 방식의 소프트웨어 개발을 실험하고 있으며, 이 변화가 기존 엔지니어링 관행을 낡게 만들고 있다고 설명한다.
2. 컴파운드 엔지니어링은 기능이 늘수록 다음 기능 개발이 더 어려워진다는 전통적 전제를 뒤집고, 버그·실패한 테스트·문제 해결 통찰을 기록해 에이전트와 팀이 함께 학습하게 만드는 접근이다.
3. Every는 이 방식으로 내부의 다섯 개 소프트웨어 제품과 추가 인큐베이션 제품을 운영하고 있으며, 각 제품은 주로 한 사람이 만들고 운영하지만 실제 사용자들이 매일 중요한 업무에 사용한다고 주장한다.
4. 컴파운드 엔지니어링의 반복 루프는 계획, 작업, 검토, 컴파운드 단계로 구성되며, 에이전트가 병렬로 계획하고 코드를 작성하며 평가하는 동안 엔지니어는 결과와 학습 내용을 검토한다.
5. 이 글에서 공개된 본문은 특히 계획 단계의 중요성을 강조하며, 에이전트가 현재 코드베이스와 커밋 기록, 관련 모범 사례를 조사하게 한 뒤 구현 계획을 세우는 것이 핵심이라고 설명한다.

🧠 상세 정리

1. 사람이 직접 코드를 쓰지 않는 상황에서 나온 질문

글은 ‘코드의 100%를 에이전트가 작성하면 소프트웨어 엔지니어링은 어떻게 되는가’라는 질문에서 출발한다. Every에서는 AI 코딩이 매우 강력해지면서 사람이 직접 코드를 입력하거나 코드 편집기에서 커서를 바라보는 일이 이상하게 느껴질 정도라고 설명한다. 저자는 기존 엔지니어링이 코딩의 어려움과 엔지니어의 희소성을 전제로 설계되어 왔다고 본다. 이 전제가 사라지면 수동으로 테스트를 작성하거나 사람이 읽기 좋은 코드를 장황하게 직접 타이핑하는 방식은 느리고 시대에 뒤처진 관행처럼 보인다는 것이 글의 문제의식이다.

2. 컴파운드 엔지니어링의 핵심 정의

Every가 제안하는 새 방식은 ‘컴파운드 엔지니어링’이다. 전통적인 개발에서는 기능이 추가될수록 코드가 많아지고 엣지 케이스와 상호의존성이 늘어나 다음 기능을 만들기 더 어려워진다고 여긴다. 반대로 컴파운드 엔지니어링에서는 각 기능이 다음 기능 개발을 더 쉽게 만들어야 한다고 본다. 이유는 에이전트와 팀원이 함께 학습하는 루프를 만들기 때문이다. 버그, 실패한 테스트, 문제 해결 과정에서 얻은 깨달음을 문서화하고 이후 에이전트가 활용하게 함으로써 코드베이스의 복잡성이 커지는 동시에 AI의 코드베이스 이해도도 함께 커진다는 설명이다.

3. Every 내부에서의 실제 적용과 생산성 주장

저자는 이 접근이 단순한 아이디어가 아니라 Every 내부에서 작동하고 있다고 말한다. Every는 내부적으로 다섯 개의 소프트웨어 제품을 운영하고 있으며, 몇 개의 제품을 추가로 인큐베이팅하고 있다고 설명한다. 각 제품은 주로 한 사람이 만들고 운영하지만, 매일 수천 명이 중요한 업무에 사용하는 실제 제품이지 단순한 데모가 아니라고 강조한다. 이 경험을 바탕으로 저자는 AI를 제대로 활용하면 오늘날 한 명의 개발자가 몇 년 전 다섯 명의 개발자가 하던 일을 수행할 수 있다고 주장한다. 다만 그 전제는 AI의 힘을 붙잡아 쓸 수 있는 좋은 시스템이 있어야 한다는 점이다.

4. 계획·작업·검토·컴파운드로 이루어진 반복 루프

컴파운드 엔지니어는 병렬로 실행되는 에이전트들을 조율하며, 이 에이전트들은 코드를 계획하고 작성하고 평가한다. 글은 이 과정을 네 단계 루프로 제시한다. 첫째, 계획 단계에서는 에이전트가 이슈를 읽고 접근법을 조사하며 구현 계획을 종합한다. 둘째, 작업 단계에서는 에이전트가 그 계획에 따라 코드를 작성하고 테스트를 만든다. 셋째, 검토 단계에서는 엔지니어가 결과물 자체와 그 결과에서 얻은 교훈을 살핀다. 넷째, 컴파운드 단계에서는 성공과 실패에서 나온 결과를 시스템에 되먹여 다음 루프를 더 좋게 만든다.

5. 도구보다 중요한 것은 워크플로의 구조

Every는 컴파운드 엔지니어링에 주로 Anthropic의 Claude Code를 사용한다고 밝힌다. 그러나 저자는 이 방식이 특정 도구에 묶인 것은 아니라고 설명한다. 팀 일부는 Factory의 Droid와 OpenAI의 Codex CLI도 사용한다고 언급한다. 또한 Every는 내부에서 사용하는 정확한 워크플로를 직접 실행해볼 수 있도록 Claude Code용 컴파운드 엔지니어링 플러그인을 만들었다고 소개한다. 중요한 비중 배분도 제시된다. 저자에 따르면 컴파운드 엔지니어링의 약 80%는 계획과 검토에 있으며, 실제 작업과 컴파운드 단계는 약 20%를 차지한다.

6. 공개 본문에서 구체화된 계획 단계

본문에서 실제로 상세 설명이 시작되는 부분은 첫 번째 단계인 계획이다. 저자는 에이전트가 모든 코드를 작성하는 세계에서는 개발자의 대부분 시간이 계획에 쓰인다고 말한다. 좋은 계획은 조사에서 시작하며, 에이전트에게 현재 코드베이스와 커밋 히스토리를 살펴보게 해 구조, 기존 모범 사례, 코드가 만들어진 방식을 이해하게 한다고 설명한다. 또한 해결하려는 문제와 관련된 인터넷상의 모범 사례도 조사하게 한다. 이렇게 사전 정보를 충분히 넣어두면 구현 계획을 세울 때 에이전트가 더 좋은 작업을 할 준비가 된다는 것이 공개된 본문의 핵심 설명이다.

🧾 핵심 주장 / 시사점

• 글의 핵심 전환은 ‘개발자가 코드를 잘 쓰는 사람’에서 ‘에이전트가 반복적으로 더 잘 일하도록 계획·검토·기억을 설계하는 사람’으로 역할이 바뀐다는 데 있다.
• 컴파운드 엔지니어링의 생산성 주장은 단순히 에이전트에게 작업을 시키는 것이 아니라, 실패와 깨달음을 다음 작업의 입력으로 남기는 체계가 있을 때 성립한다.
• 공개된 본문은 작업 실행보다 계획과 검토에 훨씬 큰 비중을 둔다고 강조하므로, 에이전트 코딩 도입의 병목은 코딩 속도보다 맥락 수집과 품질 평가 체계일 가능성이 크다.

✅ 액션 아이템

• 다음 개발 과제부터 에이전트에게 코드베이스·커밋 기록·관련 모범 사례를 먼저 조사하게 하고, 구현 전 계획안을 검토하는 절차를 만든다.
• 버그, 실패한 테스트, 해결 과정에서 얻은 통찰을 에이전트와 팀이 재사용할 수 있는 학습 기록으로 남기는 간단한 템플릿을 도입한다.
• 계획·작업·검토·컴파운드 단계로 나눠 한 기능을 실험하고, 엔지니어가 직접 코딩한 시간과 검토·학습 설계에 쓴 시간을 비교한다.

❓ 열린 질문

• 에이전트가 병렬로 계획하고 코드를 작성할 때, 엔지니어는 어떤 기준으로 결과의 품질과 위험을 빠르게 판별할 수 있을까?
• 버그와 실패한 테스트를 학습 자산으로 쌓는 과정에서 어떤 정보가 다음 개발 속도를 실제로 높이는 데 가장 유용할까?
• 한 사람이 제품을 만들고 운영하는 구조에서 계획·검토·컴파운드 루프가 커질수록 어떤 병목이 새로 생길까?