AI SECURITY · DATA SOVEREIGNTY · FINANCIAL AI · CLOUD
데이터가 한국에 있으면
정말 ‘한국에 있는’ 걸까?
AI 시대의 Data Residency vs Data Sovereignty
최근 미국의 AI 담당자와 On-premise Model Hosting, 조금 더 정확히는 Cloud 기술을 이용해 고객사 내부 인프라에 모델을 배포·운영하는 방식에 대해 이야기할 일이 있었다.
Data Security 이야기를 하던 중 꽤 흥미로운 이야기가 나왔다.
“한국은 둘 다 중요하게 보는 것 같던데? 제일 까다로운 시장 아닐까?”
물론 한 사람의 경험을 지역 전체의 특성으로 일반화할 수는 없다. 실제로 아시아도 한국·일본·싱가포르 등 국가마다 법과 규제 환경이 꽤 다르다.
그런데 이 대화를 하고 나니 한 가지 질문이 머릿속에 남았다.
정확히 무슨 뜻일까?
서울 Region에 저장되어 있다는 뜻일까?
그런데 해외 사업자의 운영자가 접근할 수 있다면? 암호화 Key의 실질적인 통제권이 Provider에 있다면? Prompt는 국내에서 처리되지만 Log나 Telemetry가 다른 국가로 이동한다면?
그리고 모델은 우리 데이터센터 GPU에서 돌지만 Control Plane, Model Update, Monitoring을 위해 계속 Public Cloud와 연결되어 있어야 한다면?
바로 여기서 Data Residency와 Data Sovereignty의 차이가 시작된다.
Data Sovereignty = 데이터와 시스템을 누가, 어떤 법 아래에서 통제하는가
AI Sovereignty = 여기에 Model · Compute · Key · Operation · Supply Chain까지 포함한다.
1. 가장 쉬운 비유: 금고가 서울에 있다고 끝이 아니다
은행이 중요한 서류를 보관하기 위해 서울에 금고를 빌렸다고 생각해보자.
그런데 Security 담당자가 질문을 이어간다.
해외 직원도 원격으로 열 수 있는가?
어느 나라 법률의 영향을 받는 회사가 운영하는가?
백업 복사본은 어디에 있는가?
사업자와 연결이 끊겨도 금고를 사용할 수 있는가?
갑자기 이야기가 달라진다.
“어디에 있는가?”와 “누가 통제하는가?”는 같은 질문이 아니다.
전자가 Residency라면 후자가 Sovereignty에 더 가깝다.
2. Residency, Localization, Sovereignty — 비슷해 보여도 다르다
| 개념 | 핵심 질문 | 예시 |
|---|---|---|
| Data Localization | 특정 국가 안에 반드시 있어야 하는가? | 법·정책상 국내 저장/처리 요구 |
| Data Residency | 어디에 저장·처리되는가? | Seoul Region에 Storage·DB 배치 |
| Data Sovereignty | 누가 어떤 법과 권한으로 통제하는가? | Operator · Key · Jurisdiction · Audit |
여기서 중요한 점은 이 용어들의 정의가 모든 국가와 기관에서 완전히 동일하지는 않다는 것이다. 따라서 실제 Architecture Review에서는 용어 자체보다 요구되는 Control을 구체적으로 분해하는 것이 더 중요하다.
3. AI에서는 Residency가 더 복잡해진다
전통적인 시스템에서는 “고객 데이터가 DB 어디에 있나?”를 추적하면 어느 정도 답이 나왔다.
RAG와 LLM에서는 그렇지 않다.
↓ Parsing
Chunk
↓ Embedding
Vector Index
↓ Retrieval
Prompt + Context
↓ Inference
Response
↓ Monitoring
Log · Trace · Telemetry
원본 문서 하나가 AI Pipeline에 들어가면 Chunk, Embedding, Vector Index, Prompt Context, Cache, Log 같은 여러 파생 데이터가 만들어진다.
Fine-tuning이라면 Dataset, Checkpoint, Adapter, Evaluation Artifact까지 생긴다.
4. 데이터는 서울에 있다. 그런데 해외 운영자가 접근할 수 있다면?
여기서 Sovereignty 문제가 등장한다.
Jurisdiction — 어느 국가의 법이 영향을 미치는가?
Operator — Provider 직원이 접근할 수 있는가?
Cryptography — Key의 실질적 통제자는 누구인가?
Operation — 누가 운영·지원·복구하는가?
Technology — 특정 Provider와 단절되어도 운영 가능한가?
그래서 Sovereignty를 단순히 “데이터를 국내에 둔다”라고 이해하면 절반만 보는 것이다.
Residency는 Sovereignty를 구성하는 중요한 Control이지만, Sovereignty 전체는 아니다.
5. 그래서 On-prem Model Hosting도 생각보다 단순하지 않다
처음 이야기로 돌아가 보자.
Model을 금융회사 내부 GPU에 올리면 꽤 많은 문제가 해결된다. Prompt와 고객 데이터가 Public Model API로 나가지 않고, Model Inference도 내부 Network에서 수행할 수 있다.
그렇다고 바로 “Sovereign AI”가 되는 것은 아니다.
Control Plane은 Public Cloud인가?
Model Artifact는 어디에서 내려오는가?
Telemetry는 Cloud로 올라가는가?
License 검증에 Internet 연결이 필요한가?
Provider Support Engineer가 접근 가능한가?
Model Update를 Provider가 통제하는가?
완전 Disconnected 상태에서도 추론이 가능한가?
즉 Compute Location과 Operational Sovereignty는 다른 문제다.
진짜 중요한 것은 GPU가 어느 건물에 있느냐보다 Data Plane · Control Plane · Management Plane의 경계가 어디까지인가를 보는 것이다.
6. 나라별로도 보는 포인트가 조금씩 다르다
미국 담당자와의 대화에서 나온 “아시아는 Sovereignty를 더 보는 것 같다”는 이야기는 흥미로운 관찰이지만, 실제 규제는 그렇게 단순하게 지역별 한 줄로 나눌 수 없다.
다만 Architecture 관점에서 각 지역에서 자주 부각되는 질문을 아주 거칠게 요약하면 다음과 같이 볼 수 있다.
| 지역 | 눈여겨볼 관점 | 질문 |
|---|---|---|
| 🇺🇸 US | Jurisdiction / Lawful Access | Provider의 법적 통제 범위는 어디까지인가? |
| 🇪🇺 EU | Data + Legal + Technology Sovereignty | EU의 법·데이터·기술 통제 아래 얼마나 독립적인가? |
| 🇦🇺 Australia | Hosting / Operational Control | 민감 시스템을 누가 소유·운영·통제하는가? |
| 🌏 Asia | 국가별 차이가 큼 | Cross-border와 Cloud 규칙을 국가별로 어떻게 적용하는가? |
| 🇰🇷 Korea 금융 | Data + Network + Access + Audit | AI 전체 Data Flow를 금융 보안·감독 체계 안에서 통제할 수 있는가? |
특히 EU의 움직임은 흥미롭다. 최근의 Sovereign Cloud 논의는 단순 Residency를 넘어 Legal/Jurisdictional, Data & AI, Operational, Supply Chain, Technological Control까지 범위를 넓히고 있다.
일본도 재미있는 예다. 서버가 일본에 있느냐만 보는 것이 아니라 해외 Cloud 사업자가 실제로 그 개인정보를 취급하는지에 따라 판단이 달라질 수 있다.
결국 “Asia = Sovereignty”처럼 단순화하기보다는 Country × Industry × Data Classification으로 보는 것이 정확하다.
7. 그리고 한국 금융권 — 농담처럼 “둘 다”가 꽤 정확한 이유
미국 담당자가 “한국은 Residency도 중요하고 Sovereignty도 중요해서 까다로운 것 같다”고 농담했지만, 금융 AI Architecture를 설계해보면 왜 그런 인상을 받을 수 있는지는 이해된다.
한국 금융권에서는 단순히 Cloud Region만 보는 것이 아니다.
Derived Data — Prompt·Embedding·Vector·Log는 어디에 있는가?
Access — CSP·Model Provider가 접근할 수 있는가?
Network — Private Endpoint와 Egress Control이 가능한가?
Key — CMK/HSM 등 암호화 Key를 누가 통제하는가?
Audit — 관리자·Model·Data Access를 추적할 수 있는가?
Operation — 장애·지원·변경·Model Update를 누가 수행하는가?
BCP — Cloud나 특정 Model 장애 시 중요 업무를 유지할 수 있는가?
다만 한국 금융권도 방향은 바뀌고 있다.
과거의 강한 물리적 망분리 중심 접근에서 벗어나, 금융당국은 생성형 AI와 SaaS 활용 범위를 단계적으로 확대하면서 “자율보안-결과책임” 방향으로 보안체계를 전환하고 있다. 2026년에는 일정한 보안 규율을 전제로 내부 업무망의 SaaS 활용에 대한 망분리 예외도 제도화됐다.
“AI 데이터를 자유롭게 외부로 보내도 된다”는 의미는 아니다.
오히려 물리적 차단 하나에 의존하던 방식에서 Data Classification · IAM · Network · Encryption · Monitoring · Audit 같은 세밀한 통제로 책임이 이동하는 것으로 보는 편이 맞다.
8. 금융 AI에서 가장 위험한 착각: “LLM이 출력하지 않았으니 괜찮다”
Sovereignty 이야기를 RAG에 적용하면 아주 중요한 원칙 하나가 나온다.
이미 Data Access는 발생했다.
권한 없는 고객 문서가 Retrieval되어 Prompt Context에 포함된 뒤 외부 Model Endpoint로 전달됐다면, 최종 답변에서 그 내용이 출력되지 않았다고 해서 없던 일이 되지는 않는다.
따라서 금융 RAG에서 Authorization은 Generation 이후가 아니라 Retrieval 이전에 적용되어야 한다.
↓
Authorization / Eligibility
↓
Allowed Documents Only
↓
Retrieval
↓
LLM
9. Sovereign AI Architecture를 그려보면
이 그림에서 중요한 것은 특정 Vendor의 Sovereign Cloud 상품이 아니다.
Sovereignty는 제품명이 아니라 Architecture Property다.
Public Cloud에서도 필요한 Control을 충분히 구현할 수 있는 Workload가 있고, 반대로 고도의 통제가 필요한 Workload라면 Private Cloud, Local Model Hosting, 심지어 Disconnected Architecture까지 검토할 수 있다.
10. 그렇다고 모든 AI를 On-prem으로 가져오면 될까?
그것도 정답은 아니다.
| 선택 | 얻는 것 | 떠안는 것 |
|---|---|---|
| Managed AI | 빠른 구축·최신 모델 | Provider 의존·Data Boundary 검증 |
| Private / Local AI | 높은 Data·Runtime 통제 | GPU·Serving·Patch·Capacity 운영 |
| Disconnected | 높은 독립성 | Update·Model Supply Chain·운영 복잡도 |
Sovereignty가 강해질수록 대체로 통제권은 증가하지만 운영 책임도 함께 증가한다.
그래서 현실적인 Enterprise Architecture는 모든 AI를 가장 폐쇄적인 환경에 넣는 것이 아니라, Data Classification × Workload Risk에 따라 필요한 통제 수준을 선택하는 것이다.
11. 그래서 다음 AI Platform Review에서는 질문을 바꿔야 한다
예전에는 Vendor에게 이렇게 물었다.
이제는 그 다음 질문들이 더 중요하다.
② Embedding과 Vector Index도 같은 Boundary에 있는가?
③ Log·Trace·Abuse Monitoring Data는 어디로 가는가?
④ Provider Operator가 Plaintext에 접근할 수 있는가?
⑤ Encryption Key를 고객이 통제할 수 있는가?
⑥ Model Artifact와 Update Source는 어디인가?
⑦ Control Plane은 어느 국가에서 운영되는가?
⑧ Public Cloud 연결이 끊겨도 추론 가능한가?
⑨ Model Version을 고정하고 재현할 수 있는가?
⑩ 계약 종료 시 Data·Vector·Log·Model Artifact를 어떻게 삭제·이관하는가?
여기까지 질문하고 나면 비로소 “우리 데이터가 어디에 있는가?”에서 “우리 AI를 실제로 누가 통제하는가?”로 넘어간다.
12. 마무리 — 서울에 있는 GPU만 보고 안심할 수 없는 이유
미국 AI 담당자와 나눈 대화는 가벼운 농담에서 시작했다.
“한국은 Residency도 보고 Sovereignty도 보니 꽤 까다로운 것 같다.”
그런데 AI Architecture 관점에서 생각해보면 이 말이 꽤 재미있는 질문을 던진다.
“데이터가 어디에 있는가?”
Sovereignty는 한 번 더 묻는다.
“그 데이터를 누가 통제할 수 있는가?”
AI Sovereignty는 여기서 한 단계 더 간다.
“데이터·모델·연산·운영 전체의 통제권은 어디에 있는가?”
그래서 Model을 On-prem에 올렸다는 사실도, 서울 Region을 선택했다는 사실도, CMK를 사용한다는 사실도 각각 중요한 Control이지만 그 하나가 정답은 아니다.
AI 시대의 Security Architecture에서 더 중요한 것은 데이터와 모델이 움직이는 전체 Lifecycle을 그리고, 우리가 통제권을 잃는 지점을 찾아내는 것이다.
보다 한 단계 더 좋은 질문은
“어디서부터 우리가 통제할 수 없습니까?”
References
- Microsoft Learn — AI Workloads and Sovereignty
- Microsoft Learn — Digital Sovereignty / Sovereign Private Cloud / Azure Local
- AWS Well-Architected — Digital Sovereignty Lens
- European Commission — Cloud Sovereignty Framework
- U.S. Department of Justice — CLOUD Act Resources
- Japan Personal Information Protection Commission — APPI Cloud / Overseas Server FAQ
- Australian Government — Hosting Certification Framework
- 금융위원회 — 금융분야 망분리 개선 로드맵
- 금융위원회 — 금융회사 내부 업무망 SaaS 망분리 규제 개선, 2026
- 금융위원회 — 금융권 AI 전환 및 AI 보안위협 대응, 2026
'AI 보안' 카테고리의 다른 글
| [AI 보안] 폐쇄망이면 안전하다고? 문서 한 줄이 AI 에이전트를 조종하는 법 (0) | 2026.09.08 |
|---|---|
| [AI 보안] 서버 대신 AI를 속이면 된다? Prompt Injection부터 Agent 해킹까지 - 2026 AI 보안 완전정복 (0) | 2026.09.06 |
| [AI 보안] 혁신금융서비스 실사 — 생성형 AI 플랫폼은 무엇을 증명해야 할까 (0) | 2026.09.04 |