RL, Borg서 패배. DeepMind 진화형 bin-packer 0.7% 달성

0.7% 플릿 회수 효과, 엄밀히 따져도 성립할까?

0.7%라는 수치는 벤치마크 점수가 아니라, 실제 운영 중인 플릿에서 지속적으로 측정한 지표다. DeepMind에 따르면 AlphaEvolve는 Google의 클러스터 관리 시스템인 Borg를 위한 스케줄링 휴리스틱을 발견했고, 이를 통해 전 세계 컴퓨팅 자원 중 그렇지 않았다면 유휴 상태로 남았을 용량을 평균 0.7% 회수했다 . 이는 실제 워크로드를 대상으로 한 지속적인 프로덕션 측정치로, 합성 리더보드 결과와는 증거의 성격이 다르다.

신뢰도를 판단할 때는 시점도 중요하다. 2025년 5월 14일 발표 당시 이 휴리스틱은 이미 1년 넘게 프로덕션에서 운영되고 있었다 . 이는 2024년 초에서 중반쯤 배포가 시작됐음을 시사한다. 함께 공개된 백서인 arXiv 2506.13131은 2025년 6월 16일 게시됐으며, 이 휴리스틱이 먼저 과거 스냅샷을 사용한 데이터센터 시뮬레이터에서 평가되고, 보지 못한 최신 테스트 데이터셋에서 검증된 뒤, 기존 프로덕션 휴리스틱을 앞선 후에야 전체 플릿에 배포됐다고 설명한다. 또한 배포 후 측정 결과가 시뮬레이터 결과와 일치했다고 밝힌다 .

빠져 있는 것은 외부 검토자가 그 효과의 크기를 검증하는 데 필요한 정보 전부다. Google의 수치는 전적으로 자체 보고에 의존한다. arXiv 논문 기준으로, 0.7% 향상에 대한 독립 감사도 없고, 공개된 A/B 테스트 설계도 없으며, 신뢰구간도 제시되지 않았고, 대체된 기준선의 정의나 측정 기간도 공개되지 않았다 . 정확한 프로덕션 시작일 역시 명시돼 있지 않다.

가장 방어 가능한 해석은 이렇다. 운영 엔지니어링 팀이 시뮬레이터 검증 후 배포라는 경로를 거쳐, 실제 플릿에서 지속적으로 관측한 지표를 보고한 사례다. 일회성 합성 벤치마크보다는 더 신뢰할 만하지만, 동료 심사를 거친 통제 실험만큼 엄밀하지는 않다. 따라서 0.7%는 내부적으로 검증된 실제 효율 개선 효과로 보되, 그 정확한 크기를 아직 독립적으로 확인할 수는 없다고 봐야 한다.

진화 알고리즘은 Borg의 휴리스틱을 어떻게 찾아냈나

AlphaEvolve는 신경망을 훈련한 것이 아니라, 후보 프로그램 집단을 대상으로 생성-평가-선택 루프를 돌려 Borg의 스케줄링 휴리스틱을 찾아냈다. Gemini 모델 앙상블이 프로그램 변형을 제안하면, 자동화된 하네스가 각각을 컴파일하고 점수를 매기며, 프로그램 데이터베이스를 기반으로 한 진화 알고리즘이 살아남을 후보를 골라 다음 라운드의 씨앗으로 사용한다 . 이 발견 방식은 AlphaEvolve가 커널과 수학 문제에 적용하는 방식과 같다. Borg는 2025년 5월 14일 공개적으로 설명된 범용 코드 진화 시스템의 대상 중 하나다 .

모델 앙상블은 비용과 품질에 따라 역할을 나눈다. Gemini Flash는 폭넓은 탐색을 위해 비용이 낮은 변형을 많이 만들어 후보 휴리스틱의 넓은 공간을 훑고, Gemini Pro는 수는 적지만 품질이 더 높은 제안을 내 깊이를 보탠다. 두 흐름은 같은 후보 풀로 들어가므로, 집단 안에는 저렴한 탐색과 더 비싸지만 더 숙고된 수정이 함께 섞인다 .

Borg에 특화된 엄밀함은 적합도 평가에서 들어온다. 각 후보는 Google의 데이터센터 시뮬레이터 안에서 컴파일되고, 과거 플릿 워크로드와 용량 스냅샷을 사용해 점수가 매겨진다. 목표는 기존 프로덕션 휴리스틱 대비 개선으로 정의됐다. 엔지니어들은 배포 전에 보지 못한 최신 테스트 데이터셋에서 우승 후보를 추가로 검증했고, 이후 배포 후 측정으로 시뮬레이터 예측을 확인했다 . 프로그램 데이터베이스는 세대를 거치며 최고 점수 변형들을 보존한다. 살아남은 후보들은 다음 LLM 제안 묶음의 프롬프트 재료가 되므로, 선택 압력은 운 좋은 초안 하나에 기대는 대신 여러 주기에 걸쳐 누적된다.

운영 관점에서 가장 중요한 결과물은 모델 가중치가 아니라 사람이 읽을 수 있는 소스 코드다. DeepMind는 이를 의도적인 설계 선택으로 설명한다. 일반 코드로 표현된 휴리스틱은 읽고, 테스트하고, 리뷰하고, 미션 크리티컬 스케줄러에 들어가는 다른 변경과 같은 엔지니어링 프로세스를 거쳐 배포할 수 있기 때문이다 . 바로 이 특성 덕분에 진화로 얻은 함수가 Borg처럼 민감한 시스템에 배포될 수 있었다.

클러스터 배치에서는 왜 읽히는 휴리스틱이 RL보다 나은가

Google이 처음부터 진화된 휴리스틱에 도달한 것은 아닙니다. 같은 Borg 배치 문제에 딥 강화학습 정책도 적용해 봤지만, 성능은 더 낮았고 프로덕션에서 운영하기도 더 어려웠습니다 . 결정적 차이는 평균 점수가 아니라 판독 가능성이었습니다. 해석 가능한 점수 함수는 다른 엔지니어링 변경과 같은 절차로 리뷰하고, 테스트하고, 배포할 수 있었지만, 불투명한 DRL 정책은 그럴 수 없었습니다 .

운영상의 격차는 구체적입니다. 장애가 발생하면 전체 플릿에 걸쳐 워크로드가 멈출 수 있는 스케줄러에는 엣지 케이스 감사, 정확성 검증, 안전한 롤아웃이 필요합니다. 블랙박스 정책은 바로 이런 속성에 맞서게 됩니다. 학습된 네트워크가 처음 보는 워크로드 조합에서 어떻게 행동할지 이해하려면 경험적으로 찔러 봐야 합니다. 읽을 수는 없습니다. 반대로 진화된 함수는 required-CPU/free-CPU와 required-memory/free-memory 비율, 그리고 불균형을 다루는 교차항으로 표현된 평범한 코드입니다. 그래서 SRE는 어떤 머신이 왜 그렇게 순위가 매겨졌는지 읽고 이해할 수 있습니다 .

이 판독 가능성은 RL 정책이 따라가기 어려운 세 가지 배포 수준의 보장으로 이어집니다.

• 리뷰 가능 — 점수 산정 로직은 플릿에 적용되기 전에 클러스터 관리 엔지니어가 한 줄씩 읽어 볼 수 있습니다.
• 깔끔한 A/B 테스트 가능 — Google은 과거 스냅샷을 사용한 데이터센터 시뮬레이터에서 이 휴리스틱을 검증했고, 보지 못한 최신 테스트 세트에서도 확인한 뒤, 프로덕션 기준선을 이긴 뒤에야 롤아웃했습니다. 배포 후 측정값도 시뮬레이터와 일치했습니다 .
• 명확한 되돌리기 가능 — 이 변경은 Borg의 admission check를 우회하는 것이 아니라 배치 우선순위에 영향을 주는 결정적 함수이므로, 롤백하면 잔여 모델 상태 없이 알려진 동작으로 돌아갑니다.

DeepMind는 이 트레이드오프를 분명히 말합니다. "a single piece of code that can be easily understood, deployed, predictably analyzed and debugged," — Borg에 딥 RL 접근 대신 읽기 쉬운 휴리스틱을 선호한 이유에 대한 DeepMind의 설명 (source: Google DeepMind, 2025-05).

이 설계상의 함의는 Borg를 넘어 빌더 전반에 적용됩니다. 핵심 경로에 있는 어떤 시스템에서든 판독 가능성은 모델이 더 나은 평균 지표로 덮어 버릴 수 있는 선호가 아니라, 배포를 가르는 엄격한 제약입니다. 엣지 케이스를 감사할 수 없고, 롤백이 깨끗하다는 것을 증명할 수 없고, 새벽 3시에 온콜 엔지니어에게 결정을 설명할 수 없다면, 더 좋은 벤치마크 숫자만으로는 배포하기에 충분하지 않습니다.

진화된 휴리스틱이 Borg에서 방치되는 리소스를 줄이는 방식

진화된 휴리스틱은 대기 중인 작업에 대해 후보 머신의 순위를 매기는 점수 함수입니다. required-CPU를 free-CPU로 나눈 값, required-memory를 free-memory로 나눈 값이라는 두 가지 사용률 비율을 사용하고, 불균형에 패널티를 주는 교차항과 결합합니다 . 쉽게 말해, Borg가 이미 수백만 번 마주하는 배치 질문에 답합니다. 이 작업을 합법적으로 실행할 수 있는 호스트들 중에서, 배치 후 플릿을 가장 건강한 패킹 상태로 남기는 곳은 어디인가? 2025년 6월 16일 arXiv에 2506.13131로 게시된 백서는 이를 CPU와 메모리라는 두 변수에 대한 벡터 bin-packing 작업으로 설명합니다 .

핵심 메커니즘은 불균형 패널티입니다. 메모리는 거의 바닥나는데 CPU는 대부분 놀게 되는 머신은 미래의 방치 리소스가 됩니다. 한 차원이 포화되면 다른 차원에 여유가 있어도 더 이상 추가 작업을 받을 수 없기 때문입니다. 교차항은 이런 한쪽으로 치우친 배치를 순위에서 밀어내고, CPU와 메모리가 함께 줄어드는 호스트 쪽으로 작업을 유도합니다. 패킹이 좋아지면 하드웨어를 비례해서 더 늘리지 않고도 사용 가능한 용량을 되찾을 수 있으므로, 같은 물리적 규모에서 더 많은 작업을 완료할 수 있습니다 .

중요한 점은 이 함수가 Borg가 작업에 대해 이미 적격이고 실행 가능하다고 판단한 머신들의 순서만 바꾼다는 것입니다. admission-control과 정확성 검사를 통과한 뒤 배치 우선순위에 영향을 주므로, 기존 작업 제약, 용량 보장, 안전 불변식은 그대로 유지됩니다 . 이는 성숙한 스케줄러 내부의 튜닝 레버이지, 스케줄러를 자율적으로 대체하는 것이 아닙니다. 바로 그 점 때문에 이처럼 중요한 시스템에도 배포될 수 있었습니다.

전 fleet 에서 반복 누적되는 절감: 0.7%가 결코 작지 않은 이유

0.7%라는 수치는 일회성 벤치마크가 아니라 지속적인 production 절감이다. Borg의 전 세계 fleet 전반에서 scheduling cycle이 돌 때마다 누적되며, otherwise stranded 상태로 남았을 compute를 회수한다 . 2025년 5월 발표 시점에 이 evolved heuristic은 이미 1년 넘게 production에서 운영되고 있었으므로, deployment는 대략 2024년 초에서 중반 사이였음을 시사한다 . 같은 물리적 footprint 위에서 이득이 반복되기 때문에, 이는 한 번 회수한 lump sum이라기보다 recurring efficiency dividend처럼 작동한다.

1% 미만의 숫자를 실질적인 규모로 바꾸는 것은 scale이다. Google의 2015년 EuroSys Borg 논문은 이 시스템이 전 세계 여러 cluster에서, cluster당 최대 수만 대의 machine 위에 수천 개 application에서 나온 수십만 개 job을 실행한다고 설명한다 . fleet 전체에 적용하면 0.7%는 새 hardware를 구매하거나 전력을 공급하지 않고도 대형 data-center facility 하나에 해당하는 capacity를 되찾는 것과 대략 맞먹는다 .

Google은 이 수치를 CPU 수, accelerator 수, megawatt, 또는 회피한 capex로 환산해 공개하지 않았다. 따라서 그 무게는 dollar나 watt 단위의 명시값이 아니라 scale에서 추론된다 . constraint context는 이 의미를 더 키운다. GPU와 TPU capacity가 Google 자체 model training의 bottleneck일 때, silicon을 추가하지 않고 schedulable capacity를 회수하는 것은 그 압박을 직접 완화한다.

또 다른 evolutionary 성과: Strassen, attention 최적화, TPU rewrite

Borg를 넘어, 같은 generate-evaluate-select loop는 순수 수학, kernel 성능, silicon design에 걸친 결과를 냈다. 이는 AlphaEvolve가 일회성 scheduler tuner가 아니라 범용 code-evolving system이라는 증거다. 가장 많이 인용된 수학적 성과는 4×4 complex-valued matrix 두 개를 곱할 때 scalar multiplication을 49번이 아니라 48번만 사용하는 방법이다. 이는 해당 setting에서 Strassen의 1969년 algorithm 이후 56년 만에 나온 첫 개선이다 .

수학적 성과는 고립된 사례가 아니라 넓게 나타났다. AlphaEvolve는 14개의 matrix-multiplication algorithm에서 state of the art를 개선했고, 50개가 넘는 open problem 전반에서 약 75%는 best-known result와 맞췄으며 약 20%는 이를 개선했다 . 같은 접근은 Google의 자체 production stack에서도 성과를 냈다:

세 수치 모두 DeepMind의 자체 보고에서 나온 것이다 . Verilog 사례는 가장 구체적인 hardware outcome이다. AlphaEvolve는 arithmetic circuit에서 redundant bit를 제거하는 rewrite를 제안했고, 이 변경은 research artifact로 남지 않고 future TPU generation에 통합되도록 accepted 되었다. DeepMind는 또한 이 loop가 kernel-optimization engineering time을 weeks에서 days로 줄였다고 보고한다 .

DeepMind는 발표에서 “AlphaEvolve made an engineering choice... that improved a heavily optimized component of Gemini's training stack”라고 설명하며, 이러한 speedup을 benchmark trophy가 아니라 recurring compute savings로 framing한다 . Borg와 이어지는 핵심도 같다. 모든 output은 engineer가 review하고 deploy하며 own할 수 있는 human-readable code다.

프로그램이 요구하는 것과 독립 포크가 생략하는 것

Google 밖에서 AlphaEvolve를 재현하려면 먼저 큰 제약부터 받아들여야 한다. 이 시스템은 셀프서비스 제품이 아니다. 2025년 12월 10일 기준, Google Cloud는 AlphaEvolve Service API를 비공개 프리뷰 Early Access Program으로만 제공하며, 가입 페이지에서 신청하는 방식이 아니라 Google Cloud 담당자에게 문의해야 접근할 수 있다 . 가격, 정식 출시 일정, 속도 또는 컴퓨트 한도는 공개되지 않았다 .

접근 권한을 제외하더라도, 이 시스템이 무언가를 진화시키려면 먼저 세 가지 구체적인 입력이 필요하다.

• 문제 명세 — 코드가 다룰 수 있을 만큼 정밀하게 정의된 작업.
• 객관적 평가 함수 — 사람이 개입하지 않아도 각 후보를 자동으로 컴파일하고 실행하고 점수화하는 로직.
• 컴파일 가능한 시드 프로그램 — 탐색이 변형을 시작할 수 있는 작동 중인 출발점 .

이 요구사항이 적용 범위를 정한다. AlphaEvolve는 코드로 표현할 수 있고 자동으로 측정 가능한 문제에 맞는다. 스케줄링, 리소스 할당, 커널 및 회로 최적화, 조합 탐색이 여기에 해당한다. 객관적 채점기가 없는 개방형 추론은 이 범위 밖에 있다 .

오픈소스 "OpenEvolve"식 재구현은 이미 핵심 루프에 가까이 다가가 있다. LLM이 diff를 제안하고, 자동 평가기가 이를 평가하며, 진화적 선택 단계가 이어지는 방식이다. 이 레시피 자체는 원리상 재현 가능하다 . 그러나 포크가 복제할 수 없는 것은 평가기다. Google이 Borg에서 거둔 성과는 휴리스틱을 전체 플릿에 배포하기 전에 검증하기 위해 내부 데이터센터 시뮬레이터, 과거 플릿 스냅샷, 스케줄러 직접 통합에 기대고 있었다 .

빌더가 가져가야 할 결론은 이렇다. LLM이 제안하는 루프는 쉬운 20%다. 진화한 코드가 실제 인프라와 만났을 때 살아남을지를 결정하는 80%는 평가기의 충실도, 즉 프로덕션 시스템을 정확히 모델링하는 채점 하네스다. 그것이 있다면 AlphaEvolve의 방법론은 손이 닿는 곳에 있다. 없다면 API 접근 권한만으로 얻을 수 있는 것은 많지 않다.

자주 묻는 질문

AlphaEvolve는 Borg에서 정확히 무엇을 바꿨나요?

AlphaEvolve가 바꾼 것은 기계 순위 산정 함수뿐입니다. 즉 Borg가 이미 대기 중인 작업을 실행할 수 있고 배치해도 된다고 판단한 기계들 사이에서 우선순위를 정하는 휴리스틱입니다. admission control, 작업 제약, 정확성 검사는 건드리지 않았습니다 . 진화된 함수는 required-CPU/free-CPU와 required-memory/free-memory 비율을 사용하며, 교차 항으로 불균형에 페널티를 줘서 작업이 배치됐을 때 다른 자원을 고립시키는 기계를 피하게 합니다. 이미 유효한 배치 후보들의 순서만 다시 정하기 때문에, 이 변경은 Borg의 기존 admission 및 정확성 로직을 우회하는 것이 아니라 배치 우선순위에 영향을 줍니다 .

Google은 왜 이 스케줄링 개선에 딥 RL을 쓰지 않았나요?

Google은 같은 배치 문제에 딥 강화학습도 시도했지만, 진화된 휴리스틱보다 성능이 낮았고 운영하기도 더 어려웠습니다 . 핵심 경로에 있는 클러스터 스케줄러에서는 불투명한 신경망 정책이 감사, 엣지 케이스 검증, 안전한 롤아웃을 현실적으로 어렵게 만듭니다. AlphaEvolve의 출력은 사람이 읽을 수 있는 코드이므로, DeepMind는 해석 가능성, 디버깅 가능성, 예측 가능한 동작을 배포 여부를 가르는 요구사항으로 분명히 제시합니다. 진화된 휴리스틱은 한 줄씩 읽고, 시뮬레이션하고, 추론할 수 있지만 RL 정책의 가중치는 그렇게 다룰 수 없습니다 .

내 스케줄러에도 AlphaEvolve의 방식을 어떻게 재현할 수 있나요?

루프 자체는 재현할 수 있습니다. LLM 기반 후보 생성, 각 후보를 지표에 따라 객관적으로 점수화하는 자동 평가기, 그리고 가장 좋은 프로그램을 다음 라운드의 출발점으로 삼는 진화적 선택 단계입니다 . 이미 여러 오픈소스 “OpenEvolve”식 재구현이 이 구조를 따라 하고 있습니다 . 따라 하기 어려운 부분은 평가기입니다. Google은 전체 플릿 롤아웃 전에 과거 워크로드와 용량 스냅샷으로 만든 고충실도 데이터센터 시뮬레이터에서 이 휴리스틱을 검증했습니다 . 그런 수준의 시뮬레이션 충실도가 없으면, 제안하고 선별하는 루프가 만들어낸 후보를 신뢰할 수 없습니다.

0.7% 컴퓨트 회수는 독립적으로 검증됐나요?

독립 감사는 없습니다. 전 세계 컴퓨트의 약 0.7%를 회수했다는 수치는 Google이 라이브 플릿 측정에서 자체 보고한 것입니다 . arXiv 백서(2506.13131, 2025년 6월 16일 게시)는 롤아웃 전에 보지 않은 최신 테스트 데이터셋으로 시뮬레이터 결과를 검증했고, 배포 후 측정값이 시뮬레이터와 일치했다고 밝힙니다 . 하지만 이 수치는 동료 심사를 거친 것이 아니며, Google은 신뢰구간, 대체된 기존 휴리스틱, 지표의 측정 기간, 외부 재현에 필요한 A/B 설계를 공개하지 않았습니다.

AlphaEvolve는 언제 공개 API로 제공되나요?

아직 공개 셀프서비스 API는 없습니다. 2025년 12월 10일 기준, Google Cloud는 AlphaEvolve Service API를 Early Access Program을 통한 비공개 프리뷰로만 제공하며, Google Cloud 담당자를 통해 접근할 수 있습니다 . 사용하려면 고객이 문제 명세, 후보를 객관적으로 점수화하는 평가 로직, 바로 컴파일 가능한 시드 프로그램을 제공해야 합니다. 일반 공개 일정, 가격, rate limit, 컴퓨트 할당량은 공개되지 않았습니다 .