How to Build an AI Software Factory: Agents That Open, Review, and Merge PRs

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AI 소프트웨어 팩토리의 핵심은 코딩 에이전트 자체보다 작업 선별·격리·도구·검증·병합의 다섯 단계에 게이트를 두어, 코드 생성량을 팀의 검토 역량 안에서 처리하는 데 있다.

📌 핵심 요약

• AI 소프트웨어 팩토리는 큐 기반 작업 배정, 폐기 가능한 실행 환경, 사람의 검토에 앞선 자동 검증, 명시적인 병합 책임으로 코딩 에이전트를 둘러싼 작업을 인프라화한다.
• 원문은 성공한 기업들이 에이전트 군단보다 게이트를 먼저 구축했다고 강조한다. Spotify의 Fleetshift는 에이전트 도입보다 2년 앞선 2023년에 출시됐으며, 코드 생성은 지출에 따라 늘릴 수 있지만 검토 역량은 같은 방식으로 확장되지 않는다고 설명한다.
• 작업 선별 단계에서 Sentry의 Seer는 조치 가능성을 평가하고 Shopify의 River는 공개 Slack 채널에서만 일한다. dotnet/runtime의 10개월 데이터에서 변경량 1~50줄인 에이전트 PR의 성공률은 76~80%, 성능 개선 작업의 성공률은 54.5%였다.
• Firecrawl Developer Index는 이슈·병합된 PR·README·문서를 검색해 상위 저장소의 기존 해결 여부를 확인하는 용도로 제시된다. 검색 결과가 없어도 repos[0].indexed가 false라면 미해결로 단정하지 않고 확인 불가로 처리해야 한다.
• 격리 방식은 Git worktree, 컨테이너, 클라우드 샌드박스로 구분된다. Stripe는 약 10초 만에 개발 환경을 시작하고 약 500개 내부 MCP 도구를 제공하며, Spotify의 LLM 판정기는 에이전트 세션 약 25%를 거부하고 Faire는 에이전트 PR에 사람 2명의 검토를 요구한다.

🧩 주요 포인트

1. 코드 생성과 검토 역량의 확장 속도 차이 → 작업 선별과 자동 검증으로 사람에게 도달하는 변경을 제한하는 설계가 중요하다.
2. 작은 변경의 높은 성공률과 검색 범위의 불확실성 → 작업 규모·명세 명확성·상위 저장소 확인 상태를 작업 시작 판단에 반영해야 한다.
3. Git worktree부터 클라우드 샌드박스까지 다른 격리 범위와 명시적인 병합 책임 → 동시 실행 환경과 최종 검토 게이트를 함께 설계해야 한다.

🧠 상세 정리

1. 코드 생성보다 검토 수용력이 핵심 문제

원문은 2026년 1월 6일 Stephen Toub가 고도 35,000피트의 비행기 안에서 휴대전화로 dotnet/runtime의 PR 9개를 열었고, 그중 7개가 병합됐다는 사례로 출발한다. 이 사례가 보여주는 변화는 판단력 있는 엔지니어 한 사람이 팀이 검토할 수 있는 속도보다 빠르게 PR을 생산할 수 있다는 점이다. 저자는 이에 따라 핵심 질문이 에이전트에게 코드를 쓰게 하는 방법에서 그 산출물을 조직이 어떻게 받아들일 것인가로 이동했다고 설명한다. 코드 생성은 지출에 따라 늘릴 수 있지만 검토는 같은 방식으로 확장되지 않으며, 이 비대칭을 다루는 주변 시스템이 AI 소프트웨어 팩토리라는 것이 글의 중심 주장이다.

2. 에이전트 주변 업무를 인프라로 전환

AI 소프트웨어 팩토리는 에이전트 자체가 아니라 작업 큐, 격리된 실행 공간, 자동 검증, 사람이 책임지는 병합 게이트를 갖춘 주변 시스템으로 정의된다. 노트북에서 에이전트를 실행하면서 사람이 과제를 고르고 작업을 지켜보며 변경 내용을 읽고 병합하는 방식에서는 여전히 사람의 주의력이 처리량의 한계가 된다. 팩토리는 작업 선택을 접수 규칙에 맡기고 실행 환경을 자동 제공하며, 컴파일과 테스트 및 변경 범위 확인을 사람의 검토 전에 수행한다. 원문이 제시하는 세 가지 구별 기준은 프롬프트보다 큐를 중심으로 작동한다는 점, 환경을 폐기할 수 있다는 점, 검토보다 검증이 먼저라는 점이다. 특히 마지막 조건이 빠지면 팀이 감당할 수 있는 양보다 많은 검토 업무를 만들어내는 시스템이 된다고 경고한다.

3. 다섯 단계와 게이트를 먼저 구축하는 순서

원문은 기업마다 명칭과 구현은 달라도 작업 선별, 격리, 도구, 검증, 병합 게이트라는 공통 구조가 반복된다고 정리한다. Mastra는 여섯 개의 명명된 단계로, Spotify는 중첩된 피드백 루프로, Stripe는 블루프린트로 설명하지만, 각 게이트가 다음 단계로 넘어갈 작업을 제한하고 비용이 큰 단계가 뒤에 놓인다는 원리는 같다는 것이다. 이를 뒷받침하는 사례로 Spotify의 Fleetshift가 에이전트를 갖추기 2년 전인 2023년에 먼저 출시됐다는 점을 든다. 검증과 책임의 구체적 장치로는 에이전트 세션 약 25%를 거부하는 Spotify의 LLM 판정기와 에이전트 PR에 사람 2명의 검토를 요구하는 Faire가 제시된다. Vercel CEO Guillermo Rauch는 경쟁 우위가 작성한 코드에서 코드를 생산하는 수단으로 이동할 것이라는 전략적 주장을 덧붙인다.

4. 실행 환경은 폐기하고 세션 기록은 유지

원문은 Anthropic의 관리형 에이전트 아키텍처가 모델과 하네스로 구성된 무상태의 두뇌, 폐기 가능한 샌드박스인 손, 지속적으로 보존되는 추가 전용 이벤트 로그인 세션을 분리한다고 설명한다. Shopify는 Under the River에서 이 구조를 직접 인용하며, 저자는 이 글에서 하나만 구현한다면 세션 로그를 만들라고 강조한다. 작업 기록을 실행 환경과 분리해 보존하는 것이 나머지 구성 요소를 폐기 가능하게 만드는 기반이라는 설명이다. 또한 사람이 지켜보지 않는 동안 에이전트가 실행하고 자체 점검한 뒤 검증기의 중단 판단까지 반복하는 루프를 여러 개 운영하는 것이 팩토리의 역할이라고 본다. 다만 하나의 세션 안에서 여러 에이전트를 병렬 실행하는 문제는 에이전트 군단 전체를 운영하는 문제와 구분한다.

5. 작업 접수에서 조치 가능성과 범위 선별

작업 접수는 무엇을 시작할 가치가 있는지 결정하며, 여기서 잘못 선별하면 이후 모든 단계가 시작하지 말았어야 할 작업에 토큰을 소비하게 된다고 원문은 설명한다. Sentry의 Seer는 들어오는 오류의 조치 가능성을 평가해 기준을 넘는 것만 조사하고, Shopify의 River는 개인 메시지를 거절하고 공개 Slack 채널에서 작업하도록 한다. Shopify의 공개 채널 원칙은 대화를 검색 가능하게 하고 누구나 참여하게 하려는 조직적 선택으로 소개된다. 최소 구현 예시는 agent-ready 라벨이 붙은 열린 이슈를 최대 20개 조회하고 needs-design 라벨이 있는 항목을 제외하는 방식이다. dotnet/runtime의 10개월 데이터에서는 변경량 1~50줄인 에이전트 PR이 76~80% 성공한 반면 성능 작업은 54.5%였으며, 원문은 이를 명세가 분명한 변경 구현에는 강하지만 해법 설계에는 상대적으로 약하다는 평가와 연결한다.

6. 상위 저장소에서 이미 해결됐는지 확인

원문은 작업 접수 단계에서 해당 문제가 상위 저장소에서 이미 해결됐는지도 물어야 하지만, 이런 확인이 거의 이뤄지지 않는다고 지적한다. 한 엔지니어에게는 부가적인 편의일 수 있으나 Stripe처럼 에이전트 PR을 주당 1,300개 병합하는 규모에서는 이미 해결된 문제에 에이전트를 투입하는 일이 제거해야 할 낭비가 된다는 주장이다. Firecrawl Developer Index는 관련 설명을 담은 블로그 대신 이슈 스레드, 병합된 PR, README, 문서를 색인하므로 이런 확인에 적합한 제품으로 제시된다. 예시는 magicstack/asyncpg 저장소로 범위를 제한하고 높은 동시성에서 연결 풀이 소진되는 문제를 이슈와 PR에서 검색한다. 글은 이를 저장소 내부에 없는 최신 웹 맥락을 에이전트에 제공하는 용도와 연결하며, Firecrawl이 하나의 MCP 블록으로 검색 기능을 제공하고 매번 가져오는 내용에 프롬프트 주입 탐지를 적용한다고 소개한다.

7. 검색 결과 없음과 검색 범위 부재의 구별

Firecrawl 검색을 작업 시작 게이트로 사용할 때 원문이 강조하는 차이는 검색 결과가 없다는 사실과 해당 저장소가 색인되지 않았다는 사실이 서로 다르다는 점이다. 저장소 범위를 지정하면 응답의 최상위 repos 블록에 색인 여부와 자료 유형별 지원 상태가 포함되며, 예시의 magicstack/asyncpg는 indexed가 true이고 acme/internal-fork는 false이다. 두 경우 모두 HTTP 200과 success: true를 반환할 수 있으므로 결과가 없으면 에이전트를 시작한다는 조건만으로는 기존 보고가 없는 상황과 검색 범위 자체가 없는 상황을 구별하지 못한다. 저자는 이 경우 확인 불가 상태까지 통과시키는 게이트가 된다고 지적한다. 해결책은 repos[0].indexed를 읽고 false를 확인 불가로 처리해 사람에게 넘기거나 저장소 범위를 해제한 검색으로 재시도하는 것이다.

8. 동시 실행 규모에 맞춘 격리 방식

격리 단계는 여러 에이전트가 같은 작업 디렉터리를 수정해 충돌하는 문제를 다루며, 원문은 자체 구축한 팩토리가 동시 실행 수를 늘릴 때 흔히 여기서 막힌다고 설명한다. 비교표에서 Git worktree는 파일과 브랜치를 분리하지만 포트, 데이터베이스, 설치된 의존성, 네트워크는 격리하지 않으며 한 기계에서 에이전트 2~5개를 실행하는 용도로 제시된다. 컨테이너는 파일뿐 아니라 의존성, 네트워크, 프로세스를 격리하지만 호스트 자원은 분리하지 않고, 의존성이 충돌하거나 신뢰하기 어려운 변경을 실행하는 경우에 적합하다고 정리한다. 클라우드 샌드박스는 군단 규모와 제한 없는 병렬 실행을 위한 방식으로 소개되며 Stripe의 개발 환경, Ramp의 Modal, Spotify의 Kubernetes가 사례로 등장한다. 저자는 worktree부터 시작하라고 권하지만, 제공된 본문은 worktree 정의를 설명하던 중 끊겨 있어 이후의 상세 구현 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 팩토리의 처리량은 코드 생성량만으로 판단하기 어렵다. 작업 선별과 자동 검증이 사람에게 전달되는 검토 부담을 얼마나 줄이는지가 중심 평가 대상이 된다.
• 검색의 성공 응답은 문제 해결 여부를 확인했다는 뜻이 아니다. 색인 범위를 함께 읽어야 정보 부재를 작업 시작의 근거로 오인하지 않는다.
• 폐기 가능한 실행 환경과 지속되는 세션 로그의 분리는 병렬 작업의 격리와 작업 기록의 보존을 함께 가능하게 하는 구조로 제시된다.

✅ 액션 아이템

• 작업 선별에 변경량 1~50줄의 성공률 76~80%와 명세 명확성을 참고해 에이전트에 맡길 범위 검토.
• Firecrawl Developer Index의 repos[0].indexed가 false인 경우를 확인 불가로 구분해 작업 시작 판단에 반영.
• Git worktree·컨테이너·클라우드 샌드박스의 격리 범위를 비교하고 자동 검증 및 병합 게이트의 책임 기준 설정.

❓ 열린 질문

• 코드 생성량이 검토 역량을 초과할 때 작업 선별과 자동 검증 중 어느 단계의 게이트를 먼저 강화할 것인가?
• 변경량 1~50줄의 성공률 76~80%와 성능 개선 작업의 성공률 54.5%를 작업 선별 기준에 어떻게 반영할 것인가?
• Firecrawl Developer Index의 repos[0].indexed가 false일 때 작업 시작에 필요한 확인은 어떻게 확보할 것인가?