취약점 보고서는 더 이상 특별하지 않다 — 2026년 LLM 시대 보안 분류학

도입: 보안 보고가 "예외"였던 시절의 약속

오픈소스 유지보수자에게 이슈와 PR은 보통 선택적으로 다루는 선물 같은 존재입니다. 받아들일지, 무시할지, 일부만 살려낼지는 메인테이너의 재량입니다. 그런데 취약점 보고서는 예외였어요. 보안 연구자는 즉시 공개하지 않고 비공개 채널을 택했고, 프로젝트는 그 대신 빠르게 검토·조사·진행 공유·크레딧 제공으로 보답하는 구조였습니다. 핵심 가치는 단순했습니다 — 공격자가 익스플로잇을 내놓기 전에 수정본을 배포할 수 있게 해주는 통찰과 기밀성. "보안 보고를 무시한다"는 것은 곧 "사용자 보안을 신경 쓰지 않는다"는 신호로 읽혔죠.

이 암묵적 합의가 2026년의 LLM 현실 앞에서 흔들리고 있습니다. Go Security 팀의 전 리드 Filippo Valsorda가 자신의 블로그에 올린 글이 그 신호탄입니다. 결론부터 말하면 — "취약점 보고서가 특별했던 시기는 끝났을 수 있다. 지금 더 중요한 일은 분류, 빠른 수정, 예방이다."

2026년에 무너진 전제 — LLM이 만든 평준화

과거의 보안 보고서가 특별했던 이유는 희소성이었습니다. 좋은 취약점을 찾는 사람 자체가 드물었기 때문에, 발견자는 프로젝트에 "서비스를 제공하는 사람"으로 인정받았죠. 하지만 2026년에는 LLM이 거의 모든 보안 연구자만큼 잘 분석을 수행하고, 누구나 그 LLM을 실행할 수 있습니다.

이게 무너뜨린 전제는 명확합니다:

• 잠재 이슈 발견은 더 이상 병목이 아님 — LLM이 컨테이너 런타임, 암호화 라이브러리, 네트워크 스택까지 훑을 수 있어요.
• 진짜 병목은 "이 중 무엇이 실제 취약점인가"라는 분류 작업으로 이동함.
• 공격자와 방어자가 같은 LLM을 동시에 실행하기 때문에 비밀 유지, 엠바고, 조율의 우위가 예전만큼 크지 않음.
• 공격자도 방어자와 같은 분류 병목을 겪음 — 즉 LLM 출력 검토와 security@ 받은편지함 검토의 신호 대 잡음비가 거의 같아짐.

신뢰 관계가 없는 외부 연구자는 이 분류 단계에서 의미 있게 기여하기 어렵습니다. PR을 보내기 전에 이미 같은 LLM이 maintainer의 CI에서도 돌고 있을 가능성이 높기 때문이죠. 특별 취급을 정당화하던 "희소한 통찰"이라는 전제가 평준화된 겁니다.

우선순위의 이동 — 보고 → 분류 → 빠른 수정 → 예방

메인테이너의 시간 투자가 바뀌어야 한다는 게 Filippo의 핵심 주장입니다. 과거에는:

> 보고 받기 → 조사 → 패치 작성 → 크레딧 공개

이 4단계가 모두 사람의 손을 거쳤습니다. 2026년에는:

> LLM 대량 후보 생성 → 사람이 분류 → 사람이 핵심 수정 → 사람이 CI에서 자동 검증 → 예방 규칙 코드로 내장

이렇게 재편되는 게 자연스럽습니다. LLM 분석을 CI에서 실행하는 방법이 그 핵심 인프라예요. PR이 들어오면 사람이 보기 전에 LLM이 자동으로 후보를 걸러내고, 메인테이너는 "진짜 위험한 것"에만 시간을 쓰게 됩니다. curl이 한 달간 취약점 보고 채널을 닫은 결정이 처음엔 도발적으로 보였지만, 사용자 보호를 위해 그 채널에 시간 쓰는 게 최선인지 더 이상 분명하지 않다는 맥락에서 이해할 수 있는 선택이죠.

분류 자동화의 실전 신호

Lobste.rs 댓글에서 한 참여자는 최전단 모델을 써도 오탐률이 90%에 가까울 때가 있다고 지적합니다. 즉 LLM이 취약점이라고 주장한 것 중 90%가 실제 문제가 아니라는 뜻이에요. 분류 작업은 여전히 사람이 해야 하지만, 그 사람은 "후보 생성" 단계가 아니라 "최종 판정" 단계에 들어가게 됩니다.

신뢰와 공개 관행의 복잡한 역사

신뢰 기반 취약점 보고 체계에는 복잡한 역사가 있습니다. 과거에는 선의의 연구자가 법적 위협이나 기소를 당한 사례가 있었고, 2026년 오픈소스 현실에서는 기소를 두려워하는 연구자가 거의 없어요. 동시에 프로젝트도 문서화된 보고 정책의 대안으로 기소를 암시해서는 안 됩니다.

행동의 심각성, 사적인 문제인지 커뮤니티 영향인지, security@ 처리팀의 자원이 어떤지에 따라 판단이 갈리죠. 정답은 없습니다. 다만 Code of Conduct 집행과 보안 보고 처리가 충돌할 때는 명확한 가이드라인이 미리 있어야 합니다.

"특별 보고"는 여전히 존재하지만 기준이 높아진다

Lobste.rs 토론에서 합의되는 결론은 이겁니다 — 모든 취약점 보고가 평범해졌지만, 심각도가 높거나 신뢰도가 높은 일부 보고는 여전히 "특별 보고"로 다뤄야 한다. 보안 이슈 진입 장벽이 낮아지면서 메일링 리스트에 잡음이 늘었고, 그러니까 방어자 쪽에서 더 나은 검증 방식과 공개된 위협 모델을 마련해야 합니다. 그래야 사람들이 "훌륭한 보고"로 인정받기 위한 더 높은 기준을 채우게 되죠.

결론 — 2026년 메인테이너를 위한 세 가지 액션

2026년의 오픈소스 메인테이너는 다음 세 가지를 즉시 코드와 운영에 반영해야 합니다:

1. LLM 분석을 CI에 통합 — PR이 들어오면 사람이 보기 전에 후보를 분류하는 자동화. 신호 대 잡음비를 메인테이너 쪽으로 끌어올리는 핵심 투자예요.
2. 신고 정책 문서를 위협 모델과 함께 공개 — 어떤 보고를 "특별 보고"로 다루는지, 분류는 어떤 순서로 진행되는지, 우선순위는 어떻게 매기는지를 사전에 명시. 기소 암시는 절대 금지.
3. 예방을 코드로 내장 — LLM이 잡아낼 수 있는 흔한 패턴(예: containerd의 GHSA-rgh6-rfwx-v388 / GHSA-33vj-92qq-66hc 같은 advisory들)은 CI 룰로 박아두는 게 수신 분류보다 싸게 먹힙니다.

취약점 보고가 "특별"이라는 관념은 2026년에 역사 속으로 들어갔을 가능성이 큽니다. 그 자리를 분류 자동화, 빠른 수정, 예방이라는 세 가지 실무 우선순위가 대신 채웁니다. 메인테이너의 시간은 이제 "받는 쪽"이 아니라 "판정하고 예방하는 쪽"에 쓰여야 해요.

• --

함께 보면 좋은 글

• 오픈 모델로 갈아타는 데 따른 단점은 크지 않음 — LLM 평준화가 보안 외 영역에서도 같은 패턴이라는 맥락.
• 오픈 소스 보안 작업은 "특별"하지 않다 — 본문과 같은 주장을 다른 메인테이너 관점에서 풀어낸 글.
• AI는 엔지니어링 규율을 더 적게가 아니라 더 많이 요구한다 — 분류·검증 단계가 오히려 더 무거워진다는 시각.
• 90일 공개 정책은 죽었다 — 엠바고 자체의 가치 하락을 다룬 글.
• LLM이 작성한 인시던트 보고서의 미래가 두렵다 — 자동 생성 보고서를 사람이 어떻게 신뢰할 것인가.