Gemini Notebook 감사 로그 사용법: 외부 공유 변경을 조사하는 법

TL;DR

핵심 3줄 요약

이 글에서 다룰 내용

어떤 문제를 해결하는 기능인가요?

언제 쓰면 좋은가요?

외부 공유 알림이나 내부 신고가 들어왔을 때 쓸 수 있습니다. 노트북 소유자와 보안 담당자의 설명이 다르거나 현재 공개 범위만으로 변경 경로를 설명하기 어려운 경우에도 맞습니다. 감사 대응을 위해 특정 기간의 Gemini Notebook 활동을 재구성할 때도 유용합니다.

반대로 앞으로의 외부 공유를 미리 제한하려는 목적이라면 이 로그 검색이 첫 도구는 아닙니다. 그 작업은 Gemini Notebook의 관리자 공유 정책에서 처리해야 합니다. 로그 조사와 정책 변경을 같은 단계로 묶으면 사건 증거를 정리하기 전에 접근 범위를 바꾸게 될 수 있습니다.

시작 전에 권한과 범위를 확인하세요

Reporting → Audit and investigation 경로에는 Audit & Investigation 관리자 권한이 필요합니다. 검색 가능 여부는 Google Workspace 에디션, 관리자 권한, 선택한 데이터 소스에 따라 달라집니다. 최종 사용자에게는 이 기능을 켜거나 끄는 별도 설정이 없습니다.

공식 업데이트에 따르면 Gemini Notebook 감사 로그는 Admin console에서 기본 제공됩니다. 다만 BigQuery로 내보내는 기능은 별도로 켜기 전까지 비활성화되어 있습니다. 이 글에서는 BigQuery 설정이나 자동 경보를 다루지 않고 Admin console의 읽기 중심 조사만 진행합니다.

데이터 위치도 따로 봐야 합니다. 공식 안내는 감사 로그 저장이 표준 Workspace 지역 라우팅 정책을 따른다고 설명합니다. 반면 notebook, source, chat history 같은 Gemini Notebook 사용자 데이터는 전역 저장되며 현재 데이터 리전화가 지원되지 않습니다. 감사 로그의 저장 위치와 사용자 콘텐츠의 저장 위치를 같은 범위로 해석하면 안 됩니다.

2026년 9월 3일부터 Rapid Release와 Scheduled Release 도메인에 최대 15일의 점진 배포가 시작됐습니다. 메뉴가 보이지 않으면 임의로 캐시 삭제나 재설치를 권하지 말고 현재 계정의 에디션, 관리자 권한, 배포 상태를 확인합니다.

외부 공유 변경을 조사하는 7단계

1. 사건 범위와 승인자를 먼저 기록합니다

변경이 의심되는 기간, 대상 노트북 또는 Resource ID, 현재 visibility, 조사 시간대, 조사 담당자, 승인 기록 소유자를 적습니다. 노트북 본문·source·chat history를 조사표에 복사하지 말고 비민감 식별 정보만 사용합니다.

2. Gemini Notebook log events를 엽니다

Google Admin console에서 Menu → Reporting → Audit and investigation → Gemini Notebook log events로 이동합니다. 이 경로 자체가 첫 행동입니다. 공유 정책이나 사용자 권한은 아직 바꾸지 않습니다.

3. Date로 조사 기간을 좁힙니다

화면에는 기본적으로 최근 7일의 이벤트가 표시됩니다. Date 에서 Before 또는 After 를 선택해 신고 시점 전후로 범위를 조정합니다. 표시 시각은 브라우저의 기본 시간대를 따르므로 조사표에 사용한 시간대를 함께 남깁니다.

4. Event 필터를 단계적으로 적용합니다

Add a filter 에서 Event 를 선택하고 연산자와 값을 고른 뒤 Apply , Search 순서로 실행합니다. 공식 도움말은 Event 값의 예로 Sharing permissions updated를 제시합니다. 현재 화면에 이 값이 표시되는지 먼저 확인하고, 보이지 않는 이름을 추정해 입력하지 않습니다.

처음부터 조건을 너무 많이 넣지 않습니다. Date와 Event로 넓게 찾은 다음 대상 리소스와 Actor를 대조하는 편이 누락을 줄이기 좋습니다. 여러 조건은 Filter 탭의 값 쌍이나 Condition builder의 AND·OR 조건으로 구성할 수 있습니다.

5. 조사에 필요한 열을 고정합니다

검색 결과 오른쪽 위 Manage columns 에서 Date, Actor, Event, IP address, Prior visibility, Resources, Visibility를 검토합니다. Prior visibility 는 이벤트 전 공유 공개 범위, Visibility 는 현재 공유 공개 범위를 뜻합니다.

Resources 를 열면 Resource ID·title·type과 owner details를 확인할 수 있습니다. Source나 Studio artifact 관련 속성도 있을 수 있습니다. 다만 모든 이벤트에 모든 속성이 보고되는 것은 아니므로 빈 값은 임의로 채우지 말고 확인 필요 로 둡니다.

6. 로그 행과 승인 기록을 분리해 대조합니다

각 후보 행에서 Date, Actor, Event, Resource ID, Prior visibility, Visibility를 한 묶음으로 봅니다. 그런 다음 변경 요청서, 티켓, 승인 메시지처럼 사람이 남긴 근거와 별도로 대조합니다.

이벤트 행은 어떤 행동이 기록됐다는 증거입니다. 그 행동이 업무상 승인됐는지, 악의가 있었는지, 실제 외부인이 콘텐츠를 열었는지까지 증명하지 않습니다. IP address 역시 보통 사용자의 물리 위치를 반영하지만 프록시나 VPN일 수 있으므로 위치나 침해 여부를 확정하는 근거로 쓰지 않습니다.

7. 내부 증거표를 만들고 조사 단계에서 멈춥니다

조사표에는 행 ID | Date | Actor | Event | Resource ID | Prior visibility | Visibility | 승인 근거 | 판정 | 후속 승인자 를 둡니다. 입력 로그의 각 행을 한 번씩 포함하고, 승인 기록과 맞으면 확인 완료 , 충돌하면 상충 , 값이 없거나 모호하면 확인 필요 로 적습니다.

필요하면 검색 결과의 Export all 을 사용해 Google Sheets 또는 CSV로 내보낼 수 있습니다. 원본은 보존하고 작업 복사본에서 정렬합니다. 권한 변경, 공유 회수, 활동 규칙 생성, 외부 통지, 사용자 제재는 조사표의 후속 제안으로만 남기고 별도 사람이 승인하기 전에는 실행하지 않습니다.

그대로 복사해 쓸 프롬프트

아래 프롬프트에는 승인된 로그 행의 필요한 열만 넣습니다. 이메일 전체, 전체 IP, 노트북·source·chat 내용, 자격증명은 제거합니다.

결과가 자연스럽게 쓰였더라도 원본 로그의 Date·Actor·Resource ID와 한 행씩 다시 맞춰야 합니다. 요약은 증거를 찾는 보조 수단이지 사실 확인을 대신하지 않습니다.

실전 인사이트

주의할 점

자주 묻는 질문

출처

마무리

Gemini Notebook 외부 공유 변경을 조사할 때는 Gemini Notebook log events 에서 Date와 Event로 시작합니다. 이후 Actor, Resources, Prior visibility, Visibility를 같은 행으로 묶고 사람의 승인 기록과 대조합니다.

완료 기준은 로그를 많이 모으는 것이 아닙니다. 대상 행이 빠짐없이 들어가고, 기술 행동과 업무 승인이 분리되며, 불확실한 값이 확인 필요 로 남은 내부 증거표가 있어야 합니다. 그다음 권한 변경과 공유 회수는 별도 승인 절차로 넘깁니다.