Google의 AI 및 인프라 팀이 대부분의 업계가 대수롭지 않게 넘긴 블로그 게시물에서 조용히 주목할 만한 내용을 공개했습니다. 수천 줄의 코드, 수백 개의 레이어, 여러 파일에 걸쳐 깊숙이 얽힌 종속성을 포함하는 규모에서 프로덕션 머신러닝 모델을 TensorFlow에서 JAX로 마이그레이션하여 6배의 속도 향상을 달성한 것입니다. Sundar Pichai가 Google Cloud Next 무대에서 이 내용을 언급했습니다. 그 숫자가 헤드라인을 장식했습니다. 그 밑에 있는 아키텍처가 실제 이야기이며, 지금 일어나고 있는 모든 신뢰할 수 있는 대규모 에이전트 마이그레이션 뒤에는 동일한 아키텍처가 있습니다. 에이전트 집단이 8개든 800개든 말이죠.
여기서 가장 중요한 세부 사항은 다음과 같습니다. 먼저 단일 AI 에이전트를 코드베이스에 투입해 보았습니다. 실패했습니다. 부분적으로 실패한 것이 아닙니다. 컨텍스트를 잃고, 존재하지 않는 API를 환각했으며, 컴파일되지 않는 코드를 생성했습니다. 해결책은 더 똑똑한 모델이 아니었습니다. 완전히 다른 아키텍처였으며, 지금은 "다크 팩토리" 패턴이라는 이름이 붙었습니다. 이는 에이전트가 계획, 구현, 테스트 및 코드를 배포하는 코드베이스로, 말 그대로 인간의 검토가 전혀 개입되지 않습니다. 마치 완전 자동화된 공장이 불을 켤 사람이 아무도 없기 때문에 어둠 속에서 기계를 가동하는 것과 같습니다.
이 글은 해당 패턴에 대한 완전한 분석입니다. 마케팅 버전이 아닙니다. 수백 개의 에이전트가 인간이 각각의 변경 사항을 확인하지 않고 실제 코드베이스를 마이그레이션하는 실제 메커니즘과, 이를 안전하게 만드는 요소가 모델에 대한 신뢰가 아니라 처음부터 그러한 신뢰가 필요하지 않도록 특별히 설계된 아키텍처라는 이유에 대한 것입니다.
단일 에이전트가 대규모에서 실패하는 이유
아키텍처를 살펴보기 전에, 순진한 접근 방식이 왜 실패하는지 정확히 이해해야 합니다. 작동하는 패턴의 모든 설계 결정은 이러한 실패 중 하나를 해결하기 위해 특별히 존재하기 때문입니다.
대규모 코드베이스에 투입된 단일 에이전트는 먼저 컨텍스트 문제에 직면합니다. 아무리 넉넉한 컨텍스트 창이라도, 수백 개의 상호 의존적인 파일, 깊은 호출 체인, 모듈 전반에 걸친 상속된 가정을 가진 코드베이스는 단일 세션이 일관되게 유지할 수 있는 범위를 초과합니다. 에이전트는 처음 몇 개의 파일에서 강력하게 시작하지만, 작업 컨텍스트가 축적된 반쯤 관련된 기록으로 채워지면서 성능이 저하됩니다.
그런 다음 시퀀싱 문제에 부딪힙니다. 코드 마이그레이션은 기본적으로 병렬 작업이 아닙니다. 파일 B는 종종 파일 A가 이미 마이그레이션되었는지에 따라 달라집니다. 함수 서명이 변경되었거나, 임포트가 이동되었거나, 데이터 구조가 변경되었기 때문입니다. 명시적인 종속성 맵이 없는 에이전트는 순서를 추측하거나(깨진 중간 상태를 생성함), 파일이 나열된 순서대로 처리합니다(이는 추측과 기능적으로 동일합니다).
그런 다음 검증 문제에 부딪히며, 이것이 실제로 가장 중요한 문제입니다. 코드를 마이그레이션한 다음 자신의 마이그레이션을 평가하는 에이전트는 처음에 실수를 초래한 바로 그 사각지대를 가지고 자신의 숙제를 확인하는 것입니다. 에이전트가 특정 API가 새 버전에서 다르게 동작한다는 것을 이해하지 못한다면, 자신의 출력을 검토할 때 그 오해를 잡아내지 못할 것입니다. 왜냐하면 동일한 이해의 공백이 두 패스 모두에 존재하기 때문입니다.
Google 팀은 이를 직접 발견했습니다. 단일 에이전트 설정은 마이그레이션의 구조적 규칙과 라인별 실행 세부 사항을 동시에 균형 있게 유지할 수 없었습니다. 이 두 가지 관심사를 별도의 역할로 분할하는 것이 실제 해결책이며, 이는 OpenAI의 게시된 마이그레이션 쿡북, 다중 에이전트 마이그레이션 루프에 대한 학술 연구, 그리고 실제로 이 규모로 실행되는 모든 프로덕션 시스템에서 독립적으로 나타나는 동일한 해결책입니다.
아키텍처: 하나의 제너럴리스트가 아닌 세 가지 역할
작동하는 패턴은 작업을 진정으로 다른 작업을 가진 역할로 분할합니다. 단지 동일한 제너럴리스트 에이전트를 가리키는 다른 프롬프트가 아닙니다.
LLM 추측이 아닌 결정론적 도구를 사용하여 작업을 순서화하는 플래너. 이것이 실제로 확장되는 시스템과 데모에서는 인상적이지만 프로덕션에서는 무너지는 시스템을 구분하는 세부 사항입니다. Google의 플래너는 LLM에게 추론을 통해 마이그레이션 순서를 알아내도록 요청하지 않습니다. 수십 년 동안 엔터프라이즈 소프트웨어를 뒷받침해 온 동일한 범주의 결정론적 도구인 컴파일러 기반 정적 분석을 사용하여 실제 종속성 트리를 구축하고, 아무것도 의존하지 않는 파일(리프 노드)에서 시작하여 다른 모든 것이 의존하는 파일 쪽으로 올라가는 실행 계획을 정의합니다.
이것이 중요한 이유는 종속성 순서 지정이 창의적인 문제가 아니기 때문입니다. 이는 정답이 있는 기계적인 문제이며, 이미 결정론적 솔루션이 있는 문제를 해결하기 위해 LLM을 사용하면 존재할 필요가 없는 새로운 오류 소스가 도입될 뿐입니다. 이면의 규칙: 문제에 알고리즘적 답이 있는 곳이라면 어디든 알고리즘을 사용하십시오. 진정한 판단이 필요한 작업 부분, 즉 실제 코드 변환을 위해 언어 모델을 남겨두십시오. 어떤 파일이 먼저인지 순서를 정하는 것이 아닙니다.
실제 코드 변환을 수행하는 마이그레이션 에이전트(또는 더 큰 시스템에서는 동일한 역할의 격리되고 범위가 좁은 인스턴스가 수백 개 병렬로 실행됨). 각 인스턴스는 하나의 범위가 지정된 작업, 가급적이면 하나의 파일 또는 하나의 단단히 경계가 지정된 모듈, 단일 체크아웃, 그리고 정확히 무엇을 변경해야 하는지와 그 이유를 설명하는 명시적인 마이그레이션 브리프를 받습니다. 관련 코드를 검사하고, 편집하고, 패치를 생성합니다. 자신의 패치가 올바른지 여부를 결정하지 않습니다. 그것은 그들의 작업이 아니며, 아키텍처는 실수로 그 작업을 맡지 않도록 특별히 설계되었습니다.
아무것도 수락되기 전에 격리된 환경에서 마이그레이션된 코드를 빌드, 실행 및 테스트하는 환경 및 검증 계층. 여기서 "완료는 완료"가 의견이 아닌 기계적 사실이 됩니다. Google의 이에 대한 프레이밍은 정확합니다. 업계는 역사적으로 AI의 작업이 실제로 완료되었는지 결정하는 두 가지 나쁜 옵션을 제공했습니다. 수백 개의 파일로 확장되지 않는 인간 검토 또는 실제로 확인된 내용에 대한 기록이 없기 때문에 감사할 수 없는 AI 자체 평가입니다. 그들의 답변은 수학적 검증, 즉 컴파일 성공, 테스트 통과, 정의된 사양과 일치하는 동작을 확인하는 결정론적 코드로, 두 가지 나쁜 옵션을 실제로 검사 가능한 세 번째 옵션으로 대체합니다.
이 목록에서 누락된 것이 무엇인지 주목하십시오: 병합 전에 모든 개별 diff를 읽는 인간. 이것이 다크 팩토리 패턴의 핵심이며, 또한 대부분의 사람들이 안전에 대한 직관이 잘못되는 지점이기도 합니다. 시스템이 에이전트를 더 신뢰하는 것처럼 들리기 때문입니다. 그 반대입니다. 구조적으로 에이전트를 덜 신뢰하는 것입니다. "에이전트가 이것이 작동한다고 말했는가"라는 단일 판단 지점을 에이전트가 영향을 미치거나 우회할 수 없는 검증 계층으로 대체함으로써 말입니다.
격리 계층: 각 에이전트가 자체 샌드박스를 갖는 이유
동일한 코드베이스에 대해 수백 개의 에이전트를 동시에 실행하면 명백한 위험이 발생합니다. 에이전트 47이 에이전트 12의 변경 사항이 의존하는 파일을 편집하는 중이고 에이전트 12의 편집이 방금 컴파일을 망가뜨렸다면 어떻게 될까요?
OpenAI의 게시된 마이그레이션 아키텍처와 Google의 프로덕션 시스템에서 일관된 답변은 기본적으로 격리하는 것입니다. 각 마이그레이션 작업은 자체 샌드박스 환경, 종종 자체 git worktree, 즉 해당 작업 하나에 범위가 지정된 관련 리포지토리의 완전하고 독립적인 체크아웃에서 실행됩니다. 해당 샌드박스의 에이전트가 무언가를 망가뜨리면 공유 코드베이스가 아닌 격리된 복사본이 손상되며, 다른 에이전트의 진행 중인 작업은 절대 손상되지 않습니다.
이 격리는 충돌을 방지하는 것 이상의 기능을 수행합니다. 수백 개의 동시 에이전트가 밟을 수 있는 공유 변경 가능 상태가 없기 때문에 전체 시스템을 사소하게 병렬화할 수 있습니다. 에이전트 1부터 에이전트 800까지는 각각 특정 작업에 관련된 파일과 컨텍스트만 포함하는 깨끗한 환경에서 진정으로 동시에 실행될 수 있으며, 한 에이전트의 환각이 다른 에이전트의 올바른 작업을 오염시킬 위험이 전혀 없습니다.
어떤 작업이 어떤 샌드박스로 이동하고 결과 패치에 어떤 일이 발생하는지 결정하는 오케스트레이션 계층인 하네스는 모든 개별 샌드박스 외부에 유지됩니다. 이는 구체적이고 중요한 아키텍처 선택입니다. 비밀, 외부 도구 및 실제 리포지토리에 액세스할 수 있는 신뢰할 수 있는 프로세스는 AI 생성 코드가 실제로 실행되는 신뢰할 수 없는 실행 환경과 별도로 존재합니다. 샌드박스는 하나의 작업에 필요한 정확한 것만 얻고 그 이상은 얻지 못합니다. 호스트 프로세스는 자체 상승된 권한으로 생성된 코드를 직접 실행하지 않습니다. 이 분리는 에이전트의 코드가 전혀 실행되도록 하는 것을 안전하게 만듭니다. 샌드박스 내부의 실수나 적대적 프롬프트 주입조차도 외부의 어떤 것에도 접근할 수 있는 경로가 없기 때문입니다.
루프 자체: 계획, 실행, 검증, 개선
규모와 특정 도구를 제거하면, 이 모든 것의 밑에서 실행되는 실제 루프는 작업이 통과하거나 재시도 예산을 소진할 때까지 작업당 반복되는 네 가지 단계로 구성됩니다.
1단계: 마이그레이션 계획. 마이그레이션 에이전트는 범위가 지정된 작업(하나의 파일 또는 모듈, 특정 대상 사양(언어 버전, 프레임워크 변경, API 호환성 요구 사항))을 받고 후보 변환을 생성합니다. 이것이 창의적이고 판단 기반의 언어 모델 추론이 주요 작업을 수행하는 유일한 단계입니다. 특정 패턴을 새 프레임워크의 동등한 패턴으로 올바르게 변환하는 방법을 결정하려면 기계적 조회뿐만 아니라 진정한 이해가 필요하기 때문입니다.
2단계: 자동화된 환경 설정. 이 패턴에 대한 학술 문헌에서 때때로 환경 에이전트라고 불리는 별도의 구성 요소가 마이그레이션된 코드에 대한 빌드 및 런타임 환경을 자율적으로 구성하여 종속성 해결 및 구성을 처리하므로 후보 패치를 추상적으로 평가하는 것이 아니라 실제 조건에서 실제로 컴파일 및 실행할 수 있습니다.
3단계: 테스트 검증. 마이그레이션된 코드는 실제 테스트 스위트 또는 해당 모듈에 대한 테스트 스위트가 없는 경우 생성된 동등한 테스트에 대해 실행됩니다. 이것은 기계적 검증 단계로, 인상이 아닌 객관적인 합격 또는 불합격을 생성합니다. 테스트가 통과하거나 통과하지 못하며, 에이전트가 우회할 수 있는 모호함이 없습니다.
4단계: 피드백 개선. 실패 시 특정 테스트 실패 및 진단 로그가 막연한 "이것이 작동하지 않았습니다. 다시 시도하십시오"가 아닌 대상 수정 입력으로 마이그레이션 에이전트에 다시 라우팅됩니다. 패치를 소유한 에이전트는 일반적인 처음부터 재시도가 아니라 무엇이 깨졌는지에 대한 구체적인 증거를 기반으로 특정 논리 및 종속성 매핑을 개선합니다.
이 4단계 주기는 정의된 상한선과 함께 작업당 반복됩니다. 이 정확한 루프 패턴의 문서화된 작동 버전은 "더 이상 이전 패턴과 일치하는 파일이 없음"과 같은 중지 조건과 함께 하드 최대 반복 횟수(한 게시된 예에서는 200회 반복)를 지정하며, 그 후 시스템은 수렴되지 않는 작업에서 무기한 실행되는 대신 자동으로 중지됩니다.
이 상한선은 대규모에서 엄청나게 중요합니다. 그것이 없으면, 사양 자체가 모호하거나 대상 패턴에 실제로 깔끔한 동등 항목이 없기 때문에 구조적으로 완료할 수 없는 작업이 인간이 실제로 보고 해결할 수 있는 특정하고 제한된 실패로 표면화되는 대신 영원히 리소스를 소모할 것입니다.
인간 검토가 확장되지 않는 이유와 이를 대체하는 것
여기서 "각각을 검토하는 인간이 없는 것"이 실제로 더 안전한 설계인 이유, 즉 절충안이 아니라는 점을 정확히 설명할 가치가 있습니다.
AI 에이전트 코드 리뷰와 인간 코드 리뷰를 비교한 연구는 구체적이고 유용한 것을 발견했습니다. AI 생성 리뷰 코멘트는 코드 라인당 인간 리뷰보다 거의 7배 더 길며, 거의 전적으로 코드 개선 및 결함 탐지에 집중하는 반면, 인간 리뷰는 자연스럽게 공유 이해 구축, 지식 전달, 팀원 간의 사회적 의사소통 등 완전히 다른 것들에 분산됩니다. 인간 리뷰의 왕복은 피드백 유형에 따라 크게 다릅니다. AI 대 AI 리뷰 상호 작용은 무엇이 플래그 지정되었는지에 관계없이 훨씬 더 균일하고 기계적입니다.
이를 올바르게 읽으면 중요한 것을 알 수 있습니다. 인간 리뷰와 AI 검증은 구조적으로 다른 것에 능숙합니다. 에이전트 집단이 생성하는 속도와 볼륨으로 800개의 개별 diff를 검토하도록 인간에게 요청하는 것은 안전 업그레이드가 아니라 고무 도장 승인을 생성하는 병목 현상입니다. 어떤 인간도 그 볼륨에 걸쳐 진정한 정밀 조사를 유지할 수 없기 때문입니다. 다크 팩토리 패턴의 실제 안전성은 검증을 제거하는 데서 오는 것이 아닙니다. 이는 한 종류의 검증(수백 개의 반복적인 diff에 분산된 느리고, 소모적이며, 일관성 없는 인간의 주의)을 확장되는 다른 종류의 검증(diff 1과 diff 800에서 정확히 동일한 엄격함을 주의 피로 없이 생성하는 결정론적 빌드 및 테스트 검증)으로 대체하는 데서 옵니다.
이것이 바로 플래너 단계에서 시퀀싱을 위해 LLM 판단 대신 컴파일러 기반 정적 분석을 사용하는 이유이기도 합니다. 결정론적 검사가 판단 호출을 대체할 수 있는 시스템의 모든 곳에서 그래야 합니다. 결정론적 검사는 이 아키텍처에서 사후에 진정으로 감사할 수 있는 유일한 부분이기 때문입니다. 정적 분석기가 찾은 것을 정확히 재생할 수 있습니다. 언어 모델이 특정 마이그레이션 순서가 옳다고 "느낀" 이유를 완전히 재생할 수는 없습니다.
여전히 인간이 필요한 것과 경계선의 위치
이 패턴은 "인간을 완전히 제거하고 희망하라"는 것이 아닙니다. Google의 프로덕션 시스템, 학계의 Environment-in-the-Loop 연구, OpenAI 자체 쿡북 등 이에 대한 모든 신뢰할 수 있는 게시된 버전은 인간의 판단이 필수적으로 유지되어야 하는 명시적인 경계선을 그립니다.
에이전트 기반 라이브러리 마이그레이션에 대한 정량적 연구에서 일관된 발견: 에이전트는 신뢰할 수 있게 높은 마이그레이션 적용 범위를 달성하여 어떤 API 변경이 필요한지 올바르게 식별하지만, 성공적인 마이그레이션이 구문 패턴 일치뿐만 아니라 의도 이해를 필요로 하는 더 복잡한 경우에서 전체 애플리케이션 동작을 보존하는 데 특히 어려움을 겪습니다. 해당 발견에 직접적으로 이어지는 권장 사항은 전체 배치가 아니라 결정론적 검증이 고위험 또는 저신뢰도로 플래그 지정하는 파일의 하위 집합에 대해 인간이 개입하는 체크포인트를 두는 것입니다.
실제로 이것은 계층화된 시스템을 생성합니다. 정적 종속성 분석이 작고, 잘 격리되어 있으며, 구조적으로 단순하다고 분류하는 파일(실제 마이그레이션의 대부분)은 결정론적 빌드 및 테스트 게이트 외에는 인간의 손길이 전혀 없는 완전 자동화된 루프를 통해 흐릅니다. 복잡하고, 깊이 상호 연결되어 있거나, 비즈니스 크리티컬 로직을 건드리는 것으로 플래그 지정된 파일은 그렇지 않으면 완전히 자동화된 시스템 내에서도 병합 전에 실제 인간 검토를 위해 대기열로 라우팅됩니다.
이 계층화된 접근 방식이 "800명의 에이전트, 각각을 검토하는 인간 0명"의 현실적인 버전입니다. 인간이 아무것도 보지 않는다는 것이 아닙니다. 시스템이 기계적이고 위험이 낮은 작업의 95%를 완전 자동화를 통해 라우팅하는 동시에, 희소 자원(진정한 인간의 판단)을 결정론적 검증이 복제할 수 없는 가치를 실제로 추가하는 소수의 경우에만 집중하도록 특별히 설계되었다는 것입니다.
자체 코드베이스에 구축하기
이 패턴은 확장되는 만큼 깔끔하게 축소됩니다. 대규모 프로덕션 코드베이스에 대해 800개의 병렬 에이전트를 실행하든 단일 리포지토리에 대해 소수의 순차적 마이그레이션 작업을 실행하든 동일한 네 가지 역할이 적용됩니다.
플래너부터 시작하고, LLM으로 만들고 싶은 유혹을 뿌리치십시오. 마이그레이션에 어떤 종류의 종속성 구조(파일 임포트, 공유 인터페이스, 빌드 순서)가 있다면, 해당 언어에 적합한 실제 정적 분석 도구를 사용하여 해당 종속성 그래프를 기계적으로 구축하십시오. 이 단일 결정은 전체 시스템에서 가장 영향력이 큰 결정입니다. 모든 다운스트림 단계는 플래너가 만드는 순서 지정 실수를 그대로 물려받기 때문입니다.
종속성 그래프가 허용하는 한 각 개별 작업의 범위를 좁게 지정하십시오. 하나의 파일, 하나의 모듈, 하나의 명확하게 경계가 지정된 변경 단위로, 정확히 무엇을 변경해야 하는지와 그 이유를 설명하는 명시적인 브리프를 포함하십시오. 효율성만을 위해 여러 관련 없는 변경 사항을 하나의 작업으로 결합하지 마십시오. 좁은 범위는 검증 단계의 합격 또는 불합격 판단을 모호하지 않게 만들기 때문입니다.
모든 작업의 실행을 격리하십시오. 최소한 작업당 새로운 git worktree, 실제 규모로 실행하는 경우 완전한 샌드박스 환경입니다. 이것은 선택적 인프라 오버헤드가 아닙니다. 병렬화를 안전하게 만들고 단일 에이전트의 실수를 포함시키고 전염되지 않도록 하는 요소입니다.
다른 모든 것을 구축하기 전에 결정론적 검증을 구축하십시오. 컴파일 성공, 테스트 스위트 통과율, 구축할 수 있는 경우 동작 동등성 검사. 이것은 "에이전트가 작동한다고 말했는가"를 "실제로 작동했는가"로 대체하는 구성 요소이며, 대부분의 자체 구축 마이그레이션 시도가 완전히 건너뛰는 단일 구성 요소이며, 이것이 바로 이러한 시도가 의미 있는 규모에서 실패하는 이유입니다.
재시도 루프를 느낌이 아닌 숫자로 명시적으로 제한하십시오. 아무것도 실행하기 전에 "이 작업이 막혔습니다"가 어떻게 보이는지 정의하고, 막힌 작업이 리소스를 무기한 소모하거나, 더 나쁘게는 잘못된 성공을 조용히 보고하는 대신 자동으로 인간 대기열로 라우팅되도록 하십시오.
헤드라인 숫자 아래의 실제 교훈
특정 대규모 마이그레이션에서 실행되는 실제 숫자가 800 에이전트든, 80이든, 8,000이든, 헤드라인 수치는 이야기에서 가장 흥미롭지 않은 부분입니다. 흥미로운 점은 그러한 에이전트 중 어느 누구도 자신의 작업이 올바른지 여부를 결정하기 위해 개별적으로 신뢰되지 않으며, 전체 시스템이 그 불신을 기반으로 설계되었다는 점입니다.
다크 팩토리는 아무도 지켜보지 않기 때문에 어둠 속에서 작동하지 않습니다. 감시가 완전히 기계 자체, 즉 컴파일러 검사, 테스트 스위트, 종속성 그래프로 이동되었기 때문에 어둠 속에서 작동합니다. 이러한 것들은 파일 1과 파일 800에서 매번 동일한 엄격한 답변을 피로 없이, 그리고 인간에게 동일한 반복적인 판단 호출을 수천 번 연속으로 요청할 때 발생하는 불일치 없이 생성합니다.
이것이 지금 프로덕션에서 작동하는 모든 버전 뒤에 있는 실제 패턴입니다. 더 큰 모델에 대한 더 용감한 신뢰가 아닙니다. 단일 구성 요소(인간 또는 AI)가 자신의 작업에 대한 유일한 판단자가 되는 것을 더 훈련된 방식으로 거부하는 것입니다.
더 많은 AI 콘텐츠를 보려면 @cyrilxbt를 팔로우하세요
