GitLab CI/CD는 중국에서 작동하나요? 데이터 레지던시, ICP, 그리고 국경 간 규칙
GitLab CI/CD 파이프라인은 귀사의 독점 소스를 체크아웃하고 배포 키·클라우드 자격 증명·서명 키를 작업에 주입한 뒤 빌드 아티팩트를 씁니다; GitLab.com의 호스팅 러너에서는 그것이 GitLab의 해외 인프라에서 돕니다 — 도달성이 아니라 PIPL 데이터 레지던시 문제입니다. 국내의 자체 관리 GitLab＋자체 호스팅 GitLab Runner가 소스·시크릿·아티팩트를 국내에 머물게 합니다.
GitLab CI/CD는 중국에서 작동하나요?
GitLab CI/CD가 중국에서 작동하는지는 속도가 아니라 귀사의 소스와 시크릿에 관한 데이터 레지던시 질문입니다. 파이프라인 작업은 본토 내부에서 문제없이 돕니다 — 이것을 결정하는 건 그것이 실행되는 동안 귀사의 코드와 자격 증명이 어디에 사느냐입니다.
모든 CI/CD 작업은 귀사의 독점 소스를 러너의 워크스페이스에 체크아웃하고 시크릿 — 배포 키, 클라우드 자격 증명, 서명 키, 레지스트리 토큰 — 을 주입한 뒤 빌드 아티팩트를 씁니다. GitLab.com의 호스팅 러너에서 그것은 GitLab 자신의 해외 인프라에서 일어나므로, 귀사의 집약된 소스·시크릿·아티팩트가 국외에 앉고 귀사 중국 배포의 빌드 파이프라인이 국경을 넘습니다: PIPL이 규율하는 개인정보의 국경 간 이전이며, 핵심정보인프라 운영자나 대량 취급자에는 데이터 레지던시 의무이기도 합니다. 레버는 국내의 자체 관리 GitLab＋자체 호스팅 GitLab Runner이며, 그래서 체크아웃·시크릿·아티팩트가 국내에 머뭅니다.
이는 판정이 아니라 리스크 그림입니다 — 귀사의 의무는 데이터 물량과 역할에 따라 달라집니다. 저희 중국 팀이 귀사 파이프라인의 레지던시 노출을 함께 정리해 드립니다 →
컴플라이언스 스냅샷
- ! 파이프라인 작업은 중국에서 문제없이 돌아감 — 이것을 결정하는 건 도달성이 아님
- ! GitLab.com 호스팅 러너는 GitLab의 해외 인프라에서 돌아감
- ! 체크아웃은 독점 소스, 배포 키, 서명 키를 해외에 둠
- ! 커미터 신원, 로그, 아티팩트 속 개인정보가 국경을 넘음 — PIPL
- ! CIIO나 대량 취급자: 해외 러너가 충족할 수 없는 레지던시 의무
- ✓ 레버: 국내의 자체 관리 GitLab＋자체 호스팅 Runner가 국내에 머물게 함
GitLab CI/CD 공식 문서가 중국에 대해 말하는 것
| 사실 | 1차 출처 |
|---|---|
| GitLab 자신의 표현으로: "GitLab-hosted runners are managed by GitLab and available on GitLab.com,"이며 GitLab이 그것을 "provides them as a service" — 자신의 인프라 — 하는 반면, "Self-managed runners are GitLab Runner instances that you install, configure, and manage in your own infrastructure,"이고 "You can install and register self-managed runners on all GitLab installations."입니다. 따라서 귀사의 소스를 체크아웃하고 시크릿을 도는 호스팅 러너는 GitLab의 해외 서비스이며, 국내 레지던시 경로는 귀사가 직접 운영하는 자체 호스팅 러너입니다. | GitLab Docs — GitLab Runner, 2026-10-13 열람 |
| CI/CD 작업은 단지 서비스에 닿는 것이 아니라 — 도는 동안 귀사의 소스와 시크릿을 쥡니다. GitLab 문서는 CI/CD 변수를 귀사가 "store values you want to re-use, for example in job scripts"하는 데 쓰는 "a type of environment variable"로 설명합니다: 배포 키, 클라우드 자격 증명, 서명 키, 레지스트리 토큰을 실행 환경에 주입하는 메커니즘. 호스팅 러너에서 그 환경과, 그 옆에 체크아웃된 독점 소스는 GitLab의 해외 인프라에서 실행됩니다. | GitLab Docs — CI/CD variables, 2026-10-13 열람 |
| 호스팅 러너가 귀사 커미터의 신원, 작업 로그, 아티팩트나 변수 안의 모든 개인정보를 쥐고 그것을 본토 밖 인프라에서 실행하므로, 이는 개인정보의 국경 간 이전입니다. PIPL이 이를 규율합니다(제38~40조): 개인정보 처리자(GitLab 고객인 귀사)는 고지하고, 별도 동의를 받고, 이전 메커니즘 하나 — CAC 안전성 평가, CAC 표준계약, 또는 인증 — 를 충족해야 합니다. | 개인정보 보호법 제38~40조 |
| CIIO나 대량 취급자의 경우, 중국 본토에서 수집·생성한 개인정보와 중요 데이터는 본토에 저장되어야 하며 어떤 수출 전에도 안전성 평가가 필요합니다 — 2026-01-01 시행된 2025년 개정으로 재번호된 사이버보안법 데이터 국내화 규칙 제39조(구 제37조)입니다. 귀사의 소스를 체크아웃하고 시크릿을 도는 해외 호스팅 러너에는 이를 충족할 본토 발판이 없습니다. | 중화인민공화국 사이버보안법 제39조(구 제37조) |
21YunBox 컴플라이언스 팀이(가) 2026년 10월 13일에 출처를 확인했습니다.
중국 본토 배포라면, GitLab CI/CD에 대한 결정적인 질문은 상하이의 러너가 GitLab에 닿거나 공개 의존성을 풀할 수 있는지가 아니라 — 파이프라인이 도는 순간 귀사의 소스 코드, 빌드·배포 시크릿, 빌드 아티팩트가 어디에 사느냐입니다. 서비스에 닿고 의존성을 해결하는 것은 도달성 주제이고 연결성 튜닝이 도울 수 있습니다; 그것은 귀사의 구성이 방어 가능한지를 결정하는 부분이 아닙니다. CI/CD 작업은 다릅니다. 모든 작업은 귀사의 독점 소스를 러너의 워크스페이스에 체크아웃하고, 시크릿 — 배포 키, 클라우드 자격 증명, 서명 키, 레지스트리 토큰 — 을 실행 환경에 주입한 뒤, 빌드 아티팩트를 생성합니다. GitLab.com의 호스팅 러너에서 그 집약된 소스, 그 시크릿, 그 아티팩트가 모두 GitLab 자신의 인프라에서 실행되고, 귀사 중국 배포의 빌드 파이프라인이 국경을 넘습니다. 풀 레이턴시가 아니라 레지던시와 국경 간 이전이 이것을 결정합니다.
한눈에 보는: GitLab CI/CD는 중국에서 작동하나요?
| 무엇이 결정하나 | 중국 본토에 그것이 뜻하는 바 |
|---|---|
| 작업이 무엇을 체크아웃하나 | 모든 CI/CD 작업은 귀사의 독점 소스를 러너의 워크스페이스에 클론합니다 — 러너가 도는 곳 어디에든 앉는, 귀사 지적 재산의 집약된 일부. |
| 작업이 어떤 시크릿을 쥐나 | CI/CD 변수는 배포 키, 클라우드 자격 증명, 서명 키, 레지스트리 토큰을 실행 환경에 주입합니다; GitLab 문서상 그것들은 작업에 제공되는 “a type of environment variable”(환경 변수의 한 종류)입니다. |
| 러너가 어디서 도나 | GitLab.com의 호스팅 러너는 GitLab의 해외 인프라에서 “managed by GitLab”하고 “provided as a service”됩니다. GitLab은 중국 본토 호스팅 러너 리전을 공표하지 않습니다(현재 상태는 GitLab에 확인). |
| 데이터 레지던시 | CIIO나 대량 취급자의 경우, 중국에서 수집한 개인정보와 중요 데이터는 본토에 저장되어야 합니다(사이버보안법 제39조(구 제37조)) — 해외 러너가 충족할 수 없는 의무입니다. |
| 국경 간 이전 | 커미터 신원, 작업 로그, 그리고 아티팩트나 변수 안의 모든 개인정보가 해외에서 실행되면 PIPL 국경 간 이전입니다(제38~40조): 고지, 별도 동의, 이전 메커니즘 하나. |
| 레지던시 레버 | 본토 안에서 운영하는 자체 관리 GitLab＋자체 호스팅 GitLab Runner는 체크아웃, 주입된 시크릿, 빌드 아티팩트를 국내에 머물게 합니다. |
첫 번째 문 — 소스는 러너에 체크아웃되며, 레지던시는 러너가 도는 곳을 따른다
실제로 무엇이 실행되는지에서 시작하십시오. 중국 법이 반응하는 것이 바로 그것이기 때문입니다. GitLab에 닿고 공개 패키지를 푸는 것은 연결성 주제이며, 이것을 결정하는 부분이 아닙니다. 작업이 결정합니다. 파이프라인이 돌면 GitLab Runner는 귀사의 비공개 리포지토리를 러너의 워크스페이스에 클론합니다 — 귀사의 독점 소스, 의존성, 빌드 로직, 귀사 지적 재산의 집약된 일부. GitLab 자신의 문서는 GitLab 호스팅 러너를 “managed by GitLab and available on GitLab.com,”으로 설명하며, GitLab이 그것을 “as a service”로 제공합니다 — GitLab 자신의 해외 인프라에서 도는 호스팅 플릿이며, 귀사의 작업을 위한 중국 본토 호스팅 러너 리전이 없습니다(가정하지 말고 GitLab에 확인할 가치가 있습니다). 귀사가 핵심정보인프라 운영자이거나 개인정보를 대량으로 취급한다면, 중국에서 수집·생성한 개인정보와 중요 데이터는 본토에 저장되어야 하며 어떤 수출 전에도 안전성 평가가 필요합니다 — 사이버보안법 데이터 국내화 규칙, 2026-01-01 시행된 2025년 개정으로 재번호된 제39조(구 제37조)입니다. 귀사의 소스를 국외에 체크아웃하는 호스팅 러너에는 이를 충족할 본토 발판이 없습니다.
두 번째 문 — 주입된 시크릿, 커미터 신원, 그리고 귀사의 빌드 아티팩트
두 번째 문은 PIPL과, 파이프라인이 실어 나르는 집약된 시크릿입니다. CI/CD 작업은 소스보다 훨씬 많은 것을 쥡니다: GitLab 문서는 CI/CD 변수를 귀사가 “store values you want to re-use, for example in job scripts”하는 데 쓰는 “a type of environment variable”로 설명합니다 — 배포 키, 클라우드 자격 증명, 서명 키, 레지스트리 토큰을 도는 작업에 주입하는 메커니즘. 그 둘레에 푸시·리뷰·트리거한 사람의 사용자명과 이메일 주소, 작업 로그, 그리고 작업이 쓰는 빌드 아티팩트가 앉습니다 — 이따금 픽스처나 테스트 데이터셋에 개인 기록이 묻어 따라갑니다. 개인정보 보호법(PIPL)에 따라, 그 데이터를 본토 밖 인프라에 보유·처리하는 것은 국경 간 이전입니다(제38~40조): 처리자는 고지하고, 이전에 대한 별도 동의를 받고, 메커니즘 하나 — CAC 안전성 평가, CAC 표준계약, 또는 인증 — 를 충족해야 합니다. 변수를 마스킹하고 로그·아티팩트에 들어가는 것을 다듬는 것은 좋은 위생의 일부이지만, 그것을 실행하는 러너를 옮기지는 못합니다. 그리고 귀사 중국 배포가 작업을 실행하는 러너 어디에서든 빌드·배포되므로, 본토로 출하되는 것의 출처와 무결성 — 어떤 소스로 빌드되고 어떤 키로 서명되었는지 — 도 국경 너머에서 규율됩니다: 연결성 점검이 결코 드러내지 못하는 공급망 노출입니다.
왜 도달성 점검은 이것을 놓치나
“내 러너가 상하이에서 GitLab에 닿을 수 있나” 테스트는 잘못된 질문에 답합니다. 연결성 튜닝이나 의존성 캐시는 작업이 얼마나 빠르고 안정적으로 시작·패키지 해결을 하는지를 바꿀 뿐 — 귀사의 소스가 어디서 체크아웃되는지, 주입된 시크릿이 어디서 실행되는지, 빌드 아티팩트가 어디서 쓰이는지를 바꾸지 않습니다. 그래서 파이프라인은 중국 내부에서 완벽하게 초록으로 보이면서도, 귀사의 독점 소스 체크아웃, 작업에 주입된 모든 배포 키·서명 키, 모든 커미터 기록이 여전히 해외에서 돌 수 있습니다. 위의 레지던시·국경 간 질문은 바로 작업이 계속 통과하기 때문에 도달성 탐침에 보이지 않습니다 — 그래서 중요한 조치는 호스팅 러너를 단지 도달 가능하게 하는 것이 아니라 러너를 국내에서 운영하는 것입니다. 저희는 중국 내부에서 측정한 GitLab 연결성 자체 측정값을 공표하지 않으므로 여기에 수치를 두지 않습니다; 그것은 주장하기보다 귀사의 실제 구성에 대해 측정할 것입니다.
이는 판정이 아니라 리스크 지도입니다: 국내 러너, 이전 메커니즘, 재설계된 동의 플로우, 공개 개발자·배포 포털을 위한 ICP 비안, 또는 그 조합 중 무엇이 필요한지는 귀사의 파이프라인이 무엇을 체크아웃하는지, 어떤 시크릿을 쥐는지, 누가 커밋하는지에 따라 달라집니다 — 구축에 들어가기 전에 법률 자문과 함께 정리할 가치가 있습니다.
레버 — 진단, 현지화, 전송
진정한 자체 관리 GitLab과 자체 호스팅 GitLab Runner가 존재하므로 실질적인 국내 경로가 있으며, 21YunBox는 어떤 불법적 우회도 결코 쓰거나 권하지 않습니다 — 국내 경로가 합법적 경로입니다.
- 진단(map) — 어떤 파이프라인이 독점 소스를 체크아웃하는지, 러너가 어떤 시크릿(배포 키, 클라우드 자격 증명, 서명 키, 레지스트리 토큰)을 쥐는지, 러너와 아티팩트 저장소가 오늘 어디에 사는지, 레지던시 근거, 그리고 귀사 중국 배포의 빌드 파이프라인이 어떻게 국경을 넘는지를 목록화합니다.
- 현지화 / 거버넌스 — 러너를 국내에서(자체 호스팅 — 귀사 자신의 인프라에 자체 관리 GitLab＋자체 호스팅 GitLab Runner) 운영하여 체크아웃된 소스, 주입된 시크릿, 빌드 아티팩트가 국내에 머물게 하고; 귀사 중국 배포의 빌드 파이프라인을 국내에 유지하며; 국경을 넘는 것을 최소화합니다.
- 전송(deliver) — 해외 호스팅 러너 앞단에(또는 대신에) 규정에 맞는 국내 자체 호스팅 러너와 자체 관리 컨트롤 플레인을 둡니다; 21YunBox가 재구축 없이 국내 계층을 세웁니다.
호스팅 서비스를 단지 도달 가능하게 하는 것은 해답이 아닙니다 — 귀사의 소스·시크릿·아티팩트는 여전히 해외에서 실행되고, 작업을 더 빨리 시작하는 것이 그것을 바꾸지 않습니다. 러너와 그것이 쥔 것을 국내에 두는 것이 해답입니다.
21YunBox의 자리 — 마이그레이션이 아니라 컴플라이언스 오버레이
귀사는 GitLab과 기존 파이프라인을 계속 씁니다. 저희는 호스팅 러너가 스스로 제공할 수 없는 부분을 더합니다: 자체 관리 GitLab＋자체 호스팅 GitLab Runner를 위한 적법한 국내 거처를 두어 귀사의 독점 소스, 주입된 시크릿, 빌드 아티팩트가 법이 요구하는 곳에 국내에 머물게 하고, 그 앞단의 개발자 접근과 모든 공개 배포 포털을 위한 규정에 맞는 ICP 비안 전송을 둡니다 — 기존 구성 주위에, 재구축도, 두 번째 코드베이스도, GitLab에서의 마이그레이션도 없이. 이미 운영 중인 툴체인의 파트너로서, 저희 중국 팀이 귀사의 PIPL 국경 간, 동의, 데이터 레지던시 의무를 귀사의 법인과 파이프라인에 비추어 정리한 뒤, 방어 가능한 중국 프레즌스가 필요로 하는 국내 러너와 전송을 세웁니다. 저희는 어떤 불법적 우회도 결코 쓰거나 권하지 않습니다.
함께 읽기:
자주 묻는 질문
제 GitLab 러너가 중국 내부에서 GitLab.com에 닿을 수 있나요?
대개 그렇고, 바로 그것이 도달성이 잘못된 시험인 이유입니다. 작업은 본토 내부에서 시작·통과하면서도, 귀사의 독점 소스, 거기 주입된 배포 키·서명 키, 그것이 쓰는 빌드 아티팩트가 모두 여전히 GitLab의 호스팅 러너에서 해외로 실행될 수 있습니다. 귀사의 구성이 방어 가능한지를 결정하는 것은 파이프라인이 돌 때 그 소스와 시크릿이 어디에 사느냐이지 러너가 연결될 수 있느냐가 아닙니다.
중국에서 GitLab CI/CD를 쓰면 법을 어기나요?
본질적으로는 아닙니다. 쟁점은 파이프라인이 쥔 것 — 귀사의 소스, 주입된 시크릿, 커미터 신원, 아티팩트 — 의 국경 간 이전과 레지던시입니다. PIPL은 귀사가 고지하고, 별도 동의를 받고, 이전 메커니즘 하나를 충족하면 국경 간 이전을 허용합니다; 데이터 국내화 의무가 추가로 적용되는지는 귀사의 역할(예: 핵심정보인프라 운영자 여부)과 다루는 개인정보 물량에 따라 달라집니다. 포괄적 금지가 아니라 법률 자문과 함께 평가할 리스크로 보시기 바랍니다.
GitLab 파이프라인의 소스와 시크릿을 중국에 어떻게 두나요?
러너를 국내에서 운영하십시오. GitLab 자신의 자체 관리 에디션＋자체 호스팅 GitLab Runner로 본토 안 귀사 자신의 인프라에서 플릿을 설치·운영하면, 체크아웃, 주입된 시크릿, 빌드 아티팩트가 국내에 머뭅니다. 21YunBox가 그 국내 자체 호스팅 계층을 ICP 비안 전송과 함께 그 앞단에 세웁니다 — 기존 GitLab 주위에, 재구축 없이. 문의하기로 구체적인 사례를 진단하십시오.
