2026년 현재, 글로벌 데이터 프라이버시 환경은 단순한 '체크박스' 수준의 규정 준수 활동에서 벗어나, 반드시 갖추어야 할 비즈니스 기능으로 자리 잡았습니다. 이러한 환경에서 운영 시스템에만 초점을 맞춘 데이터 프라이버시 정책은 오히려 위험 요소가 될 수 있습니다. 그래서 오늘날 CISO들이 던지는 질문은 단순히 "우리는 안전한가?"가 아니라, "우리의 테스트 데이터는 합법적인가?"입니다.
SUMMARY: SAP에서의 데이터 프라이버시는 더 이상 형식적인 규정 준수 항목이 아닙니다. 운영 시스템이 안전하다고 해서 비운영 환경에 마스킹되지 않은 개인정보(PII)가 존재하는 경우까지 규정을 준수한다고 볼 수는 없습니다. 숨겨진 위험은 테스트 시스템, 커스텀 Z-테이블, 그리고 실제 데이터를 기반으로 하는 AI에 존재하는 경우가 많으며, 이는 내부 통제 실패, 데이터 주권(Data Sovereignty) 문제, 계약 위반 등을 초래할 수 있습니다. EPI-USE Labs는 세 가지를 권장합니다. 실제 데이터로 테스트하지 말 것, PII 탐지를 자동화할 것, 그리고 익명화된 데이터를 기반으로 AI를 운영할 것입니다.
2026년 현재, 글로벌 데이터 프라이버시 환경은 단순한 '체크박스' 수준의 규정 준수 활동에서 벗어나, 반드시 갖추어야 할 비즈니스 기능으로 자리 잡았습니다. 이러한 환경에서 운영 시스템에만 초점을 맞춘 데이터 프라이버시 정책은 오히려 위험 요소가 될 수 있습니다. 그래서 오늘날 CISO들이 던지는 질문은 단순히 "우리는 안전한가?"가 아니라, "우리의 테스트 데이터는 합법적인가?"입니다.
대부분의 조직은 운영 환경에 대해서는 규정 준수를 달성했지만, 비운영 시스템에는 여전히 여러 취약점이 존재합니다. CISO에게 위험은 단순히 외부 공격에만 있는 것이 아니라 테스트 환경 내부에 존재하는 잠재적인 규제 이슈에도 있습니다. 데이터를 보호하는 것은 필수적이지만, 데이터가 적절하게 사용되고 규정을 준수하는지 확인하는 것 역시 그만큼 중요해지고 있습니다.
최근 패널 토론에서 저는 데이터 프라이버시 전문가인 Johann Haefele, Danie Loots, Rohin Ramjee와 함께 SAP를 운영하는 조직들이 왜 잘못된 안전 의식 아래 있을 수 있는지에 대해 이야기를 나눴습니다. 운영 시스템은 철저히 보호되고 있을 수 있지만, 테스트 시스템은 조직의 규정 준수 전략 전체를 위험에 빠뜨릴 수 있습니다.
우리가 가장 자주 접하는 오해는 보안이 강화된 SAP 운영 시스템이 곧 전체 규정 준수를 의미한다는 것입니다. 운영 환경에서 직무 분리(Segregation of Duties), 다중 인증, 부정 방지 체계를 갖추고 있다면 안전하다고 생각할 수 있습니다.
하지만 그렇지 않습니다. 이러한 생각은 SAP 환경 전체에 걸쳐 규정 준수가 이루어져야 한다는 사실을 간과하고 있습니다. 대부분의 기업은 정확한 테스트를 위해 운영 환경의 데이터를 그대로 비운영 환경으로 복제합니다. 그 결과 사실상 또 하나의 운영 환경과 같은 그림자 운영 환경(shadow production environment)이 만들어집니다. 이러한 환경에는 실제 고객 이름, 은행 계좌 정보, 직원 정보가 그대로 포함되어 있지만, 접근 통제는 일반적으로 훨씬 느슨하게 운영됩니다.
"법은 개발, QA, 운영 환경을 구분하지 않습니다."라고 Johann Haefele은 설명합니다. "법은 데이터 자체에 초점을 맞춥니다. 테스트 시스템에 식별 가능한 정보가 존재한다면, 해당 데이터를 보호할 책임은 전적으로 조직에 있습니다. 만약 그 데이터가 마스킹되지 않은 상태라면, 그 데이터가 해당 환경에 존재하는 것 자체가 법적으로 정당한지 질문해야 합니다."
Johann에 따르면, 올해 상반기에 발생한 데이터 프라이버시 사고의 약 90%는 외부 공격이 아니라 내부 통제 실패로 인해 발생했습니다. 이러한 내부 유출은 개발자나 오프쇼어 팀이 문제 해결을 위해 비운영 시스템 내 테이블에 광범위한 접근 권한을 부여받으면서 발생하는 경우가 많습니다. 이들이 테스트 환경에서 실제 데이터를 조회하는 순간, 이는 승인되지 않은 데이터 노출에 해당할 수 있습니다.
위험성을 인지하고 있는 조직이라 하더라도, 데이터를 찾아내는 것 자체가 절반의 과제입니다. SAP의 가장 큰 강점인 거의 무한에 가까운 커스터마이징 기능은 동시에 데이터 프라이버시 측면에서는 약점이 되기도 합니다. 지난 20년 동안 개발자들은 즉각적인 비즈니스 요구 사항을 해결하기 위해 커스텀 'Z-테이블'을 생성하거나 표준 필드를 확장해 왔을 가능성이 높습니다. 이러한 필드에는 종종 매우 민감한 개인정보(PII)가 포함되어 있지만, 일반적인 규정 준수 스캔으로는 이를 발견하지 못하는 경우가 많습니다.
이러한 기술 부채는 생성형 AI 시대와 맞물리면서 더욱 큰 문제가 되고 있습니다. 조직들이 SAP BTP 및 AI Core를 통해 SAP 환경에 대규모 언어 모델(LLM)과 챗봇을 통합함에 따라, 의도치 않게 민감한 데이터에 대한 새로운 위험을 만들어 내고 있습니다. 예를 들면 다음과 같습니다.
만약 AI가 스크램블링되거나 마스킹되지 않은 테스트 데이터를 학습하고 있다면, 조직은 데이터 프라이버시 침해를 자동화하고 있는 것일 수 있습니다.
데이터는 SAP 안에만 존재하지 않습니다. 오늘날 SAP는 거의 항상 Salesforce, Workday와 같은 플랫폼을 포함하는 더 넓은 생태계의 일부로 운영됩니다. 이로 인해 데이터가 시스템 경계를 넘을 때마다 테스트 데이터의 적법성이 검증되는 참조 무결성(Referential Integrity) 문제가 발생합니다.
동의(Consent)와 데이터 주권(Data Sovereignty): 2026년 데이터 프라이버시 법률에 따르면, 데이터의 특정 사용 목적마다 명시적이고 충분한 동의를 받아야 합니다. 고객이 운영 시스템에서 구매 처리를 위해 자신의 데이터 사용에 동의했다고 해서, QA 환경에서 신규 직원을 교육하는 데 동일한 데이터를 사용하는 것까지 동의한 것은 아닙니다. 해당 목적에 대한 동의를 확보하지 못했다면, 과연 테스트 데이터를 사용하는 것이 합법적일까요? 또한 오프쇼어 팀이 다른 국가에 위치한 테스트 시스템에서 주권 데이터(sovereign data)에 접근하는 경우, 불법적인 국가 간 데이터 이전 위반에 해당할 수 있습니다.
계약상 규정 준수(Contractual Compliance): Amazon이나 Costco와 같은 글로벌 유통업체들이 엄격한 책임 조항(strict liability clauses)을 계약에 포함하는 사례가 크게 증가하고 있습니다. 이러한 조항은 실제 고객 데이터를 거래 후 60일 이내에 삭제하거나 파기하도록 요구하는 경우가 많습니다. 만약 시스템 리프레시를 수행한 후 QA 시스템에 실제 거래 데이터를 6개월간의 테스트 주기 동안 보관한다면, 개인정보 보호 법규를 위반할 뿐만 아니라 공급 업체와의 계약도 직접적으로 위반하게 됩니다.
SAP 환경을 규정을 준수하는 환경으로 전환하기 위해서는 다음과 같은 모범 사례를 구현해야 합니다.
핵심 질문으로 다시 돌아가 보겠습니다. 여러분의 테스트 데이터는 과연 합법적입니까? 만약 아직도 교육 및 QA 목적으로 운영 데이터의 복사본을 그대로 사용하고 있다면, 단순히 벌금의 위험만 감수하는 것이 아닙니다. 계약, 평판, 그리고 조직의 신뢰성까지 리스크에 노출시키고 있는 것입니다.
여러분의 개인정보(PII) 리스크가 어디에 숨어 있는지 궁금하신가요? 전체 패널 토론 영상을 시청하여 데이터 프라이버시에 대한 SAP 환경의 대표적인 세 가지 오해를 전문가들이 어떻게 설명하는지 확인하고, 2026년 SAP 환경을 보호하기 위해 필요한 실질적인 조치들을 알아보시기 바랍니다.