AI가 바꾼 공격의 경제학: 정밀 공격의 대량 생산 시대, 방어자는 무엇을 준비해야 하는가

공격 한 건의 단가가 0에 가까워지면, "우리는 작아서 표적이 안 될 것"이라는 가정이 가장 먼저 무너집니다. 지금까지 안전했던 자산 대부분은 견고해서가 아니라 수지가 안 맞아서 방치돼 있었을 뿐입니다.

AI와 보안을 엮어 말할 때 사람들은 보통 두 극단 중 하나로 미끄러집니다. 한쪽은 "이제 AI가 뭐든 다 뚫는다"는 종말론이고, 다른 한쪽은 "AI라고 해 봐야 도구 하나 늘어난 것뿐, 달라질 건 없다"는 무신경입니다. 둘 다 틀렸습니다. 전자는 공포만 주고 행동 지침은 주지 않으며, 후자는 지금 실제로 벌어지는 구조 변화를 놓칩니다.

이 글은 그 사이를 걷습니다. 핵심 질문은 "AI가 마법 같은 신종 공격을 발명했는가"가 아니라 훨씬 더 건조합니다. 같은 공격을 하는 데 드는 돈·시간·전문성이 어떻게 달라졌는가 — 즉 공격의 경제학이 어떻게 재편되었는가입니다.

AI가 진짜로 바꾼 것: 새로운 공격이 아니라 단가

먼저 오해를 하나 걷어 내겠습니다. AI가 완전히 새로운 공격 기법을 발명한 사례는 생각보다 드뭅니다. 정찰, 취약점 탐색, 익스플로잇 작성, 피싱, 침투 후 내부 이동 — 이 모든 단계는 예전부터 존재했습니다. AI가 손댄 것은 기법 그 자체가 아니라 그 기법을 얼마나 싸게, 빠르게, 적은 숙련도로 수행하느냐입니다. 그리고 바로 이 점이 신종 공격보다 훨씬 광범위한 파장을 만듭니다.

이유는 단순합니다. 지금까지 수많은 잠재 표적이 무사했던 건 방어가 튼튼해서가 아니라 공격할 만한 값어치가 없어서였습니다. 작은 표적 하나를 정밀하게 터는 데 드는 사람의 시간이, 거기서 건질 이득보다 컸기 때문에 그냥 지나쳤던 겁니다. 그런데 공격 비용이 0에 수렴하면 이 손익 계산이 통째로 뒤집힙니다. 건질 게 아무리 적어도 드는 비용이 더 적으면, 공격은 "합리적 선택"이 됩니다.

사람의 노동이라는 제동 장치

전통적으로 사이버 공격은 노동 집약 산업이었습니다. 표적을 파악하고, 빈틈을 찾고, 익스플로잇을 다듬고, 설득력 있는 미끼 메일을 쓰고, 침투한 뒤 내부를 훑는 모든 공정에 숙련된 사람의 시간이 들었습니다. 사람은 비싸고, 느리고, 한 번에 한 가지밖에 못 합니다. 이 비효율이 역설적으로 표적을 지키는 자연 방벽이었습니다.

이 방벽은 두 방향으로 작동했습니다.

작은 블로그, 동네 쇼핑몰, 병원 예약 시스템이 정밀 공격을 면했던 건 단단해서가 아니라 "남는 게 없어서"였습니다. AI가 사람 노동의 상당 부분을 대신하는 순간, 이 두 방벽이 동시에 낮아집니다.

한 문장으로 압축하면 이렇습니다. AI는 "정밀 공격의 대량 생산"을 가능하게 한다. 과거의 무차별 공격은 정밀하지 않아서 기본 방어로 막혔고, 과거의 정밀 공격은 대량이 아니어서 대부분의 표적이 비껴갔습니다. AI는 그 사이 빈칸 — 정밀하면서 동시에 대량인 공격 — 을 메웁니다. 그리고 그 빈칸이야말로 "값어치가 없어서" 안전했던 무수한 자산이 앉아 있던 자리입니다.

정찰: 표적 조사가 사람 손을 떠난다

공격의 첫 공정은 정찰입니다. 여기서 핵심 개념 하나. OSINT(Open-Source Intelligence, 공개정보 수집)는 해킹이 아닙니다. 웹사이트, 채용 공고, 검색 결과, 공개 코드처럼 누구나 볼 수 있는 정보만 그러모아 표적의 윤곽을 그리는 합법적 정보 수집입니다.

예전에는 표적을 깊게 파는 일이 통째로 수작업이었습니다. 조직도를 그리고, 핵심 인물을 골라내고, 그들의 공개 흔적을 모으고, 기술 스택을 추론하고, 약점을 짚는 일을 사람이 일일이 했습니다. 비용이 비싸니 깊은 정찰은 값나가는 소수 표적에만 투입됐습니다.

AI는 이 공정을 자동화하고 확장합니다. 회사 사이트, 채용 공고, 직원의 공개 프로필, 기술 블로그, 코드 저장소, 뉴스 기사를 빠르게 읽고 엮어서 표적의 구조화된 초상을 만들어 냅니다. 누가 급소인지, 무슨 기술을 쓰는지, 어디가 무를 법한지를 사람보다 압도적으로 빨리 추려 냅니다.

함의는 분명합니다. 정밀 정찰의 단가가 폭락합니다. "우리가 작은데 누가 그렇게까지 조사하겠어"라는 안도감이 깨지는 지점입니다. 조사하는 주체가 사람이 아니라 자동화 시스템이고, 그 시스템에게는 표적이 하나든 만 개든 비용 차이가 거의 없기 때문입니다.

방어: 공격자가 보는 화면을 나도 본다

정찰 자체를 원천 봉쇄할 수는 없습니다. 대신 노출되는 정보를 의식적으로 관리해 정찰의 수확량을 깎을 수 있습니다.

• 호스트명·도메인에 자산의 성격(예: admin-db, backup-old)을 그대로 드러내지 않기
• 코드 저장소에 API 키, 비밀번호, 토큰 같은 비밀 정보를 커밋하지 않기
• 블로그·발표 자료에 인프라의 구체적 약점을 친절하게 설명하지 않기

공격자가 덜 알수록 그들의 자동 분석도 빈약해집니다. 지금 당장 할 점검은 단순합니다 — 공격자가 보는 것을 나도 똑같이 보면 됩니다.

• 내 IP·도메인을 Shodan에 넣어 인터넷에서 노출된 서비스·포트 확인
• crt.sh에 도메인을 넣어, 발급된 인증서로부터 딸려 나오는 서브도메인 목록 점검

이 둘만으로도 "내가 밖에 뭘 흘리고 있는지"의 큰 그림이 잡힙니다.

취약점 탐색과 익스플로잇: 과장과 안일함 사이

취약점을 찾고 익스플로잇을 만드는 단계에서 AI의 영향은 특히 큽니다. 다만 여기서는 균형이 생명입니다.

코드 읽기의 가속

AI는 코드를 읽고 이해하는 데 강합니다. 이건 전형적인 양날의 검입니다. 방어자가 자기 코드에서 결함을 찾는 그 능력을, 공격자는 표적의 코드에서 결함을 찾는 데 그대로 씁니다.

공개된 소스, 유출된 코드, 클라이언트에 노출된 코드(웹 앱의 자바스크립트 번들 등)를 AI에게 던지면, 사람이 한 줄씩 훑는 것보다 훨씬 빨리 의심 구간을 추려 냅니다. 입력 검증이 빠진 곳, 인증이 없는 엔드포인트, 위험한 데이터 흐름을 빠르게 짚습니다. 핵심은 속도와 규모입니다. 숙련된 연구자 한 명이 한 달에 검토할 수 있는 코드 양은 한정돼 있지만, AI를 붙이면 그 한계가 크게 밀려납니다.

그리고 이건 내가 직접 쓴 코드만의 이야기가 아닙니다. 오늘날 거의 모든 웹 프로젝트는 수백 개의 오픈소스 의존성 위에 얹혀 있습니다. 2024년 xz-utils 백도어(CVE-2024-3094)는 신뢰받던 오픈소스 안에 악성 코드가 교묘히 심어진 공급망 공격의 교과서적 사례였습니다. 내가 안 짠 코드라도 결국 내 서버에서 돌면 내 위험입니다. 그래서 개발자가 둘 가장 실속 있는 한 수는 내가 끌어다 쓰는 패키지의 알려진 취약점을 자동으로 감시하는 것입니다.

• OSV — 오픈소스 취약점 데이터베이스
• GitHub Advisory — 보안 권고 DB
• 의존성 점검 도구를 CI 파이프라인에 상시 연결

익스플로잇 작성의 보조

취약점을 찾는 것과 그것을 실제로 동작하는 익스플로잇으로 만드는 것은 별개이며, 후자가 보통 더 어렵습니다. AI는 이 과정도 거듭니다. 알려진 취약점의 익스플로잇 초안을 뽑거나, 기존 코드를 특정 환경에 맞게 변형하거나, 막힌 부분을 우회하는 변종을 제안합니다.

여기서 침착할 필요가 있습니다. AI가 버튼 하나로 완성된 0-day 익스플로잇을 척척 찍어 내는 단계는 아직 아닙니다. 정교한 익스플로잇 개발에는 여전히 깊은 전문성과 손품이 듭니다. 그러나 AI는 진입 장벽을 낮추고 속도를 끌어올립니다. 특히 역량이 낮은 공격자에게 AI는 강력한 보조 도구이자 학습 가속기입니다. 운전 못 하던 사람에게 반자율주행을 쥐여 주는 격입니다 — 운전 실력 자체를 만들어 주진 않지만, 도달 거리는 확 늘려 줍니다.

진짜 위협은 0-day가 아니라 n-day

먼저 용어를 정리합시다.

• 0-day: 패치가 아직 없는, 세상에 알려지지 않은 취약점
• n-day: 이미 공개됐고 패치까지 나왔지만 당신이 아직 적용하지 않은 취약점
• CVE: 공개적으로 번호가 매겨진 보안 취약점

가장 현실적이고 즉각적인 위협은 0-day가 아니라 n-day입니다. 새 CVE가 공개되면, 그것을 실제 공격 가능한 익스플로잇으로 무기화하기까지 걸리는 시간 — 그 간격이 곧 방어자의 패치 골든타임입니다. AI는 이 무기화 시간을 단축합니다. 공개된 취약점 정보를 빠르게 분석해 익스플로잇을 빚어내는 속도가 빨라지면, 방어자가 손볼 시간은 그만큼 짧아집니다.

n-day가 왜 더 무서운지는 사례가 증언합니다.

• Log4Shell (CVE-2021-44228, Apache Log4j 원격 코드 실행): 2021년 말 터진 뒤 패치가 나오고도 수년간 악용됨
• Citrix Bleed (CVE-2023-4966): 패치가 분명히 있었는데 미적용한 곳들이 대규모로 털림

즉, 공격자가 노리는 건 대개 천재적인 0-day가 아니라 "패치를 안 한 당신"입니다. 지금 실제로 악용되고 있는 취약점 목록은 미국 CISA가 악용된 취약점 카탈로그(Known Exploited Vulnerabilities)로 공개합니다. 내가 쓰는 소프트웨어가 거기 올라와 있는지 한 번씩만 확인해도 우선순위가 또렷해집니다. AI가 무기화 속도를 더 당기면서 "공개 → 대량 악용" 사이의 간격은 해마다 짧아지는 중입니다.

방어의 함의는 직설적입니다. 무기화가 빨라졌다는 건 패치도 빨라져야 한다는 뜻입니다. "다음 정기 점검 때 올리지 뭐"라는 여유는 사라졌습니다. 자동화된 패치 관리와 신속 대응 체계가 선택이 아니라 필수가 됩니다. 그리고 방어 측도 똑같은 AI로 "이 새 CVE가 우리한테 영향을 주나?"를 즉시 판정해야 합니다.

소셜 엔지니어링: 가장 크고 즉각적인 변화

기술적 공격보다 사실 AI가 더 빠르고 넓게 흔든 영역이 따로 있습니다. 사람을 속이는 기술 — 소셜 엔지니어링입니다. 그리고 대부분의 조직에게 이것이 가장 현실적인 위협입니다.

피싱의 질적 도약

옛날 피싱 메일에는 들통날 단서가 많았습니다. 어색한 문법, 번역기 돌린 듯한 어투, 두루뭉술한 인사("고객님께"), 맥락 없는 본문. 보안 교육도 대체로 "이런 어색한 신호를 알아채라"는 식이었습니다.

AI는 그 단서들을 깨끗이 지웁니다. 이제 공격자는 완벽한 문법과 자연스러운 어조로, 표적의 언어·문화에 맞춰, 심지어 특정 조직의 내부 용어와 말투까지 흉내 낸 피싱을 대량으로 찍어 냅니다. 여기에 앞서 본 자동화된 정찰을 결합하면 표적 개인의 상황에 딱 맞는 맞춤형 미끼가 나옵니다. "지난주 참석하신 그 컨퍼런스 후속 자료입니다" 같은, 실제 맥락에 박혀 있는 메일 말입니다.

이게 바로 "정밀 공격의 대량 생산"의 가장 전형적인 모습입니다. 과거 스피어 피싱(특정인을 겨냥한 정교한 피싱)은 손이 많이 가서 값나가는 소수에게만 쓰였습니다. 이제는 그 정교함이 자동으로 대량 생산됩니다. 모든 직원, 모든 조직이 맞춤형 스피어 피싱의 사정권에 들어옵니다.

이게 공허한 경고가 아닌 이유는, 침해 원인을 추적한 통계가 한결같이 같은 곳을 가리키기 때문입니다. Verizon의 데이터 침해 조사 보고서(DBIR)는 해마다 침해의 상당 부분에 사람의 요소 — 피싱이나 도난당한 자격 증명 같은 사람을 통한 경로 — 가 끼어 있음을 반복해서 보여 줍니다. 기술적 0-day보다 "속아 넘어간 사람"이 훨씬 흔한 입구라는 뜻입니다.

딥페이크: 텍스트를 넘어선 위조

AI의 위조는 텍스트에 머물지 않습니다. 딥페이크(deepfake)로 특정 인물의 목소리와 얼굴까지 흉내 낸 가짜 음성·영상을 만듭니다.

공격에 쓰이는 방식은 노골적입니다. 상사 목소리를 흉내 낸 전화로 긴급 송금을 지시하고, 임원 얼굴로 위장한 화상 통화로 직원을 속이고, 신뢰하는 인물의 음성 메시지로 자격 증명을 요구합니다. 사람은 익숙한 목소리와 얼굴을 본능적으로 믿기 때문에 이런 공격은 무섭게 잘 먹힙니다.

특히 위험한 조합은 긴급성 + 권위입니다. "지금 당장, 평소 절차 건너뛰고 처리해 달라"는 요청이 신뢰하는 사람의 목소리로 날아오면, 평소라면 의심했을 사람도 압박 속에서 무너집니다.

방어: 직관이 아니라 절차로

소셜 엔지니어링 방어는 근본 재설계를 요구합니다. AI가 "어색함을 알아채라"는 기존 교육의 전제를 통째로 무너뜨렸기 때문입니다. 더는 메일이나 음성의 어색함에 기대 공격을 가려낼 수 없습니다.

해법은 개별 메시지의 진위를 사람이 판단하는 방식에서, 절차로 검증하는 방식으로 갈아타는 것입니다.

• 대역 외 확인(out-of-band verification) — 송금, 권한 변경, 자격 증명 제공 같은 민감 요청은 요청이 들어온 경로와 다른 경로로 반드시 재확인합니다. 메일로 송금 지시가 오면 메일로 답하지 말고, 알고 있는 번호로 직접 전화해 확인합니다. 음성으로 지시가 오면 사전에 약속한 다른 방법으로 검증합니다.
• 절차의 신성함 — "긴급하니 절차 건너뛰자"는 요청 그 자체를 위험 신호로 다루도록 교육합니다. 진짜 급한 상황이라도 검증 절차는 지켜져야 하며, 절차를 건너뛰라는 압박이야말로 공격의 전형적 지문입니다.
• 권위에 대한 건강한 의심 — 직위가 높은 사람의 비정상적 요청일수록 더 신중히 검증하는 문화를 만듭니다.
• 다단계 인증(MFA) — 자격 증명이 피싱으로 새도, 두 번째 인증 요소가 있으면 그것만으로는 못 들어옵니다. 다만 MFA 자체를 노리는 피싱도 있으니 피싱에 강한 방식(하드웨어 키 등)이 더 안전합니다.
• 발신자 위조 차단(이메일 인증) — 피싱의 절반은 "보낸 사람"이 진짜처럼 보이는 데서 시작합니다. 내 도메인을 사칭한 메일이 함부로 나가지 못하도록 SPF·DKIM·DMARC를 설정해 두면, "우리 회사 사칭 메일"의 상당수를 차단하거나 차단 표시할 수 있습니다. 지금 당장 MXToolbox로 내 도메인의 이메일 인증 설정이 제대로 되어 있는지 점검하세요.

이 방어들의 공통점은 사람의 직관에 의존하지 않는다는 것입니다. AI가 사람의 직관까지 속일 수 있게 된 시대에, 방어는 직관이 아니라 검증 가능한 절차 위에 서야 합니다.

침투 후 활동의 자동화

공격이 성공한 다음 단계에서도 AI의 손길이 보입니다. APT가 수행하는 거점 확보, 권한 상승, 측면 이동(lateral movement)은 침투 이후의 정교한 작전인데, 이 과정도 부분적으로 자동화될 수 있습니다.

침투한 시스템의 환경을 빠르게 분석해 다음 이동 경로를 찾고, 권한 상승 기회를 식별하고, 탐지를 피하는 방법을 조정하는 데 AI가 보조 역할을 합니다. 공격 속도가 빨라지고, 사람 공격자가 일일이 판단하던 몫이 줄어듭니다.

다만 이 영역은 앞선 단계들보다 자동화 성숙도가 낮습니다. 침투 후 활동은 환경마다 천차만별이고 정교한 판단을 요구하기 때문입니다. 그래도 방향성은 분명합니다. 시간이 갈수록 이 단계의 자동화도 발전할 것이고, 침해의 진행 속도는 빨라질 것입니다.

방어의 함의: 침투 후 활동이 빨라진다는 건 탐지와 대응의 속도가 더 중요해진다는 뜻입니다. 침해를 이미 일어난 일로 가정하고, 내부를 분할해 측면 이동을 어렵게 만들고, 모든 활동을 기록해 이상을 빠르게 포착하는 심층 방어(defense in depth)가 더욱 중요해집니다.

군비 경쟁: 방어자도 같은 무기를 든다

여기까지는 AI가 공격을 어떻게 키우는지였습니다. 그런데 이 이야기엔 반대편이 있습니다. 똑같은 AI가 방어자의 손에도 쥐어집니다. 공격이 자동화되면 방어도 자동화되어야 한다 — 이것이 핵심 원칙입니다.

비대칭의 재균형

공격 비용이 0에 수렴하는 비대칭은 분명 방어자에게 불리합니다. 그러나 방어자도 AI를 쓰면 그 비대칭의 일부를 되돌릴 수 있습니다. 방어자가 AI로 하는 일은 사실 공격자가 하는 일의 거울상입니다.

거창하게 들리지만 출발점은 무료 공개 도구 몇 개로 충분합니다.

• crt.sh — 도메인만 넣으면 발급된 인증서, 즉 잊고 있던 서브도메인 노출 확인
• SSL Labs — TLS 설정 등급 1분 점검
• securityheaders.com — 보안 헤더 상태 즉시 확인
• nuclei — 알려진 취약점 패턴을 내 자산에 먼저 돌려 보는 오픈소스 스캐너

여기에 AI를 얹으면 — 예컨대 스캔 결과를 정리해 "무엇부터 고칠지" 우선순위를 매기게 하면 — 혼자서도 꽤 넓은 면을 빠르게 훑을 수 있습니다.

현장에서 보면 정작 위험한 구멍은 대단한 게 아니라 "잊고 방치한 옛 서브도메인"이나 "끄는 걸 깜빡한 디버그 페이지"인 경우가 압도적으로 많습니다. 후자는 결코 사소하지 않습니다. Laravel을 쓴다면 디버그 모드(APP_DEBUG=true)를 운영 서버에 켜 둔 것이 실제 원격 코드 실행으로 이어진 CVE-2021-3129(Laravel Ignition) 같은 사례가 있습니다. AI 스캐너는 이런 "켜진 디버그 모드"를 사람보다 빠르고 지치지 않게 찾아냅니다 — 문제는 공격자 쪽에서도 똑같다는 것입니다.

핵심은 선제성입니다. 같은 취약점을 공격자보다 방어자가 먼저 찾으면, 그건 위협이 아니라 패치된 과거가 됩니다. AI는 방어자가 이 선제성을 규모 있게 확보하도록 돕습니다.

모델 발전 = 방어자의 재점검 신호

방어자에게 특별히 유리한 지점이 하나 더 있습니다. AI 모델은 계속 발전하고, 더 똑똑해진 모델은 같은 자산을 다시 봤을 때 이전엔 놓친 것을 새로 잡아냅니다.

이건 공격자에게도 마찬가지지만, 방어자가 더 체계적으로 써먹을 수 있습니다. 방어자는 자기 자산 전체에 완전한 접근 권한이 있고, 시간 압박 없이 차분히 들여다볼 수 있으며, 발견 즉시 고칠 수 있기 때문입니다. 공격자는 밖에서 단편적으로 엿보지만, 방어자는 안에서 전체를 봅니다.

그래서 권합니다. AI 모델이 새 버전으로 올라갈 때마다, 그것을 전체 보안 자산을 다시 점검하는 신호로 삼으세요. 더 똑똑해진 모델은 어제는 안 보이던 격차를 오늘 보여 줍니다.

만능 해법은 아니다

다만 "방어자도 AI 쓰면 되지"를 만능 치료제로 오해하면 안 됩니다. AI는 틀릴 수 있고, 민감 정보를 다룰 때 신중해야 하며, 사람의 검토를 대체하지 않고, 결코 유일한 방어선이 되어서는 안 됩니다.

올바른 자세는 이렇습니다. AI는 방어자가 더 많은 것을, 더 빠르게, 더 규모 있게 점검하도록 돕는 강력한 도구입니다. 그러나 그것은 공격면 축소, 접근 제어, 전송 계층 보안, 모니터링, 백업 같은 기본기 위에 더해지는 것이지 그것을 대체하는 것이 아닙니다. AI로 무장한 방어자라도 22번 포트가 인터넷에 활짝 열려 있고 비밀번호가 약하면 뚫립니다. AI는 잘 갖춰진 기본기를 증폭할 뿐, 없는 기본기를 만들어 내지는 않습니다.

결론: 과장도 안일함도 경계하며

다시 균형을 강조하며 마무리하겠습니다.

과장하지 마세요. AI가 모든 시스템을 즉시 해킹하는 마법은 아닙니다. 정교한 공격에는 여전히 전문성과 노력이 들고, 잘 갖춰진 기본 방어는 여전히 대부분의 공격을 막아 냅니다. 공포는 방어를 개선하지 못하고 오히려 마비시킵니다.

안일해하지도 마세요. AI는 공격의 경제학을 실제로 바꿨습니다. 정밀 공격의 대량 생산이 가능해졌고, "값어치가 없어서 안전했던" 표적들의 안전이 사라지고 있으며, 소셜 엔지니어링은 질적으로 도약했고, 무기화 속도는 빨라졌습니다. "본질은 안 변했다"는 안일함은 이 변화를 통째로 놓칩니다.

올바른 자세는 그 사이에 있습니다. AI는 공격의 속도·규모·접근성을 높였다. 그러므로 방어도 속도·규모·자동화를 높여야 한다. 더 빨리 패치하고, 더 넓게 점검하고, 직관이 아닌 절차로 검증하고, 방어자 자신도 AI를 도구로 삼되 그것을 기본기 위에 얹는 것 — 이게 전부입니다.

한눈에 보는 실행 체크리스트

자주 묻는 질문 (FAQ)

Q. 우리는 직원 몇 명짜리 작은 회사인데, 정말 AI 기반 공격의 표적이 될까요? 바로 그 "작아서 괜찮다"는 가정이 AI 시대에 가장 먼저 깨집니다. 과거에 작은 조직이 안전했던 건 방어가 튼튼해서가 아니라, 사람 공격자가 일일이 손대기엔 수지가 안 맞아서였습니다. 정찰·피싱·취약점 탐색이 자동화되면 표적이 하나든 만 개든 공격자에게 비용 차이가 거의 없어집니다. 규모가 작을수록 오히려 기본 방어(MFA, 패치, 노출 점검)에 먼저 집중하는 게 효율적입니다.

Q. 0-day와 n-day 중 무엇을 더 걱정해야 하나요? 압도적으로 n-day입니다. 0-day는 아직 알려지지 않은 취약점이라 무기화하려면 깊은 전문성이 필요하지만, n-day는 이미 패치까지 나왔는데 적용을 안 한 취약점이라 공격자 입장에서 "공짜로 굴러다니는" 셈입니다. Log4Shell(CVE-2021-44228)이나 Citrix Bleed(CVE-2023-4966)처럼 패치가 있었는데도 미적용으로 털린 사례가 현실의 대부분입니다. CISA의 악용된 취약점 카탈로그에 내 소프트웨어가 있는지부터 확인하세요.

Q. AI가 만든 피싱은 이제 어떻게 알아채나요? "어색함으로 알아챈다"는 접근 자체를 버려야 합니다. AI는 완벽한 문법, 자연스러운 어조, 심지어 사내 용어까지 흉내 내므로 메시지의 외형으로는 더 이상 구분이 안 됩니다. 대신 절차로 검증하세요. 송금·권한 변경 같은 민감 요청은 요청이 들어온 경로와 다른 경로(알고 있는 번호로 직접 전화 등)로 재확인하고, "긴급하니 절차를 건너뛰자"는 압박 자체를 위험 신호로 취급하면 됩니다.

Q. 방어에 AI를 쓰면 기존 보안 점검은 안 해도 되나요? 아닙니다. AI는 기본기를 증폭할 뿐 대체하지 않습니다. 22번 포트가 인터넷에 열려 있고 비밀번호가 약하면 아무리 AI로 무장해도 뚫립니다. 공격면 축소, 접근 제어, TLS, 모니터링, 백업 같은 기본기를 먼저 갖춘 다음, 그 위에 AI를 얹어 "공격자보다 먼저 같은 취약점을 찾는" 선제 점검에 활용하는 것이 올바른 순서입니다.

Q. 딥페이크 음성/영상 공격은 기술적으로 어떻게 막나요? 탐지 기술로 막으려 들면 끝없는 군비 경쟁에 빠집니다. 근본 해법은 기술이 아니라 절차입니다. 익숙한 목소리나 얼굴이라는 이유로 신뢰하지 말고, 금전·권한이 걸린 요청은 사전에 약속된 대역 외 경로로 반드시 재확인하는 규칙을 세우세요. 특히 직위가 높은 사람의 비정상적이고 긴급한 요청일수록 더 신중히 검증하는 문화가 가장 효과적인 방어입니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.