- Authors

- Name
- 오늘의 바이브
cURL이 6년 만에 버그 바운티를 접었다

2026년 1월, Daniel Stenberg가 cURL의 버그 바운티 프로그램을 폐지했다. 6년 동안 운영해 온 프로그램이다. 총 지급액은 86,000달러. 한때 오픈소스 보안의 모범 사례로 꼽히던 제도가 사라졌다.
이유는 단순하다. 2025년 기준으로 버그 바운티 제출물의 20%가 AI가 생성한 보고서였다. 전체 제출물 중 실제로 유효한 것은 **5%**에 불과했다. 나머지 95%는 AI가 그럴듯하게 작성한, 실제로는 존재하지 않는 취약점에 대한 보고서였다. Stenberg와 그의 팀은 진짜 버그를 찾는 시간보다 가짜 보고서를 걸러내는 시간을 더 많이 써야 했다.
버그 바운티의 원래 목적을 생각해보자. 외부 보안 연구자가 취약점을 찾으면 보상을 주는 제도다. 공격자보다 먼저 버그를 찾겠다는 논리다. 그런데 AI가 이 제도를 악용하기 시작했다. AI는 코드를 분석해서 진짜 취약점을 찾는 것이 아니라, 그럴듯한 보안 보고서를 대량 생산한다. 형식은 완벽하다. CVE 번호를 인용하고, 공격 시나리오를 묘사하고, 재현 단계를 나열한다. 그러나 내용은 거짓이다. 존재하지 않는 함수에 대한 취약점 보고서, 이미 패치된 문제의 재탕, 아예 다른 라이브러리의 버그를 cURL의 것으로 돌린 보고서가 쏟아졌다.
cURL은 30년 가까이 유지되어 온 인터넷 인프라의 핵심이다. 전 세계 거의 모든 서버에 설치되어 있다. 그런 프로젝트의 보안 프로그램이, AI가 만들어낸 노이즈 때문에 폐지됐다. 이것이 바이브코딩 시대의 첫 번째 증거다.
Ghostty와 tldraw, 각자의 방식으로 문을 닫았다
cURL만의 문제가 아니다. Mitchell Hashimoto가 만든 터미널 에뮬레이터 Ghostty는 AI가 생성한 코드의 PR을 전면 금지했다. Hashimoto의 입장은 명확하다.
"이것은 반AI 입장이 아니다. 반바보 입장이다. Ghostty는 AI 도움을 받아 작성됐고, 우리 메인테이너 다수가 매일 AI를 사용한다. 우리는 단지 어떻게 만들어졌든 간에 양질의 기여를 원할 뿐이다."
핵심을 찌르는 말이다. 문제는 AI 자체가 아니다. AI를 도구로 쓰는 숙련된 개발자와, AI에게 전부를 맡기는 바이브코더 사이의 차이다. Hashimoto는 전자를 환영하고 후자를 차단한 것이다. 하지만 둘을 구분하는 것이 점점 어려워지고 있다. AI가 생성한 코드의 품질이 올라가면서, 숙련된 개발자가 AI로 작성한 코드와 비개발자가 AI로 만든 코드의 차이가 줄어들고 있다. Ghostty의 정책은 결국 자기 신고에 의존하는데, 솔직히 신고할 인센티브가 없다.
tldraw의 Steve Ruiz는 더 극단적인 방법을 택했다. 외부 PR을 전부 자동으로 닫는다. 심지어 자신이 AI 스크립트를 돌려서 이슈를 생성해 봤더니, 그 결과물이 형편없는 이슈였다는 것을 발견했다. Ruiz의 말이 인상적이다.
"코드를 작성하는 것이 쉬운 부분이라면, 왜 다른 사람이 그것을 작성하기를 원하겠는가?"
메인테이너에게 코드 작성은 가장 쉬운 일이다. 어려운 것은 설계 결정, 호환성 유지, 기술 부채 관리다. 바이브코더가 AI로 뚝딱 만들어 보낸 PR은 그 어려운 부분을 전혀 이해하지 못한 채로 쉬운 부분만 던져놓는 행위다.
세 프로젝트의 대응 방식이 다르다는 점이 흥미롭다. cURL은 보안이라는 특정 영역에서 문을 닫았다. Ghostty는 AI 생성 코드를 정책으로 금지하되, AI 보조 코드는 허용했다. tldraw는 아예 외부 기여 자체를 차단했다. 스펙트럼의 한쪽 끝에서 다른 쪽 끝까지, 공통점은 하나다. 메인테이너가 더 이상 감당할 수 없다는 것이다. 이들은 오픈소스의 베테랑이다. 수년간 외부 기여를 받아온 사람들이 문을 닫기로 결정했다는 것 자체가 상황의 심각성을 보여준다.
"AI Slopageddon"이라는 이름이 붙었다

RedMonk 애널리스트 Kate Holterhoff는 이 현상에 이름을 붙였다. "AI Slopageddon." AI가 만들어낸 슬롭(slop)이 대재앙(armageddon) 수준으로 밀려온다는 뜻이다. Holterhoff는 한 가지 불편한 예측도 했다. AI가 작성한 기여를 탐지하는 것이 **"1~2년 안에 사실상 불가능"**해질 것이라는 점이다.
이것은 단순한 불편함의 문제가 아니다. Stacklok의 공동 창업자 Craig McLuckie는 실제 상황을 이렇게 묘사한다.
"이제 'good first issue'로 라벨을 달면, 24시간도 안 돼서 저품질 바이브코딩 슬롭이 쏟아져 들어온다. 실제 일을 하는 시간을 빼앗긴다."
"Good first issue"는 오픈소스에 처음 기여하려는 신규 개발자를 위한 라벨이다. 새로운 개발자가 프로젝트에 입문하는 관문이었다. 이제 그 관문이 AI 봇과 바이브코더에게 점령당했다. 진짜 신규 개발자는 줄을 설 자리조차 없다. 24시간 안에 쏟아지는 PR 중에서 자신의 것이 선택될 확률은 거의 없다. 바이브코더의 속도를 사람이 이길 수 없으니까. 오픈소스의 인재 파이프라인 자체가 막히고 있다.
Flux CD의 핵심 메인테이너 Stefan Prodan은 더 날카로운 진단을 내렸다.
"AI 슬롭이 오픈소스 메인테이너에게 DDoS 공격을 하고 있다. 오픈소스를 호스팅하는 플랫폼들은 이를 막을 인센티브가 없다. 오히려 AI가 생성한 기여를 부풀려서 주주들에게 '가치'를 보여줄 인센티브가 있다."
DDoS라는 표현이 비유가 아니다. 메인테이너의 시간과 주의라는 자원을 고갈시킨다는 점에서, 이것은 정확히 서비스 거부 공격의 구조와 같다. 서버에 대한 DDoS는 트래픽으로 자원을 고갈시킨다. 메인테이너에 대한 DDoS는 저품질 PR과 이슈로 리뷰 시간을 고갈시킨다. 결과는 같다. 정상적인 서비스가 불가능해진다.
Prodan이 짚은 두 번째 포인트도 중요하다. 플랫폼의 인센티브 구조 문제다. GitHub, GitLab 같은 플랫폼은 활동 지표가 올라갈수록 좋다. PR이 많이 올라오면 "활발한 생태계"로 보인다. AI가 생성한 이슈가 늘어나면 "플랫폼 활용도 증가"로 포장된다. 플랫폼이 이 문제를 해결할 동기가 구조적으로 없다.
숫자가 말하는 생태계 붕괴
바이브코딩의 영향은 오픈소스 프로젝트에만 국한되지 않는다. 개발자 생태계 전체가 흔들리고 있다.
Stack Overflow는 ChatGPT 출시 후 6개월 만에 활동량이 25% 감소했다. 개발자들이 질문을 올리는 대신 AI에게 물어보기 시작한 것이다. Stack Overflow는 20년 넘게 축적된 프로그래밍 지식의 집합체다. 그 활동량이 4분의 1이나 줄었다는 것은, 새로운 지식의 축적도 그만큼 느려졌다는 뜻이다. 아이러니한 것은 AI 자체가 Stack Overflow의 과거 답변을 학습 데이터로 사용했다는 점이다. AI가 Stack Overflow를 학습해서 Stack Overflow를 대체하고 있다. 새로운 질문과 답변이 줄어들면, AI의 학습 데이터도 결국 고갈된다.
Tailwind CSS의 사례는 더 극적이다. 문서 트래픽이 40% 감소했고, 매출은 80%나 급락했다. Tailwind CSS는 유틸리티 우선 CSS 프레임워크로, 웹 개발자 사이에서 폭넓게 사용된다. 문서를 읽지 않는다는 것은 개발자들이 직접 학습하지 않는다는 의미다. AI가 대신 코드를 작성해주니까. 하지만 매출 80% 감소는 프로젝트의 지속 가능성 자체를 위협한다.
| 프로젝트 | 지표 | 변화 |
|---|---|---|
| cURL | 버그 바운티 유효율 | 5%로 하락, 프로그램 폐지 |
| Stack Overflow | 활동량 | ChatGPT 출시 후 25% 감소 |
| Tailwind CSS | 문서 트래픽 | 40% 감소 |
| Tailwind CSS | 매출 | 80% 급락 |
이 숫자들은 하나의 패턴을 보여준다. 바이브코딩은 오픈소스의 **수요 측(사용)**은 늘리면서 **공급 측(기여, 후원, 문서 참여)**은 줄이고 있다. AI가 패키지를 자동으로 선택하고 조립하니까 사용량은 올라간다. 하지만 사용자가 문서를 읽지 않고, 커뮤니티에 참여하지 않고, 후원하지 않으니까 프로젝트는 말라간다.
Tailwind CSS의 매출 80% 급락은 특히 시사점이 크다. Tailwind는 오픈소스이면서 동시에 상업적 제품(Tailwind UI)으로 수익을 올리는 모델이다. 이 모델은 개발자가 문서를 읽고, 프레임워크를 학습하고, 유료 컴포넌트를 구매하는 흐름에 의존한다. AI가 Tailwind 코드를 직접 생성해주면, 개발자가 문서를 방문할 이유가 사라진다. 문서 방문이 줄면 유료 제품 노출도 줄고, 매출이 따라 떨어진다. 이것은 Tailwind만의 문제가 아니다. "오픈소스 + 상업적 부가 서비스"라는 비즈니스 모델 전체가 위협받고 있다.
연구가 경고하는 구조적 위기
Central European University와 Kiel Institute의 공동 연구는 이 현상을 경제학 모델로 분석했다. 연구진은 AI 에이전트가 개발자의 관여 없이 오픈소스 패키지를 자동으로 선택하고 조립하는 행위를 **"바이브코딩"**으로 정의했다.
연구 결과는 직관과 다르다. AI가 개발자의 생산성을 높이면 오픈소스도 번성할 것이라는 낙관론이 있다. 더 많은 코드가 더 빠르게 작성되니까. 하지만 연구진의 결론은 정반대다. AI가 개발자의 생산성을 높이더라도, 오픈소스 소프트웨어의 가용성과 품질은 오히려 감소할 수 있다. AI를 통한 생산성 향상이 오픈소스 생태계의 지속 가능성을 보장하려면, AI 사용자들이 기존 직접 사용자가 기여하는 가치의 84%에 해당하는 기여를 해야 한다. 연구진은 이 임계값을 **"비현실적"**이라고 명시했다.
쉽게 말하면 이렇다. 지금까지 오픈소스는 "사용하는 사람이 기여도 한다"는 선순환으로 돌아갔다. 직접 코드를 쓰니까 버그를 발견하고, 문서를 읽으니까 오류를 고치고, 프로젝트에 의존하니까 후원했다. 바이브코딩은 이 연결고리를 끊는다. AI가 중간에서 패키지를 대신 선택하고 조립하면, 사용자는 자신이 어떤 오픈소스에 의존하고 있는지조차 모른다. 모르는 프로젝트에 기여할 리 없다.
84%라는 임계값이 비현실적인 이유도 분명하다. 바이브코더는 정의상 코드에 깊이 관여하지 않는 사용자다. AI에게 "이런 앱 만들어줘"라고 말하는 사람이 의존성 목록을 확인하고, 각 라이브러리의 GitHub 이슈를 살펴보고, 버그 리포트를 제출할 가능성은 거의 없다. 연구진이 "비현실적"이라고 한 것은 수사적 표현이 아니라 모델의 결론이다.
플랫폼은 왜 움직이지 않는가

일부 오픈소스 커뮤니티는 이미 행동에 나섰다. Gentoo Linux와 NetBSD는 AI가 생성한 기여를 전면 금지했다. 두 프로젝트 모두 수십 년 된 인프라 프로젝트로, 코드 품질에 대한 기준이 높다.
반면 Linux Foundation과 Apache는 다른 접근을 택했다. 품질 필터링보다는 라이선스 호환성과 "Generated-by:" 태그 부착에 초점을 맞추고 있다. AI가 작성한 코드인지 표시하라는 것이다. 의도는 이해할 수 있다. AI가 작성한 코드의 라이선스 출처를 추적해야 하니까. 그러나 Kate Holterhoff의 예측대로, AI 탐지가 1~2년 안에 불가능해진다면 이 접근법은 자발적 신고에만 의존하게 된다. 자발적으로 "이건 AI가 썼습니다"라고 밝히면 PR이 거부될 확률이 올라간다. 밝힐 인센티브가 없다.
가장 논란이 되는 것은 GitHub의 행보다. GitHub은 2025년 5월에 Copilot 이슈 생성 기능을 출시했다. AI가 이슈를 자동으로 만들어주는 기능이다. 문제는 메인테이너가 이를 필터링할 도구를 함께 제공하지 않았다는 것이다. 무기는 줬는데 방패는 안 준 셈이다.
Stefan Prodan의 지적이 정확하다. 플랫폼은 AI 기여를 막을 인센티브가 없다. AI가 만들어낸 PR, 이슈, 커밋은 모두 활동 지표로 잡힌다. 지표가 올라가면 투자자에게 보여줄 숫자가 생긴다. GitHub의 모회사인 Microsoft는 Copilot을 밀고 있다. Copilot이 생성한 코드가 GitHub에 더 많이 올라오는 것은 Microsoft에게 좋은 일이다. 메인테이너의 고통은 이 순환 구조에서 외부 비용(externality)으로 처리된다.
오픈소스를 호스팅하는 플랫폼이 오픈소스를 보호할 동기가 없다는 것. 이것이 구조적 문제의 핵심이다. Gentoo와 NetBSD처럼 전면 금지를 선택할 수 있는 프로젝트는 자체 거버넌스가 강한 곳뿐이다. GitHub에 의존하는 대다수 프로젝트는 플랫폼이 제공하는 도구의 범위 안에서만 대응할 수 있다. 그런데 그 플랫폼이 AI 기여를 줄일 동기가 없다면, 메인테이너는 혼자 싸워야 한다.
작은 프로젝트부터 죽는다
연구가 특별히 경고하는 대상이 있다. 작고 틈새한(niche) 프로젝트들이다. 연구진에 따르면 "인기 있는 라이브러리는 계속 후원자를 찾을 것"이지만, 소규모 프로젝트는 가장 큰 위험에 처해 있다.
이것은 직관적이다. React나 Linux 같은 대형 프로젝트는 기업 후원, 전담 메인테이너, 견고한 거버넌스 구조를 갖추고 있다. AI 슬롭이 몰려와도 이를 걸러낼 인력과 시스템이 있다. 하지만 메인테이너가 1~2명인 소규모 프로젝트는 다르다. 한 사람이 코드 리뷰, 이슈 관리, 릴리스, 문서 작성을 모두 맡고 있다. 여기에 AI가 생성한 PR과 이슈가 쏟아지면, 그 한 사람이 감당할 수 없는 부하가 걸린다.
연구진은 이렇게 묻는다. "작은 프로젝트의 메인테이너가 포기하면, 다음 Linux를 만들 사람은 누구인가?"
이 질문의 무게를 이해하려면 오픈소스의 역사를 봐야 한다. Linux는 헬싱키 대학의 학생 한 명이 시작했다. Git은 한 사람의 좌절에서 탄생했다. Node.js, SQLite, curl, 이 모든 것이 한두 명의 메인테이너가 시작한 소규모 프로젝트였다. 오픈소스 생태계의 다양성과 혁신은 이런 작은 프로젝트에서 나온다.
바이브코딩이 대형 프로젝트만 살리고 소형 프로젝트를 죽인다면, 오픈소스는 겉으로는 건재해 보이지만 안에서부터 경화(硬化)된다. 거대 프로젝트 몇 개만 남고, 실험적이고 혁신적인 작은 프로젝트들은 사라진다. 생태계의 다양성이 줄어들면, 결국 대형 프로젝트에도 혁신이 멈춘다. 새로운 아이디어는 작은 곳에서 시작되니까.
더 현실적인 위험도 있다. 소규모 프로젝트 중에는 대형 프로젝트의 의존성으로 깊숙이 박혀 있는 것들이 많다. left-pad 사건을 기억하는가. 11줄짜리 npm 패키지 하나가 삭제됐을 때 React, Babel, 수천 개의 프로젝트가 빌드 실패를 겪었다. 소규모 프로젝트의 메인테이너가 지쳐서 떠나면, 의존성 체인을 타고 대형 프로젝트까지 영향이 간다. 그리고 바이브코딩은 의존성 체인을 더 깊고 복잡하게 만든다. AI가 자동으로 패키지를 선택하면, 인간 개발자가 직접 선택할 때보다 더 많은 의존성이 추가되는 경향이 있다.
오픈소스의 사회 계약이 깨지고 있다
바이브코딩이 오픈소스를 죽이고 있다는 증거는 이제 충분하다. cURL의 버그 바운티 폐지, Ghostty의 AI PR 금지, tldraw의 외부 PR 자동 닫기, Stack Overflow 활동량 25% 감소, Tailwind CSS 매출 80% 급락, Gentoo와 NetBSD의 AI 기여 전면 금지. 각각은 개별 사건이지만, 합치면 하나의 패턴이 보인다.
오픈소스는 **사회 계약(social contract)**으로 작동해왔다. 만든 사람이 무료로 공개하고, 쓰는 사람이 버그를 보고하고, 고치고, 후원한다. 이 계약은 법적 구속력이 없다. 라이선스는 사용 권한만 규정할 뿐, 기여 의무는 없다. 그럼에도 이 계약이 유지된 것은 사용자가 동시에 개발자였기 때문이다. 코드를 직접 다루는 사람은 자연스럽게 프로젝트에 관여하게 된다.
바이브코딩은 이 계약의 "쓰는 사람" 부분을 AI로 대체했다. AI는 패키지를 선택하지만 버그를 보고하지 않는다. AI는 코드를 조립하지만 메인테이너를 후원하지 않는다. AI는 문서를 참조하지만 오류를 수정하지 않는다. 그리고 결정적으로, 바이브코더는 자신이 어떤 오픈소스를 사용하고 있는지 모르는 경우가 대부분이다.
남은 것은 이 계약을 어떻게 재구성할 것인가라는 질문이다. 바이브코딩을 금지할 수는 없다. 이미 개발자의 일상이 됐다. 그렇다면 바이브코딩의 수혜자가 오픈소스에 기여하는 새로운 메커니즘이 필요하다.
가능성은 몇 가지 있다. AI 도구를 만드는 회사가 오픈소스 생태계에 직접 기여하는 방식이 있다. Claude, Copilot, Codex 같은 도구가 오픈소스 코드를 학습 데이터로 사용하고 있으니, 그 가치의 일부를 생태계에 돌려주는 것이 논리적이다. 혹은 AI가 사용한 패키지를 자동으로 추적하고, 사용량에 비례하여 후원하는 시스템이 필요할 수도 있다. npm이나 pip 같은 패키지 매니저에 AI 사용 추적 기능을 넣고, 자동으로 마이크로 후원을 하는 구조다.
어떤 형태든 간에, 지금의 구조는 지속 가능하지 않다. 누군가는 코드를 유지해야 하는데, 그 누군가의 시간을 빼앗는 것이 바로 바이브코딩이니까. 오픈소스가 죽으면 바이브코딩도 죽는다. AI가 조립할 블록이 없어지니까. 바이브코딩의 최대 수혜자가 바이브코딩의 최대 피해자를 만들고 있는 이 역설을, 누군가는 풀어야 한다. 그 누군가가 오픈소스 메인테이너여서는 안 된다. 그들은 이미 충분히 지쳤다.
출처: