AX Field Notes

전체 사례No. 047

Every, 코드는 안 써도 사람은 샌드위치의 빵

손 코딩을 멈추고 계획·검토·교훈 축적으로 옮겨 간 팀

사례 번호
047
1차 출처
Every's own articles and podcast transcript, plus vendor customer stories
원문 게시
2025-12-11

요약

  • 에이전트가 코드와 잡무를 맡고 사람은 계획과 검토, 다듬기를 맡았습니다.
  • 자동화 뒤에도 인원은 줄지 않고 검토와 교훈 축적으로 일이 옮겨 갔습니다.
  • 생성물이 넘쳐날수록 전문가 검토 전에 기계적으로 거르는 장치가 필요합니다.

열 배 큰 회사처럼 움직인다는 작은 팀의 실제 모습

2020년 4월 13일, 유료 뉴스레터 두 편을 하나로 묶은 작은 구독 상품이 세상에 나왔습니다. Dan Shipper의 Superorganizers와 Nathan Baschez의 Divinations를 한 번에 구독할 수 있게 한 소박한 묶음 상품이었습니다. 당시 회사의 설명은 단순했습니다. “예전에는 뉴스레터를 각각 따로 구독해야 했습니다.”

그로부터 몇 년 뒤, Every는 채용 페이지에서 자신들을 “미디어 회사이자 소프트웨어 회사이자 컨설팅 회사”라고 소개하기 시작했습니다. 13만 명 이상의 구독자를 둔 인공지능 일간 뉴스레터를 발행하고, 기업의 인공지능 도입을 자문하면서, 사내에서 직접 소프트웨어 제품들을 만들어 굴립니다. 이메일 비서 Cora, 글쓰기 보조 도구 Spiral, 음성 받아쓰기 앱 Monologue, 파일 정리 도구 Sparkle 같은 앱들이 그렇게 나왔습니다. 채용 페이지는 이 조직을 두고 “열 배 큰 회사처럼 출시하는 팀”이라고 표현합니다.

이들이 주목받는 이유는 단순히 결과물이 많아서가 아닙니다. 소프트웨어를 만드는 방식 자체가 전통적인 개발 조직과 완전히 다르기 때문입니다. 2025년 12월 11일, CEO이자 공동 창업자인 Dan Shipper와 Cora 총괄 매니저(general manager)인 Kieran Klaassen이 함께 쓴 글에는 이런 선언이 등장합니다. “아무도 손으로 코드를 쓰지 않습니다.”

이 사례의 기록은 대부분 Every 구성원들이 직접 쓴 글과 팟캐스트 녹취록에서 나왔으며, 협업 도구 Notion과 클라우드 플랫폼 Render가 발행한 고객 사례가 구체적인 세부를 보탭니다. Every는 이 과정에서 만든 도구를 공개하고 인공지능 에이전트와 구독, 컨설팅을 판매하는 기업이기도 합니다.

처음부터 에이전트를 전제로 세운 기술 회사가 아니었습니다. 평범한 뉴스레터 발행사로 출발해 소프트웨어와 컨설팅으로 영역을 넓혀 가던 작은 팀이, 소프트웨어 개발과 글쓰기, 일상 운영 전반을 에이전트 중심으로 다시 짠 현장 보고서에 가깝습니다.

제품은 늘어나는데 전통적 개발 방식은 한계에 부딪혔습니다

2025년 12월 기준으로 Every는 사내에서 소프트웨어 제품 5개를 운영하고 있었고, 몇 개를 더 준비하고 있었습니다. 각 제품은 매일 수천 명이 중요한 업무에 쓰고 있었지만, “주로 한 사람이 만들고 운영”하는 구조였습니다. 작은 조직이 여러 제품을 동시에 감당하기에는 물리적인 자원이 턱없이 부족했습니다.

Dan Shipper와 Kieran Klaassen은 전통적인 엔지니어링의 구조적 모순을 지적했습니다. 전통적인 개발에서는 기능 하나를 더할 때마다 다음 기능을 만들기가 더 어려워집니다. 코드가 늘어날수록 생각지 못한 예외 상황이 불어나고, 코드 사이의 상호 의존성이 얽히며, 미리 예측하기 힘든 오류가 계속 쌓이기 때문입니다. 저자들은 지금까지의 소프트웨어 공학이 “코딩은 어렵고 엔지니어는 귀하다”는 전제 위에 세워져 있었다고 보았습니다. 에이전트가 코드를 대신 작성할 수 있게 된 순간, 그 오랜 전제가 흔들리기 시작했습니다.

글을 쓰고 다듬는 편집 과정에서도 병목이 있었습니다. 편집장인 Kate Lee의 주요 업무는 발행 직전 마지막 검토인 ‘탑 에디트(top edit)‘입니다. 그런데 글의 구조와 방향을 바로잡아야 할 편집장이 마지막 단계에 이르러서야 글을 처음 읽는 일이 잦았습니다. 편집장이 이 단계에서 글을 처음 읽는 일이 많아 그의 판단은 맨 끝에야 들어갔습니다.

운영 업무도 복잡하게 얽혀 있었습니다. Notion을 본격적으로 쓰기 전에는 마케팅 자료가 주로 Google Drive에 흩어져 있었고, 중요한 맥락은 Slack 대화 속에 묻혀 사라지기 일쑤였습니다. 사람이 찾기도 어려운 정보는 에이전트가 접근해 활용하기도 어려웠습니다.

그런데 2026년 5월 무렵에는 병목이 다른 곳으로 옮겨 가 있었습니다. Dan Shipper는 팟캐스트에서 자동화 뒤의 풍경을 이렇게 설명했습니다. “대충 괜찮은 결과물이 넘쳐납니다.” “거의 맞지만 딱 맞지는 않은 것들로 판을 뒤덮습니다.”

COO인 Brandon Gell은 농담조로 “이게 되는지 전혀 모르겠지만 여기요”라며 검토 요청(PR)을 넘겼고, 이를 넘겨받은 리뷰어가 코드를 “완전히 다시 했다”고 Dan Shipper는 회상했습니다. 코드를 만들고 글을 찍어내는 일은 아주 쉬워졌지만, 그것이 정말로 맞는지 짚어내는 검토 작업이 조직의 가장 귀한 병목으로 떠오른 것입니다.

컴파운드 엔지니어링: 80%는 계획과 검토에 쏟습니다

Every는 이 문제를 풀기 위해 ‘컴파운드 엔지니어링(compound engineering)‘이라는 방식을 정립했습니다. 기능 하나를 만들 때마다 다음 기능이 더 쉬워지도록 배운 것을 차곡차곡 쌓는 방식입니다. 저자들은 이 일의 노력이 대략 계획과 검토에 80%, 실제 작업과 축적에 20%로 배분된다고 밝혔습니다. 사람이 코드를 치는 시간 대신, 에이전트에게 내릴 계획을 다듬고 결과물을 뜯어보는 시간이 업무의 대부분을 차지하게 된 것입니다.

초기 컴파운드 엔지니어링 루프는 4단계로 돌아갔습니다.

첫째는 계획 단계입니다. 에이전트가 기존 코드베이스와 이전 커밋 기록, 인터넷의 모범 사례들을 폭넓게 조사합니다. 그런 다음 목표와 아키텍처, 코드 접근법, 참고한 출처, 성공 기준을 담은 계획 문서를 파일이나 GitHub 이슈 형태로 작성합니다. 사람이 손을 놓고 모든 것을 넘기는 것이 아닙니다. 개발자는 에이전트가 조사해 온 내용을 검토하고 방향을 바로잡습니다. 저자들은 “좋은 계획은 순수한 위임이 아니다”라고 강조합니다. 에이전트가 모든 코드를 쓰는 환경에서는 개발자 시간의 대부분이 바로 이 계획 단계에 들어갑니다.

둘째는 작업 단계입니다. 에이전트는 승인된 계획 문서를 바탕으로 단계별 할 일 목록을 만들고 실제 코드를 작성합니다. 이때 에이전트는 코드만 치는 데 머물지 않습니다. 웹 브라우저 자동화 도구인 Playwright나 모바일 환경을 제어하는 XcodeBuildMCP를 사용해, 웹 앱을 직접 써 보거나 휴대폰 화면을 흉내 내며 스스로 오류를 잡아냅니다.

셋째는 검토 단계입니다. 코드 문법 검사기인 린터와 단위 테스트, 그리고 사람이 직접 만져 보는 수동 테스트가 함께 돌아갑니다. 사내에서는 Claude, Codex, Friday, Charlie 같은 코드 리뷰 에이전트를 활용합니다. 특히 Every가 Claude Code용으로 개발해 GitHub의 EveryInc 계정에 공개한 플러그인은, 12개의 리뷰 서브에이전트를 병렬로 동시에 실행합니다. 원문이 밝힌 서브에이전트의 관점은 흔한 보안 문제, 흔한 성능 문제, 그리고 필요 이상으로 복잡하게 과하게 만든 코드 검사 세 가지입니다. 12개의 에이전트가 각자의 눈으로 코드를 훑어낸 뒤 결과를 하나로 합치면, 개발자는 그 요약을 보고 무엇을 고칠지 최종 결정합니다.

리뷰 서브에이전트 병렬 검토
흔한 보안 문제흔한 성능 문제과하게 만든 코드나머지 9개 관점코드 변경결과 취합개발자가 수정 결정
Every의 Claude Code용 플러그인은 코드 변경 하나를 서브에이전트 12개로 병렬 검토한 뒤 결과를 합쳐 개발자가 수정 사항을 결정하게 합니다. (출처: Every)

넷째는 축적(compound) 단계입니다. 기능을 만들면서 맞닥뜨린 버그, 성능 저하 문제, 문제 해결 과정에서 배운 모든 교훈을 코드베이스 안이나 플러그인에 프롬프트와 규칙 형태로 기록합니다. 코드 리뷰에서 오간 코멘트들도 요약되어 저장됩니다. 이렇게 쌓인 교훈은 코드베이스와 함께 보관되기 때문에, 오늘 처음 입사해 코드를 한 번도 본 적 없는 사람도 에이전트를 통하면 오랫동안 일한 동료만큼이나 흔한 실수를 미리 피할 수 있습니다.

Every 엔지니어들은 주로 Anthropic의 Claude Code를 쓰고, 일부는 Factory의 Droid나 OpenAI의 Codex CLI를 사용합니다. 저자들은 “손으로 테스트를 쓰거나 문서가 많은 사람용 코드를 쓰는 일은 이제 필요 없다”고 적었습니다.

사람이 돌아오는 다듬기 단계: 8단계로 넓어진 루프

2026년 5월 29일, Kieran Klaassen은 기존 4단계를 8단계로 넓힌 루프를 공개했습니다. 구상(ideate)에서 시작해 브레인스토밍, 계획, 작업, 검토를 거쳐 다듬기(polish), 축적(compound), 반복으로 이어지는 흐름입니다.

이 확장에서 핵심은 검토 뒤에 새로 붙은 ‘다듬기’ 단계입니다. 에이전트가 코드를 다 짜고 테스트와 검토를 아무 탈 없이 통과했더라도, 사람이 직접 화면을 보며 디자인과 문구를 점검하고 실제 느낌을 살피는 과정입니다. Kieran Klaassen은 단계를 덧붙인 이유를 이렇게 밝혔습니다. “기술적으로는 다 돌아가는데 제품은 여전히 좋지 않을 때가 있습니다.” 에이전트가 기계적인 오류를 잡는 작업 단계는 “가장 좋은 의미에서 지루해졌다”는 것이 그의 설명입니다.

Every 컴파운드 엔지니어링 루프 확장
구상브레인스토밍계획작업검토다듬기사람이 느낌 확인축적반복계획·검토 대략 80%작업·축적 20%2025년 12월 기준2025년 12월 4단계2026년 5월 추가 단계
Every의 컴파운드 엔지니어링 루프는 4단계에서 8단계로 넓어졌으며, 검토 뒤 사람이 느낌을 확인하는 다듬기 단계가 추가되었습니다. (출처: Every)

팀 페이지에서 Compound Engineering 메인테이너(maintainer)라는 직함을 가진 Trevin Chow는 이 협업 구조를 샌드위치에 빗대어 설명했습니다. “AI는 가운데 속이고 사람은 양쪽의 빵입니다.” 시작할 때 무엇을 만들지 계획하고, 끝날 때 제품의 맛과 결을 다듬는 것은 오롯이 사람의 몫이라는 뜻입니다.

Render 고객 사례는 Kieran Klaassen이 Cora를 실제로 어떻게 운영하는지 보여줍니다. 그는 자신이 “lfg”라고 부르는 긴 실행 명령을 씁니다. 이 명령 하나를 내리면 계획 수립부터 코드 구현, 테스트, 검토 요청(PR) 생성까지 루프의 가운데를 대부분 사람 없이 돌립니다. 작업 크기에 따라 한 번 실행에 약 1시간에서 길게는 16시간까지 걸립니다.

그는 에이전트 세션 옆에 실제로 실행 중인 앱을 띄워 놓고 직접 화면을 보며 검토합니다. 그의 철칙은 기능 하나에 쓰는 시간의 절반은 제품을 만드는 데 쓰고, 나머지 절반은 그 작업에서 배운 교훈을 기록하는 데 쓰는 것입니다. 또한 그동안 쌓인 교훈 전체를 정기적으로 다시 점검해, 지금 코드베이스에도 여전히 맞는 규칙인지 확인하는 별도의 점검 명령을 돌립니다.

Render 글에 따르면 Kieran Klaassen은 그해 코드를 단 한 줄도 직접 쓰지 않았고, 코드 자체를 들여다보지도 않았습니다. 그는 Cora의 제품 기획과 엔지니어링 전체를 총괄하고 있으며, 디자인과 마케팅, 고객 지원은 각각 전담하는 동료들이 따로 맡고 있습니다. Dan Shipper는 팟캐스트에서 Kieran Klaassen이 Cora의 받은편지함 전체를 처음부터 끝까지 “한두 달 만에” 만들었다고 전했습니다.

실제 현장에서는 이 교훈 축적이 수작업 기록이 아니라 반자동화된 방식으로 돌아갔을 가능성이 높습니다. 기능 구현이 끝나는 시점에 스크립트를 실행해 코드 변경 사항과 12개 서브에이전트가 남긴 코멘트, 수정된 오류 내역을 취합한 뒤, 다음 작업 시 에이전트가 읽을 규칙 파일로 자동 정리했을 것입니다. 그리고 규칙이 너무 많아져 서로 충돌하거나 오래된 코드를 가리키게 되면, 별도 점검 명령을 통해 에이전트가 불필요한 규칙을 골라내 삭제를 제안하고 사람이 이를 승인하는 형태로 관리했을 것입니다.

편집실과 Slack으로 번진 에이전트 협업

에이전트를 업무 중심에 둔 방식은 개발팀 바깥으로도 똑같이 뻗어 나갔습니다.

Every 편집실의 작업은 글의 중심 논지와 구조를 잡는 ‘구성 편집(developmental edit)’, 문장을 다듬는 ‘문장 편집(line edit)’, 그리고 Kate Lee 편집장이 최종 검수하는 ‘탑 에디트’ 3단계로 나뉩니다. 모든 단계마다 에이전트가 개입합니다.

스태프 작가인 Katie Parrott는 초고를 쓰기 전에 Claude 프로젝트를 열고, 에이전트가 자신에게 한 번에 질문을 하나씩 던지며 인터뷰하도록 합니다. 생각을 말로 풀어내며 논리를 다진 뒤에야 글을 쓰기 시작합니다. 모든 초고는 진실성과 유용성, 고유한 목소리를 가졌는지 따지는 사내 기준을 통과해야 합니다. “이 글은 참인 무언가를 말하는가?” 같은 질문이 기준이 됩니다.

2026년 2월 당시 편집 매니저(managing editor)였던 Eleanor Warnock은 피치나 초고의 1차 판단, 복잡한 기술 문단을 알기 쉽게 풀어내는 작업, 그리고 사내 스타일 가이드를 기준으로 한 최종 문장 점검에 인공지능을 활용했습니다. Kate Lee 편집장은 미묘하고 주관적인 문장 표현을 결정할 때 Spiral 앱을 띄워 다양한 고쳐 쓰기 안을 추천받습니다. 소셜 미디어 게시물을 맡은 Anthony Scarpulla는 Claude에게 “완성된 게시물이 아니라 재료”를 받아낸 뒤, 모든 게시물을 사람이 직접 꼼꼼히 읽고 최종 승인합니다.

편집팀은 탑 에디트 스킬, 인공지능이 쓴 티가 나는 상투적 표현을 걸러내는 스킬, 스타일 가이드 검사기라는 세 가지 핵심 프롬프트 스킬을 만들어 사내 GitHub에 저장해 두고 함께 갱신합니다. Dan Shipper는 Kate Lee 편집장의 과거 교정 이력 3만 건을 모아 ‘Kate Pass’라는 새로운 스킬을 구축했고, 2026년 10월 글에서 이를 소개했습니다. 팀원이 초안을 두고 에이전트에게 검토를 요청하면, 에이전트가 Google Doc 문서 위에 직접 제안 형태로 수정 의견을 남깁니다.

이 방대한 교정 데이터 역시 실제로는 프롬프트 하나에 다 들어가지 않았을 것입니다. 3만 건의 수정 내역에서 군더더기 표현 덜어내기, 도입부 간결하게 다듬기 같은 대표적인 교정 패턴들을 에이전트로 분류해 모범 사례집으로 만든 뒤, 에이전트가 문서 도구와 연동해 원본을 해치지 않고 제안 모드로 의견을 남기도록 구현했을 것입니다.

일상 운영 업무에서도 에이전트 도입은 단계를 밟아 진화했습니다. 2026년 3월 Every는 사내에서 쓰던 개인용 비서인 ‘Plus One’을 공개했습니다. Slack 안에서 돌아가는 개인 맞춤형 OpenClaw 기반 에이전트였습니다. 구성원들은 버그를 분류하고, 마케팅 문구 초안을 작성하며, 성장 실험을 돌리는 데 이를 썼습니다. COO인 Brandon Gell은 45분 만에 자기 Plus One을 설정해 버그 보고서를 Notion으로 정리하고 캘린더 일정을 요약해 매일 아침 브리핑을 받도록 만들었습니다. Austin Tedesco 성장 책임자는 Claude Code로 직접 에이전트를 구축해 쓰면서도, 시스템을 다듬느라 여전히 적잖은 시간을 쓴다고 인정했습니다. 신뢰는 천천히 쌓였습니다. 아주 사소한 일부터 맡기기 시작해 에이전트의 책임 범위를 조금씩 넓혀 가는 방식이었습니다.

2026년 10월 6일, Every는 각자 쓰던 개인 비서를 하나로 합쳐 회사 전체가 함께 쓰는 단일 에이전트인 ‘Every Agent’를 발표했습니다. Claude Managed Agents를 바탕으로 구축되었으며, 출시 전까지 사내에서 약 6개월 동안 쓰였습니다.

이 전환의 핵심은 ‘공개된 협업’이었습니다. 아무 Slack 채널에서나 @Every를 부르고 할 일을 적으면, 에이전트가 해당 스레드 안에서 바로 작업을 처리합니다. 스레드 안에서 사람이 수정한 피드백은 고스란히 저장되어 다음 작업에 반영됩니다. Dan Shipper는 “공개적으로 프롬프트하는 것이 효과가 있는 이유는 대부분의 AI 사용이 보이지 않기 때문”이라고 설명했습니다. 동료들이 에이전트에게 일을 어떻게 시키고 바로잡는지 서로 보면서 배우게 만든 것입니다.

실제 활용은 직무를 가리지 않았습니다. Brandon Gell은 Documenso를 이용해 연사 계약서를 만들고 계약서와 함께 보낼 안내 이메일 초안을 작성하게 했습니다. Douglas Brundage 마케팅 책임자는 Thesis 콘퍼런스 웹사이트에 연사 두 명의 프로필을 추가하는 검토 요청(PR)을 에이전트를 통해 생성했고, 엔지니어가 이를 검토해 코드에 반영했습니다. Arielle Shipper 운영 책임자는 서비스 성과와 웹사이트 방문자, 이메일 통계를 하나로 합쳐 숫자가 서로 맞지 않는 부분을 짚어내는 주간 리더십 보고서를 만듭니다. Mike Taylor 평가 책임자(head of evals)는 매주 월요일마다 끝내지 못한 일들을 점검하고 한 주의 우선순위를 다시 세워 주는 개인 스킬을 만들어 썼습니다.

Every는 지금 같은 에이전트를 다른 회사의 Slack 워크스페이스에도 판매합니다.

Notion 고객 사례를 보면 분기 계획 수립도 에이전트가 맡았습니다. Brandon Gell이 만든 OKR 인터뷰 에이전트는 경영진의 우선순위를 바탕으로 전 직원을 1대1로 인터뷰한 뒤 표준화된 계획서를 작성했습니다. 이 인터뷰 과정은 “사실상 하루 만에” 끝났고, 매니저들은 완성된 계획을 검토하고 승인하기만 했습니다. Austin Tedesco는 다음 분기 계획을 세우는 데 단 20분 정도밖에 쓰지 않았습니다.

성장 지표 관리도 자동화되었습니다. Notion Workers가 데이터 소스 네 곳(사내 어드민 도구, Kit, Stripe, PostHog)을 6시간마다 조회해 정리하면, 에이전트가 매일 아침 7시 Slack에 성장 스코어카드를 올립니다. Austin Tedesco는 숫자가 맞아 보이는지만 눈으로 확인하고 지나갑니다. 그는 필요한 구조를 Codex나 Claude Code에 말로 설명해 에이전트, 워커, 데이터베이스를 만들게 했으며, 실제로 돌아가는 Worker 코드는 한 번도 직접 읽어본 적이 없다고 밝혔습니다. Brandon Gell은 조직의 운영 원칙을 한 문장으로 정리했습니다. “이 회사의 누구도 컴퓨터 잔심부름을 해서는 안 됩니다.”

자동화할수록 전문가는 더 귀해집니다

조직 안에서 사람의 역할은 완전히 달라졌습니다. Dan Shipper는 팟캐스트에서 사내 Slack 분위기를 전하며 “사람을 만날 확률만큼 에이전트를 만난다”고 말했습니다. 개발자뿐 아니라 모든 구성원이 일상적으로 Claude Code와 Codex를 쓰고, 누구나 검토 요청(PR)을 올리며, 반대로 엔지니어가 에세이를 씁니다.

비개발자가 올린 PR로 시스템이 망가지지 않도록 촘촘한 관문이 마련되었습니다. Dan Shipper는 “저장소 규칙과 검토 지침이 잘 갖춰져 있어서, Willy가 PR을 보기 전까지 이미 여러 단계를 거친다”고 설명했습니다. 편집실에서도 글이 최종 데스크에 도달하기 전에 여러 검증 스킬을 거치는 것과 똑같은 구조입니다.

실제로는 비개발자가 PR을 올리면 통합 빌드 시스템에서 린터와 자동 테스트가 먼저 돌고, 플러그인에 들어 있는 12개의 리뷰 서브에이전트가 보안과 성능 규칙에 맞는지 검토 댓글을 남겼을 것입니다. 에이전트가 지적된 문제를 스스로 수정한 뒤에야 Willy 같은 리뷰어에게 알림이 가며, 최종 승인과 코드 병합 권한은 끝까지 엔지니어가 쥐고 있었을 가능성이 큽니다.

이런 환경에서 사람은 어떤 일을 하게 될까요? Brandon Gell은 “전문가는 그 어느 때보다 중요합니다. 에이전트가 훌륭한 일을 하도록 기반을 놓기 때문입니다”라고 강조했습니다. 무엇이 좋은 코드이고 무엇이 좋은 글인지 기준을 세우는 감각, 에이전트가 쏟아낸 결과물의 결함을 한눈에 짚어내는 안목이야말로 자동화할 수 없는 영역이기 때문입니다.

팀 페이지를 보면 조직 구성도 이에 맞춰 바뀌었습니다. 평가 책임자(head of evals), AI 교육 책임자, 기업 AI 도입 책임자, 응용 AI 엔지니어, 플랫폼 책임자, Compound Engineering 메인테이너 같은 생소한 직함들이 이름을 올리고 있습니다. 반면 고객 지원 전담 인력은 단 한 명뿐입니다.

수치로 확인되는 변화도 분명합니다. 2025년 12월 11일 글에서 저자들은 Every의 경험을 바탕으로 “한 명의 개발자가 몇 년 전 개발자 다섯 명의 일을 할 수 있다”고 추정했습니다. 하지만 이는 인력을 줄이기 위한 수단이 아니었습니다. Dan Shipper는 팟캐스트에서 GPT-3를 쓰던 초창기 4명이었던 인원이 약 30명으로 늘었다고 밝혔습니다. Notion 고객 사례에는 20명 팀에 약 30개의 에이전트가 돌아간다고 적혀 있고, 2026년 10월 22일 확인한 팀 페이지에는 기고 작가를 포함해 총 34명이 일하고 있었습니다.

Dan Shipper는 2026년 5월 에세이에서 이렇게 털어놓았습니다. “Every에서는 자동화할 수 있는 것은 다 자동화했습니다.” “그런데도 사람이 할 일은 그 어느 때보다 많습니다.” 그는 팟캐스트에서도 “지금 더 채용하고 있다”고 덧붙였습니다. 자동화가 회사를 줄이지 않았고, 사람의 시간은 손으로 코드를 쓰는 일에서 계획, 검토, 다듬기, 교훈 기록으로 옮겨 갔습니다.

다른 조직이 이 사례에서 읽어내야 할 점

Every의 실험을 살펴볼 때는 몇 가지 한계를 함께 염두에 두어야 합니다.

Every는 기본적으로 규모가 작은 조직입니다. 인공지능 기술 자체를 매일 취재해 글을 쓰는 회사이고, 새로운 파운데이션 모델이 나오면 출시 당일 리뷰를 내놓을 정도로 구성원들의 이해도와 관심이 남다릅니다. 무엇보다 이들이 운영하는 소프트웨어 제품들은 규모가 작고, 각 제품마다 한 명의 담당자가 전권을 쥐고 움직입니다. 수백 명의 엔지니어가 수십 년 동안 얽혀 있는 거대한 레거시 코드베이스를 다루는 대기업 환경에서 이 방식이 똑같이 작동할지는 아직 증명되지 않았습니다. 또한 Every 스스로가 관련 도구를 배포하고 기업 대상 컨설팅을 제공하는 만큼, 자사의 경험을 더 매력적으로 전하려는 동기가 녹아 있을 수 있습니다.

그럼에도 Every가 겪어낸 시행착오는 규모와 업종을 불문하고 모든 기업 리더에게 중요한 질문을 던집니다.

첫째, 생성의 시대에는 검토가 가장 희소한 자원이 됩니다. 에이전트를 도입하면 코드나 초안을 빠르게 대량으로 만들어 냅니다. 하지만 그 결과물은 대부분 “대충 괜찮지만 딱 맞지는 않은” 수준에 머뭅니다. 이때 전문가가 아무런 안전장치 없이 그 결과물을 하나하나 확인하려 들면, 검토 피로로 조직 전체가 마비됩니다. 12개의 서브에이전트나 자동화된 저장소 규칙처럼, 전문가의 눈앞에 도달하기 전에 기계적인 오류를 미리 걸러내는 다단계 필터링 장치가 반드시 함께 마련되어야 합니다.

둘째, 사람이 일한 결과는 반드시 다음 에이전트를 위한 규칙으로 축적되어야 합니다. Kieran Klaassen이 작업 시간의 절반을 배운 것을 정리하는 데 쓰고, Dan Shipper가 Kate Lee의 과거 교정 3만 건을 스킬로 만든 이유가 여기에 있습니다. 한 번 해결한 문제의 원인과 해결 방식을 코드베이스나 프롬프트 형태로 남겨 두지 않으면, 다음에 돌아가는 에이전트는 똑같은 실수를 끝없이 반복합니다. 일회성 작업으로 끝내지 않고 다음 작업의 자산으로 남기는 규칙을 세워야 합니다.

셋째, 인공지능 도입은 혼자 쓰는 골방에서 열린 광장으로 나와야 합니다. 개인용 비서를 각자 쓸 때는 누가 어떤 프롬프트로 무슨 효율을 내는지 알 수 없었고, 도구를 다듬느라 오히려 시간을 잃기도 했습니다. 하지만 Slack의 공용 채널에서 @Every를 부르며 일하는 방식을 공유하자, 공개 채널에서 서로의 프롬프트를 보고 따라 할 수 있게 되어 인공지능 사용이 더 빨리 퍼졌습니다.

손으로 코드를 치고 문장을 고치는 일은 점점 사라지고 있습니다. 그러나 무엇을 만들지 결정하는 계획의 깊이, 기술적으로 완성된 제품을 사용자의 눈높이에 맞게 매만지는 감각, 그리고 시스템이 엉뚱한 길로 새지 않도록 감시하는 비판적 검토는 오직 사람의 영역으로 남아 있습니다. 기계에게 작업을 넘길수록, 그 결과물을 꿰뚫어 보는 사람의 기준은 그 어느 때보다 중요해지고 있습니다.

출처