MySQL은 중국에서 작동하나요? 데이터 레지던시, 현지화 & PIPL 국경 간
MySQL은 귀사가 어디서든 — 중국 본토 땅을 포함해 — 자가 호스팅하는 무료 오픈소스 소프트웨어이므로, 엔진은 레지던시 중립적이고 결코 차단되지 않습니다. 진짜 질문은 귀사가 그것을 어디서 돌리는가입니다: 해외나 비중국 리전 관리형 MySQL은 귀사 중국 사용자의 레코드를 해외에 두는, PIPL 국경 간과 데이터 현지화 노출입니다. MySQL과 중국 데이터 레지던시를 컴플라이언스 우선으로 살핍니다.
MySQL은 중국에서 작동하나요?
MySQL은 중국에서 차단되지 않고 잘 돕니다 — 그래서 진짜 질문은 데이터 레지던시 질문입니다: 그것이 쥐는 개인정보가 어디에 쉬도록 허용되는가.
MySQL은 귀사가 내려받아 직접 돌리는 무료 오픈소스 소프트웨어(GPL 라이선스, Oracle 소유)이고, 그것이 엔진을 레지던시 중립적으로 만듭니다 — 귀사는 그것을 중국 본토 땅에 자가 호스팅할 수 있고, 그것이 합법적 레버입니다. 노출은 배포입니다: 글로벌 클라우드 리전(Amazon RDS와 Aurora, Azure Database for MySQL, Google Cloud SQL)이나 어떤 비중국 리전의 관리형 MySQL은 귀사 중국 사용자의 개인 데이터를 해외에 둡니다 — 모든 읽기와 쓰기마다 PIPL이 규율하는 국경 간 이전. 핵심정보인프라 운영자나 고물량 취급자에게, 그 데이터는 본토에 머물러야 하고(사이버보안법 제39조, 구 제37조; PIPL 제40조), 어떤 해외 데이터베이스도 그것을 충족 못 합니다. 국내 관리형 MySQL은 존재하지만, 오직 별도 소버린 클라우드(Sinnet과 NWCD를 통한 AWS China, 21Vianet을 통한 Azure China, Alibaba Cloud ApsaraDB)에서만 — 국내 리전은 자동 컴플라이언스가 아닙니다.
이는 리스크 지도이지 판결이 아닙니다 — 귀사 의무는 귀사 법인, 귀사 데이터 물량, 그리고 귀사가 누구의 데이터를 쥐는지에 달렸습니다. 저희 중국 팀이 귀사 노출을 매핑할 수 있습니다 →
컴플라이언스 스냅샷
- ! MySQL은 중국에서 잘 돎 — 귀사가 그것을 어디서 돌리는가가 컴플라이언스 질문
- ✕ 해외나 비중국 리전 MySQL은 귀사 중국 데이터를 본토 밖에 둠
- ! 중국 사용자의 레코드가 해외 = PIPL 국경 간 이전(제38~40조)
- ! CIIO / 고물량 취급자는 어떤 해외 DB도 충족 못 하는 국내 저장을 짐
- ! 소버린 국내 관리형 MySQL이 존재(AWS/Azure/Alibaba China) — 별도 클라우드
- ✓ MySQL을 국내에서 돌림 + ICP 비안된 인프라로 전송 — 마이그레이션 없이
MySQL 공식 문서가 중국에 대해 말하는 것
| 사실 | 1차 출처 |
|---|---|
| MySQL은 귀사가 직접 돌리는 무료 오픈소스 소프트웨어입니다 — 그래서 엔진은 차단된 것이 아니라 레지던시 중립적입니다. 그 자신의 표현으로, "MySQL Community Edition is the freely downloadable version of the world's most popular open source database," 이고 "available under the GPL license" 이며 "over 20 platforms and operating systems including Linux, Unix, Mac and Windows" 에서 돕니다. 귀사가 선택하는 어디서든 서버를 내려받아 설치하므로, 귀사는 MySQL을 중국 본토 인프라에 자가 호스팅할 수 있습니다 — 중국 데이터를 중국 땅에 두는 합법적 레버. | MySQL Community Edition — mysql.com, 2026-10-10 열람 |
글로벌 클라우드의 관리형 MySQL은 중국 본토 리전이 없습니다; 국내 옵션은 별도 소버린 클라우드입니다. Amazon RDS와 Aurora MySQL-Compatible, Azure Database for MySQL, Google Cloud SQL for MySQL은 제공자의 글로벌 리전에만 배포합니다 — Google은 "Cloud SQL is available in all Google Cloud regions," 라 밝히고, 그 가장 가까운 아시아 항목은 대만(asia-east1)과 홍콩(asia-east2)이며, 중국 본토에는 없습니다. 국내에, 관리형 MySQL은 오직 그 자신의 계정을 가진 별도 소버린 클라우드에서만 돕니다: Beijing Sinnet과 Ningxia Western Cloud Data(NWCD)가 운영하는 AWS China의 aws-cn 파티션, 21Vianet이 운영하는 Azure China, 그리고 Alibaba Cloud의 ApsaraDB RDS for MySQL — 각각 그 자신의 ICP와 컴플라이언스 의무와 함께. | Google Cloud SQL for MySQL — instance locations (cloud.google.com), 2026-10-10 열람 |
| CIIO나 고물량 취급자에게, 중국 수집 데이터는 본토에 저장되어야 합니다 — 어떤 해외 데이터베이스도 충족 못 하는 의무. 중국 본토에서 수집되거나 생성된 개인정보는 그 안에 저장되어야 합니다(사이버보안법 제39조(구 제37조) — 2026년 1월 1일 발효된 2025년 사이버보안법 개정이 데이터 현지화 조항을 37에서 39로 재번호, 실질 불변; 그리고 PIPL 제40조). 해외의, 또는 비중국 관리형 리전의 MySQL 인스턴스는 그 국내 저장 의무를 충족할 본토 사본이 없습니다; 국내 자가 호스팅, 또는 라이선스된 소버린 관리형 MySQL은 충족합니다. | 사이버보안법 제39조(구 제37조); PIPL 제40조 |
| 해외 MySQL 속 중국 사용자의 개인 데이터는 PIPL 아래 국경 간 이전입니다. 중국 본토 내 사람들에게서 수집된 개인정보가 그 밖에서 저장되거나 처리되는 곳에서, PIPL은 취급자 — Oracle이나 클라우드가 아니라 귀사 — 에게 고지하고, 별도 동의를 받고, 이전 메커니즘 하나를 통과할 책임을 지웁니다: CAC 안전성 평가, CAC 표준계약, 또는 인증(제38~43조). 중국에서 해외 데이터베이스로의 모든 읽기와 쓰기가 그 이전을 반복합니다. | PIPL 제38~43조 — cac.gov.cn, 2026-10-10 열람 |
21YunBox 컴플라이언스 팀이(가) 2026년 10월 10일에 출처를 확인했습니다.
중국 본토 수용자에게, MySQL에 대한 결정적 질문은 그것이 설치되거나, 연결되거나, 쿼리를 돌려주는가 — 그것은 어디서든 그렇게 합니다 — 가 아니라, 그것이 쥐는 데이터가 어디에 쉬도록 허용되는가입니다. MySQL은 무수한 애플리케이션 뒤의 기록 시스템입니다: 고객 레코드, 사용자 계정, 로그인, 주문과 거래, 그리고 그 모두에 싸인 개인정보. MySQL은 이 목록에서 특이한데, 그것이 귀사가 내려받아 직접 돌리는 무료 오픈소스 소프트웨어이기 때문입니다: 엔진은 레지던시 중립적이고, 결코 차단되지 않으며, 중국 본토 땅에서 완벽하게 잘 돕니다. 그것이 바로 합법적 레버입니다. 컴플라이언스 노출은 엔진이 아닙니다 — 그것은 귀사가 그것을 어디서 그리고 어떻게 배포하는가입니다. 그것을 해외 관리형 서비스에서, 또는 중국 밖 클라우드 리전에서 돌리면, 귀사 중국 사용자의 개인 데이터가 국경의 틀린 편에 삽니다. 그것을 국내에서 돌리면 그렇지 않습니다.
asia-east1(대만)과 asia-east2(홍콩)이고, 중국 본토에는 없음. 엔진 자체는 본토 땅을 포함해 어디서든 설치됩니다; 해외 전용 리전 목록을 물려받는 것은 관리형 배포입니다. 출처: cloud.google.com/sql/docs/mysql/locations한눈에 보는 중국에서의 MySQL
| 무엇이 결정하는가 | MySQL 자신의 표현으로 — 그리고 중국의 법 |
|---|---|
| 데이터가 물리적으로 어디에 쉬는가 | MySQL은 귀사가 서버를 설치하는 어디서든 데이터를 저장합니다. 그것을 자가 호스팅하면 데이터가 그 머신에 삽니다; 관리형 MySQL을 쓰면 그것이 그 서비스가 제공하는 리전에 삽니다 — 그리고 일례로 Google Cloud SQL for MySQL은 “available in all Google Cloud regions,” 이고, 그중 어느 것도 중국 본토에 없습니다. |
| MySQL이 무엇을 쥐는가 | 기록 시스템: 고객 레코드, 사용자 계정, 로그인, 주문과 거래. 그 거의 전부가 개인정보이므로, 데이터베이스가 앉는 곳이 그 개인정보가 앉는 곳입니다. |
| 귀사 중국 사용자의 레코드 | 해외 리전이나 비중국 관리형 서비스에 쥐어지면, 귀사 중국 사용자의 개인 데이터가 본토 밖에 쉽니다 — PIPL이 규율하는 국경 간 이전(제38~40조), 모든 읽기와 쓰기마다 국경 너머로 운반됨. |
| 국내 저장 의무 | 핵심정보인프라 운영자나 고물량 취급자에게, 중국에서 수집된 개인정보는 본토에 머물러야 합니다(PIPL 제40조; 사이버보안법 제39조(구 제37조)). 해외 데이터베이스는 그 의무를 충족 못 합니다. |
| 그것이 닿는가? | 도달성은 축이 아닙니다 — MySQL은 차단된 사이트가 아니라 오픈소스 소프트웨어입니다. 합법적 경로는 그것을 국내에서 돌리는 것입니다: 본토 인프라에 자가 호스팅하거나 라이선스된 소버린 클라우드 옵션에서, 중국 대상 표면을 ICP 비안된 발판에 둔 채. |
데이터가 실제로 어디에 쉬는가
MySQL 자체는 홈 리전이 없습니다 — 그것은 귀사가 두는 머신에서 돌고, 바로 그것이 엔진이 레지던시 중립적인 이유입니다. 레지던시 질문은 전적으로 귀사 배포에 떨어집니다. MySQL을 내려받아 중국 본토 안 서버에서 돌리면, 데이터가 중국 땅에 쉽니다. 귀사 애플리케이션을 글로벌 클라우드의 관리형 MySQL로 가리키면, 데이터가 그 서비스가 리전을 제공하는 어디에든 쉽니다.
그것이 관리형 풍경이 중요해지는 곳입니다. 글로벌 클라우드 — Amazon RDS와 Aurora MySQL-Compatible, Azure Database for MySQL, Google Cloud SQL for MySQL — 에서, 귀사는 제공자의 리전에서 고르고, 글로벌 파티션의 어느 것도 중국 본토 안에 앉지 않습니다. Google은 “Cloud SQL is available in all Google Cloud regions,” 라고 명시하고, 그 가장 가까운 아시아 리전은 대만(asia-east1)과 홍콩(asia-east2)입니다 — 가깝고, 닿고, 레지던시 목적상 여전히 본토 밖; Google Cloud는 어떤 본토 리전도 전혀 없습니다. 거기 관리형 MySQL은 귀사 중국 데이터를 해외에 둡니다.
국내에, 관리형 MySQL은 존재합니다 — 하지만 오직 그 자신의 계정으로 닿는 별도, 소버린 클라우드에서만: AWS China는 Beijing Sinnet(cn-north-1)과 Ningxia Western Cloud Data, 즉 NWCD(cn-northwest-1)가 운영하는 별개 aws-cn 파티션입니다; Azure China는 21Vianet이 운영합니다; 그리고 Alibaba Cloud의 ApsaraDB RDS for MySQL은 그 본토 리전에서 돕니다. 이것들은 진짜 국내 옵션이지만, 각각 귀사가 이미 쓸 수 있는 글로벌 서비스와는 다른 운영자이자 계정이고, 그 자신의 기능 세트, ICP 비안, 컴플라이언스 의무를 가집니다 — 국내 리전은 자동 컴플라이언스가 아닙니다.
그것이 쥐는 것은 개인정보입니다
데이터베이스는 개인정보가 물리적으로 쉬게 되는 곳이고, 그것이 MySQL을 귀사가 물을 수 있는 가장 문자 그대로의 데이터 레지던시 질문으로 만듭니다. 그 안의 행은 이름, 연락처, 로그인 자격증명, 주문 이력, 결제 참조입니다 — 중국의 개인정보 보호법상 개인정보. 그 정보가 중국 내 사람들에게서 수집되고 해외 MySQL에 저장되는 순간, 그것을 거기 쥐는 것은 국경 간 이전이고, 그것을 읽거나 쓰는 모든 쿼리가 개인 데이터를 또 국경 너머로 옮깁니다. PIPL은 그 의무를 귀사 — Oracle이나 클라우드가 아니라 취급자 — 에 두어 고지하고, 별도 동의를 받고, 이전 메커니즘 하나를 통과하게 합니다: CAC 안전성 평가, CAC 표준계약, 또는 인증(제38~43조).
일부 취급자에게 법은 이전 메커니즘보다 더 나아가 데이터가 그대로 머물기를 요구합니다. 귀사가 핵심정보인프라 운영자이거나, 규제 물량 문턱 위로 개인정보를 처리한다면, 본토에서 수집된 개인정보는 본토에 저장되어야 합니다(사이버보안법 제39조(구 제37조) — 2026년 1월 1일 발효된 2025년 사이버보안법 개정이 데이터 현지화 조항을 37에서 39로 재번호, 실질 불변; 그리고 PIPL 제40조). 해외 MySQL, 또는 비중국 리전의 관리형 인스턴스는, 그 국내 저장 의무를 구조적으로 충족 못 합니다 — 가리킬 데이터의 본토 사본이 없습니다.
그것을 해외에서 돌리는 것은 레지던시 의무를 충족하지 않는다 — 그리고 무엇이 충족하는가
해외 레지던시 틈에 대한 해결책은 해외 데이터베이스로의 더 빠른 연결이 아닙니다 — 같은 개인 데이터를 국경 너머로 더 빨리 옮기는 것은 그것을 똑같이 해외인 채 둡니다. 합법적 레버는 MySQL이 귀사에 공짜로 건네는 것입니다: 엔진을 국내에서 돌리십시오. MySQL이 홈 리전이 없는 오픈소스 소프트웨어이므로, 귀사는 본토 인프라에 MySQL 서버를 세우거나, 라이선스된 소버린 클라우드 관리형 MySQL을 채택하고, 귀사 중국 사용자의 개인정보를 중국 땅에 — 레지던시와 현지화 의무가 돌아가지는 것이 아니라 설계상 충족되는 곳에 — 둘 수 있습니다.
그렇게 하는 것은 MySQL로부터 마이그레이션하거나 귀사 애플리케이션을 재작성하는 것을 뜻하지 않습니다: 그것은 같은 엔진, 같은 SQL, 같은 스키마이고, 이제 올바른 관할에 쉽니다. 필요한 것은 국내 저장, 어떤 공개 중국 대상 표면에든 ICP 비안, 그리고 진정으로 움직여야 하는 어떤 데이터든에 대한 합법적 국경 간 조정입니다. 이 페이지는 리스크 지도이지 판결이 아닙니다 — 귀사가 국내 저장, 이전 메커니즘, 또는 둘 다를 지는지는 귀사 법인, 귀사 데이터 물량, 그리고 누구의 개인정보가 데이터베이스에 앉는지에 달렸으므로, 짓기 전에 구체를 자문과 매듭지으십시오.
합법적 경로 — 매핑, 현지화, 전송
귀사는 MySQL을 계속 돌립니다. 21YunBox는 해외나 글로벌 클라우드 데이터베이스가 할 수 없는 조각을 더합니다: 데이터의 합법적, 국내 집, 그리고 그것에 닿는 ICP 비안된 방법.
- 매핑. 저희 중국 컴플라이언스 팀이 귀사 PIPL 국경 간, 데이터 레지던시, 데이터 현지화(CII) 의무, 그리고 귀사 ICP 의무를, 귀사 법인, 귀사 데이터 물량, 그리고 누구의 개인정보가 귀사 MySQL에 앉는지에 대조해 읽습니다.
- 현지화. 저희는 MySQL을 국내에서 — 본토 인프라에 자가 호스팅하거나, 라이선스된 소버린 클라우드 옵션에서 — 돌려, 귀사 중국 사용자의 개인정보가 본토 땅에 머물게 하고, 머물러야 하는 것에 동의받은, 국내 저장과 함께. 현지화는 해외 엔드포인트로 되돌아 숨은 경로를 내는 것이 아니라 합법적 국내 MySQL을 세우는 것을 뜻합니다.
- 전송. 데이터베이스 앞단의 어떤 중국 대상 표면이든 — 앱, API 에지, 귀사 본토 사용자가 건드리는 관리와 리포팅 포털 — 은 ICP 비안된, 국내 전송(21YunBox Optimizer)으로, 귀사가 이미 돌리는 스택 앞단에, 재구축도 두 번째 코드베이스도 없이 돕니다.
21YunBox는 마이그레이션이 아니라 규정에 맞는 overlay이고, MySQL과 귀사 클라우드의 경쟁자가 아니라 파트너입니다. 21YunBox는 어떤 종류의 우회도 결코 쓰거나 제안하지 않습니다. 결과는 귀사 중국 사용자에게 합법적이고 규정에 맞게 도는 MySQL입니다.
관련 읽을거리:
자주 묻는 질문
MySQL은 중국에서 작동하나요, 아니면 차단되나요?
MySQL은 작동하고 차단되지 않습니다 — 그것은 귀사가 중국 본토 안 서버를 포함해 설치하고 직접 돌리는 무료 오픈소스 소프트웨어입니다. 중국 질문은 도달성이 아니라 데이터 레지던시입니다: 귀사 MySQL 속 개인정보가 어디에 쉬도록 허용되는가. 국내 자가 호스팅은 그것을 본토 땅에 둡니다; 해외나 비중국 리전 관리형 MySQL은 그것을 본토 밖에 두고, 거기서 PIPL의 국경 간과 데이터 현지화 규칙이 적용됩니다.
관리형 MySQL에 중국 본토 리전이 있나요?
글로벌 클라우드에는 없습니다. Amazon RDS와 Aurora MySQL-Compatible, Azure Database for MySQL, Google Cloud SQL for MySQL은 중국 본토 밖 리전에만 배포합니다 — 일례로 Google Cloud는 "available in all Google Cloud regions," 이고, 그중 어느 것도 본토에 없습니다(그 가장 가까운 것은 대만과 홍콩). 국내 관리형 MySQL은 오직 그 자신의 계정으로 닿는 별도 소버린 클라우드에서만 존재합니다: Sinnet과 NWCD가 운영하는 AWS China의 aws-cn 파티션, 21Vianet이 운영하는 Azure China, 그리고 Alibaba Cloud의 ApsaraDB RDS for MySQL. 그것들은 진짜 국내 옵션이지만, 국내 리전은 자동 컴플라이언스가 아닙니다 — 각각 그 자신의 운영자, ICP, 의무를 가져옵니다.
21YunBox가 우리 MySQL 설정을 중국에서 규정에 맞게 만들 수 있나요?
예. 저희 중국 컴플라이언스 팀이 귀사 PIPL 국경 간, 데이터 레지던시, 데이터 현지화 노출을 귀사 법인, 귀사 데이터 물량, 그리고 누구의 개인정보가 데이터베이스에 앉는지에 대조해 매핑한 뒤, MySQL을 국내에서 — 본토 인프라에 자가 호스팅하거나 라이선스된 소버린 클라우드 옵션에서 — 돌려, 귀사 중국 사용자의 데이터가 본토 땅에 머물게 하고, 어떤 중국 대상 표면이든 귀사가 이미 돌리는 스택 앞단에 ICP 비안된, 국내 인프라로 전송합니다. 재구축 없이, MySQL로부터의 마이그레이션 없이. 귀사의 구체적 데이터 흐름을 다루려면 문의하기.
