[보안] 제로 트러스트 도입 1년 후기: 비용과 효과 분석

중소기업에서 제로 트러스트 도입 이야기가 나오면 보통 두 반응으로 갈립니다. “그거 대기업 하는 거 아닌가요?” 아니면 “도입 비용이 더 무서운데요?” 같은 반응이죠. 저도 처음엔 딱 그랬습니다. 13년째 인프라 일을 하면서 방화벽(Firewall, 네트워크 접근 제어 장비) 하나 잘 세우고 VPN(Virtual Private Network, 가상사설망) 잘 운영하면 어느 정도 버틴다고 생각했었거든요. 근데 재택, SaaS, 클라우드, 외부 협업이 늘어나니까 기존 방식이 자꾸 틈을 보이더라고요.

그래서 지난 1년 동안 중소 규모 조직 기준으로 제로 트러스트 아키텍처를 실제 운영에 맞게 다듬어 봤습니다. 오늘 글은 이론 소개보다, 무엇을 줄였고 무엇을 늘렸는지, 그리고 정말 보안 비용 절감이 됐는지에 초점을 맞춘 후기입니다. 화려한 성공담만 하면 재미없죠. 삽질도 꽤 했습니다 ㅎㅎ

사내 사용자, SaaS, 내부 웹 애플리케이션, ID 제공자, 정책 엔진이 어떻게 연결되는지 한눈에 보여주는 개요 다이어그램입니다.

왜 중소기업 보안에서 제로 트러스트 도입이 중요해졌나

쉽게 말해 예전엔 “사내망 안이면 일단 믿는다”가 기본 전제였습니다. 그런데 지금은 그 전제가 자꾸 깨집니다. 노트북은 집과 카페를 오가고, 업무 시스템은 퍼블릭 클라우드(Public Cloud, 외부 클라우드 서비스)와 온프레미스(On-premise, 사내 구축 환경)에 섞여 있고, 협력사는 내부 시스템 일부에 접속해야 하거든요.

여기서 문제는 경계 기반 보안(Perimeter Security, 외곽선 중심 보안)이 생각보다 빨리 낡는다는 점입니다. 한 번 내부로 들어오면 횡적 이동(Lateral Movement, 내부 시스템 간 확산)이 쉬워지고, 계정 하나만 털려도 피해 범위가 커집니다. 저희도 예전에 VPN 계정 관리가 느슨했던 시기가 있었는데, 그때 로그를 다시 보니 식은땀이 나더라고요. 실제 사고가 나진 않았지만, “이건 운이 좋았네” 싶은 순간이 있었습니다.

• 접속 위치보다 사용자와 기기 상태를 더 봐야 합니다.
• 한 번 인증했다고 계속 믿으면 안 됩니다.
• 업무 시스템마다 최소 권한(Least Privilege, 최소 권한 원칙)을 다시 설계해야 합니다.

중소기업 보안은 인력도 예산도 넉넉하지 않은 경우가 많습니다. 그래서 더더욱 “관리 포인트를 줄이면서 사고 가능성을 낮추는 구조”가 중요합니다. 제가 1년 운영해 보니, 제로 트러스트 도입은 비싼 제품 이름이 아니라 운영 원칙을 바꾸는 일에 더 가깝습니다.

제로 트러스트 아키텍처, 쉽게 말해 뭐냐면

설명은 거창하지만 핵심은 단순합니다. 아무도 자동으로 신뢰하지 않고, 매 요청마다 확인한다는 겁니다. 사용자(User), 기기(Device), 위치(Location), 애플리케이션(Application), 세션(Session) 상태를 보고 접근을 허용하거나 막는 구조죠.

저는 처음에 “이거 결국 MFA(Multi-Factor Authentication, 다중 인증)만 붙이면 끝 아닌가?” 싶었는데, 실제로 해보면 훨씬 넓습니다. 인증은 시작일 뿐이고, 그 다음이 더 중요합니다.

여기서 중요한 포인트! 제로 트러스트 도입은 한 번에 끝내는 프로젝트가 아니었습니다. 저희는 아래 순서로 갔습니다.

1. ID 제공자(IdP, Identity Provider)와 SSO(Single Sign-On, 통합 로그인) 정리
2. MFA 적용 대상 확대
3. 내부 웹 서비스 앞단에 접근 프록시(Access Proxy, 인증 연동 게이트) 배치
4. 관리자 권한 분리 및 승인 흐름 정리
5. 로그 수집과 예외 정책 축소

이 과정을 거치면서 클라우드 보안도 같이 좋아졌습니다. 왜냐면 접근 기준이 네트워크가 아니라 ID와 정책으로 이동하니까, 클라우드 쪽 자원도 동일한 철학으로 묶이더라고요.

제가 실제로 진행한 제로 트러스트 도입 단계

이제 실전 이야기로 가보겠습니다. 중소기업 환경에서는 멋진 레퍼런스 아키텍처보다 “지금 있는 계정 체계와 시스템을 얼마나 덜 흔들고 바꿀 수 있느냐”가 더 중요했습니다. 그래서 저는 큰 틀에서 4단계로 나눴습니다.

1. 사용자와 계정부터 정리했습니다

처음엔 네트워크 장비부터 만지고 싶었는데, 실제로는 계정이 먼저였습니다. 퇴사자 계정, 공용 계정, 용도 불명 서비스 계정이 남아 있으면 제로 트러스트고 뭐고 출발이 안 되더라고요.

# 최근 90일 미사용 계정 점검 예시
lastlog | awk 'NR>1 {print $1, $4, $5, $6, $7, $8}'

# 로컬 관리자 그룹 확인 예시
getent group sudo
getent group wheel

# 서비스 계정 쉘 접근 여부 점검
cat /etc/passwd | grep -E '(/bin/bash|/bin/sh)'

실제로 써보니까 여기서 이미 많은 게 보였습니다. “왜 이 계정이 아직 살아 있지?” 싶은 항목이 생각보다 많았거든요. 이 단계에서 쓸데없는 예외를 줄여야 뒤에 정책이 단순해집니다.

2. 애플리케이션 단위로 접근을 재정의했습니다

VPN으로 네트워크 전체를 열어주던 방식을 줄이고, 업무 시스템별로 접근 경로를 분리했습니다. 예를 들어 Git, Wiki, ERP, 모니터링, 관리자 페이지를 전부 같은 수준으로 열지 않았습니다.

applications:
  - name: monitoring
    exposure: internal
    auth:
      sso: required
      mfa: required
    authorization:
      groups:
        - sre
        - infra
  - name: wiki
    exposure: internal
    auth:
      sso: required
      mfa: optional
    authorization:
      groups:
        - all-employees
  - name: admin-console
    exposure: restricted
    auth:
      sso: required
      mfa: required
      device_posture: managed-only
    authorization:
      groups:
        - infra-admin

위 예시는 특정 제품 문법이라기보다 제가 정책 문서를 정리할 때 썼던 형태에 가깝습니다. 핵심은 네트워크가 아니라 앱 기준으로 접근을 나눈다는 점입니다.

SSO, MFA, 그룹 기반 권한, 기기 상태 조건이 실제 접근 흐름에 어떻게 반영되는지 설명하는 구성 다이어그램입니다.

3. 리버스 프록시와 인증 연동을 붙였습니다

내부 웹 서비스는 리버스 프록시(Reverse Proxy, 역방향 프록시) 앞단에서 인증을 강제하는 구조가 운영이 편했습니다. 서비스마다 로그인 기능을 다시 개발할 필요가 없었거든요.

server {
    listen 443 ssl;
    server_name internal.example.com;

    location / {
        auth_request /auth;
        proxy_set_header X-User $upstream_http_x_user;
        proxy_set_header X-Email $upstream_http_x_email;
        proxy_pass http://internal_app;
    }

    location = /auth {
        internal;
        proxy_pass http://auth_gateway/verify;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header X-Original-URI $request_uri;
    }
}

이 구조를 쓰면 기존 레거시 웹 서비스도 비교적 손쉽게 묶을 수 있습니다. 저도 처음엔 애플리케이션을 하나씩 손대야 하나 싶었는데, 프록시 계층에서 많이 해결됐습니다. 드디어 됐다! 싶었던 구간이 여기였네요.

4. 로그와 예외 정책을 계속 줄였습니다

도입보다 더 힘든 건 운영입니다. 예외가 쌓이면 구조가 다시 무너집니다. 그래서 접속 로그, 실패한 인증, 관리자 권한 사용 이력을 계속 봤습니다.

# 인증 실패 로그 확인 예시
journalctl -u auth-gateway --since "7 days ago" | grep -i failed

# 관리자 권한 사용 추적 예시
grep "sudo" /var/log/auth.log | tail -n 50

# 프록시 접근 로그에서 국가/시간대 이상 패턴 확인 예시
grep "admin-console" /var/log/nginx/access.log | tail -n 100

여기서 중요한 건 로그를 많이 모으는 게 아니라, 누가 봐도 의미 있는 지표로 줄이는 것입니다. 실패 로그인 횟수, 신규 디바이스 접근, 고위험 애플리케이션 접근, 예외 정책 사용량 정도만 정리해도 운영 감각이 확 달라집니다.

비용은 어떻게 바뀌었나: 생각보다 라이선스보다 운영비가 컸습니다

이 글 제목에 비용이 들어가 있으니 솔직히 말씀드려야죠. 1년 운영해 보니 저희 쪽에서는 제품 구매비보다 초기 설계와 운영 정리 비용이 더 크게 느껴졌습니다. 다시 말해, 단순히 도구 하나 사는 걸로 끝나는 일이 아니었습니다.

다만 그렇다고 무조건 비용이 늘기만 하진 않았습니다. 오히려 아래 항목은 줄었습니다.

• VPN 계정 발급/회수 처리 시간
• 외부 협력사 접근 예외 요청 건수
• 공용 계정 관리에 들어가던 숨은 운영 시간
• 감사 대응 시 접근 이력 정리 시간

반대로 늘어난 것도 있습니다.

• 초기 정책 설계 시간
• SSO 연동 테스트 시간
• 예외 케이스 조정 회의
• 사용자 교육과 안내 문서 작성

제가 직접 해보니 보안 비용 절감은 “당장 라이선스가 줄었다”보다 “운영 복잡도가 낮아졌다”에서 체감됐습니다. 특히 사람 손으로 처리하던 예외 요청이 줄어든 게 꽤 컸습니다. 중소기업 보안은 결국 사람 시간 싸움이거든요.

⚠️ 실제로 겪은 문제와 트러블슈팅

좋은 얘기만 하면 재미없죠. 실제로 꽤 부딪혔습니다.

문제 1. MFA 예외를 너무 쉽게 줬습니다

초기에는 “일단 업무 막히면 안 되니까”라는 생각으로 예외를 많이 열어줬습니다. 근데 한 달쯤 지나니까 예외가 정책이 되더라고요. 이건 진짜 위험했습니다.

해결: 예외에 만료일을 붙이고, 연장 시 사유를 다시 받았습니다. 예외가 영구 설정이 되는 걸 막아야 합니다.

문제 2. 레거시 시스템이 헤더 기반 인증을 잘 못 받았습니다

일부 오래된 내부 시스템은 프록시가 넘겨주는 사용자 헤더를 제대로 처리하지 못했습니다. 저도 처음엔 이게 뭔가 싶었는데, 알고 보니 애플리케이션 쪽에서 신뢰 프록시 설정이 빠져 있더라고요.

해결: 프록시와 애플리케이션 사이 구간을 제한하고, 신뢰 가능한 프록시 목록을 명확히 설정했습니다.

문제 3. 기기 상태(Device Posture, 단말 보안 상태) 조건이 과했습니다

관리 대상 기기만 허용하는 정책은 방향은 맞는데, 초기에 너무 넓게 걸면 현업 반발이 큽니다. 특히 외부 파트너나 임시 장비 접근이 문제였습니다.

해결: 고위험 애플리케이션부터 우선 적용하고, 일반 시스템은 단계적으로 확대했습니다. 결국 순서가 중요하더라고요.

문제 4. 장애 때 우회 경로가 없었습니다

인증 게이트가 장애 나면 여러 시스템이 동시에 막힙니다. 이건 제로 트러스트 구조에서 꼭 고려해야 할 지점입니다.

# 간단한 상태 점검 예시
curl -I https://internal.example.com
curl -I https://auth.example.com/health

# 인증 게이트 프로세스 확인 예시
systemctl status auth-gateway
systemctl status nginx

해결: 인증 계층 이중화, 점검 페이지 분리, 비상 관리자 접근 절차를 문서화했습니다. 비상 계정은 더 강하게 통제해야 하고, 사용 즉시 감사 로그를 남기도록 했습니다.

검증 결과: 무엇이 좋아졌고, 무엇은 여전히 숙제인가

1년 정도 지나고 나서 가장 체감된 건 “누가 어디에 왜 접근했는지” 설명이 쉬워졌다는 점입니다. 이전에는 네트워크 열어준 뒤 각자 접속하는 구조라 추적이 흐릿했는데, 지금은 사용자와 애플리케이션 기준으로 보이니까 판단이 빨라졌습니다.

• ✅ 계정 회수와 권한 변경이 빨라졌습니다.
• ✅ 관리자 페이지 접근이 훨씬 명확해졌습니다.
• ✅ 외부 협력사 접근을 앱 단위로 통제하기 쉬워졌습니다.
• ✅ 클라우드 보안 정책과 사내 정책을 같은 기준으로 맞추기 쉬워졌습니다.

특히 감사 대응이나 보안 점검 때 효과가 확실했습니다. “이 시스템은 왜 이 사람이 접근 가능한가요?”라는 질문에 답하는 시간이 줄었거든요. 예전엔 담당자마다 말이 달랐는데, 지금은 그룹과 정책 기준으로 설명이 됩니다.

접근 정책 정리, 예외 감소, 인증 실패 추적, 관리자 접근 가시성 향상 같은 운영 성과를 보여주는 대시보드 이미지입니다.

물론 숙제도 남아 있습니다.

• 기기 신뢰 수준을 더 정교하게 나눌 필요가 있습니다.
• 서비스 계정과 API 토큰 관리도 같은 철학으로 묶어야 합니다.
• 모든 SaaS가 동일한 SSO 정책을 잘 지원하는 건 아니었습니다.

그래서 저는 다음 글에서 서비스 계정과 머신 아이덴티티(Machine Identity, 시스템 간 인증 주체) 쪽을 따로 다뤄볼 생각입니다. 이 부분이 빠지면 제로 트러스트 도입이 반쪽짜리가 되기 쉽거든요. 이전 글에서 다뤘던 계정 정리 원칙과 함께 보시면 더 이해가 쉬우실 겁니다.

정리: 중소기업 제로 트러스트 도입, 이렇게 시작하면 덜 아픕니다

한 줄로 요약하면 이렇습니다. 제로 트러스트 도입은 보안 장비 교체 프로젝트가 아니라 운영 모델 전환입니다. 저도 처음엔 제품 비교부터 했었는데, 실제로는 계정, 권한, 예외, 로그를 다시 설계하는 쪽이 훨씬 중요했습니다.

1. 가장 먼저 계정과 그룹을 정리하세요.
2. VPN 전체 개방보다 애플리케이션 단위 접근부터 나누세요.
3. MFA는 예외를 엄격히 관리해야 효과가 납니다.
4. 고위험 시스템부터 기기 상태 조건을 붙이세요.
5. 운영 로그는 적어도 의미 있는 지표로 보이게 만드세요.

혹시 이런 경험 있으신가요? 보안을 강화하려고 했는데 오히려 예외 정책만 잔뜩 늘어나서 운영이 더 복잡해지는 경우요. 저도 딱 그 구간을 지나왔습니다. 그래서 더더욱 말씀드리고 싶습니다. 처음부터 완벽하게 하려 하지 말고, 작게 시작해서 예외를 줄이는 방향으로 가는 게 맞습니다.

도입 전과 도입 후의 운영 방식, 접근 통제, 예외 관리, 비용 체감을 한 장으로 비교하는 요약 인포그래픽입니다.

자주 묻는 질문

중소기업도 제로 트러스트 아키텍처가 꼭 필요할까요?

모든 조직이 같은 수준으로 할 필요는 없습니다. 다만 원격 근무, SaaS, 외부 협업이 많다면 최소한 SSO, MFA, 앱 단위 접근 통제는 꼭 검토해볼 만합니다.

VPN을 완전히 없애야 하나요?

반드시 그렇진 않습니다. 저희도 일부 운영 구간은 아직 VPN을 씁니다. 다만 네트워크 전체를 여는 기본값을 줄이고, 가능하면 애플리케이션 단위 접근으로 옮기는 방향이 더 안전했습니다.

비용이 많이 드나요?

도구 비용보다 운영 정리 비용이 먼저 듭니다. 하지만 계정 회수, 예외 관리, 감사 대응 시간이 줄면 장기적으로는 충분히 의미가 있습니다. 특히 중소기업 보안에서는 인력 시간을 아끼는 효과가 큽니다.

오늘 내용이 도움이 되셨다면, 다음 글에서 다룰 서비스 계정 최소 권한 설계 편도 이어서 보셔도 좋겠습니다. 제로 트러스트 도입은 결국 사람과 시스템이 서로를 어떻게 검증할지 정하는 일입니다. 해보면 생각보다 기술보다 운영이 더 중요합니다. 근데 그 운영이 정리되기 시작하면, 이거 진짜 편하더라고요. 🎉