모의해킹 비용을 매년 내는데, 왜 불안은 그대로인가

이 글은 Pentera 의 「Why Pay a Pentester? The Shift to Automated Penetration Testing」(2024-10-08, Aviv Cohen) 을 바탕으로 Hawoo Lab 이 국내 맥락을 더해 작성하였다. 원문 링크는 맨 아래에 있다.

---

연 1회 점검이 만든 착시

국내 금융회사와 전자금융업자는 전자금융기반시설에 대해 연 1회 이상 취약점 분석·평가를 받아야 한다. 홈페이지 모의해킹이 그 안에 들어간다. 규제가 요구하는 최소선이고, 대부분의 조직이 딱 그 최소선을 지킨다.

문제는 규제가 정한 주기와 환경이 바뀌는 주기가 다르다는 점이다.

Pentera 가 2025년 CISO·보안임원 500명을 조사한 「State of Pentesting 2025」에 따르면, 응답 기업의 96%가 분기 단위 이상으로 IT 환경을 변경하지만 같은 주기로 모의해킹을 하는 곳은 30%에 그쳤다. 70%는 많아야 연 2회이다.

즉 대부분의 조직은 이런 상태다.

1월    모의해킹 통과. 보고서 수령
2~12월 서버 증설 · 클라우드 이전 · 협력사 연동 · 계정 수백 개 변동
       → 이 기간 동안 무엇이 뚫리는지 아무도 모른다

보고서는 1월의 사진이고, 공격자는 8월에 온다.

비용 구조와 점검 주기

왜 더 자주 안 하는가. 하기 싫어서가 아니라 단가 때문이다.

Pentera 는 원문에서 수동 모의해킹 비용을 이렇게 제시한다 — 기본적인 외부 웹 테스트가 약 3만 달러, 복잡한 클라우드 환경 분석은 15만 달러까지. 착수부터 최종 보고서까지 2~3개월이 걸리고, 한 주기에 실제로 테스트되는 자산은 전체의 5~10% 수준이라고 한다.

국내 사정도 크게 다르지 않는다. 규모 있는 금융권 프로젝트는 수천만 원대에서 시작하고, 일정은 분기를 초과한다. 이 구조에서 「자주 하자」는 말은 예산 승인 요청과 동의어다.

같은 조사에서 확인된 저해 요인도 그 구조를 그대로 보여준다.

확대를 막는 것	응답
모의해킹 인력 가용성	48%
예산	44% (2024년 24% → 급등)
비즈니스 연속성 리스크 우려	28%
내부 조치 자원 부족	26%

예산 항목이 1년 만에 24%에서 44%로 뛴 것이 눈에 띈다. 보안 예산이 늘지 않는데 검증 요구는 늘어난 해였다.

도구 증가와 검증의 정체

같은 보고서에서 미국 기업이 운용하는 보안 솔루션은 평균 75개, 62%는 75개를 넘는다. 도구가 늘면 주간 알럿도 같이 는다 — 101개 이상 운용하는 조직은 주당 약 3,074건이다.

여기서 반직관적인 수치가 하나 도출된다.

도구를 늘리면 나아지긴 한다. 다만 93 → 61이다. 도구를 두 배로 늘려도 3분의 1이 넘는 조직은 여전히 뚫린다. 그리고 그 조직들은 이미 주당 3천 건의 알럿을 처리하고 있다.

도구를 더 사는 것으로는 이 곡선을 끝까지 내릴 수 없다는 뜻이다. 남은 질문은 하나다 — 지금 깔아둔 것들이 실제 공격에 버티는가.

자동화의 대체 범위와 한계

Pentera 의 주장은 명확하다. 수동 모의해킹 한 번 값이면 연중 상시로, 열 배 넓은 범위를 자동으로 테스트할 수 있다는 것이다.

다만 오해하면 안 되는 지점이 있다. Pentera 자신이 자사 문서에서 범위를 이렇게 획정한다 — 자동 레드팀은 레드팀을 대체하려는 것이 아니라 적대적 테스트에 대한 접근성을 넓히려는 것이라고요.

정리하면 이렇게 분기한다.

	자동화가 잘하는 것	사람이 계속 필요한 것
범위	전사 상시 검증	특정 목표 심층 공격
빈도	변경이 생길 때마다	연 1~2회 집중
성격	반복 가능·재현 가능	창의적 우회·물리 결합
산출	실증된 공격 경로와 조치	시나리오 기반 서사

둘은 대체재가 아니라 층위가 다르다. 자동화가 바닥을 상시로 깔고, 사람이 그 위에서 깊게 파는 구조다.

국내 적용 관점

여기부터는 원문에 없는, 국내 환경에 대한 Hawoo Lab 의 정리이다.

1. 규제 대응과 실질 보안을 분리해서 보아야 한다.

전자금융기반시설 취약점 분석·평가는 연 1회 이상이 요구선이다. 이건 지켜야 하는 하한이지 충분조건이 아니다. 규제 대응용 점검과 상시 검증을 같은 예산 항목에서 다투게 만들면 둘 다 부실해진다. 하한은 규제로, 상시는 운영으로 분리해 세우는 편이 승인받기 쉽다.

2. 「운영 중인 시스템에 실제 공격을 돌린다」는 반드시 걸린다.

국내에서 이 방식 도입 시 첫 번째 반대는 예산이 아니라 가용성이다. 검토할 때 다음을 벤더에게 문서로 요구해야 한다.

• 어떤 안전장치가 있는가 (속도 제한, 영향 한계 설정, 긴급 중지, 읽기 전용 모드)
• 전 감사 로그가 남는가
• 운영 시간 중 테스트 사례가 있는가 — PoC 로 직접 확인

3. 조직 구조를 먼저 보아야 한다.

상시 검증은 「발견」을 증가시킨다. 조치할 손이 없으면 백로그만 쌓이고 그건 감사 지적 사항이 된다. 도입 전에 조치 소유자와 SLA 를 먼저 정하는 것이 순서이다. 위 조사에서 「내부 조치 자원 부족」이 26%로 잡힌 이유가 이것이다.

4. 기존 솔루션과의 관계를 정리해야 한다.

취약점 스캐너·EDR·BAS 를 이미 쓰고 있다면, 자동화 검증은 그것들을 대체하는 게 아니라 그것들이 실제로 작동하는지 검사하는 층이다. 이 정의를 먼저 합의하지 않으면 내부에서 「중복 투자」로 정리된다.

---

출처 · Pentera, Why Pay a Pentester? The Shift to Automated Penetration Testing (2024-10-08, Aviv Cohen (CMO, Pentera))