Google Drive의 정책 기반 자동 암호화는 베타 등록과 지원 조건을 갖춘 조직을 위한 기능입니다. 파일 URL이 유지된다는 설명만 보고 기존 기능과 이전 버전까지 그대로 남는다고 생각하면 안 됩니다. 도입을 검토한다면 암호화 대상뿐 아니라 연결된 자동화, 파일 이력, 외부 키 서비스의 준비 상태를 먼저 나누어 보세요.
Google은 2026년 11월 5일 정책으로 클라이언트 측 암호화를 적용하는 베타를 발표했습니다. 이 글은 2026년 11월 6일 공지와 관리자 문서를 확인한 해설입니다. 실제 조직의 규칙을 만들거나 암호화·복호화·삭제를 시험하지 않았습니다. 아래 표와 사례는 도입 전에 질문을 정리하기 위한 자체 자료예요.
새 기능의 핵심은 조건에 맞는 파일을 전환하는 방식이에요
이번 발표는 관리자가 정한 조건에 맞는 Drive 파일에 Workspace CSE를 자동 적용하는 Policy-Based Enforcement입니다. CSE는 Client-side encryption, 즉 클라이언트 측 암호화를 줄인 말이에요. 공지는 기존 파일의 URL을 유지하면서 암호화를 적용한다고 설명합니다.
먼저 일반 Drive 파일에 아무 암호화도 없었다는 뜻으로 읽지 않는 것이 좋겠습니다. 사용자용 도움말은 일반 파일도 전송 중과 저장 중에 암호화되며, CSE는 추가적인 기밀성을 위한 선택이라고 설명합니다. 서로 다른 보호 방식과 운영 조건을 비교하는 이야기이지, 기존 파일을 모두 평문이라고 부르는 이야기는 아닙니다.
이름에 ‘자동’이 들어가지만 아무 준비 없이 전체 파일이 바뀌는 기능도 아닙니다. 어떤 파일이 조건에 맞는지, 누가 규칙을 정할지, 키 서비스를 누가 운영할지가 선행 질문이에요. 파일 담당자와 보안 담당자가 서로 다른 경우라면 같은 용어를 쓰고 있는지부터 맞춰 보세요.
공지를 읽은 뒤 간단한 설명 메모를 만든다면 ‘조건에 맞는 파일에 추가 암호화를 적용하는 베타’라고 적을 수 있겠습니다. 여기에 자신의 조직에서 아직 확인하지 않은 전제까지 완료된 것으로 덧붙이지 마세요. 제품이 제공하는 기능과 실제 조직이 준비한 환경을 구분하는 출발점입니다.
모든 계정에 기본으로 켜지는 기능은 아닙니다
출시 공지는 기능이 기본적으로 꺼져 있고, 베타 신청과 허용목록 등록이 필요하다고 안내합니다. 공지의 제공 범위에는 Enterprise Plus에 Assured Controls 또는 Assured Controls Plus 추가 기능을 갖춘 고객이라는 조건이 있습니다. 개인 Drive 계정이나 모든 Workspace 플랜에 자동 적용됐다고 쓰기에는 범위가 다릅니다.
지원 조건을 확인할 때에는 현재 계약과 실제 베타 등록 상태를 따로 물어보세요. 제품 이름을 안다는 사실, 추가 기능이 있다는 사실, 해당 도메인이 허용됐다는 사실은 각각 확인해야 하는 내용입니다. 조직의 어떤 담당자가 답할 수 있는지도 함께 적어 두면 문의를 반복하는 일을 줄이는 데 도움이 될 수 있어요.
관리 도움말의 지원 에디션 표기에는 교육용 에디션도 등장합니다. 따라서 출시 공지의 Enterprise Plus 범위와 도움말의 더 넓은 에디션 문구를 하나로 섞어 ‘교육 계정도 모두 즉시 이용 가능’이라고 단정하지 않겠습니다. 자신의 계약과 베타 자격은 공식 지원 경로에서 별도로 확인해야 합니다.
이 차이는 자료를 읽을 때 함께 남겨야 할 조건입니다. 어느 문서가 무조건 잘못됐다고 판단하거나 더 넓은 문구 하나만 선택해 구매를 권하는 대신, 확인한 문서와 기준일을 적어 두세요. 이 글은 특정 조직의 계약 자격이나 다음 날의 이용 가능 여부를 확정하지 않습니다.
같은 URL은 같은 파일 사용 경험을 보장하지 않아요
가령 팀의 안내 문서 링크가 업무 게시판 여러 곳에 붙어 있다고 가정해 보세요. 링크를 그대로 쓸 수 있다는 점은 배포된 주소를 관리하는 관점의 장점으로 이해할 수 있습니다. 하지만 그 문서를 열었을 때의 기능, 이전 이력, 다른 도구와의 연결까지 같다는 결론은 별도로 확인해야 합니다.
정책 기반 CSE 관리자 문서는 파일 전환의 영향을 구체적으로 설명합니다. 서버 측 접근이 필요한 연결된 Forms와 문서에 묶인 Apps Script 같은 기능은 중단되고 기본 파일에서 영구적으로 제거된다고 안내합니다. Docs·Sheets·Slides의 최신 리비전은 남지만 이전 비암호화 리비전은 삭제된다고 설명합니다.
따라서 ‘문서가 열린다’는 확인만으로 전환 검수를 끝내면 부족합니다. 원래 이 파일에서 어떤 업무를 했는지, 어떤 연결과 이력을 사용했는지까지 같은 기준으로 봐야 해요. 여기서는 실제 파일을 변환해 보지 않았으므로 작동 여부나 복구 성공을 확인했다고 쓰지 않습니다.
| 나누어 볼 대상 | 전환 전에 담당자에게 물을 내용 |
| 파일 주소 | 기존 링크가 쓰이는 위치를 알고 있나요? |
| 현재 내용 | 보존해야 할 최신 내용과 책임자가 정해졌나요? |
| 이전 리비전 | 과거 이력이 필요한 업무가 연결돼 있나요? |
| 연결 기능 | Forms·Apps Script 등 의존 기능이 있나요? |
| 사용 과정 | 열기·편집·공유 방식의 제약을 검토했나요? |
이 표는 모든 파일에 동일한 영향이 생긴다고 선언하는 목록이 아닙니다. 파일 형식과 기능에 따라 확인할 대상을 빠뜨리지 않기 위한 자체 질문이에요. 단순 문서와 여러 자동화의 출발점인 스프레드시트를 같은 준비 상태로 처리하지 않는 데 초점을 두었습니다.
되돌리기 계획은 ‘스위치를 끄면 끝’이라고 정하지 마세요
이전 리비전이나 연결 기능이 제거되는 영향을 읽었다면, 규칙을 나중에 꺼도 모든 것이 원래대로 돌아온다고 가정해서는 안 됩니다. 운영 담당자가 실제 복구 가능한 내용과 별도로 복원해야 할 업무를 구분해야 해요. 이 글은 복구를 시험하지 않았고 원래 상태로의 자동 복원을 보장하지 않습니다.
관리 문서는 제거된 내용의 내보내기 파일에 대한 설명도 제공합니다. 그 사실을 ‘모든 기능과 이력을 즉시 되살리는 백업’이라는 말로 바꾸어 받아들이지는 마세요. 무엇이 보관되는지, 누가 열 수 있는지, 원래 업무에 어떻게 연결할지는 각각 확인할 내용입니다.
도입 전 메모에는 ‘유지될 것이라고 기대한 기능’과 ‘문서에서 확인한 영향’을 따로 적어 보세요. 예를 들어 이전 버전으로 돌아가 자료를 확인하는 업무가 있었다면, 그 필요를 파일 소유자에게 먼저 확인하는 식입니다. 실제 문서의 민감한 내용을 이 검토 메모에 복사할 필요는 없습니다.
판단이 끝나지 않은 상태라면 대상을 넓히기보다 확인할 파일 유형과 책임자를 명확히 남기는 편이 좋겠습니다. 이는 조직의 변경 승인을 대신하는 지시가 아니라 검토 순서를 정리하는 제안입니다. 실제 전환은 승인된 운영 절차와 복구 계획을 갖춘 담당자가 수행해야 합니다.
외부 키 서비스도 준비 항목에 넣어 주세요
관리 문서는 기존 CSE와 신원 제공자, 외부 키 서비스인 KACLS의 준비를 요구합니다. 자동 적용에는 키 서비스의 systemwrap 지원 여부도 확인 대상이에요. 여기서 systemwrap은 이번 자동 암호화에 필요한 키 서비스 기능의 이름이며, 이 글에서 실행할 명령어로 제시하는 것은 아닙니다.
‘지원한다’는 설명을 읽는 일과 자신의 조직이 연결한 서비스가 준비됐다는 사실은 다릅니다. 계약한 서비스와 운영 담당자에게 지원 범위와 현재 준비 상태를 확인해 보세요. 인증 정보를 글이나 메신저에 붙여 넣거나, 권한을 더 넓혀 보면서 확인하는 방식으로 접근할 필요는 없습니다.
관리 문서에 따르면 KACLS에 연결할 수 없을 때에는 파일이 암호화되지 않은 채 남고 알림이 발생할 수 있습니다. 규칙의 조건에 맞았다는 사실만으로 암호화 완료를 보고하면 안 되는 이유예요. 상태를 확인할 때에는 규칙 일치와 실제 전환 결과를 나누어 읽어야 합니다.
이 구분은 오류가 생길 것이라고 미리 단정하는 설명이 아닙니다. 정상 도입을 검토할 때도 어떤 증거를 완료 기준으로 쓸지 먼저 합의하자는 뜻이에요. 서비스 운영자가 확인할 사항과 파일 사용자가 확인할 사항을 나누어 두면 어느 단계의 답이 아직 비어 있는지도 보입니다.
실제 적용 전에는 대상 범위부터 읽어 보세요
공식 관리 문서는 암호화를 바로 실행하기 전에 감사 전용 규칙으로 영향을 받는 파일을 확인하는 방법을 제안합니다. 이 글에서는 그 규칙을 생성하지 않았습니다. 중요한 점은 ‘대상으로 예상한 파일’과 ‘조건에 실제로 맞는 파일’을 구분해서 검토하는 과정입니다.
가상 팀의 예를 들어 볼게요. 팀은 외부에 배포하는 완성 문서만 떠올렸지만, 같은 위치에 내부 응답 수집 시트나 자동화에 쓰는 자료가 함께 있다고 가정합니다. 이때 검토할 것은 파일 수를 줄이는 기술보다, 자신이 정한 조건이 업무의 경계를 정확히 표현했는지입니다. 실제 조직에서 이런 구성이 있다고 주장하는 사례는 아닙니다.
| 검토 메모 항목 | 확인 결과를 남기는 방식 |
| 의도한 범위 | 어떤 파일과 사용자를 생각했는지 적기 |
| 관찰한 범위 | 조건에 맞는 대상으로 확인한 근거 기록 |
| 예상과의 차이 | 연결 기능·파일 위치·소유 조건을 다시 질문 |
| 완료의 증거 | 규칙 일치와 암호화 결과를 따로 확인 |
| 미확인 항목 | 책임자와 다음 확인 내용을 남기기 |
공지의 My Drive와 공유 드라이브 지원을 읽을 때에도 파일이 놓인 위치와 조직의 관리 범위를 함께 봐야 합니다. 지원되는 위치라는 이유만으로 그 안의 모든 자료를 같은 정책으로 바꿔야 하는 것은 아닙니다. 실제 대상과 예외는 조직의 기준에 따라 결정할 부분이에요.
보안 기능을 한 가지 완료 표시로 묶지 않는 편이 좋아요
파일 전환 결과를 확인할 때에는 공식 문서가 안내하는 규칙 로그와 암호화 적용 결과를 대조해야 합니다. 처리 시간이 얼마나 걸릴지, 모든 파일이 같은 시점에 끝날지 이 글에서 수치로 약속하지는 않겠습니다. 관리 문서도 파일 수와 여러 조건에 따라 소요 시간이 달라질 수 있음을 설명합니다.
같은 보안 분야에서도 질문은 다를 수 있어요. GitHub의 공개 유출 탐지 범위를 확인한 글은 공개된 비밀정보를 찾는 서비스의 범위를 다룹니다. 이번 글은 Drive 파일을 추가 암호화 상태로 전환하는 조건과 업무 영향을 다룹니다. 어느 한쪽의 완료가 다른 보호 조치까지 끝냈다는 뜻은 아닙니다.
URL이 같으면 사용자에게 안내할 필요가 없나요? 기능과 접근 경험에 영향이 있을 수 있으므로 조직의 안내 기준을 확인해야 합니다. 공지는 추가 암호화가 적용됐음을 알려 주는 제품 내 안내도 설명합니다. 링크를 바꾸지 않는 일과 사용자가 변화의 의미를 이해하는 일은 다른 확인 항목입니다.
베타를 사용하면 특정 규정을 자동 충족하나요? 이 글은 규정 준수나 법률 판단을 제공하지 않습니다. 확인한 것은 제품의 기능과 조건이며, 조직의 의무와 운영 적합성은 별도로 검토할 내용입니다. 도입 전에 계정 조건, 파일 영향, 키 서비스, 완료 증거를 한 장에 적는 것부터 시작해 보시면 좋겠습니다.
'소프트웨어개발' 카테고리의 다른 글
| GitHub 비밀키 탐지 업데이트: 경고가 줄었다면 안전해진 걸까요? (0) | 2026.11.07 |
|---|---|
| Google Forms에 Gemini 분석 추가: 응답 12개면 바로 쓸 수 있을까요? (0) | 2026.11.07 |
| GitHub Desktop 토큰이 짧아집니다: 업데이트만 하면 전환될까요? (0) | 2026.11.06 |
