Google AlphaEvolve, 10월 26일 기본 모델 전환 — Gemini 4 Argon과 새 실험의 확인점
AI 실험의 설정을 그대로 복사했는데, 생성되는 후보의 조건은 달라질 수 있어요. Google Cloud가 예고한 AlphaEvolve 기본 모델 전환일인 오늘, 모델을 생략한 새 실험은 Gemini 4 Argon 배정 구간에 들어가요.
기존 실험의 유지와 전환 당일 혼재 가능성, 모델 명시와 과금 기준을 공식 문서로 확인했어요. 이 글은 계정에서 직접 실험한 성능 평가가 아닌 적용일 해설이에요.
AlphaEvolve의 기본 모델 전환일이 왔어요
Google Cloud의 AlphaEvolve 기본 모델 표에서 2026년 10월 26일 이후 생성하는 실험은 Gemini 4 Argon을 사용하는 구간으로 바뀌어요. 모델을 따로 지정하지 않은 새 실험에 해당하는 변화예요.
최초 예고는 10월 22일 릴리스 노트에 실렸고, 오늘은 그 적용일이에요. Gemini 4 Argon 자체가 오늘 처음 출시됐다는 뜻은 아니에요. 이번 글은 적용일에 달라지는 실험 설정과 확인 범위를 살펴봐요.
전환 당일에는 두 모델이 모두 나올 수 있어요
공식 API 문서는 기본 모델 변경이 하루에 걸쳐 적용되므로 전환일에 만든 실험에는 이전 모델이나 새 모델이 배정될 수 있다고 밝혀요. 따라서 오늘 생성한 실험이 모두 즉시 Argon으로 바뀌었다고 단정할 수 없어요.
문서상 날짜와 개별 계정의 실제 배정 결과를 나눠 보는 것이 중요해요. 이 글은 공식 일정과 설정 규칙을 확인했으며, Google Cloud 계정에서 실험을 만들어 배정 결과를 측정하지는 않았어요.
영향을 받는 것은 모델을 생략한 새 실험이에요
AlphaEvolve는 generationSettings의 models 필드가 비어 있을 때 실험 생성 시점의 기본 모델을 저장해요. 새 실험을 만들면서 모델을 명시하지 않았는지가 영향 범위를 가르는 기준이에요.
같은 요청 템플릿을 계속 써도 기본값이 바뀌면 선택되는 모델이 달라질 수 있어요. 설정 파일의 내용이 같다는 사실만으로 생성 조건까지 같다고 보기는 어려워요.
기존 실험은 원래 모델을 유지해요
Google의 공지와 API 문서는 이미 만들어진 실험이 기존 설정에 기록된 모델을 유지한다고 설명해요. 기본 모델 변경이 과거 실험의 모델을 자동으로 교체하는 방식은 아니에요.
기존 실험을 다시 실행하는 일과 새 실험을 생성하는 일을 구분할 수 있어요. 어느 쪽인지에 따라 기본값 전환의 영향이 달라져요.
실제 배정은 설정이나 생성 응답에 남아요
공식 문서가 제시하는 확인 위치는 실험 구성 또는 생성 응답의 generationSettings.models예요. 기본값의 이름을 추측하는 대신 해당 실험에 저장된 모델을 확인하는 방식이에요.
전환 당일의 혼재 가능성도 이 기록으로 구분할 수 있어요. 6월 30일 이전에 모델 생략으로 만들어진 오래된 실험에는 이 필드 값이 없는 경우가 있다는 별도 주의사항도 있어요.
이전 기본값은 Gemini 3.8 Flash였어요
공식 표는 9월 29일부터 10월 25일까지 생성된 실험의 기본 모델을 gemini-3.8-flash로 제시해요. 10월 26일 이후 구간에는 gemini-4-argon이 기록돼 있어요.
이 구분은 실험의 생성 날짜에 관한 기준이에요. 모든 실행이 매번 최신 기본 모델을 다시 찾아가는 구조라고 이해하면 기존 실험 유지 규칙과 어긋나요.
모델을 명시하면 선택을 고정할 수 있어요
10월 22일 공지는 Gemini 3.8 Flash를 계속 사용하려면 models 필드에 gemini-3.8-flash를 지정할 수 있다고 설명해요. 새 모델을 명시적으로 선택하는 경우도 같은 설정 경로를 사용해요.
이는 기본 모델 전환을 기다리는 방식과 다른 선택이에요. 어떤 이름을 적을 수 있는지는 해당 서비스의 지원 모델 표와 요청 지역을 함께 봐야 해요.
지원 모델 이름과 지역도 검사해요
API 참조는 gemini-4-argon과 gemini-3.8-flash를 global, us, eu에서 제공한다고 안내해요. 모델마다 지원 지역이 같다고 일반화할 수는 없으며, 예를 들어 목록의 gemini-3.1-pro-preview는 global로 표시돼 있어요.
지원하지 않는 모델 이름이나 해당 지역에서 사용할 수 없는 모델을 지정하면 생성 과정에서 INVALID_ARGUMENT가 반환될 수 있어요. 이름을 아는 것과 요청 조합이 유효한 것은 별개예요.
한 실험에는 최대 두 모델을 조합해요
공식 API는 한 실험에 최대 두 모델을 넣을 수 있다고 설명해요. 각 모델의 weight는 생성 호출에서 차지하는 상대적인 비중을 뜻해요.
가중치가 반드시 합쳐서 1이 될 필요는 없다는 안내도 있어요. 이를 한 번의 요청을 두 모델이 동시에 합의해 답한다는 의미로 확대하기보다는, 호출을 나누는 구성으로 이해하는 편이 정확해요.
기본 모델 변경은 과금 기준에도 닿아요
Google의 공지는 전환 후 새 실험이 새 기본 모델을 사용하면 Gemini 4 Argon의 토큰 가격을 적용한다고 밝혀요. 기본값의 변화가 결과뿐 아니라 사용 비용의 조건에도 연결되는 셈이에요.
다만 이번 자료만으로 전체 실험 비용이 몇 배 오른다거나 내려간다고 말할 수는 없어요. 호출량과 모델 배정, 평가 작업의 실행량이 다르므로 이 글에서는 총비용을 추정하지 않아요.
반복 실험에서는 생성 조건이 중요해요
같은 문제의 결과를 비교하려면 어느 모델이 후보 코드를 만들었는지도 실험 조건이 돼요. 기본값을 생략한 새 실험을 날짜를 달리해 만들면 모델 전환이라는 변수가 들어갈 수 있어요.
이 점은 공식 설정 규칙에서 도출되는 해석이에요. 특정 모델의 결과가 더 좋거나 나쁘다는 성능 결론은 아니며, 이번 전환의 독립적인 비교 측정도 수행하지 않았어요.
AlphaEvolve는 어떤 일을 하나요
AlphaEvolve는 진화적 탐색으로 알고리즘 발견과 수학적 탐색, 조합 최적화를 다루는 AI 코딩 에이전트예요. 동작하는 프로그램에서 여러 후보 변형을 만들고 평가를 반복해 목표를 개선하는 흐름이에요.
일반적인 코드 작성 비서와 쓰임새가 달라요. 공식 개요는 단순한 자연어 설명만으로 기본 프로그램을 만드는 일이나 코드 스타일 정리를 주된 용도로 삼지 않아요.
출발점은 동작하는 코드예요
공식 개요는 기능적으로 올바르게 동작하지만 성능 기준을 더 개선할 필요가 있는 코드를 입력으로 설명해요. 먼저 작동하는 기준 구현과 최적화할 대상을 구분하는 구조예요.
탐색 도중 바뀔 수 있는 코드와 고정할 제약도 중요해요. 문제 자체를 코드의 변수와 제약으로 표현하기 어렵다면, 공식 적합성 안내는 다른 전문 모델이나 접근을 검토할 상황으로 구분해요.
모델만으로 평가까지 끝나는 것은 아니에요
Google이 제공하는 주요 구성은 모델 앙상블, 후보 프로그램 데이터베이스, 프롬프트 샘플러와 이를 연결하는 조정 로직이에요. 평가기는 사용자가 자신의 문제와 지표에 맞게 설계하고 구현하도록 설명돼 있어요.
모델이 후보를 만드는 부분과 후보가 실제로 좋은지 재는 부분이 나뉘어 있어요. 기본 모델이 바뀌어도 평가 기준을 누가 정의하는지는 달라지지 않아요.
자동으로 계산할 수 있는 목표가 필요해요
최적화 목표 문서는 후보마다 사람의 개입 없이 점수를 계산할 수 있는 평가 흐름을 요구해요. 직접 계산, 성능 측정, 검증된 시뮬레이션, 별도 검증 데이터 평가 등이 가능한 방법으로 소개돼요.
사람이 매번 눈으로 보고 점수를 붙여야만 하는 문제는 바로 같은 탐색 구조에 넣기 어려워요. 좋은 결과를 어떻게 수치로 구분할지가 모델 선택보다 먼저 정의돼야 하는 조건이에요.
작아질수록 좋은 지표는 방향을 맞춰요
AlphaEvolve는 수치 점수를 크게 만드는 방향으로 탐색해요. 지연시간처럼 낮아질수록 좋은 목표는 부호를 바꿔 제출하는 예가 공식 문서에 나와요.
예를 들어 밀리초 지연시간에 음수를 붙이면 지연이 줄 때 점수는 커져요. 이는 평가 규칙을 설명한 예시이며, 실제 측정값이나 어떤 모델의 속도를 보여주는 숫자는 아니에요.
여러 목표는 평가 설계로 함께 다뤄요
공식 지표 안내는 여러 값을 적절한 범위로 맞춰 하나의 점수로 합치는 방법과, 이름이 붙은 여러 점수를 반환하는 방법을 구분해요. API도 여러 지표를 통해 파레토 관점의 후보 비교를 설명해요.
정확도와 지연시간을 동시에 볼 때 어느 쪽을 얼마나 중시하는지가 설계에 들어가요. 모델 이름만 바꾸면 이런 목표 간의 관계까지 자동으로 해결된다고 볼 수는 없어요.
맥락은 많기보다 필요한 내용이 중요해요
공식 맥락 구성 안내는 문제의 수학적 정의, 제약과 이유, 전문 용어, 이미 알려진 좋은 접근을 담는 방향을 제시해요. 일반 강좌나 무관한 큰 데이터 덩어리를 모두 프롬프트에 넣는 방식과는 거리가 있어요.
문서는 결합된 맥락이 20만 토큰을 넘으면 주의력과 변형 품질이 낮아질 수 있다고 설명해요. 이는 AlphaEvolve의 구성 권고이며, Gemini 4 Argon 모델 자체의 전체 맥락 한도를 뜻하는 수치는 아니에요.
실패 설명도 다음 탐색의 입력이에요
평가기의 숫자 점수와 함께 돌아오는 진단 피드백은 다음 세대의 프롬프트에 붙어요. 공식 문서는 구체적이고 간결한 피드백과 막연한 실패 문구를 구분해요.
어느 조건에서 결과가 어긋났는지가 남으면 다음 변형이 그 정보를 참고할 수 있어요. 다만 피드백을 넣었다는 이유만으로 같은 오류가 반드시 사라진다고 보장되지는 않아요.
반복 횟수와 실행량도 별도 조건이에요
공식 실험 구성에는 최대 프로그램 수, 동시 실행 수, 전체 실행시간, 유휴시간 제한 등이 있어요. 모델 선택은 이 중 생성 부분의 조건이고, 평가 작업이 얼마 동안 얼마나 많이 도는지는 별도로 관리돼요.
따라서 전환 전후를 비교할 때 모델뿐 아니라 탐색 범위와 실행 제한도 같은지 살펴볼 필요가 있어요. 단일 답변 생성과 반복적인 후보 탐색을 같은 비용 단위로 보는 것은 부정확해요.
후보와 결과는 다시 조회할 수 있어요
API 참조는 생성된 변형의 소스 코드, 실행 지표와 기록을 조회하는 흐름을 설명해요. 완료 상태로 거르거나 지표를 기준으로 정렬해 후보를 찾는 방식이 포함돼요.
높은 점수를 받은 후보를 찾는 일과 그 후보의 실제 코드·검증 근거를 보는 일이 연결돼 있어요. 이 글에서는 API를 실행하거나 원격 프로젝트의 결과를 생성하지 않고 문서상 동작만 확인했어요.
기업용 이름이 모든 보안 범위를 뜻하지는 않아요
공식 보안 프로필에는 AlphaEvolve가 Model Armor 통합을 지원하지 않는다는 제한이 있어요. Assured Workloads, FedRAMP, 미 국방부 관련 요구사항에도 별도 제한이 적혀 있어요.
Gemini Enterprise에 속한 기능이라는 사실만으로 다른 기능의 보안·규정 지원을 그대로 적용할 수는 없어요. 모델 기본값 전환과 서비스의 지원 범위는 각각 확인할 항목이에요.
적용 장면은 기존 실험과 새 실험을 나눠 봐요
가령 같은 정렬 알고리즘을 최적화하는 실험을 전환 전부터 운영하다가 오늘 새 실험을 하나 더 만든다고 생각할 수 있어요. 기존 실험은 저장된 모델을 유지하고, 모델을 생략한 새 실험은 전환일 배정 규칙의 영향을 받을 수 있어요.
이것은 공식 규칙을 설명하기 위한 가상 사례예요. 두 모델의 속도나 정렬 성능을 실제로 비교한 결과가 아니에요. 생성 응답의 모델 값과 같은 평가기를 함께 남기면 비교의 범위를 구분할 수 있어요.
오늘의 핵심은 실제로 저장된 모델이에요
이번 변화의 핵심은 새 기본값, 기존 실험 유지, 전환 당일 혼재 가능성, 새 모델에 따른 과금 기준이에요. 최초 예고일과 실제 적용일을 나누고, 개별 실험의 기록을 기준으로 이해하는 것이 정확해요.
AI 실험에서 설정을 생략해도 괜찮은 부분과 명시해 두어야 하는 부분은 어디일까요? 모델, 평가기, 실행 제한을 함께 기록하는 습관이 기본값 변화의 영향을 알아보는 출발점이 될 수 있어요.
출처
- Google 공식 릴리스 노트: 10월22일 예고·10월26일 전환
- AlphaEvolve API·기본모델·전환일 주의사항
- AlphaEvolve 개요와 사용 범위
- 모델·데이터베이스·평가기 구조
- 적합한 문제와 평가 조건
- 맥락과 피드백 구성
- 최적화 지표의 계산과 여러 목표
- 보안 프로필과 지원 제한
협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/