Code Factory: 에이전트가 나눠 짜고 리뷰 에이전트가 병합을 허락하는 개발 공장

Loren Stewart의 코드 공장에서 사람의 몫은 사실상 계획 검토로 좁혀졌습니다. 구현, 버그 찾기, 상호 리뷰, 수정은 에이전트가 나눠 맡습니다. 병합은 자동 검사와 별도 리뷰 에이전트의 승인을 둘 다 넘어야 열립니다. 따라 하려면 테스트가 받쳐 주는 코드베이스와, 어떤 일을 공장에 맡기고 어떤 일을 손에 남길지 정한 기준이 먼저 있어야 합니다.

요약

Every의 Source Code 섹션에 실린 이 글에서 Every 엔지니어 Loren Stewart(Every의 Slack 에이전트 담당)는 지난 두 달 남짓 만든 “code factory”(코드 공장)를 소개합니다. 공장은 네 단계로 움직입니다. 먼저 저자가 LLM과 함께 계획을 세우고 직접 검토합니다. 이어 다른 에이전트가 그 계획을 한 번 더 봅니다. 공장은 계획을 작은 조각으로 나누고, 여러 에이전트가 이 조각을 동시에 구현합니다. 에이전트는 브라우저와 터미널을 써서 기능을 만들고, 버그를 찾고, 서로의 작업을 리뷰하고, 문제를 고칩니다. 변경분은 자동 검사가 통과하고 별도 리뷰 에이전트가 지적 사항을 하나하나 모두 승인해야 병합됩니다.

공개 부분에 나온 공장의 흐름. 사람의 손은 1단계 검토에 주로 남습니다.

결과에 대한 저자의 평가는 분명합니다. 공장을 켜 두고 하루를 보내다 돌아오면 새 기능이나 앱 하나가 완성돼 있습니다. 결과물은 더 빨리 나오고, 저자 표현으로는 “may be better than what I would have written myself”(직접 쓴 것보다 나을 수도 있다)입니다. 다만 편집자 Kate Lee의 소개에 따르면 저자는 손으로 짜던 일을 내려놓으면서 일을 즐겁게 하던 시행착오를 잃었습니다. 글은 이 상실을 카를 마르크스의 소외(alienation) 이론으로 풀고, AI가 사람을 코드에서 떼어 놓는 네 가지 방식과 자동화·감독·손코딩을 가르는 기준을 다룹니다. 이 노트는 무료로 공개된 앞부분, 곧 공장의 구조와 저자가 밝힌 효과까지만 다룹니다. 네 가지 방식과 판단 기준은 회원 공개 부분에 있어 옮기지 않았습니다. 아래에서는 공장의 각 단계를 풀고, 실제로 돌릴 때 필요한 설정과 일정을 덧붙입니다.

왼쪽은 저자가 밝힌 효과, 오른쪽은 편집자 소개와 부제가 예고한 비용입니다.

핵심 메커니즘

Plan Review: 구현 전에 계획을 두 번 검토하기

무엇인가. 코드를 한 줄도 쓰기 전에 계획을 사람이 한 번, 다른 에이전트가 한 번 검토하는 단계입니다.

어떻게 작동하나. 저자는 LLM과 대화하며 만들 기능의 계획을 짜고 스스로 검토합니다. 그다음 계획을 쓴 쪽이 아닌 별도 에이전트에게 다시 검토를 맡깁니다. 이렇게 두 번 걸러진 계획이 뒤의 분할과 병렬 구현의 기준이 됩니다. 사람의 판단이 가장 많이 들어가는 곳이 바로 여기입니다.

언제 쓰고 언제 안 쓰나. 여러 에이전트에게 나눠 맡길 만큼 큰 기능일수록 쓸모가 큽니다. 계획이 틀리면 병렬로 도는 에이전트 모두가 같은 방향으로 틀리기 때문입니다. 한 줄짜리 수정처럼 계획 자체가 필요 없는 일에는 과합니다.

원문의 예. 저자는 계획 단계만큼은 본인이 직접 검토한다고 밝혔습니다. 어떤 LLM을 썼는지는 공개 부분에 나오지 않습니다.

구현보다 앞에서 사람과 에이전트가 한 번씩 계획을 봅니다.

Chunking·Parallel Agents: 계획을 쪼개 여러 에이전트에 동시에 맡기기

무엇인가. 검토된 계획을 작은 조각(chunk)으로 나눠 에이전트 여러 개가 동시에 구현하게 하는 방식입니다.

어떻게 작동하나. 공장이 계획을 받아 독립적으로 끝낼 수 있는 작은 단위로 자릅니다. 각 조각을 에이전트 하나가 맡아 나란히 진행합니다. 한 사람이 순서대로 짜던 일을 여러 갈래로 펼치는 셈이라, 저자가 하루를 다른 일에 쓰는 동안 기능 전체가 완성될 수 있습니다.

언제 쓰고 언제 안 쓰나. 조각끼리 서로 기다리는 일이 적을 때 효과가 큽니다. 모든 조각이 같은 파일 하나를 고쳐야 하는 일이라면 병렬로 돌려도 충돌만 늘어납니다.

작은 예시(가상 예시). 사내 결재 앱에 ‘대리 결재’ 기능을 넣는다고 합시다. 데이터 모델, API, 화면, 알림의 네 조각으로 나누면 데이터 모델과 알림은 바로 시작하고, API와 화면은 데이터 모델이 정해진 뒤 동시에 시작할 수 있습니다.

가상 예시. B·C는 A의 데이터 모델에 기대므로 다음 칸에서 시작하고, D는 독립이라 A와 동시에 돕니다.

Tool-Using Agents: 브라우저와 터미널을 쥔 구현 에이전트

무엇인가. 코드를 생성하는 데서 그치지 않고 브라우저와 터미널을 직접 다루며 결과를 확인하는 에이전트입니다.

어떻게 작동하나. 저자의 에이전트는 네 가지 일을 합니다. 기능을 구현하고, 버그를 찾고, 다른 에이전트의 작업을 리뷰하고, 문제를 고칩니다. 터미널로는 코드를 돌리고 테스트를 실행합니다. 브라우저로는 만든 화면을 직접 열어 확인하거나 버그를 재현합니다. 에이전트가 자기 결과를 실행해 보고 고치므로 사람에게 넘어오는 것은 이미 한 번 검증된 변경분입니다.

언제 쓰고 언제 안 쓰나. 결과를 실행해 확인할 수 있는 일, 곧 테스트나 화면으로 맞고 틀림이 드러나는 일에 맞습니다. 운영 데이터나 운영 계정에 닿아야만 확인되는 일은 에이전트에게 그 권한을 주는 위험이 더 큽니다.

저자의 에이전트는 기능 구현, 버그 찾기, 서로의 작업 리뷰, 수정을 모두 맡습니다.

Merge Gate: 자동 검사와 리뷰 에이전트 승인을 모두 넘어야 병합

무엇인가. 에이전트가 만든 변경분이 메인 코드에 들어가기 전에 지나야 하는 두 개의 관문입니다.

어떻게 작동하나. 첫 관문은 자동 검사입니다. 검사가 하나라도 실패하면 병합하지 않습니다. 두 번째 관문은 구현 에이전트와 분리된 리뷰 에이전트입니다. 리뷰 에이전트가 낸 지적 사항이 모두 승인돼야 병합이 열립니다. 사람이 줄마다 리뷰하던 자리를 이 두 관문이 맡습니다. 저자가 결과를 믿고 하루를 비울 수 있는 근거도 여기서 나옵니다.

언제 쓰고 언제 안 쓰나. 자동 검사가 촘촘한 코드베이스에서 힘을 씁니다. 테스트가 거의 없는 저장소라면 첫 관문이 사실상 비어 있어 리뷰 에이전트 하나에 모든 판단이 몰립니다.

두 게이트 중 하나라도 걸리면 병합하지 않고 수정 루프로 돌아갑니다.

Automate·Supervise·Hand-code: 일마다 손과의 거리를 고르기

무엇인가. 글의 부제가 제시한 세 가지 작업 방식입니다. 일을 공장에 통째로 맡기거나(자동화), 에이전트가 하게 두고 지켜보거나(감독), 사람이 직접 씁니다(손코딩).

어떻게 작동하나. 공장은 빠르지만 사람을 코드에서 멀어지게 합니다. 편집자 소개에 따르면 저자가 잃은 것은 시행착오, 그리고 그 과정에서 오던 일의 즐거움입니다. 그래서 모든 일을 공장에 넣기보다 일마다 셋 중 하나를 고르자는 것이 글의 방향입니다. 어떤 일을 어디에 둘지에 대한 저자의 구체적 기준은 회원 공개 부분에 있습니다.

언제 쓰나. 공장을 도입한 팀이 무엇을 계속 손으로 할지 정해야 할 때 씁니다. 아래 현업 실행 디테일에 AX Review가 정리한 예시 기준을 붙였습니다.

세 방식의 이름은 부제에서 왔습니다. 어느 일을 어디에 둘지의 저자 기준은 회원 공개 부분에 있습니다.

통념과 다른 주장

흔히 이렇게 봅니다에이전트가 쓴 코드는 사람이 직접 쓴 코드보다 품질이 낮으므로, 사람이 한 줄씩 리뷰해야 안심할 수 있다고 봅니다.

저자는 이렇게 봅니다계획 검토, 분할, 자동 검사, 리뷰 에이전트를 구조로 묶으면 결과가 더 빠를 뿐 아니라 직접 쓴 것보다 나을 수도 있다고 봅니다. 사람의 판단은 줄 단위 리뷰가 아니라 계획 검토에 들어갑니다.

근거두 달 남짓 직접 운영한 공장에서, 켜 두고 하루를 보낸 뒤 완성된 기능이나 앱을 받아 온 경험입니다.

저자의 근거는 두 달 남짓 직접 돌려 본 자신의 공장입니다.

저자가 든 사례

Every의 Loren Stewart: 두 달 남짓 돌린 코드 공장

구분	내용
상황	Every에서 Slack 에이전트를 맡은 엔지니어가 구현 대부분을 에이전트에 맡기기로 함
한 일	계획 이중 검토 → 작은 단위로 분할 → 브라우저·터미널을 쓰는 에이전트의 병렬 구현과 상호 리뷰 → 자동 검사와 리뷰 에이전트 승인을 거친 병합
결과	공장을 켜 두고 하루를 보낸 뒤 기능이나 앱 하나를 받음. 더 빠르고 직접 쓴 것보다 나을 수도 있음. 대신 손으로 짜며 겪던 시행착오와 그 즐거움을 잃음(편집자 소개). 처리 건수·기간 같은 수치는 원문 공개 부분에서 밝히지 않음
연결	Plan Review, Chunking·Parallel Agents, Tool-Using Agents, Merge Gate가 한 흐름으로 묶인 사례이며, 잃은 것은 Automate·Supervise·Hand-code 판단으로 이어짐

공장을 만든 계기와 기능별 수치는 원문 공개 부분에 없습니다.

기술 디테일: 실제로 돌릴 때 필요한 것

원문 공개 부분은 공장의 구조만 밝히고 모델, 도구, 설정값은 밝히지 않습니다. 아래는 같은 구조를 처음 세울 때 필요한 내용을 새로 정리한 것입니다.

Plan Review를 돌리려면 계획을 구조화된 문서로 남겨야 합니다. 계획이 대화 기록에만 있으면 리뷰 에이전트도, 분할 단계도 같은 것을 보지 못합니다. 계획을 아래처럼 조각 단위 JSON으로 고정해 두면 리뷰 에이전트가 빠진 완료 조건이나 숨은 의존을 짚기 쉽습니다(가상 예시).

{
  "feature": "대리 결재",
  "chunks": [
    {
      "chunk_id": "A",
      "goal": "delegation 테이블과 마이그레이션 추가",
      "files_touched": ["db/migrations/", "models/delegation.ts"],
      "depends_on": [],
      "acceptance": ["마이그레이션 up/down 테스트 통과"],
      "out_of_scope": ["화면 변경"]
    },
    {
      "chunk_id": "B",
      "goal": "대리인 지정·해제 API",
      "files_touched": ["api/delegation/"],
      "depends_on": ["A"],
      "acceptance": ["권한 없는 사용자 403 테스트"],
      "out_of_scope": ["알림 발송"]
    }
  ]
}

리뷰 에이전트에게는 “고칠 점”을 자유 문장이 아니라 {"chunk_id", "issue", "severity": "block|warn", "suggested_fix"} 목록으로 받습니다. block이 하나라도 남으면 분할 단계로 넘기지 않습니다. 계획을 쓴 세션과 리뷰하는 세션은 분리합니다. 같은 대화 맥락을 이어 받으면 같은 맹점을 공유하기 쉽기 때문입니다. 가능하면 다른 모델로 교차 검토합니다.

Chunking·Parallel Agents를 돌리려면 조각마다 작업 공간을 분리해야 합니다. 에이전트마다 별도 브랜치와 git worktree(저장소 하나에서 작업 폴더를 여러 개 띄우는 기능)를 줍니다. 조각의 files_touched가 겹치면 같은 시간대에 배정하지 않고 depends_on 순서로 돌립니다. 처음에는 동시에 3개만 돌리고, 병합 충돌 없이 2주를 넘기면 5개로 늘리는 식으로 시작합니다.

Tool-Using Agents를 돌리려면 샌드박스부터 갖춰야 합니다. 에이전트의 터미널은 운영 접속 정보가 없는 격리 환경에서 돌립니다. 브라우저 확인은 헤드리스 브라우저 자동화 도구(예: Playwright)로 하고, 확인할 때마다 화면 캡처와 콘솔 로그를 변경분에 첨부하게 합니다. 사람이 나중에 “왜 이렇게 고쳤는지”를 따라갈 수 있게 하는 기록이기도 합니다.

Merge Gate를 돌리려면 두 관문을 각각 측정해야 합니다. 첫 관문(자동 검사)에는 타입 검사, 린트, 단위 테스트, 화면 흐름 테스트를 넣습니다. 두 번째 관문(리뷰 에이전트)은 지적마다 {"issue_id", "status": "open|resolved", "evidence"}를 남기고, 모든 항목이 resolved여야 병합 신호를 냅니다. 구현 에이전트가 같은 조각을 3번 고쳐도 통과하지 못하면 사람에게 넘기고 사유를 기록합니다. 리뷰 에이전트가 형식적으로 승인만 하는지 보려면 일부러 버그를 심은 변경분을 섞어 걸러 내는 비율을 잽니다.

실패하는 경우	증상	대응
조각끼리 같은 파일을 고침	병합 충돌, 서로 덮어쓴 변경	`files_touched` 겹침 검사 후 순차 배정
테스트가 얇음	첫 관문이 무엇이든 통과	조각마다 완료 조건 테스트를 먼저 작성
리뷰 에이전트가 무조건 승인	심어 둔 버그가 병합됨	리뷰 세션·모델 분리, 정기적으로 버그 심기 시험
수정 루프가 끝나지 않음	같은 조각이 계속 실패	3회 상한, 넘으면 사람에게 넘김

가상 예시. 원문 공개 부분에는 설정값이 없으며 첫 시범용 출발점으로 제안합니다.

현업 실행 디테일: 누가, 언제, 무엇을

공장을 들이는 일은 도구 설치보다 역할을 다시 나누는 일에 가깝습니다. 아래는 개발 조직 한 팀이 4주 동안 시범을 돌리는 예시입니다.

역할	맡는 일	산출물
기능 오너(엔지니어)	계획 작성과 1차 검토, 결과 점검	조각 단위 계획 문서
플랫폼 담당	CI, 샌드박스, worktree 자동화, 실행 로그	공장 실행 환경
리뷰 규칙 오너	리뷰 에이전트 체크리스트와 버그 심기 시험	리뷰 규칙 문서, 탐지율 기록
팀장	업무를 자동화·감독·손코딩으로 분류, 확대 결정	업무 분류표, 판정 메모

시작 전 준비물. 자동 테스트가 도는 저장소 하나, 운영과 분리된 실행 환경, 코딩 규칙 문서, 지난 분기에 처리한 기능 목록과 사람이 들인 시간(비교 기준선)을 챙깁니다.

4주 일정(예시). 1주차에 실행 환경과 계획 템플릿을 만들고 업무를 셋으로 분류합니다. 2~3주차에 ‘자동화’로 분류한 기능 2~3개를 공장에 넣습니다. 4주차에 아래 판정 기준으로 확대 여부를 정합니다.

가상 예시. 1주차 준비, 2~3주차 기능 2~3개 시범, 4주차 판정.

시범 전에 팀이 답할 질문.

지금 테스트로 잡히지 않는 오류는 어디서 주로 나오는가?
계획 검토에 누가 몇 시간을 쓸 수 있는가?
에이전트가 절대 건드리면 안 되는 디렉터리와 시스템은 무엇인가?
사람이 손으로 계속 짜야 실력이 유지되는 영역은 어디인가?

진행 판정 기준(예시). 병합된 변경분 가운데 2주 안에 되돌린 비율이 사람이 짠 코드의 평소 수준을 넘지 않을 것, 리뷰 에이전트가 심어 둔 버그를 80% 이상 걸러 낼 것, 기능 오너가 계획 검토와 결과 점검에 쓴 시간이 기준선의 구현 시간보다 적을 것. 셋을 모두 넘으면 동시 실행 수를 늘리고, 하나라도 못 넘으면 원인을 고친 뒤 2주 더 돌립니다.

자동화·감독·손코딩을 나누는 예시 기준. 저자의 기준은 회원 공개 부분에 있으므로, 아래는 AX Review가 시범용으로 정리한 출발점입니다.

AX Review가 정리한 예시 기준입니다. 저자의 기준이 아닙니다.

AX 적용 제언. 사내 개발 조직이나 ERP 주변 개발(보고서, 인터페이스, 화면 추가)처럼 테스트로 확인되는 반복 개발이 많은 곳이 첫 적용처로 맞습니다. 순서는 테스트가 두꺼운 사내 도구 하나에서 시범을 돌리고, Merge Gate 지표가 안정된 뒤 고객 접점 시스템으로 넓히는 편이 안전합니다. 이 글이 바꾸게 하는 관행은 “생산성은 사람 손이 덜 갈수록 좋다”는 셈법입니다. 공장을 들이는 팀은 어느 일을 손에 남겨 엔지니어가 시스템을 계속 이해하게 할지도 함께 정해야 합니다. 신입 엔지니어가 시행착오로 배우던 일을 모두 공장에 넘기면, 몇 년 뒤 계획을 검토할 사람이 줄어듭니다.

원문 사례

항목	내용
저자	Loren Stewart, Every 엔지니어(Every의 Slack 에이전트 담당)
발표처	Every, Source Code 섹션, 2026.10.30 게재(11.05 갱신)
핵심 주장	코드 공장은 더 빠르고 결과가 직접 쓴 것보다 나을 수도 있지만, 사람을 코드에서 떼어 놓음
공장 구조	LLM과 계획 → 본인 검토 → 별도 에이전트 검토 → 작은 단위 분할 → 에이전트 병렬 구현(브라우저·터미널) → 자동 검사 + 리뷰 에이전트 전원 승인 후 병합
에이전트의 일	기능 구현, 버그 찾기, 다른 에이전트 작업 리뷰, 문제 수정
운영 기간	지난 두 달 남짓
분석 틀	마르크스의 소외 이론, AI가 코드에서 떼어 놓는 네 가지 방식, 자동화·감독·손코딩 판단(회원 공개 부분)
밝히지 않은 것(공개 부분 기준)	모델·도구 이름, 처리 건수, 비용

핵심 개념

alienation: 소외. 마르크스가 1844년 『경제학·철학 수고』에서 쓴 개념으로, 일하는 사람이 자기 노동의 결과물과 과정에서 멀어지는 상태를 말합니다. 흔히 결과물, 노동 과정, 인간다운 활동, 다른 사람으로부터의 소외라는 네 갈래로 정리합니다. 저자가 이를 코딩에 어떻게 대응시켰는지는 회원 공개 부분에 있습니다.
Source Code: Every의 섹션 이름. 엔지니어가 AI로 소프트웨어를 만드는 경험을 씁니다.
git worktree: 저장소 하나에서 여러 브랜치를 서로 다른 작업 폴더로 동시에 열어 두는 git 기능. 병렬 에이전트의 작업 공간을 나눌 때 씁니다.
CI: continuous integration. 변경분이 올라올 때마다 빌드와 테스트를 자동으로 돌리는 체계. Merge Gate의 첫 관문입니다.

내 메모

TODO: 내 생각 추가

원문은 Every의 Source Code 섹션에 실린 Loren Stewart의 「What Karl Marx Would Say About My Coding Agents」(2026.10.30 게재)입니다. 이 노트는 로그인 없이 볼 수 있는 앞부분(편집자 소개, 부제, 공장 구조 설명)만 읽고 썼습니다. 소외의 네 가지 방식과 자동화·감독·손코딩 판단 기준은 회원 공개 부분에 있어 다루지 않았습니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 저자가 밝힌 내용을 AX Review가 다시 정리했습니다. 기술 디테일, 현업 실행 디테일, JSON 예시, 설정값, 일정표, 판정 기준, 업무 분류 기준, 인포그래픽은 실제로 돌릴 때 필요한 내용을 새로 작성했으며 가상 예시는 그렇게 밝혔습니다. 소외 개념의 네 갈래 설명은 마르크스 원전에 대한 일반적 정리입니다. 전체 내용은 원문에서 볼 수 있습니다.