Google I/O 2026에는 헤드라인을 장식할 만한 내용들이 있었습니다. 네 가지 크기로 제공되는 Gemma 4, 새로운 에이전트 친화적인 Gemini 인터페이스, Genie, Project Mariner 관련 내용들 모두 이야기할 가치가 있습니다. 하지만 실제로 어떤 에이전트를 구축하는 것이 타당할지, 그리고 스프레드시트에서 어떤 에이전트를 삭제할지를 결정하게 만들 발표는 이 중 그 어느 것도 아닙니다. 바로 Gemini 2.5 Flash의 캐시 할인 (cache-discount) 가격 티어입니다. 저는 Gemini 에이전트를 위한 오픈 소스 관측성 레이어 (observability layer)인 GeminiLens를 유지 관리하는 사람입니다. 비용 계산 (Cost calc)은 해당 라이브러리의 핵심 부분입니다. 저는 키노트가 끝난 바로 다음 날 계산 방식을 다시 작성해야 했습니다. 그 이유는 다음과 같습니다.

이전의 계산 방식
I/O 2026 이전의 고빈도 Gemini 에이전트에 대한 저의 사고 모델은 다음과 같았습니다:
입력 토큰 (Input tokens): 100만 개당 $0.30
출력 토큰 (Output tokens): 100만 개당 $2.50
점점 커지는 시스템 프롬프트 (system prompt)와 함께 한 번의 실행에서 Gemini를 30회 이상 호출하는 연구 에이전트의 경우, 입력 토큰 비용이 지배적입니다. 매 달러의 3분의 2는 동일한 시스템 프롬프트와 도구 목록 (tool list)을 반복해서 다시 보내는 데 사용됩니다. 프롬프트를 줄여서 이 문제를 해결할 수는 없습니다. 도구 목록이 곧 에이전트이기 때문입니다. 이를 줄이면 에이전트가 멍청해집니다. 따라서 선택지는 보통 두 가지였습니다: 입력 비용 전액을 지불하거나, 도구 사용 능력이 떨어지는 더 작은 모델을 중심으로 에이전트를 다시 구축하거나 말입니다.

새로운 계산 방식
캐시 할인 (cache-discount) 티어 (I/O에서 발표되었으며 현재 API에 적용됨)는 입력 토큰에 대해 세 번째 가격을 도입합니다: 캐시된 입력 (cached input). 최근에 이미 전송한 토큰 (캐시 TTL 창 내)은 새로운 입력 토큰보다 대략 한 자릿수(an order of magnitude) 더 저렴합니다. 시스템 프롬프트 + 도구 목록이 매 턴마다 변하지 않는 에이전트 루프의 경우, 첫 번째 호출 이후 모든 호출에서 "입력 토큰"의 약 95%가 이제 캐시됩니다. 비용 그래프가 급격히 하락합니다. 저는 제가 가장 좋아하는 스트레스 테스트 시나리오를 다시 수행했습니다: 4K 토큰 시스템 프롬프트와 12개의 도구 함수 호출 (function-calling) 스키마를 가진 30단계 연구 에이전트입니다.

| 기존 가격 | 새로운 가격 | 단계당 평균 비용 | $0.0048 | $0.0011 |
| 30단계 실행당 비용 | $0.14 | $0.033 |
| 일일 10만 회 실행 시 비용 | $14,400 | $3,300 |

이는 4.3배의 비용 절감이며, 이는 "더 작은 모델을 사용하라"거나 "프롬프트를 더 똑똑하게 작성하라"는 조언 때문이 아니라 오직 가격 정책의 변화만으로 달성된 결과입니다. 이것이 어떤 에이전트가 타당해지는지에 대해 의미하는 바는 다음과 같습니다.

저는 "만들고 싶지만 단위 경제성 (unit economics) 때문에 포기했던 에이전트 아이디어" 목록을 가지고 있습니다. 캐시 할인 (cache-discount) 티어 도입 이후, 그중 세 가지가 '불가능'에서 '아마도 가능'으로 바뀌었습니다:

1. 실시간 보안 경고 분류 (Real-time security alert triage): 모든 새로운 경고가 20단계의 Gemini 조사를 시작하는 경우. 기존 계산: 경고당 약 $1.50. 새로운 계산: 약 $0.35. 높은 경고 발생량에서도 갑자기 실행 가능해졌습니다.
2. B2B SaaS를 위한 사용자별 일일 연구 요약 (Daily-per-user research digests): 기존 계산: 사용자당 일일 $1.10. 새로운 계산: 약 $0.25. 이제 좌석당 $20 가격 모델에서도 방어 가능합니다.
3. 장기 실행 모니터링 에이전트 (Long-running monitoring agents): 5분마다 깨어나 상태를 재평가하고, 변화가 없으면 결정한 뒤 다시 잠드는 에이전트. 기존 계산으로는 이 방식이 무모해 보였습니다. 새로운 계산: Cron 작업에서 계속 대화하는 Gemini 에이전트가 이제 작은 휴리스틱 (heuristic) Lambda 함수보다 저렴합니다.

이 중 어느 것도 화려하지 않습니다. 키노트 슬라이드에서 언급된 것도 없습니다. 하지만 단위 경제성에 기반하여 Gemini 에이전트를 구축하는 팀에게 있어, 캐시 할인 티어는 게임의 판도를 바꾸는 (changes the model) I/O 발표입니다.

GeminiLens에서 변경하는 사항

저는 같은 날 GeminiLens에서 세 가지 사항을 업데이트해야 했습니다:

1. 비용 계산 시 이제 토큰 클래스를 별도로 추적합니다.

수정 전

total_cost = input_tokens * INPUT_PRICE + output_tokens * OUTPUT_PRICE

수정 후

total_cost = ( fresh_input_tokens * INPUT_PRICE_FRESH + cached_input_tokens * INPUT_PRICE_CACHED + output_tokens * OUTPUT_PRICE )

단순 합산 방식은 어떤 호출이 캐시가 적용된 상태(cache-hot)인지 아니면 적용되지 않은 상태(cache-cold)인지를 숨기고 있었습니다. 이제 JSONL 감사 로그(audit log)는 fresh_input_tokens와 cached_input_tokens를 별도의 필드로 기록합니다. Streamlit 대시보드는 호출당 캐시 적중률 (cache-hit ratio)을 렌더링합니다.

2. 대시보드에 이제 "캐시될 수 있었음 (could-have-been-cached)" 경고를 표시합니다.

만약 30단계 실행에서 모든 호출의 캐시된 토큰이 0개인 것을 발견한다면, 그것은 버그입니다. 캐시 TTL (Time To Live) 설정이 잘못되었거나 프롬프트가 재배열(reshuffled)되고 있을 가능성이 높습니다.

이제 경고(warning)로 표시됩니다. 3. 실행당 비용 추정치(Cost-per-run estimator)가 콜드 스타트(cold-start)와 정상 상태(steady-state)를 분리합니다. 에이전트 루프(agent loops)의 경우, 첫 번째 호출은 콜드(cold, 전체 입력 가격 적용) 상태이며, 정상 상태는 핫(hot) 상태입니다. 평균값을 보고하는 것은 전체적인 그림을 평탄화하여 최적화 결정을 어렵게 만듭니다. 새로운 대시보드는 두 수치를 별도로 보여줍니다. 눈에 띄지 않는 사실: 제가 본 대부분의 I/O 보도 자료들은 캐시 티어(cache tier)를 "API 최적화"로 프레임화합니다. TechCrunch 포스트의 4번째 단락이나 Gemini 문서 페이지의 3분의 2 지점처럼 말이죠. 이것은 사실 특정 형태의 에이전트에게 있어 유닛 이코노믹스(unit-economics, 단위 경제성)의 비약적인 변화(step change)입니다. 즉, 프롬프트가 대규모로 유지되고 루프가 길게 지속되는 형태의 에이전트 말입니다. 만약 여러분이 그런 종류의 에이전트를 출시하고 있다면, 스프레드시트를 다시 작성하십시오. 5월 16일 금요일에 가지고 있던 계산법은 더 이상 유효하지 않습니다. 이것은 저의 Google I/O 2026 글쓰기 챌린지(Writing Challenge) 제출물입니다. 저는 @MukundaKatta 아래에서 오픈 소스 AI 에이전트 신뢰성 도구(reliability tooling)를 개발하고 있습니다. GeminiLens는 PyPI에서 이용 가능합니다: pip install geminilens .