Every의 일하는 방식 재편

1. 왜 이 사례인가

Every(every.to)는 2020년 4월 13일, 댄 시퍼의 Superorganizers와 네이선 배셰즈의 Divinations라는 두 유료 뉴스레터를 묶은 번들 서비스로 출발했습니다. 출시 당시 글에서는 이를 단순하게 설명했습니다. “이전에는 각 뉴스레터를 따로 구독해야 했습니다.” 그로부터 6년 뒤 Every의 채용 페이지는 회사를 “미디어 기업이자 소프트웨어 기업, 그리고 컨설팅 기업”으로 소개하며, “규모가 열 배에 달하는 조직처럼 제품을 출시하는” 팀이 운영한다고 적고 있습니다. 회사는 AI를 다루는 일간 뉴스레터를 발행하고, 자체 앱(이메일 비서 Cora, 글쓰기 도구 Spiral, 받아쓰기 앱 Monologue, 파일 정리 도구 Sparkle)을 운영하며, 기업들의 AI 도입을 자문합니다.

이 사례의 핵심 기준 자료는 댄 시퍼와 Cora 총괄 매니저인 키어런 클라슨이 2025년 12월 11일에 발행한 글 컴파운드 엔지니어링: Every가 에이전트로 코딩하는 방식(Compound Engineering: How Every Codes With Agents)입니다. 글에서 두 저자는 이렇게 밝혔습니다.

“아무도 손으로 직접 코드를 작성하지 않습니다.”

2026년 5월 에세이에서 댄 시퍼는 한 걸음 더 나아갔습니다. “Every에서는 자동화할 수 있는 모든 것을 자동화했습니다.”

이 사례는 세 가지 점에서 눈에 띕니다. 첫째, Every는 처음부터 에이전트를 전제로 세워진 회사가 아닙니다. 기존에 운영되던 소규모 미디어 기업이 몇 년에 걸쳐 개발, 편집, 운영 업무를 에이전트로 점진 전환한 사례이므로, 백지상태의 설계가 아닌 현실적인 전환 과정을 보여 줍니다. 둘째, Every는 자신들의 작업 방식을 매우 구체적으로 기록으로 남겼습니다. 독자적인 엔지니어링 루프(컴파운드 엔지니어링(compound engineering)), 공개된 Claude Code 플러그인, 공유 AI 스킬을 갖춘 편집 프로세스, 전사 공유 Slack 에이전트 등이 대표적입니다. 셋째, 회사는 자동화가 해결해 주지 못한 문제를 솔직하게 밝힙니다. 직원 수는 줄어들지 않고 오히려 늘어났으며, 댄 시퍼와 COO 브랜던 겔은 에이전트의 산출물이 만들어 낸 새로운 검토 업무를 가감 없이 설명합니다.

자료의 대부분은 Every가 직접 작성한 글입니다. Every는 자신이 설명하는 플러그인을 공개하고 에이전트, 구독 상품, 컨설팅을 직접 판매하므로, 자체 프로세스에 대한 기록은 마케팅 성격도 함께 띱니다. 두 곳의 벤더 고객 사례(Notion 및 Render)가 구체적인 세부 내용을 보완하며, 해당 내용은 인용 시 출처를 밝혔습니다.

2. Problem

Every의 자료들은 변화를 촉발한 단 하나의 결정적 위기를 언급하지는 않습니다. 대신 출판사, 소프트웨어 개발사, 컨설팅사를 동시에 해내려던 작은 조직이 맞닥뜨린 현실적 조건들을 서술합니다.

제품은 많고 인력은 부족한 환경. 2025년 12월 글에 따르면 회사는 인큐베이팅 단계의 몇몇 프로젝트 외에도 “사내에서 5개의 소프트웨어 제품을 운영”하고 있으며, 각 제품은 “주로 단 한 사람에 의해 개발 및 운영”되고 “매일 수천 명이 중요한 업무에 사용”하고 있습니다.

시간이 갈수록 유지보수가 어려워지는 코드베이스. 댄 시퍼와 키어런 클라슨은 이 문제를 엔지니어링 관점에서 이렇게 정의합니다.

“전통적인 엔지니어링에서는 기능을 하나 추가할 때마다 다음 기능을 만들기가 더 어려워질 것으로 예상합니다.”

이들은 “코드가 많아질수록 엣지 케이스, 상호 의존성, 예측하기 어려운 문제가 늘어난다”라며, “지금까지의 수많은 엔지니어링 관행은 코딩이 어렵고 엔지니어가 부족하다는 전제 위에 서 있었다”라고 덧붙입니다. 하지만 에이전트가 코드를 작성할 수 있게 된 순간, 그 오랜 관행을 지탱하던 기본 전제는 더 이상 유효하지 않게 되었다고 저자들은 주장합니다.

편집과 지식 전달의 병목. 2026년 2월, 편집장 케이트 리는 자신의 역할을 이렇게 설명했습니다. “내 업무는 톱 에디트, 즉 발행 전 마지막 검토입니다.” 케이트 리는 이 단계에서 글을 처음 읽는 경우가 많아, 편집장의 판단이 전체 과정의 가장 끝자락에야 개입하게 됩니다. 운영 측면에서도 Notion 고객 사례(벤더 출처, 날짜 없음)에 따르면, Every가 업무를 Notion으로 옮기기 전에는 마케팅 자료가 주로 Google Drive에 흩어져 있었고 중요 맥락이 Slack 안에서 자주 유실되어 에이전트가 필요한 정보를 찾기 어려웠습니다.

자동화 이후 새롭게 나타난 병목. 2026년 5월에 이르자 병목 지점이 완전히 이동했습니다. 브랜던 겔과 함께한 팟캐스트에서 댄 시퍼는 “자동화는 모두 그럭저럭 괜찮고 제법 쓸 만한 결과물을 과도하게 쏟아낸다”라며, “그 결과 아슬아슬하게 어긋난 수준의 작업물들이 공간을 가득 메우게 된다”라고 말했습니다. 브랜던 겔은 “이게 제대로 돌아가는지 솔직히 전혀 모르겠지만 일단 전달합니다”라는 말과 함께 풀 리퀘스트를 넘기던 상황을 농담조로 회상했고, 댄 시퍼는 검토자가 이를 “완전히 처음부터 다시 작업해야 했다”라고 털어놓았습니다. 이제 부족한 자원은 제작 역량이 아니라 검토 역량이 되었습니다.

확인된 사실: 2020년 4월 13일 두 개 뉴스레터의 번들로 설립됨; 스스로 미디어, 소프트웨어, 컨설팅 기업으로 정의; 사내 5개 소프트웨어 제품 각각을 주로 1인이 개발 및 운영(2025-12-11); 전통적 엔지니어링이 새 기능 개발을 갈수록 어렵게 만든다는 저자들의 문제의식; 편집장이 톱 에디트 단계에서 처음 글을 확인하는 경우가 많음; 이전에는 마케팅 맥락이 Google Drive와 Slack에 분산되어 있었음(Notion, 벤더); 자동화 이후 “아슬아슬하게 어긋난” 결과물의 과잉과 검증되지 않은 풀 리퀘스트 발생(팟캐스트, 2026-05-27).

3. Solution

3.1 엔지니어링: 컴파운드 엔지니어링 루프

댄 시퍼와 키어런 클라슨은 전통적 모델과 대비해 이 개념을 다음과 같이 정의합니다.

“반면 컴파운드 엔지니어링에서는 기능을 하나 추가할 때마다 다음 기능을 만들기가 더 쉬워질 것으로 기대합니다.”

2025년 12월 글에서는 네 단계를 제시합니다.

* 계획(Plan). 에이전트가 기존 코드베이스, 커밋 기록, 온라인 모범 사례를 조사한 뒤 목표, 아키텍처, 코드 접근 방식, 참고 자료, 성공 기준을 담은 계획서를 작성하여 파일이나 GitHub 이슈로 저장합니다. 방향 제어는 개발자가 맡습니다. “좋은 계획 수립은 단순한 위임이 아닙니다.” 글은 “에이전트가 모든 코드를 작성하는 세상에서는 개발자 시간의 대부분이 계획 수립에 쓰인다”라고 덧붙입니다.

* 작업(Work). 에이전트가 계획을 할 일 목록으로 변환하고 단계별로 구현합니다. 에이전트는 Playwright와 XcodeBuildMCP를 사용해 작업 도중 웹 앱을 직접 띄워 보거나 모바일 환경을 시뮬레이션함으로써, 스스로 문제를 발견하고 수정할 수 있습니다.

* 리뷰(Review / assess). 에이전트와 엔지니어가 린터, 단위 테스트, 수동 테스트를 활용해 결과물을 점검합니다. 글에 언급된 코드 리뷰 에이전트로는 Claude, Codex, Friday, Charlie가 있습니다. Every가 만든 Claude Code용 컴파운드 엔지니어링 플러그인은 12개의 리뷰 서브에이전트를 병렬로 실행하며, 각 에이전트는 흔한 보안 취약점, 일반적인 성능 문제, 과도하게 복잡하게 짜인 코드 등을 전담 확인합니다. 점검 결과가 하나로 취합되면 무엇을 수정할지는 개발자가 결정합니다.

* 컴파운드(Compound). 버그, 성능 이슈, 문제 해결 과정에서 얻은 교훈을 코드베이스 내부나 플러그인에 프롬프트 형태로 기록합니다. 코드 리뷰 의견은 요약되어 저장됩니다. 이러한 프롬프트가 코드베이스와 함께 관리되므로, 해당 코드를 처음 접하는 신규 입사자도 오랫동안 근무한 팀원만큼 “흔한 실수를 피할 수 있는 준비를 갖추게 됩니다.”

저자들은 업무 비중이 양쪽 끝에 쏠려 있다고 설명합니다. “컴파운드 엔지니어링의 대략 80%는 계획과 리뷰 단계에 들어가며, 20%만이 작업과 컴파운드 단계에 쓰입니다.” 이들은 주로 Anthropic의 Claude Code를 쓰며, 팀원에 따라 Factory의 Droid나 OpenAI의 Codex CLI를 병용합니다. 저자들은 또한 “손으로 테스트 코드를 작성하거나 긴 문서가 딸린 사람이 읽기 좋은 코드를 쓰는 일은 이제 불필요해졌다”라고 덧붙입니다. 해당 플러그인은 GitHub의 EveryInc 계정에 공개되어 있습니다.

3.2 인간의 다듬기 단계를 추가한 루프 확장

2026년 5월 29일, 키어런 클라슨은 확장된 루프를 발표했습니다.

“아이디어 발상 → 브레인스토밍 → 계획 → 작업 → 리뷰 → 다듬기 → 컴파운드 → 반복”

새로 추가된 다듬기(polish) 단계는 작업물이 기술적 리뷰를 통과한 뒤 사람이 다시 개입하여 디자인과 문구를 검토하고 사용자 경험이 온전한지 확인하는 과정입니다. 키어런 클라슨은 “모든 것이 기술적으로는 작동하지만 제품 자체는 여전히 훌륭하지 않은 경우가 있기 때문”이라고 이유를 밝혔습니다. 그는 또한 “작업 단계는 가장 이상적인 의미에서 지루한 일이 되었다”라고 적었습니다. 팀 소개 페이지에서 컴파운드 엔지니어링 메인테이너로 명시된 트레빈 차우는 이 구조를 샌드위치에 비유합니다. “AI는 중간에 들어가는 속재료입니다. 사람은 양쪽 끝에서 형태를 잡아 주는 빵 역할을 합니다.”

Render의 블로그 글(벤더 출처, 2026-07-26)은 키어런 클라슨이 Cora를 이런 방식으로 운영하는 과정을 소개합니다. 그가 “lfg”라 부르는 장기 실행 명령은 계획 수립부터 구현, 테스트, 풀 리퀘스트 생성에 이르는 “루프의 중간 과정 전체를 사람의 개입 없이 거의 스스로” 처리하며, 실행에는 “작업 규모에 따라 약 1시간에서 길게는 16시간”이 걸립니다. 그는 “에이전트 세션 옆에 앱을 띄워 놓고 지켜보며” 리뷰를 진행합니다. 그의 업무 원칙은 “기능을 만드는 데 시간의 절반을 쓰고, 나머지 절반은 해당 작업이 남긴 교훈을 정리하는 데 쓰는 것”이며, 별도의 명령어가 “누적된 전체 교훈을 정기적으로 점검하여 여전히 유효한지 확인”합니다. 해당 글에 따르면 키어런 클라슨은 “올해 들어 코드 한 줄도 직접 쓰지 않았고, 코드를 들여다본 적조차 없습니다.” 그는 Cora의 제품 기획과 엔지니어링을 총괄하며, “디자인, 마케팅, 고객 지원은 각 담당자가 따로 맡고 있습니다.”

3.3 편집: 모든 단계에 AI를 두되 결정은 사람이 진행

케이트 리가 2026년 2월에 작성한 글은 편집 프로세스를 상세히 다룹니다. 초안은 “주제 의식, 구조, 논지를 다듬는 구성 편집”, “문장을 다듬는 라인 에디트”, 그리고 케이트 리의 톱 에디트를 거칩니다. AI는 모든 단계에 관여합니다.

* 작가. 소속 작가 케이티 패럿은 초안 작성 전 Claude 프로젝트를 띄우고 한 번에 질문 하나씩 인터뷰를 진행하도록 요청합니다. 완성된 초안은 진실성, 유용성, 고유한 문체 기준을 통과해야 하며, “이 글이 진실된 무언가를 명확히 표현하고 있는가?” 같은 질문을 검증받습니다.

* 편집 관리자. 글 작성 당시