클라우드 네이티브 플랫폼의 주권은 워크로드가 실행되거나 데이터가 저장되는 위치만으로 결정되지 않는다. CNCF가 2026년 8월 18일 게시한 분석에 따르면, CNCF 앰배서더 Chamod Perera와 WSO2의 수석 소프트웨어 엔지니어 Suvin Kodituwakku가 작성한 이 글은 주권을 입증하려면 제어 상태의 위치, 로그 및 메타데이터 경로, 키와 자격 증명에 접근할 수 있는 주체, 그리고 공급업체 서비스가 사라져도 팀이 운영을 계속할 수 있는 능력도 고려해야 한다고 설명한다.
이 분석은 주권을 단순히 설정 목록에서 리전을 선택하는 문제가 아니라 플랫폼 토폴로지의 속성으로 바라볼 것을 제안한다. CNCF의 Sandbox 단계 프로젝트이자 오픈 소스 개발자 내부 플랫폼인 OpenChoreo는 이 접근 방식을 검토할 수 있는 사례로 사용되지만, 이러한 아키텍처 원칙이 OpenChoreo에만 한정되는 것은 아니다.
서버 위치를 넘어서는 네 가지 질문
이 글은 EU Data Act, NIS-2, DORA, UK Data Use and Access Act와 같은 프레임워크에 따라 플랫폼 팀이 지리적 리전을 정하는 것 이상의 실무적 질문에 답해야 한다고 설명한다. 첫째는 테넌트 데이터에 접근할 수 있는 각 구성 요소가 어떤 법적 관할권 아래에서 운영되는가이다. 여기에는 제어 계층과 로그도 포함된다. 둘째는 공급업체가 호스팅하는 서비스가 중단되었을 때 팀이 워크로드를 실행하고, 재구축하고, 이전할 수 있는가이다.
나머지 두 질문은 국경 밖의 당사자가 키, 클러스터 상태 또는 관리 자격 증명에 접근할 수 있는지, 그리고 공급업체·하드웨어·국가를 변경할 때 워크로드를 다시 작성해야 하는지에 관한 것이다. 분석은 이러한 질문이 주로 제어와 상태가 어디에 존재하며 누가 이에 접근할 수 있는지에 초점을 둔다고 결론 내린다.
다중 계층 아키텍처는 어떻게 작동하는가?
OpenChoreo는 플랫폼을 각각 고유한 수명 주기, 보안 경계, 확장 동작을 가진 독립적인 클러스터로 나눈다.
- 제어 계층: 선언적 API를 통해 원하는 상태를 유지하고 조정 모듈을 실행하지만, 테넌트 워크로드를 실행하지는 않는다.
- 데이터 계층: 실제로 워크로드를 실행하는 호환 Kubernetes 클러스터들로 구성되며, 각각 독립적인 API 서버와 상태를 가진다.
- 모니터링 계층: 로그, 메트릭, 트레이스를 수집하고 제공한다.
- 워크플로 계층: CI 및 GitOps 작업을 실행한다.
- 경험 계층: 개발자 포털, CLI, API, MCP 인터페이스를 제공한다.
가장 중요한 요소는 연결 모델이다. 데이터, 모니터링, 워크플로 계층은 mTLS를 통해 제어 계층 게이트웨이로 인증된 송신 연결을 열지만, 제어 계층은 이 계층들에 먼저 연결하지 않는다. 따라서 규제 대상 워크로드를 호스팅하는 클러스터의 API 서버가 인터넷에 노출되지 않는다. 또한 제어 계층은 원하는 상태를 보유할 뿐 테넌트의 전체 실행 상태를 보유하지 않는다. 그러므로 제어 계층과의 연결이 끊겨도 데이터 계층은 요청 처리를 계속할 수 있다.
플랫폼 팀에 실질적으로 달라지는 점은 무엇인가?
각 데이터 계층을 특정 법적 관할권에 연결할 수 있으므로 ‘하나의 관할권, 하나의 데이터 계층’ 모델을 검토하고 감사할 수 있다. 또한 각 데이터 계층은 운영 데이터를 지역 모니터링 계층으로 전송하며, 로그와 트레이스를 제어 계층을 통해 전달하지 않는다. 이를 통해 테넌트 워크로드와 해당 텔레메트리가 지정된 지역 경계 안에 머물게 된다.
공급업체로부터 독립적으로 지속할 수 있는 능력은 각 데이터 계층이 폐쇄적인 관리형 엔드포인트가 아니라 완전하고 호환 가능한 Kubernetes 클러스터라는 점에 기반한다. 분석은 Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager, Cilium과 같은 CNCF 및 클라우드 네이티브 생태계의 오픈 소스 구성 요소를 사용하는 방법을 제시한다. 모듈식 아키텍처를 통해 구성 요소를 교체하거나 기존 모니터링 시스템을 동일한 쿼리 인터페이스에 연결할 수 있다.
시크릿과 키 보호는 External Secrets Operator와 호환되는 저장소나 운영 주체가 선택한 볼트에 맡기며, 기본 키 소유권을 강제하지 않는다. 또한 네임스페이스·프로젝트·구성 요소 수준에 세밀한 권한을 적용할 수 있고, 호출 주체가 개발자든 CLI 도구든 AI 에이전트든 관계없이 그룹을 모든 OAuth2/OIDC 아이덴티티 공급자에 연결할 수 있다.
가상 클러스터와 플랫폼 계층의 통합
이 모델은 테넌트 클러스터 패턴을 없애는 것이 아니라 보완한다. 가상 클러스터는 공유 호스트 클러스터 안에서 각 테넌트에 가상 제어 계층, API 서버, 전용 저장소를 제공한다. 이를 통해 테넌트별 전용 클러스터보다 낮은 비용으로 테넌트 간 제어 상태를 격리할 수 있다. 그러나 가상 클러스터만으로는 테넌트를 어느 관할권에서 호스팅해야 하는지, 로그를 어디로 전송해야 하는지, 또는 누가 두 환경이나 두 리전 사이에서 워크로드를 업그레이드할 권한을 가지는지를 결정할 수 없다.
여기서 플랫폼 계층이 배포 및 운영 제어를 추가한다. DataPlane 리소스에는 법적 관할권 태그를 부여할 수 있고, observabilityPlaneRef 리소스를 지역 모니터링 계층에 연결할 수 있으며, 업그레이드 경로는 워크로드가 이동할 수 있는 환경을 정의한다. 또한 개발자 포털은 바로 사용할 수 있는 경로를 제공해 사용자가 민감한 클러스터에 직접 접근해야 할 필요를 줄인다.
그러나 이 조합에는 분명한 한계가 있다. 동일한 호스트에 있는 테넌트들은 노드와 운영 체제 커널을 공유한다. 위협 모델이 테넌트별 하드웨어 격리를 요구한다면 가상 클러스터만으로는 충분하지 않으며, 실제로 독립된 데이터 계층이 필요하다.
선언적이고 감사 가능한 구성으로서의 주권
분석은 토폴로지를 선언적 Kubernetes 리소스로 표현하고 Git에 저장할 것을 제안한다. 어떤 리전이 어떤 데이터 계층을 사용하는지, 어떤 대상이 모니터링 데이터를 수신하는지, 어떤 업그레이드 경로가 허용되는지를 기록하는 방식이다. 이를 통해 새로운 관할권을 생성하는 일은 검토 가능한 풀 리퀘스트가 되고, 특정 지역에 테넌트 데이터가 존재하는 이유에 대한 답변도 제어판 스크린샷이 아니라 변경 이력을 근거로 제시할 수 있다.
그러나 다중 계층 아키텍처가 인프라를 운영하는 주체의 법적 관할권을 변경하거나 해당 주체가 적용받는 법률 체계에 대한 노출을 없애지는 않는다. 또한 경계를 그릴 뿐 그 안에서 일어나는 일을 자동으로 통제하지도 않는다. 공급망 증명, SBOM, 감사 로깅, SPIFFE/SPIRE와 같은 도구를 통한 워크로드 아이덴티티는 여전히 통합해야 하는 별도의 제어 수단이다.
마지막 제약은 운영 비용이다. 추가되는 각 클러스터에는 모니터링, 업그레이드, 백업이 필요하다. 따라서 설정한 경계가 실제 법적 또는 보안상의 중요성을 가질 때 이 아키텍처가 정당화되며, 그러한 필요가 없는 환경에서는 과도할 수 있다. 결론적으로 테넌트 클러스터를 통한 리소스 격리, 경계를 넘을 수 있는 대상을 정의하는 다중 계층 아키텍처, 버전 관리가 가능한 선언적 구성을 결합하면 주권은 계약상의 약속에서 운영하고 감사할 수 있는 속성으로 전환된다.