공격자가 AI를 무기로 쓰는데 방어자만 맨손이라면, 그 싸움의 결과는 시작 전에 정해져 있습니다.
E.1 왜 방어도 자동화되어야 하는가
이 책의 여섯 번째 원칙은 "공격이 자동화되면, 방어도 자동화되어야 한다"였습니다. 부록 E는 그 원칙을 실제로 어떻게 실현하는지에 대한 구체적인 안내입니다.
3장에서 살펴보았듯, 공격의 경제학은 이미 근본적으로 바뀌었습니다. 과거에는 취약점을 찾고 익스플로잇을 만드는 데 숙련된 사람의 시간이 많이 들었습니다. 그러나 이제 공격자는 AI를 이용해 취약점 탐색, 코드 분석, 익스플로잇 초안 작성, 피싱 문구 생성을 자동화합니다. 한 사람이 다룰 수 있는 공격의 규모와 속도가 수십, 수백 배로 늘어났습니다.
이 상황에서 방어자가 여전히 "1년에 한 번 보안 점검", "기억나면 패치", "사고가 터지면 대응"이라는 수작업 방식에 머무른다면, 비대칭은 갈수록 심해집니다. 공격은 기계의 속도로 진행되는데 방어는 사람의 속도로 진행되기 때문입니다.
해법은 분명합니다. 방어자도 같은 도구를 손에 쥐는 것입니다. AI를 활용해 서버의 보안 상태와 프로젝트 코드의 보안 상태를 상시 그리고 반복적으로 점검하고, 발견된 격차를 신속하게 메우는 것입니다.
특히 중요한 통찰이 하나 있습니다. AI 모델은 계속 발전합니다. 오늘 사용하는 모델이 놓친 취약점을, 6개월 뒤 더 똑똑해진 모델은 발견할 수 있습니다. 새 모델은 더 많은 취약점 패턴을 알고, 더 깊이 코드를 이해하며, 더 미묘한 설정 오류를 잡아냅니다. 그러므로 보안 점검은 한 번 하고 끝나는 것이 아니라, 모델이 새 버전으로 올라갈 때마다 다시 수행해야 하는 루틴이 되어야 합니다. 같은 코드, 같은 서버라도 더 나은 모델로 다시 보면 어제는 보이지 않던 것이 보입니다.
E.2 무엇을 자동화할 수 있는가
AI를 활용한 보안 자동화는 크게 네 가지 영역으로 나눌 수 있습니다.
영역 1: 서버 설정 감사 (Configuration Audit)
서버의 각종 설정 파일은 보안의 최전선이자, 사람이 실수하기 가장 쉬운 곳입니다. AI는 이런 설정을 빠르게 읽고, 알려진 모범 사례와 비교하여 위험한 부분을 짚어낼 수 있습니다.
점검 대상의 예시는 다음과 같습니다.
- SSH 설정 — 비밀번호 로그인이 꺼져 있는가, 공개키 인증만 허용하는가, root 직접 로그인이 막혀 있는가, 안전하지 않은 암호 스위트가 남아 있지 않은가. (7장)
- 웹 서버 설정(Nginx/Apache) — TLS 버전이 1.2 이상으로 제한되어 있는가, 약한 암호 스위트가 비활성화되어 있는가, 보안 헤더가 빠짐없이 설정되어 있는가, 디렉터리 노출이 차단되어 있는가,
.git이나.env같은 민감 경로 접근이 막혀 있는가. (8장, 9장) - 방화벽 규칙 — 불필요하게 열린 포트가 없는가, 허용 규칙이 최소 권한 원칙을 따르는가. (6장)
- 데이터베이스 설정 — 외부 바인딩이 차단되어 있는가, 기본 계정과 기본 포트가 그대로 쓰이지 않는가.
- 클라우드 인프라 설정 — 보안 그룹, IAM(클라우드에서 누가 무엇에 접근할 수 있는지를 정하는 권한 체계) 권한, 스토리지 버킷의 공개 여부 등. 공개로 잘못 열린 스토리지 버킷은 해마다 반복되는 대표적 유출 경로입니다.
이 작업의 핵심은, AI에게 설정 파일의 내용을 제공하고 "이 설정에서 보안상 위험하거나 모범 사례에서 벗어난 부분을 찾아 우선순위와 함께 알려 달라"고 요청하는 것입니다. 사람이 수백 줄의 설정을 일일이 검토하는 것보다 훨씬 빠르고, 빠뜨리는 부분이 적습니다.
영역 2: 프로젝트 코드 보안 검토 (Code Security Review)
애플리케이션 코드 자체의 취약점은 방화벽이나 TLS로 막을 수 없습니다(12장). AI는 코드를 읽고 다음과 같은 문제를 찾아낼 수 있습니다.
- SQL 인젝션, 명령어 인젝션 등 인젝션 취약점이 가능한 지점
- 인증과 접근 제어가 누락되거나 허술한 엔드포인트
- 사용자 입력에 대한 검증이 부족한 부분
- 하드코딩된 비밀 정보(키, 비밀번호, 토큰)
- 안전하지 않은 직렬화/역직렬화 (외부에서 들어온 데이터를 객체로 되살리는 과정에서 공격 코드가 끼어드는 문제)
- SSRF(서버 측 요청 위조 — 서버가 공격자가 시킨 내부 주소로 대신 요청을 보내게 만드는 공격)가 가능한 외부 요청 처리
- 오래되어 알려진 취약점이 있는 의존성 라이브러리
이런 유형이 추상적으로 느껴진다면, 어떤 코드가 위험한지에 대한 표준 분류인 OWASP Top 10을 옆에 두고 AI에게 "이 코드를 OWASP Top 10 기준으로 점검해 달라"고 요청하면 결과가 한결 일관됩니다. 더 깊이 들어가려면 항목별 안전 코딩 패턴을 모은 OWASP Cheat Sheets가 좋은 참고가 됩니다.
특히 의존성 점검은 매우 중요합니다. 4장에서 다룬 공급망 공격과 의존성 지옥의 위험은, 내가 직접 쓴 코드보다 내가 끌어다 쓴 라이브러리에서 더 자주 현실화됩니다. AI에게 프로젝트의 의존성 목록과 버전을 주고, 알려진 취약점이 있는 패키지가 있는지, 업데이트가 필요한지 확인하게 할 수 있습니다. 다만 AI의 기억(학습 시점)은 어제 새로 공개된 취약점까지 담고 있지 못할 수 있으므로, AI의 1차 판단은 반드시 공개 취약점 데이터베이스 — OSV, GitHub Advisory, NVD — 로 교차 확인하는 것이 안전합니다. 2024년 xz-utils 백도어(CVE-2024-3094)처럼, 신뢰받던 패키지가 어느 날 갑자기 위험해지는 일이 실제로 일어나기 때문입니다.
영역 3: 로그와 이상 징후 분석 (Log Analysis)
13장에서 다루듯, 침해를 가정하는 방어에서는 로그를 남기는 것만큼 그것을 읽는 것이 중요합니다. 그러나 사람이 매일 수만 줄의 로그를 읽을 수는 없습니다. AI는 대량의 로그에서 이상 패턴을 식별하는 데 활용할 수 있습니다. 비정상적인 접근 시도, 평소와 다른 트래픽 패턴, 권한 상승 시도의 흔적, 알려진 공격 서명 등을 사람보다 빠르게 1차 분류할 수 있습니다.
다만 이 영역은 다음 두 가지를 주의해야 합니다. 첫째, 로그에는 민감 정보가 포함될 수 있으므로 외부 서비스에 보낼 때 신중해야 합니다(E.5 참고). 둘째, AI의 1차 분류는 사람의 판단을 보조하는 것이지 대체하는 것이 아닙니다.
영역 4: 스캔 결과 해석과 우선순위화 (Triage)
10장의 자가 진단 도구들(testssl.sh, sslyze, securityheaders.com의 보안 헤더 점검, OWASP ZAP·nmap, nuclei)은 많은 양의 결과를 쏟아냅니다. 문제는 그 결과를 읽고 "무엇부터 고쳐야 하는가"를 판단하는 것입니다. AI는 스캔 결과를 입력받아, 각 발견 사항의 심각도를 평가하고, 실제 위험과 수정 난이도를 고려한 우선순위를 제안하며, 구체적인 수정 방법까지 안내할 수 있습니다. 이것은 스캐너가 주지 못하는 "그래서 무엇을 먼저 하면 되는가"라는 맥락을 채워 줍니다. 현장에서 보면, 스캐너가 쏟아낸 수십 개의 "경고" 중 진짜 급한 것은 두세 개뿐인 경우가 대부분입니다 — AI에게 1차로 추려 달라고 시키면, 그 두세 개를 찾는 시간이 확연히 줄어듭니다.
E.3 모델 업그레이드를 트리거로 삼는 재점검 루틴
부록 E의 가장 핵심적인 실천 항목입니다. 보안 자동화를 일회성이 아니라 살아 있는 루틴으로 만드는 방법입니다.
다음 세 가지 시점을 보안 재점검의 트리거로 설정하시기 바랍니다.
트리거 1: 정기 일정. 가장 기본입니다. 주간 또는 월간으로 서버 설정 감사와 코드 보안 검토를 자동 실행하도록 예약합니다. 이것은 원칙 5(과정으로서의 보안)의 기본 실천입니다.
트리거 2: 새로운 위협의 등장. 사용 중인 소프트웨어나 의존성에 새로운 고위험 CVE(공개적으로 등록된 보안 취약점에 붙는 고유 번호)가 공개되면(4장), 해당 구성 요소를 쓰는 프로젝트와 서버를 즉시 재점검합니다. "이 새 취약점이 우리에게 영향을 주는가"를 신속하게 판단하는 것이 n-day(이미 공개되어 패치가 나왔는데도 미적용으로 남아 악용되는 취약점) 공격의 골든타임을 지키는 길입니다. 2023년 MOVEit Transfer(CVE-2023-34362)는 공개 직후 랜섬웨어 조직이 대량으로 악용했고, Citrix Bleed(CVE-2023-4966)는 패치가 있었는데도 미적용한 곳들이 대규모로 털렸습니다. 즉 골든타임을 놓치는 순간이 곧 침해의 순간입니다. 어떤 취약점이 "지금 실제로" 악용되고 있는지는 미국 CISA의 악용된 취약점 카탈로그(KEV)에 공개되니, 이 목록을 트리거의 입력으로 삼아 "내가 쓰는 구성 요소가 여기 올라왔는가"를 AI에게 대조시키면 우선순위가 단번에 분명해집니다. 2026년 현재, AI가 익스플로잇 제작 속도를 더 당기면서 "공개 → 대량 악용"의 간격은 점점 짧아지고 있어, 이 트리거의 가치는 갈수록 커집니다.
트리거 3: AI 모델의 버전 업그레이드. 이것이 이 책이 특별히 강조하는 트리거입니다. 사용하는 AI 모델이 새 버전으로 올라가면, 그것을 전체 보안 자산을 다시 들여다보는 신호로 삼으십시오. 더 똑똑해진 모델은 다음을 더 잘합니다.
- 이전 모델이 놓친 미묘한 취약점 패턴을 식별합니다.
- 더 복잡한 코드 흐름을 추적하여 깊숙이 숨은 문제를 찾습니다.
- 최신 공격 기법에 대한 더 많은 지식을 반영합니다.
- 거짓 양성과 거짓 음성을 줄여 더 정확한 판단을 제공합니다.
같은 서버 설정, 같은 프로젝트 코드를 새 모델로 다시 검토하면, 종종 이전에는 발견되지 않았던 격차가 드러납니다. 이것은 코드가 바뀌어서가 아니라, 보는 눈이 더 좋아졌기 때문입니다. 그러므로 "모델이 업그레이드되었다"는 소식은 곧 "보안 점검을 다시 돌릴 때가 되었다"는 신호로 받아들이는 습관을 들이시기 바랍니다.
이 세 트리거를 종합한 재점검 루틴을 의사 코드로 표현하면 다음과 같습니다.
정기적으로(주간/월간):
서버 설정 감사 실행
프로젝트 코드 보안 검토 실행
의존성 취약점 점검 실행
→ 발견 사항을 우선순위와 함께 보고
→ 자동 수정 가능한 항목은 제안서 생성(사람이 승인 후 적용)
새 고위험 CVE 공개 시:
영향받는 구성 요소를 쓰는 자산 식별
해당 자산 즉시 재점검
→ 영향 평가 및 대응 우선순위 보고
AI 모델 새 버전 출시 시:
전체 서버 설정과 프로젝트 코드를 새 모델로 재검토
이전 점검 결과와 비교
→ 새로 발견된 격차를 별도 보고
→ "더 나은 눈으로 다시 본 결과" 기록 및 추적E.4 실천을 위한 워크플로 설계
위 루틴을 실제로 구현하기 위한 현실적인 조언입니다. 특히 1인 또는 소규모 팀을 위한 것입니다(15장과 연결됩니다).
작게 시작하십시오. 처음부터 완벽한 자동화 파이프라인을 구축하려 하지 마십시오. 가장 위험이 큰 것 하나, 예를 들어 SSH 설정 감사나 의존성 취약점 점검부터 자동화하고, 점차 범위를 넓히는 것이 현실적입니다.
결과를 한곳에 모으십시오. 여러 점검의 결과가 흩어져 있으면 관리되지 않습니다. 점검 결과를 하나의 보고 형식으로 통일하고, 정해진 채널(예: 알림 메시지, 대시보드)로 받도록 하십시오. 무엇을 발견했고, 무엇을 고쳤고, 무엇이 미해결인지 추적할 수 있어야 합니다.
자동 발견과 자동 적용을 분리하십시오. 이것은 매우 중요한 안전장치입니다. AI가 문제를 발견하고 수정안을 제안하는 것까지는 자동화해도 좋습니다. 그러나 그 수정을 운영 서버에 적용하는 것은, 특히 되돌리기 어려운 변경은, 반드시 사람이 검토하고 승인한 뒤에 이루어져야 합니다. AI가 제안한 방화벽 규칙 변경이나 SSH 설정 변경을 검토 없이 자동 적용했다가, 자기 자신을 서버에서 잠가버리거나 서비스를 중단시키는 일이 생길 수 있습니다(6장의 경고를 기억하십시오).
점검 자체를 버전 관리하십시오. 어떤 점검을, 어떤 모델로, 언제 수행했고, 그 결과가 무엇이었는지를 기록으로 남기십시오. 그래야 모델이 업그레이드된 뒤 "이전 대비 무엇이 새로 발견되었는가"를 비교할 수 있습니다.
E.5 AI에게 절대 맡겨서는 안 되는 것들
AI를 방어에 활용하는 것은 강력하지만, 만능이 아니며 그 자체로 새로운 위험을 만들 수도 있습니다. 다음은 반드시 지켜야 할 한계선입니다.
민감 정보를 함부로 외부에 보내지 마십시오. 서버 설정이나 코드에는 비밀번호, 키, 토큰, 개인정보가 포함될 수 있습니다. 이것을 외부 AI 서비스에 그대로 전송하면, 그 자체가 정보 유출이 될 수 있습니다. 점검에 보내기 전에 민감 정보를 제거하거나 가리고, 데이터 처리 정책이 신뢰할 만한 환경을 사용하며, 매우 민감한 자산은 외부로 나가지 않는 방식을 택하십시오.
AI의 출력을 맹신하지 마십시오. AI는 틀릴 수 있습니다. 존재하지 않는 취약점을 보고하거나(거짓 양성), 실재하는 취약점을 놓칠 수 있습니다(거짓 음성). AI가 "안전합니다"라고 말했다고 해서 안전이 보장되는 것이 아닙니다. AI의 판단은 사람의 검토를 보조하는 입력이지, 최종 결론이 아닙니다.
되돌리기 어려운 변경을 자동 적용하지 마십시오. E.4에서 강조한 대로, 발견과 적용을 분리하십시오. 특히 접근 제어, 방화벽, 인증 관련 변경은 사람의 승인 없이 자동 적용되어서는 안 됩니다.
AI가 생성한 코드나 설정을 검토 없이 배포하지 마십시오. AI에게 보안 수정을 요청해 받은 코드라도, 그것이 새로운 취약점을 만들지 않는지, 의도대로 동작하는지 사람이 확인해야 합니다. 보안을 고치려다 다른 보안 구멍을 내는 일이 없도록 해야 합니다.
AI를 유일한 방어선으로 삼지 마십시오. 이것은 원칙 3(깊이로 방어하라)의 연장입니다. AI 기반 점검은 여러 방어 층 중 하나일 뿐입니다. 공격면 축소, 접근 제어, TLS, 모니터링, 백업 같은 기본기를 대체하는 것이 아니라 보완하는 것입니다.
E.6 요약
부록 E의 핵심을 정리합니다.
- 공격이 AI로 자동화된 시대에, 방어가 수작업에 머무르면 비대칭이 심화됩니다. 방어도 자동화해야 합니다.
- AI는 서버 설정 감사, 코드 보안 검토, 로그 분석, 스캔 결과 우선순위화의 네 영역에서 방어자를 도울 수 있습니다.
- 보안 점검은 일회성이 아니라 루틴이어야 하며, 정기 일정·새 CVE 공개·AI 모델 업그레이드의 세 가지를 트리거로 삼아야 합니다.
- 더 나은 모델은 같은 자산에서 더 많은 것을 발견합니다. 모델 업그레이드는 곧 재점검의 신호입니다.
- 발견과 적용을 분리하고, 민감 정보를 보호하며, AI의 출력을 검증하고, AI를 유일한 방어선으로 삼지 않는다는 한계선을 반드시 지켜야 합니다.
자동화는 사람을 대체하기 위한 것이 아닙니다. 사람이 더 중요한 판단에 집중할 수 있도록, 반복적이고 대규모인 점검을 기계에게 맡기는 것입니다. 공격자가 기계의 속도로 달려올 때, 방어자도 최소한 같은 속도로 점검할 수 있어야 합니다.
관련 장: 3장(AI가 바꾼 공격의 경제학), 4장(CVE의 홍수), 10장(자기 사이트를 직접 스캔하라), 15장(지속 가능한 보안 운영).