AI가 curl에서 진짜 취약점을 찾았다 — Mythos가 보여준 가능성과 한계

curl 메인테이너가 직접 쓴 글

curl이라는 프로젝트를 모르는 분은 거의 없을 거예요. HTTP 요청을 다루는 거의 모든 시스템 어딘가에 들어 있고, 자동차, 냉장고, 우주선까지 쓴다고 농담할 정도로 깔려 있는 라이브러리죠. 그 curl을 30년 가까이 이끌고 있는 메인테이너 Daniel Stenberg가 흥미로운 글을 하나 올렸어요. 제목이 "Mythos가 curl에서 취약점을 찾았다"인데요, 여기서 Mythos는 AI 기반 보안 취약점 탐지 도구예요.

그동안 Daniel은 AI가 제출하는 "curl에 취약점이 있어요" 보고서들에 꽤 강한 짜증을 표현해왔어요. HackerOne 같은 버그 바운티 플랫폼에 LLM이 만들어낸 그럴듯하지만 완전히 가짜인 보고서들이 쏟아져 들어와서, 메인테이너의 시간을 갉아먹는 "AI slop" 문제가 심각했거든요. 그런데 이번에는 달랐어요. Mythos가 진짜로 동작하는 진짜 취약점을 찾아냈고, 그게 패치까지 이어진 사례거든요.

AI가 코드 취약점을 어떻게 찾을까

Mythos 같은 도구들이 어떻게 동작하는지 짧게 설명할게요. 전통적인 정적 분석 도구(Coverity, CodeQL 같은)는 미리 정의된 "패턴"을 코드에서 찾아요. "여기서 strcpy 쓰는데 길이 체크 안 했네" 같은 식이죠. 빠르고 안정적이지만, 패턴에 안 맞는 새로운 종류의 취약점은 못 잡아요.

AI 기반 도구는 좀 달라요. LLM이 코드 전체를 읽으면서 "여기서 이런 입력이 들어오면 어떻게 흘러갈까?" 를 사람처럼 추론해요. 그리고 의심스러운 흐름을 발견하면 실제로 그 입력을 만들어서 동작시켜보는 검증(verification) 단계까지 자동화하죠. 이게 잘 되면 사람 보안 연구자가 며칠 걸려서 찾을 만한 버그를 몇 시간에 찾아낼 수 있어요. 안 되면? 환각(hallucination)으로 가짜 보고서를 양산하죠. Mythos가 다른 점은 "검증 단계"를 엄격하게 두어서 가짜 보고서 비율을 낮춘 거예요.

Daniel이 평가한 "좋은 AI 보고서"의 조건

Daniel이 글에서 강조한 부분이 흥미로워요. AI가 찾은 취약점이라도 메인테이너 입장에서 받아들일 만한 보고서가 되려면 몇 가지 조건이 있어요. 우선 재현 가능한 PoC(Proof of Concept) 코드가 있어야 해요. "이런 입력을 이런 옵션으로 curl에 넣으면 이런 일이 일어난다"가 명확해야 하죠. 그리고 영향 범위가 정확히 분석되어 있어야 해요. "심각한 RCE!" 같은 과장된 문구가 아니라, 어떤 빌드 옵션, 어떤 사용 시나리오에서만 발생하는지를 솔직하게 적어야 해요.

Mythos가 보낸 보고서는 이 두 가지를 잘 갖췄대요. 그리고 흥미로운 건, AI가 보고서를 쓰는 동안에도 사람이 한 번 더 검토하는 단계가 있다는 점이에요. 완전 자동화가 아니라 "AI 1차 + 사람 검수" 구조죠. 결국 이런 하이브리드 방식이 당분간 가장 현실적인 답인 것 같아요.

업계의 흐름 — Big Sleep, Atheris, OSS-Fuzz

비슷한 시도가 여기저기서 진행 중이에요. Google의 Project Zero가 만든 Big Sleep(이전 이름은 Naptime)도 LLM으로 메모리 안전성 버그를 찾는 프로젝트예요. 이미 SQLite에서 진짜 취약점을 찾은 사례를 발표했어요. Microsoft, Meta도 비슷한 내부 도구를 운영 중이고요. 전통적인 퍼징(fuzzing — 랜덤한 입력을 잔뜩 넣어서 크래시를 유발하는 기법) 도구인 OSS-Fuzz도 LLM과 결합하는 실험을 활발히 하고 있어요.

반면에 HackerOne, Bugcrowd 같은 버그 바운티 플랫폼들은 "AI 슬롭" 문제로 골머리를 앓고 있어요. 진짜 취약점 1건을 받기 위해 가짜 100건을 거르는 시간이 더 들어가는 상황이거든요. 그래서 "AI가 만든 보고서임을 명시할 것", "PoC 없는 보고서는 자동 거절" 같은 정책들이 도입되고 있어요.

한국 개발자에게 주는 시사점

첫째, 여러분이 운영하는 오픈소스 프로젝트가 있다면, 이런 AI 보안 도구를 한 번 돌려보는 것도 의미 있어요. 무료/저가 옵션도 늘고 있고, 진짜 버그 한두 개라도 찾으면 큰 이득이거든요. 단, 결과는 반드시 사람이 한 번 더 검증하세요.

둘째, 버그 바운티에 참여한다면 AI를 도구로 쓰는 건 좋지만, 검증 없이 그대로 제출하는 건 절대 하지 마세요. 메인테이너의 신뢰를 한 번 잃으면 회복하기 어렵고, 본인 평판에도 안 좋아요.

셋째, 보안 엔지니어를 꿈꾸는 분이라면 "AI + 보안" 분야가 지금 폭발적으로 성장 중이에요. LLM 출력을 어떻게 검증하고, 어떻게 진짜 취약점만 추려낼지에 대한 노하우가 매우 귀해지고 있어요. 시큐리티 분야에 새로운 직군이 만들어지고 있는 셈이죠.

넷째, 이번 사례는 결국 "AI는 보안 연구자를 대체하는 게 아니라, 도와주는 도구" 라는 걸 다시 한번 보여줘요. AI는 의심 영역을 빨리 좁혀주고, 사람은 그 결과를 판단하고 책임지는 구조가 당분간 가장 현실적이에요.

마무리

Daniel처럼 AI 보고서에 회의적이던 사람조차 "이번 건 진짜다"라고 인정한 사례는, AI 보안 도구가 한 단계 발전했다는 신호일 수 있어요. 여러분은 본인 코드에 AI 보안 스캐너를 돌려본 경험이 있나요? 결과는 신뢰할 만했나요, 아니면 가짜 알람의 홍수였나요?