오픈소스 보안 대응의 관행은 오랫동안 '엠바고'에 기대어 왔다. 취약점을 비공개로 고치고, 영향을 받는 사용자에게 알린 뒤, 마지막에 공개 권고문을 내는 식이다. 이 절차의 전제는 상세 정보의 비밀 유지가 곧 사용자 보호라는 믿음이었다. 그러나 OCaml의 HTTP 라이브러리 cohttp 6.3.0에 경로 순회(path traversal) 취약점 수정을 배포한 한 메인테이너의 경험은 그 전제가 무너졌음을 보여준다. 그는 수정 PR을 연 지 불과 몇 분 만에, 자신의 실서비스 웹서버 로그에서 정확히 해당 버그 패턴을 노린 탐침(probe)을 발견했다.
더 심각한 것은 그 자신이 '대략 어떤 문제인지'만 알고도 자기 AI 에이전트로 익스플로잇을 재현할 수 있었다는 점이다. 실제로 그는 취약 코드에 자기 Claude를 붙여 추가 문제를 찾게 했는데, Fable은 Glasswing 접근 권한이 없어 보안 차단으로 거부한 반면 DeepSeek V4 Pro는 응했고 관련 결함 몇 개를 독립적으로 찾아냈다. 로컬 서버를 겨냥한 익스플로잇 코드는 1분도 걸리지 않았다. 공개 PR(cohttp#1145)을 연 뒤 약 10분 만에 퍼센트 인코딩된 순회 시퀀스를 노린 자동 탐침이 들어온 것을 고려하면, 오히려 10분은 긴 편이라는 게 그의 관찰이다.
익스플로잇이 패치를 앞지르다
이 변화는 일화가 아니라 측정된 추세다. Fang 등의 연구에서 GPT-4 에이전트는 CVE 설명이 주어지면 15개 취약점 벤치마크의 87%를 익스플로잇했지만, 설명이 없으면 7%에 그쳤다. 방향성만 있으면 나머지는 에이전트가 스스로 조사한다는 뜻이다. 익스플로잇까지 걸리는 평균 시간은 2018~19년 약 63일에서 2024년에 0을 지났고, 이제는 -7일, 즉 익스플로잇이 패치보다 먼저 등장하는 국면에 접어들었다. marimo의 CVE-2026-39987은 공개 PoC가 없었는데도 권고문에서 첫 공격 시도까지 9시간, Langflow의 CVE-2026-33017은 20시간이 걸렸다.
2026년 5월의 한 논문은 이 국면을 '버고노믹스(bugonomics)'로 명명하며, 병목이 이제 '방어자의 교정 처리량(defender remediation throughput)'으로 옮겨갔다고 주장한다. LLM은 익스플로잇을 손쉽게 찍어내지만, 메인테이너의 검증·분류·릴리스 속도는 정체돼 있다. Pesoli 등은 승부는 프런티어 모델이냐 오픈웨이트냐 프로그램 분석이냐가 아니라, 희소한 검증·우선순위·릴리스 역량을 기계적 탐색과 보고서 초안이 아니라 견고한 수정에 쓰도록 어떻게 조율하느냐라고 지적한다.
왜 방어 역량은 정체되어 있나
메인테이너 역량이 제자리인 데는 이유가 있다. 하나는 프런티어 에이전트(예: Mythos)에 대한 접근 자체가 막혀 있다는 점이다. 서구권 상용 모델에는 보안 가드가 걸려 있어 소규모 프로젝트가 쓰기 어렵고, Project Glasswing은 중요 인프라 운영자, 클라우드·금융 사업자, 리눅스 재단 등 15개국 150개 조직으로 확대됐지만 '동네 구멍가게' 수준의 메인테이너는 여전히 배제돼 있다. 다른 하나는 더 근본적이다. 회귀(regression)를 일으키지 않는 보안 패치를 설계하는 일은 그 자체로 훨씬 많은 노동을 요구한다.
제안된 대응책은 세 갈래다. 첫째는 AI의 손이 닿지 않는 정말 비공개된 곳에서 수정을 개발하는 것이다. 다만 GitHub의 임시 비공개 포크는 CI가 접근하지 못해 테스트 결과와 단절되고, 하나의 PR만 병합 가능하며, 리뷰어를 관리자가 한 명씩 등록해야 해 '지나가다 돕는' 오픈소스 리뷰 문화와 맞지 않는다. 게다가 이는 잘못된 구멍을 막는다. 정작 중요한 것은 패치의 비밀 유지가 아니라, 문제에 대한 설명이 공격자에게 새지 않고 정확히 필요한 사람에게만 닿게 하는 것이다. 그래서 프로젝트 맥락에서 아군과 적을 구분할, Advogato 같은 경량 신뢰의 웹(web-of-trust)이 필요하다는 제안이 나온다.
둘째는 반대로 공개적으로 빠르게 고치고 지속적으로 배포하며 릴리스 경로를 자동화로 개선하는 길이다. Chrome은 주간 보안 업데이트와 주 2회 릴리스, 재시작 없는 동적 패치까지 구현해 이것이 가능함을 보인다. 리눅스 커널도 수정을 가능한 한 빨리, 길어야 7일(예외적으로 14일)만 미룬다. 문제는 패키징이다. Chrome은 단일 바이너리를 배포하지만, cohttp 같은 라이브러리는 다양한 하위 제품에 임베드되고 배포판은 저마다의 일정으로 재패키징한다. 엔드포인트를 통제하지 못하는 구조에서는 구글식 마이크로업데이트의 사치를 누리기 어렵다.
셋째는 가장 급진적인 발상, 즉 상위 패치가 늘 익스플로잇을 뒤따를 수밖에 없다면 더 빠른 무언가를 앞세우자는 것이다. 이번 cohttp 버그에는 '요청 URL의 퍼센트 인코딩된 경로 구분자를 정규화한다'는 간단한 완화책이 있었고, 이는 보고가 도착한 순간부터, 정식 수정이 리뷰·테스트·패키징을 거치는 동안에도 배포 가능했다. Cloudflare가 2021년 Log4shell에 관리형 규칙을 배포했듯 클라우드에서 가상 패치는 이미 일상이다. 다만 오픈소스에는 상용 CDN 밖에서 그런 규칙을 전파할 배포 메커니즘이 없다는 것이 한계다.
결국 단기적으로는 세 가지의 조합이 불가피해 보인다. 기여자 간 신뢰의 웹, 인간 기여자를 압도하지 않는 패키징·연속 배포·분류 자동화, 그리고 취약점을 초 단위로 감지해 즉시 자기 인프라를 방어하는 국지적 확산 방어다. 이 사례가 한국 실무자에게 던지는 질문도 분명하다. 기업 내부 SBOM과 가상 패치, 커밋·메일링 리스트에서의 정보 누출 관리를 전제로, 상위 패치보다 먼저 움직일 완화 수단을 갖췄는가다. 소문만으로 익스플로잇이 나오는 시대에, 방어의 병목은 더 이상 '얼마나 오래 숨기느냐'가 아니라 '얼마나 빨리 검증하고 굴리느냐'로 옮겨갔다.