AI 보안 도구 도입 전 반드시 확인할 5가지 체크포인트

벤더가 낸 벤치마크 자료 한 장이 팀 채팅방에 공유되면, 검토는 대개 그 자료의 결론부터 시작된다. 이 글은 특정 제품이 더 나은지를 가리는 대신, 그런 자료를 받았을 때 도입을 판단하기 전에 무엇을 확인해야 하는지를 순서대로 정리한다. 23년간 조직에서 도구 선정을 해오며 반복해서 확인한 것은, 벤더 자료가 틀렸다기보다 측정 조건이 우리 환경과 달랐다는 쪽이었다.

MS 발표 요약: 무엇을 ‘더 낫다’고 주장했나

지난주 마이크로소프트가^[1] Security Copilot 관련 벤치마크 자료를 냈다. 요지는 두 가지였다. 위협 탐지 속도가 경쟁 플랫폼보다 빠르고^[2], 총 운영 비용은 더 낮다는 것.

이런 자료가 팀 채팅방에 공유되면 반응은 대체로 비슷하다. “이것도 도입 검토해야 하지 않냐”는 반응이 나오고, 벤더 슬라이드 캡처가 뒤따른다. 탐지 시간이 평균 몇 분 단축됐다는 막대그래프와 “경쟁사 대비 비용 효율 우수”라는 문구가 나란히 자리한 이번 자료도 마찬가지였다. 그런데 그 그래프 밑에는 측정 데이터셋 이름도, 위협 시나리오 종류도, 테스트 환경 스펙도 적혀 있지 않았다. 23년간 이런 자료를 수없이 봤는데, 패턴은 늘 비슷하다. 결론 문장은 크고 굵게 박아 넣고, 측정 조건은 각주보다 작게 쓰거나 아예 빼버린다.

벤더 자체 벤치마크를 곧이곧대로 믿으면 안 되는 이유 – 실제 PoC 실패 사례

벤더 벤치마크는 검증 자료가 아니라 마케팅 자료로 봐야 한다. 이게 원칙이다. 근거는 내가 직접 겪은 실패 사례에서 나온다.

엔드포인트 탐지 솔루션을 도입할 때 벤더가 제시한 오탐률 수치만 믿고 계약을 진행했다가 곤란해진 적이 있다. 데모 환경에서 낮게 나온 오탐률이 실제 운영 데이터를 넣자 눈에 띄게 치솟았다. 이유는 간단했다. 벤더 데모는 정제된 샘플 로그로 테스트한 것이었고, 우리 조직의 실제 트래픽에는 레거시 시스템에서 나오는 비정형 로그가 상당한 비중을 차지하고 있었다. “성능이 좋다”와 “우리 환경에서 성능이 좋다”는 완전히 다른 명제다.

그때 회의에서 나온 질문은 결국 하나였다 — 발표 자료에 있던 숫자는 도대체 어떤 근거였느냐는 것. 답은 간단했다. 그 숫자가 우리 상황을 대변한 적은 애초에 없었다.

AI 보안 도구 도입 전 반드시 확인하는 5가지 체크포인트

도입 전 체크리스트는 문서화되어 있어야 한다. 그래야 의사결정 책임 소재가 명확해진다. 내가 지금 프로젝트마다 쓰는 체크포인트는 다음과 같다.

– 독립 벤치마크 존재 여부: MITRE ATT&CK 평가나 SE Labs, AV-Comparatives 같은 제3자 기관 테스트 결과가 있는가

– 자체 PoC 설계: 벤더 데모 환경이 아니라 우리 조직의 실데이터, 실사용 시나리오로 테스트했는가

– 기존 스택과의 통합 비용: Splunk, Sentinel, CrowdStrike 등 기존 SIEM/EDR과 API 연동에 걸리는 실제 공수는 얼마인가

– 데이터 거버넌스·규정 준수: 로그가 해외 리전으로 전송되는지, 개인정보 마스킹이 자동화되는지

– 벤더 락인 리스크: 계약 종료 시 데이터 반출이 몇 시간 안에 가능한지, 대체 도구로 전환하는 데 필요한 기간은 얼마인지

이 다섯 개를 표로 정리해서 담당자 서명을 받아두면 나중에 “누가 이 도구를 골랐냐”는 질문에 답이 명확해진다. 형식적 절차가 아니다. 실패했을 때 원인을 추적할 수 있는 유일한 안전장치다.

비용 절감 주장 뒤에 숨은 TCO 함정 – 라이선스 외 도입 비용

비용 절감 주장은 대부분 라이선스 비용만 비교한 것이다. 실제 TCO는 그보다 훨씬 크다. Security Copilot과 경쟁 플랫폼을 비교한 자료를 다시 보면, 비교 축이 “월 구독료”로 고정돼 있었다.

비슷한 도구를 도입했던 사례들을 보면 사정이 다르다. 초기 라이선스 비용은 전체 예산의 일부에 지나지 않았고, 나머지 대부분은 마이그레이션 인력, 기존 룰셋 재작성, 운영팀 교육, 그리고 이후 도구를 바꾸기로 결정하면서 발생한 이탈 비용이 차지하는 경우가 많다. 특히 이탈 비용은 계약서에 잘 안 보인다. 데이터 익스포트 포맷이 표준이 아니면 다른 도구로 옮기는 데 몇 주씩 걸리기도 한다.

그래서 나는 이제 비교표를 만들 때 “라이선스 비용” 한 줄로 끝내지 않는다. 통합 비용, 운영 인력 비용, 전환 비용, 교육 비용을 각각 항목으로 나눠서 계산한다. 이렇게 하면 초기에는 비싸 보였던 도구가 3년 총비용에서는 오히려 저렴한 경우도 나온다.

우리 조직이라면 이 도구를 어떻게 파일럿할 것인가

파일럿은 벤더가 제안한 성공 지표가 아니라 우리가 정의한 지표로 평가해야 의미가 있다. 지금 검토 중인 방식은 이렇다.

먼저 4주짜리 PoC 기간을 잡는다. 벤더 데모 데이터가 아니라 최근 3개월치 실제 보안 로그를 넣는다. 평가 지표는 벤더가 제시한 “탐지 속도”가 아니라 우리가 정한 세 가지, 즉 오탐률, 실제 인시던트 대응 시간 단축폭, 기존 인력 재교육에 걸리는 시간으로 잡는다.

Security Copilot은 마이크로소프트 생태계, 즉 Defender나 Sentinel을 이미 쓰고 있는 조직이라면 통합 공수가 적어서 유리하다. 반대로 CrowdStrike나 Darktrace를 쓰던 조직이 굳이 이걸로 갈아탄다면, 통합 비용이 오히려 더 들 수도 있다. 이 판단은 벤더 슬라이드로는 절대 나오지 않는다.

4주 뒤 리포트에 숫자가 나오면 그때 다시 결정하면 된다. 지금 다시 이 프로젝트를 시작한다면, 나는 계약서에 서명하기 전에 이 파일럿부터 먼저 돌릴 것이다. 발표 자료를 본 첫날 계약 여부를 결정하는 건, 언제나 너무 이른 일이었다.