구글, 프롬프트와 응답을 기록하지 않는 추론 요청 메타데이터 로깅 정식 출시

구글 클라우드는 2026년 10월 30일 Gemini Enterprise Agent Platform의 출시 기록에서 추론 요청 메타데이터 로깅을 정식 제공한다고 발표했다. 명시적으로 켜면 지원되는 추론 요청마다 모델, 리전, 토큰 수, Provisioned Throughput 사용량, 지연 및 오류 코드를 포함한 구조화된 Cloud Logging 항목을 남길 수 있으며 프롬프트나 응답 본문은 기록하지 않는다. 정식 출시는 기능의 제공 단계를 뜻하지 모든 프로젝트에서 기본으로 켜졌거나 모든 모델과 API 방식이 대상이라는 뜻이 아니다. 이 사이트의 발행일은 11월 2일이다.

먼저 실제 지원 범위를 살펴야 한다. 발표는 Gemini의 `generateContent`와 `streamGenerateContent`, Claude의 `rawPredict`와 `streamRawPredict`를 열거한다. 세부 문서는 다른 협력사 모델의 호출은 이 방식으로 기록되지 않는다고 밝힌다. 종량제와 예약된 Provisioned Throughput 모두 지원하지만 애플리케이션이 어느 API 방식을 쓰는지는 운영자가 확인해야 한다. 지원하지 않는 트래픽을 한 보고서에 섞으면 로그가 없는 것을 사용량이 없는 것으로 잘못 읽을 수 있다. 이 항목은 운영과 이용의 메타데이터일 뿐 요청과 답변의 전체 보관본이 아니다. 본문이 필요하다면 구글은 별도의 요청·응답 로깅 기능을 안내한다.

설정은 구글 클라우드 콘솔의 Provisioned Throughput 화면이나 REST API에서 프로젝트 전체 또는 특정 리전의 모델 단위로 할 수 있다. 적용에 몇 분이 걸릴 수 있으므로 변경 시각과 이후 보낸 식별 가능한 시험 요청을 기록해야 한다. 세부 안내에는 게시자 모델 설정을 바꾸고 로그 버킷을 관리하는 데 필요한 IAM 권한이 나온다. Observability Analytics에서 SQL로 조회하거나 콘솔의 자세한 지표를 보려면 `_Default` 버킷을 업그레이드해야 한다. 이 업그레이드는 되돌릴 수 없고 이전에 쓰인 로그를 나중에 SQL로 조회할 수도 없다. 로깅 활성화, 저장소 업그레이드, 분석자 접근 허용은 서로 다른 변경이므로 각각 검토해야 한다.

비용과 보관 기간도 운영 조건이다. Cloud Logging의 수집과 보관에는 요금이 붙고 Observability Analytics 조회는 Cloud Monitoring 사용량으로 과금된다. 기본 버킷의 보존 기간은 30일이다. 자체 라벨이 많으면 로그 한 건의 크기가 커지고 많은 요청을 보내는 에이전트 서비스에서는 비용이 의미 있게 늘 수 있다. 구글은 대표적인 업무에서 하루 분량의 로그를 재고 월 비용을 예상하라고 권한다. 프롬프트와 답변을 저장하지 않는 것은 수집 범위를 줄이지만 라벨에 민감한 식별자를 넣으면 다른 유출 위험이 남는다. 라벨 규칙과 접근 권한, 보존 정책, 경보를 함께 점검해야 한다.

실용적인 용도는 팀, 애플리케이션, 고객별 사용량의 귀속이다. 클라이언트가 `x-goog-agent-platform-observability-label-`로 시작하는 헤더를 보내면 Observability Analytics에서 라벨 기준으로 조회할 수 있다. 같은 기록에서 모델·리전별 토큰, 오류, 지연, 예약 처리량의 소진과 초과 여부도 분석할 수 있다. 그러나 업무상 귀속이 자동으로 완성되는 것은 아니다. 어떤 클라이언트가 헤더를 빠뜨리거나 서비스마다 다른 이름을 쓰면 집계는 전체 사용량을 나타내지 않는다. 청구서와 비교할 때도 일반 토큰, 캐시 토큰, 사용량 메타데이터와 실제 청구 금액을 구별해야 한다.

작게 검증하려면 시험 프로젝트에서 IAM과 버킷을 확인한 뒤 기능을 켜고 적용을 기다려 지원되는 Gemini 방식과 Claude 방식으로 표식이 있는 요청을 각각 보낸다. Logs Explorer 또는 이미 준비된 분석 버킷에서 모델, 리전, 토큰, 오류 필드를 확인한다. 지원되지 않는 방식도 함께 점검해 ‘로그 없음’을 ‘요청 없음’으로 오해하지 않게 한다. 설정을 되돌리는 방법과 이미 보관된 로그의 처리 규칙도 남겨야 한다. 비용과 정보 접근 범위가 바뀌므로 이 글을 읽었다는 사실만으로 운영 환경 설정 변경이 허가되는 것은 아니다.

로그 한 건이 존재한다고 업무 요청이 성공했다고 단정할 수 없다. 실패한 요청에도 오류 항목이 남을 수 있다. 반대로 로그가 비면 설정 전파 지연, 지원하지 않는 API, 조회 권한 부족이 원인일 수 있다. 호출 측의 건수와 시간대를 보존해 Cloud Logging과 대조해야 수집 장애와 실제 사용량 변화를 분리할 수 있다.

이번 기능은 추론 운영과 비용 귀속을 더 세밀하게 확인할 근거를 제공하지만 지원 범위, 명시적 설정, 권한 및 기록 품질에 좌우된다. 실제 요청과 대조한 뒤 지속적인 분석에 써야 하며 메타데이터 로그를 프롬프트 전체 감사라고 부르면 안 된다.