curl은 약 300억 개의 장치에 설치되어 있습니다. 이는 단연코 지구상에서 가장 면밀히 조사되고, 가장 많은 퍼징 (Fuzzing) 테스트를 거치는 네트워킹 라이브러리입니다. 그리고 지금, curl의 제작자는 번아웃 (Burnout)을 겪고 있습니다.

curl에 갑자기 구멍(취약점)이 가득해졌기 때문이 아닙니다. AI 기반의 보안 연구 (AI-powered security research)가 인간 관리자가 수용할 수 있도록 설계되지 않은 수준의 품질과 양에 도달했기 때문입니다.

curl의 창립자이자 리드 개발자인 Daniel Stenberg는 이번 주에 가감 없고 솔직한 글을 게시했습니다:

유입되는 보안 보고서의 속도는 2024년보다 4~5배 높고, 2025년보다 2배 빠릅니다. 즉, 평균적으로 이제 하루에 하나 이상의 보고서를 받고 있다는 뜻입니다. 품질은 그 어느 때보다 훨씬 높습니다. 보고서들은 보통 매우 상세하고 깁니다.

이제는 단순히 '슬롭 (Slop, 저질 콘텐츠)'의 시대가 아닙니다. 2024년에 Stenberg는 버그 트래커 (Bug tracker)를 넘쳐나게 만드는 어리석은 LLM (Large Language Model) 환각 (Hallucination)에 대해 글을 썼습니다. 2025년 초에는 "수천 개의 슬롭에 의한 죽음"이 화두였습니다. 이제 2026년에 이르러 도구들이 성숙해졌고, 그에 따라 압박감도 커졌습니다.

실제로 무엇이 변했는가

• 보고서가 2024년 속도의 4~5배, 2025년 속도의 2배로 도착하고 있습니다 — 하루에 1개 이상입니다.
• 그것들은 더 이상 환각이 아닙니다 — 보고서들은 신뢰할 수 있고 상세하며, 완전한 분류 (Triage) 과정을 필요로 합니다.
• 곧 출시될 버전에는 이미 12개의 확인된 취약점이 포함되어 있으며, 이는 프로젝트 기록입니다.
• curl은 2026년이 절반 지나기도 전에 **30개 이상의 CVE (Common Vulnerabilities and Exposures)**를 발표할 궤도에 올라와 있습니다.
• Stenberg는 업무 시간의 거의 전부를 HackerOne 분류 (Triage), 패치 (Patching), 그리고 권고문 (Advisory) 작성에 소비하고 있습니다.
• 처음으로 그의 아내가 그의 워라밸 (Work/life balance)에 대해 우려를 표했습니다.

병목 현상은 버그가 아니다

문제는 이것입니다: 기술적으로 curl은 잘 버텨내고 있습니다. 지난 몇 년 동안 발견된 모든 취약점은 낮음 (LOW) 또는 중간 (MEDIUM) 심각도로 평가되었습니다. 마지막 높은 (HIGH) 심각도의 CVE는 2023년 10월이었습니다. 30년간의 끊임없는 엔지니어링 덕분에 치명적인 구멍은 정말로 드뭅니다.

하지만 그것은 거의 본질에서 벗어난 이야기입니다. 제약 요인은 버그의 품질이 아니라, 인간의 대역폭 (Bandwidth)입니다.

AI 보안 도구(AI security tooling)는 이제 대규모로 체계적이고 심층적인 코드 분석을 수행할 수 있습니다. 이는 소프트웨어 품질 측면에서는 순이익(net positive)입니다. 하지만 반대편에서는 그에 상응하는 확장이 이루어지지 않고 있습니다. 즉, 각 보고서를 검증하고, 패치(patch)를 작성하며, 공개 일정(disclosure timelines)을 조율하고, 수정 사항을 배포(ship)하는 소규모 유지 관리자(maintainer) 팀 말입니다.

Stenberg는 이 수치에 대해 직설적으로 말합니다: "쓰나미가 우리를 덮쳐오고 있고, 우리가 할 수 있는 것이라고는 수영하는 것뿐입니다. 우리를 위한 구명보트는 없습니다."

이것이 curl을 넘어선 문제인 이유

인터넷에서 가장 잘 관리되는 핵심 인프라(critical infrastructure) 조차 어려움을 겪고 있다면, 나머지 오픈 소스 생태계는 세심한 주의를 기울여야 합니다.

이것은 AI라는 형태의 날카로운 칼날을 맞이한 오픈 소스 지속 가능성 위기입니다. 산업계는 수십억 달러 가치의 무료 인프라를 소비하고, 유지 관리자들이 그 비용을 감당합니다. 이제 여기에는 AI 기반 보안 연구 파이프라인(security research pipeline)에서 마지막 인간 체크포인트(human checkpoint) 역할을 수행하는 비용까지 포함됩니다.

Curl은 적어도 유료 고객이 일부라도 있습니다. 대부분의 프로젝트는 그렇지 않습니다.

무엇을 해야 하는가

• 귀사의 서비스가 curl 또는 libcurl에 의존한다면 (실제로 그러할 것입니다): 자금을 지원하십시오. Stenberg는 명시적으로 지원 계약(support contracts)을 요청하고 있으며, 이는 개발자의 시간을 보상하는 일입니다. 그의 포스트에 자세한 내용이 있습니다.
• AI 보안 도구를 출시한다면: 다운스트림 부하(downstream load)를 생각하십시오. HackerOne에 제출하기 전에 속도 제한(Rate limiting), 중복 제거(deduplication), 심각도 필터링(severity filtering)을 수행하는 것이 실질적인 차이를 만들 것입니다.
• 오픈 소스를 유지 관리한다면: AI 지원 연구(AI-assisted research)가 성숙해짐에 따라, 이러한 패턴은 모든 주요 프로젝트에 닥쳐올 것입니다. 이미 물에 빠진 뒤가 아니라, 지금 바로 고민해 볼 가치가 있습니다.

출처: The pressure — Daniel Stenberg · Simon Willison's linkblog

✏️ KewBot (AI)로 초안 작성, Drew가 편집 및 승인.