압박

• curl 유지보수는 공익성, 엔지니어링 도전, 품질 목표가 결합된 전업 작업이 되었고 주 50시간 안팎으로 이어져 왔음
• curl은 약 300억 개 설치 기반을 가진 전송 라이브러리와 도구로, 보안 실패가 사용자에게 번지지 않게 해야 한다는 부담이 큼
• 현재 보안 보고 유입은 2024년보다 4~5배, 2025년의 두 배 수준이며 평균 하루 한 건 이상이라 즉시 처리가 필요함
• 보안 처리는 주장 검증, 중요도 평가, 패치 작성, 도입 시점 파악, 권고문 작성, 연구자·보안팀 소통까지 포함함
• 예정 릴리스까지 이미 확정 취약점 12개가 대기 중이며, 전례 없는 압박 속에서도 자금과 인력 지원의 한계가 드러남

---

curl에 대한 책임감과 장기 유지보수

• 오픈소스 작업은 돈이나 화려한 생활을 위한 일이 아니라, 사회적 의미와 공익성, 모두에게 동작하게 만드는 엔지니어링 도전 때문에 계속되는 일임
• curl 작업은 2019년부터 전업이 되었고, 보통 주 50시간가량을 쓰며 낮과 늦은 밤, 주중과 주말을 모두 포함해 이어져 왔음
• curl의 목표는 가능한 최고의 전송 라이브러리와 도구가 되고, 오픈소스 품질·성능·보안 측면에서 최상위 프로젝트가 되는 것임
• curl은 한 사람의 프로젝트가 아니며 팀원들이 없었다면 지금의 curl은 없었지만, 많은 사람은 여전히 curl을 Daniel Stenberg 개인과 강하게 연결해 봄
• curl에 대한 비판은 자신이 지지하거나 직접 내린 결정과 선택에 대한 비판처럼 받아들여지며, curl은 삶을 영구히 바꾼 개인적인 프로젝트가 되었음
• 2026년 말에는 curl 프로젝트가 30주년을 맞고, 전 세계 curl 설치 수는 약 300억 개로 언급됨

보안 보고 환경의 변화

• 최근 몇 년간 curl 보안 보고 환경은 어리석은 LLM에 대한 불만에서 AI 슬롭 보고서, 버그 바운티 종료, 2026년 3월경 시작된 고품질 혼란으로 바뀌어 왔음
• 인터넷 제품, 소프트웨어 인프라, 오픈소스에서 큰 보안 실패가 반복될 때마다 curl이 어디에나 있다는 사실과, 그런 일이 curl이나 사용자에게 일어나면 안 된다는 압박이 커짐
• curl 프로젝트는 더 많은 점검, 테스트, 지침을 추가하며 결함이 새거나 침몰할 가능성을 조금씩 줄여 왔음

높은 검증 수준과 남는 위험

• Mythos가 첫 스캔에서 낮은 심각도의 문제 하나만 찾았다는 일 이후, curl이 상상 가능한 수준에서 가장 많이 검토되고 퍼징되고 검증된 코드 중 하나라는 평가가 반복됨
• 이런 상태는 우연이나 행운이 아니라, 수십 년간의 집요한 작업과 세부사항에 대한 주의, 끝나지 않는 반복 개선의 결과임
• 검토와 검증이 많아도 버그나 보안 문제가 없다는 뜻은 아니며, curl은 여러 프로토콜, 운영체제, CPU 아키텍처에서 고도로 병렬적인 네트워킹을 수행하는 수십만 줄의 C 코드임
• 문제는 발견될 때마다 수정되고 패치가 릴리스되는 과정이 반복됨
• 약 300억 개의 전 세계 설치 기반은 휴대폰, 태블릿, 자동차, TV, 프린터, 게임 콘솔, 주방 기기 등에 curl이 여러 번 들어 있을 가능성을 뜻함
• 과거에 큰 버그로 세상이 한동안 불타오르게 만든 프로젝트들은 주목을 받고, 일부는 자금과 인력을 얻어 여러 명의 전업 엔지니어를 고용할 수 있었음

전례 없는 보안 보고량

• 현재 보안 보고 유입 속도는 2024년보다 4~5배 높고, 2025년의 두 배이며, 평균적으로 하루에 한 건이 넘는 보고가 들어옴
• 보고 품질은 이전보다 훨씬 높고, 대개 매우 상세하고 길게 작성됨
• 보고가 계속 들어오기 때문에 가능한 한 도착 즉시 처리해야 하며, 도착 속도와 비슷하게 처리하지 않으면 잠재적 보안 문제 목록이 계속 쌓임
• 통제하지 못하는 잠재 보안 문제 목록은 정신적 부담을 만듦
• 현재 대부분의 시간은 HackerOne에 보고된 보안 이슈 목록을 처리하는 데 쓰임
• 주요 작업은 주장 검증, 중요도 평가, 패치 작성, 버그가 도입된 시점 파악, 취약점 이해, 세부 보안 권고문 작성, 보안 연구자 및 curl 보안팀과의 커뮤니케이션임

건강과 팀에 대한 압박

• 처음으로 배우자가 작업 시간과 불균형한 일·생활 상태를 걱정했고, 주변 사람들도 이 대량 유입을 어떻게 감당하는지와 소진 가능성을 걱정함
• 팀원들에 대한 걱정도 커졌고, 조만간 숨 돌릴 시간을 확보하기 위해 작업 시간을 줄여야 할 수도 있음
• 현재 상황은 curl 프로젝트와 보안팀 구성원이 이전에 겪어보지 못한 압박임
• 보안 이슈 처리는 프로젝트의 다른 모든 일을 제치는 높은 우선순위 작업이며, 책임감과 양심, 작업에 대한 자부심 때문에 무시하지 않음
• curl이 전 세계 기기에 배포된 소프트웨어인 만큼, 그 안의 보안 문제를 고쳐야 한다는 의무감이 강함
• 예정된 릴리스까지 릴리스 주기가 절반가량 남은 시점에 이미 확정 취약점 12개가 있고, 이는 대기 중인 CVE 발표 12건을 뜻함
• 이는 프로젝트 신기록이며, 2026년이 절반도 지나기 전에 공개 CVE가 30건에 도달한다는 뜻임
• 이 추세라면 2026년 전체 curl CVE 공개 수는 최소 그 두 배가 될 것으로 예상됨

필요한 지원과 구조적 한계

• 단기적으로는 이미 처리해야 할 일이 너무 많아 즉각적인 도움을 받기에는 늦은 상태임
• curl 또는 libcurl을 상용 소프트웨어와 서비스에서 사용하고 의존하는 기업들이 더 많이 자금을 지원하면, 더 많은 개발자에게 비용을 지급해 작업 부하를 나눌 수 있음
• 지원 계약을 통해 고용주가 비용을 지불하도록 하는 방식도 가능한 지원 경로임
• 이미 이런 지원을 하는 고객들이 있어 일부 구성원은 curl을 전업으로 작업할 수 있음
• 다만 이 영역에서 의미 있는 변화가 곧 일어날 것이라는 기대는 없고, 전례 없는 상황과 더 어려운 국면에서도 결국 스스로 폭풍을 지나갈 가능성이 큼
• curl 프로젝트는 회사 소유가 아니고 어떤 우산 조직에도 속하지 않음
• 이런 구조는 때로 자원이 부족하게 만들지만, 동시에 최대한의 자유와 유연성을 제공함
• 프로젝트의 행동 기준은 전 세계와 curl 사용자를 위해 curl을 가능한 한 좋게 만드는 데 맞춰져 있음

긍정적인 면과 현재 상태

• 버그와 문제를 고치는 일 자체는 좋은 일이며, 보고된 문제 하나는 곧 수정된 이슈 하나를 의미함
• 보고가 늘수록 curl은 더 나은 제품이 됨
• 최근 몇 년간 발견된 curl 취약점은 모두 심각도가 LOW 또는 MEDIUM으로 평가되었고, 매우 심각한 취약점은 거의 발견되지 않았음
• 앞으로 HIGH가 다시 나오지 않는다는 뜻은 아니지만, 적어도 드문 상태임
• 가장 최근의 높은 심각도 curl CVE는 2023년 10월에 공개된 CVE-2023-38545임
• 현재 curl 팀은 압박을 받고 있으며, 때로 응답이 느릴 수 있음

[GN⁺]

Lobste.rs 의견들

• Daniel과 다른 분들이 건강이나 가족에 큰 악영향 없이 이 어려운 상황을 잘 넘기길 바람
  다만 이 일이 어떻게 전개될지는 꽤 흥미로울 듯함. 새로운 자동 분석 방식이 여러 FOSS 프로젝트에서 갑자기 많은 취약점을 찾아낸 일이 처음은 아니고, 지금은 2010년대 그레이박스 퍼징이 등장했을 때와 비슷하게 느껴짐. 가능한 전개는 세 가지로 보임: A) 개발자들이 LLM을 보안 연구 흐름에 넣으면서 LLM이 찾는 새 취약점 수가 크게 줄고, LLM이 닿지 못하는 취약점은 계속 발견되는 퍼저 시나리오. B) A와 비슷하지만 LLM이 훑고 나면 취약점 발견이 사실상 멈추는 “LLM이 보안 연구를 해결”하는 시나리오. C) curl 같은 큰 프로젝트에서 취약점이 계속 높은 비율로 발견되고, 수십만 줄 코드 프로젝트의 버그 수는 사실상 무한하다는 “Tony Hoare의 복수” 시나리오

  • 실제로는 A 시나리오가 일어날 것 같음
    특정 코드베이스의 스냅샷에는 보안 버그가 유한하게만 있을 수 있음. 보안 버그 탐색 공간이 소진되면 홍수는 잦아들고, 이후 코드 병합이나 새로운 테스트 하네스, 모델 개선에서 나오는 버그가 조금씩 남을 듯함
    curl 프로젝트의 C 시나리오와 관련해서는, 기존에 보안 테스트와 전통적인 버그 발견 기법의 기준이 높았기 때문에 발견된 버그들이 낮은 심각도였다고 봄. 이는 버그 발견에 대한 지속적 투자가 장기적으로 계속 보답한다는 걸 보여줌. 오늘이나 미래에 어떤 발견 방법이 있든 마찬가지임
    Marcus Hutchins의 말을 빌리면 “버그 발견이 병목이었던 적은 없고, 조직이 보안 연구자에 투자하지 않기로 한 결정이 병목이었다”는 쪽에 가까움. LLM은 그 투자를 더 싸게 만들었을 뿐이고, 조직은 원래도 더 투자해서 더 많은 버그를 찾을 수 있었음. 결국 정책 결정임

• LLM 기술을 만드는 회사들은 자연 세계뿐 아니라 소프트웨어 세계도 파괴하고 있음. 하드웨어 가격이 치솟으면서 개인용 컴퓨팅 자체도 위협받고 있고, 만들고 싶어서 만드는 선의의 오픈소스 개발자들도 마찬가지임
  기존 커뮤니티 관리 오픈소스 프로젝트를 깎아내리고 망가뜨리는 데는 무한한 자금이 있는 듯한데, 그 후폭풍을 처리하는 데 쓸 돈은 전혀 없다는 점이 흥미로움
  이건 Zig가 옳았다는 걸 증명한다고 봄. LLM이 발견한 CVE는 그냥 상대하지 말고, 하고 싶은 사람이 맡게 두면 됨

  • “LLM이 발견한 CVE는 그냥 상대하지 말라”면, Linux 사용자들은 커널에 여러 로컬 권한 상승 취약점이 남아 있기를 더 원했을까?
    이게 정확히 핵심은 아니라는 건 알지만, LLM CVE의 문제는 같은 도구를 쓰는 다른 누구나 아마 똑같이 찾을 수 있다는 데 있음. 실제로 중대한 문제가 발견된다면, 더 많은 사람이 그것으로 해로운 무언가를 만들 수 있다는 뜻임
    물론 curl이 넘쳐나는 낮은 심각도나 비보안 이슈에 이것이 똑같이 적용된다는 뜻은 아님. 그래도 어떤 이슈가 높은 우선순위인지 실제로 판단해야 하고, 그러면 다시 1단계로 돌아가게 됨
  • Zig의 경우는 Curl과 상황이 다름
    Zig는 아직 활발히 개발 중이고, 예를 들어 증분 컴파일이나 비동기 I/O 같은 기능을 구체화할 때마다 새 버그를 넣을 가능성이 크며, 이전 구현이 불완전해서 생겼던 버그를 동시에 제거하기도 함
    이 개발 단계에서 누군가 Mythos 같은 걸 Zig에 돌려 “모든 버그를 찾고 실수하지 말라”는 식으로 접근하면 엄청난 양의 보고서가 나오겠지만, 그 전체가 우리에게는 사실상 쓸모없을 가능성이 큼. 지금 버그 보고의 주된 가치는 특정 사용 사례에서 막힌 사용자가 있다는 신호를 준다는 데 있고, 우선순위를 두기로 하면 그 사용자를 풀어줄 수 있다는 점임
    그렇다고 이 상태가 영원히 지속되지는 않음. 중요한 컴파일러 기능들이 많이 맞춰지고 있고, 안정화되면 모든 버그를 찾고 고치는 것이 최우선이 될 것임. 그때는 버그가 알려져 있다는 사실이 발견 방식과 무관하게 중요해지겠지만, 그 문제는 그 시점에 다룰 예정임
    그동안의 정책은 단순히 LLM 금지임
  • “하고 싶은 사람이 맡게 두라”고 하면, 블랙햇들이 그 보안 이슈를 기꺼이 맡을 것임. 다만 모두가 바라는 방식은 아닐 수 있음
    LLM 기여를 금지하는 건 이해는 하지만 동의하지는 않음. 보안 취약점은 발견 방식과 무관하게 취약점임
    Daniel이 하는 방식이 최선이라고 봄. 고칠 수 있는 버그를 고쳐 사용자를 더 안전하게 만들고, 그 대가가 크다는 점을 알리며 지원을 요청하는 것임. 그가 이 글을 읽을 가능성은 낮겠지만, 육체적·정신적 건강을 우선하기 위해 작업량을 제한하는 것도 지지하고 권하고 싶음. 세상 대부분은 이해할 것이고, 소수만 불평할 것 같음
  • CVE가 진짜라면 어떻게 발견됐는지는 중요하지 않아서, 이 방식이 어떻게 작동할지 불분명함
  • Project Zero의 사람들이 발견한 보안 버그를 두고도 비슷한 태도를 본 적이 있음
    여기에는 두 가지 핵심이 빠져 있는 듯함. 1) LLM 회사나 Project Zero가 그 보안 버그를 코드에 넣은 게 아님. 2) 보안 버그 수정은 LLM 회사나 Project Zero를 위한 게 아니라 사용자를 위한 것임. 보안 버그가 악용되면 사용자가 피해를 봄
    특히 LLM이 발견한 버그의 경우, 여러 오픈소스 프로젝트에서 같은 LLM을 쓰는 다른 사람들이 중복 보고를 올린다는 신호가 이미 있음. 따라서 방어자가 손을 떼면 공격자도 LLM 발견 버그를 알게 된다고 가정해야 함

• “과거에 세상을 한동안 불태운 끔찍한 버그를 배포한 프로젝트들이 부럽다. 그들은 관심을 받았고, 일부는 자금과 재정적 힘을 얻어 직원을 두고 여러 명의 풀타임 엔지니어를 고용했다. 가끔은 우리도 그런 게 하나 있었으면 더 나았을 거라고 생각한다”
  이런 일은 많은 직장에서도 일어남. 실패하는 팀에는 인력이 더 붙고, 잘되는 팀은 끔찍한 일이 일어나지 않는다는 이유로 더 적은 인원으로 더 많은 일을 해야 함

• curl 같은 프로젝트에 맞는지는 모르겠지만, 일정 기간 기능 동결을 해서 들어오는 버그/CVE 보고에만 집중하면 도움이 될까?
  정해진 기능 집합이라면 잠재적 버그/CVE의 수는 유한하고, 고치다 보면 0에 가까워질 것 같음
  어쨌든 그들에게 행운을 빔. 그만큼 중요한 소프트웨어를 유지보수하는 시기가 쉽지는 않을 것임

  • 회사에서의 기능 동결은 개발자들이 이미 망가졌다고 의심하는 것을 고칠 기회를 주기 위한 것임. 릴리스 전 기능 동결은 가능한 한 좋은 기능을 내보내기 위한 것이고, 오픈소스에서 여러 릴리스에 걸친 기능 동결은 개발자들이 중요한 사용성 개선이 빠진 도구를 계속 쓰도록 강제하는 것임
    개발자 만족도에는 순서대로 증가, 유지, 감소로 작용함
    기능 동결은 릴리스를 잘 마무리하게 해주는 훌륭한 도구이지만, 스스로 방향을 정해 일하는 개발자의 압박을 덜어주는 데는 좋은 도구가 아님