DSPM은 또 다른 ‘섀도우 IT’인가

토니 프럼 - 제품 관리 부문 수석 엔지니어

2026년 3월 19일 5 읽는 데 5분

데이터 보안 상태 관리(DSPM)는 저를 포함해 많은 사람들에게 다소 생소한 개념입니다. 저는 종종 DSPM이 정확히 무엇인지, 정확히정확히 무엇인지에 대해 다소 학문적인 토론을 벌이는 경우가 종종 있습니다. 수많은 토론 끝에 저는 다음과 같은 결론에 도달했습니다. DSPM의 핵심은 결국 찾으라고 지시하지 않은 데이터를 찾아내는. 분류 기준을 직접 정의할 필요가 없습니다(분류 기준은 민감한 정보인지)을 결정하는 방법)이나 정책(민감한 데이터를 민감한 데이터를 어디서 찾아야 하는지 발견 시어떻게 처리할지 발견했을 때 어떻게 처리할지를 설명하는 것)을 정의할 필요가 없습니다.)로 구성됩니다. 이 도구를 실행하기만 하면, 사용자가 알지 못했던 민감한 데이터를 찾아내고 발견한 모든 항목을 목록으로 정리해 줍니다. 간단합니다.

저는 오늘날에도 이 정의를 고수하고 있지만, 제 동료 중 한 명인 수하스 코다가리(Suhaas Kodagali)가 이를 훨씬 더 통찰력 있게 표현했는데, 그 말이 머릿속에서 떠나지 않습니다. 그는 이렇게 말했습니다. “DSPM은 또 다른 섀도우 IT다”라고 말했는데, 이 한 마디에 저는 완전히 깜짝 놀랐습니다. 사실 이건 내부 농담에 가까운 이야기인데, 그 의미를 설명해 드리겠습니다.

약 10년 전으로 거슬러 올라가 보면, Secure Web Gateway SWG) 시장은 이미 확고히 자리 잡은 상태였으며, 사실상 낡은 개념으로 여겨지고 있었습니다. SWG 솔루션은 모든 웹 트래픽을 모니터링하고, 원하는 트래픽을 차단하며, 환경 내 거의 모든 기기에서 발생하는 모든 HTTP 요청을 기록할 수 있습니다.  이는 강력한 기술이며, 일반적으로 완벽한 보안 스택에서 절대적으로 필수적인 요소로 간주됩니다. 그 후 Cloud Access Security Broker CASB) 시장이 등장했는데, 이는 주로 우리의 전신 기업 중 하나인 Skyhigh Networks가 주도한 것으로, 이 회사는 오늘날에도 여전히 “섀도우 IT”라고 불리는 솔루션을 개발했습니다.

섀도우 IT는 무엇을 할까요? 제가 질문을 하나 드리며 설명해 드리겠습니다. twtimg.com 이 무엇인지 아시나요? 아마 모르실 겁니다. 하지만 이는 'Twitter images'의 줄임말로, 과거 트위터였던 X와 관련된 수많은 도메인 중 하나입니다. 만약 SWG 솔루션의 보고 데이터에서 이 도메인을 보셨다면, 그게 무엇인지 전혀 짐작조차 못 하셨을 겁니다. 또 다른 임의의 예시인 sanpdf.com을 예로 들어보겠습니다. 잘 모르신다면 구글에서 간단히 검색해 보시면 SanPDF가 문서 변환 도구 세트라는 것을 알 수 있습니다. 도메인은 명확하지만, SanPDF에 대한 보안 관련 질문에 얼마나 쉽게 답할 수 있겠습니까? 그들의 법적 조항에 따라 변환된 데이터를 자체 목적으로 사용할 권리가 주어지나요? 그들이 데이터를 안전하게 저장하는지 알고 계신가요? 요컨대, 사용자들이 이를 사용하도록 허용해야 하는지 알고 계신가요?  아마도 모르실 가능성이 높습니다. 이것이 바로 섀도우 IT가 하는 일입니다. 섀도우 IT는 SWG 보고서를 이해하는 데 도움을 주고, 비즈니스 위험을 기반으로 합리적인 정책을 수립할 수 있도록 지원합니다.

여기서 흥미로운 점은 섀도우 IT(Shadow IT) 솔루션 제공업체인 스카이하이 네트워크스(Skyhigh Networks)가 웹 트래픽을 검사하거나 어떤 것도 차단할 수 있는 기본적인 기능을 갖추고 있지 않았다는 것입니다.  이 업체는 SWG 로그 데이터를 가져와 위험 요소가 어디에 있는지 보여주는 유용한 보고서를 생성했고, 고객은 이를 바탕으로 정책을 정의할 수 있었습니다. 섀도우 IT는 용납할 수 없는 특정 위험 요소를 정의할 수 있게 함으로써 웹 정책의 구성 요소를 생성할 수 있었고, 이를 통해 차단해야 할 애플리케이션 목록과 관련 도메인 목록을 생성할 수 있었습니다. 여기서 농담의 핵심은 바로 이것입니다. 섀도우 IT는 자체적으로 정책을 강제할 수 없었다. 그들은 SWG와 통합할 수밖에 없었는데, 할 수 있는, 아니면 자체 프록시를 구축해야만 했습니다.  섀도우 IT는 SWG에 계속 의존하거나, 중복되는 프록시가 되는 것 중 하나를 선택해야만 했으며가 될 수밖에 없었는데, 두 선택지 모두 고객에게는 매력적이지 않았습니다.

이는 오늘날의 순수형 DSPM 솔루션에 대한 완벽한 비유입니다. 현재 Security Service Edge SSE) 공급업체들은 승인된 클라우드 애플리케이션, 웹 트래픽, 사내 애플리케이션 등에서 데이터를 보호하는 데 필요한 모든 가시성과 제어 기능을 갖추고 있습니다. 그렇다면 DSPM은 무엇을 제공할까요?  DSPM은 SSE 데이터 보안 기술을 더욱 효과적으로 활용할 수 있도록 도와줍니다. 마치 섀도우 IT가 조직이 SWG 기술을 더 효과적으로 활용하도록 도왔던 것처럼 말입니다. 최신 SSE 포트폴리오를 통해 데이터를 정확하게 분류하고 보호할 수 있지만, 아무리 노력해도 결국 “내가 모르는 부분은 무엇일까?”라는 걱정에 시달리게 될 것입니다.  사용자들이 정책을 수립하지 않아 막지 못한 민감한 데이터를 어떤 애플리케이션으로 전송하고 있을까요? 귀사가 다루고 있지만 한 번도 고려하지 않았던 민감한 데이터 유형은 무엇일까요? 전혀 인지하지 못한 채 어떤 법률을 위반하고 있지는 않을까요? DSPM은 이러한 질문에 답하는 것을 목표로 합니다. DSPM은 어떤 유형의 민감한 데이터 어디서든 검색을 허용하는 곳이라면 어디에서나모든 종류의 민감한 데이터를 찾아냅니다. 이 솔루션은 여러분이 모르는 사실을 알려주므로, 섀도우 IT의 경우와 마찬가지로 스스로를 보호하기 위한 정책을 수립할 수 있게 해줍니다.

문제는 많은 DSPM 공급업체들이 현재 섀도우 IT가 처했던 상황과 똑같은 처지에 놓여 있다는 점입니다. 이들은 어쩔 수 없이 의존 의존 중복. 대부분의 순수 DSPM 솔루션은 단순히 탐지 도구일 뿐이며 데이터를 보호하지 . 이제 이러한 벤더들은 발견된 데이터에 대한 보호를 시행하기 위해 기존 SSE 벤더에 의존하거나, 많은 고객이 이미 SSE 투자를 통해 구축한 보호 기능을 확보하기 위한 일련의 기능을 자체적으로 구축해야 합니다. 많은 벤더가 기존 SSE 솔루션의 CASB 부분과 완전히 중복되는 IaaS 및 SaaS 애플리케이션과의 API 통합을 이미 구축한 것으로 보아, 그들의 선택은 이미 내려진 것으로 보입니다.

견고한 SSE 솔루션을 구축하고 순수 DSPM 벤더에도 투자한 조직의 입장에서 생각해 보십시오. DSPM 솔루션은 민감한 데이터가 어디에 배포되어 있는지 알려주지만, 실제로 발견된 데이터를 보호하려면 SSE 솔루션을 사용해야 합니다.  예를 들어 Microsoft 365와 통합된 두 개의 별도 솔루션을 보유하고 있는데, 두 도구 모두 동일한 데이터를 스캔하려고 시도하는 과정에서 Microsoft의 API 사용량 제한에 부딪힐 가능성이 높습니다. 이러한 접근 방식이 타당할까요? 그리고 만약 여러분이 순수 DSPM 벤더라면, 이 문제를 어떻게 해결하시겠습니까? 약 10년 전 CASB 시장에서 이미 해결된 문제에 대한 솔루션을 새로 구축하시겠습니까?

제가 시장 예측의 달인은 아니지만, DSPM과 섀도우 IT 사이의 유사점은 부인할 수 없습니다. DSPM이 결국 자신이 강화하고자 하는 기술 스택, 즉 주로 SSE에 흡수되는 동일한 궤적을 밟을 수도 있다고 보는 것은 적어도 논리적인 추론이라고 생각합니다. 조직이 굳이 두 가지 DSPM 와 SSE 솔루션까지 모두구현해야만 데이터를 발견하고 보호할 수 있다는 것입니까? 발견된 데이터를 실제로 보호하는 데 궁극적으로 필요한 SSE 스택의 필수적인 부분으로 DSPM의 자동 발견 방식을 통합하는 것이 더 합리적이지 않을까요? 저는 시장이 결국 섀도우 IT의 경우와 마찬가지로, 발견과 적용은 동일한 플랫폼에 속해야 한다는 결론에 도달할 것이라고 생각합니다.

블로그로 돌아가기