Google Workspace MCP 11월 11일 차단 예고: OAuth 클라이언트 분리 점검

AI 에이전트와 일반 앱의 OAuth 신원을 분리하는 개념도. 생성형 이미지이며 실제 Google 설정 화면은 아니다.

Google Workspace의 공식 원격 MCP 서버를 붙인 앱이라면 이번 주에는 모델보다 실제 요청에 쓰이는 OAuth 클라이언트부터 확인해야 한다. Google은 10월 12일 공지에서 11월 11일부터 에이전트용으로 표시되지 않은 클라이언트의 MCP 요청을 거부한다고 예고했다. 11월 9일 기준 적용이 임박한 변경이다. 새로 발표된 기능으로 소개하는 글이 아니라, 아직 전환하지 않은 통합의 장애를 줄이기 위한 점검 글이다. 공식 릴리스 노트

11월 11일과 12일은 서로 다른 경계다

11월 11일: Use this client for an AI-powered agent가 선택되지 않은 OAuth 클라이언트의 Google Workspace MCP 요청이 거부되기 시작한다.

11월 12일까지 미표시 상태인 기존 클라이언트: 이후에도 non-agentic 상태로 남는다. 그 뒤 MCP를 쓰려면 에이전트용 새 OAuth 클라이언트를 만들고 앱이 이를 사용하도록 바꿔야 한다.

일반 Workspace REST API만 사용하는 비에이전트 앱: 이 변경의 대상이 아니다.

두 날짜 사이를 정상 이용이 보장되는 유예 기간으로 해석하면 안 된다. 공지는 정확한 시행 시각이나 시간대를 제시하지 않는다. 한국 시간 자정으로 임의 환산하기보다 시행일 전에 점검과 검증을 끝내는 편이 안전하다. Gmail·Calendar·Chat·Docs·Drive·Sheets 등의 공지에 같은 일정이 실려 있다. 일정과 영향 범위

먼저 ‘어느 MCP 서버인가’를 구분한다

이 글의 대상은 Google이 제공하는 Workspace 원격 MCP 서버다. 예를 들어 Gmail은 https://gmailmcp.googleapis.com/mcp/v1, Drive는 https://drivemcp.googleapis.com/mcp/v1을 사용한다. 두 제품의 구성 문서는 현재 Developer Preview로 안내하며 프로그램 참여를 전제로 한다. Gmail 구성 문서 · Drive 구성 문서

직접 만든 MCP 서버가 뒤에서 Google REST API를 호출하는 구조까지 이번 공식 서버의 차단 일정이 그대로 적용된다고 단정할 수는 없다. 연결 설정의 서버 주소와 실제 OAuth 경로를 확인해야 한다. 서비스 이름에 ‘Gmail’이 있다는 이유만으로 영향을 판정하지 않는 것이 좋다.

기존 클라이언트 수정과 새 클라이언트 분리를 나눈다

Google Auth Platform의 Clients에서 현재 쓰는 클라이언트를 찾은 뒤 다음과 같이 판단한다.

에이전트 전용이고 설정을 바꿀 수 있다: 기존 클라이언트에서 에이전트용 체크박스를 선택한다.

기존 클라이언트에서 설정을 바꿀 수 없다: 에이전트용으로 표시한 새 클라이언트가 필요하다.

사람이 쓰는 웹·모바일 기능과 에이전트가 같은 클라이언트를 공유한다: 에이전트용 클라이언트를 별도로 만들고, 기존 클라이언트는 일반 기능에 남긴다.

Google의 클라이언트 관리 문서는 혼합 앱에서 두 신원을 분리하도록 요구한다. 에이전트 트래픽에 적용한 관리 정책 때문에 일반 로그인까지 함께 영향을 받지 않도록 하기 위한 구분이다. 체크박스는 에이전트라는 선언이며, 추가 데이터 권한을 주는 기능은 아니다. OAuth 범위, 사용자 동의, 앱 검증 요건은 계속 적용된다. 클라이언트 분리와 권한의 의미

서비스 계정과 Apps Script에는 같은 처방을 쓰지 않는다

11월 5일 갱신된 Gmail 구성 문서의 문제 해결 절은 인증 방식별 차이를 명확히 설명한다.

도메인 전체 위임을 사용하는 서비스 계정은 Google Auth Platform의 일반 OAuth 클라이언트처럼 체크박스를 고르는 대상이 아니다. 이 방식의 MCP 요청은 표시 누락을 이유로 거부되지 않으며, Workspace 관리자의 도메인 전체 위임 설정으로 접근을 관리한다. 민감한 도구 호출에 대한 사람의 확인 절차도 유지된다. 따라서 일반 OAuth 전환 문제를 피하려고 광범위한 위임을 새로 부여하는 것은 적절한 대응이 아니다.

Apps Script의 기본 OAuth 클라이언트에는 해당 표시를 할 수 없다. 표준 Google Cloud 프로젝트를 연결해도 마찬가지다. MCP 호출에는 별도로 만든 에이전트용 OAuth 클라이언트와 OAuth2 for Apps Script 라이브러리를 사용하고, ScriptApp.getOAuthToken() 대신 그 라이브러리에서 받은 액세스 토큰을 보내도록 안내한다. Workspace MCP를 호출하지 않는 스크립트는 이 변경의 영향을 받지 않는다. Gmail 인증 방식별 문제 해결

전환 완료는 설정 저장보다 실제 호출로 판단한다

다음은 공식 설정 절차를 운영 배포에 적용하기 위한 권장 검증 순서다.

사용 경로를 목록화한다. 개발·스테이징·운영마다 MCP 주소, 인증 방식, 클라이언트 식별자, 설정 소유자를 기록한다. 비밀값이나 액세스 토큰은 점검 문서에 복사하지 않는다.

혼합 사용 여부를 찾는다. 동일 클라이언트를 쓰는 일반 로그인, 백그라운드 작업, 에이전트 호스트가 있는지 확인한다. 일부 서버만 바뀌는 상황을 피하도록 배포 설정도 함께 점검한다.

필요한 경로만 전환한다. 새 클라이언트가 필요한 경우 호스트 설정과 리디렉션 URI를 맞추고, 해당 호스트가 지원하는 인증 절차를 완료한다. 이전 토큰을 새 클라이언트에서 그대로 재사용할 수 있다고 가정하지 않는다.

테스트 계정의 읽기 작업부터 확인한다. Drive의 테스트 문서 검색·읽기처럼 결과를 예측할 수 있는 작업을 사용한다. 실제 데이터 변경 작업은 별도로 검토한다.

일반 기능도 회귀 검사한다. 에이전트 MCP 호출과 기존 REST 기능을 각각 확인한다. 거부가 계속되면 Workspace 관리자와 OAuth 로그를 확인하고, 현재 배포가 어느 클라이언트를 사용하는지 대조한다.

Drive 문서는 인증 상태 확인, 도구 목록 확인, 실제 파일 검색·읽기 검증을 별도 단계로 제시한다. 이 순서를 따라가면 ‘콘솔에서는 바꿨는데 운영은 옛 설정을 쓴다’는 문제를 줄일 수 있다. 새 클라이언트가 필요한 상황에서는 이전 설정으로 되돌리는 것만으로 차단 원인이 해결되지는 않는다. Drive 연결·호출 검증

에이전트 표시 뒤에도 데이터 보호는 남는다

클라이언트 분리는 프롬프트 주입 방어를 대신하지 않는다. Google은 Workspace MCP에서 프롬프트와 응답의 악성 내용 검사를 요구한다. Model Armor를 쓰거나, 자체 방식을 쓰는 경우 위험을 문서화해 사용자가 이를 수용하도록 안내해야 한다. Model Armor 로깅을 켜면 전체 페이로드가 기록될 수 있고, 지원 지역에 따른 라우팅이 데이터 거주 요건에 영향을 줄 수 있다는 점도 확인해야 한다. 연결을 복구하는 과정에서 메일·문서 본문을 디버그 로그에 무심코 남기지 않도록 한다. Workspace MCP 보안 구성

이번 점검의 완료 기준은 에이전트 전용 신원으로 실제 MCP 읽기 호출이 성공하고, 일반 기능은 기존 경로에서 정상 동작하는지다. 11월 11일 요청 거부 시작과 12일 기존 클라이언트의 전환 경계를 함께 기록해 두면, 장애 뒤에 인증 설정을 처음 찾아보는 일을 줄일 수 있다.

확인 범위

2026년 11월 9일 공식 공개 릴리스 노트와 설정·보안 문서를 기준으로 작성했다. 실제 Google Cloud 설정 변경, OAuth 클라이언트 생성, 권한 부여, MCP 호출과 과금 테스트는 수행하지 않았다. 위 검증 순서는 도입 체크리스트이며 특정 운영 환경에서의 성공을 보장하지 않는다.