바이브 코딩이 오픈소스를 죽인다는 논문

Tailwind CSS 문서 트래픽이 40% 빠졌다

코드 에디터 화면 — 바이브 코딩 시대, 개발자는 더 이상 문서를 읽지 않는다

2023년 초, ChatGPT가 세상에 나온 직후. Tailwind CSS의 창시자 Adam Wathan은 이상한 현상을 감지했다. npm 다운로드 수는 꾸준히 오르는데, 공식 문서 사이트 방문자가 줄기 시작한 것이다. 처음에는 일시적인 변동이라고 생각했다.

3년이 지난 지금, 문서 트래픽은 40% 하락했다. Tailwind CSS를 쓰는 사람은 늘었는데, 문서를 읽는 사람은 줄었다. Wathan은 이렇게 말했다. "문서가 우리 상업 제품을 알리는 유일한 통로인데, 고객이 없으면 프레임워크를 유지보수할 수 없다."

Tailwind Labs는 직원 3명을 해고했다. 오픈소스 프로젝트가 인기를 얻으면서 동시에 수익이 줄어드는 역설. 이것이 바이브 코딩이 오픈소스에 가하는 첫 번째 타격이다.

2026년 1월, 중앙유럽대학교(CEU)와 킬 세계경제연구소의 경제학자 4명이 이 현상을 학술적으로 분석한 논문을 arxiv에 올렸다. 제목은 "Vibe Coding Kills Open Source". 직역하면 "바이브 코딩이 오픈소스를 죽인다"다.

논문이 말하는 핵심 메커니즘

이 논문의 저자는 Miklós Koren, Gábor Békés(중앙유럽대학교), Julian Hinz, Aaron Lohmann(킬 세계경제연구소)이다. 이들은 경제학자다. 컴퓨터 과학자가 아니라 경제학자가 오픈소스 생태계를 분석했다는 점이 독특하다.

논문의 핵심 주장은 이렇다. 바이브 코딩은 사용과 참여를 분리한다. 개발자가 "채팅창에 요청하고, AI가 코드를 생성하고, 개발자가 결과를 받아들이는" 과정에서 오픈소스 메인테이너와의 모든 접점이 사라진다.

전통적인 오픈소스 생태계는 이렇게 작동했다. 개발자가 라이브러리를 쓰려면 문서를 읽는다. 문서를 읽다가 버그를 발견하면 이슈를 올린다. 이슈를 올리다가 코드를 이해하면 PR을 보낸다. PR을 보내다가 커뮤니티에 합류한다.

이 과정에서 메인테이너는 세 가지 보상을 받는다. 첫째, 버그 리포트와 피드백으로 코드 품질이 올라간다. 둘째, 커뮤니티 인지도와 평판이 쌓인다. 셋째, 문서 트래픽을 통해 상업적 수익을 올릴 수 있다. Tailwind CSS, Next.js, Astro 같은 프로젝트가 이 모델로 운영된다.

바이브 코딩은 이 순환을 끊는다. AI가 라이브러리를 대신 선택하고, 대신 설치하고, 대신 사용 코드를 짠다. 개발자는 문서를 읽지 않는다. 이슈를 올리지 않는다. 커뮤니티에 참여하지 않는다. 라이브러리가 뭔지도 모르는 경우가 있다.

논문은 이 현상을 **"사용과 참여의 디커플링(decoupling)"**이라 부른다. 과거에는 사용이 곧 참여였다. 라이브러리를 쓰면 자연스럽게 생태계에 기여했다. 이제 사용은 있지만 참여는 없다. AI가 그 사이에 끼어들었기 때문이다.

일반 균형 모델이 보여주는 미래

논문의 방법론이 흥미롭다. 저자들은 오픈소스 생태계를 **일반 균형 모델(General Equilibrium Model)**로 구성했다. 경제학에서 시장 전체의 수요와 공급을 동시에 분석할 때 쓰는 프레임워크다.

모델에는 세 가지 변수가 있다. 첫째, 메인테이너의 진입 결정. 새로운 오픈소스 프로젝트를 시작할지 말지. 둘째, 프로젝트의 이질적 품질. 모든 프로젝트가 같지 않다. 셋째, 사용자의 선택. 직접 코드를 쓸지, AI에게 시킬지.

바이브 코딩이 확산되면 모델은 세 가지 결과를 예측한다.

첫째, 메인테이너 진입 감소. 보상이 줄어들면 새로운 프로젝트를 시작하는 사람이 줄어든다. 기존 메인테이너도 유지보수를 중단할 유인이 생긴다. Tailwind Labs의 해고가 이미 현실에서 벌어지고 있다.

둘째, 코드 품질 하락. 버그 리포트가 줄면 메인테이너가 문제를 인지하기 어렵다. AI가 생성한 코드는 문서화된 이슈를 잘 반영하지 못한다. 품질 피드백 루프가 끊기면 코드는 천천히 부패한다.

셋째, 사회적 후생 감소. 생산성은 올라가는데 후생은 떨어진다. 역설적이다. 논문의 표현을 빌리면 "생산성이 올라도 오픈소스의 가용성과 품질이 떨어지면 전체 사회적 후생은 감소한다."

이 모델의 핵심은 **외부 효과(externality)**다. 바이브 코딩 사용자는 자기 생산성이 올라가는 이득을 취하지만, 오픈소스 생태계가 약화되는 비용은 모두가 분담한다. 공유지의 비극과 구조가 같다.

Stack Overflow는 이미 무너졌다

논문이 이론적 모델이라면, 현실의 데이터는 더 직접적이다.

Stack Overflow의 트래픽은 ChatGPT 출시 후 6개월 만에 약 25% 하락했다. 2024년에는 하락세가 더 가팔라졌다. 개발자들이 공개 Q&A 대신 비공개 AI 채팅을 이용하기 시작한 것이다.

Stack Overflow는 단순한 Q&A 사이트가 아니었다. 오픈소스 생태계의 비공식 지원 채널이었다. 라이브러리에 문제가 있으면 Stack Overflow에 질문이 올라왔다. 메인테이너는 이 질문을 보고 버그를 인지했다. 다른 개발자들이 답변을 달면서 문서에 빠진 사용법이 공유됐다.

이 모든 것이 공개적이었다는 게 중요하다. Stack Overflow의 질문과 답변은 검색 가능하고 누구나 볼 수 있다. AI 채팅은 비공개다. 한 개발자가 "이 라이브러리에서 이런 에러가 난다"고 Claude에게 물으면, 그 정보는 그 개발자와 Anthropic의 서버 사이에서만 존재한다. 메인테이너는 모른다. 다른 개발자도 모른다.

Hackaday의 분석에 따르면, AI가 생성한 코드는 문서화된 이슈에 대한 인식이 부족하다. LLM의 학습 데이터에 오래된 코드가 포함돼 있기 때문이다. 이미 수정된 버그를 다시 만들어내거나, 폐기된 API를 사용하는 경우가 빈번하다.

더 심각한 건 버그 리포트의 질이다. 바이브 코딩으로 만든 프로젝트에서 에러가 생기면, 개발자가 이슈를 올려도 내용이 부실하다. 코드를 이해하지 못하기 때문이다. "AI가 만든 코드인데 안 돼요"라는 이슈는 메인테이너에게 디버깅 정보를 주지 못한다.

오픈소스 메인테이너 입장에서 생각해 보자. 예전에는 이슈가 올라오면 재현 가능한 코드 스니펫, 환경 정보, 시도해 본 해결책이 함께 왔다. 이제는 AI가 생성한 코드 덩어리와 "에러가 납니다"라는 한 줄이 전부인 이슈가 늘고 있다. 메인테이너는 답할 수 없고, 답하지 않으면 이슈는 방치된다. 이 악순환이 반복되면 메인테이너의 번아웃은 가속화된다.

LLM이 선택하는 라이브러리의 편향

GitHub 로고 — 오픈소스 프로젝트의 발견 경로가 AI로 바뀌고 있다

바이브 코딩의 또 다른 문제는 라이브러리 선택의 편향이다. AI에게 "HTTP 요청을 보내는 코드를 짜줘"라고 하면 높은 확률로 axios를 추천한다. "날짜를 다루는 코드를 짜줘"라고 하면 moment.js를 추천한다. moment.js는 2020년에 유지보수가 중단된 라이브러리인데도.

LLM은 학습 데이터에 가장 많이 등장하는 라이브러리를 추천하는 경향이 있다. 이건 인기 투표와 같다. 가장 많이 쓰이는 라이브러리가 가장 많이 추천되고, 가장 많이 추천되니 더 많이 쓰이고, 더 많이 쓰이니 다음 학습 데이터에 더 많이 포함된다.

이 순환은 승자 독식 구조를 만든다. 이미 인기 있는 라이브러리는 더 인기를 얻고, 작은 프로젝트는 발견되지 못한다. 논문 저자들은 이것을 "통계적으로 빈번한 의존성만 현실적으로 LLM 출력에 나타난다"고 표현했다.

인간 개발자가 라이브러리를 선택하는 과정은 다르다. GitHub에서 검색하고, 비교하고, README를 읽고, 이슈 목록을 확인하고, 최근 커밋 이력을 본다. 이 과정에서 작지만 잘 만들어진 프로젝트를 발견할 수 있다. AI는 이 탐색 과정을 생략한다.

항목	인간 개발자	AI(바이브 코딩)
라이브러리 선택	검색, 비교, README 읽기	학습 데이터 기반 추천
문서 방문	직접 읽고 참고	건너뜀
버그 발견 시	이슈 리포트, PR	AI에게 우회 요청
커뮤니티 참여	포럼, 디스코드, 컨퍼런스	없음
새 프로젝트 발견	가능	어려움

결과적으로 오픈소스 생태계의 다양성이 줄어든다. 소수의 대형 프로젝트만 살아남고 나머지는 서서히 사라진다. 이건 NPM 생태계의 left-pad 사건보다 더 구조적인 문제다. left-pad은 하나의 패키지가 삭제돼서 생긴 위기였지만, 바이브 코딩은 생태계 전체의 다양성을 잠식한다.

Spotify 모델은 답이 될 수 있나

논문 저자들은 해결책도 제시한다. OpenAI, Anthropic, Google 같은 AI 회사가 LLM이 사용하는 오픈소스 라이브러리를 **미터링(metering)**하고, 그 사용량에 기반해 수익을 분배하자는 것이다.

기술적으로는 단순하다. LLM이 코드를 생성할 때 어떤 라이브러리를 임포트하는지 추적하면 된다. import axios from 'axios'가 100만 번 생성됐다면 axios 메인테이너에게 그에 비례하는 수익을 분배한다.

Hackaday 기사는 이 모델을 Spotify 비유로 설명한다. 그리고 바로 문제점을 지적한다. Spotify에서 아티스트의 80%는 거의 수익을 얻지 못한다. 상위 1%가 수익의 대부분을 가져간다. Taylor Swift는 수백만 달러를 벌지만, 인디 뮤지션은 월 몇 달러를 받는다.

오픈소스에 같은 모델을 적용하면 어떻게 될까. React, Express, Lodash 같은 대형 프로젝트는 상당한 수익을 올리겠지만, 나머지 프로젝트에는 의미 없는 금액이 돌아간다. 기존의 승자 독식 구조를 수익 분배에서도 반복하는 셈이다.

더 근본적인 문제가 있다. 돈으로 해결되는 게 아니라는 것이다. 오픈소스 메인테이너의 동기는 복합적이다. 순수한 기술적 호기심, 커뮤니티 소속감, 경력 개발, 자아실현. 돈은 그 일부일 뿐이다. 커뮤니티가 사라지고 피드백이 사라지면, 돈이 있어도 동기가 꺼진다.

Flask의 창시자 Armin Ronacher도 비슷한 입장이다. AI의 영향을 인정하면서도 "결론을 내리기엔 아직 이르다"고 신중론을 펼쳤다. 하지만 Tailwind Labs의 해고는 이미 벌어진 일이다.

논문이 제시하는 또 다른 대안은 공적 자금 투입이다. 오픈소스를 사회 기반 시설로 취급하고, 도로나 다리처럼 정부가 유지보수 비용을 부담하자는 것이다. 유럽연합의 NLnet 재단이나 미국의 NSF 같은 기관이 오픈소스에 투자하는 사례가 있지만, 규모가 너무 작다. 논문 저자들은 이 접근이 시장 실패를 보정할 수 있는 유일한 구조적 해법이라고 본다.

41%의 버그, 19%의 생산성 하락

오픈소스 생태계만의 문제가 아니다. 바이브 코딩으로 만들어진 코드 자체의 품질도 의문이다.

2024년 Uplevel의 연구에 따르면, GitHub Copilot을 사용한 개발자들은 코드를 55% 빠르게 작성했지만 버그가 41% 더 많았다. 약 800명의 개발자를 대상으로 한 조사에서 Copilot 접근권이 있는 351명의 코드를 분석한 결과다.

2025년 METR의 무작위 대조 시험은 더 충격적이었다. 경험 많은 오픈소스 개발자 16명이 AI 도구를 사용했을 때 오히려 19% 느려졌다. 본인들은 20% 빨라졌다고 믿었는데. 실제와 체감 사이 39%포인트의 괴리가 존재했다.

이 데이터들을 종합하면 우려스러운 그림이 나온다. 바이브 코딩으로 생산된 코드는 더 많은 버그를 포함한다. 그 버그가 오픈소스 라이브러리와 관련돼 있을 때, 과거라면 Stack Overflow나 GitHub 이슈를 통해 발견되고 수정됐다. 이제는 아니다. AI에게 물어보고, AI가 다른 우회 코드를 만들어주고, 버그는 방치된다.

Hackaday의 표현을 빌리면, 바이브 코딩은 "인간 지능에 대한 스트레스 테스트이지 생산성이나 코드 품질에 대한 실질적 향상이 아니다." 코드를 더 빨리 쓰는 건 맞다. 하지만 그 코드가 더 많은 버그를 품고 있고, 그 버그가 발견되지 않는 구조라면, 생산성이라는 단어의 정의를 다시 생각해야 한다.

논문 저자들은 JavaScript와 Python이 가장 먼저 영향을 받는 언어라고 지적한다. LLM 학습 데이터에 가장 많이 포함돼 있고, 바이브 코딩을 수용하는 개발자 비율이 높고, 패턴 기반의 반복적 코드가 많기 때문이다. 반면 Rust나 Haskell 같은 언어는 학습 데이터가 상대적으로 적어 아직 영향이 크지 않다. 하지만 AI 모델의 학습 데이터가 계속 확장되면 이 언어들도 시간문제다.

오픈소스의 가치는 0.1%만 돌아간다

이 논문이 제기하는 문제의 배경에는 오래된 구조적 불균형이 있다. 오픈소스 소프트웨어의 경제적 가치 대비 메인테이너에게 돌아가는 몫이 극도로 적다는 것이다.

하버드 비즈니스 스쿨의 연구에 따르면, 오픈소스가 창출하는 경제적 가치의 0.1%만이 실제 개발자에게 돌아간다. 나머지 99.9%는 오픈소스를 사용하는 기업이 가져간다. FAANG부터 스타트업까지, 모두 오픈소스 위에서 사업한다. 하지만 기여는 미미하다.

이 구조에서 바이브 코딩은 상황을 악화시킨다. 기존에는 최소한 개발자들이 직접 사용하면서 생기는 간접적 기여가 있었다. 버그 리포트, 문서 개선, Stack Overflow 답변, 컨퍼런스 발표. 이것들이 메인테이너에게 돌아가는 비금전적 보상이었다.

바이브 코딩은 이 비금전적 보상마저 줄인다. 개발자가 라이브러리를 "사용"하지만 "접촉"하지 않으면, 메인테이너는 사용자가 있는지도 모른다. npm 다운로드 수만 올라갈 뿐, 실질적 상호작용은 제로다.

Anthropic CEO Dario Amodei는 자사 코드의 70~90%가 Claude로 작성된다고 공개적으로 밝힌 바 있다. AI 회사조차 바이브 코딩을 적극적으로 활용한다. 그 과정에서 수많은 오픈소스 라이브러리가 사용되지만, 메인테이너와의 접점은 없다.

이건 기술 문제가 아니라 경제 구조의 문제다. 논문이 경제학자에 의해 쓰인 이유가 여기에 있다. 오픈소스는 공공재의 성격을 가진다. 공공재는 시장에 맡기면 과소 공급된다. 바이브 코딩은 이 과소 공급을 가속화한다.

EU의 Cyber Resilience Act가 오픈소스 프로젝트에도 보안 의무를 부과하기 시작한 것도 이 맥락에서 아이러니하다. 정부는 오픈소스에 더 많은 책임을 요구하면서, 그 유지보수를 가능하게 하는 생태계가 무너지는 것은 방관하고 있다. 한쪽에서는 규제를 강화하고 다른 쪽에서는 보상이 줄어드는 이중고다.

생태계는 코드가 아니라 관계다

논문의 결론은 단호하다. "현재 규모의 오픈소스를 바이브 코딩 시대에 유지하려면 메인테이너 보상 방식의 근본적 변화가 필요하다."

하지만 이 논문만으로 모든 걸 판단하기엔 이르다. 반론도 존재한다. AI가 새로운 개발자를 오픈소스로 유입시키는 효과도 있다. 프로그래밍 경험이 없던 사람이 AI의 도움으로 첫 프로젝트를 만들고, 그 과정에서 오픈소스에 관심을 가질 수 있다. Hackaday 기사의 댓글에서도 일부 개발자들이 AI를 통해 오히려 오픈소스에 기여하게 됐다는 경험을 공유했다.

또한 GitHub Copilot, Cursor, Claude Code 같은 도구들이 오픈소스 기여를 더 쉽게 만드는 측면도 있다. 낯선 코드베이스를 빠르게 이해하고, 테스트를 작성하고, PR을 만드는 과정에서 AI가 진입 장벽을 낮춘다.

그러나 이 긍정적 효과가 부정적 효과를 상쇄하는지는 아직 검증되지 않았다. Tailwind의 40% 트래픽 하락, Stack Overflow의 25% 이용 감소, 메인테이너의 번아웃 증가. 데이터는 부정적 방향을 가리키고 있다.

오픈소스 생태계는 코드의 집합이 아니다. 관계의 집합이다. 개발자가 라이브러리를 선택하고, 사용하고, 피드백을 주고, 기여하는 관계. 이 관계가 없으면 코드만 남는다. 유지보수되지 않는 코드. 버그가 수정되지 않는 코드. 결국 아무도 쓸 수 없는 코드.

바이브 코딩이 오픈소스를 "죽이는지"는 아직 단정하기 어렵다. 하지만 약하게 만들고 있다는 건 확실하다. AI가 코드를 대신 짜주는 시대에, 사라지는 건 타이핑이 아니라 개발자와 생태계 사이의 유대다. 그 유대가 없으면 오픈소스는 껍데기만 남는다.

다음에 AI에게 코드를 시킬 때, 한 번쯤 생각해 봐야 한다. 이 코드가 의존하는 라이브러리의 메인테이너가 누구인지. 그 사람이 지금도 무보수로 유지보수를 하고 있는지. 그리고 내가 그 사람에게 무언가를 돌려주고 있는지.

출처: