보안은 이제 신뢰를 파는 일이다
한때 사이버보안은 회사 안쪽에서 조용히 돌아가는 방어 업무처럼 여겨졌다. 방화벽을 세우고, 백신을 설치하고, 사내망에 들어오는 길목을 지키면 충분하다고 믿었다. 보안팀은 회사의 '성벽'을 관리하는 사람들이었고, 사업 부서는 그 성벽 안에서 서비스를 만들고 고객을 만났다.
하지만 지금의 기업은 성벽 안에만 존재하지 않는다. 직원은 집과 카페와 공항에서 일한다. 고객 데이터는 클라우드 데이터베이스에 저장된다. 영업팀은 SaaS 고객관리 도구를 쓰고, 개발팀은 오픈소스 패키지를 내려받아 서비스를 만든다. 결제, 물류, 인증, 마케팅 자동화는 외부 API와 연결된다. 기업의 실제 업무 흐름은 사내망이라는 한 공간이 아니라 수많은 사용자, 기기, 애플리케이션, 클라우드, 파트너 시스템 사이에 흩어져 있다.
이 변화는 보안의 의미를 바꿔 놓았다. 보안은 더 이상 '뚫리지 않기 위한 기술'만이 아니다. 고객이 이 회사에 자신의 데이터를 맡겨도 되는지, 파트너가 이 회사의 API와 시스템을 연결해도 되는지, 투자자가 이 회사의 운영 리스크를 감당할 수 있다고 판단할 수 있는지를 증명하는 언어가 되었다. 다시 말해 사이버보안은 디지털 신뢰의 기반이다.
디지털 신뢰란 단순히 '우리는 안전합니다'라고 말하는 것이 아니다. 중요한 데이터가 어디에 있는지 알고, 누가 접근했는지 설명할 수 있으며, 문제가 생겼을 때 빠르게 탐지하고, 피해를 제한하고, 회복할 수 있음을 보여주는 능력이다. 고객과 시장은 완벽한 무사고를 요구하기보다, 기업이 위험을 어떻게 관리하는지 점점 더 구체적으로 묻고 있다.
그래서 최신 IT 트렌드에서 보안은 마지막에 붙이는 부속품이 아니다. AI, 클라우드, 데이터, SaaS, API, 자동화가 확장될수록 보안은 설계의 중심으로 들어온다. 빠르게 연결되는 기업일수록 빠르게 신뢰를 잃을 수도 있기 때문이다.
사내망 안은 안전하다는 오래된 믿음
전통적인 보안 모델은 비교적 단순한 세계에서 출발했다. 회사 안에는 중요한 서버와 PC가 있고, 회사 밖에는 위험한 인터넷이 있다. 그러니 회사와 인터넷 사이에 방화벽을 세우고, 외부에서 들어오는 사람은 VPN을 통해 사내망에 접속하게 만들면 된다고 생각했다. 이 모델에서는 '안'과 '밖'의 구분이 핵심이었다.
문제는 이제 그 경계가 흐려졌다는 점이다. 업무용 애플리케이션은 사내 데이터센터가 아니라 퍼블릭 클라우드와 SaaS에 있다. 직원의 노트북은 사무실 책상 위에만 있지 않다. 협력사와 프리랜서도 프로젝트 도구, 저장소, 문서 시스템에 접근해야 한다. 개발 환경은 클라우드에 있고, 배포 파이프라인은 여러 외부 서비스와 연결된다.
이런 환경에서 레거시 VPN은 종종 낡은 회전문처럼 작동한다. 한 번 들어오면 사내망의 여러 구역이 생각보다 넓게 보인다. 사용자의 신원은 확인했지만 그 기기가 안전한지, 지금 접속 위치가 평소와 다른지, 접근하려는 데이터가 얼마나 민감한지, 사용자의 행동이 이상한지는 충분히 반영하지 못하는 경우가 많다. 공격자가 계정을 탈취하면 VPN은 공격자에게도 '회사 안으로 들어가는 길'을 열어 줄 수 있다.
게다가 VPN은 생산성 문제도 만든다. 모든 원격 트래픽을 중앙 장비로 우회시키면 속도가 느려지고, 클라우드 서비스와 SaaS를 쓰는 업무 흐름에서는 불필요한 병목이 생긴다. 직원은 느린 접속을 피하려고 우회 방법을 찾고, 보안팀은 더 많은 예외 규칙을 만들며, 예외가 쌓일수록 가시성은 낮아진다. 보안을 강화하려 했던 도구가 오히려 복잡성과 공격 표면을 키우는 역설이 생긴다.
실제로 많은 조직은 여전히 레거시 VPN과 여러 네트워크 보안 도구를 함께 운영하며 복잡성에 시달린다. Tailscale의 2025년 제로 트러스트 보고서는 조사 대상 기업의 41%가 레거시 VPN을 사용하고, 90%가 현재 VPN에서 하나 이상의 문제를 겪으며, 92%가 네트워크 보안을 위해 둘 이상의 도구를 사용한다고 설명한다.1 수치가 말하는 핵심은 명확하다. 지금의 문제는 단일 제품의 성능 부족만이 아니라, 경계 중심 보안 모델 자체가 분산된 업무 환경과 잘 맞지 않는다는 데 있다.
제로 트러스트: 아무도 믿지 않는다는 오해를 넘어
제로 트러스트는 흔히 '아무도 믿지 않는다'는 차가운 문장으로 소개된다. 하지만 실제 의미는 더 정교하다. 사람을 불신하자는 철학이 아니라, 접속 위치만으로 신뢰를 부여하지 말자는 보안 원칙이다. 사내망 안에 있든 밖에 있든, 모든 요청은 검증되어야 한다. Microsoft는 제로 트러스트를 '절대 신뢰하지 말고 항상 검증하라'는 원칙에 기반한 현대적 보안 전략으로 설명하며, 모든 요청을 공개 네트워크에서 온 것처럼 확인하고 침해를 전제로 설계해야 한다고 말한다.2
제로 트러스트의 핵심은 세 가지로 압축할 수 있다.
명시적으로 검증한다. 사용자 신원, 기기 상태, 위치, 애플리케이션, 데이터 민감도, 이상 징후처럼 가능한 많은 신호를 종합해 접근을 판단한다.
최소 권한을 적용한다. 사용자는 지금 업무에 필요한 만큼만, 필요한 시간 동안만, 필요한 리소스에 접근한다.
침해를 가정한다. 이미 내부에 공격자가 있을 수 있다고 보고, 수평 이동을 막고, 로그를 남기고, 빠르게 탐지하고, 피해 범위를 줄인다.
여기서 중요한 단어는 '지속'이다. 과거에는 로그인 한 번이 통과 의례처럼 여겨졌다. 비밀번호와 MFA를 통과하면 일정 시간 동안 신뢰가 유지되었다. 그러나 제로 트러스트에서는 로그인 이후에도 상황이 바뀌면 신뢰 수준도 바뀐다. 평소 서울에서 접속하던 직원이 갑자기 낯선 국가의 IP에서 고객 데이터베이스에 접근하려 한다면 추가 인증을 요구할 수 있다. 관리되지 않는 개인 기기에서 소스코드 저장소에 접근하려 한다면 읽기 권한만 허용하거나 차단할 수 있다. 야간에 대량 다운로드가 발생하면 세션을 중단하고 보안팀에 알릴 수 있다.
제로 트러스트는 제품 이름이 아니라 운영 방식이다. 특정 솔루션 하나를 샀다고 해서 제로 트러스트가 완성되는 것은 아니다. Trend Micro도 제로 트러스트를 네트워크 경계가 아니라 사용자, 자산, 리소스 각각에 초점을 맞추는 접근법으로 설명하며, 특정 제품이 아니라 여러 기술과 정책이 결합된 보안 철학에 가깝다고 강조한다.3 다시 말해 제로 트러스트는 구매 목록이 아니라 질문 목록에 가깝다. 누가, 어떤 기기로, 어디에서, 어떤 앱을 통해, 어떤 데이터에, 왜 접근하는가. 그리고 그 접근은 지금도 안전한가.
이 질문에 답하려면 기업은 먼저 자신의 자산을 알아야 한다. 보호해야 할 데이터가 무엇인지, 핵심 시스템이 어디에 있는지, 어떤 계정이 관리자 권한을 갖고 있는지, 어떤 외부 서비스가 연결되어 있는지 모르면 제로 트러스트는 구호에 머문다. 그래서 제로 트러스트의 출발점은 화려한 대시보드가 아니라 목록화와 가시성이다. 보이지 않는 것은 검증할 수 없고, 검증할 수 없는 것은 통제할 수 없다.
SASE와 ZTNA: 보안과 네트워크가 다시 만나는 방식
제로 트러스트가 원칙이라면, SASE와 ZTNA는 그 원칙을 분산된 업무 환경에 구현하는 대표적인 방식이다. SASE는 Secure Access Service Edge의 약자로, 네트워크 기능과 보안 기능을 클라우드 기반으로 결합하는 구조를 뜻한다. 쉽게 말하면 사용자가 어디에 있든 가까운 클라우드 보안 지점으로 연결하고, 그곳에서 정책을 적용한 뒤 필요한 애플리케이션으로 안전하게 보내는 방식이다.
ZTNA는 Zero Trust Network Access, 즉 제로 트러스트 네트워크 접근을 뜻한다. 전통적 VPN이 사용자를 네트워크 안으로 들여보내는 방식에 가깝다면, ZTNA는 사용자를 특정 애플리케이션에만 연결하는 방식에 가깝다. 사무실 전체 열쇠를 주는 대신, 필요한 회의실 문만 시간 제한을 두고 열어 주는 셈이다.
SASE에는 보통 여러 기능이 함께 들어간다. SD-WAN은 지점과 클라우드 사이의 네트워크 연결을 유연하게 관리한다. 보안 웹 게이트웨이는 위험한 웹사이트나 악성 다운로드를 차단한다. CASB는 클라우드 애플리케이션 사용을 감시하고 통제한다. 방화벽 서비스는 클라우드에서 트래픽 정책을 적용한다. 그리고 ZTNA는 사용자의 애플리케이션 접근을 세밀하게 제어한다. Microsoft는 SASE를 SD-WAN과 제로 트러스트 보안 솔루션을 결합해 사용자, 시스템, 엔드포인트, 원격 네트워크를 애플리케이션과 리소스에 안전하게 연결하는 클라우드 제공 프레임워크로 설명한다.2
이 구조의 장점은 보안과 성능을 함께 다룰 수 있다는 데 있다. 과거에는 보안을 강화하면 느려지고, 빠르게 만들면 위험해지는 식의 트레이드오프가 자주 발생했다. 하지만 SASE와 ZTNA는 사용자의 위치와 애플리케이션의 위치를 기준으로 더 가까운 경로를 선택하면서도 동일한 정책을 적용할 수 있다. 재택근무자는 본사 VPN 장비를 거쳐 다시 클라우드 SaaS로 나갈 필요가 없다. 모바일 사용자는 위치에 따라 가장 적절한 보안 지점으로 연결되고, 정책은 중앙에서 일관되게 관리된다.
물론 이것도 만능은 아니다. SASE 도입이 성공하려면 네트워크팀과 보안팀이 따로 움직이면 안 된다. 과거에는 네트워크팀이 연결성과 속도를, 보안팀이 방어와 통제를 담당했다. 그러나 SASE 환경에서는 연결 방식 자체가 보안 정책의 일부가 된다. 어느 사용자를 어떤 애플리케이션에 연결할지, 어떤 트래픽을 검사할지, 어떤 데이터 이동을 차단할지, 어떤 예외를 허용할지를 함께 설계해야 한다.
또 하나의 함정은 '한 번에 전부 바꾸기'다. 수십 개 지점, 수백 개 애플리케이션, 수천 명 사용자를 한꺼번에 이전하려 하면 실패 가능성이 커진다. 더 현실적인 접근은 고위험 사용자나 고가치 애플리케이션부터 시작하는 것이다. 예를 들어 관리자 계정, 개발자 접근, 고객 데이터베이스, 재무 시스템, 협력사 포털처럼 피해가 클 수 있는 영역에 ZTNA와 조건부 접근을 먼저 적용한다. 작은 성공이 쌓이면 조직은 보안을 '느리게 만드는 장애물'이 아니라 '일을 안전하게 계속하게 하는 기반'으로 받아들이기 시작한다.
AI는 공격자에게도, 방어자에게도 날개를 달아준다
AI는 사이버보안의 균형을 흔들고 있다. 공격자는 더 빠르고 더 그럴듯한 공격을 만들 수 있게 되었다. 예전의 피싱 메일은 어색한 번역투와 이상한 문장 때문에 쉽게 의심받았다. 이제 생성형 AI는 특정 회사의 말투, 업무 용어, 직무 맥락을 반영해 훨씬 자연스러운 문구를 만들 수 있다. 공격자는 채용 공고, 보도자료, 임직원 SNS, 개발자 커뮤니티 글을 모아 맞춤형 사회공학 공격을 설계한다.
딥페이크는 신원 확인을 더 어렵게 만든다. 영상회의에서 낯익은 임원이 긴급 송금을 지시하거나, 음성 메시지로 비밀번호 초기화를 요청하는 장면은 더 이상 영화적 상상에만 머물지 않는다. 악성코드도 AI를 활용해 변형 속도를 높일 수 있다. 보안 솔루션에 탐지되지 않도록 코드 구조를 조금씩 바꾸거나, 취약한 시스템을 자동으로 찾아 공격 순서를 조정하는 방식이 쉬워지고 있다. 2026년 사이버보안 전망에서도 자동화된 AI 공격, 딥페이크 기반 신원 조작, 통제되지 않는 외부 AI 사용, 공급망 취약성이 주요 위협으로 언급된다.4
하지만 AI는 방어자에게도 강력한 도구다. 보안팀이 겪는 가장 큰 어려움 중 하나는 신호가 너무 많다는 점이다. 하루에도 수많은 로그, 경고, 접속 기록, 엔드포인트 이벤트가 쌓인다. 이 중 진짜 위험한 사건은 일부에 불과하지만, 사람만으로는 우선순위를 빠르게 판단하기 어렵다. AI는 정상 행동의 패턴을 학습하고, 평소와 다른 접근이나 데이터 이동을 찾아내며, 여러 시스템의 경고를 하나의 사건으로 묶어 분석할 수 있다.
예를 들어 한 직원의 계정이 새벽에 해외 IP에서 로그인했고, 곧바로 소스코드 저장소에서 대량 복제를 수행했으며, 이어 클라우드 저장소에 비정상 파일 업로드가 발생했다고 해 보자. 각각의 이벤트만 보면 애매할 수 있다. 하지만 AI 기반 탐지 시스템은 이 흐름을 하나의 공격 시나리오로 연결하고 위험도를 높게 평가할 수 있다. 보안팀은 수천 개 경고를 하나씩 확인하는 대신, 가장 위험한 사건부터 대응할 수 있다.
AI가 유용한 보안 영역은 점점 넓어지고 있다.
위협 인텔리전스 분석: 공격자 인프라, 악성 도메인, 취약점 정보, 다크웹 유출 데이터를 연결해 위험 신호를 찾는다.
보안 이벤트 우선순위화: 수많은 경고 중 실제 피해 가능성이 큰 사건을 먼저 보여준다.
자동 대응: 의심 계정을 잠그고, 세션을 종료하고, 감염 의심 기기를 격리하고, 방화벽 정책을 임시 변경한다.
보안 운영 보조: 분석가가 로그를 자연어로 질의하고, 사고 보고서 초안을 만들며, 대응 절차를 빠르게 확인한다.
그러나 AI 보안의 핵심은 '자동화'보다 '책임 있는 자동화'다. AI가 잘못된 판단으로 정상 사용자를 차단하면 업무가 멈춘다. 반대로 위험한 행동을 정상으로 판단하면 피해가 커진다. 따라서 AI 기반 보안은 사람의 검토, 명확한 권한 범위, 감사 가능한 로그, 모델 성능 평가와 함께 운영되어야 한다. AI는 보안팀을 대체하는 것이 아니라, 보안팀이 시간과 주의를 더 중요한 판단에 쓰도록 돕는 증폭기다.
공급망 보안: 우리 코드만 안전해서는 부족하다
현대 소프트웨어는 혼자 만들어지지 않는다. 개발자는 오픈소스 패키지를 사용하고, 컨테이너 이미지를 가져오며, CI/CD 파이프라인으로 자동 빌드와 배포를 수행한다. 인증은 외부 ID 제공자와 연결되고, 결제는 PG사 API를 호출하며, 고객 상담은 SaaS에 기록된다. 기업의 서비스는 수많은 외부 구성요소 위에서 작동한다.
그래서 공격자는 정문만 노리지 않는다. 더 쉬운 길을 찾는다. 널리 쓰이는 오픈소스 패키지에 악성 코드를 심거나, 비슷한 이름의 패키지를 올려 개발자가 실수로 설치하게 만들 수 있다. 빌드 서버의 토큰을 탈취해 정상 업데이트처럼 악성 코드를 배포할 수도 있다. 협력사의 계정을 통해 내부 시스템에 접근하거나, SaaS 권한 위임을 악용해 고객 데이터를 빼낼 수도 있다. 기업 내부 방화벽이 아무리 튼튼해도, 공급망의 약한 고리 하나가 전체 신뢰를 무너뜨릴 수 있다.
소프트웨어 공급망 보안은 이제 개발팀만의 일이 아니다. 구매, 법무, 보안, 인프라, 데이터 거버넌스가 함께 다뤄야 하는 운영 과제다. 어떤 오픈소스와 상용 컴포넌트를 쓰는지, 어떤 버전이 배포되어 있는지, 어떤 취약점이 영향을 미치는지, 누가 배포 권한을 갖고 있는지 알아야 한다. 또한 외부 파트너가 우리 데이터에 접근할 때 어떤 권한을 갖는지, 계약 종료 후 권한이 제거되는지, 사고 발생 시 통지와 대응 절차가 있는지도 확인해야 한다.
여기서 SBOM이 중요해진다. SBOM은 Software Bill of Materials, 즉 소프트웨어 자재 명세서다. 식품 포장지에 원재료가 적혀 있듯, 소프트웨어가 어떤 라이브러리와 컴포넌트로 구성되어 있는지 목록화하는 개념이다. SBOM이 있으면 특정 오픈소스 취약점이 공개되었을 때 우리 서비스가 영향을 받는지 빠르게 확인할 수 있다. 없다면 개발팀은 저장소를 뒤지고, 배포 이미지를 확인하고, 담당자를 찾아다니며 시간을 잃는다. 사고 대응에서 시간은 곧 피해 규모다.
공급망 보안은 다음과 같은 실천으로 구체화된다.
의존성 검증: 사용 중인 오픈소스 패키지와 버전을 관리하고, 알려진 취약점과 악성 패키지 여부를 지속적으로 확인한다.
코드 서명과 배포물 검증: 빌드 결과물이 신뢰할 수 있는 주체에 의해 만들어졌고 중간에 변조되지 않았는지 확인한다.
CI/CD 권한 관리: 빌드 서버, 배포 계정, API 토큰, 비밀키 접근을 최소화하고 자동 만료와 회전을 적용한다.
SaaS와 API 권한 점검: 외부 애플리케이션에 부여한 권한을 정기적으로 검토하고, 과도한 권한과 사용하지 않는 연결을 제거한다.
협력사 보안 평가: 파트너가 어떤 보안 통제와 사고 대응 체계를 갖췄는지 계약과 운영 절차에 반영한다.
이 모든 활동의 목적은 개발 속도를 늦추는 것이 아니다. 오히려 반대다. 신뢰할 수 있는 소프트웨어 공장을 만드는 것이다. 개발자가 매번 보안팀의 승인을 기다리는 구조가 아니라, 안전한 기본값이 파이프라인 안에 들어 있어야 한다. 취약한 패키지는 자동으로 알려 주고, 비밀키가 코드에 들어가면 커밋 단계에서 막고, 배포물은 자동으로 서명되고, 운영 환경 접근은 임시 권한으로 부여되어야 한다. 좋은 공급망 보안은 개발자의 발목을 잡지 않고, 위험한 실수를 조용히 줄여 준다.
클라우드와 데이터 접근은 제로 트러스트의 시험대다
많은 기업이 제로 트러스트를 말하지만, 실제 시험대는 클라우드와 데이터 접근에서 드러난다. 클라우드는 빠르다. 개발자는 몇 분 만에 서버를 만들고, 데이터베이스를 열고, 외부 서비스를 붙일 수 있다. 이 속도는 혁신의 원천이지만, 동시에 잘못된 설정과 과도한 권한이 빠르게 퍼지는 통로가 된다.
StrongDM의 클라우드 제로 트러스트 보고서에 따르면 조사 대상 조직의 81%가 제로 트러스트 모델을 완전히 또는 부분적으로 구현했고, 84%가 클라우드 보안을 위해 제로 트러스트를 적극 추진하고 있다. 동시에 멀티클라우드 정책 관리, 비용과 자원 제약, 데이터베이스 접근 통제 부족 같은 과제가 여전히 크다고 설명한다.5 이 결과는 중요한 현실을 보여 준다. 제로 트러스트는 모두가 가야 한다고 생각하는 방향이지만, 실제 운영으로 녹여 내는 일은 쉽지 않다.
특히 데이터베이스 접근은 까다롭다. 애플리케이션 서버, 분석 도구, 운영자, 데이터 과학자, 외부 파트너가 각기 다른 이유로 데이터에 접근한다. 어떤 접근은 실시간 서비스 운영에 필요하고, 어떤 접근은 분석 목적이며, 어떤 접근은 장애 대응을 위해 일시적으로 필요하다. 이때 모든 사람에게 넓은 권한을 주면 편하지만 위험하다. 반대로 너무 많은 절차를 만들면 업무가 멈춘다.
좋은 접근은 '정책의 세밀함'과 '경험의 단순함'을 함께 추구한다. 사용자는 자신의 역할에 맞는 데이터를 쉽게 찾고 사용할 수 있어야 한다. 그러나 민감한 데이터에는 추가 승인, 마스킹, 감사 로그, 다운로드 제한이 적용되어야 한다. 관리자 권한은 상시 보유가 아니라 필요할 때만 부여되고, 사용 후 자동 회수되어야 한다. 데이터 접근은 보안팀만 보는 것이 아니라 데이터 오너와 업무 책임자도 이해할 수 있어야 한다.
여기서 앞 장에서 다룬 데이터 거버넌스와 보안이 만난다. 데이터가 어디에 있는지, 어떤 등급인지, 누가 소유자인지, 어떤 업무 목적에 쓰이는지 모르면 접근 정책도 만들 수 없다. 데이터 경쟁력을 높이는 조직은 동시에 데이터 접근의 책임성을 높여야 한다. 데이터가 많아질수록 신뢰의 질문은 더 날카로워진다. 고객의 개인정보가 어디에 있고, 누가 보았고, 왜 필요했으며, 언제 삭제되는가. 이 질문에 답하지 못하는 데이터 조직은 오래 버티기 어렵다.
보안 성숙도는 솔루션 개수가 아니라 회복력으로 측정된다
기업은 종종 보안 성숙도를 도입한 솔루션의 개수로 설명하려 한다. EDR도 있고, SIEM도 있고, WAF도 있고, DLP도 있고, 클라우드 보안 도구도 있다고 말한다. 물론 도구는 중요하다. 하지만 도구 목록은 신뢰의 증거가 될 수 없다. 더 중요한 것은 그 도구들이 실제 위험을 줄이고, 사고를 빨리 발견하고, 피해를 제한하고, 회복을 돕는가다.
성숙한 보안 조직은 '우리는 절대 뚫리지 않는다'고 말하지 않는다. 대신 '우리는 침해를 빨리 발견하고, 확산을 막고, 핵심 서비스를 복구할 수 있다'고 말한다. 이것이 사이버 회복력이다. 회복력은 예방을 포기한다는 뜻이 아니다. 예방을 하되, 예방 실패까지 설계한다는 뜻이다.
보안 성숙도를 판단하는 지표도 이 방향으로 바뀌어야 한다.
탐지 시간과 대응 시간: 이상 행위를 발견하는 데 얼마나 걸리고, 계정 차단·기기 격리·서비스 복구까지 얼마나 걸리는가.
권한 가시성: 누가 어떤 시스템과 데이터에 접근할 수 있으며, 그 권한이 왜 필요한지 설명할 수 있는가.
최소 권한 적용률: 관리자 권한, 상시 권한, 공유 계정, 퇴사자 계정, 장기 미사용 계정을 얼마나 줄였는가.
데이터 보호 수준: 민감 데이터가 분류되고, 암호화되고, 마스킹되고, 외부 유출 경로가 통제되는가.
사고 훈련과 복구 능력: 랜섬웨어, 클라우드 계정 탈취, 공급망 침해 같은 시나리오를 실제로 훈련하고 복구 시간을 측정하는가.
외부 신뢰 지표: 고객과 파트너가 확인할 수 있는 보안 인증, 감사 보고서, 취약점 대응 절차, 사고 통지 체계가 있는가.
이 지표들은 경영진의 언어로 번역되어야 한다. 보안팀이 '취약점 3,000개를 발견했다'고 보고하는 것만으로는 충분하지 않다. 그중 고객 데이터에 영향을 줄 수 있는 취약점은 무엇인지, 핵심 서비스 중단으로 이어질 가능성은 어느 정도인지, 개선에 필요한 비용과 우선순위는 무엇인지 설명해야 한다. 디지털 신뢰는 기술 보고서가 아니라 경영 판단의 일부가 되어야 한다.
고객과 파트너가 확인할 수 있는 신뢰
디지털 신뢰의 중요한 특징은 외부에서 확인 가능해야 한다는 점이다. 내부적으로 아무리 훌륭한 보안 체계를 갖췄다고 해도 고객과 파트너가 알 수 없다면 시장의 신뢰로 이어지기 어렵다. 특히 B2B 시장에서는 보안 질문지가 영업 과정의 일부가 되었다. 고객은 암호화 방식, 접근 통제, 로그 보관, 취약점 관리, 하위 처리업체, 백업과 복구, 사고 통지 시간을 묻는다. 대기업 고객일수록 이 질문은 더 구체적이다.
이때 보안은 영업의 장애물이 아니라 계약을 가능하게 하는 조건이 된다. 보안팀이 미리 준비한 문서와 증거가 있으면 영업 사이클이 짧아진다. 반대로 보안 체계가 불명확하면 좋은 제품을 갖고도 계약이 지연되거나 탈락할 수 있다. 고객은 기능만 사는 것이 아니라, 그 기능을 안전하게 운영할 능력까지 함께 산다.
파트너 생태계에서도 마찬가지다. API를 공개하고, 외부 개발자와 연결하고, SaaS 간 데이터를 주고받는 기업은 신뢰 규칙을 명확히 해야 한다. 어떤 권한을 요청하는지, 데이터는 어디에 저장되는지, 사용자가 연결을 끊으면 데이터는 어떻게 삭제되는지, 토큰은 어떻게 보호되는지 설명할 수 있어야 한다. API 경제에서 보안은 연결을 막는 장벽이 아니라, 더 많은 연결을 가능하게 하는 계약 언어다.
Zscaler는 2025년 전망에서 제로 트러스트가 기업의 기본 보안 모델로 자리 잡고, SASE 통합과 실시간 경영진 가시성, AI 기반 탐지와 대응, 정체성 중심 접근 제어가 중요해질 것이라고 예측한다.6 여기서 특히 주목할 부분은 '경영진 가시성'이다. 보안은 더 이상 보안 운영센터 안에서만 소비되는 정보가 아니다. 이사회와 CEO, CFO, CPO가 사이버 리스크를 실시간에 가깝게 이해하고 의사결정해야 하는 영역이 되었다.
실행 로드맵: 거창한 선언보다 작은 검증부터
제로 트러스트, SASE, AI 보안, 공급망 보안을 한꺼번에 완성하려 하면 조직은 쉽게 지친다. 중요한 것은 선언이 아니라 순서다. 가장 큰 위험을 먼저 줄이고, 조직이 따라올 수 있는 속도로 운영 방식을 바꾸어야 한다.
첫 단계는 자산과 접근의 가시성을 확보하는 것이다. 사용자, 기기, 애플리케이션, 데이터, API, 클라우드 계정, SaaS 연결, 오픈소스 의존성을 목록화한다. 이 과정은 지루해 보이지만 필수다. 보안의 대부분은 '모르는 것'에서 무너진다. 누가 관리자 권한을 갖고 있는지, 어떤 외부 앱이 메일과 파일에 접근할 수 있는지, 어떤 저장소에 고객 정보가 있는지 알아야 다음 단계로 갈 수 있다.
두 번째 단계는 정체성 보안을 강화하는 것이다. MFA를 기본값으로 만들고, 관리자 계정에는 더 강한 인증과 별도 관리를 적용한다. 퇴사자와 이동자의 권한 회수를 자동화하고, 장기 미사용 계정을 제거한다. 권한 요청과 승인을 업무 흐름에 맞게 단순화하되, 민감한 시스템에는 임시 권한과 승인 로그를 남긴다.
세 번째 단계는 고위험 애플리케이션부터 ZTNA와 조건부 접근을 적용하는 것이다. 모든 시스템을 한 번에 바꾸기보다 고객 데이터, 소스코드, 운영 콘솔, 재무 시스템처럼 피해가 큰 영역을 우선한다. 이후 부서, 지점, 협력사, 개발 환경으로 확대한다. 이때 사용자 경험을 함께 측정해야 한다. 보안이 너무 불편하면 사람은 우회로를 만든다. 좋은 보안은 사용자가 안전한 길을 가장 쉬운 길로 느끼게 만든다.
네 번째 단계는 탐지와 대응 자동화를 강화하는 것이다. 로그를 모으는 것에서 끝나지 말고, 사건을 식별하고 우선순위를 매기며, 반복 대응을 자동화한다. AI는 이 단계에서 큰 역할을 할 수 있다. 다만 자동 차단 정책은 영향 범위를 작게 시작해 점진적으로 확대해야 한다. 처음부터 모든 의심 행위를 자동 차단하면 업무 중단 리스크가 커진다.
다섯 번째 단계는 공급망 보안을 개발 파이프라인에 녹이는 것이다. 의존성 스캔, 비밀키 탐지, 코드 서명, 컨테이너 이미지 검증, 배포 승인, SBOM 생성이 개발 흐름 속에서 자연스럽게 이루어지도록 한다. 보안팀이 마지막에 검사하는 방식이 아니라, 개발자가 코드를 작성하고 배포하는 과정 곳곳에 안전장치를 심어야 한다.
마지막 단계는 신뢰 지표를 외부 커뮤니케이션으로 연결하는 것이다. 보안 인증과 감사 보고서, 취약점 신고 채널, 데이터 처리 정책, 사고 통지 절차, 서비스 상태 페이지, 고객용 보안 문서를 정리한다. 이는 단순 홍보가 아니다. 기업이 자신의 보안 운영을 투명하게 설명하고, 고객이 합리적으로 판단할 수 있게 하는 신뢰 인프라다.
디지털 신뢰는 속도를 늦추지 않는다
보안을 강화하자고 하면 어떤 조직은 먼저 걱정한다. 개발 속도가 느려지는 것 아닌가. 직원들이 불편해지는 것 아닌가. 고객 온보딩이 복잡해지는 것 아닌가. 이런 걱정은 현실적이다. 잘못 설계된 보안은 실제로 속도를 늦춘다. 모든 요청을 수동 승인으로 돌리고, 예외를 문서로만 관리하고, 현업의 업무 흐름을 이해하지 못하면 보안은 우회당한다.
하지만 잘 설계된 보안은 반대로 속도를 만든다. 새 직원이 입사하면 역할에 맞는 권한이 자동으로 부여되고, 프로젝트가 끝나면 자동으로 회수된다. 개발자는 안전한 템플릿과 검증된 패키지를 사용해 빠르게 배포한다. 고객 보안 질문에는 준비된 증거로 신속히 답한다. 사고가 발생해도 무엇을 차단하고 무엇을 복구해야 하는지 알기 때문에 혼란이 줄어든다.
디지털 신뢰는 '느리지만 안전한 회사'가 되자는 말이 아니다. '빠르게 움직이면서도 설명 가능한 회사'가 되자는 말이다. AI가 업무를 자동화하고, 클라우드가 인프라를 유동화하며, API가 기업 간 경계를 허무는 시대에는 보안도 같은 속도로 진화해야 한다. 성벽을 높이는 것만으로는 부족하다. 모든 문에 맥락을 이해하는 잠금장치를 달고, 복도마다 움직임을 감지하며, 문제가 생기면 즉시 격리하고 복구하는 건물처럼 기업을 설계해야 한다.
사이버보안의 미래는 공포의 언어가 아니라 신뢰의 언어다. 고객은 완벽한 무결점을 기대하지 않는다. 대신 기업이 위험을 알고 있는지, 통제하고 있는지, 사고가 났을 때 책임 있게 행동할 수 있는지를 본다. 제로 트러스트, SASE, AI 기반 보안, 공급망 보안은 각각 다른 기술처럼 보이지만 결국 하나의 질문으로 모인다.
'이 기업은 디지털 세계에서 믿고 연결할 수 있는가?'
이 질문에 자신 있게 답할 수 있는 기업만이 더 많은 데이터, 더 많은 파트너, 더 많은 자동화, 더 큰 시장을 감당할 수 있다. 보안은 비용이 아니라 신뢰를 생산하는 시스템이다. 그리고 앞으로의 경쟁은 누가 더 많은 기술을 가졌는가보다, 누가 더 안전하게 연결되고 더 빠르게 회복하며 더 투명하게 증명할 수 있는가에서 갈릴 것이다.
참고
1The State of Zero Trust report 2025 | Tailscale
2Protect and modernize your organization with a Zero Trust strategy | Microsoft
3What Is Zero Trust? | Trend Micro
4Top Cyber Security Trends in 2026 | National Cyber Security Institute
5The State of Zero Trust Security in the Cloud Report | StrongDM
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.