[데이터주권 시리즈] 주권 확보를 위한 다섯 가지 요건

데이터 소재지만으로는 구분되지 않는 지점

1편에서는 데이터가 어디에 저장되는지와 데이터를 누가 통제하는지가 다른 문제라는 점을 알아보았습니다. 2편에서는 저장 위치가 역내여도 데이터가 오가는 경로는 역외를 지날 수 있다는 사실을 확인했죠. 두 편 모두 무엇이 문제인지를 짚는 글이었습니다. 그렇다면 주권을 갖췄다고 말하려면 실제로 무엇이 있어야 할까요?

데이터 소재지는 판정이 단순합니다. 역내에 있거나 없거나 둘 중 하나입니다. 역내에 데이터센터를 둔 사업자가 늘어날수록 고르는 쪽에서는 사업자 간 차이를 확인할 근거가 사라집니다. 모든 사업자가 역내 소재라는 같은 조건을 충족하기 때문입니다.

유럽연합 집행위원회가 2025년 10월에 공개한 클라우드 주권 프레임워크(Cloud Sovereignty Framework)¹는 이 문제를 등급으로 정리했습니다. 주권 상태를 SEAL-0부터 SEAL-4까지 다섯 단계로 나눴는데요, 이중 두 번째 단계인 SEAL-1의 설명을 주목해야합니다. SEAL-1은 유럽연합 법이 형식적으로는 적용되지만 실질적인 집행력은 제한되고 서비스와 기술과 운영은 역외 제3자의 배타적 통제 아래 있는 상태를 가리킵니다. 즉 소재지는 충족했으나 통제권은 없는 상태에 대해 유럽연합이 공식 등급을 붙여둔 것이 SEAL-1 단계입니다.

1. European Commission DG DIGIT, Cloud Sovereignty Framework Version 1.2.1, 2025

데이터 주권 요건이란 무엇인가

데이터 주권 요건 정의

데이터 주권 요건은 데이터에 대한 통제권이 역내에 실제로 귀속되는지를 항목별로 나눠 보는 판정 기준입니다. 소재지는 역내에 있는지 하나만 확인합니다. 이와 달리 주권 요건은 소유 구조·운영 권한·암호화 키·공급망·이동 경로라는 다섯 갈래를 각각 따로 봅니다. 다섯 요건 가운데 충족된 항목이 많을수록 역외 관할이 데이터에 닿을 수 있는 통로가 줄어들고, 충족되지 않은 요건은 그 자체로 노출 지점이 됩니다.

데이터 주권 다섯 가지 요건은 실무에서 흔히 꼽는 항목입니다. 앞으로 나오는 요건은 아래 세 문서를 근거로 삼고 있습니다.

기준	성격	이 글에서 쓰는 방식
클라우드 주권 프레임워크(CSF) · 유럽연합 집행위원회 · 2025년 10월	조달에서 사업자를 평가하기 위한 프레임워크입니다. 인증이나 자격 제도가 아니며 통과와 탈락을 가르지 않습니다.	각 요건이 무엇을 보는 것인지를 정의하는 틀로 씁니다.
SecNumCloud 3.2 · 프랑스 국가정보시스템보안청(ANSSI) · 2022년 3월판	국가가 발급하는 자격(qualification)입니다. 충족해야 할 조항이 명시돼 있습니다.	요건이 실제로 어느 수준까지 요구되는지 보여주는 사례로 씁니다.
EUCS · 유럽사이버보안청(ENISA)	유럽연합 차원의 인증 체계이나 아직 채택되지 않았습니다.	근거로 쓰지 않습니다. 주권 인증으로 오해되는 경우가 있어 현황만 밝힙니다.

세 문서의 효력은 서로 다릅니다. SecNumCloud만이 사업자가 충족해야 할 의무를 담고 있습니다. CSF는 사업자를 비교하는 도구이며, EUCS는 아직 효력이 없습니다. 사업자가 세 이름을 나란히 제시하더라도 세 가지가 같은 수준의 보증을 뜻하지는 않습니다.

EUCS는 오랫동안 주권 요건 포함 여부를 두고 논의가 이어졌습니다. 유럽연합 집행위원회는 2026년 입법 제안에서 사이버보안 인증이 기술적 요소를 넘어선 주권 문제를 다루기에는 적합하지 않다고 보고, 주권 요건을 별도의 입법으로 분리²하는 방향을 제시했습니다. 유럽 안에서도 주권 요건을 판단할 때 하나의 인증으로만 해결하기 어렵다는 입장이 나오고 있습니다.

유럽연합 집행위원회는 CSF에서 여덟 개 주권 목표를 두고 각각에 가중치를 매겼습니다. 가장 높은 항목은 공급망으로 20%이고 가장 낮은 항목은 환경으로 5%¹입니다. 어디에 무게를 뒀는지가 그대로 드러납니다.

2. European Commission, COM(2026) 502 final, 2026

데이터 주권 요건 다섯 가지 한눈에 보기

요건	무엇을 보는가	대응하는 기준	비었을 때 남는 노출
① 역내 법인 실체	사업자가 역내 법에 속하는가	CSF SOV-1·SOV-2 / SecNumCloud 19.6	역외 법 집행 명령이 모회사를 통해 닿을 수 있습니다
② 운영 통제권	누가 접근·운영 권한을 쥐는가	CSF SOV-4 / SecNumCloud 9.7	역외 인력이 감독 없이 데이터에 접근할 수 있습니다
③ 로컬 키 관리	암호화 키를 누가 통제하는가	CSF SOV-3 / SecNumCloud 10.1·10.5	사업자에게 내려진 명령이 데이터에 닿을 수 있습니다
④ 공급망 투명성	하위 위탁 사슬이 드러나는가	CSF SOV-5 / SecNumCloud 15.1	계약하지 않은 곳이 데이터를 다룰 수 있습니다
⑤ 네트워크 경로 통제	이동 경로가 역내에 묶이는가	CSF SOV-3 일부 / SecNumCloud 13.1	저장은 역내인데 경로는 역외를 지납니다

다섯 요건을 모두 충족하는 선택이 언제나 정답은 아닙니다. 요건을 높일수록 고를 수 있는 사업자가 줄고 비용은 올라갑니다. 그래서 다섯 가지를 모두 채우려 하기보다 자사의 상황에 맞춰 어느 요건을 먼저 볼지 정하는 편이 현실적입니다. 다루는 데이터가 무엇인지, 유출됐을 때 영향이 어디까지 미치는지, 적용받는 규제가 있는지를 먼저 확인하면 우선순위가 나옵니다. 아래 다섯 가지는 그 검토에 쓰는 기준입니다.

① 역내 법인 실체: 계약 상대 법인의 관할 확인

역내 법인 실체는 서비스를 제공하는 법인이 역내 법에 실제로 속하는지를 보는 요건입니다. 등기상 주소가 아니라 결정 권한을 가진 기관의 위치·지분 구조·의결권으로 판정합니다. 역내에 설립된 법인이라도 역외 모회사의 지시를 따를 수밖에 없는 구조라면 이 요건을 충족하지 못한 것이죠. 설립지가 아니라 지배 구조가 기준이 됩니다.

유럽연합 집행위원회는 서비스에 대한 결정적 권한을 가진 기관이 역내 관할 안에 있는지와 지배권 변경에 대한 보증이 있는지를 봅니다. 또한 미국 클라우드법(CLOUD Act)처럼 역외 적용 범위를 가진 법률에 얼마나 노출돼 있는지와 역외 당국이 데이터 접근을 강제할 수 있는 법적·계약적·기술적 통로가 있는지¹를 함께 평가합니다.

이 요건을 어디까지 따질 수 있는지는 프랑스 사례에서 확인할 수 있습니다. SecNumCloud 3.2³의 역외 법 보호 조항은 본사와 중앙 행정 조직과 주된 사업장이 역내에 있을 것을 요구하고 역외 주체의 지분과 의결권을 개별 24%·합계 39% 이하⁴로 제한합니다. 거부권이나 경영진 과반 선임권도 가질 수 없습니다. 역외 투자자 두 곳이 각각 20%를 보유하면 개별 기준은 통과하지만 합계가 40%가 되어 기준을 넘습니다. 국내 사업자에게 이 수치를 그대로 요구할 수는 없지만 지배 구조를 어느 수준까지 따져볼 수 있는지 보여주는 기준선으로 참고하기 좋습니다.

• 계약서에 서명하는 법인이 어느 나라 법을 준거법으로 삼는지 확인합니다.
• 모회사와 주요 주주의 소재 국가와 지분율을 확인합니다.
• 역외 주주가 거부권이나 이사 선임권을 갖는지 확인합니다.

② 운영 통제권: 데이터 접근 권한 주체 확인

운영 통제권은 시스템을 운영하고 고객 데이터에 접근할 수 있는 인력이 어느 나라의 법을 적용받는지를 보는 요건입니다. 개인의 국적이 아니라 두 가지를 봅니다. 그 인력이 물리적으로 어느 나라에 있는지와 인력을 고용한 법인이 어느 나라에 속하는지입니다. 한국인 엔지니어라도 역외 법인 소속으로 역외에서 접속한다면 그 나라의 자료 제출 명령이 그 사람에게 영향을 미칩니다.

CSF는 역내 운영자가 역외 공급사의 개입 없이 기술을 관리하고 유지할 수 있는지¹를 봅니다. 운영 지원이 역내에서 제공되고 역내 법체계에만 종속되는지도 함께 봅니다.

SecNumCloud는 절차를 명시합니다. 지원 업무 때문에 고객 데이터에 접근해야 한다면 고객의 명시적 동의가 먼저 있어야 합니다³. 역외에 있는 인력이 원격으로 개입하는 경우에는 보안 경유 서버를 통해서만 접속하게 하고 검증을 거친 담당자가 실시간으로 그 작업을 감독해야 합니다. 이때 이뤄진 모든 행위는 관리 행위로 기록되며 작업이 끝나면 권한은 삭제됩니다.

금지가 아니라 조건부 허용이라는 점이 실무에서는 더 중요합니다. 금지는 확인할 수 없지만 절차는 문서로 확인할 수 있기 때문입니다.

• 운영과 기술 지원 인력이 상주하는 국가를 확인합니다.
• 고객 데이터에 접근하기 전에 동의를 받는 절차가 문서로 있는지 확인합니다.
• 접근 기록을 고객이 열람할 수 있는지 확인합니다.

③ 로컬 키 관리: 암호화 키 통제권 확인

로컬 키 관리는 암호화된 데이터를 푸는 키를 누가 통제하는지를 보는 요건입니다. 암호화를 적용했는지가 아니라 키를 어디서 만들고 어느 장치에 보관하며 누가 꺼낼 수 있는지로 판정합니다. 사업자가 키에 접근할 수 있다면 사업자가 속한 나라의 정부나 사법기관이 자료 제출을 명령했을 때 사업자는 데이터를 복호화해 제출할 수 있습니다. 암호화 여부와 무관하게 데이터가 열리는 것입니다.

유럽연합 집행위원회도 사업자가 아니라 오직 고객만이 자기 데이터에 대한 암호학적 접근을 실효적으로 통제해야 한다¹고 명시하고 있습니다.

여기서 주의할 점이 있습니다. 사업자가 데이터를 암호화해 저장한다고 해도 그 암호화가 사업자 자신의 접근까지 막아주지는 않는다는 것입니다. SecNumCloud가 요구하는 저장 데이터 암호화의 목적은 자원이 다른 고객에게 재할당되거나 물리적 저장 매체가 외부로 나갔을 때 데이터를 복구하지 못하게 하는 것³입니다. 다른 고객이나 외부인으로부터 데이터를 지키는 장치입니다. 키를 사업자가 보관하고 있으므로 사업자 자신은 언제든 복호화할 수 있습니다.

임대 건물에 빗대어 설명하자면 사업자가 제공하는 암호화는 세입자 방에 달아준 자물쇠와 같습니다. 옆방 세입자나 침입자는 막아주지만 열쇠 복사본을 가진 집주인은 자물쇠를 열 수 있습니다. 수사기관이 영장을 들고 집주인을 찾아오면 자물쇠 성능과 무관하게 문은 열립니다. 세입자가 별도의 자물쇠를 하나 더 달고 열쇠를 소유하고 있을 때에만 집주인이 문을 열 수 없게 되는 것이죠.

SecNumCloud는 이 한계를 문서에 직접 적어뒀습니다. 이 기준은 사업자의 데이터 접근에 대해 기술적 보장이 아니라 계약상 약속만을 제공하며, 기술적으로 막으려는 고객은 자기 통제 아래 있는 암호화 수단을 따로 마련해야 한다는 내용입니다. 인증을 발급하는 쪽이 인증만으로는 이 요건이 채워지지 않는다고 밝힌 셈입니다.

그래서 고객이 할 일이 남습니다. 인증받은 사업자를 고르는 것만으로는 키 통제권이 넘어오지 않습니다. 민감한 데이터라면 사업자가 제공하는 암호화 위에 고객이 직접 통제하는 암호화를 한 겹 더 두는 방식을 검토해야 합니다. 이때 키를 사업자의 키 관리 시스템에 맡길지 자사 환경에만 둘지가 갈림길입니다.

BYOK와 HYOK의 차이

둘 다 고객의 키라고 부르지만 사업자가 키에 닿을 수 있는지에서 갈립니다. 다만 이 구분은 표준 기관이 정한 정의가 아니라 업계에서 통용되는 구분이어서 사업자마다 구현 방식이 다릅니다.

• 키를 어디서 생성하고 어느 장치에 보관하는지 확인합니다.
• 사업자 인력이 키에 접근할 수 있는 경로가 있는지 확인합니다.
• 사업자가 BYOK나 HYOK를 지원하는지, 지원한다면 키가 어느 쪽 영역에 놓이는지 확인합니다.
• 키를 폐기하면 데이터를 더 이상 복호화할 수 없게 되는지 확인합니다.

④ 공급망 투명성: 하위 위탁 사슬 확인

공급망 투명성은 서비스 제공에 관여하는 사업자 사슬이 어디까지 드러나는지를 보는 요건입니다. 직접 계약한 사업자만이 아니라 그 사업자가 다시 맡긴 곳까지 포함해 판정합니다. 계약 상대의 하청을 제4자 위험(fourth-party risk)이라고 부릅니다. 데이터를 실제로 다루는 손은 종종 이 지점에 있습니다.

CSF에서 공급망은 여덟 목표 가운데 가중치가 20%로 가장 높습니다. 하드웨어가 제조되고 조립된 국가·하드웨어를 제어하는 펌웨어의 관할·소프트웨어가 설계된 곳과 업데이트가 배포되는 관할¹을 모두 봅니다. 감사권을 포함해 공급자와 하위 공급자 사슬 전체가 들여다보이는지도 평가 항목입니다.

SecNumCloud는 서비스에 관여하는 제3자 전체 목록을 여러 단계의 하도급까지 포함해 유지하도록³ 요구합니다. 이 목록 가운데 데이터에 접근할 수 있는 곳은 고객이 열람할 수 있어야 하고 수탁자가 바뀌면 고객이 이의를 제기할 수 있도록 통지해야 합니다. 제3자와 맺는 계약에는 감사 조항을 넣도록 해 자격 심사 기관이 하위 사슬까지 준거 준수 여부를 검증할 수 있게 합니다. 감사 주체는 고객이 아니라 심사 기관입니다. 자격이 붙어 있다면 하위 사슬도 함께 검증됐다는 뜻이지만 고객이 직접 감사할 권리가 따라오지는 않습니다.

• 하위 수탁자 목록을 계약 전에 받을 수 있는지 확인합니다.
• 수탁자가 바뀔 때 통지를 받고 이의를 제기할 수 있는지 확인합니다.
• 하위 사슬까지 자격 심사 범위에 들어가 있는지 확인합니다.
• 고객이 직접 감사할 수 있는지는 계약에서 따로 정합니다.

⑤ 네트워크 경로 통제: 이동 경로 확인

네트워크 경로 통제는 데이터가 오가는 구간이 역내에 묶이는지를 보는 요건입니다. 저장 위치와 달리 경로는 계약서에 잘 적히지 않아서 확인하려면 따로 물어야 합니다.

이 요건은 앞의 넷과 위상이 조금 다릅니다. CSF에는 경로를 직접 다루는 목표가 없고 저장과 처리를 역내 관할로 한정하며 제3국으로 되돌아가는 우회를 두지 않는다는 조항이 가장 가깝습니다. SecNumCloud 쪽이 더 구체적이어서 허용된 통신 흐름을 정리한 목록을 포함한 망 구성도를 유지하도록 하고 청구 정보나 장애 처리 기록처럼 인프라 밖으로 나가는 정보도 검사하고 걸러낼 수 있어야 한다³고 요구합니다.

네트워크 경로 문제는 2편에서 더욱 상세히 확인할 수 있습니다.

• 트래픽이 역외를 경유하는 구간이 있는지 확인합니다.
• 데이터 외에 청구 정보나 운영 기록처럼 밖으로 나가는 정보가 무엇인지 확인합니다.

3. ANSSI, Prestataires de services d’informatique en nuage (SecNumCloud) référentiel d’exigences v3.2, 2022
4. Assemblée nationale, Question écrite n°71 réponse du Gouvernement, 2022

데이터 주권은 어떻게 확보하는가

다섯 요건은 결국 다섯 개의 질문입니다. 누가 법적으로 책임지는가. 누가 시스템을 만지는가. 누가 키를 쥐는가. 누가 뒤에서 일하는가. 데이터는 어디를 지나는가. 이 가운데 몇 가지는 데이터센터에서 갈립니다. 서버에 누가 손댈 수 있는지, 회선이 어디로 나가는지는 서비스를 고른다고 정해지지 않습니다. 시설에서 이미 정해져 있습니다. 요건을 따질 때 시설까지 내려가 봐야 하는 이유입니다.

주권은 선언으로 확보되지 않습니다. 역내에 있다는 말도, 인증을 받았다는 말도 출발점일 뿐입니다. 데이터 주권의 요건 중 무엇이 충족됐고 무엇이 비어 있는지 알고 고르는 것과 묻지 않은 채 맡기는 것은 다릅니다.

지금까지 데이터 주권 시리즈를 통해 소재지와 주권의 차이부터 요건의 구성까지 세 편에 걸쳐 짚어봤습니다. 다루는 내용은 달랐지만 가리키는 곳은 같습니다. 데이터 주권은 어디에 두었느냐로 정해지지 않습니다. 요건을 하나씩 확인하고 채워간 만큼 확보됩니다.

| FAQ

데이터 주권이 왜 중요한가요?

데이터 주권은 역외 당국의 자료 제출 명령으로부터 데이터를 지키고 국내 규제를 지키기 위해 중요합니다.

▪ 역외 관할 리스크: 유럽연합 집행위원회는 미국 클라우드법(CLOUD Act)처럼 역외 적용 범위를 가진 법률에 사업자가 얼마나 노출돼 있는지를 평가 항목으로 둡니다¹.
▪ 통제권 공백: 암호화 키를 사업자가 보관하면 사업자에게 내려진 명령만으로 데이터가 열립니다.

역내 법인 실체란 무엇인가요?

서비스를 제공하는 법인이 역내 법에 실제로 속하는지를 보는 요건입니다.

▪ 판정 기준: 등기 주소가 아니라 결정 권한을 가진 기관의 위치와 지분 구조로 판정합니다.
▪ 충족하지 못하는 경우: 역외 모회사가 거부권을 가지면 이 요건은 충족되지 않습니다.

운영 통제권이란 무엇인가요?

고객 데이터에 접근할 수 있는 인력이 어느 관할에 속하는지를 보는 요건입니다.

판정 기준: 접근 경로와 감독 절차로 판정합니다.
오해하기 쉬운 점: 역외 인력의 접근을 금지하라는 뜻이 아니라 통제된 경로로만 일어나게 하라는 뜻입니다.

BYOK와 HYOK는 어떻게 다른가요?

BYOK는 고객이 만든 키를 사업자의 키 관리 시스템에 올려두고 쓰는 방식이고 HYOK는 키를 고객 환경 안에만 두는 방식입니다.

▪ BYOK: 고객이 키를 만들어 소유하되 사업자의 키 관리 시스템에 올려두고 씁니다.
▪ HYOK: 키를 고객 환경 안에만 두고 사업자와 공유하지 않습니다.
▪ 핵심 차이: 두 방식 모두 고객의 키를 쓰지만 사업자가 키를 꺼낼 수 있는 경로가 남는지에서 갈립니다.

CSF와 SecNumCloud는 어떻게 다른가요?

CSF는 사업자를 비교해 등급을 매기는 평가 틀이고 SecNumCloud는 충족해야 할 조항이 정해진 국가 자격입니다.

▪ CSF: 유럽연합 집행위원회가 만든 평가 프레임워크로 주권을 여덟 목표로 나누고 등급을 매깁니다.
▪ SecNumCloud: 프랑스 국가정보시스템보안청이 발급하는 국가 자격으로 충족해야 할 조항이 명시돼 있습니다.
▪ 핵심 차이: CSF는 사업자들의 순위를 매기는 자이고 SecNumCloud는 통과해야 하는 문턱입니다.