Elasticsearch는 중국에서 작동하나요? PIPL 국경 간, 데이터 레지던시 & 셀프호스팅
Elasticsearch는 전문 검색 엔진이자 벡터 데이터베이스입니다: 귀사가 색인하는 문서와 그로부터 파생된 dense-vector 임베딩은 정지 상태로 보유되는 개인정보이고, Elastic Cloud는 중국 본토 리전이 없습니다 — 그러니 거기 귀사 중국 사용자의 데이터를 색인하는 것은 PIPL 국경 간 이전입니다. 레지던시 노출과 국내 셀프호스트 레버를 컴플라이언스 우선으로 봅니다.
Elasticsearch는 중국에서 작동하나요?
Elasticsearch는 귀사 사용자 콘텐츠의 정지 데이터 저장소입니다 — 귀사가 색인하는 문서와 그로부터 파생된 dense-vector 임베딩 — 그리고 Elastic Cloud는 중국 본토 리전이 없으므로, 중국향 색인은 해외에 앉습니다: 속도가 아니라 레지던시·국경 간 이전 문제.
귀사는 Elasticsearch에 문서·기록·로그와 그것이 kNN 검색·RAG를 위해 그로부터 계산하는 임베딩을 싣습니다 — 모두 귀사 사용자의 메시지·프로필·파일에서 지어지므로, 그 사용자가 중국에 있을 때 모두 개인정보. 그것을 해외 Elastic Cloud 리전(AWS·GCP·Azure — 가장 가까운 것은 홍콩, 본토가 아니라)에 색인하는 것은 PIPL 국경 간 이전(고지, 별도 동의, 이전 메커니즘, 제38~40조)이고, 핵심정보인프라 운영자와 대량 취급자에는 본토 내 저장 의무(제40조; 사이버보안법 제39조(구 제37조)). 임베딩이 그것을 익명화해 없애지 않습니다 — 그것은 역산과 멤버십 추론을 지원하므로, 벡터 저장소도 여전히 개인정보 저장소입니다. Elasticsearch가 오픈 소스(2024년 이래 AGPL)이고 완전히 셀프호스트 가능하므로, 합법적 레버는 색인과 임베딩을 국내에 두는 것입니다 — 오픈 엔진을 본토 인프라에 셀프호스트하거나, 허가받은 국내 관리형 배치 사용 — 해외 엔드포인트를 도달 가능하게 만드는 것이 아니라.
이는 판정이 아니라 리스크 그림입니다 — 어느 이전 메커니즘이 맞는지와 국내화 의무가 귀사를 묶는지는 귀사 법인, 데이터 볼륨, 누구의 데이터인지로 갈립니다. 저희 중국 팀이 귀사 노출을 매핑할 수 있습니다 →
컴플라이언스 스냅샷
- ! Elastic Cloud는 AWS·GCP·Azure에서 돎 — 가장 가까운 리전은 홍콩, 본토가 아님
- ! 귀사가 색인하는 것 — 문서와 dense-vector 임베딩 — 은 정지 상태 개인 데이터
- ! 임베딩은 익명이 아님 — 역산과 멤버십 추론이 사람을 복원
- ✕ Elastic Cloud는 중국 본토 리전이 없어 데이터 국내화를 충족 못 함
- ! Alibaba Cloud Elasticsearch는 허가받은 운영자로 국내에서 돎 — 통과가 아니라 warn
- ✓ 오픈 소스(AGPL) 엔진을 국내에 셀프호스트; ICP는 앞단 앱에 탐
Elasticsearch 공식 문서가 중국에 대해 말하는 것
| 사실 | 1차 출처 |
|---|---|
| Elasticsearch는 다시 오픈 소스이고 완전히 셀프호스트 가능합니다 — 데이터를 국내에 두는 레버. 2024년 8월 Elastic은 Elastic License v2와 SSPL에 더해 OSI 승인 AGPL(AGPLv3) 라이선스 옵션을 더하며 "Elasticsearch and Kibana can be called Open Source again."라 썼습니다. 같은 엔진을 귀사 자신의 하드웨어에서 돌릴 수 있으므로, 클러스터 — 색인과 dense-vector 임베딩 — 를 해외 관리형 리전이 아니라 본토 인프라에 호스트할 수 있습니다. | Elastic blog — "Elasticsearch Is Open Source. Again!" (Shay Banon, Aug 29 2024), retrieved 2026-10-10 |
| Elastic Cloud는 중국 본토 리전이 없습니다 — 그리고 그것은 텍스트만이 아니라 dense-vector 임베딩을 저장합니다. Elastic 자사 Elastic Cloud Hosted 리전 페이지는 AWS·GCP·Azure 위치를 열거하고; 가장 가까운 아시아 태평양 리전은 홍콩(aws-ap-east-1), 어느 것도 중국 본토 안이 아닙니다. Elasticsearch는 문서(역색인에)와 임베딩(kNN 검색을 위한 그 dense_vector 필드 유형으로) 둘 다 색인합니다 — 그러니 Elastic Cloud 위 중국향 배치는 그 콘텐츠를 해외에 둡니다. | Elastic Docs — Elastic Cloud Hosted regions; Elastic Docs — kNN / dense_vector, retrieved 2026-10-10 |
| 중국 사용자 데이터를 해외 클러스터에 색인하는 것은 PIPL 국경 간 이전이고, 일부 취급자에는 국내 저장 의무가 붙습니다. 해외 리전에 개인정보를 보유하는 것은 PIPL의 국경 간 규칙을 유발합니다 — 고지, 별도 동의, 한 이전 메커니즘(CAC 안전성 평가, CAC 표준계약, 또는 인증), 제38~40조. 핵심정보인프라 운영자나 대량 취급자는 중국에서 수집된 개인정보를 본토에 저장해야 합니다(PIPL 제40조; 사이버보안법 제39조(구 제37조) — 2026년 1월 1일 발효된 2025년 사이버보안법 개정이 데이터 국내화 조항을 37조에서 39조로 재번호, 실질 불변). | PIPL Articles 38–40 (DigiChina/Stanford translation); Cybersecurity Law Article 39 (formerly Article 37), retrieved 2026-10-10 |
| 임베딩은 개인 데이터에서 파생되고 익명화가 아닙니다. PIPL은 개인정보를 식별된 또는 식별 가능한 자연인에 관한 정보로 정의하고 진정으로 익명화된 데이터만 범위 밖으로 다룹니다(제4조). 벡터 임베딩은 사람의 텍스트나 이미지로부터 계산되고 역산(원본의 근사 재구성)과 멤버십 추론을 지원하므로, 귀사 사용자 데이터의 임베딩 저장소는 여전히 개인정보 저장소입니다 — "우리는 벡터만 보낸다"가 그것을 PIPL의 레지던시·국경 간 이전 의무 밖으로 데려가지 않습니다. | PIPL Article 4 (DigiChina/Stanford translation), retrieved 2026-10-10 |
21YunBox 컴플라이언스 팀이(가) 2026년 10월 10일에 출처를 확인했습니다.
중국향 애플리케이션에, Elasticsearch에 관한 질문은 클러스터가 쿼리에 답하느냐 — 답합니다 — 가 아니라, 귀사가 먹이는 콘텐츠가 어디 살도록 허락되느냐입니다. Elasticsearch는 두 의미에서 동시에 정지 데이터 저장소입니다: 귀사가 색인하는 문서·기록·로그를 역색인에 보유하는 전문 검색 엔진이자, dense-vector 임베딩을 그 dense_vector 필드 유형에 보유하여 시맨틱 조회와 RAG를 위한 k-최근접 이웃(kNN) 검색을 구동하는 벡터 데이터베이스. 둘 다 귀사 사용자의 메시지·프로필·파일에서 지어집니다 — 변환된 형태의 개인정보. 엔진은 다시 오픈 소스이고 완전히 셀프호스트 가능하지만, 관리형 제공물 Elastic Cloud는 중국 본토 리전 없이 AWS·GCP·Azure에서 돕니다. 그러니 결정 질문은 레지던시와 국경 간 이전, 임베딩이 그 뒤의 사람을 익명화하지 않는다는 것, 그리고 오픈 엔진을 국내에 셀프호스트하는 레버입니다.
한눈에 보는 중국에서의 Elasticsearch
| 무엇이 결정하나 | Elasticsearch 자신의 표현으로 — 그리고 중국 법으로 |
|---|---|
| 그것에 싣는 것 | 귀사가 역색인에 색인하는 문서·기록·로그·채팅, 그리고 Elasticsearch가 kNN 검색과 RAG를 위해 그로부터 계산하는 dense-vector 임베딩. 귀사 사용자가 중국에 있을 때, 그것은 정지 상태로 보유되는 그들의 개인정보입니다. |
| 엔진이 도는 곳 | Elastic Cloud(관리형)는 AWS·GCP·Azure에서 돕니다 — 가장 가까운 아시아 태평양 리전은 홍콩(aws-ap-east-1), 중국 본토가 아닙니다. 거기 중국 사용자 데이터를 색인하는 것은 PIPL 제38~40조상 국경 간 이전(数据出境)입니다; 오픈 엔진을 셀프호스트하면 그것을 국내에 둡니다. |
| 임베딩은 개인정보다 | 벡터는 사람의 텍스트나 이미지로부터 계산됩니다; 그것은 역산(근사 재구성)과 멤버십 추론을 지원하므로, 익명화되지 않습니다. 귀사 사용자 데이터의 임베딩 저장소는 그 자체가 개인정보 저장소입니다 — "원시 데이터가 아니라 벡터만"은 거짓 위안입니다. |
| 데이터 국내화와 쿼리 로그 | 핵심정보인프라 운영자나 대량 취급자는 중국에서 수집된 개인 데이터를 본토에 보관해야 합니다(PIPL 제40조; 사이버보안법 제39조, 구 제37조). 쿼리 로그도 개인정보를 실을 수 있습니다. 해외 Elastic Cloud 리전은 이 중 아무것도 충족하지 않습니다. |
| 도달 가능성은 축이 아니다 | 클러스터가 쿼리에 답하느냐는 결코 질문이 아니었습니다. 레버는 색인과 임베딩을 국내에 두는 것입니다 — 오픈 소스(AGPL) 엔진을 셀프호스트하거나, 허가받은 국내 관리형 배치 — 색인하는 것을 최소화·가명화하고, 앞단 앱에 ICP 비안을 지웁니다. |
귀사가 실제로 저장하는 것 — 색인된 콘텐츠와 그 임베딩
Elasticsearch는 데이터를 넘겨주는 것이 아니라 보유함으로써 제 자리를 법니다. 검색 엔진으로서 그것은 귀사가 색인하는 모든 문서 — 지원 티켓, 제품 기록, 사용자 프로필, 로그, 채팅 기록 — 를 빠른 전문 검색을 위해 지어진 역색인에 보관합니다. 벡터 데이터베이스로서 그것은 dense-vector 임베딩을 그 dense_vector 필드 유형에 보관하고, 그것이 시맨틱 조회와 검색 증강 생성(RAG)을 위한 k-최근접 이웃(kNN) 검색을 구동하며; 대부분의 설계는 또한 매치를 보이고 추적할 수 있도록 원본 텍스트나 페이로드를 각 벡터와 함께 저장합니다. 그 구조 하나하나가 귀사 사용자 자신의 콘텐츠에서 파생됩니다. 그 사용자가 중국에 있을 때, 색인은 우연한 배출물이 아니라 — 정지 상태인 그들의 개인정보 저장소이고, 그것은 클러스터가 도는 곳이 어디든 거기 삽니다. 그 때문에 결정 질문은 지연 질문이 아니라 위치 질문입니다: Elasticsearch가 이 모두를 어디 보관하도록 허락되나?
그것은 레지던시·국경 간 이전 문제다 — 그리고 임베딩이 그것을 익명화하지 않는다 — PIPL 아래
그 클러스터를 Elastic Cloud에서 돌리면 지리가 귀사 대신 질문에 답합니다. Elastic의 관리형 서비스는 AWS·GCP·Azure에서 돌고, 그 자사 Elastic Cloud Hosted 리전 페이지는 중국 본토 안 위치를 열거하지 않습니다 — 가장 가까운 것은 홍콩(aws-ap-east-1), 데이터 국내화 목적에는 본토가 아닙니다. 따라서 귀사 중국 사용자의 문서와 임베딩을 해외 리전에 색인하는 것은 중국 개인정보 보호법상 개인정보의 국경 간 이전(数据出境)입니다: 귀사 — Elastic이 아니라 취급자 — 는 고지하고, 별도 동의를 받고, 한 이전 메커니즘(CAC 안전성 평가, CAC 표준계약, 또는 인증)을 제38~40조 아래 통과해야 합니다. 귀사가 핵심정보인프라 운영자나 대량 취급자이면, 중국에서 수집된 개인정보는 본토에 저장되어야 합니다(PIPL 제40조; 사이버보안법 제39조(구 제37조) — 2026년 1월 1일 발효된 2025년 사이버보안법 개정이 데이터 국내화 조항을 37조에서 39조로 재번호, 실질 불변) — 어떤 해외 리전도 충족할 수 없는 의무.
그리고 임베딩이 귀사를 여기서 꺼내 주지 않습니다. 벡터 색인이 이름과 이메일이 아니라 부동소수점 수의 배열을 저장하기 때문에 면제된다고 — “우리는 원시 데이터가 아니라 벡터만 보낸다” — 생각하기 솔깃합니다. 그 위안은 거짓입니다. 임베딩은 사람의 텍스트·문서·이미지로부터 직접 계산되고, 역산 — 원본 텍스트의 근사 재구성 — 과 어떤 사람의 기록이 저장소에 있는지 드러내는 멤버십 추론을 지원할 만큼 원본을 보존합니다. PIPL은 개인정보를 식별된 또는 식별 가능한 자연인에 관한 정보로 정의하고 진정으로 익명화된 데이터만 그 범위 밖에 둡니다(제4조); 귀사 사용자 데이터의 임베딩은 익명화되지도, 범위 밖도 아닙니다. 중국 사용자 개인 데이터의 임베딩 저장소는 그것이 나온 원시 텍스트와 같은 레지던시·국경 간 의무를 집니다.
엔드포인트에 닿는 것이 질문이 아니다 — 색인을 국내에 두는 것이 질문이다
이 중 어느 것도 Oregon이나 싱가포르의 클러스터가 상하이에서 온 쿼리에 답하느냐에 관한 것이 아닙니다. 답합니다. 노출은 색인과 그 임베딩 — 개인정보 — 이 본토 밖에 정지 상태로 앉아 있다는 것입니다. 깨끗한 레버는 Elasticsearch가 무엇인지에서 바로 따릅니다: 오픈 소스. Elastic이 2024년 AGPL 옵션을 더한 이래, 귀사는 같은 엔진을 중국 안 귀사 자신의 인프라에서 돌려 색인과 임베딩을 국내에 두고, 색인하는 것을 최소화·가명화하여 애초에 더 적은 개인정보가 보유되게 할 수 있습니다. 완전 관리형 서비스가 요구되는 곳에서는, 허가받은 국내 관리형 Elasticsearch — 예컨대 Alibaba Cloud의 본토 리전을 통해 제공되는 Alibaba Cloud Elasticsearch — 가 warn-positive입니다: 그것은 데이터를 국내에 두지만, 뚜렷이 구별되는 운영자·계약이고, 귀사의 동의 근거·이전 위치·쿼리 로그 처리는 여전히 해소되어야 합니다. 레버가 아닌 것은 데이터를 해외에 둔 채 멀리 있는 엔드포인트를 로컬처럼 느끼게 만드는 방법입니다; 국내화는 데이터를 본토 밖으로 보냈다 되돌리는 것이 아니라 정지 데이터 저장소를 국내 경로에 두는 것을 뜻합니다.
이는 판정이 아니라 리스크 그림입니다: 국내화 의무가 귀사를 묶는지, 어느 국경 간 메커니즘이 맞는지, 귀사 색인의 얼마가 개인정보로 치는지는 귀사 법인, 데이터 볼륨, 누구의 데이터인지로 갈립니다 — 짓기 전에 구체적인 것을 자문과 해소하십시오.
합법적 경로 — 매핑, 로컬라이즈, 전달
21YunBox는 귀사가 이미 돌리는 스택을 둘러싼 규정에 맞는 오버레이이지, Elasticsearch의 대체도 Elastic의 경쟁자도 아닙니다. 그 일은 세 부분입니다. 매핑: 귀사가 무엇을 색인·벡터화하는지, 그 문서와 임베딩이 어떤 개인정보를 싣는지, 클러스터가 오늘 어디서 도는지, 쿼리 로그가 무엇을 포착하는지, 귀사가 기대는 동의 근거를 인벤토리. 로컬라이즈: 귀사 중국 사용자 색인과 임베딩을 국내에 유지 — 오픈 소스(AGPL) 엔진을 본토 인프라에 셀프호스트하거나, 허가받은 국내 관리형 배치 사용 — 색인되는 것을 최소화·가명화하고, 남는 국경 간 이전을 다스림; 요점은 정지 데이터 저장소를 국내 경로에 두는 것입니다. 전달: 색인을 쿼리하는 애플리케이션은 ICP 비안 의무를 지고 규정에 맞는 국내 전달이 필요합니다 — 21YunBox Optimizer, 귀사가 이미 돌리는 스택 앞단에, 재구축 없이, 둘째 코드베이스 없이. 21YunBox는 어떤 종류의 우회도 쓰거나 권하지 않습니다. 결과는 중국의 귀사 사용자에게 합법적으로 그리고 규정에 맞게 도는 Elasticsearch 배치입니다.
함께 읽기:
자주 묻는 질문
임베딩이 그저 벡터라면 정말 개인정보인가요?
그것을 개인정보로 다루십시오, 그것이 바로 그것이기 때문입니다. 임베딩은 사용자의 메시지·문서·이미지로부터 직접 계산되고, 임베딩이 역산 — 원본 텍스트의 근사 재구성 — 과 멤버십 추론을 지원함이 보여졌습니다. Elasticsearch는 또한 대부분의 설계에서 원시 문서나 페이로드를 벡터와 함께 저장합니다. 그러니 귀사 중국 사용자 활동에서 지어진 색인은 익명화된 것이 아니라 변환된 형태로 그들의 개인정보를 보유합니다; PIPL 제4조상 진정으로 익명화된 데이터만 범위 밖입니다. 해외 Elastic Cloud 리전에 보유되면, 그것은 국경 간 이전이고, 의무는 취급자로서 귀사에 떨어집니다.
Elasticsearch를 셀프호스트하는 것이 중국의 깨끗한 답 아닌가요?
그것은 가장 강한 레버이고 실재합니다: Elastic이 2024년 AGPL 옵션을 더한 이래, Elasticsearch는 오픈 소스이고 같은 엔진을 본토 안 귀사 자신의 인프라에서 돌려 색인과 그 임베딩을 국내에 둘 수 있습니다. 그것이 데이터 레지던시에 답합니다. 그것이 그 자체로 전부에 답하지는 않습니다 — 클러스터를 쿼리하는 공개 앱은 본토 청중을 서비스하면 여전히 ICP 비안이 필요하고, 귀사 PIPL 동의·고지 의무는 이제 귀사가 돌릴 몫이며, 쿼리 로그가 그 자체로 개인정보를 실을 수 있습니다. 허가받은 국내 관리형 Elasticsearch(예컨대 Alibaba Cloud의 본토 리전 속 Alibaba Cloud Elasticsearch)는 warn-positive 대안입니다 — 국내지만, 뚜렷이 구별되는 운영자·계약.
21YunBox가 우리 Elasticsearch 기반 앱을 중국에서 작동하게 도울 수 있나요?
예. 저희 중국 팀이 귀사가 무엇을 색인·벡터화하는지와 그것이 싣는 개인정보를 인벤토리하고, 귀사 법인·데이터 볼륨에 대한 PIPL 국경 간·데이터 레지던시 위치를 매핑하며, 셀프호스티드 국내 Elasticsearch 경로 — 더해 그 앞단 애플리케이션이 필요로 하는 ICP 비안 국내 전달 — 를 귀사가 이미 돌리는 스택을 둘러 세울 수 있습니다, 재구축 없이, Elasticsearch 이탈 없이. 문의하기 주시면 귀사의 구체적 사례를 짚겠습니다.
