Cover · Issue 065
"문은 하나 열렸다. 그 뒤로 쌓인 것은 통로에서는 보이지 않는다."
TSTF MAG · 2026
2025년부터 2026년 초까지 오픈소스 보안 신고함을 두고 도는 이야기는 하나였다. AI가 순식간에 찍어낸 그럴듯한 가짜 신고, 이른바 "슬롭"이 메인테이너를 마비시킨다는 것. 그런데 그 이야기의 한복판에 있던 사람이 2026년 4월, 다른 말을 썼다.
curl은 이 소문의 한복판에 있던 프로젝트였다. HackerOne을 통해 들어오는 취약점 신고가 AI 도구로 인해 쓰레기 더미가 됐다는 이야기가 2025년 내내 개발자 커뮤니티를 돌았다. 형식은 그럴듯한데 내용은 비어 있는 신고, 메인테이너 한 명이 재현도 안 되는 리포트를 붙잡고 시간을 태우는 장면 — 그게 "슬롭" 서사의 핵심이었다. 이번에 우리 데스크에서 읽은 글은 그 소문의 당사자, curl 창시자 Daniel Stenberg가 2026년 4월 22일 자기 블로그에 올린 「High-Quality Chaos」였다.
제목부터 심상치 않았다. 그리고 첫 줄에서 소문과 어긋나는 문장이 나왔다. "The slop situation is not a problem anymore." 슬롭은 더 이상 문제가 아니라는 것이다. 2026년 3월 HackerOne에 복귀한 뒤로, 들어오는 신고의 성격 자체가 달라졌다고 그는 썼다.
여기서 끝났다면 흔한 해피엔딩 기사였을 것이다. 그런데 Stenberg는 안도하지 않았다.
같은 글에서 그는 수치를 댔다. 확인된 취약점 비율이 2024년, AI 이전 수준을 회복하고 넘어 15~16% 범위로 돌아왔다. 신고 하나를 열었을 때 그게 진짜일 확률이 예전만큼, 혹은 그 이상으로 높아졌다는 뜻이다.
문제는 그다음이다. 신고 빈도는 2025년의 약 두 배였고, 그 2025년도 이전 몇 년보다 이미 두 배 이상 많았다. 품질은 돌아왔는데 물량은 계속 불었다. 예전엔 열 건 중 진짜 한둘을 골라내면 됐다면, 지금은 그 비율은 회복됐는데 열어야 할 전체 건수 자체가 늘어난 셈이다. 골라내는 눈은 좋아졌는데, 골라낼 게 더 많아졌다.
RedMonk는 2026년 5월 5일 분석에서 이 구조를 다른 각도로 짚었다. 그럴듯한 취약점 신고 하나를 만드는 데 드는 비용은 토큰 몇 푼이다. 그런데 그걸 재현하고 검증하는 데는 전문가 시간 약 1시간이 든다. 만드는 쪽 비용과 받는 쪽 비용은 애초에 같은 저울에 달리지 않는다.
"This avalanche is going to make maintainer overload even worse. Some projects will have a hard time to handle this kind of backlog expansion without any added maintainers to help."
— Daniel Stenberg · curl 메인테이너 · 「High-Quality Chaos」, 2026.04.22curl은 2019년부터 운영해온 버그 바운티를 2026년 1월 끝냈다. 그 창구를 통해 확인된 취약점은 87건, 지급한 보상은 10만 달러가 넘는다. 숫자만 보면 잘 굴러가던 프로그램이다. 그런데도 접었다. 진짜를 골라내는 비용이 감당 범위를 넘었다는 뜻으로 읽힌다.
Node.js 쪽 대응은 결이 다르다. HackerOne 최소 Signal 점수를 신규 연구자에게 걸어두고, 그 문턱을 넘기 전에는 OpenJS 재단 Slack에서 사람과 먼저 대화하도록 게이트를 세웠다. 신고함을 닫는 대신, 입구에 사람 한 명을 세운 셈이다.
두 조직 다 "신고를 막자"고 말한 적은 없다. 다만 지금 들어오는 양을 그대로 받아내는 구조는 이미 무너졌다는 걸, 각자 다른 방식으로 인정한 것이다. 하나는 창구를 접었고, 다른 하나는 창구 앞에 사람이 앉는 대기실을 새로 만들었다. 둘 다 "받는 쪽 용량"을 손보는 결정이었다는 점은 같다.
검증 시간을 실제로 내는 쪽은 대체로 그 저장소를 오래 붙잡고 있는 소수다. curl이 창구를 접은 것도 지급한 10만 달러가 아까워서가 아니라, 진짜와 진짜 아닌 것을 가려내는 데 드는 사람 시간이 먼저 바닥났다는 쪽으로 읽힌다.
Screenly의 Viktor Petersson은 6개월이 안 되는 기간 동안 신고 331건을 받았고, 그중 진짜는 39건이었다고 밝혔다. 결국 그는 자체 분류 도구를 만들고 검토를 여러 팀에 나눠 맡겼다.
당신 팀에도 비슷한 자리가 있을 것이다. 유저 버그 제보나 치트 신고가 AI 도구를 거쳐 갑자기 정교해진 뒤, QA 큐 앞에 쌓인 티켓 중 무엇부터 열어야 할지 정하는 자리. 혹은 자동 생성 테스트가 뽑아낸 결함 목록이 전부 "사실"이라서, 무엇부터 고칠지가 회의 시간의 절반을 잡아먹는 자리.
리뷰도 마찬가지다. PR이 늘고 다 그럴듯해 보이면, 리뷰어 한 명이 순식간에 병목이 된다. 만드는 쪽은 사람 시간이 아니고, 검토하는 쪽은 여전히 사람 시간이다. 이 비대칭은 코드 리뷰든 취약점 신고든 똑같이 적용된다.
우리 데스크는 이번 자료를 읽으며 처음엔 "AI가 오픈소스를 망친다"는 익숙한 결론을 예상했다. 그런데 Stenberg가 실제로 한 말은 정반대에 가까웠다 — 걸러낼 쓰레기가 사라진 뒤에야, 진짜 일이 감당 못 할 만큼 남아 있었다는 관찰이다. 우리는 이쪽이 더 정확한 진단이라고 본다. 보내는 쪽 비용이 0에 가까워지는 동안 받는 쪽 용량을 그대로 둔다면, 어느 조직이든 결국 curl과 같은 결정 앞에 서게 된다.