Google Gemini 최신 소식 — API 요청 로그 ‘기본 저장’ 전환, 신규 유료 프로젝트부터 55일 보관 (2026.10.28)

출처: Wikimedia Commons “Google Gemini logo 2025.svg” — 퍼블릭 도메인(상표는 Google LLC 소유)

한 줄 요약: “안 남기던 요청이, 이제 남습니다”

구글이 2026년 10월 26일 제미나이 API(Gemini API) 문서를 조용히 고쳤습니다. 이날부터 신규 유료(paid tier) 프로젝트에서 Generate Content API — generateContent, streamGenerateContent, batchGenerateContent — 로 보낸 요청이 기본값으로 저장(store=true) 됩니다. 그동안 이 API는 “기본은 저장 안 함(store=false)”이 원칙이었는데, 상호작용 기록을 서버에 남기는 Interactions API와 동작을 맞춘 것입니다.

이미 만들어진 프로젝트는 기존 설정을 유지합니다. 즉 지금 잘 돌고 있는 파이프라인이 갑자기 로그를 남기기 시작하는 건 아니고, 앞으로 새로 만드는 유료 프로젝트가 기본 저장으로 시작합니다. 문제는 대부분의 팀이 “새 프로젝트”를 아무 생각 없이 만든다는 점입니다. 서비스 분리, 스테이징 환경, 신규 고객사 전용 워크스페이스 — 전부 새 프로젝트로 생성되니까요.

구글 데이터센터 전경 (사진=Lambtron, Wikimedia Commons, CC BY-SA 4.0) 출처: Wikimedia Commons “Google data center.jpg” — 촬영 Lambtron, CC BY-SA 4.0

무엇이 바뀌고, 무엇이 그대로인가

헷갈리기 쉬운 부분이라 표로 먼저 정리합니다.

구분	변경 전	변경 후 (2026.10.26~)
신규 유료 프로젝트 · generateContent	기본 저장 안 함 (`store=false`)	기본 저장 (`store=true`)
기존 유료 프로젝트	설정 그대로	설정 그대로 (영향 없음)
Interactions API	기본 저장	기본 저장 (변동 없음)
무료 티어	저장 기능 자체가 유료 전용	유료 전용 (변동 없음)
보관 기간	요청별 설정	기본 최대 55일, 7·14·28일 선택 가능
저장된 데이터셋	만료 없음	만료 없음 (변동 없음)
끄는 방법	요청마다 `store=false`	요청마다 `store=false` + 프로젝트 단위 설정

문서에 적힌 표현을 그대로 옮기면 이렇습니다. “New projects using the Generate Content API … on the paid tier now store requests by default (store=true), matching the Interactions API. Existing projects keep their current setting.” 그리고 옵트아웃 방법으로 요청에 store=false를 넣거나, Logs and datasets 설정에서 프로젝트 단위로 끄라고 안내합니다.

왜 갑자기 기본값을 뒤집었나

세 가지가 겹쳐 보입니다.

인터페이스 통일. 구글은 2026년 6월부터 Interactions API를 기본 인터페이스로 밀고 있습니다. 새 API는 서버가 대화 상태를 들고 있는 구조라 previous_interaction_id로 문맥을 잇습니다. 저장이 기본이 아니면 이 구조가 성립하지 않습니다. 구형 generateContent만 “저장 안 함”으로 남아 있으면 문서·SDK·샘플 코드가 계속 갈라집니다.
에이전트 디버깅 수요. 에이전트는 한 번의 작업에 수십~수백 번 모델을 호출합니다. 실패 지점을 찾으려면 요청·응답 타임라인이 남아 있어야 합니다. 구글이 “로그와 데이터셋” 기능을 밀어온 흐름과 정확히 맞물립니다.
백그라운드 실행. 장기 실행 작업은 저장이 전제입니다. 실제로 저장을 끈 상태에서 백그라운드 실행을 요청하면 store=true is required for background interactions 오류가 납니다. 상태를 서버가 들고 있어야 재개가 가능하기 때문입니다.

정리하면 편의 기능을 기본값으로 올린 변경입니다. 다만 그 편의의 대가가 “데이터가 남는다”는 사실이고, 이 기본값은 개발자가 아무것도 하지 않아도 적용됩니다.

실제로 남는 것은 무엇인가

“로그”라고 하면 접속 기록 정도를 떠올리기 쉽지만, 여기서 남는 건 훨씬 구체적입니다.

프롬프트 원문 — 사용자가 입력한 문장 그대로
모델 응답 원문 — 생성된 텍스트, 코드, 표
함께 첨부한 컨텍스트 — 업로드한 문서, 이미지, 오디오에서 추출된 내용
상호작용 기록 — Interactions API의 경우 단계(steps) 타임라인, 도구 호출 흐름

즉 사내 문서를 요약시키고, 거래명세서를 붙여 정리하고, 고객 메일을 요약하는 파이프라인이라면 그 원문이 55일간 구글 쪽 로그로 남는다고 봐야 합니다. 저장 버킷에 파일이 쌓이는 게 아니라, API 요청 본문이 로그로 남는 형태입니다.

보관 기간은 줄일 수 있다 — 다만 조건이 있다

기본값은 최대 55일입니다.
프로젝트 설정에서 7일, 14일, 28일로 줄일 수 있습니다.
기간이 지나면 로그는 삭제 대상으로 표시됩니다.
데이터셋으로 저장(save)한 로그는 만료되지 않습니다. 실험용으로 데이터셋을 만들어 두었다면, 그건 별도 자산으로 계속 남습니다.

여기서 실무적으로 중요한 포인트가 하나 있습니다. “로그 보관 55일”과 “남용 모니터링 보관 55일”은 다른 로그입니다. 구글 문서는 정책 위반 감지를 위해 프롬프트·추가 컨텍스트·응답을 최대 55일 보관한다고 안내합니다. 그래서 개발자 로그를 7일로 줄여도, 감사 대응 관점에서 “7일 뒤 전부 삭제”라고 단정할 수는 없습니다. 계약서나 개인정보 처리방침에 보관 기간을 쓰는 팀이라면 이 구분을 반드시 확인해야 합니다.

또 하나. 제로 데이터 보관(ZDR)을 표방하려면 요청마다 store=false를 명시해야 하고, 그와 별개로 암시적 인메모리 캐싱과 cached_content(명시적 캐시) 는 사용자가 정한 TTL만큼 남습니다. 문서도 “완전한 제로 데이터를 원하면 cached_content를 쓰지 말라”고 명시합니다.

영향 1: 업무 자동화 파이프라인이 가장 먼저 맞는다

AI 에이전트를 실사용하는 팀일수록 타격이 큽니다. 이유는 단순합니다. 에이전트가 다루는 데이터가 가장 민감하기 때문입니다.

메일·메신저 요약 파이프라인 → 고객사 이름, 계약 조건, 인사 이슈가 프롬프트에 들어갑니다.
정산·세금계산서 정리 → 사업자번호, 금액, 거래처 정보가 그대로 들어갑니다.
문서 RAG → 사내 규정집, 미공개 기획서가 컨텍스트로 붙습니다.
고객 응대 봇 → 개인정보가 포함된 문의 원문이 들어갑니다.

이런 파이프라인에서 신규 프로젝트를 만들면, 아무 설정도 하지 않은 상태에서 55일 보관이 기본이 됩니다. 개발자는 “로그를 켠 적이 없다”고 생각하지만, 기본값이 바뀌었으니 켜진 것과 같습니다.

특히 위험한 지점은 키 유출 시 피해 범위입니다. API 키가 샜을 때 공격자가 새로 호출하는 피해는 즉시 탐지·차단할 수 있지만, 이미 저장된 55일치 로그는 과거 데이터 유출로 이어질 수 있습니다. 로그 저장소 자체가 공격 표면이 되는 셈입니다.

영향 2: 개발자·보안·감사 관점

관점	달라지는 것	대응
개인정보	요청 본문이 기본 보관	민감정보 마스킹, `store=false` 기본화
계약·DPA	보관 기간·위탁 범위 조항 재검토	남용 모니터링 55일 별도 명시
감사	“삭제했다”는 증적 요구 증가	프로젝트 설정 스크린샷·정책 문서화
사고 대응	키 회수만으로 끝나지 않음	키 로테이션 + 로그 접근 권한 최소화
데이터 거버넌스	프로젝트 생성 절차에 보안 게이트 필요	템플릿·IaC로 `store=false` 강제

특히 IaC(Infrastructure as Code) 로 프로젝트를 찍어내는 조직은 지금 바로 확인할 필요가 있습니다. Terraform이나 사내 스캐폴딩이 프로젝트를 만들 때 로그 설정을 명시하지 않는다면, 신규 프로젝트는 전부 기본 저장으로 태어납니다. 프로젝트 생성 템플릿에 “로깅 끄기”를 넣는 것이 가장 싸고 확실한 대응입니다.

지금 확인해야 할 5가지

1) 새 프로젝트인지, 기존 프로젝트인지 확인

10월 26일 이후 생성된 유료 프로젝트는 기본 저장입니다. 반대로 그 이전 프로젝트는 설정이 유지되므로, “우리는 해당 없다”고 안심하기 전에 최근에 만든 프로젝트 목록을 먼저 뽑아보는 게 순서입니다.

2) 요청 단위로 끄기

REST 기준으로는 요청 본문에 store를 넣으면 됩니다.

curl -s "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{"parts": [{"text": "요약할 문서 본문"}]}],
    "store": false
  }'

SDK를 쓴다면 요청 설정(config) 단계에서 같은 값을 넘깁니다. 중요한 건 한 곳에서만 끄면 전체가 꺼지지 않는다는 점입니다. 배치 작업, 백그라운드 작업, 별도 마이크로서비스가 각자 호출한다면 전부 확인해야 합니다.

3) 프로젝트 단위로 끄기

Logs and datasets 설정에서 프로젝트 전체 로깅을 끌 수 있습니다. 운영 프로젝트는 프로젝트 단위로 끄고, 실험 프로젝트만 켜 두는 식이 관리하기 편합니다.

4) 보관 기간 단축 + 데이터셋 정리

로깅을 유지해야 하는 경우(디버깅·품질 개선)라면 보관 기간을 7일로 줄이고, 데이터셋으로 저장한 로그가 있는지 점검합니다. 데이터셋은 만료가 없으므로, 잊고 있던 실험 데이터가 몇 년치 쌓여 있을 수 있습니다.

5) 백그라운드 작업의 예외 처리

장기 실행·재개가 필요한 작업은 store=true가 강제됩니다. 이 경우엔 저장을 끄는 대신, 프롬프트에 들어가는 데이터를 최소화하는 방향으로 설계를 바꿔야 합니다. 원문을 통째로 넣지 말고, 필요한 필드만 추려 넣는 전처리 단계를 두는 식입니다.

균형 있게 보면: 과장할 일도, 무시할 일도 아니다

솔직히 말하면 이 변경은 “갑자기 데이터를 수집하기 시작했다”기보다 “기본값을 편의 쪽으로 맞췄다”에 가깝습니다. 유료 티어의 프롬프트를 모델 학습에 쓰지 않는다는 구글의 기존 방침은 그대로이고, 저장을 끄는 수단도 명확히 제공됩니다.

그런데도 이걸 이슈로 봐야 하는 이유는 기본값의 힘입니다. 대부분의 팀은 기본값을 바꾸지 않습니다. 옵트아웃이 문서 세 줄 안에 있어도, 그 세 줄을 읽지 않으면 적용되지 않습니다. 정책 변경에서 실제 사고는 “막을 수 없어서”가 아니라 “몰라서” 생깁니다.

반대로, 로그가 남는 게 반드시 나쁜 것만도 아닙니다. 에이전트가 왜 이상한 답을 했는지 사후에 추적할 수 있고, 품질 회귀를 데이터로 잡을 수 있습니다. 문제는 선택입니다. 남길 거면 남기고, 안 남길 거면 끄고 — 그 결정을 팀이 하고 있어야 합니다.

전망: ‘기본 저장’은 업계 공통 방향이 된다

이번 변경은 구글만의 일이 아닙니다. 에이전트 시대의 API는 상태를 서버가 들고 있는 쪽으로 빠르게 이동하고 있고, 상태를 들고 있으면 필연적으로 기록이 남습니다. Interactions API가 기본 인터페이스가 된 순간, 구형 generateContent의 “저장 안 함” 기본값은 정합성 측면에서 오래 버티기 어려웠습니다.

앞으로 예상되는 흐름은 세 가지입니다.

보관 기간 세분화 — 7·14·28·55일처럼 규제 산업용 옵션이 더 촘촘해질 가능성.
리전·조직 단위 정책 — 프로젝트마다 끄는 방식에서, 조직 정책으로 일괄 강제하는 방식으로 이동.
ZDR의 상품화 — 제로 데이터 보관이 기본이 아니라 계약 옵션으로 자리 잡는 흐름. 이미 다른 대형 모델 사업자들이 같은 방향입니다.

결국 개발자에게 남는 숙제는 하나입니다. “이 요청이 남아도 되는 데이터인가?”를 코드를 짜기 전에 묻는 습관. 모델을 고르는 기준에 가격·성능만 넣던 시절은 끝났고, 이제 보관 정책이 선택 기준의 한 줄을 차지합니다.

마무리: 오늘 할 일은 하나면 충분합니다

거창하게 체계를 만들 필요는 없습니다. 10월 26일 이후 만든 유료 프로젝트 목록을 뽑고, 그중 민감 데이터를 다루는 프로젝트의 로깅을 끄거나 7일로 줄이면 이번 변경의 실질 리스크는 대부분 정리됩니다.

자동화 파이프라인을 운영한다면, 프로젝트 생성 템플릿에 로깅 설정을 박아두는 것까지 해두면 다음 프로젝트부터는 신경 쓸 일이 없어집니다. 새 기능이 좋아서 쓰는 것과, 새 기본값이 무서워서 점검하는 것은 별개의 일이니까요. 둘 다 하면 됩니다.

참고한 자료

Google AI for Developers, Gemini API Release notes / Changelog (2026.10.26)
Google AI for Developers, Logs and datasets · Zero data retention · Abuse monitoring 문서
관련 보도: “Gemini API now stores requests by default for new paid projects” (2026.10.27~28)