AI 침해 사고는 처음에는 장애처럼 보인다: 이제 온콜 엔지니어가 보안 사고의 최초 대응자가 되는 이유

최종 업데이트: 2026년 7월 14일

‍

핵심 요약

AI 기반 침해 사고 대응은 점점 보안팀이 아니라 온콜 엔지니어에게서 시작되고 있습니다. AI를 활용한 공격은 과거 몇 주가 걸리던 침입 과정을 몇 시간으로 단축하며, 가장 먼저 관측되는 신호도 CPU 급증, 지연 시간 증가, 설정 드리프트, 원인을 알 수 없는 파이프라인 실행과 같은 운영 문제로 나타납니다.

이러한 신호는 인프라 온콜 담당자에게 알럿을 보냅니다. 그 결과 해당 엔지니어는 보안 관련 맥락이나 보안 런북, 명확한 에스컬레이션 경로가 없는 상태에서 사실상 최초의 보안 대응자가 됩니다. 이제 이 경계 지점을 바로잡는 일도 인시던트 대비의 일부가 되어야 합니다.

‍

‍

개요

• 이번 주 공개된 두 건의 공격 보고서가 보여준 사실
• 기계 속도로 진행되는 침해 사고가 인프라 알럿으로 먼저 나타나는 이유
• 사람의 속도로 진행되는 침입과 기계 속도로 진행되는 침입의 차이
• 최초 페이징 담당자 문제
• “장애”가 실제로는 침해 사고임을 보여주는 신호
• 장애가 공격처럼 보일 때 하지 말아야 할 것
• AI 기반 침해 사고 대응에 대비해 온콜 로테이션을 준비하는 다섯 가지 방법
• 자주 묻는 질문

‍

두 개의 보고서, 하나의 패턴

2026년 7월 14일, CSO Online은 최근 두 가지 사건에 대한 분석을 발표했습니다. 이 사건들은 엔지니어링 팀이 사고 대응을 바라보는 방식을 완전히 재정립해야 함을 시사합니다.

보안 기업 Sygnia가 조사한 첫 번째 사건은 AI 기반 클라우드 침해 사례로, 공격자는 애플리케이션 서비스, AWS 리소스, 소스 코드 저장소, CI/CD 워크플로, 런타임 구성 요소, 데이터 저장소 전반의 취약점을 연쇄적으로 악용했습니다. 자격 증명 수집, 클라우드 환경 탐색, 파이프라인 악용, 데이터베이스 접근이 Sygnia가 “압축된 시간대”라고 표현한 짧은 시간 안에 이루어졌습니다. 포렌식 흔적은 AI 기반 자동화가 새로 접근한 시스템에 맞춰 공격 방식을 조정했다는 점을 보여주었습니다. 침입 경로는 제로데이 취약점이 아니었습니다. 공격에는 AI 에이전트를 구축하는 도구인 Langflow에서 1년 전에 발견된 취약점인 CVE-2025-3248이 사용되었습니다. 아이러니하게도 AI 도구 자체를 노리는 공격도 증가하고 있습니다. 모델을 겨냥한 공격은 모델 추출과 모델 역전 공격을 다룬 글에서 자세히 설명합니다.

두 사고에서 공격자가 접근한 시스템을 살펴보세요. 애플리케이션 서비스, AWS 인스턴스, CI/CD 러너, 데이터베이스, 런타임 구성 요소가 포함됩니다. 이 영역은 보안 운영 센터만의 관할이 아닙니다. SRE와 플랫폼 팀이 소유하고 모니터링하며, 문제가 발생했을 때 페이징을 받는 시스템입니다.

‍

AI 기반 침해 사고 대응이 온콜에서 시작되는 이유

전통적인 인시던트 대응은 역할이 분리되어 있다는 전제를 바탕으로 합니다. 보안 도구가 공격자를 탐지하고, 보안 운영 센터가 조사하며, 해결 과정이 프로덕션 환경에 영향을 줄 때 인프라 팀이 참여하는 방식입니다. 이 모델은 공격자가 활동 범위를 본격적으로 확장하기 전에 방어팀이 조사하고 차단할 수 있을 만큼 충분한 관측 신호가 발생한다는 가정 위에 만들어졌습니다. Sygnia 연구진에 따르면 새로운 공격은 바로 이 가정을 무너뜨립니다. 사람이 수행하는 공격은 탐지를 피하기 위해 수주 동안 조심스럽게 움직입니다. AI 에이전트는 굳이 조심스럽게 움직이지 않습니다. 보안팀의 탐지 검토 주기보다 더 빠르게 공격을 진행합니다. 인프라 내부에서 빠르고 요란하게 진행되는 활동은 가장 먼저 운영상의 증상으로 나타납니다. 리소스 사용량 증가, 지연 시간 증가, 설정 드리프트, 서비스 장애 등이 발생합니다. 이러한 증상은 관측성 스택을 통해 전달되고, 일반적인 안정성 문제와 동일한 임계값을 넘으면서 온콜 엔지니어에게 알럿을 보냅니다. SLO 기반 알럿 가이드에서는 이러한 임계값이 어떻게 작동하는지 설명합니다. 결국 온콜 엔지니어는 평범한 장애처럼 보이는 문제를 조사하기 시작합니다.

사람이 수행하는 침입은 보안팀이 대응할 수 있는 수주간의 체류 시간을 제공하고 보안 도구를 통해 드러나는 경우가 많았습니다. 반면 AI 기반 침입은 몇 시간 안에 진행되며, 온콜 엔지니어에게 전달되는 인프라 알럿과 서비스 장애로 먼저 나타납니다.

Bonfy.ai의 CEO인 Gidi Cohen은 CSO와의 인터뷰에서 어려움을 겪게 될 조직은 “AI 기반 방어 체계가 없는 조직이 아니라, 기계 속도로 움직이는 위협 환경에서 여전히 사람의 속도로 보안에 대응하는 조직”이라고 말했습니다.

‍

최초 페이징 담당자 문제

최초 페이징 담당자 문제: 인시던트에 가장 먼저 대응하는 사람이 인시던트의 실제 성격이 아니라 알럿 라우팅에 의해 결정되는 현상을 말합니다. 침해 사고가 인프라 문제를 일으키면 페이저는 SRE를 호출하고, 누군가 다른 문제임을 알아차릴 때까지 해당 인시던트는 장애로 조사됩니다.

최초 페이징 담당자 문제는 단순한 도구의 한계가 아닙니다. 조직 구조 사이의 경계에서 발생하는 문제입니다.

SRE는 관리자 권한과 시스템에 대한 깊은 이해를 갖추고 있으며, 서비스를 신속하게 복구해야 할 책임도 있습니다. 하지만 보안 사고에서 가장 중요한 요소는 부족한 경우가 많습니다.

증거를 보존해야 한다는 판단, 침해된 시스템을 “수정”하는 행위가 공격자에게 탐지 사실을 알리거나 포렌식 증거를 파괴할 수 있다는 인식, 그리고 보안팀에 대응을 넘기는 연습된 절차가 없는 경우가 많습니다.

그사이 상황은 더 나쁜 방향으로 움직이고 있습니다. Huntress의 Dray Agha는 CSO 기사에서 이를 분명하게 표현했습니다.

“랜섬웨어 공격을 실행하는 데 필요한 최소 역량이 이제 에이전트를 실행하는 비용 수준으로 낮아졌습니다.”

패치되지 않은 수많은 인프라를 노리는 공격자가 더 많아지고, 공격 빈도도 증가하고 있습니다. 새벽 2시에 받는 페이징 중 실제로는 처음 보이는 것과 전혀 다른 문제가 더 많아질 수 있다는 뜻입니다.

‍

"장애"가 사실은 침해 사고라는 신호

온콜 엔지니어는 다음과 같은 신호가 함께 나타날 때 이를 단순한 이상 현상이 아니라 보안 에스컬레이션의 계기로 판단해야 합니다.

• 성능 저하와 자격 증명 관련 활동이 동시에 발생하는 경우: 지연 시간이나 CPU 사용량 이상이 비정상적인 IAM 이벤트, 새로운 액세스 키, 예상하지 못한 주체의 로그인과 동시에 발생하는 상황입니다.

• 배포하지 않았는데 설정이 변경된 경우: "새로운 역할, 변경된 보안 그룹, 익숙하지 않은 예약 작업, 변경 기록과 일치하지 않는 런타임 설정 변경 등이 포함됩니다.

• 아무도 실행하지 않은 파이프라인 작업: 특히 시크릿이나 배포 대상을 다루는 CI/CD 작업이 평소 패턴을 벗어나 실행되는 경우입니다. 최근 두 공격 모두 배포 워크플로를 악용했습니다.

• 데이터 저장소의 외부 전송량 급증: 데이터베이스나 오브젝트 스토리지에서 애플리케이션의 정상적인 동작으로는 설명하기 어려운 규모의 데이터가 갑자기 외부로 전송되는 경우입니다.

• 해결 후 다시 발생하는 문제: 문제를 해결했지만 다시 발생하는 경우입니다. 공개된 두 공격 모두 복구 작업 후에도 접근 권한을 유지할 수 있도록 여러 위치에 지속성 메커니즘을 심었습니다.
  각 신호는 개별적으로는 정상적인 원인으로 발생할 수 있습니다. 하지만 장애처럼 보이는 상황에서 두 가지 이상의 신호가 함께 나타난다면 보안 사고로 에스컬레이션해야 합니다.

‍

장애가 공격처럼 보일 때 하지 말아야 할 것

• 먼저 복구하고 나중에 질문하지 마십시오. 인스턴스를 재구축하거나 배포를 롤백하면 침입을 이해하는 데 필요한 포렌식 증거가 파괴될 수 있습니다. 또한 다른 위치에 남아 있는 공격자의 접근 경로까지 제거하는 것은 아닙니다.

• 보안팀이 이미 알고 있을 것이라고 가정하지 마십시오. 온콜 담당자에게 알럿을 보낸 신호가 보안 운영 센터의 도구에는 전혀 감지되지 않았을 수 있습니다. 보안팀이 알고 있을 것이라고 추측하지 말고 명시적으로 알려야 합니다.

• 복구를 차단으로 착각하지 마십시오. Sygnia가 조사한 공격자들은 복구 시도를 무력화하기 위해 여러 위치에 지속성 메커니즘을 구축했습니다. 서비스가 복구되었더라도 공격자가 시스템 내부에 남아 있다면 인시던트가 해결된 것이 아닙니다.

• 오탐을 피하려고 혼자 조사하지 마십시오. 불필요하게 보안팀을 호출했을 때 드는 비용은 담당자 몇 분의 시간입니다. 보안팀을 호출하지 않았을 때의 비용은 유출된 데이터의 규모로 계산될 수 있습니다.

‍

AI 기반 침해 사고 대응에 대비해 온콜 로테이션을 준비하는 다섯 가지 방법

1. 인시던트 런북에 보안 대응 분기를 추가하십시오

주요 운영 런북에는 “침해 사고처럼 보이는 경우”를 위한 짧은 분기가 포함되어야 합니다. 확인해야 할 구체적인 신호, 호출해야 할 사람, 즉시 중단해야 할 행동을 명시하십시오. 문서 한 페이지 정도면 충분하며, 새벽 2시에 온콜 엔지니어가 혼자 판단해야 하는 상황을 줄일 수 있습니다.

2. 실제 상황이 발생하기 전에 SRE에서 보안팀으로 이어지는 인계 절차를 정의하십시오

공동 심각도 기준, 공유 채널, 장애와 침해 사고가 동시에 발생했을 때 누가 인시던트를 지휘할지를 미리 합의하십시오. 인시던트 커맨더 모델을 적용할 수 있습니다. 핵심은 인계가 즉흥적으로 이루어지는 것이 아니라 미리 연습된 단계여야 한다는 점입니다.

3. 복구 단계에 증거 보존 절차를 포함하십시오

재구축하기 전에 스냅샷을 생성하십시오. 재시작하기 전에 실행 중인 프로세스, 연결 상태, 최근 로그와 같은 휘발성 정보를 수집하십시오. 압박이 큰 상황에서도 기본적으로 수행될 수 있도록 이러한 단계를 표준 롤백 절차에 포함해야 합니다.

4. 가짜 장애로 시작하는 테이블탑 훈련을 실시하십시오

대부분의 보안 테이블탑 훈련은 “침해 사고가 탐지되었습니다”라는 상황에서 시작합니다. 대신 지연 시간 알럿으로 훈련을 시작하고, 대응하는 엔지니어가 침해 가능성을 고려하기까지 얼마나 걸리는지 확인하십시오. 그 시간 차이가 조직의 실제 탐지 시간입니다. 또한 훈련 포스트모템에 포함해야 할 항목입니다. AI 지원 포스트모템 가이드에서는 추가적인 반복 작업 없이 해당 내용을 기록하는 방법을 설명합니다.

5. 서로 연관된 알럿 유형은 두 팀 모두에게 라우팅하십시오

앞에서 설명한 신호의 조합, 예를 들어 인프라 이상과 IAM 활동, 파이프라인 실행과 시크릿 접근이 함께 나타나는 경우에는 보안팀과 온콜 담당자 모두에게 동시에 알럿을 보내야 합니다. AI 지원 트리아지는 공격이 계속 진행되는 동안 온콜 엔지니어가 수동으로 수집해야 할 여러 시스템의 맥락을 미리 정리할 수 있습니다. AI 인시던트 관리에 관한 글에서는 이러한 조사 레이어가 어떻게 작동하는지 설명합니다.

‍

자주 묻는 질문

AI 기반 침해 사고 대응이란 무엇인가요?

AI 기반 침해 사고 대응은 AI 에이전트가 수행하거나 가속하는 공격에 맞춰 인시던트 대응 방식을 조정하는 것을 의미합니다. 이러한 공격은 과거 수주가 걸리던 침입 과정을 몇 시간으로 단축합니다. 따라서 기계 속도에 맞춘 차단, 온콜 엔지니어와 보안팀 간의 신속한 에스컬레이션, 운영 문제로 먼저 나타나는 공격에 대한 사전 준비를 중요하게 다룹니다.

AI 침해 사고는 왜 처음에 장애처럼 보이나요?

AI 기반 공격은 인프라 내부에서 빠르고 요란하게 진행되기 때문에 가장 먼저 관측되는 영향이 리소스 사용량 급증, 지연 시간 증가, 설정 드리프트, 서비스 장애와 같은 운영 문제로 나타납니다. 이러한 신호는 보안 도구가 침입을 탐지하기 전에 관측성 도구를 통해 온콜 엔지니어에게 전달됩니다.

SRE가 보안 사고를 책임져야 하나요?

아닙니다. 하지만 현장에 가장 먼저 도착할 가능성에는 대비해야 합니다. 현실적인 목표는 SRE를 보안 분석가로 만드는 것이 아닙니다. “장애”가 실제로 침해 사고로 확인될 때 이를 알아볼 수 있는 신호, 에스컬레이션 경로, 증거 보존 습관을 제공해 보안팀에 빠르고 정확하게 인계할 수 있도록 하는 것입니다.

AI 기반 공격은 얼마나 빠르게 진행되나요?

최근 공개된 사례에서는 여러 단계로 이루어진 침입이 몇 시간 안에 진행되었습니다. Sygnia가 2026년 7월 공개한 조사에서는 AI 지원 워크플로가 압축된 시간 안에 여러 클라우드 시스템에서 자격 증명 수집, 권한 분석, 공격 경로 파악을 수행했습니다. Sysdig의 JadePuffer 사례에서는 자율 에이전트가 사람의 개입 없이 전체 침입 및 금품 요구 공격을 실행했습니다.

‍

‍

용어집: AI 기반 침해 사고 대응의 주요 용어

• 온콜 엔지니어: 정해진 로테이션 기간 동안 프로덕션 알럿에 대응하도록 지정된 엔지니어입니다. 일반적으로 장애가 발생했을 때 서비스를 복구하는 책임을 맡습니다.
• SRE (사이트 신뢰성 엔지니어): 프로덕션 시스템의 안정성, 성능, 운영 가능성에 중점을 두는 엔지니어입니다. 일반적으로 인프라의 모니터링, 알럿, 인시던트 대응을 담당합니다.
• SOC (보안 관제 센터): 보안 도구를 모니터링하고, 의심스러운 침입을 조사하며, 확인된 보안 사고 대응을 조율하는 팀 또는 조직 기능입니다.
• 체류 시간 (Dwell time): 공격자가 최초로 침입한 시점부터 탐지되기까지의 기간입니다. 과거 인간이 주도한 침입은 평균 수주에서 수개월이 걸렸으나, AI 기반 공격은 이 체류 시간을 수 시간으로 단축합니다.
• 측면 이동 (Lateral movement): 공격자가 처음 침해한 시스템에서 환경 내 다른 시스템으로 접근 범위를 확장하는 과정입니다. 일반적으로 자격 증명을 수집하고 내부 취약점을 악용하는 방식으로 이루어집니다.

• 지속성 (Persistence): 공격자가 탐지되거나 복구 작업이 진행된 이후에도 접근 권한을 유지하기 위해 설치하는 메커니즘입니다. 새로운 액세스 키, 추가된 역할, 예약 작업 등이 포함됩니다. 지속성 메커니즘이 존재하기 때문에 서비스를 복구했다고 해서 침해 사고가 차단된 것은 아닙니다.

• 자격 증명 수집: 침해된 시스템에 저장된 비밀번호, API 키, 토큰을 자동으로 수집하는 행위입니다. 수집된 자격 증명은 다른 시스템에 추가로 접근하는 데 사용됩니다.
• IAM (계정 및 권한 관리): 클라우드 환경에서 사용자 신원, 역할, 권한을 제어하는 계층입니다. 장애처럼 보이는 상황에서 비정상적인 IAM 활동이 나타난다면 침해 사고를 의심해야 하는 핵심 신호입니다.

• 설정 드리프트: 시스템의 실제 설정과 의도된 버전 관리 상태 사이에 차이가 발생한 상황입니다. 일치하는 변경 기록 없이 설정 드리프트가 발생했다면 공격자가 설정을 변경했을 가능성이 있습니다.
• CI/CD 파이프라인: 코드를 빌드하고 테스트하고 배포하는 자동화된 워크플로입니다. 파이프라인은 시크릿과 배포 권한을 보유하므로, 설명할 수 없는 파이프라인 실행은 중요한 공격 신호입니다.

• 이그레스(Egress): 조직의 환경 밖으로 나가는 데이터를 의미합니다. 인시던트 중 데이터베이스나 오브젝트 스토리지의 이그레스가 갑자기 증가한다면 운영 장애가 아니라 데이터 유출을 의심해야 합니다.

• 제로데이: 벤더와 방어팀에 알려지지 않아 아직 패치가 제공되지 않은 취약점입니다. 이 글에서 다룬 공격에는 제로데이가 필요하지 않았습니다. 이미 알려졌지만 패치되지 않은 취약점이 악용되었습니다.
• 인시던트 커맨더: 인시던트 대응을 총괄하고, 에스컬레이션 결정을 내리며, 대응 인력이 같은 방향으로 움직이도록 조율하는 단일 책임자입니다. 직접 조사 작업을 수행하기보다는 전체 대응을 관리합니다.
• 테이블탑 훈련: 실제 프로덕션 시스템에 영향을 주지 않고 가상의 인시던트를 단계적으로 검토하며 프로세스와 인계 절차를 테스트하는 구조화된 훈련입니다.

이 용어집은 이 글에서 사용된 보안 및 운영 관련 용어를 설명합니다. 장애로 위장한 침해 사고를 식별할 때 특히 유용한 네 가지 신호는 비정상적인 IAM 활동, 설정 드리프트, 지속성, 이그레스 급증입니다.