이 소식은 무엇인가요?
배경부터 차근차근 살펴보기
OAuth를 사용해 외부 서비스와 통합할 때, 장시간 유효한 refresh token이 필요하다. 그러나 이 토큰이 인포스틸러 악성코드에 의해 탈취되거나 네트워크에서 가로채지면 공격자가 사용자 대신 오랫동안 행동할 수 있다. 특히 자동화 시스템이나 AI 에이전트처럼 24시간 운영되는 환경에서 이 위험은 더 크다.
Google이 DPoP(Demonstrating Proof-of-Possession)를 OAuth Platform에 추가했다. DPoP는 refresh token을 특정 클라이언트의 공개키에 암호화적으로 묶어서, 그 토큰을 다른 환경에서 사용하지 못하게 한다. Access token은 기존 Bearer 토큰 방식을 유지하므로 성능 오버헤드가 없다.
Google Cloud의 Secure Token Service(STS)를 사용하면 멀티에이전트 워크로드에서 여러 에이전트 간 안전하게 토큰을 위임할 수 있다. 한 에이전트가 받은 Google Drive 접근 토큰을 다른 에이전트에게 넘길 때, STS가 수신 에이전트 전용 토큰을 발급하므로, 위임된 토큰이 탈취되어도 발급자를 사칭할 수 없다.
이 발표는 기술 리더와 자동화 담당자에게 기존의 '토큰을 안전하게 보관하는 방법'이라는 오래된 고민에 새로운 기술적 해결책을 제시한다. 동시에 AI 교육자들에게는 AI 시스템이 외부 계정에 안전하게 접근하는 원리와 발전 과정을 설명할 근거가 된다.
공식 발표에서 확인된 내용
구체적으로 무엇이 달라졌나
- 01
DPoP는 refresh token을 클라이언트의 공개키에 암호적으로 결합시켜, 토큰이 탈취되거나 가로채져도 다른 환경에서 사용되지 않도록 방어한다.
- 02
Infostealer 악성코드(브라우저나 메모리에서 저장된 토큰을 훔치는 공격)와 중간자(MITM) 공격이 무력화된다.
- 03
Access token은 기존 Bearer 토큰 방식을 유지하므로, 짧은 수명의 토큰에는 높은 QPS(초당 쿼리) 오버헤드가 발생하지 않는다.
- 04
Google Cloud STS를 통해 멀티에이전트 워크로드에서 안전하게 토큰을 위임할 수 있으며, 위임된 토큰은 수신 에이전트의 공개키에만 유효하다.
- 05
선택적 기능이므로 기존 OAuth 통합은 그대로 동작하며, 보안이 필요한 경우에만 활성화 가능하다.
사용자에게 미치는 영향
누구에게 어떤 의미가 있나
AI 에이전트나 자동화 시스템을 운영하는 기술 리더
장시간 실행되는 에이전트가 Google 서비스에 접근할 때 토큰 탈취 위험이 낮아지며, 여러 에이전트 간 권한 위임이 더 안전해진다. Google Cloud와 이를 통합하는 아키텍처를 재설계하거나 보안 정책을 업데이트할 때 이 기능 적용 여부를 판단해야 한다.
AI 리터러시 교육자나 업무자동화 컨설턴트
클라이언트에게 'AI 시스템이 외부 계정에 안전하게 접근하는 방법'을 설명할 때, 새로운 보안 옵션을 근거로 제시할 수 있다. 강의 자료나 컨설팅 보고서에 토큰 보안의 발전 과정을 추가할 수 있다.
Google Cloud를 사용해 자동화 시스템을 구축하는 개발팀
DPoP 지원 추가로 기존의 'refresh token을 안전하게 보관하고 위임하는 방법'에 대한 기술적 해결책을 갖게 된다. 새로운 프로젝트나 기존 시스템의 보안 업그레이드 시에 고려할 수 있다.
실제 활용 장면
어디에 어떻게 써볼 수 있나
멀티에이전트 AI 시스템에서 안전한 권한 위임
여러 AI 에이전트가 협력하면서 한 에이전트가 다른 에이전트에게 Google Drive나 Gmail 접근 권한을 줘야 할 때, STS를 통해 토큰을 위임할 수 있다. 이 과정에서 DPoP가 적용되면 각 에이전트는 자신에게 주어진 토큰만 사용할 수 있고, 토큰이 탈취되어도 다른 에이전트를 사칭할 수 없다.
- 예를 들면
- 에이전트 A(데이터 수집)가 받은 Google Drive 토큰을 에이전트 B(분석)에게 넘길 때, STS에서 B 전용으로 새 토큰을 발급한다. 이 토큰은 B의 공개키로만 유효하다.
- 확인할 결과
- 에이전트 B가 Google Drive에 접근할 수 있지만, 그 토큰은 다른 에이전트나 공격자가 가로챠도 사용할 수 없다.
장시간 실행되는 자동화 시스템의 토큰 보안
업무 자동화 시스템이 야간 시간에 지속적으로 Google Sheets를 업데이트하거나 Gmail에서 데이터를 수집할 때, refresh token이 서버 메모리나 캐시에 오래 남아 있다. DPoP를 적용하면, 그 토큰이 서버 침해로 탈취되어도 공격자가 사용할 수 없다.
- 예를 들면
- 야간 배치 작업이 매시간 Google Sheets를 쿼리한다. 이 작업의 refresh token을 DPoP로 보호하고, 서버의 공개키를 Google에 등록해 두면, 서버가 침해되어 토큰이 탈취되어도 그 토큰은 등록된 공개키가 있는 환경에서만 유효하다.
- 확인할 결과
- 자동화 시스템의 Google 계정 침해 위험이 줄어들고, 규정 준수(compliance) 요구사항을 더 충족할 수 있다.
공개 인터넷 노출 자동화 서버의 보안 강화
API 게이트웨이나 웹훅으로 노출된 자동화 서버가 Google 서비스에 접근할 때, 서버 자체가 공격 대상이 될 수 있다. 토큰이 메모리에서 읽혀도 DPoP가 적용되면 다른 서버에서 그 토큰으로 행동할 수 없다.
- 예를 들면
- Webhook 서버가 공개 IP에서 돌면서 Google Drive와 동기화한다. 이 서버의 refresh token을 DPoP로 보호하면, 서버가 해킹되어 토큰이 노출되어도, 공격자는 그 토큰으로 다른 곳에서 Google Drive에 접근할 수 없다.
- 확인할 결과
- 토큰 탈취 시에도 2차 피해(token reuse)를 방지할 수 있어, 보안 침해 대응 시간을 확보할 수 있다.
직접 적용해 보기
처음부터 무리하지 말고, 이 순서로 확인하세요
Google Cloud 공식 문서에서 DPoP 요구사항 확인
DPoP는 OAuth 표준이지만, Google에서 어떤 SDK 버전, 프로젝트 설정, API 활성화가 필요한지 확인해야 한다. Google Developers 블로그의 링크를 따라 공식 문서를 읽어서 적용 범위와 선행 조건을 파악한다.
확인: 'DPoP는 모든 Google API에서 지원되는가', '어느 SDK 버전부터 지원되는가', '프로젝트 수준의 설정이 필요한가', '비용 추가가 있는가' 네 가지를 메모한다.
현재 Google OAuth 통합 인벤토리 작성
자신의 조직이나 프로젝트에서 Google OAuth를 사용하는 곳을 모두 나열한다. 특히 refresh token을 저장하거나 오래 유지하는 통합(자동화, 에이전트, 배치 작업, 웹훅)을 구분한다.
확인: 목록에 각 통합의 목적, 현재 토큰 저장 방식(메모리, 데이터베이스, 파일), 보안 위험도(인터넷 노출 여부, 데이터 민감도), 예상 구현 난이도를 함께 기록한다.
프로토타입이나 테스트 환경에서 DPoP 시도
프로덕션 적용 전에 개발 또는 테스트 프로젝트에서 DPoP를 활성화하고, 기존 코드와 호환되는지, 에러나 성능 저하가 있는지 확인한다. Google의 샘플 코드나 마이그레이션 가이드가 제공되는지도 함께 확인한다.
확인: 테스트 환경에서 'DPoP 활성화 전후 API 응답 시간 변화', '코드 변경 범위(몇 줄?)', '발생한 에러와 해결 방법', 'Bearer 토큰 방식과의 호환성' 네 가지를 기록한다.
팀이나 조직의 보안 정책에 토큰 보호 요구사항 추가
DPoP가 새로운 옵션이 되었으므로, '장기간 유효한 토큰을 사용하는 시스템은 DPoP 또는 동등 수준의 토큰 바인딩을 적용할 것' 같은 정책을 추가한다. 이는 새 프로젝트나 기존 시스템 업그레이드 시 기준이 된다.
확인: 정책 문서에 '어떤 통합이 DPoP 적용 대상인가(기준: 토큰 수명이 24시간 이상? 외부 인터넷 노출?)', '기한을 정해 적용 일정을 언제인가' 두 항목을 명시한다.
적용 일정과 우선순위 결정
전체 통합 중에서 보안 위험도가 높고 기술적 난이도가 낮은 것부터 단계적으로 DPoP를 적용한다. 예를 들어, 공개 인터넷에 노출된 자동화 서버부터 시작한다.
확인: 적용 우선순위 목록을 작성하고, 각 항목의 예상 구현 기간(일 수), 테스트 기간, 의존성(다른 시스템과의 연계)을 기록한다. 첫 번째 항목부터 시작해 2주 안에 결과를 검토한다.
해석할 때 주의할 점
확인된 범위와 아직 모르는 내용을 구분하세요
공식 발표에서 확인된 사실: Google OAuth Platform이 DPoP를 지원하기 시작했으며, refresh token을 클라이언트의 공개키에 암호적으로 결합시켜 인포스틸러와 MITM 공격을 방어한다. Access token은 기존 Bearer 방식이며, Google Cloud STS를 통해 멀티에이전트 워크로드에서 안전하게 토큰을 위임할 수 있다. 원문에서 명시된 기술 메커니즘과 사용 목적은 신뢰할 수 있다. 아직 공개되지 않았거나 확인이 필요한 내용: 모든 Google API에서 지원되는지 여부(예: Google Sheets API, Gmail API 각각), SDK별 지원 버전과 마이그레이션 경로, 비용 추가 여부, 실제 구현 시 성능 오버헤드 측정값, 기존 Bearer 토큰 통합과의 호환성 정책, STS 위임의 체인 깊이 제한, 위임 시마다 발생하는 비용 구조.
- 원문은 DPoP의 기술 개요와 보안 이점을 설명하지만, 실제 구현에 필요한 SDK 버전별 지원, API별 적용 범위, 비용 추가 여부, 마이그레이션 경로는 상세하지 않다.
- Google Cloud STS를 통한 멀티에이전트 토큰 위임은 언급되었지만, 실제 사용 시나리오에서의 제한 사항(예: 위임 깊이 제한, 위임 시마다 비용 발생 여부)이 명확하지 않다.
- DPoP는 선택적 기능이므로, 기존 시스템이 자동으로 보호되지 않는다. 각 팀이 주도적으로 적용해야 하고, 이는 조직 내 보안 정책 수립과 수평적 조율을 요구한다.
- 공개 자료만으로는 Google이 다른 클라우드 제공자(AWS, Azure)의 유사 기능(예: AWS 일시 보안 자격증, Azure Managed Identity)과 비교해 어떤 위치에 있는지, 업계 표준 채택 속도는 어떤지 판단하기 어렵다.
- 토큰 바인딩 기술 자체는 새로운 것이 아니며(OWASP, IETF에서 이미 논의), Google의 구현이 얼마나 완전하고 다른 플랫폼의 것과 호환되는지는 추가 검증과 커뮤니티 피드백이 필요하다.
출처와 확인일
원문에서 다시 확인하기
이 글은 Google Developers Blog의 공식 발표를 바탕으로 정리했습니다. 기능 범위와 제공 조건은 바뀔 수 있으므로 실제로 적용하기 전에는 원문을 다시 확인해 주세요.
- 마지막 확인
- 2026-10-16
- 다음 검토
- 2026-11-15