AI Slop의 역설: 취약점을 더 잘 찾는 시대에 triage가 더 어려워지는 이유

AI는 취약점 발견 비용을 낮추지만, 동시에 취약점 후보를 만드는 비용도 거의 0에 가깝게 낮춘다. 그래서 AI 시대의 병목은 탐지보다 선별, 즉 triage로 이동한다.

여기서 triage는 들어온 취약점 후보를 모두 같은 깊이로 검증하지 않고, 먼저 분류하고 우선순위를 정하는 과정이다. 병원 응급실에서 환자를 위중도에 따라 먼저 나누듯, 보안 운영에서도 후보를 조치 대상, 사람 검증 대상, 모니터링 대상, 보류 또는 폐기 대상으로 빠르게 나눠야 한다.

이 글은 CVE 이후의 보안 시리즈의 두 번째 글이다.

• 1편: CVE 이후 대응만으로는 늦다: AI 시대 취약점은 번호가 붙기 전에 움직인다
• 2편: AI Slop의 역설: 취약점을 더 잘 찾는 시대에 triage가 더 어려워지는 이유
• 3편: 보안진단은 외주 업무가 아니라 개발 공정이 된다
• 4편: 공급망 보안은 SBOM만으로 끝나지 않는다: AI 개발 도구와 자동화 연결 관리

이전 글에서는 CVE/NVD 중심 대응만으로는 충분하지 않은 이유를 다뤘다. 이번 글에서는 그 변화의 반대편, 즉 AI가 만드는 노이즈와 triage 비용을 다룬다.

1. AI는 취약점을 더 많이 만든 것이 아니라, 취약점 후보를 더 많이 만든다

AI 기반 취약점 연구를 이야기할 때 흔히 한쪽만 본다.

AI가 더 많은 취약점을 찾는다.
AI가 exploit을 재현한다.
AI가 patch diff를 분석한다.
AI가 공격자의 시간을 줄인다.

이 말들은 중요한 변화다. 그러나 이것만 보면 절반만 보는 것이다.

AI는 진짜 취약점만 늘리지 않는다. 취약점처럼 보이는 후보도 늘린다. 중복 신고도 늘린다. 잘못된 위협 모델도 늘린다. 실제로는 exploit이 불가능한 PoC도 늘린다. 취약점 이름은 그럴듯하지만, 운영 환경에서는 영향이 없는 보고서도 늘린다.

즉, AI는 취약점 발견 비용을 낮추는 동시에 취약점 후보 생성 비용을 거의 0에 가깝게 낮춘다.

이 차이가 중요하다.

운영자는 취약점만 처리하는 것이 아니다. 취약점 후보를 선별해야 한다.

2. 탐지보다 선별이 병목이 된다

보안 자동화의 오래된 꿈은 이렇다.

더 많이 스캔한다 → 더 많이 찾는다 → 더 안전해진다

하지만 실제 운영에서는 중간에 빠진 단계가 있다.

더 많이 스캔한다 → 더 많이 나온다 → 더 많이 선별해야 한다 → 병목이 생긴다

취약점 후보가 10개일 때는 하나씩 읽어볼 수 있다. 100개일 때는 우선순위가 필요하다. 1,000개가 되면 프로세스가 필요하다. 10,000개가 되면 조직 구조가 필요하다.

AI는 이 숫자를 빠르게 키운다.

문제는 보안팀의 검토 시간, 메인테이너의 정신적 에너지, 개발팀의 대응 여력은 같은 속도로 늘지 않는다는 점이다.

AI 시대의 병목은 탐지가 아니라 triage다.

즉 triage는 취약점을 덜 보겠다는 뜻이 아니다. 제한된 검증 시간을 실제 위험이 큰 후보에 먼저 쓰기 위한 운영 절차다.

그림. 모든 후보에 같은 검토 깊이를 적용하면 방어선이 무너진다. 먼저 내부 사용 여부, 외부 노출, PoC와 패치 존재, 실제 공격 난이도로 걸러야 한다.

3. AI Slop은 왜 위험한가

AI slop은 단순히 품질 낮은 결과물을 뜻하지 않는다. 보안 운영에서는 더 구체적인 의미를 갖는다.

AI slop은 다음과 같은 형태로 나타난다.

• 실제로는 취약점이 아닌데 취약점처럼 보이는 보고서
• 영향 조건이 빠진 PoC
• 패치된 버전에만 해당하는 잘못된 분석
• 내부 전제와 맞지 않는 공격 시나리오
• CVSS만 높고 exploitability가 낮은 항목
• 같은 문제를 여러 표현으로 반복한 중복 신고
• 코드 조각만 보고 전체 컨텍스트를 오해한 판단
• 존재하지 않는 함수나 설정을 근거로 한 hallucination

이런 항목은 하나하나가 치명적이지 않을 수 있다. 그러나 양이 많아지면 취약점 공개 인프라와 보안 운영을 갉아먹는다.

메인테이너는 진짜 취약점을 찾는 데 시간을 쓰지 못한다. 보안팀은 false positive를 닫느라 중요한 패치를 놓칠 수 있다. 개발팀은 보안 알림을 신뢰하지 않게 된다.

결국 AI slop의 가장 큰 피해는 신뢰의 붕괴다.

4. 취약점 신고 생태계의 비용 전가

AI로 취약점 후보를 만드는 비용은 낮아진다.

하지만 그 후보가 진짜인지 확인하는 비용은 사라지지 않는다. 오히려 누군가에게 전가된다.

• 오픈소스 메인테이너가 읽는다.
• 보안팀이 검증한다.
• 개발팀이 재현한다.
• 제품팀이 영향도를 판단한다.
• 운영팀이 패치 가능성을 검토한다.

AI를 사용한 신고자는 몇 분 만에 보고서를 만들 수 있다. 그러나 그 보고서를 받는 쪽은 몇 시간, 며칠을 써야 할 수 있다.

이것이 AI 취약점 신고의 비대칭성이다.

공격자는 AI로 비용을 낮추고, 방어자는 검증 비용을 떠안는다.

5. 모든 항목을 같은 방식으로 처리하면 진다

AI slop이 늘어나는 환경에서 가장 위험한 운영 방식은 모든 취약점 후보를 같은 방식으로 처리하는 것이다.

동일한 SLA, 동일한 검토 깊이, 동일한 보고서 양식, 동일한 승인 절차를 적용하면 보안팀은 금방 소모된다.

따라서 취약점 후보는 처음부터 분류되어야 한다.

예를 들면 다음 기준이 필요하다.

이 기준은 완벽하지 않다. 하지만 모든 항목을 동일한 줄에 세우는 것보다는 낫다.

Triage는 취약점 후보를 버리는 과정이 아니다.

제한된 검증 능력을 실제 위험이 큰 곳에 먼저 배치하는 과정이다.

6. AI가 만든 후보를 AI로만 검증할 수는 없다

여기서 유혹이 생긴다.

AI가 후보를 많이 만들면, AI로 다시 검증하면 되지 않을까?

부분적으로는 맞다. AI는 다음 작업에 도움이 된다.

• 보고서 요약
• 중복 후보 묶기
• 관련 commit 찾기
• 내부 SBOM과 매핑
• PoC의 전제 조건 정리
• 취약점 유형 분류
• 재현 절차 초안 작성
• 개발팀 전달용 이슈 초안 작성

하지만 AI가 최종 판단까지 대체하기는 어렵다.

왜냐하면 보안 판단에는 코드 사실만 있는 것이 아니기 때문이다.

• 이 API는 실제로 외부에서 접근 가능한가?
• 인증 게이트웨이 전제가 깨질 수 있는가?
• 이 데이터는 회사 기준에서 민감정보인가?
• 이 서비스는 장애 허용도가 낮은가?
• 패치를 지금 적용하는 것이 더 위험한가?
• 임시 차단이 비즈니스에 미치는 영향은 무엇인가?

이 질문들은 단순 탐지가 아니라 맥락 판단이다.

AI는 보조할 수 있다. 그러나 책임을 질 수는 없다.

7. Triage도 구조화되어야 한다

AI slop이 늘어난다고 해서 사람을 더 많이 붙이는 방식만으로는 버티기 어렵다.

필요한 것은 triage의 구조화다.

나는 다음과 같은 흐름이 현실적이라고 본다.

후보 수집
→ 중복 제거
→ 내부 사용 여부 확인
→ 노출 여부 확인
→ exploitability 1차 평가
→ 자동 재현 가능성 검토
→ 사람 검증 대상 선정
→ 조치/보류/모니터링 분류

이 과정에서 AI는 좋은 도구가 될 수 있다. 그러나 AI가 잘 작동하려면 입력이 구조화되어야 한다.

• SBOM이 있어야 한다.
• 자산 목록이 있어야 한다.
• 외부 노출 정보가 있어야 한다.
• API 목록이 있어야 한다.
• 배포 경로가 있어야 한다.
• 과거 취약점 이력이 있어야 한다.
• 예외 승인 기준이 있어야 한다.

구조가 없으면 AI는 더 많은 텍스트를 만든다. 구조가 있으면 AI는 반복 검증을 줄인다.

그림. triage는 후보를 없애는 절차가 아니라, 노출도와 악용 가능성의 교차점에 따라 조치, 일정화, 완화, 보류 대상을 나누는 운영 구조다.

8. 보안팀의 역할은 더 중요해진다

AI slop의 시대에 보안팀의 역할은 줄어들지 않는다.

오히려 바뀐다.

과거의 보안팀이 취약점을 직접 찾는 데 많은 시간을 썼다면, 앞으로의 보안팀은 다음 역할을 더 많이 맡게 된다.

• 어떤 신호를 수집할지 정한다.
• 어떤 후보를 버릴지 기준을 만든다.
• 어떤 항목을 사람 검증으로 올릴지 판단한다.
• AI가 만든 결과의 품질 기준을 정한다.
• 개발팀이 받아들일 수 있는 형태로 결과를 표준화한다.
• 반복 가능한 triage 파이프라인을 설계한다.
• 최종 위험 판단과 예외 승인 구조를 운영한다.

즉, 보안팀은 단순 진단자에서 triage 시스템의 설계자이자 운영자로 이동한다.

이 변화는 다음 글의 주제와 연결된다.

보안진단은 더 이상 건별 외주 업무로 남기 어렵다. 개발과 공격의 속도가 동시에 빨라진다면, 보안진단은 개발 공정 안에 반복 가능한 통제로 들어가야 한다.

9. 결론: AI 시대의 핵심 능력은 선별이다

AI는 취약점 발견을 빠르게 만든다.

하지만 보안 운영에서 더 중요한 변화는 이것이다.

AI는 취약점 후보를 폭증시키고, 그 후보를 선별하는 비용을 방어자에게 넘긴다.

따라서 AI 시대의 취약점 대응은 더 많은 스캔을 돌리는 문제가 아니다.

더 빨리 선별하고, 더 정확히 검증하고, 더 책임 있게 조치하는 구조를 만드는 문제다.

이 글의 산출물은 모든 취약점 후보를 같은 줄에 세우지 않고, 내부 사용 여부, 노출 여부, exploitability, 신뢰도를 기준으로 먼저 줄이는 triage 기준이다.

다음 글에서는 이 문제를 내부 운영 모델로 가져간다.

보안진단은 외주 업무인가, 아니면 개발 프로세스 안에 들어가야 할 반복 통제인가.

이 질문으로 넘어가기 전에, 이 글의 결론은 분명하다. AI 시대의 보안 운영은 후보를 더 많이 만드는 능력만으로 좋아지지 않는다. 후보를 줄이고, 묶고, 버리고, 사람 검증으로 올릴 대상을 정하는 능력이 있어야 한다. 앞으로의 경쟁력은 탐지량이 아니라 triage 품질에서 갈린다.

FAQ

Q1. AI slop이란 AI가 만든 모든 보안 보고서를 뜻하나?

아니다. AI가 만든 결과 중 근거가 약하거나, 재현 조건이 부정확하거나, 실제 영향이 없는 저품질 취약점 후보를 말한다. AI 보조 연구 자체가 문제라는 뜻은 아니다.

Q2. 그럼 AI 기반 취약점 신고는 무시해야 하나?

아니다. 무시가 아니라 선별이 필요하다. 내부 사용 여부, 노출 여부, exploitability, 신뢰도, 중복 여부를 기준으로 먼저 분류해야 한다.

Q3. triage를 AI로 자동화하면 되지 않나?

일부는 가능하다. 중복 제거, 요약, 관련 commit 탐색, SBOM 매핑은 AI가 도울 수 있다. 하지만 최종 영향도 판단, 예외 승인, 조치 우선순위 결정은 여전히 사람의 책임이 필요하다.

다음 편: 보안진단은 외주 업무가 아니라 개발 공정이 된다