[전자신문] 24시간 관제의 역설: 왜 아무도 대응하지 못했는가
2025년 일련의 해킹 사건은
우리에게 불편한 공통점을 남겼다.
피해를 입은 곳들은 모두
24시간 보안 관제를 운영하던 조직이었다.
보안 인력도 있었고,
관제 체계도 있었다.
그럼에도 불구하고
침해는 제때 발견되지 못했고,
실질적인 대응으로 이어지지 못했다.
이 사실은 하나의 질문을 남긴다.
24시간 관제가 있는데도 왜 아무도 막지 못했는가
관제는 존재하지만, 작동하지 않는다
많은 조직이 “관제를 운영한다”고 말한다.
- SIEM이 있다
- EDR이 있다
- 관제 인력이 있다
- 24시간 대응 체계가 있다
하지만 실제 사고에서는
다른 결과가 나타난다.
- 경보는 있었지만 해석되지 않는다
- 이상 징후는 있었지만 연결되지 않는다
- 이벤트는 있었지만 흐름으로 보이지 않는다
즉,
관제는 존재하지만, 작동하지 않는다
왜 이런 일이 반복되는가
문제는 단순한 실수가 아니다.
구조적인 문제다.
1. 제품 중심 구조
현실의 보안 환경은 다음과 같다.
- 방화벽
- WAF
- EDR
- SIEM
- VPN
- NAC
각 제품은 강력하다.
하지만 서로 연결되어 있지 않다.
관제 담당자는
각각의 화면을 따로 보고,
각각의 경보를 따로 해석해야 한다.
이 구조에서는
공격을 “흐름”으로 이해하기 어렵다.
2. 과도한 경보 (Alert Fatigue)
현장에서 가장 많이 듣는 말은 이것이다.
“경보가 너무 많아서 중요한 것을 놓친다”
- 하루 수천 건 이상 발생
- 대부분 false positive
- 우선순위 판단 어려움
결과적으로
- 중요한 공격은 묻힌다
- 대응은 지연된다
- 관제 인력은 소진된다
3. 로그 부족 (가장 본질적인 문제)
가장 중요한 문제는 이것이다.
로그가 충분하지 않다
- CommandLine 없음
- 웹 Request Body 없음
- 계정 흐름 추적 불가
- 데이터 유출 확인 불가
이 상태에서는
관제를 아무리 해도 의미가 없다.
왜냐하면
보이는 것만 대응할 수 있기 때문이다
24시간 관제의 진짜 의미
많은 조직이 오해하는 부분이 있다.
24시간 관제 = 24시간 대응 가능
하지만 현실은 다르다.
| 항목 | 의미 |
|---|---|
| 관제 존재 | 사람이 있다 |
| 대응 가능 | 이해할 수 있다 |
즉,
이해할 수 없으면 대응할 수 없다
2025년 사건이 보여준 구조
실제 공격은 다음과 같은 흐름으로 진행된다.
공격 흐름 예시
- 크리덴셜 스터핑 또는 계정 탈취로 정상 로그인
- 내부 시스템 접근 및 권한 범위 확인
- LOLBAS 도구나 정상 관리 도구를 이용한 후속 행위 수행
- 중요 데이터 조회 및 대량 다운로드
- 외부 전송 또는 유출 흔적 최소화
이 과정에서
- 모든 행위는 정상처럼 보인다
- 개별 이벤트로는 이상이 없다
- 웹 로그만 보면 로그인 이후 행위가 평범해 보일 수 있다
- OS 로그만 보면 정상 프로세스 실행처럼 보일 수 있다
하지만 전체를 보면
명확한 공격이다.
문제는 이것이다.
이 흐름을 한 번에 볼 수 있는가
제품 중심 관제와 통합 플랫폼 관제는 다르다
블로그 관점에서 더 분명히 구분할 필요가 있다.
| 구분 | 제품 중심 관제 | 통합 플랫폼 관제 |
|---|---|---|
| 화면 | 제품별로 분리 | 하나의 흐름으로 통합 |
| 분석 단위 | 개별 이벤트 | 공격 시나리오 |
| 웹/OS 연계 | 어려움 | 상관 분석 가능 |
| 경보 처리 | 수동 분류 중심 | 우선순위 기반 대응 |
| 결과 | 경보는 많지만 이해는 부족 | 이해 가능한 대응 구조 |
결국 중요한 것은
경보의 개수가 아니라
공격 흐름을 설명할 수 있는가다.
왜 관제 인력은 버티지 못하는가
보안 관제 인력은 다음을 동시에 수행해야 한다.
- 수십 개 제품 이해
- 수천 개 경보 처리
- 실시간 대응
- 사고 분석
- 보고 및 문서화
이 구조는 지속 가능하지 않다.
결과는 명확하다.
- 번아웃
- 이탈
- 경험 단절
그리고 다시 반복된다.
관제 인력의 헌신만으로
이 문제를 막을 수 있다고 기대하는 것은 한계가 있다.
구조가 바뀌지 않으면, 사람은 계속 소진된다.
해결은 명확하다: 구조를 바꿔야 한다
더 많은 장비로는 해결되지 않는다.
더 많은 인력으로도 해결되지 않는다.
필요한 것은 구조 변화다.
1. 정확한 로그
관제의 출발점은 로그다.
반드시 필요한 것:
운영체제
- Process + CommandLine
- 계정 / 권한 흐름
- 네트워크 연결
웹
- Request / Response Body
- 인증 흐름
- 데이터 조회 / 다운로드
로그가 남지 않으면
이상 징후는 보여도 공격을 설명할 수 없다.
그리고 설명할 수 없는 관제는 결국 대응으로 이어지지 못한다.
2. 통합 플랫폼
개별 제품이 아니라
하나의 흐름으로 보는 구조
- 이벤트 통합
- 상관 분석
- 공격 시나리오 재구성
예를 들어 웹의 Request/Response Body와
운영체제의 Process/CommandLine 로그를 함께 봐야
“정상 로그인 이후 어떤 도구가 실행되었고, 무엇이 조회·다운로드되었는가”를
하나의 공격 흐름으로 이해할 수 있다.
PLURA-XDR이 의미를 갖는 지점도 여기에 있다.
웹과 OS의 로그를 분리해서 보는 것이 아니라,
하나의 타임라인과 행위 흐름으로 연결해 분석할 수 있어야
관제는 비로소 ‘이벤트 확인’이 아니라 ‘침해 이해’가 된다.
3. AI 기반 운영 지원
AI는 선택이 아니라 필수다.
- 이상 징후 탐지
- 경보 우선순위 자동화
- 설정 오류 탐지
- 공격 패턴 학습
관제 현장에서는 경보가 없는 것이 문제가 아니라,
너무 많아서 중요한 것을 놓치는 것이 더 큰 문제다.
그래서 AI는 단순히 “더 많이 탐지하는 기능”이 아니라,
무엇이 지금 가장 위험한지 우선순위를 정하고
공격 흐름을 먼저 보여 주는 운영 지원 역할을 해야 한다.
즉,
사람이 판단해야 할 것을 줄여야 한다
지금 당장 점검해야 할 3가지
1. 우리는 공격 흐름을 한 화면에서 볼 수 있는가
→ 단일 이벤트가 아니라 연결 분석
2. 로그만으로 유출 여부를 설명할 수 있는가
→ 사고 후 대응 가능 여부
3. 관제 인력이 “이해”할 수 있는 구조인가
→ 단순 모니터링이 아닌 분석 가능 여부
맺음말
2025년의 사건은 우리에게 분명한 사실을 보여주었다.
우리는 24시간 관제를 운영하고 있었지만,
실제로는 대응할 수 있는 구조를 갖추지 못했다.
그래서 결과는 하나다.
24시간 관제였지만, 아무도 대응하지 못했다
이제 방향은 명확하다.
- 로그를 남기고
- 흐름을 통합하고
- AI로 지원하는 구조
이 세 가지가 갖춰질 때
비로소 관제는 “존재”가 아니라
“대응 능력”이 된다.
그리고 구조를 바꾸는 첫걸음은
경보를 더 쌓는 것이 아니라,
공격을 이해할 수 있게 기록하고 연결하는 것이다.
함께 읽기
📰 원문 뉴스
이 글은 아래 네이버 뉴스 기고문을 바탕으로
PLURA-Blog 형식에 맞게 확장·재구성한 내용입니다.
- 전자신문 : 2026-04-10 지면 및 온라인판
- https://www.etnews.com/20260409000110