Cloudflare One 제로트러스트 도입 2026, VPN 대체 전 비용·보안·운영 기준
요약: Cloudflare One 제로트러스트 도입 전 VPN 대체 가능성, 비용 항목, 보안 정책, 운영 리스크를 실무 기준으로 정리합니다.
사내 VPN을 계속 늘릴지, 제로트러스트 네트워크 접근으로 전환할지 고민하는 팀이라면 먼저 질문을 바꿔야 한다. “Cloudflare One을 쓰면 VPN을 없앨 수 있나?”보다 “우리 회사의 앱, 사용자, 단말, 로그, 예외 처리 방식이 제로트러스트 운영을 버틸 수 있나?”가 먼저다. 제품 이름보다 운영 조건이 승패를 가른다.
Cloudflare는 2026년 6월 Cloudflare One stack을 공개했다. 이 발표의 핵심은 단순한 새 보안 기능이 아니다. 보안팀이 Zero Trust 환경을 계획하고 배포하고 관리할 때 AI 에이전트가 참고할 수 있는 구조화된 스킬 파일을 제공한다는 점이다. 즉, 제로트러스트 도입이 점점 “제품 구매”가 아니라 “정책, 네트워크, 사용자 맥락을 코드와 워크플로우로 관리하는 일”에 가까워지고 있다.
이 글은 Cloudflare One을 무조건 추천하는 글이 아니다. VPN 대체, SASE 전환, 원격근무 보안, SaaS 접근 제어를 검토하는 실무자가 도입 전에 확인해야 할 비용·보안·운영 기준을 정리한 판단 문서다. 가격과 기능은 조직 규모, 계약 조건, Cloudflare 정책에 따라 달라질 수 있으므로 최종 결정 전에는 공식 문서와 견적을 다시 확인해야 한다.
- VPN 장애와 권한 예외가 반복되는 조직은 제로트러스트 전환 검토 가치가 높다.
- Cloudflare One은 Access, Gateway, Tunnel, DLP, CASB, Browser Isolation 같은 기능을 단일 제어면으로 묶는 방향이다.
- 비용은 사용자 라이선스만 보지 말고 기존 VPN 장비, 보안 장비, 운영 인력, 로그 저장, 예외 승인 시간을 함께 계산해야 한다.
- 마이그레이션은 한 번에 뒤집기보다 내부 앱 1~2개, 협력사 접근, 고위험 SaaS 순서로 작게 시작하는 편이 안전하다.
이 글이 필요한 사람
- VPN 장비 교체 시점이 왔지만 SASE나 ZTNA 전환이 맞는지 판단해야 하는 보안 담당자
- 원격근무, 협력사, 외주 개발자 접근 권한을 더 세밀하게 나누고 싶은 IT 운영팀
- Cloudflare One, Zscaler, Palo Alto Networks, 기존 VPN을 비교해야 하는 구매 담당자
- 사내 앱을 외부에 직접 노출하지 않고 접근시키는 구조를 검토하는 인프라 담당자
- AI 에이전트 기반 보안 운영 자동화가 실제 운영에 어떤 의미가 있는지 확인하려는 리더
Cloudflare One 제로트러스트 도입, 먼저 볼 결론
Cloudflare One 제로트러스트 도입은 “VPN을 Cloudflare로 바꾼다” 정도로 보면 실패하기 쉽다. VPN은 대개 네트워크 안으로 들어가는 문이다. 제로트러스트는 문을 통과한 뒤에도 요청마다 사용자, 단말 상태, 앱, 위치, 위험도를 계속 확인하는 방식이다. 그래서 전환 범위가 더 넓다.
Cloudflare 문서 기준 Cloudflare One은 SASE 플랫폼으로 설명된다. Access는 애플리케이션 접근을 제어하고, Secure Web Gateway는 DNS·HTTP·네트워크 트래픽 정책을 다루며, Cloudflare Tunnel은 내부 리소스를 공개 IP 없이 연결하는 구조를 제공한다. 여기에 DLP, Browser Isolation, CASB, Email security 같은 기능이 붙는다. 이 조합은 “어디서 접속했는가”보다 “누가, 어떤 단말로, 어떤 리소스에, 어떤 조건에서 접근하는가”를 보겠다는 설계다.
조건부 판단은 명확하다. 내부 앱이 많고 사용자 그룹이 복잡하며 협력사 접근이 잦다면 검토할 만하다. 반대로 직원 수가 적고 내부 앱이 거의 없으며 이미 간단한 SaaS만 쓰는 조직이라면 전체 SASE 전환보다 IAM, MFA, 백업, 로그 수집부터 정리하는 편이 낫다.
VPN 대체 전에 비교할 핵심 기준
| 판단 항목 | 기존 VPN 중심 | Cloudflare One/ZTNA 접근 | 검토 포인트 |
|---|---|---|---|
| 접근 단위 | 네트워크 접속 단위로 권한이 커지기 쉽다. | 앱·사용자·단말·정책 단위로 접근을 나눈다. | 내부 앱별 접근 권한을 분리할 필요가 있는지 본다. |
| 장비 운영 | VPN 게이트웨이, 방화벽, 인증 연동을 직접 운영한다. | Cloudflare 네트워크와 클라우드 제어면을 쓴다. | 기존 장비 감가상각, 유지보수, 장애 대응 시간을 비용에 넣는다. |
| 사용자 경험 | 전체 터널 접속, 속도 저하, 인증 실패가 발생할 수 있다. | 앱 단위 접근과 정책 기반 라우팅을 설계할 수 있다. | 현장 사용자 불만이 어느 구간에서 나오는지 로그로 확인한다. |
| 보안 정책 | 접속 후 내부 이동을 별도 제어해야 한다. | 최소 권한, 단말 상태, 위치, 위험 신호를 정책에 반영한다. | 권한 예외 승인 절차와 감사 로그가 준비돼 있는지 본다. |
| 마이그레이션 리스크 | 현재 구조를 유지하므로 변화는 작지만 누적 복잡도가 커진다. | 초기 설계가 틀리면 업무 중단이 생긴다. | 파일럿 앱, 롤백 경로, 예외 처리 담당자를 먼저 정한다. |
첫 번째 실무 시나리오를 보자. 200명 규모의 SaaS 회사가 사내 관리자 페이지, Git 저장소, 모니터링 대시보드, 고객 지원 도구를 VPN 뒤에 두고 있다. 퇴사자 권한 회수는 수동이고, 외주 개발자에게 임시 VPN 계정을 열어준다. 이 경우 제로트러스트 전환은 효과가 있다. 앱별 접근 정책을 분리하고, 외주 인력은 특정 앱과 기간에만 접근시키며, 모든 요청 로그를 남기는 구조가 가능하기 때문이다.
두 번째 시나리오는 다르다. 직원 15명 규모의 작은 조직이 Google Workspace, Slack, Notion, GitHub만 쓰고 내부 서버가 없다. 이 조직은 Cloudflare One 전체 도입보다 MFA 강제, 관리자 계정 분리, SaaS 감사 로그 확인, 계정 회수 프로세스부터 정리하는 편이 비용 대비 낫다. 제로트러스트라는 이름보다 현재 위험이 어디에 있는지 먼저 봐야 한다.
비용은 라이선스가 아니라 운영 전체로 계산해야 한다
제로트러스트 도입 비용을 사용자당 월 요금만으로 보면 판단이 틀어진다. Cloudflare 가격 페이지는 Zero Trust와 SASE 관련 플랜을 안내하지만, 실제 기업 비용은 플랜 표보다 넓다. 기존 VPN 유지보수, 방화벽 정책 관리, 장애 대응, 계정 발급·회수, 보안 로그 분석, 협력사 접근 승인에 들어가는 시간을 함께 계산해야 한다.
| 비용 항목 | 확인 질문 | 누가 확인할까 |
|---|---|---|
| 라이선스/계약 | 사용자 수, 기능 범위, 무료/유료/엔터프라이즈 조건이 맞는가? | 구매 담당자, 보안 리더 |
| 마이그레이션 | 앱 목록 작성, 정책 설계, 테스트, 사용자 교육 시간이 얼마나 드는가? | 보안팀, 인프라팀 |
| 기존 장비 | VPN 장비, 방화벽, 프록시, 보안 게이트웨이 유지비가 남는가? | 인프라팀, 재무팀 |
| 운영 인력 | 예외 승인, 로그 확인, 장애 대응 시간이 줄어드는가? | IT 운영팀 |
| 리스크 비용 | 권한 과다, 퇴사자 계정, 협력사 접근 사고 가능성을 줄일 수 있는가? | 보안팀, 법무/컴플라이언스 |
실무에서는 3개월 파일럿 비용표를 따로 만드는 편이 좋다. 예를 들어 내부 관리자 페이지 2개, Git 저장소, 모니터링 도구만 대상으로 잡고 사용자 30명에게 적용한다. 이때 라이선스 비용뿐 아니라 정책 작성 시간, 장애 건수, 접속 실패 건수, 권한 예외 요청 건수, VPN 접속 시간 감소를 기록한다. 이 데이터가 있어야 전체 전환 여부를 설득할 수 있다.
보안 정책은 “차단”보다 “예외 관리”에서 갈린다
제로트러스트 정책은 멋진 대시보드보다 예외 처리에서 실력이 드러난다. 모든 사용자를 강하게 막는 것은 쉽다. 어려운 것은 배포 당일 장애를 만들지 않으면서도 권한을 좁히는 일이다. CISA의 Zero Trust Maturity Model도 위치 중심 보안에서 데이터 중심, 세분화된 접근 제어로 이동하는 흐름을 강조한다. 결국 사용자의 요청마다 정확한 최소 권한 결정을 내릴 수 있어야 한다.
Cloudflare One을 검토할 때는 Access 정책, 단말 상태 규칙, Gateway 정책, Tunnel 구성, 로그 보존, 관리자 권한 분리를 한 묶음으로 봐야 한다. Access만 켜고 “제로트러스트 도입 완료”라고 말하면 안 된다. 사용자가 어떤 경로로 앱에 들어오고, 실패한 접속은 어디에 기록되며, 관리자 계정은 누가 승인하고, 예외는 언제 만료되는지까지 설계해야 한다.
- 먼저 확인할 것: 사내 앱 목록, 앱 소유자, 사용자 그룹, 외부 협력사 접근 필요 여부
- 정책 설계: 관리자, 개발자, 고객지원, 외주 인력, 임원 계정을 별도 그룹으로 분리
- 단말 기준: 회사 관리 단말, 개인 단말, 모바일 접속, OS 보안 상태를 어떻게 볼지 결정
- 로그 기준: 누가 어떤 앱에 실패했는지, 정책 변경 이력이 남는지 확인
- 예외 만료: 임시 접근은 기본 만료일을 둔다. 만료 없는 예외는 시간이 지나면 새 취약점이 된다.
AI 에이전트 기반 배포가 의미하는 것
Cloudflare One stack 발표에서 흥미로운 부분은 “agent-powered deployment”다. Cloudflare는 보안팀이 기존 네트워크 구조, 인증·인가 구성, 트래픽 흐름, 정책 의도를 해석해야 하는 부담을 언급한다. 그리고 Cloudflare One stack을 에이전트에게 제공해 Zero Trust 환경의 계획, 배포, 관리를 돕겠다고 설명한다.
이 지점은 과장해서 보면 위험하지만, 무시하기도 어렵다. 보안 정책은 코드와 문서 사이에 걸쳐 있다. 방화벽 룰, VPN ACL, IdP 그룹, 애플리케이션별 권한, 예외 승인 이력이 따로 놀면 사람도 전체 맥락을 잃는다. AI 에이전트가 이 구조를 보조한다는 말은 “자동으로 보안을 맡긴다”가 아니라 “정책 의도와 실제 설정을 더 빨리 대조한다”에 가깝게 봐야 한다.
조건부 추천은 이렇다. 이미 인프라를 코드로 관리하고, 변경 승인 프로세스와 로그 감사를 갖춘 팀이라면 에이전트 기반 보조가 생산성을 높일 수 있다. 반대로 현재 정책 문서도 없고, 누가 어떤 권한을 갖는지 엑셀로도 정리되지 않은 조직이라면 AI 에이전트보다 자산 목록과 권한 표부터 만들어야 한다. 정리되지 않은 구조에 자동화만 붙이면 잘못된 정책이 더 빠르게 퍼진다.
도입 순서: 한 번에 VPN을 끄지 말 것
Cloudflare One 제로트러스트 도입은 작은 범위로 시작해야 한다. 가장 나쁜 방식은 전 직원 VPN을 한 번에 대체하고, 장애가 나면 다시 예외를 열어주는 식이다. 이 방식은 보안팀 신뢰를 떨어뜨리고, 사용자에게 “제로트러스트는 업무 방해”라는 인상을 남긴다.
- 앱 목록 정리: 내부 앱, 관리자 페이지, 개발 도구, SaaS를 중요도와 사용자 그룹별로 나눈다.
- 파일럿 선정: 업무 영향은 있지만 치명 장애 가능성이 낮은 앱 1~2개를 고른다.
- IdP 연동 확인: Google Workspace, Azure AD, Okta 등 현재 신원 관리 체계와 그룹 동기화를 확인한다.
- Cloudflare Tunnel 또는 접근 경로 설계: 내부 앱을 공개 IP 없이 연결할지, 기존 라우팅을 유지할지 정한다.
- Access 정책 작성: 사용자 그룹, 단말 조건, 위치, MFA, 예외 만료를 정책에 넣는다.
- 로그 검증: 성공/실패 접속, 관리자 변경 이력, 정책 충돌을 확인한다.
- 사용자 안내: 접속 방법, 실패 시 문의 경로, 예외 신청 방식을 짧게 문서화한다.
- 확장 판단: 접속 실패율, 문의 건수, VPN 사용 감소, 정책 수정 건수를 보고 다음 앱으로 확장한다.
보류해야 하는 경우도 있다
제로트러스트가 항상 정답은 아니다. 다음 조건에 해당하면 구매보다 준비가 먼저다. 첫째, 사용자와 앱 목록이 정리되지 않았다. 둘째, 퇴사자 계정 회수 프로세스가 없다. 셋째, IdP 그룹이 실제 조직과 맞지 않는다. 넷째, 관리자 계정 공유가 남아 있다. 다섯째, 로그를 봐도 누가 무엇을 했는지 추적하기 어렵다. 이 상태에서 SASE 제품을 넣으면 대시보드만 늘고 책임 소재는 더 흐려진다.
또 하나는 비용 구조다. Cloudflare One을 포함한 SASE 제품은 기능을 많이 켤수록 운영 설계가 중요해진다. DLP, CASB, Browser Isolation, SWG를 모두 검토한다면 각 기능의 정책 책임자를 정해야 한다. 구매 담당자는 견적을 보고, 보안팀은 정책을 만들고, 운영팀은 장애를 받는다. 역할을 나누지 않으면 기능이 늘수록 조직 안에서 병목이 생긴다.
제로트러스트 파일럿 정책 스켈레톤
Cloudflare One 도입 글에는 제품 설명만 있으면 부족하다. 실제 팀에서는 “어떤 앱을 먼저 옮길지”, “누가 접근할지”, “예외는 언제 만료할지”를 파일로 합의해야 한다. 아래 예시는 Cloudflare API에 바로 넣는 코드가 아니라, 보안팀과 인프라팀이 파일럿 범위를 정리할 때 쓸 수 있는 정책 설계 스켈레톤이다. 실제 적용 전에는 Cloudflare 공식 문서의 최신 리소스명과 계약 기능 범위를 확인해야 한다.
# zero-trust-pilot.yaml
# 목적: 바로 적용하는 설정 파일이 아니라, 보안팀/인프라팀이 파일럿 범위를 합의하기 위한 정책 설계 스켈레톤이다.
organization:
name: example-company
identity_provider: google-workspace # google-workspace | azure-ad | okta 등
pilot_owner: security-team
rollback_owner: infra-team
pilot_scope:
duration_days: 30
users:
- group: engineering
access_reason: internal-admin-and-git
- group: external-contractors
access_reason: limited-project-access
expires_after_days: 14
applications:
- name: admin-console
type: internal-web-app
current_access: vpn
desired_access: app-level-zero-trust
risk: high
- name: git-service
type: developer-tool
current_access: vpn
desired_access: identity-and-device-policy
risk: medium
access_policy_baseline:
default: deny
allow_rules:
- app: admin-console
groups: [engineering-admins]
require_mfa: true
require_managed_device: true
session_duration_hours: 8
- app: git-service
groups: [engineering, external-contractors]
require_mfa: true
require_managed_device: false
contractor_expiry_required: true
deny_rules:
- condition: unmanaged-device-and-admin-app
- condition: expired-contractor-account
- condition: unknown-country-for-sensitive-app
logging_and_review:
collect:
- successful_logins
- denied_requests
- policy_changes
- temporary_exceptions
review_cycle: weekly
success_metrics:
- vpn_login_count_reduced
- access_denied_false_positive_rate
- exception_count_with_expiry
- incident_or_helpdesk_ticket_count
이 YAML의 목적은 멋진 자동화가 아니다. 파일럿 범위, 사용자 그룹, 앱 목록, 기본 차단 정책, 로그 검토 항목을 한 파일에 모아 두는 것이다. 이 정도가 정리되지 않으면 Cloudflare One이든 다른 SASE 제품이든 도입 뒤 예외가 폭증한다.
배포 전 정책 검사용 Python 스켈레톤
아래 코드는 실제 Cloudflare API를 호출하지 않는다. 대신 “파일럿 정책이 최소한의 보안 기준을 통과하는지”를 사전에 확인한다. 운영팀이 이런 검사를 CI에 붙여두면, MFA 없는 허용 규칙이나 만료 없는 외주 접근이 실수로 들어가는 상황을 줄일 수 있다.
#!/usr/bin/env python3
"""Zero Trust 파일럿 점검 스크립트 예시.
실제 Cloudflare API 호출 전, 우리 조직의 앱/그룹/예외 정책이 발행 가능한 상태인지 검사한다.
"""
from __future__ import annotations
import sys, yaml
from pathlib import Path
REQUIRED_APP_FIELDS = {"name", "type", "current_access", "desired_access", "risk"}
def fail(message: str) -> None:
print(f"[FAIL] {message}")
raise SystemExit(1)
def main(path: str) -> None:
data = yaml.safe_load(Path(path).read_text(encoding="utf-8"))
apps = data.get("pilot_scope", {}).get("applications", [])
if not apps:
fail("pilot_scope.applications가 비어 있습니다. 파일럿 앱 1개 이상을 정하세요.")
for app in apps:
missing = REQUIRED_APP_FIELDS - set(app)
if missing:
fail(f"{app.get('name', '<unknown>')} 누락 필드: {sorted(missing)}")
baseline = data.get("access_policy_baseline", {})
if baseline.get("default") != "deny":
fail("기본 정책은 default: deny로 시작하는 것이 안전합니다.")
for rule in baseline.get("allow_rules", []):
if rule.get("require_mfa") is not True:
fail(f"{rule.get('app')} allow rule에 MFA가 없습니다.")
if "contractor" in ",".join(rule.get("groups", [])) and not rule.get("contractor_expiry_required"):
fail(f"{rule.get('app')} 외주/협력사 접근에 만료 조건이 없습니다.")
print("[OK] 파일럿 정책 스켈레톤 검사를 통과했습니다. 이제 공식 Cloudflare 문서 기준으로 리소스명을 확인한 뒤 적용하세요.")
if __name__ == "__main__":
if len(sys.argv) != 2:
fail("usage: python check_zero_trust_pilot.py zero-trust-pilot.yaml")
main(sys.argv[1])
- 처음부터 API 자동 적용을 목표로 삼지 말고, 정책 스켈레톤 → 리뷰 → 파일럿 → 자동화 순서로 가는 편이 안전하다.
- Cloudflare One stack처럼 에이전트 기반 보조 도구를 쓰더라도 최종 승인 기준은 사람이 읽을 수 있는 정책 파일에 남겨야 한다.
- 코드에 비밀 토큰, 계정 ID, 실제 사용자 이메일을 넣지 말고 환경변수나 시크릿 저장소를 사용한다.
도입 전 체크리스트
| 체크 항목 | 통과 기준 | 미통과 시 조치 |
|---|---|---|
| 앱 자산 목록 | 내부 앱과 SaaS, 관리자 페이지가 소유자와 함께 정리돼 있다. | 앱 목록부터 만들고 파일럿 범위를 줄인다. |
| 사용자 그룹 | 부서, 역할, 외주, 협력사 그룹이 IdP에서 관리된다. | 공유 계정과 임시 계정을 정리한다. |
| 단말 상태 | 회사 관리 단말과 개인 단말 기준이 분리돼 있다. | MDM 또는 최소 보안 기준을 먼저 정한다. |
| 로그/감사 | 접속 성공·실패와 정책 변경 이력을 추적할 수 있다. | 로그 보존 기간과 확인 담당자를 정한다. |
| 롤백 계획 | 파일럿 실패 시 기존 VPN 경로로 돌아갈 수 있다. | 긴급 예외와 되돌림 절차를 문서화한다. |
함께 보면 좋은 글
자주 묻는 질문
Cloudflare One을 쓰면 VPN을 바로 없앨 수 있나요?
바로 없애기보다 내부 앱 1~2개를 파일럿으로 옮긴 뒤 판단해야 한다. 앱별 접근 정책, 단말 조건, 로그, 예외 처리까지 안정적으로 돌아가면 VPN 의존도를 줄이는 순서가 안전하다.
제로트러스트와 SASE는 같은 말인가요?
같은 말은 아니다. 제로트러스트는 최소 권한과 지속 검증을 중심으로 한 보안 모델이고, SASE는 네트워킹과 보안 기능을 클라우드 기반으로 통합하는 아키텍처에 가깝다. Cloudflare One은 SASE 플랫폼 안에서 제로트러스트 접근을 제공하는 방향으로 설명된다.
Cloudflare One 도입 비용은 어떻게 계산해야 하나요?
사용자당 라이선스만 보면 부족하다. 기존 VPN 장비 유지비, 방화벽 정책 운영 시간, 장애 대응, 로그 분석, 계정 발급·회수, 협력사 예외 승인에 들어가는 시간을 함께 계산해야 한다.
작은 회사도 제로트러스트를 도입해야 하나요?
내부 앱과 협력사 접근이 거의 없다면 전체 SASE 전환보다 MFA, 관리자 계정 분리, SaaS 감사 로그, 백업부터 정리하는 편이 낫다. 내부 리소스가 늘고 권한 예외가 잦아질 때 본격 검토해도 늦지 않다.
AI 에이전트 기반 배포는 보안팀을 대체하나요?
대체가 아니라 보조에 가깝다. 정책 의도와 설정을 대조하고 반복 작업을 줄이는 방향으로 보는 것이 맞다. 최종 승인, 예외 판단, 위험 수용은 여전히 보안 책임자의 몫이다.
출처와 확인일
- Cloudflare Blog — Introducing the Cloudflare One stack: agent-powered deployment (확인일: 2026-06-19)
- Cloudflare Docs — Cloudflare One documentation (확인일: 2026-06-19)
- Cloudflare Pricing — Zero Trust & SASE Plans & Pricing (확인일: 2026-06-19)
- CISA — Zero Trust Maturity Model Version 2.0 (확인일: 2026-06-19)
이 글은 보안 제품 구매나 법률 자문이 아니라 일반적인 IT 도입 판단 가이드다. Cloudflare One 기능, 가격, 패키징, API, 정책 화면은 변경될 수 있으므로 실제 도입 전에는 공식 문서와 계약 조건을 다시 확인해야 한다. 보안 아키텍처 변경은 조직의 위험 수용 기준, 규정 준수 요건, 개인정보 처리 구조에 맞춰 검토해야 한다.
댓글
댓글 쓰기