오늘의 트렌드로 돌아가기: PHP, 공격자가 코드를 실행할 수 있는 결함을 고치려고 Windows 웹 도구를 업데이트
Poly 랭킹 · 오늘의 트렌드에서

웹을 조용히 떠받치는 C 라이브러리 TOP 10 2026

Brotli의 압축 풀기 부분 취약점 기록은 두 건뿐입니다. 그러나 그중 하나인 CVE-2026-111497(CVSS 3.1 기준 9.8점) 때문에 Node.js, .NET, Python 패키지, PHP의 윈도우 버전이 2026년 10월 같은 주에 수정본을 내야 했습니다.

  • 1위: OpenSSL
  • 10개 순위

01최종 목록

선도 AI들이 각자 독립적으로 10위 목록을 만들었습니다. 위는 확인하기 쉬운 하나의 종합 결과입니다. 각 순위에는 이유, 포함한 AI, 그리고 AI가 제시한 경우 출처가 있습니다.

순서: AI의 동의가 많은 항목부터 적은 항목 순입니다.

밝은 배지는 해당 AI가 이 항목을 자기 목록에 넣었다는 뜻이고, 흐린 배지는 넣지 않았다는 뜻입니다.

  1. 1

    OpenSSL

    PHP, Node.js, Python, .NET에 들어가는 TLS 라이브러리입니다. OpenCVE는 CVE 330건으로 집계하고(다른 추적 사이트는 296건 또는 229건), 가장 잘 알려진 사례는 하트블리드입니다. 웹에서 차지하는 정확한 비중을 재는 자료는 없습니다.

    포함함: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. 포함하지 않음: ChatGPT, Wenxin.

    각 AI 목록에서의 순위: Meta: 목록 보기 · Grok: 목록 보기 · Gemini: 목록 보기 · Nova: 1 · StepFun: 목록 보기 · Kimi: 목록 보기 · DeepSeek: 목록 보기 · Qwen: 목록 보기

    각 AI가 짚은 점 8
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Gemini

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Nova1위

      웹의 암호 기반입니다. HTTPS 사이트의 67%에서 TLS/SSL을 처리하지만, 반복되는 메모리 손상 결함에 시달려 왔습니다.

    • StepFun

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Kimi

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • DeepSeek

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Qwen

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 8개가 이 순위로 선택
  2. 2

    Brotli (libbrotli)

    CVE 자체는 많지 않습니다. 하지만 압축 풀기 부분의 결함 하나, CVE-2026-111497 때문에 Node.js, .NET, Python, PHP가 한꺼번에 수정본을 내야 했습니다. 점수는 CVSS 3.1 기준 9.8점, 4.0 기준 9.2점이며, 마이크로소프트와 레드햇은 8.1점으로 매깁니다.

    포함함: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, Kimi, Wenxin. 포함하지 않음: DeepSeek, Qwen.

    각 AI 목록에서의 순위: ChatGPT: 1 · Meta: 7 · Grok: 2 · Gemini: 5 · Nova: 4 · StepFun: 2 · Kimi: 2 · Wenxin: 3

    각 AI가 짚은 점 8
    • ChatGPT1위

      하나의 디코더 결함이 Node.js, Python, .NET, PHP 생태계까지 퍼졌습니다. 인용된 기록에서 CVSS 3.1 점수는 9.8입니다.

    • Meta7위

      CVSS 9.2 CVE-2026-111497, c/dec/decode.c 1.0.3–1.2.0의 범위 밖 쓰기 – 압축률은 zstd보다 5% 나음, 압축 290 MB/s, 압축 해제 425 MB/s지만 접두사 트리가 복잡함

      출처 ↗
    • Grok2위

      정적 웹에서 여전히 가장 촘촘한 압축을 보여 줍니다(gzip보다 15–35% 작음). 하지만 2026년 10월의 디코더 범위 밖 쓰기(CVE-2026-111497, CVSS 9.2)는 복잡한 상태 기계가 왜 주된 공격면이 되는지 그대로 보여 줬습니다.

      출처 ↗
    • Gemini5위

      122 KB 정적 사전으로 텍스트를 3.65배까지 줄여 경쟁 방식을 압도합니다. 하지만 노출된 진입점 런타임이 원격 메모리 손상 긴급 패치를 받아야 했습니다.

      출처 ↗
    • Nova4위

      구글의 고압축 압축기입니다. 잘못된 스트림으로 원격 코드 실행이 가능했던 CVE-2026-111497로 악명이 높습니다.

    • StepFun2위

      라이브 웹에서 가장 좋은 압축률입니다. 그리고 2026년 10월에 원격 코드 실행 디코더 버그를 낸 유일한 코덱입니다.

    • Kimi2위

      웹 텍스트에서 가장 좋은 압축률(gzip보다 15–20% 작음)입니다. 그리고 이번 주 기준, 인증 없이 원격 실행되는 디코더 취약점(CVE-2026-111497)이 있습니다.

    • Wenxin3위

      120 KB 내장 정적 사전으로 텍스트를 강하게 압축하지만, 이제 2026년 치명적 범위 밖 쓰기 취약점의 공개 증명 코드(PoC)가 있습니다.

      출처 ↗
    AI 8개가 이 순위로 선택
  3. 3

    zlib

    PHP, Node.js, nginx, Python, curl이 기본으로 쓰는 gzip 경로입니다. OpenCVE는 CVE 19건으로 집계합니다. 가장 심각한 CVE-2022-37434(inflate()의 힙 오버플로, 메모리가 넘치는 오류)는 NVD에서 9.8점, IBM에서 7.3점입니다.

    포함함: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. 포함하지 않음: ChatGPT, Wenxin.

    각 AI 목록에서의 순위: Meta: 2 · Grok: 3 · Gemini: 6 · Nova: 2 · StepFun: 9 · Kimi: 3 · DeepSeek: 3 · Qwen: 5

    각 AI가 짚은 점 8
    • Meta2위

      W3Techs 기준 웹의 82%가 사용 – 압축 해제 390 MB/s, 단순한 LZ77+Huffman 구조, 10년간 주요 힙 오버플로 CVE는 CVE-2022-37434 하나뿐

    • Grok3위

      모든 브라우저와 HTTP 스택에 여전히 들어 있는 기본 선택지입니다. 성숙했지만 수십 년이 지나도 힙 오버플로 CVE가 계속 쌓입니다.

    • Gemini6위

      AVX2 벡터화로 표준 DEFLATE 압축 해제 속도를 850 MB/s로 두 배 높이면서, RFC 1951과의 하위 호환성을 엄격히 유지합니다.

      출처 ↗
    • Nova2위

      gzip과 deflate를 떠받치는 보편적 압축 라이브러리로, 수십 년 동안 버퍼 과다 읽기와 오버플로 취약점이 이어졌습니다.

    • StepFun9위

      측정상 더 빠른 zlib 대체품입니다. 다만 짧지만 실제 CVE 목록이 있습니다.

      출처 ↗
    • Kimi3위

      모든 클라이언트가 이해하는 기본값입니다. 사이트의 93.4%가 응답을 압축하고, 그 바이트 대부분은 30년 된 inflate()로 들어갑니다.

    • DeepSeek3위

      30년 동안 인터넷의 기본값입니다. 압축률 2.743배, 디코딩 390 MB/s이지만 CVE 14–19건이 있어 역사상 가장 많이 공격받은 웹 코덱입니다.

    • Qwen5위

      30년 된 HTTP의 기반으로, 방대하고 잘 문서화된 정수 래핑 목록을 감수하는 대신 보편적 호환성을 얻었습니다.

      출처 ↗
    AI 8개가 이 순위로 선택
  4. 4

    libxml2

    PHP DOM, Python lxml, Ruby Nokogiri 뒤에서 검증되지 않은 XML을 해석합니다. 집계 사이트에 따라 CVE가 101건에서 133건까지 다릅니다. CVE-2025-49796(메모리 손상)은 9.1점을 받았습니다.

    포함함: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. 포함하지 않음: ChatGPT, Wenxin.

    각 AI 목록에서의 순위: Meta: 목록 보기 · Grok: 목록 보기 · Gemini: 목록 보기 · Nova: 5 · StepFun: 목록 보기 · Kimi: 목록 보기 · DeepSeek: 목록 보기 · Qwen: 목록 보기

    각 AI가 짚은 점 8
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Gemini

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Nova5위

      PHP, Python, Ruby의 XML 파서입니다. 엔티티 확장과 버퍼 처리에서 버퍼 오버플로 문제가 있었습니다.

      출처 ↗
    • StepFun

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Kimi

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • DeepSeek

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Qwen

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 8개가 이 순위로 선택
  5. 5

    libcurl

    PHP의 curl 확장 기능과 pycurl에 들어 있습니다. NVD는 CVE-2023-38545 SOCKS5 힙 오버플로에 9.8점을 줬지만, curl 관리자는 2021년 이후 프로젝트가 심각도 '높음' CVE를 두 건만 공개했다고 말합니다.

    포함함: Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Wenxin, Qwen. 포함하지 않음: ChatGPT, Nova.

    각 AI 목록에서의 순위: Meta: 목록 보기 · Grok: 목록 보기 · Gemini: 목록 보기 · StepFun: 목록 보기 · Kimi: 목록 보기 · DeepSeek: 목록 보기 · Wenxin: 목록 보기 · Qwen: 목록 보기

    각 AI가 짚은 점 8
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Gemini

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • StepFun

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Kimi

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • DeepSeek

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Wenxin

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Qwen

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 8개가 이 순위로 선택
  6. 6

    PCRE2

    PHP의 preg_* 함수와 nginx의 location 블록 뒤에서 정규식(문자 패턴 검색)을 처리하는 엔진입니다. PCRE2의 CVE는 19건이고, 넓은 PCRE 계열은 66건입니다. JIT 결함 하나(CVE-2022-1587)는 범위를 벗어난 읽기 오류이며 9.1점입니다.

    포함함: ChatGPT, Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Qwen. 포함하지 않음: Nova, Wenxin.

    각 AI 목록에서의 순위: ChatGPT: 6 · Meta: 목록 보기 · Grok: 목록 보기 · Gemini: 목록 보기 · StepFun: 목록 보기 · Kimi: 목록 보기 · DeepSeek: 목록 보기 · Qwen: 목록 보기

    각 AI가 짚은 점 8
    • ChatGPT6위

      겉보기에 무해한 입력 칸 뒤에 정규식 엔진이 있을 수 있습니다. 그러면 공격자가 조작한 글이 네이티브 수준의 파싱 작업을 일으킬 수 있습니다.

      출처 ↗
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Gemini

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • StepFun

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Kimi

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • DeepSeek

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Qwen

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 8개가 이 순위로 선택
  7. 7

    SQLite

    PHP, Python, Node.js에 들어 있습니다. OpenCVE는 CVE 87건으로 집계하지만, 제이프로그는 그중 50건이 넘는 것을 AI가 만든 쓸모없는 신고라고 부릅니다. 실제 2026년 결함은 FTS5 기능의 힙 쓰기 오류(CVE-2026-11822/11824)입니다.

    포함함: Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Wenxin, Qwen. 포함하지 않음: ChatGPT, Nova.

    각 AI 목록에서의 순위: Meta: 목록 보기 · Grok: 목록 보기 · Gemini: 목록 보기 · StepFun: 목록 보기 · Kimi: 목록 보기 · DeepSeek: 목록 보기 · Wenxin: 목록 보기 · Qwen: 목록 보기

    각 AI가 짚은 점 8
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Gemini

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • StepFun

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Kimi

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • DeepSeek

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Wenxin

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Qwen

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 8개가 이 순위로 선택
  8. 8

    libpng

    PHP GD와 Python Pillow가 처리하는 PNG 업로드를 모두 풉니다. 2025년 말 한 번에 올라온 수정으로 CVE 다섯 건이 고쳐졌고, 여기에는 힙 오버플로(CVE-2025-64505부터 CVE-2025-66293까지)가 포함됩니다.

    포함함: ChatGPT, Meta, Grok, DeepSeek, Wenxin, Qwen. 포함하지 않음: Gemini, Nova, StepFun, Kimi.

    각 AI 목록에서의 순위: ChatGPT: 7 · Meta: 목록 보기 · Grok: 목록 보기 · DeepSeek: 목록 보기 · Wenxin: 목록 보기 · Qwen: 목록 보기

    각 AI가 짚은 점 6
    • ChatGPT7위

      이미지 처리는 업로드 과정, 썸네일 서비스, 콘텐츠 관리 시스템에서 개발자의 주요 요청 처리 코드 밖에서 자동으로 일어나는 경우가 많습니다.

      출처 ↗
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • DeepSeek

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Wenxin

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Qwen

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 6개가 이 순위로 선택
  9. 9

    libjpeg-turbo

    Pillow, GD, sharp 뒤에서 JPEG 사진을 풀어 주는 부분입니다. 그래서 프로필 사진 업로드는 모두 여기를 지나갑니다. OpenCVE는 CVE 17건으로 집계하며, 여기에는 조작된 JPEG 파일이 일으키는 메모리 범위 밖 읽기 오류 CVE-2018-14498이 포함됩니다.

    포함함: ChatGPT, Meta, Grok, StepFun, DeepSeek, Qwen. 포함하지 않음: Gemini, Nova, Kimi, Wenxin.

    각 AI 목록에서의 순위: ChatGPT: 9 · Meta: 목록 보기 · Grok: 목록 보기 · StepFun: 목록 보기 · DeepSeek: 목록 보기 · Qwen: 목록 보기

    각 AI가 짚은 점 6
    • ChatGPT9위

      공개 API가 업로드 주소 하나뿐인 이미지 처리 서비스도 공격자가 보낸 이진 데이터를 받을 수 있습니다.

      출처 ↗
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • StepFun

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • DeepSeek

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Qwen

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 6개가 이 순위로 선택
  10. 10

    libexpat

    Python 표준 라이브러리에 든 XML 해석기입니다. OpenCVE는 CVE 70건으로 집계하며(다른 미러 사이트는 65건), 2026년 6월 출시본 하나에서 그중 14건이 고쳐졌습니다.

    포함함: Meta, Grok, StepFun, Kimi. 포함하지 않음: ChatGPT, Gemini, Nova, DeepSeek, Wenxin, Qwen.

    각 AI 목록에서의 순위: Meta: 목록 보기 · Grok: 목록 보기 · StepFun: 목록 보기 · Kimi: 목록 보기

    각 AI가 짚은 점 4
    • Meta

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Grok

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • StepFun

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    • Kimi

      자체 목록에서는 다른 이름입니다: 전체 목록을 여세요.

      목록 보기
    AI 4개가 이 순위로 선택
    출처 없음

상위 3위 더 알아보기 ↓

02상위 3위 더 알아보기

순위는 위에 있습니다. 여기서는 상위 세 곳이 무엇인지, 왜 여기 있는지, 알아 둘 만한 것을 소개합니다.

세 곳은 서로 다른 기준으로 비교합니다. OpenSSL과 zlib은 CVE 건수로, Brotli는 위험도 점수 하나로 비교합니다. Brotli 점수도 누가 매기느냐에 따라 다릅니다(9.8, 9.2 또는 8.1). OpenSSL의 CVE 건수도 집계 사이트마다 다릅니다(330, 296 또는 229).

1OpenSSL

1위 — OpenSSL. 10개 AI 중 8개의 목록에 포함; 그 안의 중간 순위: 1. PHP, Node.js, Python, .NET 안에서 TLS(암호화 통신)를 처리하며, 하트블리드를 포함해 메모리 손상 버그 기록이 가장 깁니다.

알고 계셨나요

  • 하트블리드는 두 곳에서 각각 독립적으로 발견됐습니다. 구글의 닐 메타가 2014년 4월 1일 OpenSSL에 이를 신고했습니다. 보안 회사 코드노미콘은 자체 시험 도구를 개선하던 중 같은 결함을 찾았으며, 발견 날짜로 2014년 4월 3일을 제시합니다.

무엇인가
PHP, Node.js, Python, .NET에 함께 들어 있는 주요 TLS(암호화 통신) 라이브러리입니다.
강점
Brotli나 zlib보다 기록된 CVE가 훨씬 많습니다. OpenCVE 기준 330건입니다.
알아 두면 좋은 사람
웹 서버의 암호화 코드가 왜 가장 많이 노리는 공격 대상인지 알고 싶은 분께 도움이 됩니다.
  • 영향 범위와 메모리 오류 취약점(CVE) 수OpenCVE 기준 CVE 330건

위키백과 · Wikidata

여기 있는 이유
  • 하트블리드가 공개됐을 때, 인터넷에서 신뢰받는 보안 웹 서버의 약 17%, 약 50만 대가 노출된 것으로 알려졌습니다. 결함이 있는 OpenSSL 코드는 2012년 3월 14일 1.0.1 버전과 함께 퍼졌습니다.

알고 계셨나요
  • 하트블리드의 결함 코드는 검토자가 놓친 뒤 2011년 12월 31일 OpenSSL에 들어갔습니다. 2012년 3월 1.0.1 버전으로 배포되었고, 구글의 닐 메타가 2014년 4월 신고하기 전까지 2년 넘게 라이브러리에 머물러 있었습니다.

역사
  • 2014년 하트블리드 버그가 발견됐을 때, OpenSSL은 소수의 자원봉사자가 유지하고 있었고 그중 전업으로 일하는 사람은 한 명뿐이었습니다. 연간 기부금은 약 US$2,000이었습니다. 이 버그는 2012년부터 코드에 있었습니다.

유의할 점
  • 2020년 연구에 따르면 하트블리드 이후 월간 코드 수정 횟수가 세 배로 늘었고, 취약점 91건이 찾아져 고쳐졌습니다. 이 연구는 취약점 건수만으로 라이브러리의 안전성을 판단하는 것은 허술한 방법이라고 주장합니다.

더 알아보기
  • OpenSSL 보안 권고 목록을 열어 가장 최근 항목부터 읽습니다. 그 항목이 영향을 준다고 밝힌 OpenSSL 버전을 확인합니다.

상위 3위 비교 ↓

2Brotli (libbrotli)

2위 — Brotli (libbrotli). 10개 AI 중 8개의 목록에 포함; 그 안의 중간 순위: 2.5. CVE는 전체적으로 적지만, 압축 해제 프로그램(디코더) 결함 하나 때문에 Node.js, .NET, Python, PHP를 동시에 고쳐야 했습니다.

알고 계셨나요

  • Brotli에는 여섯 개 언어의 단어 13,504개와 웹에서 흔히 쓰는 문자열을 담은 내장 사전이 들어 있습니다. 앞말이나 뒷말을 붙이거나 대소문자를 바꾸는 등 120가지 변환을 거쳐 1,633,984개의 서로 다른 단어를 표현할 수 있습니다.

무엇인가
웹 서버와 브라우저가 웹페이지 용량을 줄이는 데 쓰는 구글의 압축 라이브러리입니다.
강점
버그 하나, CVE-2026-111497은 다른 두 곳의 어떤 결함보다도 한꺼번에 더 많은 실행 환경에 영향을 줬습니다.
알아 두면 좋은 사람
프로그램마다 디코더 사본을 따로 담고 있어 각각 업데이트해야 한다는 점을 개발자가 알아 두면 좋습니다.
  • 영향 범위와 메모리 오류 취약점(CVE) 수CVE-2026-111497, CVSS 9.8

위키백과 · Wikidata

여기 있는 이유
  • Brotli 디코더 버그 하나, CVE-2026-111497은 Node.js, .NET, Bun, Envoy, Istio, Python 패키지에서 수정이 필요했습니다. 구글은 9.2점(CVSS 4.0)으로 매겼고, 레드햇과 마이크로소프트는 8.1점으로 매겼습니다.

  • 수정 사항은 2월 27일 Brotli 소스 코드에 들어갔지만, 10월 21일 전까지는 어떤 배포판에도 담기지 않았습니다. 이후 Node.js 수정본은 22.23.4, 24.22.1, 26.12.1 등 세 개 버전 계열로 나왔습니다.

역사
  • 구글 엔지니어 위르키 알라쿠이얄라와 졸탄 사바드카가 2013년 웹 글꼴 파일(WOFF)의 용량을 줄이려고 Brotli를 만들었습니다. 2015년 9월에는 웹 전송 압축 용도로 넓혀져 웹 서버와 브라우저가 쓸 수 있게 되었습니다.

유의할 점
  • 전문가들은 이 결함이 얼마나 심각한지 의견이 엇갈립니다. 오픈AI는 원격으로 코드를 실행할 수 있다고 설명하지만, 마이크로소프트의 .NET 권고문에는 이것이 나오지 않습니다. 레드햇은 코드 실행이 일어났다는 믿을 만한 공개 증거가 없다고 말하고, 사이버보안 및 인프라보안국은 실제 악용 사례를 없음으로 기록했습니다.

  • 프로그램마다 디코더 사본이 따로 들어 있어, 각각 따로 업데이트해야 합니다. Python에서는 Brotli 패키지를 설치하기만 해도 앱이 노출될 수 있습니다. Node.js는 응답이 Brotli를 쓸 때 fetch()를 통해 노출됩니다.

더 알아보기
  • 구글의 Brotli 프로젝트 페이지를 열어 설명을 먼저 읽습니다. 그다음 이 라이브러리가 따르는 형식 명세인 RFC 7932를 찾아봅니다.

ChatGPT이(가) 1위로 꼽았습니다. 그들이 본 것
  • ChatGPT: 하나의 디코더 결함이 Node.js, Python, .NET, PHP 생태계까지 퍼졌습니다. 인용된 기록에서 CVSS 3.1 점수는 9.8입니다.

상위 3위 비교 ↓

3zlib

3위 — zlib. 10개 AI 중 8개의 목록에 포함; 그 안의 중간 순위: 3. PHP, Node.js, nginx, Python, curl에서 gzip 압축의 기본 경로이지만, 기록된 취약점 이력은 OpenSSL보다 짧습니다.

알고 계셨나요

  • 마크 애들러는 장루프 가이이가 압축 부분을 쓴 zlib의 압축 해제 코드를 썼습니다. 애들러는 미국 항공우주국의 화성 탐사 로버 임무에도 참여했으며, 나중에 2003년 임무에 채택된 개념에 대한 연구를 이끌었습니다.

무엇인가
대부분의 웹 소프트웨어에서 gzip 압축 뒤에 있는 오래되고 범용적인 라이브러리입니다.
강점
가장 심각한 버그인 CVE-2022-37434는 힙 오버플로(메모리 영역 넘침) 하나이며, CVE 목록은 OpenSSL보다 훨씬 짧습니다.
알아 두면 좋은 사람
웹의 상당 부분이 30년 된 라이브러리 하나에 기대고 있는지 알고 싶은 분께 도움이 됩니다.
  • 영향 범위와 메모리 오류 취약점(CVE) 수OpenCVE 기준 CVE 19건

위키백과 · Wikidata

역사
  • zlib의 첫 공개 버전인 0.9는 1995년 5월 1일에 나왔습니다. 원래는 libpng 이미지 라이브러리를 위해 만들어졌으며, 장루프 가이이와 마크 애들러가 썼습니다.

상위 3위 비교 ↓

상위 3위 나란히 보기

OpenSSLBrotli (libbrotli)zlib
AI 목록 포함8 / 108 / 108 / 10
영향 범위와 메모리 오류 취약점(CVE) 수OpenCVE 기준 CVE 330건CVE-2026-111497, CVSS 9.8OpenCVE 기준 CVE 19건
1위로 꼽은 AINovaChatGPT—

AI 수가 같은 순위는 각 AI 목록에서의 평균 순위로 정렬했습니다.

03알아 둘 만한 것

AI들이 목록을 만들며 발견한 것.

PHP 확장 모듈 하나(php_curl.dll)가 네이티브 C 라이브러리 다섯 개를 불러옵니다. 그 다섯 개는 libcrypto, libssl, brotlidec, libzstd, nghttp2입니다.

발견한 AI:
포함함: Kimi. 포함하지 않음: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, DeepSeek, Wenxin, Qwen.
출처 ↗

Brotli 결함이 모든 설치본에서 실제로 닿는 것은 아닙니다. PHP는 cURL의 응답 자동 압축 해제가 기본적으로 꺼져 있다고 밝히고, .NET 문서는 조건이 맞을 때만 노출된다고 적어 둡니다. 한 AI는 Guzzle이 기본으로 이를 켠다고 주장합니다.

발견한 AI:
포함함: ChatGPT, Meta, Wenxin. 포함하지 않음: Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen.
출처 ↗

심각도 점수는 누가 매기느냐에 따라 달라집니다. zlib의 CVE-2022-37434는 NVD에서 9.8점, IBM에서 7.3점입니다.

발견한 AI:
포함함: Kimi. 포함하지 않음: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, DeepSeek, Wenxin, Qwen.
출처 ↗

언어가 확인된 서버 측 언어 가운데 PHP가 차지하는 웹사이트 비중은 자료 시점과 출처에 따라 69.2%, 69.3%, 약 73%, 75%로 인용됩니다.

발견한 AI:
포함함: ChatGPT, Meta, Gemini, StepFun, Kimi. 포함하지 않음: Grok, Nova, DeepSeek, Wenxin, Qwen.
출처 ↗

04집계 방법

공식 없이 쉬운 말로.

1질문

현대 웹 런타임을 조용히 떠받치는 공용 C/C++ 라이브러리 TOP 10

2적용 범위

전 세계 웹 백엔드 및 응용 프로그램 런타임 보안

3살펴본 기준

  • 웹 서버와 백엔드 언어 엔진(PHP, Node.js, Python, .NET, Ruby)에 걸친 전 세계 실행 환경 사용 범위
  • 인증 없이 공격할 수 있는 메모리 손상 취약점의 과거 빈도와 심각도(CVSS 8.0 이상의 버퍼 오버플로, 힙 손상, 범위 밖 쓰기)
  • W3Techs 웹 기술 조사 — 서버 측 언어별(언어가 확인된 사이트 중 PHP 69.2%, 2026년 10월 27일)과 웹 서버별 웹사이트 비중. 라이브러리 설치 수가 아니라 사이트 수를 셉니다.
  • OpenCVE — 제조사나 제품별로 센 CVE 기록(OpenSSL 330, libxml2 116, SQLite 87, libexpat 70, zlib 19, libjpeg-turbo 17)
  • 미국 국립표준기술연구소 — 국가 취약점 데이터베이스(NVD)의 개별 CVE 기록과 CWE 분류(CWE-119/787/125), CVSS 점수
  • 관리자 보안 페이지(curl, SQLite, OpenSSL) — 각 프로젝트가 직접 밝히는 CVE 이력과 심각도 평가. NVD 점수와 자주 다릅니다.

4순위를 매긴 AI

선도 AI: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Wenxin, Qwen. 각 AI가 독립적으로 10위까지의 목록을 만들고 순위마다 출처를 밝혔습니다.

5순위를 정한 방법

AI마다 다르게 쓴 같은 항목은 하나로 셌습니다. 더 많은 AI가 목록에 넣고 더 높이 놓을수록 순위가 높아집니다. 'AI 합의'는 그 항목을 자기 목록에 넣은 AI의 수를 보여 줍니다. 출처는 AI가 직접 찾은 것뿐이며 사람이 추가한 것은 없습니다.

05AI별 목록

🇺🇸 ChatGPT10개 순위 · 메모 2개

같은 질문에 ChatGPT 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Brotli C 디코더

    하나의 디코더 결함이 Node.js, Python, .NET, PHP 생태계까지 퍼졌습니다. 인용된 기록에서 CVSS 3.1 점수는 9.8입니다.

  2. 2
    zlib 및 DEFLATE

    gzip 뒤에서 압축을 맡아 온 기술은 수십 년의 사용 이력이 있습니다. 디코더의 작은 결함 하나도 여러 소프트웨어 스택으로 번질 수 있습니다.

    출처 ↗
  3. 3
    OpenSSL libcrypto 및 libssl

    여러 프로그램이 함께 쓰는 암호 라이브러리에서 파싱이나 메모리 관리 결함 하나가 생기면, TLS 연결 지점, 클라이언트, 내장 애플리케이션 전체의 위험으로 커질 수 있습니다.

    출처 ↗
  4. 4
    libcurl

    네트워크 접속을 편하게 하려고 만든 라이브러리가, 자동 응답 압축 해제가 켜져 있으면 믿을 수 없는 입력이 들어오는 통로가 될 수 있습니다.

    출처 ↗
  5. 5
    libxml2

    XML 파서는 복잡한 입력 문법을 다루고 믿을 수 없는 문서를 처리할 수도 있습니다. 애플리케이션이 메모리를 자동 관리하는 언어로 쓰였더라도 파서를 단단히 보강해야 합니다.

  6. 6
    PCRE2 정규 표현식 라이브러리

    겉보기에 무해한 입력 칸 뒤에 정규식 엔진이 있을 수 있습니다. 그러면 공격자가 조작한 글이 네이티브 수준의 파싱 작업을 일으킬 수 있습니다.

    출처 ↗
  7. 7
    libpng

    이미지 처리는 업로드 과정, 썸네일 서비스, 콘텐츠 관리 시스템에서 개발자의 주요 요청 처리 코드 밖에서 자동으로 일어나는 경우가 많습니다.

    출처 ↗
  8. 8
    PCRE 호환 Oniguruma

    Ruby의 객체 관리 방식이 모든 네이티브 확장이나 네이티브 정규식 구현까지 메모리 안전하게 만들어 주지는 않습니다.

    출처 ↗
  9. 9
    libjpeg-turbo

    공개 API가 업로드 주소 하나뿐인 이미지 처리 서비스도 공격자가 보낸 이진 데이터를 받을 수 있습니다.

    출처 ↗
  10. 10
    libarchive

    압축 파일 풀기는 작은 크기로 보낸 바이트 하나를 한 번의 작업으로 여러 파일 이름, 메타데이터 필드, 압축 해제 버퍼로 바꿉니다.

    출처 ↗

ChatGPT의 발견

네이티브 라이브러리의 취약점 하나가 여러 제품 권고문에 중복으로 실릴 수 있습니다. 이것은 서로 독립된 근본 원인 결함이 여러 개라는 뜻이 아닙니다. 고유 CVE 수는 영향받는 제품 수와 따로 세야 합니다.

메모리 안전한 애플리케이션 코드도 네이티브 디코더 안의 범위 밖 쓰기를 막지 못합니다. 의존성 목록에는 함께 묶인 바이너리, 벤더링된 소스, 정적 링크된 복사본까지 포함해야 합니다.

🇺🇸 Meta10개 순위 · 메모 2개

같은 질문에 Meta 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Zstandard (zstd) 1.5.7

    압축 510 MB/s, 압축 해제 1550 MB/s, 압축률 2.896 – gzip보다 5배 빠르고 압축률도 높으며 치명적 CVE 이력이 거의 없음

    출처 ↗
  2. 2
    zlib (gzip/DEFLATE) 1.3.1

    W3Techs 기준 웹의 82%가 사용 – 압축 해제 390 MB/s, 단순한 LZ77+Huffman 구조, 10년간 주요 힙 오버플로 CVE는 CVE-2022-37434 하나뿐

  3. 3
    LZ4 1.10.0

    압축 해제 3850 MB/s – 웹 엣지에서 가장 빠른 디코더, 압축률 2.101, 원격에서 악용 가능한 CVE가 기록상 없을 만큼 단순한 프레임 형식

    출처 ↗
  4. 4
    Snappy 1.2.1

    압축 해제 1500 MB/s – 구글 gRPC 기본값, 원시 리터럴에서 Huffman을 건너뛰며 압축률 2.089를 내주는 대신 상태 기계를 최소화

    출처 ↗
  5. 5
    LZO1X 2.10

    압축 해제 780 MB/s, 압축률 2.106 – 1996년 설계된 초저메모리 디코더로, 아직 Linux initramfs에 쓰이며 정수 오버플로 공격면이 매우 작음

  6. 6
    Deflate (raw RFC1951)

    gzip과 같은 핵심이지만 18바이트 래퍼가 없음 – 같은 압축 105 MB/s, 압축 해제 390 MB/s, HTTP deflate에 사용, 공격면은 zlib에서 헤더 파서를 뺀 것

  7. 7
    Brotli 1.2.0 (br)

    CVSS 9.2 CVE-2026-111497, c/dec/decode.c 1.0.3–1.2.0의 범위 밖 쓰기 – 압축률은 zstd보다 5% 나음, 압축 290 MB/s, 압축 해제 425 MB/s지만 접두사 트리가 복잡함

    출처 ↗
  8. 8
    LZMA / xz 5.6

    gzip보다 압축률이 약 30% 높지만 압축 해제는 20배 느리고, 2024년 xz 백도어 CVE-2024-3094는 상태 기계의 위험을 보여 줌

  9. 9
    bzip2 1.0.8

    Burrows-Wheeler와 Huffman 방식, LZ4보다 200배 느리고 압축률은 gzip의 약 1.15배 – 원격 코드 실행 이력은 적지만 압축 폭탄 공격은 여전히 가능

  10. 10
    LZW / compress (.Z)

    1970년대의 사전 증식 방식이며 엔트로피 단계가 없음 – 압축률은 gzip의 0.9배, 특허는 만료됐고 파서는 단순하지만 현대 웹에서는 거의 쓰지 않음

    출처 ↗

Meta의 발견

같은 i7-9700K Silesia 기준 zstd 레벨 -1은 압축 510 MB/s, 압축 해제 1550 MB/s인 반면, gzip은 105/390, brotli는 290/425입니다. 압축률은 2.896 대 2.743으로, zstd가 gzip보다 5배 빠릅니다.

여전히 gzip이 강세입니다. W3Techs에 따르면 추적되는 전체 사이트의 82%가 gzip을 쓰고, 2026년 10월 기준 93.4%가 어떤 형태든 압축을 씁니다. 코드는 가장 단순해도 zlib의 공격면은 어디에나 있습니다.

🇺🇸 Grok10개 순위

같은 질문에 Grok 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Zstandard (zstd)

    1GB/s 이상으로 압축을 풀면서도 중간급 Brotli의 압축률에 맞먹거나 넘어서며, CPU를 훨씬 적게 씁니다. 그래서 마지막 10%의 대역폭 절감이 기하급수적 비용이 아니라 값싼 이득이 됩니다.

  2. 2
    Brotli

    정적 웹에서 여전히 가장 촘촘한 압축을 보여 줍니다(gzip보다 15–35% 작음). 하지만 2026년 10월의 디코더 범위 밖 쓰기(CVE-2026-111497, CVSS 9.2)는 복잡한 상태 기계가 왜 주된 공격면이 되는지 그대로 보여 줬습니다.

    출처 ↗
  3. 3
    gzip / zlib deflate

    모든 브라우저와 HTTP 스택에 여전히 들어 있는 기본 선택지입니다. 성숙했지만 수십 년이 지나도 힙 오버플로 CVE가 계속 쌓입니다.

  4. 4
    LZ4

    압축 해제 속도가 매우 빠릅니다(종종 3GB/s 이상). 대신 압축률이 가장 낮으며, 지연 시간이 대역폭보다 중요할 때 알맞습니다.

    출처 ↗
  5. 5
    Snappy

    구글이 속도를 우선해 설계한 방식이며, 여전히 많은 RPC와 저장 경로에 쓰입니다. 압축률은 예측 가능한 낮은 CPU 해제를 위해 일부러 낮춘 것입니다.

    출처 ↗
  6. 6
    XZ / LZMA

    텍스트에서 가장 높은 압축률을 보이지만 압축 해제는 10배 이상 느립니다. 복잡한 구조지만 인증 없는 HTTP 데이터에 거의 쓰이지 않아 웹에서 노출되는 원격 CVE가 적었습니다.

  7. 7
    LZO

    임베디드 기기와 일부 파일 시스템에 아직 남아 있습니다. 압축률과 속도는 gzip과 LZ4 사이이며, 공개 CVE 기록은 더 적습니다.

  8. 8
    bzip2

    구형 고압축 방식으로, 압축과 압축 해제가 모두 너무 느려 요즘 HTTP 실시간 응답 인코딩에는 거의 쓰이지 않습니다.

  9. 9
    deflate (raw / PNG 방식)

    gzip과 같은 알고리즘 계열이지만 헤더가 없습니다. 웹 런타임이 파싱해야 하는 많은 이미지와 압축 파일 형식의 핵심으로 남아 있습니다.

  10. 10
    lzma2 (XZ 변형)

    고전 LZMA보다 조금 유연하지만, 웹 프로토콜이 대부분 버린 '최대 압축률, 최저 속도' 영역에 속합니다.

🇺🇸 Gemini10개 순위 · 메모 2개

같은 질문에 Gemini 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Zstandard (Zstd)

    코어당 1,200 MB/s 이상으로 웹 텍스트를 디코딩하며, 경쟁 코덱을 괴롭힌 정적 사전 공격면을 피합니다.

    출처 ↗
  2. 2
    LZ4

    바이트 단위 스트리밍을 우선해 4,500 MB/s 압축 해제를 달성하며, 파서가 아주 간결해서 파서 상태가 메모리를 망가뜨리는 일에 강합니다.

    출처 ↗
  3. 3
    Gzip / DEFLATE

    30년 넘게 이진 퍼징을 거치며 압축 웹 트래픽의 47.1%를 처리합니다. 디코딩 속도 상한은 350 MB/s입니다.

    출처 ↗
  4. 4
    Snappy

    가변 길이 Huffman 엔트로피 테이블을 아예 쓰지 않아 마이크로초 단위 디코딩을 보장합니다. 대신 전송 크기는 15% 커집니다.

    출처 ↗
  5. 5
    Brotli

    122 KB 정적 사전으로 텍스트를 3.65배까지 줄여 경쟁 방식을 압도합니다. 하지만 노출된 진입점 런타임이 원격 메모리 손상 긴급 패치를 받아야 했습니다.

    출처 ↗
  6. 6
    zlib-ng

    AVX2 벡터화로 표준 DEFLATE 압축 해제 속도를 850 MB/s로 두 배 높이면서, RFC 1951과의 하위 호환성을 엄격히 유지합니다.

    출처 ↗
  7. 7
    LZO

    1996년 실시간 링 버퍼 파싱을 개척했습니다. 그러나 2014년 정수 오버플로로, 관리되지 않은 수십 년 된 압축 해제 C 코드는 잘 늙지 않는다는 것이 드러났습니다.

    출처 ↗
  8. 8
    Bzip2

    Burrows-Wheeler 변환으로 텍스트를 효율적으로 줄이지만, 압축 해제 속도가 38 MB/s에 그쳐 진입 서버의 병목이 됩니다.

    출처 ↗
  9. 9
    XZ / LZMA2

    구조화된 자산에서 4.10배의 뛰어난 압축률을 보이지만, 들어오는 연결 하나마다 최대 64 MB의 압축 해제 상태 메모리가 필요합니다.

  10. 10
    Deflate64

    DEFLATE의 슬라이딩 창을 64 KB로 넓혔지만, 현대 스트리밍 코덱의 처리량 이점 없이 특이한 파싱 예외 사례만 늘렸습니다.

Gemini의 발견

DEFLATE(3.12배)와 Brotli(3.65배) 사이의 마지막 10% 페이로드 절감을 쫓으면 122 KB 사전과 다단계 동적 Huffman 테이블이 필요해지고, 참조 C 파서의 상태 복잡도가 400% 넘게 늘어납니다.

Zstandard가 쓰는 유한 상태 엔트로피(FSE)는 산술 코딩처럼 분수 비트 정밀도에 도달하면서, 코어당 1.2GB/s 이상으로 압축을 풉니다. 높은 압축이 위험한 파싱 복잡성을 꼭 요구하지는 않는다는 것을 보여 줍니다.

🇺🇸 Nova5개 순위

같은 질문에 Nova 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    OpenSSL

    웹의 암호 기반입니다. HTTPS 사이트의 67%에서 TLS/SSL을 처리하지만, 반복되는 메모리 손상 결함에 시달려 왔습니다.

  2. 2
    Zlib

    gzip과 deflate를 떠받치는 보편적 압축 라이브러리로, 수십 년 동안 버퍼 과다 읽기와 오버플로 취약점이 이어졌습니다.

  3. 3
    nghttp2

    클라우드플레어와 Nginx가 쓰는 HTTP/2 구현으로, 스트림 관리에서 힙 손상 결함을 겪었습니다.

  4. 4
    Brotli

    구글의 고압축 압축기입니다. 잘못된 스트림으로 원격 코드 실행이 가능했던 CVE-2026-111497로 악명이 높습니다.

  5. 5
    libxml2

    PHP, Python, Ruby의 XML 파서입니다. 엔티티 확장과 버퍼 처리에서 버퍼 오버플로 문제가 있었습니다.

    출처 ↗
🇨🇳 StepFun10개 순위 · 메모 3개

같은 질문에 StepFun 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Zstandard (zstd, RFC 8878)

    참조 C 디코더에 메모리 손상 CVE가 한 번도 없는 최상위 웹 코덱은 이것이 유일합니다.

    출처 ↗
  2. 2
    Brotli (RFC 7932)

    라이브 웹에서 가장 좋은 압축률입니다. 그리고 2026년 10월에 원격 코드 실행 디코더 버그를 낸 유일한 코덱입니다.

  3. 3
    gzip / DEFLATE (zlib, RFC 1952)

    웹 JavaScript의 60%를 압축하지만, Brotli는 29%입니다. 그 뒤에는 30년 된 inflate()와 CVE 19건이 있습니다.

  4. 4
    LZ4

    코어당 GB/s 범위로 압축을 풀고, 디코더가 작아서 오후 한나절이면 감사할 수 있습니다. 압축률을 감수할 수 있다면요.

    출처 ↗
  5. 5
    Snappy

    입력 250 MB/s, 출력 500 MB/s이지만, 압축률은 gzip보다 20–100% 나쁩니다. 이것이 웹에서 밀려난 이유입니다.

  6. 6
    Zopfli

    DEFLATE 밀도의 마지막 3–8%를 얻으려면 압축 비용이 약 100배 듭니다. 그리고 디코더 공격면은 정확히 0만큼 늘어납니다.

    출처 ↗
  7. 7
    LZMA / xz (liblzma)

    이 목록에서 가장 좋은 범용 압축률입니다. 그리고 참조 tarball에 의도적인 백도어를 넣은 유일한 방식입니다.

  8. 8
    bzip2

    2009년 형식으로 아직 파이썬 표준 라이브러리에 들어 있습니다. BZ2_decompress는 2019년까지 범위를 벗어난 쓰기를 계속했습니다.

  9. 9
    zlib-ng

    측정상 더 빠른 zlib 대체품입니다. 다만 짧지만 실제 CVE 목록이 있습니다.

    출처 ↗
  10. 10
    LZO (liblzo2)

    2014년 어느 오후에 CVE가 4건 나왔고, 모두 리터럴 실행 디코더의 정수 오버플로였습니다. '빠른' 코덱의 경고 사례입니다.

StepFun의 발견

채택 곡선과 효율 곡선은 반대 방향을 가리킵니다. Brotli는 2023년과 2024년 사이 모바일 페이지의 28%에서 37%로 늘었지만, gzip은 여전히 JavaScript 응답의 60%를 압축하고 Brotli는 29%입니다. 대부분의 웹은 더 나은 코덱으로 옮겨 가지 않았습니다.

기본 수준에서 속도 차이는 작지 않습니다. zstd는 510 MB/s로 압축하고, Brotli는 290, gzip은 105입니다. 압축 해제는 zstd가 1,550 MB/s, Brotli가 425입니다. 그래서 CDN은 동적 콘텐츠에는 zstd를, 미리 압축한 정적 자산에만 Brotli를 점점 더 많이 고릅니다.

Brotli에 대한 가장 날카로운 비판은 압축을 잘 못해서가 아니라, 그 장점이 '정말 추한 꼼수'라는 것, 즉 하드코딩된 사전이라는 점입니다. 그 주장마저 논쟁적입니다. 사전을 0으로 비워도 Brotli가 웹 압축에서 여전히 이긴다고 댓글 작성자들이 보고했습니다.

🇨🇳 Kimi10개 순위

같은 질문에 Kimi 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Zstandard (zstd, RFC 8878)

    gzip보다 압축률이 좋고(약 10–15% 작음), Brotli보다 약 2배 빠르게 디코딩합니다. 디코더에 메모리 손상 CVE는 없습니다.

    출처 ↗
  2. 2
    Brotli (RFC 7932)

    웹 텍스트에서 가장 좋은 압축률(gzip보다 15–20% 작음)입니다. 그리고 이번 주 기준, 인증 없이 원격 실행되는 디코더 취약점(CVE-2026-111497)이 있습니다.

  3. 3
    DEFLATE / zlib (gzip)

    모든 클라이언트가 이해하는 기본값입니다. 사이트의 93.4%가 응답을 압축하고, 그 바이트 대부분은 30년 된 inflate()로 들어갑니다.

  4. 4
    Zopfli (구글)

    인코더 전용 DEFLATE 최적화기입니다. 모든 클라이언트가 이미 출력을 디코딩하므로, 새 디코더 공격면 없이 압축률 경쟁에서 이깁니다.

    출처 ↗
  5. 5
    LZ4

    목록에서 가장 빠른 디코더입니다. 그리고 가장 유명한 메모리 버그(CVE-2021-3520)는 memmove()의 정수 오버플로 하나였습니다.

    출처 ↗
  6. 6
    Snappy (구글)

    LevelDB와 몽고DB의 기본 코덱입니다. 이 목록에서 C++ 취약점 기록이 가장 깨끗하지만, 압축률은 가장 낮습니다.

  7. 7
    xz / LZMA (liblzma)

    Brotli를 제외하면 가장 좋은 압축률입니다. 하지만 디코더는 계속 새로운 버그 유형을 발견하고, 가장 심각한 CVE(10.0)는 수학이 아니라 관리자 측에서 나왔습니다.

  8. 8
    bzip2 (Burrows-Wheeler)

    2019년 범위 밖 쓰기는 NVD에서 9.8(치명적), 레드햇에서 4.4로 평가되었습니다. '취약점 밀도'가 평가 방식에 따라 달라진다는 가장 순수한 사례입니다.

  9. 9
    LZW (Unix compress)

    변호사가 퇴출시킨, 메모리 버그가 아닌 유일한 항목입니다. 유니시스의 특허(US 4,558,302)는 2003년 6월 20일에 만료됐는데, 웹은 그 전에 이미 GIF에서 PNG로 옮겨 갔습니다.

    출처 ↗
  10. 10
    공유 Brotli (Compression Dictionary Transport)

    최전선입니다. 사이트별 공유 사전은 재방문자에게 Brotli 이상의 압축률을 주며, 웹에서 퍼징이 가장 덜 된 디코더 상태 기계를 씁니다.

    출처 ↗
🇨🇳 DeepSeek10개 순위 · 메모 2개

같은 질문에 DeepSeek 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Zstandard (zstd) 2026

    1,550 MB/s로 압축을 풀면서 Brotli와 같은 압축률을 냅니다. 더 빠른 디코더가 더 단순한 공격면이기도 한 드문 경우입니다.

    출처 ↗
  2. 2
    Brotli 2026

    웹 텍스트 최고 압축률(2.883)이 그대로 CVSS 9.2 범위 밖 쓰기를 만들었습니다. 수익 체감을 보여 주는 대표 사례입니다.

    출처 ↗
  3. 3
    gzip / DEFLATE (zlib) 2026

    30년 동안 인터넷의 기본값입니다. 압축률 2.743배, 디코딩 390 MB/s이지만 CVE 14–19건이 있어 역사상 가장 많이 공격받은 웹 코덱입니다.

  4. 4
    LZ4 2026

    여러 GB/s 압축 해제로 처리량 왕이지만, 압축률이 약 2.1배라 zstd보다 바이트가 약 25% 더 듭니다. 다만 C 디코더의 CVE 흔적은 훨씬 작습니다.

    출처 ↗
  5. 5
    XZ / LZMA2 2026

    목록에서 가장 높은 압축률(3.43배)이지만 압축 해제는 35 MB/s이고, CVSS 10.0 공급망 백도어를 겪었습니다. 최대 압축, 최대 위험입니다.

  6. 6
    bzip2 2026

    블록 정렬 압축은 텍스트에서 강한 압축률을 내지만, 압축 해제가 느리고 정수 오버플로와 범위 밖 CVE가 길게 이어집니다.

  7. 7
    Snappy 2026

    구글의 LZ77 변형으로 압축률보다 속도를 우선합니다. C++ 핵심 라이브러리는 가볍지만, Java 바인딩에서 최근 CVSS 7.5 이상 힙 오버플로가 나왔습니다.

    출처 ↗
  8. 8
    LZO 2026

    실시간 압축 해제를 위해 설계된 LZO는 217 MB/s, 압축률 2.64배를 냅니다. 웹 고유 CVE 이력은 거의 없어 공격면이 작은 일꾼입니다.

  9. 9
    DEFLATE (raw) 2026

    원시 RFC 1951 스트림은 가장 단순한 웹 코덱이지만, gzip의 CRC 래퍼가 없어 zlib의 CVE 19건 inflate 이력을 그대로 물려받습니다.

    출처 ↗
  10. 10
    LZMA (alone) 2026

    LZMA SDK는 .xz 컨테이너 없이 xz급 압축률을 냅니다. 하지만 디코더는 이 목록에서 가장 느리고, xz와 같은 복잡한 상태 기계 공격면을 공유합니다.

DeepSeek의 발견

Brotli의 복잡성은 웹 텍스트에서 gzip보다 약 5% 나은 압축률을 줍니다. 하지만 디코더가 CVE-2026-111497을 만들었습니다. 자동 HTTP 압축 해제로 닿는 CVSS 9.2 범위 밖 쓰기입니다. 이제 한계 이득은 공격면으로 측정됩니다.

LZ4 압축 해제는 xz보다 몇 자릿수 빠릅니다(SquashFS 벤치마크에서 218 MB/s 대 xz의 35 MB/s). 대신 압축률은 2.12배 대 3.43배로, 페이로드가 62% 큽니다. 가장 빠른 코덱이 대역폭을 가장 아끼는 코덱은 아닙니다.

🇨🇳 Wenxin10개 순위 · 메모 1개

같은 질문에 Wenxin 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    Zstandard (zstd)

    비슷한 빠른 설정에서 zlib보다 압축은 5배, 압축 해제는 4배 빠르며 압축률도 약간 높습니다. 공격면을 부풀릴 내장 정적 사전이 없습니다.

    출처 ↗
  2. 2
    Gzip

    거의 모든 사소한 메모리 손상 결함을 다루는, 수십 년의 공개 퍼즈 테스트를 거친 보편적 웹 대체 수단입니다.

    출처 ↗
  3. 3
    Brotli

    120 KB 내장 정적 사전으로 텍스트를 강하게 압축하지만, 이제 2026년 치명적 범위 밖 쓰기 취약점의 공개 증명 코드(PoC)가 있습니다.

    출처 ↗
  4. 4
    Deflate

    gzip을 구동하는 원시 DEFLATE 명세입니다. 추가 HTTP 래핑 로직이 없어서 새 파싱 공격면을 더하지 않습니다.

    출처 ↗
  5. 5
    LZ4

    메모리 근처 줄 압축 해제에 최적화되어, 지연 시간이 중요한 작업을 위해 최대 압축률보다 속도를 우선합니다.

    출처 ↗
  6. 6
    Snappy

    구글이 개발한 저복잡도 알고리즘으로, 메모리 안전 결함을 부르는 디코더 쪽 복잡성을 피하도록 설계됐습니다.

    출처 ↗
  7. 7
    LZF

    2000줄 미만의 최소 C 구현입니다. HTTP 용도에서 구조 파싱 복잡성이 최소입니다.

  8. 8
    LZMA

    최대 압축률은 매우 높지만, 압축 해제 복잡도가 기하급수적으로 늘고 처리량은 매우 낮습니다.

  9. 9
    Bzip2

    Burrows-Wheeler 변환 기반 알고리즘입니다. 속도가 느리고 보안 유지가 활발하지 않아 현대 웹에서는 거의 쓰이지 않습니다.

  10. 10
    DEFLATE64

    더 큰 창 크기를 가진 확장 DEFLATE 변형으로, 추가 상태 로직을 넣지만 표준 HTTP 웹 지원은 없습니다.

    출처 ↗

Wenxin의 발견

비슷한 빠른 설정에서 Zstandard는 zlib보다 거의 4배 빠르게 압축을 풀면서, 압축률은 약간 높습니다. 2026년 벤치마크가 확인했습니다.

🇨🇳 Qwen10개 순위 · 메모 2개

같은 질문에 Qwen 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.

  1. 1
    LZ4

    RAM 속도로 압축을 풀며, 취약점 스캐너에 거의 잡히지 않을 만큼 단순한 상태 기계를 씁니다.

  2. 2
    Zstandard (Zstd)

    페이스북의 공학적 걸작으로, LZ4에 가까운 압축 해제 속도와 gzip을 앞서는 압축률을 함께 냅니다.

    출처 ↗
  3. 3
    Snappy

    구글의 속도 우선 압축기로, 압축률을 희생해 압축 해제 처리량을 얻고 파서 로직을 극단적으로 최소화합니다.

  4. 4
    Brotli

    정적 자산을 위한 웹의 중량급 일꾼입니다. 다만 복잡한 사전 파서가 2026년 10월 PHP2Shell과 HTTP2Shell 원격 코드 실행 결함을 일으켰습니다.

  5. 5
    Deflate (zlib)

    30년 된 HTTP의 기반으로, 방대하고 잘 문서화된 정수 래핑 목록을 감수하는 대신 보편적 호환성을 얻었습니다.

    출처 ↗
  6. 6
    Gzip

    Deflate를 감싸는 10바이트 헤더일 뿐이며, 밑바탕 엔진의 메모리 손상 결함을 모두 물려받습니다.

    출처 ↗
  7. 7
    LZMA / XZ

    거대한 사전 상태 기계로 놀라운 압축률을 만들지만, 2024년 공급망 백도어를 유발한 것으로 유명합니다.

    출처 ↗
  8. 8
    Bzip2

    Burrows-Wheeler 변환은 수학적으로 우아하지만 계산량이 많고, 현대 웹 표준에서는 대부분 버려졌습니다.

    출처 ↗
  9. 9
    LZFSE

    애플의 독점 에너지 효율 코덱으로 모바일 배터리 수명에 좋지만, 표준 공개 웹 밖에 불투명한 상태 로직을 도입합니다.

    출처 ↗
  10. 10
    Zopfli

    인코더 전용 호기심 대상으로, 파일 하나를 표준 Deflate 데이터로 출력하는 데 몇 시간이 걸리며 압축 해제 보안 이득은 없습니다.

    출처 ↗

Qwen의 발견

Zstd와 LZ4는 우수한 웹 성능을 얻는 데 지수적 파싱 복잡성이 필요 없음을 보여 줍니다. 단순한 바이트 지향 LZ77 파생물은 높은 처리량을 유지하면서 메모리 공격면을 최소로 둡니다.

수익 체감은 실재합니다. XZ와 LZMA는 더 좋은 압축률을 내지만, 너무 큰 사전 상태 기계를 요구해 공급망 공격과 메모리 손상의 주요 표적이 됩니다.