아 암튼 이해함, 작은 LLM으로도 제로데이를 발견한다는거..?

오늘 아침에 TLDR Infosec 까보다가 이 글 한 줄짜리 요약이 눈에 띄었다.

“System Over Model, Tested: Mythos, FreeBSD, and Local Open-Weight Models”

…

뭐라는 거임?

Mythos 가 뭐고 System Over Model 이 뭔 소리고 Local Open-Weight 가 또 뭐임?

OSCP 한답시고 보안 쪽은 좀 친해진 줄 알았는데 — 이거는 보안 + AI + 취약점 자동탐지 가 한꺼번에 들어가 있어서 단어 하나하나가 다 처음 본 거였다.

근데 한 번 끝까지 읽어봤더니 — 아 암튼 이해가 되긴했다.

읽으면서 머릿속에 정리된 거 그대로 풀어봄.

틀린 부분 있으면 몰라 네 말이 맞음.

---

일단 Mythos

Mythos = Anthropic 이 2026년 4월에 푼 프리뷰 모델이다.

이 친구가 화제가 된 게 — FreeBSD 의 RPCSEC_GSS 인증 코드에서 17년 묵은 RCE 0-day 를 찾아냈다는 거다. (CVE-2026-4747)

17년이다 17년. 17년 동안 안 보인 게 아니라, 17년 동안 사람들이 봤는데도 못 찾았던 거.

그걸 LLM 이 딸깍 하고 찾아냄.

이게 보안 업계에 좀 임팩트가 있었다.

이제 LLM 이 진짜 버그 찾네…?

하는 분위기.

근데 동시에 누구나 같은 생각을 함.

“근데 이거… Anthropic 같은 회사가 굴리는 프론티어 모델이라 가능한 거 아니야? 일반인이 굴리는 작은 모델로도 됨…?”

이 글의 저자 clearbluejar 형님이 그 의문을 그냥 안 넘기고 — 직접 실험을 해버렸다.

그래서 실험 어떻게 했냐

저자 분은 평소에 리버스 엔지니어링 + LLM 결합 도구 만드는 사람이다. 일단 진성.

이 분이 한 짓을 한 줄로 요약하면:

Mythos 가 썼던 AISLE 파이프라인을 그대로 가져와서, 소비자 GPU 에서 돌아가는 작은 오픈웨이트 모델로 같은 CVE 잡을 수 있나 돌려봄.

쓴 모델은 두 개.

모델	파라미터	비고
openai/gpt-oss-20b	200억	OpenAI 가 푼 오픈웨이트
google/gemma-4-31b-it	310억	Gemma 4

이 친구들로 FreeBSD sys/rpc/ 하위 50개 파일, 2만 줄 코드를 뒤지게 시킨 거다.

파이프라인 자체는 3단계.

1. Context briefing → 파일별로 공격면 매핑
2. Vulnerability scan → 분석 질문 5개 + 예시 던지고 뒤지게 함
3. Multi-round triage → 3번 평가시키고 다수결

(이 단계들의 정확한 디테일은 솔직히 한 번 더 읽어야 알 거 같다. 일단 “여러 단계로 쪼개서 LLM 한테 차례차례 시킨다” 정도로만 이해함. 아 암튼 이해함.)

---

1차 결과: 둘 다 똥쌈

모델	1차 결과
Gemma	스캔 단계에서 CVE 떨어트림. 있지도 않은 bounds check 가 있다고 환각함
GPT-OSS	트리아지까지는 갔는데 투표가 UNCERTAIN/VALID/UNCERTAIN 으로 갈려서 컷오프 미달

읽다가 “역시 작은 모델로는 안 되는구나~ 마무리겠네” 하고 스크롤 내릴 뻔했다.

근데 저자가 한 번 더 돌려봄.

알고 보니 노이즈였음.

음? 노이즈?

이 부분에서 한 번 더 멈췄다. 글에서는 그냥 “noise” 라고 툭 쓰고 넘어가는데 — 그거 의미가 정확히 뭐임?

좀 찾아보니까 의외로 별 거 아니였다.

LLM 은 같은 질문 줘도 매번 똑같이 답을 안 한다. temperature, top-p 같은 샘플링 파라미터가 있어서 — 확률적으로 다음 토큰을 고르는 구조다.

그래서 같은 코드, 같은 프롬프트로 돌려도 어떤 날은 CVE 잡고 어떤 날은 못 잡는다.

내가 평소에 Claude 한테 같은 질문 두 번 던졌을 때 답이 미묘하게 다른 거. 그게 그거다.

이게 “노이즈”.

즉, 1차 시도가 실패한 게 Gemma 가 못해서가 아니라 그날 운 나빴던 거임.

저자가 같은 Gemma 로 격리 환경에서 17번 돌려봤더니 — 17번 다 CVE 잡아냄.

“seventeen for seventeen”.

LLM 다루는 사람한테는 상식인 거 같은데, 나는 몰랐다.

한 번 돌려서 안 되면 그냥 한 번 더 돌려봐라. 너무 당연한데 너무 자주 까먹는 거.

근데 진짜 문제는 따로 있었음

여기서 글이 흥미로워진다.

CVE 자체는 잡는 게 되긴 함. 근데 — 알람이 너무 많이 울림.

Run 1 에서 “VALID 취약점” 으로 판정된 게 30개. 그 중 진짜는 딱 1개. 그것도 타겟 CVE 도 아닌 다른 거.

29 개가 false positive

이게 0-day 헌팅 자동화의 진짜 빌런이다. 시그널이 노이즈에 묻혀서 안 보임.

리서처가 “VALID 30개요” 라는 결과를 받았는데 그 중 어느 게 진짜인지 한 줄 한 줄 확인해야 하면 — 그냥 본인이 손으로 보는 게 더 빠르다. 자동화의 의미 사라짐.

그래서 저자가 어떻게 했냐.

”모델 ㄴㄴ 시스템 ㅇㅇ”

이게 글의 핵심이고 제목 자체다.

저자는 모델을 더 큰 거로 갈아끼우는 짓을 안 했다.

대신 — 파이프라인에 단계 하나를 더 끼워넣었다.

🔹 Reachability filter.

“이 취약점, 공격자가 진짜로 도달 가능한 경로에 있냐?” 를 한 번 더 검증하는 단계.

결과:

지표	Filter 전	Filter 후
Gemma “VALID” 개수	30개	5개
GPT-OSS “VALID” 개수	21개	4개
CVE 보존	운빨	5 run 연속 잡힘

알람이 6분의 1로 줄었는데 진짜 CVE 는 죽지 않고 살아남았다.

“Change the system, not the model.”

이 한 줄이 글의 결론이다.

그리고 비용 얘기는 좀…

저자가 끝에 흘리듯 던진 숫자.

이 실험 전체. 호스팅 엔드포인트 쓰면 약 $12. 로컬에서 돌리면 무료.

…

Mythos 급 프론티어 모델로 같은 실험 돌리면 한 자릿수 백 달러는 우습게 나간다.

근데 오픈웨이트 + 잘 짠 파이프라인이면 — 점심값으로 0-day 헌팅 자동화 한 사이클 돌릴 수 있다는 거다.

엥, 이거 이러면… 공격자만 좋은 거 아님?

그래서?

다시 말하지만 이 글 디테일까지 다 이해한 건 절대 아니다.

AISLE 가 정확히 뭘 하는지, reachability filter 를 어떻게 구현했는지, RPCSEC_GSS 의 취약점이 정확히 어떤 종류였는지.. 그냥 외계어였다.

근데 한 줄 메시지는 진짜 박혔다.

“모델 키우기 전에 시스템부터 다듬어라.”

이거 보안 리서치만의 얘기 아닌 거 같다.

요즘 AI 에이전트 만든다고 깔짝대는 1인 개발자들 다 똑같은 함정에 빠진다.

“결과 별로네? 더 큰 모델로 갈아끼우면 되겠지~ Opus 박아보자~” 식.

근데 진짜 차이는 스캐폴딩 에서 난다는 거.

컨텍스트 어떻게 던지고, 단계 어떻게 쪼개고, 결과 어떻게 검증하고, false positive 어떻게 거르고.

이건 Mythos 든 Gemma 든 GPT 든 다 똑같이 적용되는 레버다.

그래서 더 쳐다볼 만한 가치가 있는 거고.

마치며

암튼 결론은 — 모델 키울 돈 없어도 파이프라인 잘 짜면 0-day 잡을 수 있다.

시간 나면 한 번 따라 해봐야지. <- 안 할 확률 28000%

암튼, 뭐… 지식 +1

마침.