소프트웨어 품질의 시대인가, 타조의 시대인가?

AI 요약

GNOME 보안 담당자 마이클 카탄자로(Michael Catanzaro)는 사람이 C, C++, Vala처럼 메모리 안전성을 보장하지 않는 언어로 안전한 코드를 작성하기 어렵다고 말합니다. 2024년과 2025년 GUADEC 발표 당시에는 안전한 소프트웨어 개발의 실패가 불가피하다고 봤지만, AI 취약점 탐지 성능이 크게 나아진 지금은 AI 스캔 없이 소프트웨어 품질을 유지하기 어렵다는 입장입니다. AI가 취약점을 더 쉽게 찾아내고 공격 코드 작성도 수월하게 만든 만큼, 프로젝트가 직접 문제를 찾지 않으면 공격자가 먼저 발견할 수 있다고 주장합니다.

AI 취약점 보고서를 허용해야 합니다

카탄자로는 2025년에는 AI가 만든 취약점 보고서 가운데 엉터리가 많았지만, 2026년에는 대체로 품질이 나아졌다고 설명합니다. 다만 보고서가 불필요하게 길거나 심각도를 부풀리고, 관련 없는 주장을 덧붙이거나 틀린 내용을 담는 경우도 있습니다. 가짜 스택 트레이스를 만들어 내는 사례도 드물지 않습니다. 숙련된 검토자가 걸러내면 좋지만, 경험이 적은 제보자가 AI 출력을 그대로 복사하는 경우가 있습니다. 보고서가 정확하더라도 수가 많으면 자원봉사 유지보수자가 감당하기 어렵고, 수정용 merge request 검토도 추가 업무가 됩니다.

그럼에도 AI 사용 자체를 이유로 이슈 보고를 금지해서는 안 된다고 주장합니다. 취약점 제보는 의무가 아니므로, 보고서를 전부 사람이 다시 쓰라고 요구하면 제보자가 다른 프로젝트로 가거나 정보를 다른 곳에 공개할 수 있습니다. 보고서 100건을 AI가 찾았다고 가정하면, 내용을 검증하고 이슈와 수정안을 제출하는 일만으로도 큰 수고입니다. 여기에 모든 보고서를 다시 작성하라고 요구하면 현실적으로 제보가 줄어든다는 설명입니다. 따라서 GNOME 프로젝트는 AI가 작성한 취약점 보고서를 허용하도록 정책을 바꾸고, 계속 금지하는 프로젝트는 GNOME의 의존성으로 적합하지 않다고 제안합니다. AI 사용만으로 보고서를 배척해서는 안 되지만, 나쁜 보고서를 받아들여야 한다는 뜻은 아니라고 덧붙입니다.

GNOME과 WebKitGTK의 취약점 추이

GNOME에 보고된 CVE는 2021년 21건, 2022년 14건, 2023년 13건에서 2024년 37건, 2025년 97건으로 늘었습니다. 2026년 9월 30일까지는 141건이며, 남은 기간을 고려해 연간 수치로 환산하면 188건입니다. GIMP, Gegl, libxml2, libxslt를 뺀 수치도 2021년 14건에서 2026년 환산치 99건으로 증가합니다. 저자는 AI가 증가의 주된 원인이지만, GNOME 유지보수자가 보안 이슈를 더 잘 식별하게 된 점도 영향을 줬다고 봅니다. 집계는 GNOME Security에 보고된 시점을 기준으로 하며, 아직 CVE가 발급되지 않은 2026년 제보는 포함되지 않습니다. 저자는 신규 보고의 보안 추적을 중단했고 이를 맡을 자원봉사자도 없어서, 향후 CVE 수가 크게 줄 것으로 예상합니다.

WebKitGTK의 CVE는 2025년 66건에서 2026년 현재까지 305건으로 늘었습니다. 증가분은 전부 Skia와 ANGLE을 AI가 분석해 발견한 취약점입니다. 이 라이브러리들은 WebKit에 포함돼 있으므로 저자는 WebKit 자체 코드와 같은 기준으로 집계해야 한다고 봅니다. 둘을 제외하면 올해 다른 WebKitGTK CVE는 21건입니다. 또 WebKit 개발자가 직접 발견한 보안 수정은 CVE로 이어지지 않는 경우가 많아 CVE 수치만으로 전체 보안 수정 증가를 볼 수 없다고 설명합니다.

버그 바운티 프로그램의 성과와 부담

독일 Sovereign Tech Agency의 Sovereign Tech Resilience 프로그램이 후원한 GNOME 버그 바운티는 YesWeHack에서 GLib, glib-networking, libsoup만 대상으로 운영됐습니다. 2024년 26건 제보 중 14건, 2025년 150건 중 33건, 2026년 2월 프로그램 종료 전까지 122건 중 24건을 수용했습니다. 총 298건 가운데 71건을 인정했고, 중복 제보 30건을 제외하면 197건은 거절했습니다. 인정된 취약점에는 총 183,900유로를 지급했습니다. libsoup에서 45건, GLib에서 23건, glib-networking에서 3건을 찾았습니다. 포상액은 500유로부터 7,500유로까지였고 평균은 2,662.99유로였습니다.

저자는 보고서 검토와 처리 부담이 커져 프로그램을 종료했다고 설명합니다. 전문 분류 담당자가 먼저 검토했어도 제보가 쌓였고, 마지막 포상 지급과 밀린 보고서 처리를 마치는 데에도 시간이 걸렸습니다. 금전적 보상이 걸린 제보는 부정확한 보고가 특히 많았으며, 채택된 보고서도 여러 차례 수정이 필요한 경우가 있었습니다. libsoup에서는 서비스 거부 취약점과 GNOME 사용자에게 위협이 되지 않는 SoupServer 요청 밀반입 문제를 범위에서 제외했지만 제보가 계속됐습니다. GLib에서는 정수 오버플로가 버퍼 오버플로로 이어지는 사례가 많았으며, 저자는 컴파일러 옵션인 -Wconversion, -Wint-conversion, -Wsign-compare가 이런 문제를 찾는 데 도움이 될 수 있다고 제안합니다.

Red Hat은 AISLE Research와 계약해 GNOME 프로젝트를 AI로 스캔했습니다. GLib에서 118건의 취약점을 발견했다고 보고했지만, 중복을 아직 모두 제거하지 않았고 46건은 gobject-introspection의 typelib 지원 문제였습니다. typelib은 프로그램이 라이브러리를 호출하는 방식을 정하므로 신뢰를 전제로 해야 하며, 악의적인 typelib 자체가 취약점을 만들 수 있습니다. 유지보수자들은 해당 문제를 고칠 필요는 있지만 보안 취약점으로 보지는 않았습니다. 저자는 이를 모두 오탐으로 치면 오탐률이 40%라고 설명합니다. 아직 전체 검증은 끝나지 않았지만, 그 외 보고서는 대체로 품질이 좋았다고 평가합니다.

AI만으로 보안 검토를 대체할 수는 없습니다

Sovereign Tech Resilience 프로그램이 후원한 Codean Labs의 보안 감사에서는 Flatpak과 xdg-desktop-portal에서 중대한 문제를 찾았습니다. AI 스캔으로 발견할 수 있었을 취약점도 있지만, Flatpak 샌드박스 탈출 두 건처럼 AI가 찾았을지 확신하기 어려운 문제도 있었습니다. 저자는 AI만 믿고 보안 검토를 맡기지 말아야 한다고 말합니다. AI로 코드 주석이나 커밋 메시지, 이슈·merge request 댓글을 대신 작성하는 일에도 부정적입니다. 특히 AI가 쓴 댓글을 자신의 글처럼 게시하면 유지보수자와 사람이 직접 대화하기 어려워진다고 지적합니다.

Rust는 메모리 안전성 문제 대부분을 줄이지만, 메모리 안전성과 무관한 취약점까지 없애지는 않습니다. 저자는 Cargo 의존성으로 인한 공급망 위험이 메모리 안전성의 이점보다 클 수 있다고 주장하며 GNOME 소프트웨어에서 Rust 사용을 권하지 않습니다. 반면 Lobsters 댓글에서는 Cargo 의존성을 버전 고정하거나 저장소에 함께 관리할 수 있고, Rust가 Cargo에 종속되지도 않는다는 반론이 나왔습니다. 글은 보안 제보를 허용하되 유지보수자가 모든 문제를 반드시 해결해야 한다고 요구하지는 않습니다. 보안 취약점의 공개 기한은 수정 완료 기한이 아니며, 자원봉사자는 보안 문제를 다른 버그보다 우선할 의무가 없다고 설명합니다.

Lobsters 반응

• @pyfisch — Rust가 메모리 안전성 문제 대부분을 없애고, 비슷한 C·C++·Vala 프로젝트보다 취약점이 한 자릿수 배 적을 것으로 기대할 수 있다는 말에는 동의합니다. 하지만 그 이유로 GNOME에 Rust를 권하지 않는다는 결론은 납득하기 어렵습니다. 의존성 버전을 고정하거나 GNOME 프로젝트가 포크해 관리하는 편이, 취약점을 줄인다고 저자 스스로 말한 언어를 피하는 것보다 낫습니다.
  • @wrs — 저자는 프로그래밍 언어 패키지 관리자를 쓰는 일과 의존성을 통제하지 못하는 일을 같은 것으로 보는 듯합니다. 두 가지는 같지 않다고 생각합니다. Rust 빌드의 의존성을 통제할 수 있다고 봅니다. 통제되지 않은 의존성을 가진 C++ 빌드도 만들 수 있습니다.
  • @ghoti — Rust는 Cargo와 본질적으로 결합돼 있지 않습니다. Make, CMake 등 어떤 빌드 시스템에서도 Cargo 없이 rustc를 직접 호출해 빌드할 수 있습니다. Cargo를 쓰는 프로젝트라면 cargo vendor로 의존성을 저장소에 포함해 버전 관리할 수 있습니다.
  • @refi64 — 악성 의존성에 대응하는 방법은 메모리 안전성 말고도 분명히 있습니다. 보안 문제를 다루는 글에서 취약점 상당수를 줄이는 쉬운 방법을 이런 이유로 지나치는 건 말이 안 됩니다.
  • @PuercoPop — Vala는 왜 C와 C++ 옆에 놓였나요? 자동 메모리 관리가 있고, 원하면 끌 수도 있는 언어라고 알고 있습니다.
  • @gulbanana — Vala는 C로 컴파일됩니다. 메모리 관리 기능은 있지만 Rust처럼 검사하지는 않습니다. 예를 들어 수명이 끝난 문자열을 가리키는 포인터를 사용할 수 있습니다. 배열도 경계 검사를 하지 않아 버퍼 오버플로가 날 수 있습니다.
• @schneems — 지금 Clippy에 기여하려고 하는데 유지보수자의 상황이 암울해 보입니다. 예전에는 PR을 만들 수 있다는 점 자체가 신호였습니다. 문서와 테스트까지 갖추면 좋은 기여자라는 뜻이었고, 어떤 이슈를 해결하는지 설명하면 더 좋았습니다. 유지보수자는 한정된 시간을 어디에 쓸지 그런 신호를 보고 판단해 왔습니다. 이제는 며칠 동안 공들여 리뷰를 받고 수정한 코드와, Claude에게 인터넷 점수와 이력서용 결과물을 만들어 달라고 한 코드를 구분하기 어렵습니다. 상대방이 실제 사람인지조차 확신할 수 없습니다. Clippy의 Rust 정책은 유지보수자와 리뷰어를 배려해 LLM을 쓰는 방법을 신중하게 설명합니다. 저도 그 정책을 완전히 따르지 못해 PR을 닫고 다시 작성하려 합니다. LLM 스캔은 좋다고 생각하지만, 사람이 검토하지 않은 LLM 이슈와 PR은 그렇지 않습니다. 어려운 일은 코드를 만드는 게 아니라 검토하고 유지할 수 있는 방식으로 만드는 일입니다.
  • @agent281 — 공감의 간극이 문제입니다. 일부 사람은 제품을 빨리 출시하는 데 익숙해졌고, 마찰을 싫어합니다. 직장에서 PR에 자세히 답했는데 곧바로 답변이 돌아오는 경우가 있었습니다. 제 글을 읽지도 않고 Claude에게 처리하라고 한 것 같았습니다. 자동 기여가 쏟아지는 상황에서 공감을 계속 요구하면 번아웃만 커질까 걱정됩니다.
• @gunduzc — “2026년에 AI 취약점 스캔 없이 품질 좋은 소프트웨어를 유지할 희망은 없다”는 말은 정말인가요? 안전하지 않은 언어를 쓰지 않거나, 포인터만 쓰지 말고 벡터를 쓰는 방법은 없나요? 이 주장은 LLM 사용을 띄우려는 악의적인 논리처럼 보입니다. Rust가 마음에 들지 않더라도 필요한 언어를 만들어 LLVM으로 컴파일할 수 있습니다. C·C++·Vala를 계속 쓰면서 터지지 않기를 바라는 것보다 낫습니다.
  • @Student — 그래도 Rust에서 버그가 생길 수 있다면요?
  • @motet-a — 대부분의 버그는 큰 문제가 아닙니다. 중요한 것은 취약점이고, Rust는 메모리 손상 버그를 잘 막습니다.
  • @mplant — 메모리 손상 없이도 취약점은 많습니다. 접근 제어를 확인하지 않아도 메모리 안전성은 유지됩니다.
  • @kornel — 안전하지 않은 언어는 접근 제어와 SQL 삽입 같은 상위 수준 버그에 더해 메모리 안전성 문제도 처리해야 합니다. C는 메모리 안전성을 포기하고 다른 안전성을 얻는 게 아닙니다. 그냥 더 안전하지 않습니다. Rust는 오류 처리를 컴파일러가 강제하는 식으로 논리 오류도 줄입니다. 임의 코드 실행이 없으면 위험은 대체로 프로그램이 원래 하려던 동작 범위에 그칩니다. C에서는 날씨 위젯을 통해 시스템 전체가 장악될 수도 있습니다.
  • @lumi — LLM이 버그를 찾는다는 사실은 LLM이 대단해서라기보다 기술 업계가 보안을 진지하게 다루지 않았다는 증거에 가깝습니다. 수백만 달러를 들여 침투 테스트 팀을 고용하면 LLM보다 양과 질 모두 더 나은 결과를 얻을 거라고 확신합니다.
  • @simonw — 최첨단 모델로 종합 보안 스캔을 돌리는 데 드는 약 100달러로 침투 테스터를 고용하면 어떨까요?
  • @dga — 제 Rust 개인 프로젝트에서도 LLM이 잠재적인 XSS와 자원 소모형 서비스 거부 경로를 짚어 줬습니다. RCE처럼 심각하진 않았지만 유용했습니다.
  • @refi64 — 기존의 안전하지 않은 언어로 작성된 소프트웨어가 많고 하룻밤 사이에 다시 쓸 수도 없습니다. JIT처럼 경계를 자주 다뤄야 하는 코드도 있습니다.
• @elliotmorris — LLM이 널리 퍼지면서 소프트웨어 품질의 정의 자체가 적대적인 영향을 받아 바뀌었습니다. 이제 그 변화를 막으려고 LLM을 더 치켜세워야 하는 상황처럼 느껴집니다. 그렇게 되도록 내버려 뒀다는 점이 슬픕니다.
  • @intelfx — 소프트웨어 품질 문제는 원래부터 있었습니다. 비용 효율적으로 찾아내는 방법을 이제야 발견한 것뿐이며, 그건 좋은 일입니다. 업계와 우리 자신이 오랫동안 소프트웨어 품질을 외면했다는 사실이 슬픕니다.
  • @gasche — 정말 끝난 건가요? 시스템 소프트웨어가 망가졌다는 사실을 인정한다면 메모리 안전 언어, capability 기반 보안, 형식 기법 등을 써서 크게 다시 만드는 게 자연스러운 대응이라고 봅니다. 하지만 실제로는 LLM이 찾은 문제를 전부 고친 뒤 지금 방식은 그대로 두고, 문제가 줄면 승리했다고 말하는 모습이 보입니다. 비용은 덜 들고 결과는 더 나쁘니 다들 그쪽을 택합니다.
  • @intelfx — 모든 일에는 비용과 편익의 절충이 있습니다. 모든 문제에 최대한의 노력을 들일 수는 없습니다. 최고 수준의 성능을 올리지 않더라도 아무것도 하지 않았을 때의 수준을 높이는 방법은 가치가 있습니다.
• @motet-a — Cargo 의존성 사용이 공급망 위험을 크게 늘린다는 점에는 동의하지만, 결론은 잘못됐다고 봅니다. GNOME의 공식 Rust 라이브러리가 왜 침해되겠습니까? GNOME 소프트웨어가 Cargo로 다른 것을 받아야 하는 이유는 무엇인가요? crates.io에 수상한 라이브러리가 많다고 해서 생태계 전체가 안전하지 않은 것은 아닙니다. 트로이 목마가 있다고 인터넷을 쓰지 말라는 말과 비슷합니다.
• @Student — LLM 리뷰가 이렇게 효과적이라는 점이 조금 실망스럽습니다. 명세도, 시뮬레이션 테스트도, 구조화한 방법도 없이 말입니다. LLM이 정말 집중해서 살펴본다는 뜻일까요?
  • @intelfx — 예상보다 적은 준비로 어떤 일이 더 잘된다면 반가운 소식이어야 하는데, 왜 실망스럽나요?
  • @Student — ‘쓴 교훈’의 씁쓸함 때문인 것 같습니다. LLM이 이미 프로그래머보다 앞선 분야니까요. 흥미로운 질문은 LLM이 퍼징이나 생성형 테스트가 찾는 버그와 같은 버그를 찾는지, 아니면 결과가 일부 겹치지 않는지입니다.
  • @intelfx — 여기서 ‘생성형 테스트’는 정확히 무엇을 뜻하나요? 퍼징이나 결정적 시뮬레이션 테스트 같은 것과 다른 말인가요?
  • @Student — 퍼징을 어떻게 정의하느냐에 달렸겠지만, 네, 퍼징이나 결정적 시뮬레이션 테스트 같은 것입니다.

원문: GNOME Blogs / 번역·요약: Trawling