top of page

대응 격차: 공격자의 시계와 SOC의 시계는 왜 맞지 않는가

작성자 사진: PAGO Networks
PAGO Networks
11시간 전
4분 분량

대응 격차(Response Gap)는 공격자가 내부로 퍼지는 속도와 SOC가 첫 조치를 시작하는 속도 사이의 차이입니다. 이 차이를 이해하려면 먼저 두 개의 시계를 읽어야 합니다.


공격자가 시스템 하나에 처음 침투한 뒤 다른 시스템으로 옮겨 가기까지 걸리는 시간을 브레이크아웃 타임(Breakout Time)이라고 부릅니다. 이 시간 안에 공격을 막으면 피해는 단말 한 대에서 끝납니다. 이 시간을 넘기면 공격은 내부망 전체의 문제가 됩니다.


2025년 이 시간의 평균은 29분이었습니다. 가장 빨랐던 사례는 27초였습니다. 이 글에서는 2026년에 발표된 위협 보고서로 공격자의 시계를 읽고, 같은 방식으로 SOC의 시계를 읽어 봅니다. 그리고 두 시계 사이의 차이, 대응 격차가 왜 생기는지, 왜 사람을 더 뽑는 것만으로는 좁히기 어려운지 정리합니다.


1. 공격자의 시계: 29분, -7일, 22초

29분, 브레이크아웃 타임 CrowdStrike 2026 Global Threat Report에 따르면 eCrime 공격의 평균 브레이크아웃 타임은 2024년 48분에서 2025년 29분으로 줄었습니다. 1년 만에 65% 빨라진 셈입니다. 같은 기간 AI를 활용한 공격은 89% 늘었습니다.


-7일, 취약점 악용 시점 Mandiant M-Trends 2026은 취약점이 공개된 뒤 처음 악용되기까지 걸리는 평균 시간(Mean Time to Exploit)을 -7일로 추정했습니다. 숫자가 음수라는 건 패치가 나오기 일주일 전부터 이미 공격이 시작된다는 뜻입니다. 패치 주기에 맞춰 짜인 취약점 관리 계획은 출발선부터 뒤처져 있는 셈입니다.


22초, 접근 권한 인계 사이버 범죄 생태계는 분업화돼 있습니다. 초기 침투를 전문으로 하는 그룹이 접근 권한을 확보하면, 랜섬웨어 그룹 같은 다른 조직이 이를 넘겨받아 다음 단계를 진행합니다. 같은 보고서에서 이 인계에 걸리는 시간은 2022년 8시간 이상에서 22초로 줄었습니다. 사람끼리 협상하고 거래하던 단계가 자동화된 파이프라인으로 바뀌었다는 신호입니다.


두 개의 속도 흥미로운 점은 같은 보고서에서 평균 체류 시간(Dwell Time)은 오히려 11일에서 14일로 늘었다는 겁니다. 사이버 스파이 활동과 북한 IT 인력 위장 취업 사례만 보면 체류 시간 중앙값은 122일, 약 4개월입니다.


공격자의 시계는 두 가지로 갈라지고 있습니다. 돈을 노리는 공격은 몇십 분 안에 퍼지고, 정보를 노리는 공격은 몇 달 동안 조용히 머뭅니다. SOC는 두 시계에 모두 대응해야 합니다.


2. SOC의 시계: 경보에서 첫 조치까지

이제 방어 쪽 시계를 읽어 봅시다. 대부분의 SOC에서 경보 하나는 다음 순서를 거칩니다.

경보 발생 → 티켓 생성 → 분석가 배정 → 1차 분류 → 상세 분석 → 조치 승인 → 차단·격리


각 화살표 사이에는 대기 시간이 있습니다. 앞 단계의 사람이 확인하고 다음 사람에게 넘겨줄 때까지 경보는 대기열에 머뭅니다. 한 업계 설문에서는 경보가 발생한 뒤 누군가 처음 조치를 시작하기까지 평균 56분이 걸린다고 답했습니다. 경보량은 계속 늘고 있습니다.

2025년 한 조사에서 SOC 리더의 88%가 지난 1년간 경보량이 늘었다고 답했고, 76%가 경보 피로(Alert Fatigue)를 겪고 있다고 했습니다. 73%는 분석가 번아웃과 인력 부족을 호소했습니다.

3. 대응 격차 계산하기

두 시계를 나란히 놓으면 대응 격차를 숫자로 볼 수 있습니다.



업계 평균값을 넣으면 56분 − 29분 = 27분입니다. 첫 조치가 시작되기 전 27분 동안 공격자는 이미 내부를 이동하고 있다는 계산입니다.

이 격차는 시간대에 따라 더 벌어집니다. 평일 주간에 56분이 걸리는 조직이라면 야간과 주말에는 대기열을 처리할 인원이 줄어드니 그보다 길어질 가능성이 높습니다. 공격자에게는 업무 시간이 없습니다.


4. 사람을 더 뽑으면 대응 격차가 줄어들까

대응 격차 앞에서 가장 먼저 떠오르는 해법은 채용입니다. 인력을 늘리면 대기열이 짧아지고, 첫 조치 시간도 줄어들 테니까요. 하지만 세 가지 이유로 채용만으로 이 격차를 메우기는 어렵습니다.


① 필요한 사람을 구하기 어렵다 ISC2는 2025 Cybersecurity Workforce Study에서 처음으로 글로벌 보안 인력 부족 규모를 발표하지 않았습니다. 응답자들이 인원 수보다 역량 부족을 더 큰 문제로 꼽았기 때문입니다. 1만6천여 명의 응답자 중 59%가 팀에 심각한 역량 공백이 있다고 답했고, 2024년 44%에서 크게 올랐습니다. 88%는 역량 부족으로 중대한 보안 사고를 한 건 이상 겪었다고 답했습니다. 채용 공고를 늘려도 필요한 역량을 갖춘 사람이 그만큼 늘어나지는 않습니다.


② 인력은 비례해서 늘고, 공격은 그보다 빨리 늘어난다 분석가를 두 배로 늘리면 처리량은 최대 두 배가 됩니다. 실제로는 사람이 늘수록 인계 단계와 커뮤니케이션 비용도 함께 늘어나니 두 배에 못 미치는 경우가 많습니다. 반면 공격은 자동화를 통해 늘어납니다. 1년 만에 65% 빨라진 브레이크아웃 타임, 8시간에서 22초로 줄어든 인계 시간은 인력 증가 곡선과 다른 곡선 위에 있습니다.


③ 24시간은 생각보다 많은 사람을 필요로 한다 교대 근무, 휴가, 교육 시간을 고려하면 24시간 365일 자리 하나를 채우는 데 일반적으로 4~5명이 필요합니다. 야간과 주말까지 평일 주간과 같은 대응 시간을 유지하려면 인력 계획의 단위 자체가 달라집니다.


5. 대응 격차를 줄이는 네 가지 방향

채용은 여전히 필요합니다. 그와 함께 대응 격차의 구조를 직접 다루는 방법이 있습니다.


우리 조직의 시계부터 재기

업계 평균은 참고값일 뿐입니다. 지난 분기 경보 중 실제 위협으로 판정된 사례를 골라, 경보 발생부터 첫 조치까지 걸린 시간을 평일 주간, 야간, 주말로 나눠 측정해 보세요. 격차가 어느 시간대, 어느 단계에서 가장 크게 벌어지는지 보입니다.


대기 단계 줄이기

가장 큰 지연은 대부분 분석이 끝난 뒤 조치 승인을 기다리는 구간에서 생깁니다. 랜섬웨어 행위가 확인된 단말 격리처럼 판단 기준이 명확한 조치는 사전에 승인된 플레이북으로 만들어 두면 승인 대기 시간을 없앨 수 있습니다.


시간대 공백 메우기

자체 인력으로 24시간을 채우기 어렵다면 야간과 주말을 전문 보안 운영 파트너에게 맡기거나, 여러 시간대에 걸친 팀이 근무를 이어받는 구조를 검토할 수 있습니다.


반복 업무 자동화하기

위협 정보 조회, 관련 로그 수집, 상관분석처럼 매번 같은 방식으로 반복되는 작업은 자동화의 우선 대상입니다. 분석가가 이 작업에 쓰던 시간이 줄어들수록 첫 조치 시간도 짧아집니다.


6. 우리 조직의 대응 격차 점검 체크리스트

  • 지난 분기 실제 위협 사례에서 경보 발생부터 첫 조치까지 평균 몇 분이 걸렸는가?

  • 그 시간은 평일 주간, 야간, 주말에 각각 얼마인가?

  • 경보 하나가 첫 조치에 이르기까지 몇 명의 손을 거치는가?

  • 사전 승인 없이 즉시 실행할 수 있는 격리·차단 조치가 정해져 있는가?

  • 패치가 나오기 전에 악용되는 취약점에 대응하는 절차가 있는가?


공격자의 시계는 분과 초 단위로 움직이고, 많은 SOC의 시계는 여전히 대기열과 승인 단위로 움직입니다. 대응 격차를 줄이는 첫걸음은 우리 조직의 시계를 정확히 재는 일입니다. 숫자가 보이면 어느 단계에 무엇을 바꿔야 할지도 보입니다.


파고네트웍스는 24시간 보안 운영과 사고 대응을 제공합니다. 우리 조직의 대응 시간을 함께 측정해 보고 싶다면 문의해 주세요.


참고 자료

  • CrowdStrike, 2026 Global Threat Report (2026.02)

  • Mandiant (Google Cloud), M-Trends 2026 (2026.03)

  • ISC2, 2025 Cybersecurity Workforce Study (2025.12)

  • Prophet Security, The State of AI in the SOC 2025 (The Hacker News 보도, 2025.09)

  • 2025 Pulse of the AI SOC Report (IT Brief 보도, 2025)

bottom of page