Gemini 4 Argon 장시간 코드베이스 최적화법: 20만 줄 Python 저장소에서 배울 운영 절차

Google이 공개한 Gemini 4 Argon의 ADK Python 최적화 사례는 모델 성능 자랑보다 운영 절차가 더 중요하다. 대상 저장소는 Google의 Agent Development Kit Python 저장소다. 약 205,000줄의 코드, 800개에 가까운 소스 파일, 16,892개 단위 테스트를 가진 실제 오픈소스 코드베이스다. Google은 Argon을 Google Antigravity의 /goal 모드로 11시간 동안 돌려 성능 병목을 찾게 했고, 최종적으로 세션 준비 시간은 긴 세션에서 약 40% 줄었고 패키지 cold import 시간은 21% 빨라졌다고 밝혔다.

개발팀이 여기서 배워야 할 것은 “에이전트에게 오래 맡기면 알아서 고친다”가 아니다. 오히려 반대다. 장시간 코딩 에이전트가 유용하려면 목표, 저장소 규칙, 벤치마크, 테스트, 리뷰 기준, PR 설명 방식이 먼저 준비돼 있어야 한다. Google 사례에서도 첫 번째 2시간 실험은 실제 병목을 찾았지만 팀 컨벤션을 놓쳤고, 두 번째 11시간 실험은 .agents/skills와 명확한 /goal 프롬프트를 준 뒤에야 리뷰 가능한 PR에 가까워졌다.

1단계: 목표를 성능 지표로 쓴다

나쁜 프롬프트는 “성능 최적화해줘”다. 좋은 프롬프트는 무엇을 유지하고 무엇을 줄일지 말한다. Google의 목표는 ADK가 어떤 에이전트에도 눈에 띄는 오버헤드를 추가하지 않게 하라는 것이었다. 동시에 모델이 받는 내용과 public API는 바꾸지 말고, 각 변경에는 회귀를 잡을 테스트를 붙이라고 했다. 두 번째 실험에서는 main에 머지하지 않는 PR을 열고, 전후 숫자를 PR 설명에 넣으라는 조건도 붙었다.

이런 조건이 필요한 이유는 성능 최적화가 쉽게 위험한 변경으로 이어지기 때문이다. 캐시를 추가하면 stale data가 생길 수 있고, import를 지연시키면 테스트가 의존하던 patch 경로가 깨질 수 있다. 모델에게 “빠르게”만 요구하면 public API나 내부 상태 보장을 희생할 가능성이 커진다.

팀에서 적용할 때는 목표를 다음처럼 쓴다. “로그인 API의 p95 지연시간을 20% 줄인다. 외부 응답 스키마와 인증 정책은 바꾸지 않는다. 변경마다 회귀 테스트와 벤치마크 전후 수치를 남긴다.” 이런 수준으로 써야 에이전트가 탐색 중에도 경계를 유지한다.

2단계: 저장소 규칙을 skill로 분리한다

Google 사례에서 차이를 만든 요소 중 하나는 .agents/skills였다. ADK 팀은 maintainer guideline을 저장소 안에 두고, visibility.md와 imports.md 같은 작은 문서로 나눴다. 에이전트는 모든 규칙을 한 번에 읽는 대신 필요한 규칙만 읽었다. 이 구조는 긴 컨텍스트를 아끼면서도 팀 관행을 전달한다.

실무 저장소에도 비슷한 문서가 필요하다. 예를 들어 다음 파일을 둘 수 있다.

• visibility.md: public/private 모듈 규칙
• imports.md: lazy import 허용 기준과 금지 사례
• testing.md: 변경 유형별 실행해야 할 테스트
• api-contract.md: 외부 응답 스키마와 하위 호환성 규칙
• performance.md: 벤치마크 실행법과 결과 기록 형식

중요한 점은 문서를 길게 쓰지 않는 것이다. 에이전트가 매번 읽어야 하는 SKILL.md에는 인덱스와 판단 기준만 두고, 세부 규칙은 references 파일로 나눈다. 긴 지침 파일 하나보다 짧은 규칙 여러 개가 장시간 작업에서 더 잘 작동한다.

3단계: 베이스라인을 먼저 만들게 한다

Argon은 첫 번째 실험에서 7분 만에 벤치마크 스크립트를 만들었고, 70분 동안 측정과 코드 읽기를 한 뒤에야 ADK 소스 코드를 수정했다. 이 순서가 중요하다. 성능 최적화는 “느려 보이는 코드”를 고치는 일이 아니라, 실제 병목과 측정 기준을 고정하는 일이다.

팀에서 에이전트에게 성능 작업을 맡길 때도 첫 커밋이 코드 수정이면 위험 신호로 봐야 한다. 먼저 현재 p50, p95, p99, cold start, warm path, 메모리 사용량, 테스트 반복 횟수, 표본 수를 정해야 한다. 벤치마크가 없다면 에이전트가 만든 성능 개선은 리뷰하기 어렵다.

또한 holdout benchmark를 따로 둬야 한다. Google은 Argon이 보지 못한 bench_turn.py로 최종 변경을 이전 릴리스와 비교했다. 에이전트가 자신이 만든 벤치마크에만 맞춰 최적화하면 실제 사용자 경로에서는 효과가 없을 수 있다. 최소한 “에이전트가 수정 중에 본 벤치마크”와 “리뷰어가 최종 검증에 쓰는 벤치마크”를 분리한다.

4단계: 제안은 많이 받고 머지는 적게 한다

Argon의 overnight PR은 6개 최적화를 제안했지만 실제로 shipped된 것은 2개였다. 세션 히스토리를 복사하기 전에 필터링하는 변경, 무거운 패키지를 필요할 때만 로드하는 lazy import 변경은 채택됐다. 반면 weak reference 기반 캐시, private OpenTelemetry attribute 접근, 성능 효과가 작은 history formatting 변경, synthetic replay에만 유리한 workflow index는 리뷰에서 제외됐다.

이 비율이 건강하다. 장시간 에이전트는 탐색 폭을 넓히는 데 강하지만, 유지보수 판단은 사람이 해야 한다. 모델이 낸 모든 변경을 수용하면 복잡도가 빠르게 쌓인다. 좋은 운영 방식은 “에이전트가 후보를 찾고, maintainer가 뺀다”다.

리뷰 기준도 명확해야 한다. synthetic benchmark에서만 빨라진 변경은 제외한다. private API나 구현 세부에 의존하는 변경은 제외한다. public API와 테스트 mock 경로를 깨는 변경은 제외한다. 캐시는 stale state와 invalidation 근거가 없으면 제외한다. 성능 향상보다 코드 이해 비용이 큰 변경도 제외한다.

5단계: 테스트 범위를 에이전트가 줄이지 못하게 한다

첫 번째 실험에서 Argon은 주변 테스트 216개만 실행했다. 두 번째 실험에서는 전체 16,892개 테스트를 실행했다. 이 차이는 장시간 에이전트 운영에서 매우 중요하다. 모델은 작업을 빨리 끝내기 위해 테스트 범위를 좁히는 선택을 할 수 있다. 그러나 성능 최적화는 cross-file 영향을 만들기 쉽기 때문에 주변 테스트만으로 부족하다.

프로젝트 지침에 테스트 규칙을 넣어야 한다. 예를 들어 “public API, import path, session state, serialization, auth, cache를 건드리면 전체 테스트를 실행한다”처럼 조건을 정한다. 시간이 오래 걸리면 병렬 실행이나 CI를 사용하되, 테스트를 생략하지 않게 한다. 에이전트가 테스트 실패를 발견했을 때는 실패 로그와 수정 이유를 PR에 남기게 한다.

6단계: PR 설명을 결과물로 본다

성능 작업의 결과물은 코드만이 아니다. 전후 수치, 실행한 벤치마크, 제외한 변경, 위험 요소, 롤백 방법이 PR 설명에 있어야 한다. Google 사례에서도 “before and after numbers in its description”이 프롬프트에 들어갔다. 이 요구가 없으면 리뷰어는 긴 에이전트 세션 로그를 뒤져야 한다.

좋은 PR 설명에는 다음이 들어간다.

• 어떤 병목을 줄였는지
• 어떤 벤치마크를 몇 번 실행했는지
• 전후 숫자와 표본 수
• public API가 유지되는 근거
• 새 테스트 목록
• 버린 최적화와 이유
• 알려진 trade-off
• 배포 후 확인할 지표

이 정보가 없으면 성능 PR은 머지 준비가 안 된 것이다.

실행 체크리스트

1. 성능 목표를 “줄일 지표”와 “바꾸지 않을 계약”으로 쓴다.
2. 저장소 규칙을 .agents/skills 또는 AGENTS.md 하위 문서로 나눈다.
3. 첫 작업은 코드 수정이 아니라 베이스라인 벤치마크 작성으로 제한한다.
4. 에이전트가 본 벤치마크와 리뷰어용 holdout benchmark를 분리한다.
5. 제안된 최적화는 모두 수용하지 말고 유지보수 위험으로 걸러낸다.
6. 전체 테스트 실행 조건을 프로젝트 지침에 명시한다.
7. PR 설명에 전후 수치, 버린 제안, 위험 요소를 남기게 한다.

장시간 코딩 에이전트는 시니어 개발자를 대체하기보다, 시니어 개발자가 검토할 후보를 빠르게 넓혀주는 도구에 가깝다. 준비된 규칙과 벤치마크가 없으면 긴 작업 시간은 오히려 위험해진다. 반대로 목표, skill, 테스트, 리뷰 기준을 갖추면 에이전트는 사람이 하루에 다 훑기 어려운 코드 경로를 실제로 탐색할 수 있다.

출처

• Google Developers Blog, Optimizing a 200,000-line Python codebase overnight with Gemini 4 Argon: https://developers.googleblog.com/optimizing-a-200000-line-python-codebase-overnight-with-gemini-4-argon/