# 압박 > Clean Markdown view of GeekNews topic #29905. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29905](https://news.hada.io/topic?id=29905) - GeekNews Markdown: [https://news.hada.io/topic/29905.md](https://news.hada.io/topic/29905.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-27T09:02:46+09:00 - Updated: 2026-05-27T09:02:46+09:00 - Original source: [daniel.haxx.se](https://daniel.haxx.se/blog/2026/05/26/the-pressure/) - Points: 3 - Comments: 1 ## Topic Body - **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](https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/)에 대한 불만에서 [AI 슬롭 보고서](https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/), [버그 바운티 종료](https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/), 2026년 3월경 시작된 [고품질 혼란](https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/)으로 바뀌어 왔음 - 인터넷 제품, 소프트웨어 인프라, 오픈소스에서 큰 보안 실패가 반복될 때마다 curl이 어디에나 있다는 사실과, 그런 일이 curl이나 사용자에게 일어나면 안 된다는 압박이 커짐 - curl 프로젝트는 더 많은 점검, 테스트, 지침을 추가하며 결함이 새거나 침몰할 가능성을 조금씩 줄여 왔음 ### 높은 검증 수준과 남는 위험 - [Mythos가 첫 스캔에서 낮은 심각도의 문제 하나만 찾았다](https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/)는 일 이후, 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](https://curl.se/docs/CVE-2023-38545.html)임 - 현재 curl 팀은 압박을 받고 있으며, 때로 응답이 느릴 수 있음 ## Comments ### Comment 58320 - Author: neo - Created: 2026-05-27T09:02:47+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/dw02ye/pressure) - 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에 가까워질 것 같음 어쨌든 그들에게 행운을 빔. 그만큼 중요한 소프트웨어를 유지보수하는 시기가 쉽지는 않을 것임 - 회사에서의 기능 동결은 개발자들이 이미 망가졌다고 의심하는 것을 고칠 기회를 주기 위한 것임. 릴리스 전 기능 동결은 가능한 한 좋은 기능을 내보내기 위한 것이고, 오픈소스에서 여러 릴리스에 걸친 기능 동결은 개발자들이 중요한 **사용성 개선**이 빠진 도구를 계속 쓰도록 강제하는 것임 개발자 만족도에는 순서대로 증가, 유지, 감소로 작용함 기능 동결은 릴리스를 잘 마무리하게 해주는 훌륭한 도구이지만, 스스로 방향을 정해 일하는 개발자의 압박을 덜어주는 데는 좋은 도구가 아님