AI로 보안 취약점 점검을 할 수 있나요?
할 수 있지만, 사람이 하던 점검을 넓히고 빠르게 만드는 보조 수단으로 쓸 때 효과가 큽니다. 지금 실무에서 AI가 맡는 일은 크게 네 가지입니다.
| 작업 | AI가 하는 일 | 사람이 해야 하는 일 |
|---|---|---|
| 코드 리뷰 보조 | 변경 코드에서 인젝션, 인증 누락 같은 패턴 지적 | 실제 공격 가능 여부 판단 |
| SAST·DAST 결과 분류 | 경고를 묶고 설명하며 오탐 후보 표시 | 최종 오탐 판정 |
| 퍼징 보조 | 퍼징 대상 코드(fuzz target) 작성 | 크래시 분석, 영향 평가 |
| 수정안 제안 | 패치 코드 초안 작성 | 회귀 테스트, 병합 승인 |
SAST(정적 분석)는 코드를 실행하지 않고 소스를 읽어 위험한 패턴을 찾고, DAST(동적 분석)는 실행 중인 서비스에 요청을 보내 반응을 봅니다. 두 도구 모두 경고가 많이 나오고 그중 상당수가 실제로는 문제가 아닌 오탐이라, 사람이 분류하는 데 시간이 가장 많이 듭니다. LLM이 가장 먼저 쓸모를 보이는 지점이 바로 이 분류와 설명입니다.
지금 AI 취약점 탐지는 어디까지 왔나요?
공개된 사례만 봐도 실제 오픈소스에서 사람이 놓친 취약점을 찾아낸 단계까지 왔습니다. 주요 발표를 시간순으로 정리하면 다음과 같습니다.
- Google OSS-Fuzz(2024년 11월): LLM으로 퍼징 대상 코드를 생성해 26개 취약점을 찾았다고 밝혔습니다. 여기에는 OpenSSL의 CVE-2024-9143이 포함되며, 구글은 이 결함이 약 20년 동안 남아 있었고 사람이 작성한 퍼징 코드로는 찾기 어려웠을 것이라고 설명했습니다.
- Google Big Sleep(2025년 7월): 딥마인드와 Project Zero가 만든 AI 에이전트가 SQLite의 CVE-2025-6965를 찾았습니다. 구글은 위협 정보와 결합해 악용 직전의 취약점을 먼저 막았고, AI 에이전트가 실제 악용 시도를 직접 저지한 첫 사례라고 발표했습니다.
- DARPA AIxCC 결선(2025년 8월): 자동으로 취약점을 찾고 고치는 시스템을 겨루는 대회에서, 참가 시스템들은 주입된 가상 취약점 63개 중 54개를 찾고 43개를 패치했습니다. 이와 별개로 실제 버그 18건도 발견했습니다. 우승은 삼성리서치, KAIST, POSTECH, 조지아공대 연구진이 참여한 Team Atlanta였습니다.
- GitHub Copilot Autofix(2024년 8월 정식 출시): CodeQL이 찾은 경고에 대해 수정 코드를 제안합니다. 2024년 9월부터 모든 공개 저장소에서 무료로 쓸 수 있습니다.
- OpenAI Aardvark → Codex Security: 2025년 10월 비공개 베타로 공개된 보안 연구 에이전트가 2026년 3월 Codex Security라는 이름의 연구 프리뷰로 바뀌었습니다.
- Anthropic Claude Code Security(2026년 2월): 코드베이스를 분석해 취약점과 패치를 제안하는 기능을 연구 프리뷰로 공개했습니다. 오픈소스 코드에서 500건 이상의 취약점을 찾았다고 밝혔으며, 모든 수정은 사람의 승인 없이 적용되지 않는다고 명시했습니다.
공통점은 하나입니다. 어느 발표도 "AI가 알아서 고친다"고 하지 않고, 찾고 제안하는 것까지가 AI, 판단과 승인은 사람이라는 구조를 유지합니다.
AI 점검의 한계는 무엇인가요?
가장 큰 한계는 환각, 미탐, 코드 반출 세 가지입니다.
그럴듯한 가짜 취약점
LLM은 존재하지 않는 함수 호출이나 재현되지 않는 공격 경로를 확신에 찬 문장으로 설명할 수 있습니다. curl 프로젝트의 다니엘 스텐베리는 AI로 만든 것으로 보이는 허위 보고가 쏟아지면서 확인된 취약점 비율이 과거 15% 이상에서 2025년 5% 미만으로 떨어졌다고 밝혔고, 2026년 1월 31일 버그바운티를 종료했습니다. 검증 없이 AI 결과를 그대로 넘기면 받는 쪽의 시간을 소모시킨다는 사례입니다.
놓치는 취약점
AI가 아무것도 찾지 못했다고 해서 안전하다는 뜻은 아닙니다. 결제 금액 조작, 다른 사용자 데이터 조회 같은 비즈니스 로직·권한 취약점은 서비스 맥락을 알아야 판단할 수 있어 코드 일부만 보는 모델이 놓치기 쉽습니다.
소스코드 외부 반출
외부 AI 서비스에 저장소를 올리는 순간 코드는 회사 밖으로 나갑니다. 고객사 계약에 비밀유지 조항이 있거나 코드에 개인정보·키가 섞여 있다면 문제가 됩니다. 이 경우 사내 서버에서 돌리는 로컬 모델이 대안입니다. 성능은 최상위 상용 모델보다 낮을 수 있지만, 오탐 분류나 코드 설명처럼 범위가 좁은 작업에는 충분히 쓸 만합니다. 구성 방법은 로컬 LLM 구축 가이드에 정리해 두었습니다.
AI 도구에 저장소 전체를 넘기기 전에 .env, 인증서, 테스트용 실데이터가 커밋돼 있지 않은지 먼저 확인하세요. 비밀값 스캔은 AI 점검보다 앞 단계에 둬야 합니다.
실제로 도입하려면 어떤 순서로 하나요?
기존 도구로 바닥을 깔고, AI는 그 위에 얹는 순서가 안전합니다.
- 1기준선 만들기: SAST, 의존성 취약점 점검(SCA), 비밀값 스캔을 CI에 붙입니다. 이 단계는 AI 없이도 됩니다.
- 2데이터 반출 기준 정하기: 어떤 저장소를 외부 AI에 보낼 수 있는지, 어떤 저장소는 로컬 모델만 쓸지 정합니다.
- 3분류부터 맡기기: 쌓인 경고를 AI가 묶고 설명하게 하고, 사람이 오탐 여부를 최종 판정합니다. 판정 결과는 기록해 두면 다음 분류의 기준이 됩니다.
- 4수정안은 PR로만 받기: AI가 만든 패치는 반드시 PR로 올리고 테스트와 리뷰를 거쳐 병합합니다.
- 5주기적인 사람 점검 병행: 큰 기능 출시 전이나 연 1회 정도는 사람이 권한 구조와 업무 흐름을 따라가며 점검합니다.
- 점검 결과마다 재현 절차가 있는가
- AI가 낸 결과와 사람이 확정한 결과를 구분해 기록하는가
- 외부 AI로 보낸 코드 범위를 설명할 수 있는가
- 자동 수정이 사람 승인 없이 병합되지 않는가
미라클스튜디오는 재하청 없이 자체 팀이 직접 점검과 수정을 함께 진행하고, 코드 반출이 어려운 환경에서는 로컬 LLM을 사내망에 구성해 점검할 수 있습니다. 범위는 AI 보안 페이지에서 확인하실 수 있습니다.
AI 점검을 개발 흐름에 붙이고 싶은데 어디서부터 시작할지 막막하시다면, 미라클스튜디오 30분 무료 상담에서 현재 저장소 구조에 맞는 순서를 함께 정리해 드립니다.
참고 자료
- Leveling Up Fuzzing: Finding more vulnerabilities with AI - Google Security Blog
- Google’s latest AI security announcements - Google
- AI Cyber Challenge marks pivotal inflection point for cyber defense - DARPA
- Copilot Autofix for CodeQL code scanning alerts is now generally available - GitHub
- Introducing Aardvark - OpenAI
- Codex Security: now in research preview - OpenAI
- Making frontier cybersecurity capabilities available to defenders - Anthropic
- The end of the curl bug-bounty - Daniel Stenberg
