구글의 AI 경쟁력은 ‘검증된 개선’의 속도에 달려 있습니다

구글은 9월 2일 Gemini 3.8 Flash를 발표하며, 6주 동안 Flash 모델을 세 번 출시했다고 밝혔습니다. 신제품을 내놓는 속도만 보면 상당히 빠릅니다. 그러나 이 숫자로는 구글이 차세대 AI를 만드는 속도까지 빨라졌는지 알 수 없습니다. 출시 간격이 짧아진 것과, 새로운 능력을 발견하는 시간이 짧아진 것은 다릅니다. 공식 발표

구글의 AI 경쟁력을 이해할 때 이 구분이 필요합니다. 어떤 모델이 오늘 코딩을 가장 잘하는지, 자체 반도체인 TPU가 얼마나 경제적인지, 연구팀이 다음 모델을 얼마나 빨리 개선하는지는 연결되어 있지만 같은 질문은 아닙니다. 좋은 칩을 많이 확보했다고 연구 가설이 저절로 좋아지지 않고, 코드를 빨리 작성한다고 학습 결과를 기다리는 시간이 사라지지도 않습니다.

9월 3일 공개된 구글 공식 팟캐스트의 코라이 카바쿨루(Koray Kavukcuoglu) 인터뷰도 이 문제와 맞닿아 있습니다. 공식 안내에 등장하는 주제는 Gemini 4의 사전학습, 여러 모델의 병렬 개발, 코딩 에이전트, 그리고 실제 사용자와 함께 AI를 만드는 일입니다. 서로 떨어진 주제로 보이지만, 연구조직의 관점에서는 아이디어를 구현하고, 실험하고, 결과를 판정하고, 다음 모델에 반영하는 과정의 서로 다른 부분입니다. 에피소드 소개·챕터

제가 주목하는 경쟁 단위는 ‘검증된 개선’입니다. 새로운 코드를 작성했다거나 실험이 끝났다는 뜻이 아닙니다. 성능 향상이 우연이나 평가상의 허점이 아니며, 필요한 비용 안에서 재현되고, 실제 모델이나 제품에 반영될 수 있다는 뜻입니다. 구글의 수직 통합이 힘을 발휘하려면 연구, 하드웨어, 제품을 많이 소유하는 데서 그치지 않고 이 단위를 더 빠르고 싸게 만들어내야 합니다.

빠르게 출시되는 모델과 오래 걸리는 연구는 함께 존재할 수 있습니다

모델 개발에는 서로 다른 시계가 돌아갑니다.

사전학습은 대규모 데이터에서 기초적인 예측 능력과 표현을 배우는 과정입니다. 이후의 후반학습은 지시를 따르고, 추론하고, 도구를 사용하는 행동을 다듬습니다. 여기에 추론할 때 쓰는 계산량, 검색과 실행 도구, 제품의 사용 방식을 바꾸는 개선도 더해집니다. 후반학습의 예시와 구현 범위는 구글의 공개 학습 도구인 Tunix 문서에서도 확인할 수 있습니다.

따라서 새 모델 이름이 나올 때마다 처음부터 대규모 사전학습을 다시 했다고 해석하면 안 됩니다. 반대로 기초 구조가 같다는 이유로 후속 모델의 성능 향상을 사소하게 취급해서도 안 됩니다. 같은 토대 위에서도 학습 목표와 실행 방식이 달라지면 사용자가 맡길 수 있는 일의 범위가 달라질 수 있습니다. 공개 자료만으로는 각 Flash 버전에서 사전학습, 후반학습, 추론 설정이 각각 얼마나 기여했는지 분해할 수 없습니다.

구글은 8월 13일의 3.7 Flash 발표에서 개발자 피드백과 알고리즘 개선을 출시 배경으로 설명했고, 이 개선을 미래 모델에도 적용할 계획이라고 밝혔습니다. 이는 제품에서 얻은 발견을 이후 모델로 옮기려는 방향을 보여줍니다. 계획된 전파가 실제로 얼마나 빠르고 성공적으로 이루어지는지는 별도의 검증 대상입니다. 3.7 Flash 발표

이 구분은 경쟁사와의 비교에도 적용됩니다. 출시가 잦은 회사가 기초 연구에서도 더 빨리 전진하고 있을 수 있지만, 기존 능력을 제품으로 옮기는 속도만 빨라졌을 수도 있습니다. 반대로 출시가 뜸한 회사가 더 큰 도약을 준비하고 있을 수 있지만, 결과가 나오지 않는 상황을 준비 기간이라는 말로 포장하고 있을 수도 있습니다. 발표 횟수는 어느 쪽도 판별해주지 못합니다.

필요한 것은 같은 난도의 과제, 같은 비용과 시간 제약에서 이전에 못 하던 일을 해내는지입니다. 연구의 시계와 제품의 시계가 모두 빨라질 때 강한 경쟁력이 생깁니다. 한쪽의 속도로 다른 쪽의 성과를 대신 설명해서는 안 됩니다.

병렬 개발은 실험의 수를 늘리지만, 배움의 순서까지 없애지는 못합니다

공식 인터뷰의 22분 19초 챕터는 병렬 모델 개발을 다룹니다. 여기서 출발할 수 있는 산업적 해석은 명확합니다. 서로 다른 가설을 동시에 시험할 여력이 있으면, 하나의 가설이 실패한 뒤에야 다음 가설을 시작해야 하는 조직보다 탐색 범위가 넓어집니다. 다만 구글 내부의 실제 실험 수나 모델별 자원 배분은 이 에피소드의 공개 안내만으로 알 수 없습니다.

가령 연구팀이 새로운 데이터 구성, 학습 목표, 모델 구조를 각각 검토한다고 가정해보겠습니다. 연산 자원이 충분하면 독립적인 초기 실험은 동시에 진행할 수 있습니다. 하지만 작은 실험에서 좋아 보인 결과가 큰 모델에서도 유지되는지 확인하는 일은 그 결과를 기다려야 합니다. 큰 모델에서 얻은 발견을 이미 학습 중인 다른 모델에 넣을 수 있는지도 별도 문제입니다. 학습 단계나 데이터 구성이 달라 처음부터 다시 검증해야 할 수 있습니다.

동시 실행은 대기열을 줄여주지만, 앞선 결과가 있어야 다음 판단을 할 수 있는 순서까지 지우지는 못합니다. 연구를 병렬화할수록 무엇을 먼저 시험하고 무엇을 중단할지 결정하는 일이 중요해지는 이유입니다.

실험의 독립성도 중요합니다. 비슷한 데이터, 같은 평가 문제, 같은 가정에 기대는 실험을 많이 돌리면 동일한 오류를 여러 번 확인할 수 있습니다. 자원을 많이 썼다는 사실이 탐색의 다양성을 보장하지 않습니다. 어느 후보가 실패했는지뿐 아니라 왜 실패했는지를 공유해야 다른 팀이 같은 막다른 길에 자원을 쓰지 않습니다.

이 관점에서 연구 인프라의 가치는 장비 수에만 있지 않습니다. 대기 중인 실험을 줄이고, 결과를 재현 가능하게 저장하고, 실패 원인을 구분하고, 유망한 발견을 다음 규모의 실험으로 옮기는 능력까지 포함합니다. 연산 설비를 늘릴수록 이 연결이 약한 조직은 평가와 의사결정 단계에 더 큰 적체를 만들게 됩니다.

코딩이 두 배 빨라져도 연구가 두 배 빨라지지는 않습니다

코딩 에이전트가 연구 생산성을 높일 수 있다는 주장은 설득력이 있습니다. 그러나 어느 부분을 얼마나 줄이는지 없이 ‘개발 속도 두 배’를 ‘다음 모델도 두 배 빨리 나온다’로 옮기면 과장이 됩니다.

실험 코드를 쓰는 시간 외에도 실행 환경을 준비하는 시간, 컴파일과 자원 배정을 기다리는 시간, 학습과 평가를 돌리는 시간, 결과를 해석하는 시간이 필요합니다. 사람의 개입이 줄어도 연산 대기나 검증이 병목으로 남을 수 있습니다.

아래는 구글의 실측치가 아닌 단순한 계산 예시입니다. 모든 단계가 순차적으로 진행되고, 코드 작성 외의 시간과 결과 품질은 그대로이며, 코드 작성 속도만 두 배가 된다고 가정했습니다.

실험 한 회에 걸리는 시간	코드 작성이 작은 부분인 경우	코드 작성이 대부분인 경우
기존 코드 작성	20시간	80시간
기존 학습·대기·평가 등 나머지	80시간	20시간
기존 전체 시간	100시간	100시간
코드 작성 속도 두 배 이후	10 + 80 = 90시간	40 + 20 = 60시간
한 회의 시간 단축률	10.0%	40.0%
같은 기간의 이론적 처리량 증가율	11.1%	66.7%

시간 단축률은 1 - 개선 후 시간 / 기존 시간, 처리량 증가율은 기존 시간 / 개선 후 시간 - 1입니다. 소수점 둘째 자리에서 반올림했습니다. 실제로는 작업이 겹쳐 진행되고 재시도도 발생하므로, 프로젝트 완료를 늦추는 단계가 무엇인지 따로 측정해야 합니다.

이 계산은 코딩 에이전트의 가치를 낮추지 않습니다. 오히려 적용 위치를 명확하게 해줍니다. 작은 실험을 자주 만들고 결과를 빠르게 판정할 수 있는 팀에서는 코드 자동화의 효과가 클 수 있습니다. 이미 코드가 안정화되어 있고 대규모 학습이 대부분의 시간을 차지하는 팀에서는 실행 효율, 평가 비용, 자원 배정 개선이 더 중요할 수 있습니다.

프런티어 모델, 즉 최고 성능권 모델을 내부 연구에 먼저 쓰는 이점도 이 조건 아래에서 봐야 합니다. 더 좋은 모델이 더 어려운 연구 코드를 다루고 사람의 검토 부담까지 낮춘다면 다음 세대 연구에 앞서 투자할 여력이 생깁니다. 그러나 제안만 늘리고 검토 부담을 키운다면 이 되먹임은 약해집니다. 현재 모델의 우위가 다음 모델의 우위로 이어지려면, 연구 과정의 실제 병목을 줄여야 합니다.

이 우위가 연구소에 영구히 독점되는 것도 아닙니다. 경쟁사나 스타트업이 같은 수준의 모델을 외부에서 이용할 수 있다면 모델 성능 자체의 격차는 줄어듭니다. 선행 접근 기간, 비공개 실험 기록, 내부 코드와 평가 환경에 대한 접근, 학습 자원 배정권이 결합되어야 내부 연구 도구가 지속적인 차이를 만들 수 있습니다. 좋은 모델이 다음 모델을 돕는다는 사실만으로 승자독식을 예상하기는 어렵습니다.

AlphaEvolve의 23%와 1%는 함께 읽어야 합니다

구글이 이미 공개한 구체적인 사례가 있습니다. 2025년 5월 발표한 AlphaEvolve는 Gemini가 프로그램 후보를 만들고, 자동 평가기가 실행 결과를 채점하며, 좋은 후보를 다음 탐색에 사용하는 시스템입니다. 구글은 넓게 탐색하는 Flash와 깊은 제안을 하는 Pro를 함께 사용한다고 설명했습니다. 모델과 평가기를 연결해 알고리즘을 개선하는 방식입니다. AlphaEvolve 공식 발표

발표에 따르면 AlphaEvolve는 Gemini에서 쓰는 중요한 행렬 연산의 처리 방식을 개선했습니다. 해당 커널, 즉 특정 계산을 수행하는 코드의 실행 속도는 23% 높아졌고, 그 결과 Gemini의 전체 학습 시간은 1% 줄었습니다. 23%는 부분 연산의 속도 향상이고, 1%는 전체 학습 시간의 감소입니다. 같은 성과를 서로 다른 분모로 잰 숫자입니다.

이를 두고 효과가 겨우 1%라고 볼 필요는 없습니다. 큰 계산에서 반복되는 비용이 줄어드는 것은 가치가 있습니다. 다만 이 결과를 ‘AI가 AI 연구 전체를 23% 가속했다’고 읽을 수는 없습니다. 이 수치들은 구글의 발표 기준이며, 특정 커널 최적화 성과를 조직 전체의 연구 생산성으로 확장한 독립 검증치는 아닙니다.

이 사례가 보여주는 더 중요한 조건은 개선 여부를 판정할 수 있는 평가기입니다. 같은 계산을 정확하게 수행하는지, 실행 시간이 실제로 줄었는지를 비교할 수 있어야 후보를 계속 생성하는 일이 탐색으로 누적됩니다. 속도가 빨라졌지만 일부 입력에서 틀리는 프로그램이라면 채택할 수 없습니다.

여기서 두 종류의 자기개선을 구별해야 합니다. AlphaEvolve가 더 좋은 프로그램을 찾아 학습 시스템을 개선하는 것과, 언어모델이 자신의 가중치를 스스로 갱신하는 것은 다른 과정입니다. 모델이 연구 도구로 쓰였다는 사실은 전자를 뒷받침하지만 후자까지 증명하지 않습니다. 무엇을 문제로 정했는지, 평가기가 놓치는 실패는 없는지, 개선 코드를 실제 시스템에 넣어도 되는지에는 여전히 별도의 판단이 필요합니다.

AI가 다음 AI를 만드는 데 기여하는 현상은 이미 구체적인 사례로 논의할 수 있습니다. 다만 그 기여를 자동으로 모든 연구 영역에 일반화하거나, 인간 없이 연구 목표와 검증까지 해결됐다는 뜻으로 읽어서는 안 됩니다.

TPU의 연구 적합성은 ‘실험을 바꾸는 비용’까지 봐야 합니다

구글의 모델 경쟁력을 TPU의 구조적 한계로 설명하려는 주장은 두 단계로 나누어야 합니다. TPU에서 어떤 작업이 가능한지와, 변화하는 연구 작업을 경쟁력 있는 비용과 시간에 수행할 수 있는지는 다릅니다.

‘TPU는 고정된 계산만 할 수 있으므로 에이전트 강화학습에 부적합하다’는 식의 단정은 공개 구현과 맞지 않습니다. 구글의 Tunix는 TPU 기반 후반학습 도구이며, 다회차 도구 사용과 비동기 실행 결과 수집을 포함한 에이전트 강화학습을 지원한다고 명시합니다. 이는 기능이 구현되어 있다는 근거입니다. 구글의 비공개 Gemini 학습 시스템이 Tunix와 같다는 증거도, 엔비디아 GPU보다 빠르다는 증거도 아닙니다. Tunix README

비용이 생길 수 있는 지점은 더 구체적입니다. JAX 문서는 데이터 모양이나 정적으로 처리하는 인수가 달라지면 재컴파일이 필요할 수 있다고 설명합니다. 동시에 조건 분기와 반복을 위한 제어 흐름 연산도 제공합니다. 따라서 ‘분기가 존재하니 실행할 수 없다’가 아니라, 변하는 입력과 실행 길이를 어떻게 묶고, 어디서 컴파일하며, 어느 장치를 기다리게 하는가의 문제로 읽어야 합니다. 이것은 JAX의 실행·컴파일 특성에 대한 설명이지 TPU의 물리적 불가능성을 뜻하지 않습니다. JAX 제어 흐름 문서

연구 작업별로 봐야 할 관측치도 달라집니다. 아래는 특정 회사의 측정 결과가 아닌, 비교 실험을 설계하기 위한 구분입니다.

작업	비용과 지연이 생길 수 있는 곳	비교할 관측치
큰 모델의 학습	연산, 메모리, 장치 간 통신, 장애 복구	같은 모델·품질에 도달하는 총시간과 총비용
에이전트의 행동 경험 수집	제각각인 생성 길이, 도구 대기, 실행 실패	유효한 경험 수, 장비 유휴시간, 긴 작업의 지연
새로운 알고리즘 실험	코드 이식, 컴파일, 분산 실행 오류	아이디어에서 첫 검증 결과까지 걸린 시간
결과 평가와 제품 반영	재현 실험, 안전성 검사, 사람의 검토	검증된 변경 한 건당 비용과 반영 지연

전용 하드웨어에 잘 맞는 계산을 대량으로 반복하면 효율을 얻을 수 있습니다. 그러나 연구 방식이 바뀔 때마다 실행 코드를 크게 손봐야 한다면 그 비용이 일부를 상쇄할 수 있습니다. 반대로 하드웨어와 모델, 컴파일러를 함께 바꿀 수 있는 조직은 같은 제약을 더 빨리 해결할 가능성도 있습니다. 어느 효과가 큰지는 실측할 문제입니다.

따라서 구글의 수직 통합을 경쟁우위로 보는 가설은 여전히 유효합니다. 다만 칩 가격이나 이론 연산량만으로 그 가설을 확정할 수는 없습니다. 같은 연구 가설을 얼마나 빨리 시험하고, 틀렸을 때 얼마나 싸게 방향을 바꾸는지가 더 가까운 지표입니다. 공개 자료에는 Gemini 4의 전체 연구 주기를 경쟁사와 동일 조건으로 비교할 데이터가 없습니다. 이 공백이 남아 있는 한 TPU를 격차의 원인으로 지목하기는 어렵습니다.

더 오래 생각하는 모델과 더 빨리 연구하는 조직도 다릅니다

3.8 Flash 발표에서 놓치기 쉬운 문장이 있습니다. 구글은 성능 향상의 배경으로 추가 추론과 반복적인 도구 호출을 설명하면서, 높은 추론 강도에서는 토큰을 더 쓸 수 있다고 밝혔습니다. 또한 비용 효율이 우선인 작업에는 추론 강도를 낮추거나 3.7을 계속 사용하는 선택지를 제시했습니다. 3.8 Flash의 실행 방식

이것은 개선을 폄하할 이유가 아닙니다. 한 번의 시도에 더 많은 계산을 써서 오류와 재작업을 줄이는 편이 전체적으로 경제적일 수 있습니다. 다만 성능 상승을 해석할 때, 같은 자원으로 더 잘하게 된 것인지 더 많은 자원을 유용하게 사용하는 능력이 생긴 것인지 구분해야 합니다. 둘 다 가치가 있지만 필요한 인프라와 사업의 비용 구조는 달라집니다.

연구 에이전트에도 같은 문제가 생깁니다. 모델이 더 오래 추론하고 여러 실험을 제안해 최종 결과는 좋아졌더라도, 그 과정에서 쓰는 연산과 평가 자원이 더 빨리 늘어날 수 있습니다. 개별 모델의 성능 곡선만 보면 이 비용은 잘 드러나지 않습니다.

구매자와 연구조직이 비교해야 할 단위는 ‘토큰 하나’나 ‘제안 한 건’보다 채택 가능한 결과 한 건에 가깝습니다. 모델 호출료에 실행과 평가 비용, 실패한 시도, 사람이 검토하고 수정한 시간을 합친 뒤 수용된 결과 수로 나눠야 합니다. 앞서 다룬 성공한 업무당 AI 비용이 연구개발에도 적용되는 이유입니다.

사용자 경험은 권한과 평가를 거쳐야 학습 자산이 됩니다

구글의 제품 접점은 실사용 실패를 발견하는 창구가 될 수 있습니다. 실제로 3.8 Flash 발표는 개발 도구, 기업용 제품, Gemini 앱과 검색, 스프레드시트 등 여러 배포 경로를 제시합니다. 그러나 사용자가 많다는 사실만으로 그 경험이 모두 학습 가능한 데이터가 되는 것은 아닙니다. 배포 경로

구글의 Gemini API 데이터 문서는 결제가 활성화된 프로젝트의 로그에 대해, 기본적으로 프롬프트와 응답을 제품 개선에 사용하지 않는다고 설명합니다. 개발자가 별도로 데이터셋을 공유하는 경우에는 모델 개선과 학습에 활용될 수 있으며, 공유할 권한을 확보해야 한다고 명시합니다. 이 구분을 소비자용 앱이나 모든 구글 서비스에 똑같이 적용해서는 안 됩니다. 제품별로 권한과 처리 조건을 확인해야 합니다. 2026년 9월 4일 갱신된 데이터 문서

권한을 확보해도 다음 문제가 남습니다. 사용자의 ‘좋아요’가 정확성을 보장하지 않고, 코드를 채택했다는 사실이 장기적인 안정성을 보장하지도 않습니다. 좋은 피드백은 사용 기록 자체보다, 어떤 입력과 제약에서 무엇이 실패했고 무엇을 바꾸자 해결됐는지를 재현 가능하게 설명하는 기록에 가깝습니다.

예를 들어 코딩 에이전트가 환불 기능을 고쳤다고 가정해보겠습니다. 화면에서 버튼이 작동하고 기존 테스트가 통과해도, 중복 요청이 들어왔을 때 두 번 환불되거나 권한 없는 사용자의 요청을 받아들인다면 실패입니다. 사용자가 코드를 받아들였다는 신호만 수집하면 이 문제를 놓칩니다. 중복 요청, 권한, 예외 처리까지 포함한 시험 환경을 만들어야 다음 모델의 개선을 판정할 수 있습니다. 이는 특정 제품의 사고가 아닌 설명용 사례입니다.

이 부분은 인터뷰의 아타리와 현실의 모호성, AGI 평가라는 주제와도 연결됩니다. 게임 점수처럼 간단한 성공 기준을 모든 업무에 그대로 옮길 수는 없습니다. 현실에서는 무엇을 성공으로 인정할지, 어떤 위험은 성과와 맞바꾸지 않을지부터 정해야 합니다. 평가를 잘못 설계한 상태에서 자기개선 속도만 높이면, 원하는 성과 대신 잘못된 지표를 더 빠르게 최적화할 수 있습니다.

구글이 자체 제품과 연구 인프라를 함께 갖고 있다는 사실은 이 연결을 만들 수 있는 자산입니다. 다만 실제로 우위가 생기는 지점은 이용자 수 자체가 아니라, 합법적으로 사용할 수 있는 실패 사례를 찾아 재현 과제로 바꾸고, 새 모델이 그 문제를 해결했는지 확인하는 과정입니다. 모델을 업데이트했는지, 주변 도구나 제품 설계를 고쳤는지도 구분해야 합니다.

스타트업에 남는 기회는 모델의 약점을 기다리는 일이 아닙니다

이 구조를 스타트업에 적용하면, ‘프런티어 모델이 아직 못 하는 기능’을 찾아 붙이는 전략만으로는 부족합니다. 후속 모델이 그 기능을 잘하게 되면 차별점이 줄어들기 때문입니다. 더 검토할 만한 위치는 모델이 좋아질수록 더 많은 실험을 처리하면서도, 무엇을 성공으로 인정할지와 실제 결과 데이터를 보유하는 업무입니다.

예를 들어 특정 기업용 시스템의 변경을 검증하는 서비스라면, 코드를 더 예쁘게 작성하는 능력만으로 경쟁하지 않아도 됩니다. 고객별 권한, 기존 시스템의 제약, 재현 가능한 장애 사례, 변경 전후의 비교와 복구 절차를 축적할 수 있습니다. 기반 모델의 성능 향상은 이 서비스가 처리할 수 있는 범위를 넓혀줄 수 있습니다. 이는 실제 기업의 실적 주장이 아닌 사업 구조에 대한 가설입니다.

반론도 있습니다. 범용 모델 회사가 평가 도구와 업무 연결까지 제공하면 이런 기능의 상당 부분을 흡수할 수 있습니다. 고객의 원자료에 접근한다는 사실도 독점권을 보장하지 않습니다. 고객이 데이터를 다른 제품으로 옮길 수 있고, 학습이나 고객 간 재사용을 허용하지 않을 수도 있습니다. 따라서 방어력을 판단하려면 데이터의 양보다 이용 권한, 드문 실패의 재현 가능성, 고객이 인정한 결과와의 연결을 확인해야 합니다.

검토 질문도 바뀝니다. 새 모델로 교체했을 때 성능이 좋아지는지에 더해, 고객이 검수하는 시간이 줄어드는지, 실패를 되돌리는 비용이 낮아지는지, 과거에 없던 입력에서도 개선이 유지되는지를 물어야 합니다. 프런티어 모델을 그대로 호출한 경우보다 어떤 조건에서 얼마나 나아지는지도 같은 예산으로 비교해야 합니다. 모델 공급자가 기본 기능으로 제공하면 사라지는 부분과, 고객의 실제 업무에서만 축적할 수 있는 부분을 분리하는 것입니다.

구글에 대해서도 같은 기준을 적용할 수 있습니다. 내부 모델이 다음 모델의 연구 시간을 줄이고, TPU가 실험당 총비용을 낮추고, 제품의 실패 기록이 검증 가능한 학습 과제로 돌아온다면 수직 통합은 강한 우위가 됩니다. 반대로 출시 횟수는 늘어도 재현 가능한 개선의 비율이 낮거나, 더 많은 추론과 사람의 검토로 성능을 유지한다면 그 우위는 생각보다 작을 수 있습니다.

다음 Gemini를 평가할 때는 가장 높은 점수 옆에, 그 결과를 만드는 데 쓴 시간과 비용을 함께 놓아야 합니다. 구글의 잠재력은 이 과정을 내부에서 연결할 수 있다는 데 있습니다. 그 잠재력이 경쟁우위가 되었다고 판단할 근거는 자산 목록이 아니라, 검증된 개선이 누적되는 속도입니다.

---

자료 범위와 출처

인터뷰는 구글이 배포한 공식 에피소드 소개와 챕터 정보를 확인했습니다. 전체 자막을 확보하지 못했으므로 게스트의 세부 발언을 직접 인용하거나 재구성하지 않았습니다. 9월 3일은 팟캐스트 에피소드의 공개일이며 영상의 최초 업로드일과 동일하다고 가정하지 않았습니다. 병렬 개발의 효과, 연구 시간 계산, TPU 비교 항목, 스타트업의 사업 구조는 별도의 분석입니다. Gemini 4의 학습 규모·구조·출시 일정과 경쟁사 대비 연구 생산성은 확인되지 않았습니다.

[1] Google AI: Release Notes, 코라이 카바쿨루 에피소드, 2026-09-03. 인터뷰 영상. 챕터: 사전학습 03:07, AGI 평가 08:53, 아타리와 현실 15:08, 병렬 개발 22:19, 코딩 에이전트 23:34. 시각은 해당 주제의 챕터 시작점이며 특정 문장의 인용 위치가 아닙니다.

[2] Google, Introducing Gemini 3.7 Flash, 2026-08-13. 개발자 피드백과 알고리즘 개선, 미래 모델 적용 계획.

[3] Google, Introducing Gemini 3.8 Flash and 3.8 Flash Cyber, 2026-09-02. 출시 간격, 추가 추론·도구 호출, 토큰 소비 및 배포 경로. 성능 설명은 공급자 발표 기준입니다.

[4] Google DeepMind, AlphaEvolve, 2025-05-14. 제안·평가 구조와 커널 속도 23% 향상, 전체 학습 시간 1% 감소. 회사 공개 성과이며 연구조직 전체의 독립적인 생산성 측정은 아닙니다.

[5] Google Tunix 공개 저장소, 2026-09-08 확인. TPU 후반학습, 다회차 도구 사용, 비동기 경험 수집 기능. 공개 도구의 지원 기능과 비공개 Gemini 내부 구현은 구별합니다.

[6] JAX, Control flow and logical operators with jit, 2026-09-08 확인. 컴파일과 제어 흐름의 조건 및 대응 수단.

[7] Google AI for Developers, Data logging and sharing, 문서 갱신일 2026-09-04. 결제 활성 프로젝트의 기본 데이터 처리와 선택적 공유, 데이터 이용 권한.

2026년 9월 8일 개정: 공식 소개만으로 확인할 수 있는 인터뷰 주제와 별도 기술 분석을 분리하고, 병렬 개발·연구 생산성·TPU·평가와 데이터 권한에 관한 근거와 반론을 보강했습니다. 종목 매매 판단은 다루지 않습니다.