존재하지 않는 함수를 인용한 curl 버그 리포트

전체 연구 및 플러그인 → github.com/bcanfield/agentic-tech-debt

지난해 curl의 버그 바운티 (bug-bounty) 대기열 어딘가에 HTTP/3 취약점에 관한 자신감 넘치고 잘 정돈된 리포트 하나가 놓여 있었습니다. 그 리포트는 결함을 설명하고, 영향을 받는 함수를 명시하며, 수정 방안을 제안했습니다. 유일한 문제는 그 함수였습니다. curl에는 존재하지 않는 함수였습니다. 단 한 번도 존재한 적이 없었습니다. AI가 프로젝트에 결코 존재하지 않았던 코드에 대해 그럴듯한 보안 리포트를 작성했고, 인간은 이를 폐기하기 전에 그것이 잘못되었음을 알아차릴 만큼 충분히 읽어야만 했습니다.

그 리포트는 수천 건 중 하나일 뿐이며, 이번 달 기준으로 거의 주목할 만한 수준도 아닙니다. 제가 이 글을 쓰고 있는 2026년 6월 현재, curl에는 대략 18시간마다 하나의 버그 리포트가 접수됩니다. 대부분은 진짜가 아닙니다. 30년 가까이 curl을 유지 관리하며 대기열의 상당 부분을 직접 분류(triage)해 온 Daniel Stenberg는 그 수를 기록해 왔습니다. 현재 제출된 것 중 약 5개 중 1개는 AI 슬롭 (AI slop)의 특징을 띠고 있습니다. 20개 중 1개 정도만이 실제 취약점입니다. 나머지는 넓은 중간 지대에 속합니다. 즉, 인간의 시간을 요구할 만큼 충분히 진짜처럼 보이지만 결국 아무것도 아닌 것으로 판명되는 리포트들입니다.

수년 동안 대기열은 신중한 사람이라면 따라잡을 수 있는 수준의 적은 양이었습니다. 그러다 2025년에 그 양이 두 배 이상 늘어나 약 48시간마다 하나의 리포트가 접수되었고, 가상의 함수가 포함된 HTTP/3 리포트도 그 시기 어딘가에 등장했습니다. 2026년 1월 말, Stenberg는 참을 만큼 참았고, 버그 바운티는 종료되었습니다.

2026년 3월, 조수가 빠져나가자 버그 바운티(bounty)가 다시 재개되었습니다. 따라서 이것은 단순히 "AI가 curl 버그 바운티를 죽였다"라고 말할 수 있는 깔끔한 부고가 아닙니다. 상황은 더 조용하고 심각한 방식으로 악화되었습니다. 프로그램은 돌아왔고, 보고서의 양은 다시 늘어났으며, 6월에는 두 번째로 두 배가 되어 현재 우리가 겪고 있는 18시간 간격의 빈도에 도달했습니다. 중단 기간 동안 몇 달간의 안도감을 얻었지만, 곧 물은 새로운 만조 수위까지 차올랐습니다.

이에 대한 명백하고도 타당한 반론이 있습니다. 질 낮은 버그 리포트는 새로운 것이 아니라는 점입니다. 메인테이너(Maintainer)들은 아주 오래전부터 노력이 부족하고, 틀렸으며, 복사해서 붙여넣은 리포트들을 처리해 왔고, 버그 바운티는 심지어 사람들에게 그런 리포트를 보내는 대가로 비용을 지불합니다. 그렇다면 보고서의 수치가 올라간 것 외에 무엇이 변했을까요? 변한 것은 틀렸을 때의 비용을 누가 부담하느냐 하는 점입니다.

쓰레기 같은 리포트를 제출하는 인간은 적어도 그것을 직접 작성하기는 해야 했습니다. 그들은 그것을 만드는 데 자신의 시간을 소비했고, 이는 제출 속도를 제한했으며, 어떤 시점에는 사람이 그 글을 읽었다는 것을 의미했습니다. AI 리포트는 그 연결 고리를 끊어버립니다. 자신만만하고 형식이 완벽하게 갖춰진 취약점 보고서(vulnerability write-up)를 생성하는 비용은 거의 제로(0)로 떨어졌습니다. 하지만 그것이 사실인지 확인하는 비용은 떨어지지 않았습니다. 특정 HTTP/3 함수가 존재하는지 확인하려면 여전히 curl을 아는 사람이 소스 코드를 열어 부정적인 결과를 확인해야 합니다. 그 작업은 저렴해지지 않았습니다. 단지 옮겨졌을 뿐입니다. 제출자로부터, 이제 그 모든 것을 짊어지게 된 Stenberg에게로 말입니다. 우리는 이것을 부르는 이름이 있습니다: 외부효과 (externality). 제출자는 보상이나 단순히 "기여했다"는 도파민 같은 이득을 얻고, 메인테이너는 비용을 흡수합니다. 누구도 이를 결정하지 않았습니다. 비용은 그저 저렴한 리포트가 하나씩 쌓이면서 도로가 교통량으로 가득 차는 것처럼, 단순히 이동했을 뿐입니다.

	기존의 인간이 작성한 쓸모없는 리포트	AI 리포트
생성 비용	제출자 본인의 시간	거의 0으로 하락
...

제 개인 프로젝트가 저에게 이 상황의 축소판을 보여주었고, 그것은 제가 이 문제를 붙잡게 만들 정도로 충분히 당혹스러웠습니다. 저는 코딩 에이전트 (coding agents)에 연결되는 기술 부채 (tech-debt) 플러그인을 만들었는데, 그 후크 (hook) 중 하나는 사람들이 편법을 쓸 때 남기는 표식들인 TODO, FIXME와 같은 계열의 것들을 스캔합니다. 그런데 제가 기술 부채에 관한 글을 쓸 때는, 문장 속에

우리는 AI를 얼마나 빨리 결과물을 생성하느냐로 계속해서 측정하고 있습니다. 실제로 중요한 숫자는 그 결과물이 진짜인지 확인하기 위해 다운스트림 (downstream)의 누군가가 지불해야 하는 비용입니다. 그리고 AI는 검증하기에는 비싸고 생성하기에는 저렴한 것들을 만들어내는 데 매우 능숙합니다. 버그 리포트(bug report), 풀 리퀘스트(pull request), 타입 체커 (type checker)를 잠재우기 위해 any로 캐스팅된 함수 같은 것들 말이죠. 생성 비용은 저렴해졌지만 검증 비용은 그렇지 않았고, 그 격차는 결국 어딘가에 있는 인간에게 전가되어야 합니다. curl의 대기열은 단지 그 현상이 가장 명확하게 드러나는 사례일 뿐입니다. 왜냐하면 18시간마다 한 명의 특정 개인에게 청구서가 전달되기 때문입니다. 저는 코드베이스 내부에서 발생하는 이러한 현상을 위해 debt-ops라는 플러그인을 작성했습니다. 이 플러그인은 에이전트 (agent)가 미룬 결정들을 기록하게 하여, 그 비용이 조용히 누적되는 대신 사람이 볼 수 있는 곳에 남도록 합니다. 이것이 Stenberg의 편지함 문제를 해결해주지는 못할 것입니다. 보상 대기열 (bounty queue)은 리포지토리 (repo)와는 다른 영역이며, 저는 그렇지 않은 척하지 않겠습니다. 하지만 이 아이디어는 이슈 트래커 (issue tracker)가 아닌 소스 트리 (source tree) 내부에서, 그가 설명하는 것과 동일한 비대칭성을 응시하는 데서 나왔습니다. 만약 그 비대칭성이 여러분에게도 신경 쓰인다면, 코드는 github.com/bcanfield/agentic-tech-debt에 있습니다.

HTTP/3 리포트는 이 혼란스러운 상황에서 여전히 제가 가장 좋아하는 유물입니다. 다소 암울한 방식으로 말이죠. AI가 한 번도 작성된 적 없는 함수에서 취약점을 발명해냈고, 시스템은 설계된 대로 정확하게 작동했습니다. 리포트는 사람이 읽었고, 소스 코드와 대조하여 확인했으며, 허위임을 확인하고 종료했습니다. 모든 것이 기능했습니다. 단지 curl 유지 관리자 (maintainer)가 아무 일도 일어나지 않았음을 확인하는 데 한 시간을 소비했을 뿐입니다. 이 일을 영원히 18시간마다 반복한다면, 과연 누구를 위한 서비스인지 저에게 말해 보십시오.

커버 사진: Unsplash의 Christa Dodoo.