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은 어떤 어떤 종류의 민감한 데이터든 어디서든 검색을 허용하는 곳이라면 어디에서나모든 종류의 민감한 데이터를 찾아냅니다. Shadow 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의 경우와 마찬가지로, 발견과 적용은 동일한 플랫폼에 속해야 한다는 결론에 도달할 것이라고 생각합니다.

블로그로 돌아가기