제로트러스트 기반 제품이라고 광고하면 정말 제로트러스트일까요? 그렇지 않습니다. 제로트러스트 아키텍처(ZTA)는 단일 기능이나 브랜드가 아니라, 사용자·기기·워크로드가 자원에 접근할 때 정책에 따라 판단하고 집행하는 설계 방식입니다. 제품은 그 설계의 일부를 구현할 수 있지만, 제품 하나를 도입했다고 조직 전체가 제로트러스트로 전환되지는 않습니다.
이 글에서 확인할 내용
제로트러스트는 무엇이고 무엇이 아닌가
미국 NIST SP 800-207은 네트워크 위치나 소유권만으로 신뢰를 부여하지 않으며, 보호 대상의 중심을 네트워크 구간에서 개별 자원으로 옮깁니다. 이때 중요한 것은 접근 주체의 인증만이 아닙니다. 요청 대상, 권한, 기기 상태, 위협 신호 등을 이용해 접근 결정을 내리고 실제로 집행하는 흐름입니다.
PE·PA·PEP가 어려우면 ‘회사 자료실의 출입문’을 떠올리세요
회사의 중요한 자료실에 들어가려는 사람이 있다고 가정해 봅시다. 예전에는 회사 출입증만 있으면 복도를 지나 여러 방에 들어갈 수 있었다면, 제로트러스트에서는 이 사람이 지금 이 방에 이 일을 하러 들어갈 자격이 있는지를 따로 확인합니다. 이를 컴퓨터 시스템에 적용한 것이 NIST가 설명하는 접근 판단 구조입니다.
PE(정책 엔진) = 출입 허가를 심사하는 사람
“직원이 맞나? 이 업무를 맡았나? 회사가 관리하는 안전한 노트북인가? 지금 허용된 시간인가?”를 확인하고 들어와도 된다 / 안 된다고 결정합니다.
PA(정책 관리자) = 심사 결과를 출입문에 전달하는 담당자
허가가 나면 특정 방의 출입 권한을 일정 시간 발급하고, 취소되면 출입 권한을 거두도록 지시합니다.
PEP(정책 집행 지점) = 실제로 열리고 잠기는 출입문
허가받은 사람만 해당 자료실로 보내고, 거부된 사람은 문 앞에서 막습니다. 접근 중 허가가 철회되면 연결도 종료하도록 제어합니다.
외우는 방법은 간단합니다. PE는 판단, PA는 지시·연결 관리, PEP는 실제 차단·허용입니다. 단, 이 비유는 이해를 돕기 위한 것입니다. 실제로는 장비 세 대를 따로 사는 것이 아니라 하나의 서비스가 여러 역할을 수행하거나 여러 제품이 역할을 나눌 수 있습니다. NIST도 이를 ‘논리적 구성’으로 설명합니다.
따라서 VPN을 ZTNA로 바꾸거나, MFA를 켜거나, 망을 작게 나누는 일만으로 완결되지 않습니다. 이들은 훌륭한 구성 요소일 수 있지만 ‘로그인 성공 후 무제한 연결’이나 ‘사내망이므로 허용’ 같은 암묵적 신뢰가 그대로 남아 있다면 전환은 불완전합니다. 제로트러스트는 방화벽을 무조건 폐기하라는 뜻도 아닙니다. 기존 경계 보안은 역할을 조정해 함께 사용할 수 있습니다.
한 회사의 중요 시스템에 누가 들어갈 수 있을까
아래는 실제 기업 사고나 정부 시스템을 묘사한 것이 아닌 NIST의 원칙을 풀어 쓴 가상 시나리오입니다. A회사의 ‘고객정보 관리 시스템’을 보호한다고 가정하겠습니다. 재직자, 외부 협력사, 유지보수 담당자가 모두 같은 시스템에 접속하려 하지만 신원만 같다고 같은 권한을 주지 않습니다.
상황 A · 재직자: 직원이라도 모든 고객정보를 볼 수는 없다
고객지원팀 직원 민지는 회사 노트북으로 고객정보 시스템의 ‘고객 문의 내역’ 화면을 엽니다. PE는 직원 신분, 직무, 기기 보안상태, 요청한 화면을 확인해 ‘담당 고객의 문의내역 조회’만 허용합니다. PA는 이 범위의 세션이 열리도록 지시하고, PEP는 조회 화면으로만 통과시킵니다. 민지가 고객정보 전체를 내려받거나 관리자 화면을 열면 별도의 권한이 없으므로 거부됩니다. 회사 사람이란 이유만으로 자동 허용되지 않는 지점이 핵심입니다.
상황 B · 외부 협력자: 계약이 있어도 필요한 업무만
외주 통계 분석가 준호는 협력사 계정으로 접속을 신청합니다. 계약은 유효하지만 사전에 승인된 분석용 데이터 화면만 볼 수 있고 원본 개인정보는 열람할 수 없다는 정책이 있습니다. PE는 협력사 계정·계약기간·승인 업무·단말 조건을 확인합니다. 조건을 충족하면 PA가 한정된 접속을 열게 하고 PEP가 허용 화면 외 경로를 차단합니다. 계약이 끝나 계정이 비활성화되면 정책 갱신 및 세션 재평가를 통해 기존 접근을 철회해야 합니다.
상황 C · 유지보수 담당자: 관리자 권한도 필요한 시간에만
시스템 장애로 외부 유지보수 기사 서윤이 긴급 접속을 요청합니다. 시스템 관리자라고 해서 상시 무제한 권한을 주지 않습니다. 등록된 작업요청, 담당자 승인, 강한 인증, 승인된 관리 단말, 30분의 허용시간을 조건으로 정했다고 가정해 봅시다. PE가 조건을 확인해 승인하면 PA가 단기 세션을 만들고 PEP가 지정한 관리 기능으로만 접근시킵니다. 작업이 끝나거나 위험 신호가 발생하면 세션을 종료하며, 로그에는 승인 사유와 수행 행위가 남아야 합니다.
| 접근자 | 허용할 수 있는 일 | 차단할 일 | 다시 확인할 상황 |
|---|---|---|---|
| 재직자 | 담당 고객 문의 조회 | 전체 고객정보 다운로드 | 기기 위험 증가·직무 변경 |
| 외부 협력자 | 승인된 분석용 화면 | 원본 개인정보 열람 | 계약 만료·계정 비활성화 |
| 유지보수 인력 | 승인된 기간의 지정 관리 기능 | 상시 관리자 접속·무관한 기능 | 작업 종료·시간 만료·위험 탐지 |
여기서 접근통제란 ‘누가 어떤 일을 할 수 있나’를 정하는 것이고, 마이크로세그멘테이션이란 필요 없는 서버·서비스 간 이동 경로를 잘게 끊는 데 쓰는 기술 방식입니다. 둘은 중요하지만 그 자체가 제로트러스트의 전부는 아닙니다. 무엇을 왜 허용할지 판단하고, 실제로 제한하며, 상황이 바뀌면 권한을 거두는 전체 흐름이 아키텍처입니다.
다른 사람에게는 이렇게 설명하면 됩니다. “제로트러스트는 회사 건물에 들어왔다고 모든 방 열쇠를 주지 않는 방식이다. 직원이든 외주 직원이든 정해진 방에, 정해진 일로, 정해진 조건에서만 들어가게 하는 것이다.”
제품이 진짜 작동하는지 확인하는 방법
업체 데모에서는 ‘접속 화면’ 대신 정책의 입력값 → 결정 → 집행 → 로그 → 상태 변경 후 재평가의 전체 경로를 요청해야 합니다. 단일 제품에 모든 기능을 요구하기보다 해당 제품이 담당하는 범위를 분명하게 밝히게 하고 다른 시스템과의 연결을 검증하는 편이 공정합니다.
표가 화면보다 넓으면 좌우로 스크롤하세요.
| 검증 항목 | 업체에 물을 질문 | 시험 예시 |
|---|---|---|
| 인증 | 계정·단말 신호를 함께 평가하는가 | 적법한 계정으로 미관리 단말 접속 시 제한 확인 |
| 인가·최소권한 | 앱·데이터·행위별로 세분화할 수 있는가 | 일반 사용자의 관리자 기능 접근 차단 확인 |
| 재평가·철회 | 접속 중 위험이 바뀌면 권한을 줄이거나 끊는가 | 단말 상태 악화·계정 비활성화 후 세션 처리 확인 |
| 집행 지점 | 정책 거부를 실제 연결 차단으로 구현하는가 | 우회 경로·직접 접속 경로 차단 확인 |
| 관측·감사 | 의사결정 이유와 정책 변경 내역이 남는가 | 로그로 누가·무엇에·왜 접근했는지 재구성 |
| 상호운용성·장애 | 기존 IAM·EDR·SIEM·클라우드와 연동하며 장애 시 안전한가 | API 증빙·정책 충돌·PEP 장애·예외 절차 시험 |
특히 주의할 것은 ‘지속 검증’을 과장하는 설명입니다. 제로트러스트가 모든 패킷마다 사람에게 MFA를 다시 요구한다는 뜻은 아닙니다. 위험 신호에 따라 세션을 재평가하고 정책을 갱신할 수 있는지, 적용 범위와 지연 시간이 무엇인지 확인해야 합니다. 또 CC·GS 등 일반 제품 인증이나 실증사업 선정만으로 조직 전체의 ZTA 준수를 입증했다고 보아서는 안 됩니다.
조직 보안체계에 적용하는 순서
제품 목록보다 자원과 접근 관계부터 정리한다
먼저 중요한 업무와 데이터를 정하고 누가, 어떤 관리·비관리 기기와 서비스 계정으로, 어디에서 접근하는지 목록화합니다. 클라우드뿐 아니라 레거시 서버, API, 외주·협력사 계정, 서비스 간 통신도 포함해야 합니다. 영국 NCSC 역시 자산 및 신원을 파악하는 일을 초기 원칙으로 제시합니다.
보호 범위를 작게 잡고 정책을 시험한다
예를 들어 인사정보 시스템을 대상으로 일반 직원은 조회만, 승인된 인사 담당자는 특정 업무를, 관리자는 한시적 승인을 받아 관리 기능에 접근하도록 정책을 세웁니다. 이후 미관리 기기, 계정 비활성화, 비정상 행위, API 토큰 탈취 의심 등 상황에서 접근이 실제로 줄어드는지 시험합니다. 장애 시 허용으로 우회되는지, 업무 연속성이 유지되는지도 점검합니다.
도입 전후 결과를 운영 데이터로 비교한다
접근 가능한 자원의 범위, 과도한 권한 계정 수, 정책 위반 차단과 오탐, 세션 철회 시간, 운영 비용 및 사용자 불편을 함께 측정합니다. 숫자가 좋아진 원인을 다른 보안 조치와 분리하기 어려울 수 있으므로 실증 결과를 과장해서는 안 됩니다. 기존 보안체계를 검증 없이 한꺼번에 제거하는 것도 위험합니다.
미국·유럽·한국 정책의 차이
미국: 2020년 NIST SP 800-207이 기술적 개념과 구성 요소를 정리했고, 2022년 연방 OMB M-22-09는 기관별 실행 목표와 일정(당시 2024 회계연도까지)을 제시했습니다. CISA의 2023년 성숙도 모델 2.0은 신원·기기·네트워크·애플리케이션/워크로드·데이터의 다섯 축과 이를 가로지르는 역량을 통해 발전 단계를 설명합니다. 이는 정부 목표와 성숙도 틀이지, 모든 미국 민간 제품에 대한 단일 공식 인증은 아닙니다.
유럽: EU NIS2 지침은 위험관리, 접근통제, 자산관리, 적절한 다중인증·연속인증 등 의무를 규정하지만, 제로트러스트라는 이름의 제품을 일괄 구매하도록 명령하지는 않습니다. EU의 규제 방식과 각국의 기술 가이드를 구분해야 합니다. 영국은 EU 회원국은 아니지만, NCSC가 네트워크 불신·정책 기반 인가·기기 건강 상태·모니터링 등 실제 설계 원칙을 상세히 공개한 비교 사례입니다.
한국: 과기정통부·KISA는 2024년 제로트러스트 가이드라인 2.0을 발표하고 2025년 12월 성숙도 모델 해설서를 공개했습니다. 2026년 민간 시범사업 공고에는 강화된 인증·마이크로 세그멘테이션·SDP, 기존 제품 간 연동, 도입 전후 성숙도 검증이 포함됩니다. OT 환경에 대한 별도 적용 안내서도 마련됐습니다. 즉 국내 논의가 단순 제품 홍보에 머물러 있다고 보는 것은 공개 문서와 맞지 않습니다.
국내 정책에서 더 검증해야 할 쟁점
여기서부터는 공식 문서의 인용이 아니라 SAGE의 편집 분석입니다. 정책 문서와 지원사업의 방향은 검증 가능한 통합과 운영 성과에 무게를 싣고 있습니다. 다만 시장에서 ‘제로트러스트 기반’이라는 표현을 접한 구매자가 어떤 기능이 어느 보호 범위에서, 어떤 조건으로 검증됐는지 동일한 형식으로 비교하기는 여전히 어렵습니다. 공개된 공고만으로 전체 시장의 성과나 실패를 판정할 수는 없습니다.
우선 개선할 분야는 세 가지입니다. 첫째, 상품 광고와 조달 설명에 해당 제품이 구현하는 PE·PA·PEP 역할과 검증 범위를 명시하도록 유도하는 것입니다. 둘째, 실증 결과에 정책 우회 차단, 접근 철회, 운영 장애, 상호운용성 등의 재현 가능한 시험 조건을 붙이는 것입니다. 셋째, 솔루션 수량이나 인증 건수뿐 아니라 도입 조직의 실제 권한 축소와 위험 감소를 설명하는 공개 지표를 발전시키는 것입니다.
반론도 중요합니다. 지나친 획일적인 시험표는 조직 규모와 OT·클라우드 등 환경 차이를 무시할 수 있고, 보안상 민감한 테스트 상세 공개는 새로운 위험을 만들 수 있습니다. 따라서 정부가 특정 제품 구조를 강제하기보다 공통 증빙 서식 + 분야별 예외 + 독립적인 확인 절차를 마련하는 방식이 검토할 만한 대안입니다.
“귀사 제품이 제로트러스트라는 설명 말고, 우리 조직의 특정 자원에 대한 접근을 어떤 근거로 허용·거부하고, 위험 상황에서 어떻게 철회하는지 재현 가능한 시나리오로 보여주세요.”
자주 묻는 질문
Q. MFA 제품이면 제로트러스트 제품인가요?
MFA는 중요한 구성 요소지만, 인증 이후의 자원별 권한 통제·정책 집행·상태 변화에 따른 조치까지 자동으로 보장하지 않습니다.
Q. 제로트러스트를 도입하면 방화벽·VPN이 필요 없어지나요?
반드시 그렇지 않습니다. 기존 장비는 자원 격리·트래픽 통제 등에 계속 유용하며, ZTNA 등으로 바꾸더라도 기존 보호 범위를 시험한 뒤 단계적으로 전환해야 합니다.
Q. 정부 사업에 선정된 제품이면 성능이 검증된 것인가요?
사업 선정과 해당 제품의 모든 사용환경에서의 효과 입증은 구분해야 합니다. 구체적인 실증 결과, 시험 범위, 예외·제약 조건을 요청하세요.
공식 웹페이지와 원문 링크 확인일: 2026-11-10. PDF 일부 내용은 검색 가능한 원문 발췌 기준이며 실무 적용 시 원문 전체를 확인하세요.