섀도 IT 함정: 커넥터를 과도하게 차단하면 사용자가 떠나는 이유

By Mirko Peters · 2026-08-11

M365 거버넌스, 보안 및 관리에 대한 심층 시리즈의 블로그 동반 페이지에 다시 오신 것을 환영합니다. 현대적인 엔터프라이즈 테넌트를 관리하고 계시다면, 환경을 최대한 잠가야 한다는 압박을 분명 느끼셨을 것입니다. 경영진이 데이터 유출을 우려하면 IT 및 보안 팀은 대개 즉각적이고 단호하게 반응합니다. 커넥터를 차단하고, 데이터 손실 방지(DLP) 정책을 극단까지 제한하며, 모든 사용자를 엄격하게 제한된 통로로 통과시키는 방식입니다. 능동적으로 대응하는 것처럼 보이고, 컴플라이언스 슬라이드에서도 좋아 보입니다. 하지만 실제 운영 감사에서 여러 차례 확인했듯이, 이런 접근은 위험한 보안 착시를 만들어 냅니다.

Automatically translated with AI from the original post. Read the English original

Microsoft 365 거버넌스, 보안, 관리에 관한 심층 시리즈의 블로그 동반 콘텐츠에 다시 오신 것을 환영합니다. 최신 엔터프라이즈 테넌트를 관리하고 계신다면, 보안을 강화해야 한다는 큰 압박을 느껴 보셨을 것입니다. 경영진이 데이터 유출을 우려할 때 IT 및 보안 팀의 즉각적인 반응은 대개 신속하고 절대적입니다. 커넥터를 차단하고, 데이터 손실 방지(DLP) 정책을 극단까지 제한하고, 모든 사용자를 엄격하게 제한된 경로로만 통과시키는 식입니다. 선제적인 조치처럼 보이고, 컴플라이언스 슬라이드에서도 좋아 보입니다. 하지만 운영 환경 감사에서 반복해서 확인되듯, 이 접근 방식은 위험한 보안 착각을 만들어 냅니다.

이 중요한 문제를 제대로 짚어 보기 위해, 최근 이러한 거버넌스 마찰 지점을 다루는 팟캐스트 에피소드를 별도로 녹음했습니다. 라이브 토론, 실제 감사 사례, 실행 가능한 내부 노하우를 듣고 싶으시다면 Strengthen Power Platform DLP and Default Environment Governance을(를) 꼭 확인해 보시기 바랍니다. 이번 글에서는 그 내용을 한층 더 확장하여, 공격적인 커넥터 제한이 역효과를 내는 이유와 보안과 사용자 활용성 사이에서 적절한 균형점을 찾는 방법에 초점을 맞추겠습니다.

많은 보안 아키텍처를 움직이는 핵심 철학은 단순합니다. 데이터를 이동시킬 수 있는 도구가 있고 그 안전성을 명확히 보장할 수 없다면, 그 도구를 비활성화해야 한다는 것입니다. Microsoft Power Platform(Power Apps, Power Automate, Copilot Studio)의 맥락에서 이는 보통 Microsoft 이외의 거의 모든 커넥터를 차단하거나, 모든 항목을 경직된 "차단됨" 비즈니스 데이터 그룹에 몰아넣는 공격적인 데이터 손실 방지 정책으로 나타납니다.

관리자는 기업 데이터가 검증되지 않은 타사 서비스로 자유롭게 흘러 들어갈 수 없다는 사실에 밤에 더 편히 잠들 수 있습니다. 그러나 이러한 컴플라이언스 태세는 근본적으로 잘못된 가정에 기대고 있습니다. 즉, 사용자가 기술적 장애물을 만나면 업무 문제 해결을 그냥 포기할 것이라는 가정입니다. 실제로 현대의 지식 근로자는 적극적이고, 마감에 쫓기며, 점점 더 기술에 능숙합니다. 인위적인 제한으로 포장된 정당한 업무 요구를 IT가 거부하면, 사용자는 업무 흐름을 포기하지 않습니다. 대신 우회 방법을 찾아냅니다. 섀도 IT는 바로 이 우회 방법에서 시작됩니다.

관리자는 기업 데이터가 검증되지 않은 제3자 서비스로 자유롭게 흘러가지 않는다는 사실에 마음 놓고 잠들 수 있습니다. 그러나 이러한 컴플라이언스 태세는 근본적으로 잘못된 가정에 기대고 있습니다. 바로 사용자가 기술적 장벽에 부딪히면 업무 해결을 그만둘 것이라는 가정입니다. 실제로 현대의 지식 근로자는 임기응변에 능하고, 마감에 쫓기며, 점점 더 기술에 익숙합니다. 인위적인 제한으로 포장된 정당한 업무 요구를 IT가 거절하면, 사용자는 업무 흐름을 포기하지 않습니다. 대신 그 제한을 우회할 방법을 찾습니다. 바로 그 우회 방법에서 섀도 IT가 시작됩니다.

사용자가 커넥터 차단을 우회하는 방법을 살펴보기 전에, 이런 보안 실패 대부분이 실제로 어디에서 비롯되는지 짚어야 합니다. 바로 기본 환경(Default Environment)입니다. 거의 모든 표준 테넌트에서 라이선스를 받은 모든 사용자는 기본적으로 기본 환경에 대한 메이커(Maker) 액세스 권한을 갖습니다. 이 환경은 말하자면 궁극의 디지털 만능 싱크대와 같습니다. 관리 오버헤드가 전혀 없이 바로 시작할 수 있기 때문에, 사람들은 개인 생산성 자동화, 빠른 개념 증명(PoC) 솔루션, 팀 알림, 실험적인 앱을 바로 그곳에서 만듭니다.

이처럼 무해해 보이는 프로토타입이 성공할 때 위험이 시작됩니다. 한 사용자가 양식의 고객 피드백을 공유 스프레드시트로 동기화하는 간단한 흐름을 만들었다고 가정해 봅시다. 그러자 갑자기 팀 전체가 이를 채택합니다. 관리자들도 이에 의존하게 됩니다. 3개월 안에 개념 증명 앱은 테넌트에서 가장 느슨한 환경에서 실행되는 운영 비즈니스 도구가 되며, 공식적인 애플리케이션 수명 주기 관리(ALM) 검토와는 완전히 단절됩니다. 기본 환경은 기본적인 생산성을 방해하지 않도록 널리 접근 가능한 상태를 유지해야 하므로, 여기에 일괄적으로 적용된 DLP 규칙은 종종 막대한 부수적 피해를 낳고, 사용자 반발의 씨앗이 됩니다.

이런 무해해 보이던 프로토타입이 성공하면서 위험이 시작됩니다. 한 사용자가 양식의 고객 피드백을 공유 스프레드시트로 동기화하는 간단한 플로우를 만듭니다. 그러자 팀이 이를 채택하고, 관리자도 이에 의존하기 시작합니다. 석 달이 지나면 개념 증명 앱이 테넌트에서 가장 개방된 환경에서 실행되는 운영 업무 도구가 되어 있고, 공식 애플리케이션 수명 주기 관리(ALM) 검토와는 완전히 단절되어 있습니다. 기본 환경은 기본적인 생산성을 저해하지 않도록 폭넓게 접근 가능한 상태를 유지해야 하므로, 여기에 일괄적으로 적용된 DLP 규칙은 종종 큰 부작용을 낳고, 그 결과 사용자의 반발을 불러옵니다.

조직이 표준 생산성 및 커뮤니케이션 커넥터에 대한 접근을 완전히 차단하는 것과 같은 가혹한 DLP 정책을 시행하면, 데이터 유출을 막고 있다고 생각합니다. 하지만 실제로 그들이 하고 있는 일은 눈에 보이지 않는 행동을 부추기는 것입니다.

조직이 표준 생산성 및 커뮤니케이션 커넥터에 대한 접근을 전면 차단하는 것과 같은 가혹한 DLP 정책을 도입하면, 데이터 유출을 막고 있다고 믿습니다. 하지만 실제로 그들이 하고 있는 일은 눈에 보이지 않는 행동을 부추기는 것입니다.

전사적 금지 정책 때문에 기업 Power Platform 환경에서 외부 커넥터가 차단된 영업 담당자를 생각해 봅시다. 이 직원은 주간 보고를 자동화하려고 내부 Microsoft 365 목록을 외부 프로젝트 관리 도구나 널리 쓰이는 클라우드 스토리지 서비스와 연결하려 합니다. 이때 직원에게는 선택지가 둘뿐입니다. 자동화를 포기하고 매주 세 시간씩 수동으로 복사와 붙여넣기를 하며 시간을 낭비하거나, 다른 방법을 찾거나 해야 합니다.

그렇다면 다른 방법은 무엇일까요? 직원은 회사 이메일 주소로 개인용 또는 승인되지 않은 SaaS(Software-as-a-Service) 계정을 만들고, 데이터를 보안 경계 밖으로 내보낸 뒤 감시되지 않는 외부 도구에서 직접 연동을 구성할 수 있습니다. 또는 평문 파일에 안전하지 않게 저장한 원시 API 토큰을 사용하는 로컬 스크립트를 작성할 수도 있습니다. 기업 생태계 안에서 기본 제공되는 감사 가능한 커넥터를 과도하게 차단하면 IT는 데이터를 보호한 것이 아닙니다. 오히려 데이터를 플랫폼 밖으로 완전히 밀어내 로깅도, 모니터링도, 거버넌스 감독도 없는 곳으로 보내 버린 셈입니다.

내부와 외부를 구분하는 사고방식의 위험성

테넌트 리뷰를 진행하면서 자주 발견하는 또 하나의 중대한 아키텍처 결함은 전통적인 "내부 대 외부" 보안 사고방식에 의존하는 것입니다. 과거에는 보안 팀이 기업 테넌트 경계 안의 모든 것을 본질적으로 안전하다고 보고, 경계 밖의 모든 것을 본질적으로 위험하다고 여기는 경우가 많았습니다.

오늘날의 하이브리드 비즈니스 모델에서는 이러한 경계가 더 이상 의미가 없습니다. 계약직 직원, 외부 파트너 에이전시, 합병된 자회사, 자동화된 B2B 워크플로가 늘어나면서 "내부" 사용자도 민감한 지식재산을 일상적으로 다루고 있습니다. 반대로 부서들은 일상 업무의 일부로 외부 서비스와 안전하게 상호작용해야 하는 경우가 빈번합니다. 모든 내부 메이커와 모든 내부 환경을 동등하게 신뢰할 수 있다고 보면 치명적인 구조적 과다 공유로 이어집니다. 정당한 외부 커넥터는 차단하면서 내부 공유는 활짝 열어 두면, 악의가 없어도 중대한 보안 사고로 이어질 수 있는 우발적 데이터 노출의 온상이 만들어집니다.

세 가지 축: 환경 전략, 커넥터 전략, 공유 철학

그림자 IT 함정을 해결하려면 거버넌스를 독립된 규칙들의 모음이 아니라 상호 연결된 생태계로 보아야 합니다. 핵심 거버넌스 프레임워크에서 자세히 설명하듯이, 세 가지 축이 함께 작동해야 합니다.

1. 환경 전략

기본 환경을 프로덕션 작업 공간으로 취급하지 마십시오. 기본 환경을 격리하고, 모니터링하고, 기능을 제한하십시오. 메이커가 적절한 리소스 제한과 자동 프로비저닝을 갖춘 전용 개발, 테스트, 프로덕션 환경을 요청할 수 있는 명확한 경로를 마련하십시오.

2. 커넥터 전략

전면 차단에서 벗어나십시오. 커넥터가 "외부"라는 이유만으로 무조건 차단하는 대신, 실제 위험 프로필, 데이터 분류, 업무상 필요성에 따라 분류하십시오. 테넌트 수준과 환경 수준의 DLP 정책을 활용해 적절한 경우 통제된 사용을 허용하고, 철저한 감사와 함께 운영하십시오.

3. 공유 철학

개방형 공유 모델에서 최소 권한 접근 방식으로 전환하십시오. 앱과 흐름에 누가 접근할 수 있는지 정기적으로 감사하고, 특히 비프로덕션 계층에서 기본적으로 광범위한 테넌트 전체 공유를 막는 안전장치를 구현하십시오.

무엇보다 중요한 점은 이것들이 서로 별개의 선택이 아니라는 것입니다. 하나의 통합된 시스템입니다. 환경 전략이 강력해도 커넥터 전략이 지나치게 제한적이면 사용자는 그림자 IT로 떠나 버립니다. 공유 철학이 취약하면 아무리 훌륭한 커넥터 전략이라도 구조적인 데이터 유출을 막지 못합니다.

정적 DLP에서 적응형 DLP로

규칙을 테넌트 전체에 전역으로 적용하고 몇 년 동안 손대지 않는 정적 DLP는 빠르게 쓸모없어지고 있습니다. 현대의 조직에는 적응형 DLP가 필요합니다. 적응형 정책은 사용자 ID, 디바이스 규정 준수 상태, 환경 분류, 데이터 민감도 레이블에 따라 동적으로 조정됩니다.

기본 환경의 일반 메이커는 커넥터 접근이 제한되어 있지만, 더 엄격한 모니터링과 데이터 분류 기준이 적용되는 전문 개발 환경의 검증된 구성원은 확장된 통합 기능을 사용할 수 있는 상황을 생각해 봅시다. 모든 사용자에게 무차별적으로 같은 규칙을 적용하는 대신 정책을 상황에 맞게 조정하면, IT는 정당한 혁신을 지원하면서도 견고한 보안 경계를 유지할 수 있습니다.

결론: 정책과 생산성 사이의 간극 메우기

거버넌스는 조직에 "안 된다"고 말하는 것이 아닙니다. 사용자가 사고 없이 빠르게 움직일 수 있도록 안전한 통로를 만드는 일입니다. IT 팀이 두려움 때문에 커넥터를 과도하게 차단하고 제한적인 정책에 의존하면, 오히려 막으려던 섀도 IT 위험을 스스로 만들어 내게 됩니다. 환경 전략을 다듬고, 세분화된 커넥터 정책을 도입하며, 공유에 대한 접근 방식을 현대화하면 사용자가 머무르고 싶어 하는 탄탄한 Power Platform 아키텍처를 구축할 수 있습니다.

사용자와 대립하는 대신 거버넌스 프레임워크를 실제 비즈니스 생산성에 맞추고 싶으시다면, 함께 제공되는 오디오 가이드를 놓치지 마십시오. Strengthen Power Platform DLP and Default Environment Governance를 방문하시면 전체 토론을 들으며 핵심 전략을 모두 확인하실 수 있습니다. 여러분의 테넌트 환경에서 사용자 활용성과 엄격한 보안 통제의 균형을 어떻게 맞추고 계신지 댓글로 알려 주십시오.