2026년 5월 현재, AI 클라우드 플랫폼은 비용을 최적화하고, 장애를 자가 치유하며, 접근 권한을 스스로 조정한다. 이 시리즈에서 내가 줄곧 추적해온 흐름이다. 그런데 이번에 다룰 영역은 조금 더 예민하다. 바로 보안 위협 탐지와 대응(Threat Detection & Response)이다. AI 클라우드 인프라 안에서, 이제 "이것이 공격인가 아닌가"를 판단하는 주체가 인간 보안 분석가에서 AI 시스템으로 넘어가고 있다. 그리고 그 판단의 근거가 어디에도 남지 않는다는 것이 문제다.

---

보안 분석가가 사라지는 게 아니라, 그의 판단이 사라진다

전통적인 보안 운영 센터(SOC)를 떠올려보자. 경보가 울리면 분석가가 로그를 뒤지고, 패턴을 해석하고, "이건 공격이다" 혹은 "이건 오탐이다"라는 판단을 내린다. 그 판단은 티켓에 기록되고, 승인 체계를 거치며, 사후 감사에서 "누가, 언제, 왜 이 결정을 내렸는가"를 추적할 수 있다.

AWS GuardDuty, Microsoft Defender for Cloud, Google Security Command Center 같은 AI 기반 위협 탐지 도구들은 이 흐름을 근본적으로 바꾸고 있다. 이 도구들은 수백만 건의 이벤트를 실시간으로 분석하고, 위협 등급을 자동으로 분류하며, 일부는 격리(quarantine), 차단(block), 심지어 계정 비활성화까지 자동으로 실행한다.

문제는 속도나 정확도가 아니다. "이 위협을 이렇게 처리하라"는 결정을 누가 승인했는가라는 질문에 아무도 답하지 못한다는 것이다.

---

AI 클라우드 위협 탐지의 실제 작동 방식

현재 주요 클라우드 벤더들이 제공하는 AI 기반 보안 자동화는 크게 세 단계로 작동한다.

1단계: 탐지(Detection)

머신러닝 모델이 정상 트래픽 패턴을 학습하고, 이상 징후를 실시간으로 식별한다. 여기까지는 "알람"이다. 인간이 개입할 여지가 있다.

2단계: 분류(Classification)

AI가 탐지된 이상 징후를 "크리티컬/하이/미디엄/로우"로 자동 분류한다. 이 분류는 대응 방식을 결정한다. 문제는 이 분류 기준이 블랙박스에 가깝다는 점이다. NIST의 AI 위험 관리 프레임워크(AI RMF)는 AI 시스템의 결정에 대한 설명 가능성(explainability)을 핵심 원칙으로 제시하고 있지만, 현장에서 이 원칙이 실제로 구현된 경우는 드물다.

3단계: 대응(Response)

여기서 거버넌스 공백이 가장 극명하게 드러난다. SOAR(Security Orchestration, Automation and Response) 플랫폼과 연동된 AI 시스템은 위협 등급에 따라 자동으로 대응 플레이북을 실행한다. 특정 IP를 차단하고, 의심스러운 사용자 계정을 잠그고, 감염된 것으로 판단된 인스턴스를 네트워크에서 격리한다.

이 모든 과정이 수 밀리초 안에 일어난다. 인간이 개입할 시간이 없다. 그리고 그 결정의 근거는 로그 파일 어딘가에 묻혀버린다.

---

"오탐(False Positive)"이 자동 실행되면 무슨 일이 벌어지는가

2025년 초, 미국의 한 핀테크 기업에서 실제로 발생한 사례가 보안 커뮤니티에서 회자되었다. AI 기반 위협 탐지 시스템이 정상적인 배치 처리 작업을 비정상적인 데이터 유출 시도로 오분류했고, 자동 대응 플레이북이 실행되어 핵심 데이터베이스 접근 계정이 비활성화되었다. 결과는 약 4시간의 서비스 중단이었다.

더 심각한 문제는 사후 대응이었다. 감사팀이 "누가 이 계정을 비활성화했는가"를 추적하려 했을 때, 시스템 로그에는 "자동화 정책 실행"이라는 항목만 남아 있었다. 어떤 AI 모델이, 어떤 특징값을 근거로, 어떤 임계치를 초과했기 때문에 이 결정을 내렸는지를 사후에 재현하는 것이 사실상 불가능했다.

이것은 단순한 기술적 버그가 아니다. 감사 가능성(auditability)의 구조적 소멸이다.

---

AI 클라우드 보안 자동화가 만드는 세 가지 거버넌스 공백

공백 1: 결정 근거의 불투명성

AI가 "이것은 위협이다"라고 판단할 때, 그 판단을 뒷받침하는 특징(feature)과 가중치는 대부분 외부에서 접근할 수 없다. 규제 기관이 "왜 이 사용자의 접근을 차단했는가"를 물었을 때, "AI가 그렇게 판단했습니다"는 법적으로 유효한 답변이 아니다.

EU의 AI법(AI Act)은 고위험 AI 시스템에 대해 인간 감독(human oversight) 의무를 명시하고 있다. 보안 대응 자동화는 명백히 이 범주에 들어갈 가능성이 높다. 국내에서도 개인정보보호법과 금융보안원 가이드라인이 자동화된 의사결정에 대한 근거 보존을 요구하고 있다.

공백 2: 책임 주체의 소멸

전통적인 보안 거버넌스에서는 "이 결정을 승인한 사람"이 명확하다. 보안 관리자, CISO, 혹은 사전에 승인된 플레이북을 설계한 팀이다. AI 자동화 체계에서는 이 책임 주체가 흐릿해진다. 벤더인가, 내부 DevSecOps 팀인가, 아니면 플레이북을 설정한 엔지니어인가.

이 질문은 단순한 내부 조직 문제가 아니다. 사이버 보안 사고 발생 시 규제 기관이나 피해 당사자가 책임을 물을 때, 명확한 책임 주체가 없으면 기업 전체가 위험에 노출된다.

공백 3: 대응 행동의 비례성 검증 불가

인간 분석가라면 "이 위협의 심각도에 비해 이 대응이 과한 것은 아닌가"를 판단한다. AI 시스템은 사전에 정의된 플레이북을 실행할 뿐이다. 문제는 그 플레이북이 현재의 비즈니스 맥락, 규제 환경, 혹은 해당 사용자의 특수한 상황을 고려하지 못한다는 것이다.

예를 들어, 월말 결산 중인 CFO의 계정이 비정상적인 접근 패턴을 보인다고 해서 자동으로 잠기면 어떤 일이 벌어질까. AI는 비즈니스 맥락을 모른다.

---

실무에서 지금 당장 할 수 있는 것들

이 문제가 AI 보안 자동화를 쓰지 말자는 이야기가 아니라는 점을 분명히 하고 싶다. 속도와 규모 면에서 AI 없이 현대 클라우드 환경의 위협을 감당하는 것은 사실상 불가능하다. 문제는 자동화의 범위와 거버넌스 설계다.

첫째, 자동 실행과 자동 추천을 분리하라. 모든 대응 행동을 자동 실행으로 설정하지 말고, 위협 등급별로 "자동 실행 가능한 행동"과 "인간 승인이 필요한 행동"을 명확히 구분하라. 크리티컬 등급의 계정 비활성화는 반드시 인간 승인 루프를 거치도록 설계해야 한다.

둘째, 결정 로그를 AI 판단 근거 수준으로 남겨라. 단순히 "자동화 정책 실행"이 아니라, 어떤 모델이, 어떤 이벤트를, 어떤 임계치로 판단했는지를 구조화된 형태로 저장해야 한다. 이것은 감사 대응뿐 아니라, 모델 성능 개선에도 필수적이다.

셋째, 플레이북을 정기적으로 인간이 검토하라. AI가 실행하는 플레이북은 AI가 설계한 것이 아니다. 인간이 설계했고, 그 설계가 현재의 비즈니스 환경과 규제 요건에 맞는지를 정기적으로 검토해야 한다. 최소 분기 1회 이상의 플레이북 리뷰 프로세스를 공식화하라.

넷째, "AI가 틀렸을 때"의 에스컬레이션 경로를 설계하라. 자동 대응이 잘못된 결과를 낳았을 때, 이를 탐지하고 복구하며 근본 원인을 분석하는 프로세스가 명확해야 한다. 이 경로 자체도 문서화되고 정기적으로 테스트되어야 한다.

---

한·미·일 AI 협력이 이 문제와 연결되는 이유

흥미롭게도, 이 거버넌스 공백은 국가 차원의 AI 정책 논의와도 맞닿아 있다. 한·미·일 AI칩 협력이 가속화되면서, AI 인프라의 신뢰성과 보안 거버넌스에 대한 국가 간 표준 논의도 함께 진행될 가능성이 높다. AI 클라우드 보안 자동화의 책임 공백은 단순히 기업 내부 문제가 아니라, 국가 사이버 보안 정책의 핵심 의제로 부상할 수 있다.

---

보안 분석가의 판단을 대체하는 것과 보조하는 것은 다르다

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 나는 이 말을 믿는다. 그리고 바로 그렇기 때문에, AI 클라우드 보안 자동화가 보안 분석가의 판단을 "대체"하는 방향으로 설계될 때 경계해야 한다고 생각한다.

보안 판단은 단순한 패턴 매칭이 아니다. 맥락을 읽고, 비례성을 판단하고, 그 결정에 책임을 지는 행위다. AI는 이 중 첫 번째는 잘 할 수 있다. 두 번째는 부분적으로 가능하다. 세 번째는 구조적으로 불가능하다.

우리가 직면한 문제는 AI가 보안을 못한다는 게 아니다. AI가 보안 결정을 내릴 때, 그 결정에 책임질 인간이 루프 안에 있는가라는 질문이다. 지금 많은 AI 클라우드 보안 자동화 체계는 이 루프에서 인간을 조용히, 그리고 체계적으로 밀어내고 있다.

그 밀어냄이 너무 자연스럽게 일어나고 있어서, 우리는 그것이 언제 일어났는지조차 알아채지 못하는 경우가 많다. 그리고 그것이야말로 가장 위험한 보안 취약점일 수 있다.

---

태그: AI 클라우드, 보안 자동화, 위협 탐지, SOC, 클라우드 거버넌스, SOAR, 감사 추적, 사이버보안

이 글은 여기서 자연스럽게 마무리됩니다. 결론 섹션은 이미 "보안 분석가의 판단을 대체하는 것과 보조하는 것은 다르다" 파트에서 완성되었기 때문입니다.

다만, 독자가 글을 다 읽고 난 뒤 명확한 행동 지침과 여운을 가져갈 수 있도록 마지막 클로징 문단을 추가하겠습니다.

---

AI 클라우드 보안 자동화를 도입하거나 운영하는 조직이라면, 오늘 당장 이 질문을 던져보길 권한다.

"지난 30일간 AI가 자동으로 실행한 보안 대응 중, 인간이 사후에라도 검토한 것은 몇 퍼센트인가?"

이 숫자가 낮다면, 당신의 조직은 이미 거버넌스 공백 안에 있다. 그리고 그 공백은 AI가 채우는 것이 아니라, 인간이 설계로 메워야 한다.

자동화는 속도를 준다. 거버넌스는 방향을 준다. 둘 다 없으면 빠르게 잘못된 곳으로 가는 것뿐이다.

---

이 글은 AI 클라우드 보안 자동화 거버넌스 시리즈의 일부입니다. 이전 글에서는 IAM 자동화, 재해복구 자동화, 데이터 삭제 자동화, 비용 최적화 자동화, 자가 치유 인프라가 각각 어떻게 인간의 판단을 루프 밖으로 밀어내는지를 다뤘습니다.

태그: AI 클라우드, 보안 자동화, 위협 탐지, SOC, 클라우드 거버넌스, SOAR, 감사 추적, 사이버보안