Chrome 웹스토어 사용자 데이터 정책 강화: 확장 프로그램 운영자의 대응

Google은 2026년 7월 1일 Chrome 웹스토어 개발자 프로그램 정책 업데이트를 발표했고, 변경 정책의 집행을 2026년 8월 1일 시작한다고 밝혔다. 사용자 데이터를 수집하는 확장 프로그램은 이제 공개한 단일 목적에 엄격히 필요한 데이터만 수집해야 하며, 설치 이후 데이터 처리 방식이 달라지면 사용자에게 그 변화를 적극적으로 알려야 한다. 한국 운영자에게 필요한 대응은 개인정보처리방침 문구만 고치는 일이 아니다. 권한, 코드, 서버 로그, 분석 SDK, 지원 절차가 실제 단일 목적과 일치하는지 제품 전체를 다시 확인해야 한다.

확인된 사실: 공식 발표는 Limited Use 정책의 데이터 수집 기준과 Disclosure Requirements의 고지 기준을 강화했으며, 위반 확장 프로그램은 집행 대상이 될 수 있다고 명시한다.

POEMORA 해석: 한국 개인정보보호법 준수 여부는 별도 법률 검토가 필요하지만, 웹스토어 심사와 국내 이용자 신뢰를 함께 지키려면 ‘수집 가능 여부’보다 ‘그 데이터가 공개한 핵심 기능에 반드시 필요한가’를 먼저 증명해야 한다.

2026년 7월 발표에서 실제로 바뀐 것

사실. Google 발표에 따르면 확장 프로그램이 수집하는 모든 사용자 데이터는 공개된 단일 목적에 엄격히 필요해야 한다. 다른 목적을 위한 수집은 금지된다. 모든 데이터 수집은 단일 목적과 밀접한지와 무관하게 눈에 띄게 고지해야 하며, 설치 후 데이터 처리 관행이 달라지는 경우에도 사용자가 알 수 있도록 적극적으로 고지해야 한다.

사실. 단일 페이지 정책 문서는 확장 프로그램이 공개된 단일 목적에 필요한 데이터만 수집·사용·전송할 수 있고, 기능 유지·보안·성능 및 신뢰성 측정 같은 관련 운영 목적을 포함할 수 있다고 적는다. 브라우징 활동의 수집과 사용은 웹스토어 페이지와 제품 UI에 명확히 설명된 사용자 대면 기능에 필요한 범위를 제외하면 금지된다.

사실. 정책은 원시 데이터뿐 아니라 집계·익명화·비식별·파생 데이터와 스크래핑 등 자동 수집 데이터에도 제한을 적용한다. 데이터의 개인 맞춤 광고 사용, 데이터 브로커나 광고 플랫폼 등에 판매·이전하는 행위도 금지 범주로 설명한다.

단일 목적을 기능 문장과 데이터 표로 고정한다

“생산성 향상”, “더 나은 경험”처럼 넓은 표현은 어떤 데이터든 정당화하는 빈 문장이 될 수 있다. 운영자는 확장 프로그램이 사용자에게 제공하는 핵심 기능을 한 문장으로 좁히고, 각 데이터 필드가 그 기능에 왜 필요한지 연결해야 한다.

예를 들어 ‘현재 보고 있는 주문 페이지에서 배송 상태를 조회한다’가 단일 목적이라면 전체 브라우징 기록, 모든 탭의 URL, 주소록 접근은 정당화하기 어렵다. 현재 사이트의 주문 번호를 읽는 권한, 상태 조회 API 호출, 오류 진단을 위한 제한된 이벤트처럼 직접 필요한 항목만 남기는 식이다. 장래 기능을 위해 미리 넓은 권한을 요청하는 접근도 공식 정책의 최소 권한 원칙과 충돌할 수 있다.

권장 데이터 표에는 다음 항목을 둔다.

이 표에서 목적 연결을 설명하지 못하는 필드는 제거하거나 로컬 처리로 바꿀 후보가 된다. 확장 프로그램과 연결 서버의 데이터 흐름을 함께 정비하려면 자동화 서비스 설계에서 최소 권한과 감사 범위를 먼저 정의할 수 있다.

고지는 설치 전과 변경 시점에 모두 필요하다

공식 Disclosure Requirements는 사용자 데이터를 처리하는 제품이 설치 전에 수집 데이터와 사용 방식을 눈에 띄게 공개하고, 사용자의 적극적이고 충분한 설명에 근거한 동의를 받아야 한다고 적는다. 설치 후 서로 다른 데이터 관행을 도입하면 그 변경도 눈에 띄게 알려야 한다.

POEMORA 해석. 웹스토어 설명, 권한 요청 직전 UI, 확장 프로그램 설정, 개인정보처리방침이 서로 다른 말을 하면 위험하다. 새 분석 SDK나 AI 요약 기능을 추가하면서 서버 전송 필드가 바뀐다면 릴리스 노트만 남길 것이 아니라, 변경 내용과 선택권을 사용자 여정에서 확인할 수 있어야 한다. 기존 동의가 새 목적까지 자동으로 포괄한다고 가정하지 말아야 한다.

고지 검토에서는 실제 네트워크 요청을 기준으로 역검증한다. 문서에 적힌 수집 목록에서 코드를 보는 것만으로는 누락된 SDK 이벤트를 찾기 어렵다. 테스트 계정으로 설치부터 핵심 기능, 오류, 고객지원까지 실행하고 전송 호스트와 페이로드를 캡처해 고지 문서와 비교한다.

위탁사와 사람의 데이터 열람 경로를 다시 본다

Limited Use 정책은 제3자 이전을 단일 목적 제공·개선에 필요한 경우, 법률 준수, 악성 행위 방지 등의 제한된 상황으로 설명한다. 사람의 사용자 데이터 열람도 구체적 데이터에 대한 명시적 동의, 법률상 요건, 보안 조사 등 열거된 조건 안에서 다뤄야 한다.

운영자는 오류 추적, 제품 분석, 고객지원, 클라우드 저장소, AI API를 각각 별도 수신자로 목록화해야 한다. 위탁사가 원시 URL과 페이지 내용까지 받는지, 자체 학습이나 광고에 쓰는지, 보존 기간과 삭제 API가 무엇인지 확인한다. 고객지원 담당자가 편의를 위해 전체 로그를 열람하는 관행도 역할 기반 접근과 승인 기록으로 제한해야 한다.

POEMORA 해석. “익명화했으니 자유롭게 쓸 수 있다”는 가정은 이 정책 대응에 맞지 않는다. 공식 정책은 집계·익명화·비식별·파생 데이터에도 요구사항이 적용된다고 밝힌다. 데이터 변환 전후의 목적, 재식별 가능성, 수신자를 함께 검토해야 한다.

집행 이후 운영 점검표

1. 웹스토어의 단일 목적 문장을 현재 제품 기능과 일치시킨다.
2. manifest 권한을 기능별로 매핑하고 사용하지 않는 권한을 제거한다.
3. 브라우징 활동과 페이지 내용 수집을 가장 먼저 재검토한다.
4. 모든 네트워크 목적지와 전송 필드를 동적 테스트로 확인한다.
5. 스토어 설명, 제품 UI, 개인정보처리방침의 고지 내용을 맞춘다.
6. 데이터 변경 릴리스에 고지·동의·롤백 검토를 필수 승인으로 둔다.
7. 위탁사의 사용 목적, 보존, 재위탁, 삭제 지원을 계약과 설정에서 확인한다.
8. 심사 연락을 받을 개발자 계정 이메일과 이의 제기 자료를 최신 상태로 유지한다.

집행 위험만 피하려고 표현을 넓히는 것은 반대 방향이다. 기능을 좁게 정의하고 실제 데이터 수집을 더 작게 만드는 것이 심사 대응과 개인정보 위험을 동시에 줄인다. 발표일과 집행일을 구분하고, 현재 정책 페이지의 문구가 이후 변경될 수 있으므로 검토 날짜와 캡처한 증거를 릴리스 기록에 남겨야 한다.

정책 준수와 국내 법 준수를 분리해 관리한다

Chrome 웹스토어 정책을 충족했다고 해서 국내 개인정보 관련 의무가 자동 충족되는 것은 아니다. 반대로 국내 개인정보처리방침이 존재한다고 웹스토어의 단일 목적·최소 권한·변경 고지 요구가 자동 충족되는 것도 아니다. 제품 정책 심사, 국내 법률, 고객과의 계약을 별도 열로 관리하고 하나의 데이터 흐름표에서 교차 확인해야 한다.

POEMORA 해석. 가장 유지하기 쉬운 증거 묶음은 단일 목적 문장, 권한-기능 매핑, 데이터 필드 표, 위탁사 목록, 설치 전 고지 화면, 변경 고지 기록, 실제 네트워크 테스트 결과다. 이 묶음을 릴리스마다 갱신하면 정책 문구가 바뀌어도 영향을 빠르게 비교할 수 있다.