중국을 위한 Firebase 솔루션: ICP, PIPL, 그리고 '작동하게 만들기'가 실제로 필요로 하는 것

귀사 팀이 Firebase를 중국 본토에서 작동하게 만들 방법을 찾고 있다면, 문제가 실제로 무엇인지 분명히 하는 것이 유익합니다. 반사적 반응은 그것을 성능 문제로 다루는 것입니다 — Google 서버로 가는 더 빠른 경로를 찾으면 문제가 사라진다고. 사라지지 않습니다. 장애물은 애초에 거리가 아니었기 때문입니다. Firebase는 Google Cloud 위에 구축된 Google 서비스이고, Google Cloud는 중국 본토 안에 리전도 별도의 국내 파티션도 운영하지 않습니다 — 그래서 애초에 속도를 높일 국경의 중국 쪽 Firebase 엔드포인트가 없습니다. 진정한 해법이 매듭지어야 할 것은 두 라이선싱 질문입니다: 공개 앱이 중국의 ICP 제도 아래 비안될 수 있는지, 그리고 귀사 중국 사용자의 개인 데이터가 어디에 사는 것이 허용되는지. 도달 가능성은 중요하지만, 그것은 둘의 하류에 있습니다.

한눈에 보는 중국 본토에서의 Firebase

도달 가능성은 실재합니다 — 그래도 관문은 아닙니다

이 중 어느 것도 도달 가능성이 상상의 산물이라는 뜻은 아닙니다. Firebase는 Google의 네트워크에서 서비스하도록 만들어졌고, 그 네트워크는 본토의 가장자리에서 멈춥니다: Google의 엔드포인트는 중국 안에서 일상적으로 걸러지거나 불안정하며, 일부 Firebase 기능은 본토 폰이 지니지 않은 Google 기기 계층을 기대합니다. Firebase 자신의 Android 가이드는 메시징 클라이언트가 “that also have the Google Play Store app installed” 핸드셋에서 돌아가도록 요구합니다 — 본토의 많은 곳에서 판매되는 폰이 없이 출하되는 스토어 — 그래서 푸시와 그 위에 구축된 기능은, 네트워크가 어떻게 배치되든, 끝내 발화하지 않을 수 있습니다.

그러나 도달 가능성은 오도하는 절반입니다. 즉시 반환하는 Firebase 호출도, 귀하가 그 대상을 서비스하는 곳에서 그들을 서비스하도록 허용되었는지에 대해서는 아무것도 말하지 않습니다. 그 허가는 두 개의 별개 관문이며, 어느 것도 속도 문제가 아닙니다.

관문 하나 — 공개 앱과 그 ICP 비안

관문 하나는 앱을 애초에 보여 줄 허가에 관한 것입니다. 본토 사용자를 겨냥한 공개 웹사이트나 앱은 국무원령 제292호와 공업정보화부령 제33호에 따라 ICP 비안(备案)을 지녀야 하며, 그 기록은 역외 Firebase 스택이 중국 쪽에 가지지 않은 두 가지에 닻을 내립니다: 본토 안에 물리적으로 있는 호스팅 자원과, 그 뒤의 본토 법인. Firebase의 호스트는 Google Cloud의 역외 리전입니다 — Google은 “43 global regions and 130 zones”를 게시하며, 본토에 가장 가까운 것이 홍콩과 타이완입니다 — 그래서 비안이 지명할 국내 대상이 없습니다. 앱은 완벽히 도달 가능하면서도 거기 있을 라이선스를 전혀 보유하지 않을 수 있으며, Google로 가는 더 빠른 경로가 그것을 바꾸지 않습니다.

관문 둘 — PIPL 아래 귀사 중국 사용자의 데이터

관문 둘은 데이터에 관한 것입니다. 귀사 기록이 물리적으로 어디에 앉는지는 데이터베이스를 생성하는 순간 결정됩니다: Firebase는 귀하가 “must choose a location for the instance”라고 요구하고, “once you provision a database instance, you cannot change its location setting”이라 경고합니다. Firebase가 제공하는 모든 위치가 본토 밖이므로, 귀사 중국 사용자의 개인정보는 첫 가입부터 역외에 저장됩니다 — 그리고 본토 거주자의 개인 데이터를 국경 너머로 옮기는 것은 국경 간 이전입니다. 중국 개인정보 보호법은 그것에 조건을 붙입니다: 고지, 별도 동의, 그리고 승인된 이전 메커니즘 하나(제38~43조). 핵심정보인프라 운영자나 규제된 분량을 넘는 취급자의 경우, 데이터가 애초에 본토에 머물러야 할 수 있습니다(PIPL 제40조, 사이버보안법 제39조(구 제37조)와 함께). 이 중 어느 것이 어떻게 구속하는지는 귀하의 역할과 숫자에 달려 있습니다 — 기본 설정이 아니라 법률 자문의 판단.

중국을 위한 진정한 Firebase 솔루션은 어떤 모습인가

속도 다이얼이 아니라 두 관문으로 틀을 잡으면, 정직한 해법 집합은 짧아집니다 — 그리고 그중 어느 것도 Google에 닿는 더 빠른 방법이 아닙니다.

Firebase를 글로벌 오리진으로 유지하십시오. 본토 밖 사용자에게는 아무것도 바꿀 필요가 없습니다; Firebase는 훌륭한 글로벌 백엔드입니다. 중국 작업은 가산적입니다: 귀사 본토 대상이 보는 경험 앞에 규정에 맞는, ICP 비안 거점을 본토 안에 세워, 공개 앱이 비안될 국내 토대를 갖게 하면서 귀사 오리진은 오늘 돌아가는 바로 그 자리에 머뭅니다.

Google 의존 조각은 그 나름의 방식으로 다루십시오. Google의 기기 계층에 기대는 Firebase 부분 — Cloud Messaging과 Google Play services 위에 구축된 모든 것 — 은, 네트워크가 어떻게 배치되든 대부분의 본토 사용자가 지닌 핸드셋에 안정적으로 닿지 못합니다. 그 특정 기능에 대한 지속 가능한 답은, 나머지 Firebase 코드는 손대지 않은 채, 그 하나의 역량에 대한 국내 대체(예: 본토 푸시 서비스)입니다. 대신 전면 교체를 저울질하고 있다면, 동반 글 중국을 위한 Firebase 대안이 후보 백엔드 전반에 걸쳐 이 같은 두 관문을 짚습니다.

출시하기 전에 중국 사용자의 데이터가 어디에 살 수 있는지 결정하십시오. Firestore 위치는 생성 시 설정되고 나중에 옮길 수 없으므로, 데이터 레지던시는 앞서 매듭짓는 것이 가장 저렴합니다: 일부 앱에는 PIPL 이전 메커니즘과 함께 역외 저장이 방어 가능하고; 다른 경우 — CIIO, 또는 대량 취급자 — 데이터가 본토에 머물러야 합니다. 그것은 콘솔에 맡길 수 있는 기본값이 아니라 법적 판단입니다.

이것은 판결이 아니라 리스크 지도입니다: 어느 관문이 얼마나 세게 구속하는지는 귀사 앱이 무엇을 하는지, 얼마나 많은 개인 데이터를 보유하는지, 그리고 이용자가 누구인지에 달려 있습니다 — 그 주위에 구축하기 전에 법률 자문과 함께 매듭지을 가치가 있습니다.

21YunBox가 들어맞는 자리 — 마이그레이션이 아니라 규정에 맞는 오버레이

Firebase를 글로벌 오리진이자 진실의 원천으로 유지하십시오. 그것이 중국 본토에 남기는 격차는 귀하가 튜닝으로 없앨 수 있는 것이 아닙니다 — 그것은 Google의 네트워크가 결코 지니도록 만들어지지 않은, 허가받은 국내 거점입니다. 그것이 저희가 더하는 조각입니다: 규정에 맞는, 본토 안에서의 ICP 비안 전송을, 귀하가 이미 운영하는 Firebase 오리진 앞에 세워, 재구축도, 병렬 중국 코드베이스도, Firebase에서의 이동도 없습니다. 저희 중국 팀은 귀사 법인과 데이터 양에 어느 관문이 구속하는지 파악하고, 국내 호스트에 대한 ICP 비안을 맡으며, 방문자·사용자 데이터가 국경에서 어떻게 취급되는지 설계하여 PIPL 질문이 귀하가 방어할 수 있는 답을 갖게 합니다. 기능이 Google의 기기 계층에 의존하는 경우, 저희는 앱을 그 주위로 재구축하기보다 그 한 조각에 대한 국내 대체를 계획하도록 돕습니다.

컴플라이언스 진단 받기 →

함께 읽기:

• 중국 ICP 라이선스란 무엇이며, 어떻게 받나요?
• PIPL상의 국경 간 데이터 이전
• 중국을 위한 Firebase 대안: 두 컴플라이언스 관문