curl은 왜 한 달 동안 버그 제보를 껐을까 — 병목은 생성이 아니라 '검증'이다

2026년 7월 1일, curl 프로젝트가 HackerOne 취약점 제보 접수를 8월 3일까지 중단한다고 선언했다. 이름하여 "Summer of Bliss(행복한 여름)".

curl이 어떤 물건인지 생각해보면 꽤 충격적인 결정이다. 지구상 거의 모든 서버, 자동차, TV, 냉장고에 들어가 있는 소프트웨어가 보안 제보 창구를 한 달 동안 닫았다. 25년 넘게 프로젝트를 이끌어온 다니엘 스텐버그(Daniel Stenberg)가 내린 결정이다.

무슨 일이 있었던 걸까. 그리고 이게 우리 팀 코드베이스와 무슨 상관일까.

1. AI 슬롭이 삼킨 버그바운티

타임라인을 따라가 보면 이렇다.

2025년 중반 — 전체 제보의 20%가 이른바 "AI 슬롭(slop)". 존재하지 않는 취약점, curl에 아예 없는 코드 경로, 몇 년 전에 패치된 CVE를 재탕한 보고서들이 LLM으로 대량 생산돼 날아들었다.
확인율 붕괴 — 제보 중 실제 취약점 비율이 역사적 평균 15%에서 5% 미만으로 추락했다.
2026년 1월 — 포상금 제도(버그바운티) 자체를 폐지했다. "챗봇 한 번 돌려서 한탕 노리는" 금전적 유인을 제거한 것.
2026년 3월 — HackerOne 복귀. 슬롭은 거의 사라졌고 확인율도 15~16%로 회복됐다.
그런데 — 제보량이 2025년의 2배가 됐다. 2025년도 이미 예년의 2배였는데.

여기서 소름 돋는 포인트는 이거다. 품질 문제가 해결됐는데도 시스템은 계속 무너지고 있었다. AI가 만드는 제보의 질이 좋아질수록, 그걸 읽고 판별해야 하는 소수 자원봉사자들의 부담은 오히려 커졌다. 그럴듯해 보이니까, 진짜일지도 모르니까, 전부 읽어야 한다.

슬롭의 반대말은 품질이 아니다. 검증 용량이다.

2. 숫자로 보는 '검증 병목'

이게 curl만의 특수한 사정이라면 흥미로운 해외 토픽으로 끝났을 거다. 그런데 올해 나온 지표들을 모아보면, 같은 일이 모든 개발팀의 리뷰 큐에서 벌어지고 있다.

지표 (AI 도입 팀 기준)	변화
완료한 작업량	+21%
머지된 PR 수	+98%
PR 리뷰에 걸리는 시간	+91%
AI 생성 PR의 리뷰어 배정 대기 시간	4.6배

만드는 건 2배가 됐는데, 검증하는 시간도 2배 가까이 늘었다. 심지어 AI가 만든 PR은 리뷰어가 손대기 시작할 때까지 4.6배를 더 기다린다. 리뷰어들이 본능적으로 미루는 거다. 나도 그런다. "이거 diff 800줄인데 AI가 짰다고?" 싶으면 일단 다른 탭부터 열게 된다.

인식과 현실의 격차도 있다. METR의 실험에서 숙련된 오픈소스 개발자들은 AI를 쓰면서 "20% 빨라졌다"고 느꼈지만, 실측 결과는 19% 느려져 있었다. 39%p짜리 착시다.

더 불편한 숫자는 Sonar 조사에 있다. 개발자의 96%가 AI 코드를 완전히 신뢰하지 않는다고 답하면서, 커밋 전에 항상 검증한다는 사람은 48%뿐이었다. 못 믿는데 확인도 안 한다. 왜? 검증할 시간이 없으니까. 생성은 기계 속도로 일어나고, 검증은 인간 속도로 일어난다. 이 속도 차이가 쌓이는 곳이 바로 리뷰 큐다.

3. 병목은 사라지지 않는다, 이동할 뿐

제조업의 제약이론(Theory of Constraints)에는 유명한 명제가 있다. 공정 하나를 아무리 빠르게 만들어도 전체 산출량은 병목이 결정하고, 병목을 뚫으면 병목은 사라지는 게 아니라 다음 공정으로 이동한다.

개발 워크플로우에 그대로 대입해보면:

2023년 — 병목은 "코드 작성 속도" → 프롬프트 엔지니어링이 떴다
2025년 — 병목은 "맥락 전달" → 컨텍스트 엔지니어링이 떴다
2026년 상반기 — 병목은 "생성 파이프라인 운영" → 하네스 엔지니어링 (지난 글에서 다뤘다)
지금 — 코드 생성이 사실상 공짜가 되자, 병목은 검증으로 옮겨왔다

이 관점에서 보면 "AI 덕분에 나 혼자 3배 빨라졌다"는 말은 팀 전체로는 위험한 신호일 수 있다. 내 산출물이 3배가 됐다는 건, 누군가의 리뷰 큐에 3배의 검증 부채를 던졌다는 뜻이기도 하니까. curl의 제보자들도 각자는 "기여"를 했다고 믿었을 거다.

4. 그래서 뭘 해야 하나 — 검증 용량을 늘리는 4가지

① PR을 리뷰 가능한 크기로 강제하기. AI는 거대한 diff를 아무렇지 않게 만들어낸다. 사람이 한 호흡에 읽을 수 있는 단위로 쪼개는 건 이제 매너가 아니라 규율이다. 리뷰 시간이 91% 늘어난 팀과 아닌 팀의 차이가 여기서 갈린다.

② 기계가 거를 수 있는 건 기계에게. 타입 체크, 린트, 테스트, CI를 1차 방어선으로 세우고, 사람의 리뷰는 설계 의도와 경계 조건에만 쓴다. 사람이 세미콜론을 보고 있으면 그 팀의 검증 용량은 이미 바닥난 거다.

③ 생성한 사람이 검증 증거까지 첨부하기. "AI가 짜줬어요"로 끝내지 말고, 실행 로그·테스트 결과·직접 확인한 범위를 PR에 명시한다. curl이 제보자들에게 요구하게 된 것도 결국 이거다 — "재현 증거를 가져와라". 생성 비용이 0에 수렴할수록, 검증 증거가 신뢰의 화폐가 된다.

④ AI로 검증하되, 최종 서명은 사람 이름으로. 리뷰 에이전트로 1차 검토를 돌리는 건 유용하다. 다만 검증되지 않은 생성물을 검증되지 않은 생성물로 검사하는 순간, curl의 리뷰 큐가 우리 팀에 재현된다. 슬롭으로 슬롭을 검증할 수는 없다.

마무리 — 코드는 공짜가 됐다, 신뢰는 아니다

curl 사태가 보여주는 건 결국 이거다. AI 시대에 희소한 자원은 생성 능력이 아니라 검증된 신뢰다. 코드를 쏟아내는 능력은 이미 모두에게 주어졌고, 그래서 아무런 차별점이 되지 못한다.

앞으로의 채용 공고는 이렇게 바뀔지도 모른다. "코드를 잘 짜는 사람"이 아니라, "무엇을 믿어도 되는지 빠르게 판별하고, 자기 이름으로 서명할 수 있는 사람".

개발자의 경쟁력은 얼마나 많이 만들 수 있느냐에서, 얼마나 빨리 "이건 믿어도 된다"고 말할 수 있느냐로 이동하고 있다.

참고 자료

1. AI 슬롭이 삼킨 버그바운티

2. 숫자로 보는 '검증 병목'

3. 병목은 사라지지 않는다, 이동할 뿐

4. 그래서 뭘 해야 하나 — 검증 용량을 늘리는 4가지

마무리 — 코드는 공짜가 됐다, 신뢰는 아니다

관련 글