"유능한 AI가 흔해지면 보안에서 무엇이 바뀌는가?" 답은 의외로 평범하다: 특별한 새 통제 수단이 필요한 게 아니라, 평범한 기본기를 지금 하는 것의 가치가 올라간다. 그 이유와, 다잡을 순서를 정리한다(방어 관점, 공격 절차 없음).
왜 지금인가
AI는 공격을 만들어내기보다 주로 증폭한다. 방어 관점에서 다음 다섯 방향을 주시하라(알아둬야 할 일반적 추세 — 구체적 방법은 없음):
공통점: 각각이 평범한 기본적 약점을 통해 침입한다. 그러니 기본기를 다잡을수록, 대규모 공격조차 침입에 실패하게 된다. 미뤄둔 기본적 빈틈은 자동화된 공격이 가장 먼저 찾는 것이다. 그래서 지금 중요하다.
숫자도 이를 뒷받침한다. Mandiant(Google Cloud)에 따르면 취약점 공개부터 악용까지의 평균 기간은 2021~2022년의 32일에서 2023년에는 5일로 줄었다. 영국 국가사이버보안센터(NCSC)도 2024년 1월, AI가 앞으로 2년 동안 사이버 공격의 양을 "거의 확실히" 늘릴 것이라고 평가했다. 한 달에 한 번 업데이트하는 습관으로는 늦을 때가 있다.
이 순서로 다잡아라 (우선순위 체크리스트)
위에서 아래로. 각 항목은 본 사이트의 상세 가이드로 연결된다.
의존성 CVE를 모니터링하고 빠르게 패치
노출된 시크릿 파일 제거
최소 권한으로 침해 시 피해를 줄인다
공개 표면 축소, 위조 차단
의존성과 Git 강화
백업과 복구를 갖추라
한눈에 보는 표: 빈도와 도구
위의 여덟 항목을, 먼저 할 일과 그 뒤의 빈도로 나눴다. 빈도는 본 사이트가 권하는 기준이다.
| 항목 | 먼저 할 일 | 그 뒤의 빈도 | 도구(대부분 무료) |
|---|---|---|---|
| 1. 의존성 취약점 | 모든 프로젝트의 의존성을 한 번 스캔한다 | 매주, 또는 코드가 바뀔 때마다 자동으로 | osv-scanner, npm audit, composer audit, GitHub Dependabot 알림 |
| 1. 패치 기한 | 악용이 확인된(KEV에 있는) 취약점부터 패치한다 | KEV 항목은 며칠에서 2주 이내 | CVSS, EPSS, KEV로 우선순위 정하기 |
| 2. 다중 인증 | 이메일, GitHub, 클라우드, 도메인 관리의 관리자 계정부터 | 계정을 만들 때마다 | 패스키, 인증 앱 |
| 3. 노출된 시크릿 | 공개 디렉터리와 공개 리포지토리를 점검하고, 찾은 키는 폐기한다 | 릴리스할 때마다 | 시크릿 유출 스캐너, 사이트 점검 |
| 4. 최소 권한 | 쓰지 않는 키, 토큰, 계정을 비활성화한다 | 3개월마다 | 각 서비스의 액세스 토큰 목록 |
| 6. Git 방어 | 커밋 전에 시크릿을 막는 점검을 추가한다 | 자동(커밋마다) | gitleaks, GitHub 푸시 보호 |
| 8. 백업 | 다른 곳에 사본을 두고 한 번 복원해 본다 | 3개월마다 복원 시험 | 제공업체의 스냅샷, 외부 저장소 |
GitHub 푸시 보호는 개인 계정이 공개 리포지토리에 푸시할 때 기본으로 켜져 있다. 비공개 리포지토리나 다른 Git 서비스는 대상이 아니므로, gitleaks 같은 로컬 점검과 함께 쓴다.
흔한 실수와 고치는 법
| 흔한 실수 | 일어나는 일 | 고치는 법 |
|---|---|---|
| 업데이트 알림을 받고 적용됐는지 확인하지 않는다 | 수정판이 있는데도 구멍이 열린 채로 남는다 | 업데이트 뒤 버전을 확인하고 스캔을 다시 돌린다 |
| 유출된 키를 파일과 이력에서 지우고 끝낸다 | 폐기하지 않으면 사본을 가진 누구나 계속 쓸 수 있다 | 먼저 발급처에서 폐기하고, 새 키로 바꾼다 |
| 자기 계정에만 MFA를 켠다 | 공유 관리자 계정이나 오래된 계정으로 들어온다 | 관리자 권한이 있는 계정을 모두 나열하고 전부 켠다 |
| 백업을 같은 서버에 둔다 | 서버가 고장 나거나 암호화되면 백업도 함께 잃는다 | 다른 곳에 두고 실제로 복원을 시험한다 |
| AI가 작성한 설정이나 코드를 그대로 운영 환경에 올린다 | 디버그 출력이나 하드코딩된 시크릿이 남는다 | 릴리스 전에 시크릿 탐지와 의존성 스캔을 돌린다 |
실제 사례
본 사이트를 시작하게 한 사고가 전형적인 예다. AI가 작성한 코드를 출시한 직후 API 키가 탈취되었고, 이어 부정 과금이 발생했다. 원인: 공개된 최고 등급 CVE(CVSS 10.0)가 몇 달간 패치되지 않은 채 방치됨. AI가 패치되지 않은 약점의 대가를 키운 구체적 사례다(→ AI 코드 API 키 유출 사례).
같은 유형의 사례는 그 밖에도 있다.
- Equifax(2017년): Apache Struts 결함의 수정판은 공개 당일에 나왔지만 공개 시스템에 적용되지 않았고, 약 1억 4,700만 명의 개인정보가 유출됐다. 항목 1을 건너뛰면 이렇게 된다(→ Equifax 유출 사고).
- Hugging Face(2026년): 연구용 AI 에이전트에 의한 침입은 공개적으로 노출되어 있던 자격 증명에서 시작됐다. 항목 3을 건너뛰면 이렇게 된다(→ Hugging Face 침입).
본 사이트의 견해: AI는 패치되지 않은 약점의 대가를 키운다. 그러니 기본기를 지금
본 사이트에서는 AI 시대 대비를 특별한 새 통제 수단을 더하는 것이 아니라, 기본기를 더 일찍 하는 것으로 본다. 유능한 AI가 공격자 손에 들렸을 때 가장 도움이 되는 것은 제로데이 발명이 아니라, 미뤄둔 기본기(패치 안 됨, 재사용됨, 노출됨)를 값싸게 대규모로 찾아내 노리는 것이다. 그러니 효과가 있는 것은 지루한 기본기를, 올바른 순서로, 지금 하는 것이다. 사이트 보안 점검, 이메일 인증 점검기, 의존성 스캐너로 자기 사이트를 확인하라. 설정만으로는 부족하다. 검증해야 비로소 작동한다.
출처
- Google Cloud(Mandiant), "How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends" — cloud.google.com
- UK NCSC, "The near-term impact of AI on the cyber threat"(2024년 1월 24일) — ncsc.gov.uk
- US CISA, "BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities" — cisa.gov
- GitHub Docs, "About push protection" — docs.github.com
다음으로 읽기
- AI 에이전트 침입: Hugging Face 침입(2026년): 자율 AI 에이전트에 의한 공격
- 흔한 오해: AI 시대 보안에서 통하는 것(과 통하지 않는 것)
- 기준선: 보안 기준선 체크리스트
- 도구: 사이트 보안 점검
- 업무의 AI 사용 관리: 섀도 AI란?(회사가 승인하지 않은 AI 도구와 대처법)