생성형 AI가 보안 담당자를 대체할 것이라는 말은 과장에 가깝습니다. 하지만 보안 업무의 상당 부분을 차지하는 읽기, 요약, 비교, 초안 작성과 반복적인 조회 작업을 줄여주는 도구라는 점은 분명합니다.
보안팀이 매일 마주하는 데이터는 방대합니다.
- 수백 개의 보안 경보
- 길고 복잡한 로그
- 난독화된 스크립트
- 새로 공개되는 취약점과 위협 정보
- 클라우드와 Kubernetes 설정 파일
- 보안 정책, 점검 결과와 사고 보고서
문제는 정보가 부족해서가 아니라 너무 많아서 중요한 신호를 제때 찾기 어렵다는 것입니다. 생성형 AI는 이 정보를 사람이 판단하기 좋은 형태로 바꾸는 데 특히 유용합니다.
이 글에서는 제품 소개보다 실제 보안 업무를 기준으로 생성형 AI를 어디에 적용할 수 있는지 살펴봅니다. 각 사례마다 무엇을 맡길 수 있는지, 어떤 결과를 기대할 수 있는지, 사람이 무엇을 검증해야 하는지를 함께 정리합니다.
생성형 AI가 보안 업무에서 잘하는 일
생성형 AI의 장점은 모든 공격을 자동으로 찾아내는 능력이 아닙니다. 서로 다른 형태의 정보를 정리하고, 사람이 다음 판단을 내리는 데 필요한 맥락을 만드는 능력입니다.
| 업무 유형 | 생성형 AI가 잘하는 일 | 사람이 해야 할 일 |
| 요약 | 긴 경보와 로그를 사건 흐름으로 정리 | 원본 증거와 일치하는지 확인 |
| 변환 | 자연어를 KQL, SPL, SQL, Sigma 초안으로 변환 | 쿼리 범위·필드·성능 검증 |
| 분류 | 피싱 의심 메일이나 취약점의 우선순위 제안 | 오탐·미탐과 업무 영향 판단 |
| 설명 | 난독화 코드, 공격 기법과 보안 설정 설명 | 샌드박스와 실제 환경에서 검증 |
| 초안 | 사고 보고서, 탐지 규칙과 대응 절차 작성 | 승인, 책임 판단과 최종 실행 |
| 비교 | 정책·설정·버전 간 차이 분석 | 최신 공식 문서와 운영 조건 확인 |
핵심은 생성형 AI를 최종 판정자가 아니라 분석 보조자로 두는 것입니다.
사례 1: 보안 경보와 사고 타임라인 요약
SOC 분석가는 하나의 사고를 조사하기 위해 엔드포인트, 이메일, 계정, 방화벽과 클라우드 로그를 오가야 합니다. 동일한 사건에서 여러 제품이 각각 다른 경보를 만들기도 합니다.
생성형 AI는 다음 데이터를 하나의 시간 순서로 정리할 수 있습니다.
- 최초 탐지 시각
- 관련 사용자와 장비
- 의심 IP·도메인·파일 해시
- 실행된 프로세스와 명령
- 초기 침투, 권한 상승, 내부 이동 같은 공격 단계
- 분석되지 않은 증거와 추가 확인 항목
예를 들어 다음처럼 요청할 수 있습니다.
아래 경보와 로그를 시간 순서로 정리해줘.
1. 확인된 사실과 추정을 분리한다.
2. 사용자, 호스트, IP, 프로세스 관계를 표로 만든다.
3. MITRE ATT&CK 전술과 기법은 근거가 있는 경우에만 연결한다.
4. 누락된 조사 항목을 질문 형태로 제시한다.
5. 격리나 차단 작업은 실행하지 말고 제안만 한다.
Microsoft의 공식 Security Copilot 사례도 여러 경보가 포함된 사고를 요약하고, 공격 단계를 설명하며, 대응 가이드를 제공하는 흐름을 제시합니다.
다만 AI가 만든 타임라인은 원본 이벤트가 아닙니다. 최종 보고서에는 SIEM 이벤트 ID, 타임스탬프, 쿼리와 원본 증거를 함께 남겨야 합니다.
사례 2: 경보 우선순위 분류와 오탐 분석
모든 경보를 같은 순서로 처리하면 중요한 사고가 뒤로 밀립니다. 생성형 AI는 경보의 심각도 자체보다 조직의 맥락을 포함한 우선순위를 제안하는 데 도움을 줄 수 있습니다.
예를 들어 다음 정보를 함께 입력합니다.
- 경보 종류와 탐지 규칙
- 공격 대상 자산의 중요도
- 인터넷 노출 여부
- 사용자 권한과 직무
- 알려진 취약점 존재 여부
- 최근 변경 작업
- 동일 개체의 과거 경보
결과는 단순히 위험·안전으로 나누기보다 다음 형태가 좋습니다.
| 판정 항목 | 출력 예시 |
| 잠정 우선순위 | 긴급, 높음, 보통, 낮음 |
| 판단 근거 | 확인된 로그와 자산 중요도 |
| 불확실성 | 누락된 데이터와 상반되는 신호 |
| 추가 조회 | 필요한 SIEM·EDR 쿼리 |
| 권장 조치 | 분석, 격리 검토, 사용자 확인 |
AI가 낮은 위험으로 분류했다는 이유만으로 경보를 자동 종료해서는 안 됩니다. 특히 관리자 계정, 도메인 컨트롤러, CI/CD 자격증명과 외부 노출 시스템은 별도의 보수적인 정책이 필요합니다.
사례 3: 위협 인텔리전스 요약과 IOC 보강
새로운 공격 캠페인이나 CVE가 공개되면 보안 담당자는 여러 보고서를 읽고 우리 환경과 관련이 있는지 판단해야 합니다.
생성형 AI에 공식 권고문과 신뢰할 수 있는 위협 인텔리전스를 제공하면 다음 작업을 빠르게 수행할 수 있습니다.
- 공격자의 목표와 주요 TTP 요약
- IOC에서 IP, 도메인, URL, 해시 추출
- MITRE ATT&CK 기법 연결
- 영향을 받는 제품과 버전 정리
- 우리 자산 목록과 교차 비교할 질문 생성
- 탐지와 완화 조치 초안 작성
첨부한 공식 권고문에서 확인된 사실만 사용해 다음을 작성해줘.
- 영향받는 제품과 버전
- 악용 전제조건
- 침해지표 목록
- MITRE ATT&CK 연결과 근거 문장
- 우리 환경에서 확인할 자산·로그·쿼리
- 패치 전 임시 완화책
문서에 없는 내용은 추측하지 말고 '확인 필요'로 표시해줘.
여기서 중요한 것은 출처 추적입니다. AI의 요약만 저장하지 말고 원문 URL, 게시일, CVE 번호와 인용한 근거를 함께 보존해야 합니다.
사례 4: 자연어로 위협 헌팅 쿼리 초안 만들기
SIEM은 강력하지만 제품마다 쿼리 언어가 다릅니다. Microsoft Sentinel의 KQL, Splunk의 SPL, 일반 SQL과 EDR 고유 문법을 모두 능숙하게 다루기는 어렵습니다.
생성형 AI는 자연어 요구사항을 쿼리 초안으로 바꾸고 기존 쿼리를 설명하는 데 유용합니다.
Microsoft Defender Advanced Hunting용 KQL 초안을 작성해줘.
목표: 최근 24시간 동안 Office 프로세스가 PowerShell을 실행한 사례 탐지
필수 출력: 시간, 장비명, 사용자, 부모 프로세스, 명령줄, SHA256
제외: 승인된 자동화 계정 sec-automation
주의: 실제 테이블과 필드가 없으면 임의로 만들지 말고 확인이 필요한 필드로 표시
AI가 만든 쿼리는 바로 운영 탐지 규칙으로 등록하지 않습니다.
- 스키마와 필드 이름을 확인합니다.
- 짧은 기간과 제한된 데이터로 실행합니다.
- 결과 표본을 원본 이벤트와 비교합니다.
- 쿼리 비용과 실행 시간을 확인합니다.
- 오탐 제외 조건이 공격자의 우회 경로가 되지 않는지 검토합니다.
좋은 활용 방식은 쿼리 생성을 맡기는 것이 아니라 분석가가 검증 가능한 첫 초안을 빠르게 얻는 것입니다.
사례 5: 의심 스크립트와 명령줄 분석
PowerShell, Bash, JavaScript와 매크로는 공격과 정상 자동화 모두에 사용됩니다. 생성형 AI는 긴 명령줄을 나누고 각 옵션의 의미를 설명하며 난독화 계층을 식별하는 데 도움을 줍니다.
가능한 작업은 다음과 같습니다.
- Base64와 URL 인코딩 식별
- PowerShell 실행 인수 설명
- 파일 다운로드와 실행 흐름 요약
- 네트워크 연결 대상 추출
- 지속성 확보 동작 후보 식별
- 조사할 파일·레지스트리·프로세스 제안
그러나 분석 대상 코드를 AI가 직접 실행하게 해서는 안 됩니다. 복호화된 스크립트는 격리된 샌드박스에서 정적·동적 분석해야 하며, AI가 안전하다고 설명한 코드도 신뢰해서는 안 됩니다.
또한 공개형 AI 서비스에 실제 악성코드 샘플, 고객 정보가 포함된 로그나 내부 경로를 그대로 업로드하면 안 됩니다. 조직이 승인한 보안 경계 안에서 사용하거나 민감정보를 제거해야 합니다.
사례 6: 탐지 규칙과 Sigma 룰 초안 작성
새로운 공격 기법을 파악한 뒤에는 이를 탐지 가능한 조건으로 바꿔야 합니다. 생성형 AI는 분석 문장을 Sigma 규칙의 첫 초안으로 변환할 수 있습니다.
다음 행위를 탐지하는 Sigma 규칙 초안을 작성해줘.
- Windows에서 rundll32.exe가 원격 URL을 인수로 사용
- 부모 프로세스와 전체 CommandLine 포함
- ATT&CK 매핑에는 근거를 주석으로 남김
- 정상 관리 도구와 충돌할 수 있는 오탐 사례 제시
- 운영 적용 전 필요한 로그 소스와 감사 정책 명시
검토할 항목은 명확합니다.
- 필요한 로그가 실제로 수집되는가
- 필드명이 대상 SIEM 변환기와 맞는가
- 대소문자와 경로 변형을 처리하는가
- 공격자가 쉽게 우회할 수 있는 문자열 한 개에 의존하지 않는가
- 정상 소프트웨어 배포와 충돌하지 않는가
AI는 규칙 작성 시간을 줄일 수 있지만 탐지 품질은 테스트 데이터와 지속적인 튜닝에서 결정됩니다.
사례 7: 취약점 우선순위와 패치 영향 분석
취약점 관리에서 CVSS 점수가 높은 항목부터 처리하는 방식만으로는 부족합니다. 실제 위험은 자산의 노출과 중요도, 악용 가능성, 보완 통제에 따라 달라집니다.
생성형 AI는 다음 자료를 하나의 판단표로 정리할 수 있습니다.
- CVE 설명과 CVSS 벡터
- CISA KEV 포함 여부
- 공급사 권고문과 패치 버전
- 인터넷 노출 자산
- 설치된 제품과 실제 버전
- 공격 전제조건과 필요한 권한
- WAF, 네트워크 분리 같은 보완 통제
| 질문 | 생성형 AI 활용 결과 |
| 우리 환경이 영향받는가 | 자산·버전별 확인 목록 |
| 지금 악용 가능한가 | 전제조건과 노출 경로 요약 |
| 먼저 패치할 대상은 | 근거가 포함된 우선순위 제안 |
| 패치가 어려우면 | 공식 문서 기반 임시 완화책 정리 |
| 무엇을 모니터링할까 | 관련 로그와 탐지 아이디어 |
패치 명령이나 설정 변경은 반드시 공급사 공식 문서와 변경 관리 절차를 거쳐야 합니다. 존재하지 않는 패치 버전이나 옵션을 AI가 만들어낼 수 있기 때문입니다.
사례 8: 클라우드와 Kubernetes 설정 검토
IAM 정책, Terraform, Kubernetes YAML과 네트워크 정책은 텍스트 기반이므로 생성형 AI가 비교적 잘 다룰 수 있습니다.
예를 들어 다음 문제를 찾도록 요청할 수 있습니다.
- 과도한 IAM 와일드카드 권한
- 공개 스토리지와 인터넷 노출
- 보안 그룹의 광범위한 인바운드 규칙
- 컨테이너의 privileged 실행
hostNetwork,hostPID,hostPath사용- 누락된
securityContext - Secret의 평문 하드코딩
- Kubernetes RBAC의 과도한 권한
- NetworkPolicy 부재
이 Kubernetes 매니페스트를 보안 관점에서 검토해줘.
각 항목을 위험도, 근거가 되는 YAML 경로, 공격 시나리오,
최소 변경 수정안으로 정리한다.
Pod Security Standards와 Kubernetes 공식 문서를 우선 기준으로 사용한다.
애플리케이션 동작을 알 수 없는 항목은 단정하지 말고 질문으로 남긴다.
AI가 만든 수정안을 바로 kubectl apply하거나 Terraform에 반영하면 안 됩니다. 스키마 검증, 정책 엔진, 테스트 환경과 코드 리뷰를 통과해야 합니다.
사례 9: 피싱 메일 조사 보조
피싱 신고 메일은 반복적으로 확인해야 할 항목이 많습니다.
- 표시 이름과 실제 발신 주소
- Reply-To 불일치
- SPF, DKIM, DMARC 결과
- URL과 리디렉션 체인
- 첨부파일 형식과 해시
- 사용자의 링크 클릭 여부
- 이후 로그인과 세션 활동
- 같은 발신자의 조직 내 수신자
생성형 AI는 헤더와 보안 제품 결과를 요약하고 추가 조사 순서를 제안할 수 있습니다. Microsoft도 사용자 신고 메일을 분류하고 분석 근거를 제공하는 피싱 트리아지 사례를 공식 보안 AI 활용 영역으로 제시합니다.
다만 메일 본문에는 개인정보와 회사 기밀이 포함될 수 있습니다. 외부 모델에 원문을 전송하기 전에 승인된 서비스인지 확인하고, 필요하면 주소·본문·첨부파일을 비식별화해야 합니다.
사례 10: 침해사고 대응 절차와 보고서 작성
사고가 발생하면 분석과 동시에 기록을 남겨야 합니다. 하지만 긴급한 상황에서 보고서 품질까지 유지하기는 쉽지 않습니다.
생성형 AI는 확인된 증거를 바탕으로 다음 문서의 초안을 만들 수 있습니다.
- 사고 개요
- 시간대별 타임라인
- 영향받은 자산과 계정
- 확인된 침해 범위
- 수행한 격리·차단·복구 조치
- 남은 위험과 추가 작업
- 경영진용 요약
- 재발 방지 과제
좋은 입력 방식은 분석가의 메모를 그대로 던지는 것이 아니라 사실, 추정, 결정과 실행 결과를 구분하는 것입니다.
아래 사고 기록으로 보고서 초안을 작성해줘.
- 확인된 사실과 분석가의 추정을 분리한다.
- 시간은 모두 KST와 UTC를 병기한다.
- 수행하지 않은 조치를 수행했다고 쓰지 않는다.
- 근거 이벤트 ID가 없는 결론은 '검증 필요'로 표시한다.
- 기술팀용 상세본과 경영진용 5문장 요약을 각각 만든다.
법적 신고, 고객 통지와 대외 발표 문구는 법무·개인정보·경영 책임자의 검토 없이 AI 결과를 사용해서는 안 됩니다.
사례 11: 보안 정책과 감사 증적 정리
보안 담당자는 기술 분석뿐 아니라 정책과 감사 대응에도 많은 시간을 사용합니다. 생성형 AI는 다음 작업을 보조할 수 있습니다.
- 여러 정책 문서의 중복과 충돌 비교
- 통제 항목과 실제 증적 매핑
- 인터뷰 질문과 점검표 작성
- 기술 설정을 비기술 담당자용 문장으로 변환
- 미비점과 필요한 증적 목록 정리
예를 들어 ISMS, ISO 27001 또는 내부 통제 기준을 클라우드 설정과 연결할 때 AI가 매핑 초안을 만들 수 있습니다. 하지만 인증 충족 여부나 법률 해석을 AI가 최종 판정해서는 안 됩니다.
자동화 수준은 세 단계로 나누는 것이 안전하다
생성형 AI 도입은 처음부터 자동 대응 에이전트를 만드는 것보다 위험도가 낮은 업무부터 시작하는 편이 좋습니다.
| 단계 | AI 권한 | 적합한 업무 |
| 1단계: 읽기·요약 | 데이터 조회와 초안 생성 | 경보 요약, 보고서, 쿼리 설명 |
| 2단계: 제안 | 조사 쿼리와 조치안 생성 | 헌팅 쿼리, 탐지 규칙, 티켓 작성 |
| 3단계: 제한적 실행 | 승인된 도구를 좁은 범위에서 호출 | 계정 잠금 요청, 장비 격리 워크플로 |
초기에는 1단계에서 품질과 위험을 측정합니다. 2단계에서는 사람이 승인한 뒤 실행하고, 3단계는 강한 권한 제한과 감사 로그, 중단 장치가 준비된 경우에만 적용합니다.
특히 다음 작업은 기본적으로 사람 승인을 요구해야 합니다.
- 계정 비활성화와 권한 회수
- 엔드포인트 격리
- 방화벽 차단
- Kubernetes 리소스 삭제
- 클라우드 IAM 변경
- 외부 기관 또는 고객 통지
보안팀이 생성형 AI에 입력하면 안 되는 데이터
도입 효과보다 먼저 데이터 경계를 정해야 합니다.
| 데이터 | 기본 처리 원칙 |
| 비밀번호·API 키·토큰 | 입력 금지, 즉시 마스킹 |
| 고객 개인정보 | 승인된 환경에서 최소한만 처리 |
| 내부 소스코드 | 계약·보존·학습 정책 확인 후 사용 |
| 악성코드 원본 | 격리 분석 환경에서만 처리 |
| 사고 로그 | 계정·IP·호스트명 등 비식별화 검토 |
| 미공개 취약점 | 공개 서비스 입력 금지, 접근 통제 |
NIST의 생성형 AI 위험관리 가이드는 데이터 프라이버시, 정보 무결성, 정보 보안, 사람과 AI의 역할 구성과 제3자 생성형 AI 사고 대응을 주요 위험 영역으로 다룹니다.
조직은 최소한 다음 질문에 답할 수 있어야 합니다.
- 입력 데이터가 모델 학습에 사용되는가
- 프롬프트와 응답은 얼마나 보관되는가
- 데이터는 어느 지역에서 처리되는가
- 관리자와 공급사가 대화를 볼 수 있는가
- 삭제와 감사 로그 기능이 있는가
- 연결된 플러그인과 에이전트는 어떤 권한을 갖는가
생성형 AI의 답변을 검증하는 체크리스트
보안 업무에서는 그럴듯한 오답이 가장 위험합니다.
- 원본 로그에 없는 이벤트를 만들어내지 않았는가
- 존재하지 않는 CVE, 패치 버전과 명령을 제시하지 않았는가
- IOC와 공격 기법의 출처가 있는가
- 사실과 추정을 구분했는가
- 시간대와 이벤트 순서가 맞는가
- 쿼리가 실제 스키마에서 실행되는가
- 제안한 조치가 업무 중단을 일으키지 않는가
- 삭제·격리·차단 전에 사람의 승인을 받는가
- AI의 입력, 출력과 실행 기록이 감사 로그에 남는가
MITRE ATLAS는 생성형 AI와 에이전트 시스템을 대상으로 프롬프트, 검색 컨텍스트, 도구 연결과 제어 정책이 공격 표면이 될 수 있음을 체계적으로 정리합니다. 보안팀이 AI를 방어에 활용할 때 AI 시스템 자체의 보안도 함께 설계해야 합니다.
작은 파일럿으로 시작하는 방법
첫 프로젝트로는 자동 차단보다 사고 보고서 초안이나 경보 요약처럼 되돌릴 수 있는 업무가 적합합니다.
- 반복 시간이 많이 드는 업무 하나를 선택합니다.
- 입력 가능한 데이터 등급을 정합니다.
- 정답이 있는 과거 사례 20~50개를 준비합니다.
- 정확도, 누락, 환각과 작업 시간 감소를 측정합니다.
- 사람이 검토하는 승인 지점을 정의합니다.
- 프롬프트와 결과를 감사 가능하게 기록합니다.
- 품질 기준을 통과한 뒤 다음 업무로 확장합니다.
평가 지표도 단순 만족도보다 구체적이어야 합니다.
- 분석 시간 감소율
- 중요 증거 누락률
- 잘못된 IOC·CVE 생성률
- 쿼리 실행 성공률
- 분석가가 수정한 문장 비율
- 오탐·미탐 변화
- 고위험 조치의 사람 승인 준수율
결론: 생성형 AI는 판단을 대신하기보다 판단 준비 시간을 줄인다
보안 업무에서 생성형 AI가 가장 큰 효과를 내는 영역은 반복되는 정보 정리와 첫 초안입니다.
경보를 사건 흐름으로 바꾸고, 위협 보고서에서 IOC를 추출하고, 자연어를 헌팅 쿼리로 변환하고, 클라우드 설정의 위험 후보를 찾고, 사고 보고서의 구조를 만드는 일은 생성형 AI와 잘 맞습니다.
반대로 공격 여부의 최종 판정, 시스템 격리, 계정 차단, 패치 적용과 법적 판단은 여전히 책임 있는 사람의 검토가 필요합니다.
좋은 도입 원칙은 간단합니다.
AI는 증거를 정리하고 선택지를 제안한다. 사람은 원본을 검증하고 책임 있는 결정을 내린다.
생성형 AI를 보안팀의 자동 판정기로 시작하면 위험이 커집니다. 분석가가 더 빠르고 일관되게 판단하도록 돕는 보조 도구로 시작하면 효과를 측정하고 통제하기 쉽습니다.
참고한 공식 자료
'일반IT > IT보안' 카테고리의 다른 글
| 브라우저에 내장된 인증기관 목록은 무엇일까 — Root Store와 HTTPS 신뢰 구조 이해하기 (0) | 2026.07.23 |
|---|---|
| AWS IMDSv1과 IMDSv2를 보안 관점에서 이해하기 (0) | 2026.06.11 |
| 🔬 Kali에서 radare2로 악성코드 PE를 해부하다 — 어셈블리 추출 완전 정복 (0) | 2026.06.02 |
| 🐍 코드로 사냥하라 — yara-python으로 만드는 자동화된 시그니처 탐지기 (0) | 2026.05.23 |
| 🎯 악성코드를 사냥하는 사냥꾼의 언어, YARA 룰 직접 만들어보기 (0) | 2026.05.23 |
