요즘 클라우드 업계에서 가장 많이 들리는 단어가 “소버린(sovereign)”입니다. 소버린 클라우드, 소버린 AI, AI 소버린티… 비슷한 단어들이 섞여 쓰이다 보니 정작 “그래서 우리 회사는 뭘 해야 하는데?”라는 질문에는 답이 잘 나오지 않습니다.
이 글에서는 용어를 먼저 정리하고, Google Cloud에서 국가핵심기술을 다루는 기업과 금융권 기업이 소버린티 요건을 만족하려면 AI와 데이터 영역에서 구체적으로 무엇을 챙겨야 하는지 정리합니다. 특히 많은 분들이 놓치는 LLM processing의 리전 위치 문제를 중심으로 다룹니다.
소버린? 소버린티? 용어부터 정리
두 단어는 품사가 다릅니다.
소버린티(sovereignty, 주권)
상태 또는 능력입니다. 내 데이터가 어디에 있는지, 누가 접근할 수 있는지, 어떤 법률의 적용을 받는지, 서비스가 끊겼을 때 스스로 운영을 지속할 수 있는지에 대한 통제권을 말합니다.
소버린(sovereign)
형용사입니다. “소버린 클라우드”는 그런 주권 요건을 만족하도록 설계·운영되는 클라우드를 가리킵니다.
즉 소버린티는 목표이고, 소버린 클라우드는 그 목표를 달성하기 위한 수단입니다. Google Cloud는 소버린티를 세 계층으로 나눠서 설명하는데, 이 프레임이 실무에서 요건을 분해할 때 유용합니다.
| 계층 | 질문 | 대표 수단 |
|---|---|---|
| 데이터 소버린티 | 내 데이터가 어디에 저장·처리되고, 누가 열람할 수 있는가? | 데이터 레지던시, CMEK/EKM, Access Transparency |
| 운영 소버린티 | 클라우드를 운영·지원하는 사람이 누구이고 어디에 있는가? | Assured Workloads, 파트너 운영 모델 |
| 소프트웨어(기술) 소버린티 | 특정 사업자 없이도 워크로드를 계속 돌릴 수 있는가? | 오픈소스 기반 스택, GDC, 오픈 모델 |
“소버린 클라우드 = 국내 리전에 데이터 저장” 정도로 이해하면 첫 번째 계층의 절반만 본 것입니다. 특히 AI 워크로드에서는 저장 위치보다 처리 위치가 더 어려운 문제입니다. 뒤에서 자세히 다룹니다.
왜 지금 이슈인가 — 국가핵심기술과 금융권
한국에서 소버린티 논의가 뜨거운 영역이 두 곳입니다.
국가핵심기술.
산업기술보호법상 국가핵심기술(반도체, 디스플레이, 이차전지, 조선, 자동차 등)을 보유한 기업이 관련 기술자료를 해외 사업자의 클라우드에 올리는 것은 기술 유출 관점에서 민감한 행위로 해석될 수 있습니다. 설계 도면이나 공정 데이터를 LLM에 넣어 요약·검색하게 만드는 순간, “그 프롬프트는 어느 나라 서버에서 처리되는가”가 컴플라이언스 질문이 됩니다.
금융권.
전자금융감독규정과 금융분야 클라우드컴퓨팅서비스 이용 가이드에 따라 금융회사는 클라우드 이용 시 중요도 평가, CSP 안전성 평가(금융보안원), 업무 위수탁 보고 등의 절차를 거칩니다. 망분리 규제가 단계적으로 개선되면서 생성형 AI를 업무에 활용할 수 있는 길이 열렸지만, 그 대가로 데이터 처리 위치와 접근 통제에 대한 입증 책임은 오히려 더 명확해졌습니다. “글로벌 SaaS라서 어디서 처리되는지 모릅니다”는 답변이 통하지 않는 환경입니다.
두 영역의 공통점은 이것입니다. “데이터가 국내에 저장됩니다”만으로는 부족하고, 저장·처리·접근·운영 전 과정을 설명할 수 있어야 한다는 것입니다.
Google Cloud의 소버린 스펙트럼
Google Cloud는 소버린티 요구 수준에 따라 단계적인 선택지를 제공합니다. 전부 아니면 전무가 아니라 스펙트럼입니다.
| 단계 | 구성 | 적합한 경우 |
|---|---|---|
| 1. 리전 + 통제 강화 | 서울 리전(asia-northeast3) + Assured Workloads + CMEK/EKM + VPC-SC | 금융권 일반 워크로드, 대부분의 규제 대응 |
| 2. Sovereign Controls | 파트너 감독 하에 운영되는 소버린 구성 (유럽의 T-Systems 모델 등) | 운영 주권까지 계약으로 입증해야 하는 경우 |
| 3. Google Distributed Cloud (Connected) | 고객 데이터센터에 Google Cloud 인프라 설치, Google 클라우드와 연결 | 데이터는 온프레미스, 관리는 클라우드 |
| 4. Google Distributed Cloud (Air-gapped) | 인터넷과 완전히 단절된 독립 운영 환경 | 국가핵심기술, 국방·공공 최고 수위 요건 |
포인트는 요건에 맞는 최소 단계를 선택하는 것입니다. 모든 워크로드를 air-gapped로 몰면 클라우드를 쓰는 의미가 없어지고, 반대로 국가핵심기술 데이터를 일반 리전 구성에 올리면 감사에서 막힙니다. 데이터 분류(classification)가 선행되어야 하는 이유입니다.
데이터 영역에서 신경 쓸 것 4가지
AI 얘기 전에 기초 공사부터 확인해야 합니다. 이 4가지가 안 되어 있으면 AI 소버린티는 논할 수 없습니다.
1. 데이터 레지던시를 조직 정책으로 강제. 콘솔에서 리전을 서울로 고르는 것과, Organization Policy의 리소스 위치 제약(Resource Location Restriction)으로 asia-northeast3 외 리소스 생성을 원천 차단하는 것은 다릅니다. 규제 대응은 후자여야 합니다. “실수로 다른 리전에 버킷을 만들 수 없는 상태”를 만들어야 감사에 대응할 수 있습니다.
2. 키 주권 — CMEK, 그리고 EKM. 고객 관리 암호화 키(CMEK)는 기본이고, 더 높은 수위가 필요하면 Cloud EKM(External Key Manager)으로 암호화 키 자체를 국내의 외부 키 관리 시스템에 보관할 수 있습니다. 키가 국내에 있고 우리가 쥐고 있으면, 해외에서 데이터에 접근하려 해도 키 없이는 복호화가 불가능합니다. 여기에 Key Access Justifications를 붙이면 Google이 키를 사용하려는 사유를 건별로 확인하고 거부할 수 있습니다.
3. 접근 투명성과 접근 승인. Access Transparency는 Google 직원이 지원 목적 등으로 고객 데이터에 접근한 내역을 로그로 남기고, Access Approval은 그 접근을 사전 승인제로 바꿉니다. “CSP 직원이 우리 데이터에 접근할 수 있는가”라는 단골 감사 질문에 대한 기술적 답변입니다.
4. VPC Service Controls로 경계 설정. IAM이 뚫려도 데이터가 조직 경계 밖으로 나가지 못하게 하는 서비스 경계(perimeter)입니다. 특히 뒤에 나올 Vertex AI를 경계 안에 넣어서, AI API 호출 자체가 통제된 네트워크 안에서만 일어나도록 해야 합니다.
AI 영역에서 신경 쓸 것 — 핵심은 “LLM이 어디에서 도는가”
이제 본론입니다. 데이터 레지던시는 익숙한 주제지만, LLM 워크로드는 저장이 아니라 처리(processing)가 중심이라서 기존 체크리스트가 그대로 적용되지 않습니다.
1. Global endpoint를 쓰면 안 됩니다
Vertex AI에서 Gemini를 호출하는 방법은 크게 두 가지입니다.
- Global endpoint — 가용성과 처리량을 우선해서, 요청을 전 세계 리전 중 여유 있는 곳으로 라우팅합니다. 프롬프트가 어느 나라에서 처리될지 보장되지 않습니다.
- Regional endpoint — 지정한 리전 안에서 추론이 수행됩니다.
Global endpoint는 편하고 쿼터도 넉넉하지만, 규제 워크로드에서는 선택지가 아닙니다. 금융 데이터나 기술자료가 포함된 프롬프트가 어느 리전의 가속기에서 처리될지 모른다는 것은, 감사 관점에서 “국외 반출 여부를 알 수 없다”는 뜻이기 때문입니다. 규제 대상 워크로드는 반드시 regional endpoint를 쓰고, 원하는 모델이 해당 리전에서 서빙되는지를 확인해야 합니다.
여기서 현실적인 문제가 나옵니다. 모든 모델이 모든 리전에 있지 않습니다. 최신 모델일수록 미국·유럽 리전에 먼저 풀리고, 서울 리전 지원은 늦거나 일부 모델에 한정되는 경우가 많습니다. 그래서 프로젝트 초기에 “우리가 쓰려는 모델 버전이 asia-northeast3 regional endpoint에서 제공되는가”를 반드시 확인하고, 안 된다면 (1) 지원되는 이전 버전 모델을 쓰거나 (2) 규제 해석상 허용 가능한 리전을 법무·컴플라이언스와 협의하거나 (3) 아키텍처를 바꿔야 합니다. 이걸 PoC 끝나고 확인하면 프로젝트가 뒤집어집니다.
2. “저장 레지던시”와 “ML processing 레지던시”는 다른 계약입니다
Google Cloud의 데이터 레지던시 커밋은 기본적으로 저장 데이터(data at rest)에 대한 것입니다. Vertex AI에서는 여기에 더해 ML processing에 대한 레지던시 커밋이 별도로 존재하며, 지원되는 리전 목록도 다릅니다. 즉 다음 세 가지를 구분해서 확인해야 합니다.
- 프롬프트·튜닝 데이터·응답이 저장되는 위치
- 추론, 즉 ML processing이 수행되는 위치
- 전송 구간(in transit)의 경로
계약서와 서비스 약관에서 “data residency for ML processing”이 우리가 쓰는 리전에 적용되는지 확인하는 것이 실무 포인트입니다. 저장은 서울인데 처리는 다른 리전인 구성이 기술적으로 얼마든지 가능하기 때문입니다.
3. 프롬프트가 남는가 — 로깅, 캐싱, 학습 사용 여부
LLM 서비스에서 데이터가 새는 경로는 저장소가 아니라 부가 기능인 경우가 많습니다.
- 어뷰즈 모니터링 캐싱 — Vertex AI는 남용 탐지를 위해 프롬프트를 짧은 기간 캐싱할 수 있습니다. 규제 워크로드라면 zero data retention 구성을 신청해서 캐싱을 끄는 것을 검토해야 합니다.
- 요청/응답 로깅 — 운영 편의를 위해 켜는 로깅이 프롬프트 원문을 로그 저장소에 남깁니다. 로그 버킷의 리전과 보존 기간, 접근 권한까지 데이터 자산으로 관리해야 합니다.
- 학습 사용 여부 — Google Cloud는 고객 데이터를 파운데이션 모델 학습에 사용하지 않는다는 것을 계약으로 확약합니다. 이것은 소비자용 Gemini 앱과 기업용 Vertex AI의 가장 큰 차이이며, 감사 대응 시 근거 문서로 챙겨둬야 하는 항목입니다.
4. Provisioned Throughput으로 리전을 고정
종량제(on-demand) 호출은 트래픽이 몰리면 리전 간 이동 유혹이 생기지만, Provisioned Throughput은 특정 리전의 처리 용량을 예약하는 방식이라 처리 위치 고정과 성능 보장을 동시에 얻습니다. 규제 워크로드가 프로덕션에 가면 사실상 필수 옵션이라고 봐야 합니다.
5. RAG 파이프라인은 전 구간의 리전 정합성을 봐야 합니다
LLM 엔드포인트만 서울로 고정하고 안심하면 안 됩니다. RAG 파이프라인은 구성 요소가 많습니다.
- 임베딩 모델 — 임베딩 API 호출도 LLM 추론과 동일하게 처리 리전을 확인해야 합니다. 원문이 그대로 들어가는 호출입니다.
- 벡터 저장소 — Vector Search 인덱스, 검색용 데이터 스토어의 리전.
- Grounding with Google Search — 검색 그라운딩을 켜면 쿼리가 Google 검색 인프라로 나갑니다. 편리한 기능이지만 규제 데이터가 포함된 프롬프트에는 켜면 안 됩니다. 내부 데이터 그라운딩과 외부 검색 그라운딩을 워크로드 등급에 따라 분리해야 합니다.
파이프라인 다이어그램을 그려놓고 화살표마다 “이 데이터는 어느 리전을 지나는가”를 적어보는 것이 가장 확실한 점검 방법입니다.
6. 같은 Gemini라도 경로가 다르면 다른 제품입니다
Gemini 앱(소비자), Workspace의 Gemini, Vertex AI의 Gemini는 이름만 같지 데이터 처리 조건이 전부 다릅니다. 직원들이 브라우저에서 소비자용 Gemini에 업무 문서를 붙여넣는 순간 지금까지의 설계가 전부 무의미해집니다. 규제 데이터는 Vertex AI 경로만 허용하고, 나머지는 DLP와 프록시 정책으로 차단하는 운영 통제가 기술 설계만큼 중요합니다.
7. 최고 수위 — 모델을 데이터 옆으로 가져오기
리전 통제로도 부족한 국가핵심기술급 데이터라면 방향을 뒤집어야 합니다. 데이터를 모델에 보내는 게 아니라 모델을 데이터가 있는 곳으로 가져오는 것입니다.
- Google Distributed Cloud air-gapped에서 Gemini 서빙 — 인터넷과 단절된 고객 시설 안에서 Gemini 모델을 운영하는 구성입니다. 프롬프트가 시설 밖으로 한 바이트도 나가지 않습니다.
- 오픈 모델 자체 서빙 — Gemma 같은 오픈 모델을 GKE나 온프레미스 GPU에서 직접 서빙하면 모델 가중치까지 우리 손에 있으니 소프트웨어 소버린티 관점에서 가장 강한 구성입니다. 대신 모델 성능과 운영 부담은 감수해야 합니다.
그래서, Gemini LLM API는 소버린티를 만족하는가?
여기까지 읽었다면 자연스럽게 나오는 질문입니다. 답은 “어느 경로로 쓰느냐에 따라 다르고, 그마저도 지금은 시한부”입니다.
경로별 결론
| 호출 경로 | 소버린티 관점 결론 |
|---|---|
| Gemini Developer API (AI Studio) | 불만족. 요청이 전 세계 글로벌 풀에서 처리되는 구조이고, 처리 리전을 지정하는 기능 자체가 없습니다. 규제 워크로드에서는 검토 대상조차 아닙니다. |
| Vertex AI + global endpoint | 불만족. Google 문서 스스로 “ML processing 요건이 있으면 global endpoint를 쓰지 말라”고 명시합니다. 어느 리전에서 처리될지 통제할 수도, 알 수도 없기 때문입니다. |
| Vertex AI + regional endpoint | 조건부 만족. 서울 리전 지정 + ML processing 레지던시 커밋 + VPC-SC·CMEK 등 통제를 결합하면 처리 위치까지 입증 가능한 유일한 Gemini API 경로입니다. |
즉 “Gemini API가 소버린티를 만족하는가”라는 질문의 실질적 답은 “Vertex AI regional endpoint에서 서빙되는 모델을 쓰는 동안만 그렇다”입니다. 그리고 바로 여기에 시한 문제가 있습니다.
2026년 10월 16일 — 시한부 선고
현재 regional endpoint에서 처리 위치를 고정할 수 있는 모델은 사실상 Gemini 2.5 세대(2.5 Pro / 2.5 Flash / 2.5 Flash-Lite)입니다. 그런데 이 세 모델은 Vertex AI에서 2026년 10월 16일 선셋(sunset, 서비스 종료) 이 예고되어 있습니다. 은퇴 한 달 전부터 온라인 추론·배치 추론·튜닝의 신규 접근이 차단되고, 은퇴일 이후에는 해당 모델 ID를 호출하면 404가 반환됩니다.
문제는 후속 세대입니다. Gemini 3.x는 (특히 Pro급 모델은) global endpoint 전용으로 출시되고 있습니다. regional endpoint로 호출하면 모델을 찾을 수 없다는 에러가 돌아옵니다. 앞서 본 대로 global endpoint는 처리 리전을 보장하지 않으므로, 이 구성은 규제 워크로드에서 쓸 수 없습니다.
두 사실을 겹치면 결론이 나옵니다. 선셋 시점까지 Gemini 3.x의 서울 리전 regional 서빙과 ML processing 레지던시 커밋이 열리지 않으면, 2.5가 내려가는 순간 “리전을 고정해서 소버린티를 만족하는 Gemini API”라는 선택지 자체가 사라집니다. 남는 방법은 클라우드 API가 아니라 GDC air-gapped에서 Gemini를 서빙하거나 오픈 모델을 자체 서빙하는 것뿐인데, 이것은 엔드포인트 교체가 아니라 아키텍처 교체입니다. 규제 심사를 다시 받는 수준의 변화입니다.
단서 하나: Google은 10월 16일을 “가장 이른(no earlier than) 은퇴일”로 공지했고, Gemini 3 GA 이후 최소 6개월 예고와 함께 확정 일자를 정하겠다고 밝혔습니다. 연기될 수는 있지만, 연기는 유예일 뿐 구조적 해법이 아닙니다.
지금 해야 할 일
- 2.5 기반 규제 워크로드의 마이그레이션 플랜을 지금 세우세요. 모델 교체는 엔드포인트 문자열 수정이 아닙니다. 프롬프트 호환성, 출력 품질, SDK 전환(구 Vertex AI SDK → Google Gen AI SDK) 검증에 수개월이 걸립니다.
- Gemini 3.x의 서울 리전 서빙·레지던시 커밋 로드맵을 어카운트 팀에 공식 확인하세요. 구두 답변이 아니라 계약·문서 근거로 받아야 감사에 쓸 수 있습니다.
- 열리지 않는 시나리오의 plan B를 미리 견적 내세요. GDC 또는 오픈 모델 자체 서빙으로 전환하는 비용·기간을 알아야, 선셋 일정에 끌려다니지 않고 협상할 수 있습니다.
시나리오별 권장 구성
지금까지의 내용을 세 가지 대표 시나리오로 매핑하면 이렇습니다.
| 시나리오 | 데이터 등급 | 권장 구성 |
|---|---|---|
| 금융 고객상담 챗봇 (가명처리 데이터) | 규제 대상, 중요도 중 | 서울 리전 regional endpoint + VPC-SC + CMEK + 요청 로깅 통제 + 검색 그라운딩 차단 |
| 사내 문서 RAG (내부 중요정보) | 규제 대상, 중요도 상 | 위 구성 + EKM(국내 키) + Access Approval + Provisioned Throughput + zero data retention |
| 국가핵심기술 설계·공정 데이터 | 최고 수위 | GDC air-gapped + Gemini on GDC 또는 오픈 모델 자체 서빙, 클라우드 API 호출 자체를 배제 |
마무리 — 소버린티는 리전 선택이 아니라 설계입니다
정리하면 이렇습니다.
- 용어를 구분하세요. 소버린티는 통제권이라는 목표이고, 소버린 클라우드는 수단입니다. “서울 리전 씁니다”는 소버린티의 일부일 뿐입니다.
- 데이터 기초 공사가 먼저입니다. 조직 정책으로 강제된 레지던시, 국내 보관 키, 접근 투명성, 서비스 경계 — 이 네 가지 없이 AI 소버린티는 없습니다.
- AI에서는 저장이 아니라 처리 위치를 물으세요. Global endpoint 배제, regional endpoint의 모델 지원 확인, ML processing 레지던시 커밋 확인, 프롬프트 로깅·캐싱 통제, RAG 전 구간의 리전 정합성 — 이것이 LLM 시대의 소버린티 체크리스트입니다.
- 모델 수명주기도 소버린티 리스크입니다. 지금 regional endpoint를 만족하는 Gemini 2.5 세대는 2026년 10월 16일 선셋이 예고되어 있고, 후속 3.x는 global endpoint 전용입니다. 서울 리전 서빙이 열리지 않은 채 선셋이 오면 리전 고정 방식 자체가 사라지므로, 마이그레이션 플랜과 plan B를 미리 준비해야 합니다.
- 등급에 맞는 단계를 고르세요. 모든 것을 air-gapped로 몰지도, 국가핵심기술을 일반 구성에 올리지도 마세요. 데이터 분류가 아키텍처를 결정합니다.
모델 리전 지원, 레지던시 커밋 범위, 규제 해석은 계속 바뀝니다. 이 글의 프레임으로 질문 목록을 만들되, 개별 항목은 계약 시점의 최신 문서와 법무 검토로 확정하시기 바랍니다. 소버린티는 한 번 사면 끝나는 제품이 아니라, 데이터 분류에서 시작해서 엔드포인트 선택까지 이어지는 설계의 연속입니다.