AI 소프트웨어 팩토리는 에이전트보다 게이트를 먼저 세워야 한다.
AI 소프트웨어 팩토리는 코딩 에이전트 자체가 아니라 그 에이전트를 둘러싼 시스템을 가리킨다. 작업이 큐에서 들어오고, 에이전트는 서로 부딪히지 않는 격리된 작업 공간에서 돌며, 검증은 사람이 개입하기 전에 자동으로 끝난다. 사람은 마지막에 책임이 실리는 지점, 즉 머지 게이트에만 등장한다. 노트북에서 에이전트 하나를 돌리는 것과의 차이는 명확하다. 노트북에서는 작업 선택, 실행 관찰, diff 확인, 머지를 모두 사람이 하므로 결국 사람의 주의력이 상한선이 된다. 팩토리는 이 단계들을 인프라로 옮긴다.
공개된 아키텍처들을 모아 보면 다섯 단계가 반복해서 나타난다. 인테이크는 어떤 작업을 시작할 가치가 있는지 정하고, 격리는 에이전트가 충돌 없이 실행될 공간을 마련한다. 도구 단계는 에이전트가 접근할 수 있는 내부 시스템의 범위를 정하며, 검증은 변경이 옳은지 판정한다. 마지막 머지 게이트는 누가 책임질지를 결정한다. 순서 자체가 설계의 핵심이다. 각 게이트가 다음 단계로 넘어가는 작업을 걸러내고, 비용이 큰 단계는 뒤쪽에 배치된다.
각 단계에는 이미 구체적인 구현 사례가 있다. Sentry의 Seer는 들어오는 이슈마다 실행 가능성을 점수로 매겨 기준을 넘는 것만 조사 대상으로 올린다. Stripe는 약 10초 만에 예열되는 개발용 인스턴스를 띄우고, Toolshed를 통해 약 500개의 내부 도구를 MCP로 노출한다. Spotify는 LLM 판정자를 세워 에이전트 세션의 약 25%를 거부하며, Faire는 에이전트가 작성한 PR에 사람 리뷰 두 건을 요구한다. Stripe가 주당 1,300건의 에이전트 PR을 머지한다는 점을 감안하면, 이런 필터가 없을 때 낭비되는 토큰과 리뷰 시간이 얼마나 커지는지 짐작할 수 있다.
이 구조가 화제가 된 계기는 생성과 검토의 비대칭이다. 2026년 1월 6일, dotnet/runtime에서 일하는 Stephen Toub는 35,000피트 상공에서 휴대폰으로 PR 아홉 건을 열었고 그중 일곱 건이 머지됐다. 판단력 있는 사람 한 명이 비행기 좌석에서 팀의 리뷰 처리량을 포화시킬 수 있다는 뜻이다. 생성은 지출에 비례해 늘어나지만 리뷰는 그렇게 늘지 않는다. 그래서 이미 성과를 낸 조직들은 에이전트 함대보다 게이트를 먼저 지었다. Spotify의 Fleetshift는 2023년에 배포됐는데, 그 안에 넣을 에이전트가 생긴 것은 2년 뒤였다.
진짜 팩토리와 스크립트 모음은 세 가지 속성으로 갈린다. 첫째, 프롬프트 기반이 아니라 큐 기반이다. 이슈나 알림, 채널 메시지로 작업이 들어오고 시스템이 시작 여부를 판단한다. 둘째, 환경이 일회용이다. 에이전트마다 파괴해도 되는 깨끗한 작업 공간을 주므로 잘못된 실행의 비용이 0에 가깝고 병렬 실행이 서로를 오염시키지 않는다. 셋째, 검증이 리뷰보다 먼저 온다. diff가 사람에게 도달할 시점에는 이미 컴파일과 테스트, 범위 검사를 통과한 상태다. 세 번째를 빠뜨리면 팩토리가 아니라 리뷰 작업을 더 빠르게 찍어내는 기계가 된다.
인테이크 단계에서 크기 필터는 선택이 아니라 필수에 가깝다. Microsoft가 dotnet/runtime에서 10개월간 수집한 데이터를 보면 변경 줄 수가 1~50줄인 에이전트 PR의 성공률은 76~80%였지만 성능 관련 작업은 54.5%에 그쳤다. 명세가 잘 된 변경 구현과 이슈 조사에는 강하지만 아키텍처를 설계하는 일에는 약하다는 평가가 수치로 확인된 셈이다. Shopify는 인테이크를 공개 채널로만 통과시키는 규칙을 택했다. 에이전트가 DM에 응답하지 않고 공개 채널 개설을 권유하는 방식인데, 비공개 세션은 한 사람만 배우고 창을 닫으면 사라지기 때문이다.
중복 작업을 걸러내는 게이트는 대부분 조용히 실패한다. 이미 상류에서 해결된 문제에 에이전트를 투입하는 낭비를 막으려면 이슈 스레드와 머지된 PR, README, 문서를 인덱싱한 검색이 필요하다. 문제는 판정 로직이다. 특정 저장소로 범위를 좁힌 검색은 응답에 indexed 필드를 함께 돌려주는데, 인덱스가 없는 저장소도 HTTP 200과 success: true를 반환한다. 결과가 비었을 때 무조건 에이전트를 띄우는 코드는 '아무도 보고한 적 없음'과 '해당 저장소를 아예 모름'을 구분하지 못하고 둘 다 통과시킨다. indexed가 false면 알 수 없음으로 처리해 사람에게 넘기거나 범위를 넓혀 재시도하는 한 줄짜리 수정이 검색창을 게이트로 바꾼다.
격리 모델은 비용과 성능 순으로 세 단계가 있다. git worktree는 파일과 브랜치만 분리하므로 한 머신에서 2~5개 에이전트까지가 한계다. 컨테이너는 의존성과 네트워크, 프로세스까지 격리해 충돌하는 의존성이나 신뢰할 수 없는 변경을 다룰 수 있다. 클라우드 샌드박스는 동시성까지 확보해 함대 규모 병렬 실행을 가능하게 한다. Anthropic의 관리형 에이전트 아키텍처는 이 구조를 두뇌(상태 없는 모델과 하네스), 손(일회용 샌드박스), 세션(추가 전용 이벤트 로그)으로 나눈다. 하나만 만든다면 세션 로그를 만들라는 조언이 붙는데, 나머지 모든 요소를 일회용으로 만들 수 있게 해주는 것이 바로 이 로그이기 때문이다.
실무에서 확인할 것은 세 가지다. 에이전트가 시작할 작업을 누가 정하는지, 실패한 실행이 다른 실행에 영향을 주지 않는지, 사람이 보는 시점에 이미 검증이 끝나 있는지. 이 중 하나라도 비어 있으면 도입 효과는 리뷰 부채로 되돌아온다. 반대로 게이트가 제대로 서 있으면 에이전트 교체나 모델 업그레이드는 파이프라인을 다시 설계하지 않고도 흡수할 수 있다.
다만 이 구조는 전제가 있다. 검증 자동화가 성숙하지 않은 코드베이스에서는 게이트가 형식만 남고, 판정 기준이 느슨하면 통과율만 높아진다. 또한 사람이 최종 머지 게이트에 서는 한 리뷰 처리량은 여전히 조직의 상한선이다. 팩토리는 그 상한선을 없애주지 않는다. 상한선에 도달하기 전에 쓸모없는 작업을 걸러내는 장치일 뿐이다.
관련 글
- DATAMIMIC CE 공개로 코딩 에이전트 테스트 데이터 지어냄 막는다MIT 라이선스로 공개된 DATAMIMIC 커뮤니티 에디션은 모델 기반으로 결정론적 합성 테스트 데이터를 생성하고 PII를 가명처리하는 파이썬 네이티브 엔진이다. 코딩 에이전트가 임의로 테스트 데이터를 지어내지 않도록 CLI와 MCP 계약으로 저작·검증·실행 절차를 고정한다.
- AI는 코드를 대신 써주지만 유지보수성은 대신 길러주지 않는다소프트웨어 엔지니어 Alexandru Nedelcu가 AI에 의존한 코딩이 유지보수성을 갉아먹는다고 주장했다. 유지보수성은 즉시 측정할 지표가 없어 AI가 학습할 수 없고, 코드를 읽고 쓰는 일을 AI에 넘긴 개발자는 숙련에 도달하지 못한다는 경고다.
- Elastic, AI 에이전트가 Elasticsearch를 스스로 최적화하게 만든 하네스 공개Elastic이 AI 코딩 에이전트가 Elasticsearch 코드베이스의 성능 병목을 스스로 찾아 최적화하도록 돕는 자동화 하네스와 CLI 도구 atune을 공개했다. 마이크로벤치마크와 검증 루프로 측정 신뢰도를 확보한 것이 핵심이다.
- AI 코딩 에이전트와 팀을 한 스펙으로 묶는 OpenSpec, 스타 6만 8천 돌파OpenSpec은 요구사항을 스펙으로 먼저 정의하고 팀과 AI 코딩 에이전트가 같은 문서를 보며 작업하도록 돕는 경량 프레임워크다. GitHub 스타 6만 8천 개를 넘겼고 2초마다 새 스펙이 만들어질 만큼 빠르게 퍼지고 있으며, npm 한 줄로 설치해 40여 종 에이전트에서 쓸 수 있다.
- AI가 쏟아내는 코드의 '슬롭', 숫자로 잴 수 있을까Earendil의 Sebastian이 LLM이 생성한 코드의 품질 저하를 정량화하는 지표를 정리했다. SlopCodeBench의 verbosity·erosion 지표는 에이전트 코드가 사람 코드보다 약 2배 verbose하고 침식됐음을 보여준다.