전 세계 수십억 대의 단말기에 탑재된 데이터 전송 라이브러리 curl이 7월 한 달 동안 취약점 보고를 일절 받지 않았다. 제작자인 Daniel Stenberg는 이를 「summer of bliss(지복의 여름)」라고 명명했다. 걸린 이유는 그 뒤에 있다. AI가 내뱉는 형편없는 보고를 견딜 수 없어서가 아니다. 보고는 오히려 좋아졌다. 좋아진 데다 양까지 늘었다. 그럼에도 그는 창구를 닫았다.

여기에는 2025년의 「AI 슬롭(AI Slop) 문제」와는 또 다른, 한 단계 더 앞선 이야기가 담겨 있다.

영어권 헤드라인을 나열하면 혼란스럽다. 「curl이 버그 바운티(Bug Bounty)를 종료」했다는 것과 「curl이 7월의 보고를 중단」했다는 것이 혼재되어 있어, 마치 같은 사건처럼 읽히기 쉽다. 실제로는 별개의 판단이다.

curl의 security 팀이 한 일을 시계열로 정리하면 다음과 같다.

시기	수행한 내용
2026년 1월	HackerOne 상의 버그 바운티(보상금 제도)를 종료. 보상금이 "일단 던지고 보자"는 동기가 되었기 때문 (BleepingComputer 보도)
...

HackerOne은 취약점을 발견한 사람이 개발자에게 비공개로 보고하고 대응 상황을 주고받는 대표적인 플랫폼이다. 1월에 중단한 것은 그 위에 얹혀 있던 「보상금」 부분이다. 금전적 인센티브가 조잡한 보고를 대량 생산하게 만드는 연료가 되었다는 판단이었다.

7월에 닫는 것은 보고 채널 그 자체다. summer of bliss 공지에 따르면, 중단 기간은 7월 1일 00:00 CEST부터 8월 3일 09:00 CEST까지다. HackerOne의 게시 양식은 멈추고, 보안용 이메일 주소도 "도착해도 처리하지 않는" 죽은 창구가 된다. 반면 GitHub의 issue와 pull request는 평소와 다름없이 열려 있으며, 유상 지원 계약자에게는 기간 중에도 풀 서비스가 제공된다. 부작용으로 다음 릴리스(8.22.0)는 약 2주 밀려 9월 2일로 연기되었다.

The curl maintainers will use this time of less pressure to take in some extra air and to enjoy the summer.

(curl의 메인테이너들은 이 압박이 적은 시간을 이용해 숨을 좀 돌리고 여름을 즐길 것이다)

공지 본문에서 언급하는 이유는 보안 대책도, 대(對) AI 정책도 아닌 메인테이너의 휴식이다. 이 점이 중요하다. 7월의 중단은 Stenberg 자신의 표현으로는 반(反) AI 조치가 아니다. 「AI가 DDoS를 하고 있다」라는 강한 프레임은 오히려 보도와 그의 과거 기사에서 비롯된 것이다.

그렇다면 무엇이 그렇게 무거웠던 것일까. 수치는 6월 초반의 별도 기사인 「The pressure」에 나와 있다. 2026년 봄 이후 취약점 보고는 평균적으로 하루 1건을 넘어섰으며, 2024년 대비 4~5배, 2025년 대비 약 2배의 속도로 도착하고 있다. 게다가 내용은 「매우 상세하고 길며」, 질은 명확하게 향상되었다.

아이러니한 점은 그 대부분이 실제 취약점이 아니라는 사실이다. 기사 작성 시점에서 확인된 미처리 안건은 12건, 2026년에 공개될 CVE는 연간 30건 이상이 예상되지만, 심각도는 모두 LOW 또는 MEDIUM이며, HIGH는 2023년 10월을 마지막으로 나오지 않고 있다. 즉, 도착하는 산더미의 대부분은 「버그이긴 하지만 취약점은 아닌 것」 혹은 오탐(False Positive)이며, 인간이 이를 하나하나 재현하고, 분류하고, 필요하다면 수정하며, 공개를 조정해야 한다. curl의 security 팀은 보도된 바에 따르면 7명 정도다. 툴은 진화했지만, 받는 사람의 수는 늘어나지 않았다.

If we don't take care of them roughly at the same speed they arrive, the backlog just grows ... takes a mental toll.

(도착하는 속도와 거의 비슷하게 처리하지 않으면 백로그는 그저 쌓여만 갈 것이고... 정신적인 고통을 준다)

여기에 생성형 AI 시대의 비대칭성이 적나라하게 드러나 있다. 「그럴싸한 결과물을 생성하는 비용」은 한없이 제로(0)에 가까워졌지만, 「그것을 검증하고 받아들이는 비용」은 인간에게 고정된 채 내려가지 않고 있다. curl의 사례는 공격이나 악의 때문이 아니라, 오히려 선의에 기반한 고품질 보고의 증가가 일으킨 현상이다. 그렇기에 까다로우며, 필터로 걸러내면 끝날 문제가 아니다.

실무 엔지니어라면 이것이 보안 보고에만 국한된 문제가 아니라는 사실을 즉시 깨달을 것이다. AI가 생성하는 PR (Pull Request), issue (이슈), 설계 제안, 리뷰 요청. 이 모든 것들은 '만드는 쪽'의 비용은 매우 저렴해지는 반면, '읽고 판단하는 쪽'의 부하만 쌓이게 된다. 흐름 제어 (Flow control)가 없는 파이프라인에서 상류(upstream)의 대역폭만 10배로 늘린 것과 같다. 'summer of bliss'는 하류(downstream)의 메인테이너(maintainer)가 수동으로 백프레셔 (Backpressure)를 걸었다고 해석하는 것이 가장 적절하다. 한 달 치 수신을 통째로 중단하는 것은 레이트 리미터 (Rate limiter) 구현 방식으로는 투박하지만, 확실한 효과가 있다.

그렇다면 보고하는 쪽은 어떻게 해야 하는가? 중단 공지 직전인 6월 29일, 그는 「Do excellent vulnerability reports (훌륭한 취약점 보고를 수행하라)」라는 실천적인 가이드를 내놓았다. 이것이 이번 사례에서 가장 가치 있는 일차 정보다.

흥미로운 점은, 거기에 "AI를 사용하지 마라"라고 적혀 있지 않다는 것이다. 오히려 반대로, 보고서를 쓰는 사람에게 요구되는 사항은 다음과 같이 정리되어 있다.

Really?— 이미 알려진 사양이나 의도된 동작을 "취약점"으로 오인하고 있지는 않은지 먼저 의심할 것
Report— 서두에 "인간이 작성한, 무엇이 문제이며 어떤 악영향으로 이어지는지에 대한 짧은 설명"을 몇 문장으로 배치할 것
Reproducer— 보안 (security) 팀이 그대로 빌드하여 재현할 수 있는, 자기 완결적인 스크립트나 코드를 첨부할 것
Patch— 불완전하더라도 좋으니 수정안을 제시할 것. "목표의 80%에 도달했다면 충분히 가치가 있다"
Versions— 어떤 버전에서 테스트했는지, 어디까지 거슬러 올라가야 재현되는지를 특정할 것
Collaborate— 던져두고 떠나지 말고, 평가·수정·어드바이저리 (advisory) 작성까지 함께할 것

AI에 대한 직접적인 언급은 단 한 곳뿐이다. "찾아내는 데, 혹은 작성하는 데 AI를 대량으로 사용했든 조금 사용했든 간에, 당신은 인간으로서 커뮤니케이션해야 한다". 요컨대, 발견 수단은 묻지 않겠다는 것이다. 질문되는 것은 자신이 발견한 것을 스스로 이해하고, 인간의 언어로 전달할 수 있느냐 하는 점이다. 재현 절차가 없는 장문의 글, 작성자 본인이 내용을 설명하지 못하는 보고서. AI로 부풀려진 바로 그것이 수신자의 시간을 가장 많이 뺏는다.

curl은 극단적인 사례처럼 보이지만, 사실 생성형 AI가 변화시킨 역학 관계의 축소판이라고 생각한다. 모델의 지능이 어떠냐의 문제보다, "생성은 저렴하고 검증은 비싸다"라는 비대칭성이 수신자 측의 운영을 서서히 망가뜨리고 있다. curl은 7명의 팀원이 한 달간 휴식을 취한다는 물리적인 수단으로 이에 저항했지만, 보다 근본적으로는 생성의 저렴함에 걸맞은 "검증의 자동화"나 "상류에서의 자기 검증 강제"를 어딘가에 추가하지 않으면, 도처에서 똑같은 벽에 부딪히게 될 것이다. 적어도 내가 AI에게 무언가를 report/PR 하게 만드는 입장이 될 때는, Stenberg의 체크리스트를 상대에게 강요하기 전에 스스로 먼저 통과시켜 두고 싶다.