Gemini 4 Argon이 20만 줄 파이썬 코드베이스를 밤새 최적화했다

코드 검토 과정에서 나머지 변경안 네 개는 받아들이지 않았다.

• 다중 에이전트 이벤트 캐시는 합성 벤치마크를 17% 빠르게 했지만, 약한 메모리 참조에 의존했다. 가비지 수집 뒤 파이썬이 메모리 주소를 재사용하면 세션 간에 오래된 데이터를 반환할 수 있었다.
• 텔레메트리 검사 코드는 OpenTelemetry 트레이서 구현체의 비공개 속성을 읽었다. 라이브러리의 마이너 버전이 올라갈 때 조용히 작동을 멈출 수 있었다.
• 모델을 호출할 때마다 ADK가 대화 기록을 구성하는 방식을 다시 작성한 변경안은 핵심 코드 경로를 읽기 어렵게 만들었지만, 독립 홀드아웃 벤치마크에서 종단 간 지연 시간에는 변화가 없었다.
• 워크플로 이벤트 재생을 위한 조회 인덱스는 상태 추적의 복잡성을 더했으며, 일반적인 에이전트 실행이 아니라 합성 재생 테스트에서만 도움이 됐다.

이런 역할 분담이 워크플로가 효과를 낸 이유다. 에이전트가 탐색하고 유지보수 담당자가 덜어낸다. 첫 번째와 두 번째 라운드의 장점을 합쳐 파일 22개를 변경하고 테스트 함수 17개를 새로 추가했다. ADK 팀의 검토를 거쳐 변경 사항은 “Argon이 이 변경 사항을 생성했다”는 커밋 메시지와 함께 main 브랜치에 반영됐다.

ADK에서 ‘턴’이란 무엇이며 158턴은 왜 중요한가

커밋 메시지의 수치를 이해하려면 ADK에서 말하는 턴이 무엇인지 알아야 한다.

엔지니어가 프롬프트를 입력하고 최종 답변을 받기까지를 ADK는 호출(invocation)이라고 부른다. 턴(turn)은 에이전트가 도구를 호출하거나, 여러 도구를 병렬로 실행하거나, MCP 서버에 질의하는 등 내부에서 동작할 때마다 발생하는 단계다.

에이전트 프레임워크를 쓰는 이유는 여러 턴에 걸친 도구 호출이다. 한 번의 실행 아래에서 내부 턴이 수십 번 또는 수백 번 발생한다.

두 라운드를 시작하기 전에 Argon에 공개하지 않은 독립 홀드아웃 벤치마크(bench_turn.py)를 작성했다. 이 벤치마크에서는 즉시 응답하는 모델과 도구를 사용해 하나의 세션에서 턴을 차례로 늘린다. 따라서 측정되는 모든 밀리초는 ADK 프레임워크 자체의 오버헤드다. 각 턴에서 병렬 도구 호출 4개를 세 라운드 실행한 뒤 답변을 반환한다. 이전 턴이 0회, 50회, 150회일 때 각각 5턴의 시간을 측정했다. 아래 수치는 각각 6~12회 실행 결과의 중앙값이며, 변경 전후로 매 턴 모델에 전달되는 요청은 바이트 단위까지 동일하다.

병합된 커밋을 이전 릴리스와 비교해 벤치마크 5개를 실행했다(그림 5):