Google이 Cloud Next 2026에서 공개한 수치 하나가 AI-First 워크플로우를 설계하는 팀 리드들 사이에서 화제다. 현재 Google 내부 신규 소스 코드의 약 75%가 AI가 생성하고 엔지니어가 검토·승인하는 방식으로 작성된다. 1년 전 50%에서 급격히 올라간 수치다. 그런데 공교롭게도 같은 시점에 이 AI 코드를 생성하는 핵심 모델인 Gemini 3.5 Pro의 출시가 수개월 지연됐다. 코딩 성능이 내부 기준에 미달했기 때문이다.
이 두 사실을 나란히 놓으면 이상한 그림이 완성된다. AI가 코드를 75%나 쓰는 조직이, 정작 그 AI 모델의 코딩 품질을 신뢰하지 못해서 출시를 미루고 있다. 모순처럼 보이지만 사실은 아주 명확한 메시지다. 75%라는 숫자는 AI를 믿는다는 선언이 아니라, 25%를 어디에 쓸지를 설계했다는 선언이다.
모델 성능 문제보다 더 깊은 것
kmjournal 보도에 따르면 Google은 6월 말 Gemini 3.5 Pro의 학습 데이터를 대규모 업데이트했지만 결과는 내부 목표치를 밑돌았다. 단순히 코드 한 블록을 생성하는 능력이 아니라 버그 탐지, 외부 툴 사용, 파일 관리, 멀티스텝 태스크 완수 같은 복합 능력이 문제였다. OpenAI와 Anthropic이 이미 이 영역에서 앞서가는 상황이라 시장 압박도 크다.
그런데 기술 문제만큼 눈에 띄는 건 조직 문제다. Google Cloud, DeepMind, Android, 컨슈머 제품팀이 각자 AI 코딩 도구를 개발하면서 기능이 중복됐고, 의사결정이 느려졌다. AI Studio, Vertex AI, Android Studio가 여전히 독립적으로 운영되는 구조다. 연구 성과를 통합 제품으로 전환하는 속도가 경쟁사보다 느린 근본 원인이 여기 있다. Google은 지금 이 도구들을 단일 시스템으로 통합하는 작업을 진행 중이다.
테크 리드 입장에서 이 상황은 낯설지 않다. AI 도구를 팀에 도입할 때 '모델 선택'에 집중하다가 '도구 난립'이라는 함정에 빠지는 패턴이다. Google 규모에서도 같은 실수가 벌어진다는 사실은, 이것이 조직 규모와 무관한 설계 문제임을 시사한다.
Agent Cost Drift: 조용히 쌓이는 비용
모델 성능과 조직 구조 문제 외에, AI-First 워크플로우를 운영하는 팀이 반드시 직면하는 세 번째 문제가 있다. dev.to에 공개된 실험 사례가 이를 정확히 포착했다.
하루 두 번 실행되는 자동화 에이전트가 있다. 이 에이전트는 매 실행마다 이전 작업 기록 파일을 읽고 중복을 피한다. 이 파일이 처음엔 약 500토큰이었는데, 한 달 뒤 7,360토큰이 됐다. 파일이 커진 이유는 모두 정당하다. 각 항목은 "이 주제를 골랐고, 이것은 왜 제외했다"는 근거를 담는다. 그런데 항목이 쌓일수록 제외 이유 자체가 이전 항목들을 참조하게 되고, 기록의 용량이 선형이 아니라 이차함수적으로 증가하기 시작했다.
이걸 'agent cost drift'라고 부른다. 스파이크도 아니고, 오류도 아니고, 경보도 울리지 않는다. 개별 항목은 모두 합리적이고 필요하다. 하지만 시퀀스 전체가 만들어내는 비용은 조용히, 선형으로, 매 실행마다 누적된다. 가장 무서운 종류의 버그다. 리뷰에서 잡히지 않고, 테스트에서 빨간 불이 켜지지 않으며, 특정 커밋을 지목할 수도 없다.
해결책은 "덜 읽기"가 아니다. 에이전트가 전체 기록을 필요로 하는 이유가 명확하기 때문이다. 실질적인 접근은 아카이브 분리다. 최근 항목은 전문을 유지하되, 오래된 항목은 날짜·주제·태그 한 줄로 압축해 별도 파일에 보관한다. 충돌 방지에 필요한 것은 두 달 전 항목의 '거절 이유 전문'이 아니라, '이 주제는 이미 다뤘다'는 신호 하나면 충분하다.
25%를 어디에 배치할 것인가
Google의 75% 수치로 돌아오자. 이 숫자가 의미하는 건 효율이 아니라 역할 재배치다. AI가 코드를 생성하는 비율이 높아질수록, 남은 인간의 판단력을 어디에 집중할지의 설계가 더 중요해진다.
Google 내부에서도 이 논쟁이 벌어지고 있다. 일부 엔지니어들은 핵심 시스템 코드에는 여전히 직접적인 인간 개입이 필수라고 주장한다. Gemini 3.5 Pro 출시를 Google이 극도로 신중하게 접근하는 이유 중 하나가 이 내부 긴장 때문이라는 분석도 있다. AI 생성 비율을 높이는 동시에 품질 기준을 유지하려면, 어떤 코드에 인간 검증을 필수로 두는지의 기준이 먼저 설계되어야 한다.
팀 리드 입장에서 이걸 실무로 번역하면 세 가지 설계 포인트가 된다.
첫째, 코드 유형별 검증 등급을 정의한다. AI 생성 코드를 단일 기준으로 검토하면 핵심 로직과 반복 보일러플레이트에 같은 리소스를 쏟게 된다. 보안, 인증, 데이터 처리 경로는 인간 검증을 필수로 두고, 나머지는 AI 리뷰 자동화로 처리하는 계층 구조가 필요하다.
둘째, 에이전트 운영 비용을 처음부터 계측한다. Agent cost drift는 사후에 발견하면 이미 늦다. 에이전트가 매 실행마다 읽는 컨텍스트의 토큰 수를 처음부터 기록하고, 한 달 전과 비교하는 루틴을 파이프라인에 심어야 한다. "파일이 존재하고 파싱되는가"가 아니라 "오늘 이 파일을 읽는 데 얼마나 들었는가"가 모니터링 지표여야 한다.
셋째, AI 도구를 통합하지 않으면 생산성 이득이 조직 마찰로 상쇄된다. Google이 겪고 있는 도구 난립 문제는 규모의 문제가 아니다. 팀 단위에서도 Cursor, Copilot, Claude Code를 동시에 도입하고 기준 없이 운영하면 같은 일이 벌어진다. 어떤 도구를 어느 단계에 쓸지, 생성물을 어떻게 검증할지의 합의가 먼저다.
전망: 모델 성능 경쟁의 끝은 설계 경쟁이다
Gemini 3.5 Pro의 지연은 Google만의 문제가 아니다. 코딩 AI 모델이 단순 생성에서 멀티스텝 에이전틱 실행으로 요구사항이 이동하면서, 벤치마크 점수와 실제 개발 환경 성능 사이의 간극이 더 벌어지고 있다. Flash 모델에 대해서도 "예상보다 비싸고 속도 개선이 체감되지 않는다"는 평가가 나오는 건, 사용자들이 이제 스펙이 아니라 운영 비용과 일관성으로 도구를 판단하기 때문이다.
어떤 모델이 코딩 벤치마크 1위를 차지하느냐보다, 팀이 AI 생성 코드를 어떻게 검증하고 에이전트 비용을 어떻게 통제하는 구조를 갖췄느냐가 실질적인 경쟁력이 되는 시대로 이동하고 있다. Google이 75%라는 숫자를 자랑스럽게 공개하면서도 핵심 코드에 인간 검증을 고집하는 건, 그들도 그 사실을 알고 있기 때문이다.
AI가 코드를 75% 짠다는 건 팀의 75%가 자동화됐다는 뜻이 아니다. 나머지 25%에 팀의 판단력이 집중되도록 설계하는 게 테크 리드의 일이다.