kentakang
2026. 04. 13
이 기가막힌 썸네일은 Gemini 3 Pro가 생성해줬습니다. 저 AI 좋아하고 자주 활용해요. 진짜입니다.
Claude Code의 출시 이후로 개발자의 업무 형태는 전례 없는 속도로 가장 빠르고 공격적으로 변하고 있습니다.
여러분이 실제 업무에서 AI 개발 도구를 쓰고 있든 아니든, 지금 Vibe coding1 열풍이 불고 있다는 사실만큼은 체감하고 계실 겁니다.
이는 당연히 오픈소스 커뮤니티에도 큰 영향을 가져왔고, 아직까지는 그 영향에 대한 의견들이 사람마다 갈리고 있습니다. Vibe Coding이 오픈소스에 긍정적인 영향을 주고 있다는 논조의 아티클도 많고, 부정적인 논조의 아티클도 많습니다. 아직은 결론이 지어지지 않은 논쟁인거죠.
저는 Vibe Coding이 오픈소스 커뮤니티를 망치고 있다고 생각하는 사람 중 한명입니다.
물론 AI 개발 도구를 모두 싫어하는 것은 아닙니다, 저는 실제로 Claude Code나 Codex CLI와 같은 에이전트 개발 도구를 업무에 도입해 사용하고 있고, 실제로 생산성이 많이 개선되었다고 느끼고 있습니다. (정량적 계산은 없지만요)
하지만, 이게 오픈소스 커뮤니티에도 긍정적인 변화를 가져오고 있다고 생각하지는 않습니다.
이번 글에서는 제가 생각하는 Vibe Coding이 오픈소스 커뮤니티에 가져오고 있는 변화들과, 긍정적으로 생각하지 않는 이유에 대해 간단하게 얘기해보도록 하겠습니다.
AI 개발 도구의 등장은, 오픈소스 프로젝트에 대한 기여 난이도를 획기적으로 낮췄습니다.
이전에는 프로젝트에 기여하기 위해서 기존 소스코드 베이스를 파악하고, 그에 맞춰 내가 수정하고자 하는 이슈 사항을 수정하는 등 어느정도 기술적인 베이스가 있지 않은 경우 프로젝트에 기여하기가 어려웠습니다.
AI 개발 도구의 등장 후에는 수정하고자 하는 이슈 사항이 무엇인지만 있으면 에이전트에게 요청해서 딸깍으로 수정할 수 있기 때문에 외부 기여가 엄청나게 쉬워졌습니다.
외부 기여가 쉬워지면 기여자도 좋고, 기존 개발 리소스가 부족해서 힘들어하던 오픈소스 유지관리자에게도 도움되는 일 아닌가요?
네, 제 생각에는 아닙니다. AI를 활용해 간단해진 외부 기여가 갖고온 문제들은 뭐가 있을까요?
검토하기 힘들어요 ㅠㅠ (https://github.com/tldraw/tldraw/issues/7695)
가장 큰 문제는 AI Slop 코드의 난립입니다.
위에서 얘기한대로 AI 딸깍으로 프로젝트의 수정이 가능해지다보니, 기존 프로젝트에 대한 이해도 없이 저품질의 수정을 마구잡이로 PR로 등록해버리는 경우들이 많아졌습니다.2
문제는 개발자가 딸깍으로 수정을 등록하는 건 간단하지만, 오픈소스 프로젝트의 유지보수자는 그렇게 딸깍으로 생긴 PR을 모두 상세하게 검토해야 한다는 점입니다.
이런 Slop PR들을 계속해서 상대하다보니 오픈소스 메인테이너들은 이미 부족한 개발 리소스를 더욱 더 의미 없는 곳에 뺏기고 피로감을 호소하고 있습니다.
기여 난이도의 하락은 쓰레기 코드의 양산을 넘어 개발자 윤리의 악화까지 가져오고 있습니다. 3
오픈소스 프로젝트에 대한 기여는 단순히 수정된 코드를 던지는 것에서 끝나는 것이 아닌, 오픈소스 유지관리자와 협업하며 수정된 사항에 대한 리뷰 및 후속 조치까지 모두 포함된 하나의 업무입니다.
또한 오픈소스 프로젝트들의 경우 오픈소스 커뮤니티 내에서의 커뮤니케이션에서 지켜야하는 기본적인 윤리 규칙, 기여 시 지켜야하는 기본 가이드들을 문서화해두는 경우가 많습니다. 4
이전에는 기여 전에 수정을 위해서도 기여 가이드를 필수로 읽어야 했기 때문에 기여 가이드를 무시하는 내용의 기여 등의 빈도가 낮았지만, 이제는 수정이 쉬워졌기 때문에 이러한 가이드를 읽지 않고 마구잡이로 올라오는 기여의 빈도가 높아진 것으로 보입니다. 5
위에서 얘기한 건 기존 오픈소스 프로젝트에서 일어난 사례들입니다.
근데 AI에 의해서 기존에 필요하지만 관심이 많지 않아 만들지 못하고 있던 프로젝트 등 신규로 만들어진 프로젝트들도 많을탠데 처음부터 AI가 활용된 프로젝트에서는 이런 문제가 없지 않을까요?
그러면 결국 위에서 예시로 든 문제들은 AI 에이전트에 적응하지 못한 기존 메인테이너들의 문제로 발생한 문제인게 아닐까요?
네, 아닙니다. 제가 생각하는 악영향은 기존 프로젝트보다 신규 프로젝트에서 훨씬 많고 심각합니다.
다른 사람을 저격하는 건 제 취미가 아니기에 실제로 올라왔던 게시글의 핵심 내용을 따서 ^AI^로 내용을 재구성했습니다. 원글이 뭔지 찾으려고 하지 마세요.
차라리 기존 프로젝트에서의 AI Slop 코드가 백배 더 낫습니다. (메인테이너의 피로감을 제외하면요!) 기존 프로젝트의 AI Slop 코드는 일부 수정사항만 말이 안되는 코드가 들어가는 등의 작은 사이즈의 Slop에 불과하니까요.
신규 프로젝트는 프로젝트 자체가 환각 덩어리입니다.
프로젝트의 핵심 개념부터 자세하게 보지 않아도 말도 안되는 내용에6, 그 결과물인 코드는 더 엉망입니다.
실행조차 잘 되지않는 프로젝트가 태반에, 실행이 되더라도 이게 왜 있어야 하는 프로젝트가 한 무더기입니다.
이전에는 Github Trending이나 GeekNews 등에서 새로운 프로젝트를 접할 때 설레는 기대감과, 직접 사용해보면서 숨은 보석을 찾는 재미가 있었는데 이젠 구경하기도 지칩니다. 7
대체 이런 프로젝트들을 앞으로 얼마나 더 봐야하나요?
네, 이 문제도 기존 프로젝트들보다 신규 프로젝트에서 더 심합니다.
물론 히포크라테스 선서마냥 개발자를 하려면 무조건 지켜야하고 선서해야하는 규칙이 존재하는 건 아닙니다. 제가 그 정도 사명감을 가지고 일하지는 않아요.
근데 적어도 개발자들끼리는 성향 상 통하는건지 어떤건진 몰라도 암묵적으로 커뮤니티 내에서 지켜지던 사항들이 있습니다.
근데 AI 에이전트 이후로는 사실 상 비개발자 / 개발자와의 차이가 거의 사라졌다보니 이전에는 볼 수 없었던 행동들이 너무 자주 보입니다.
프로젝트의 과도한 바이럴, 라이센스를 위반한 코드 사용 등의 문제들이 너무 많습니다. 8
특히 가장 최근 있었던 Claude Code 코드 유출 사건때는 제 눈을 의심했습니다.
Claude Code의 소스코드가 유출되고, 그걸 Github에 올리는거. 여기까지는 이해가 됩니다. 하면 안되는 행동이긴 하지만 이전에도 없었던 건 아니니까요.
근데 유출된 소스코드를 가지고 얻은 Star를 공공연하게 자랑하고 다니고, 그렇게 얻어놓은 Star 아쉬우니까 갑자기 force push 밀어넣고 클린룸 구현이라고 말을 돌린다? 다른 프로젝트로 전환시키면서 가장 빠른 속도로 Star를 얻은 프로젝트라고 자랑을 한다? 9
이게 말이 되나요? 제가 이상한건지 이 세상이 이상한건지는 몰라도 둘 중 하나는 분명 이상합니다.
Wine 프로젝트가 유출된 Windows 소스코드의 사용을 금지하는 것은 Wine 프로젝트 메인테이너들이 너무나 윤리적이고 양심적인 사람이어서도 아니고, 그 사람들이 그 유출된 코드의 존재를 몰라서도 아닙니다.
바이럴까지는 그런갑다하고 넘어갈게요, 최소한의 선은 지킵시다.
적어도 저작권 위반은 개발자로 일하는 우리한테 가장 크리티컬한, 밥그릇을 뺏어가는 행동이지 않나요?
아래 내용은 개인적인 용도로 개발해서 단순 소스코드 공개만 하는 분들에게 하는 이야기가 아닙니다! 그건 아무 문제 없어요. 적어도 그럴거라는걸 알고 있으면 제가 쓸 때도 생각하고 쓰니까 괜찮아요!! 그렇게 공개해주시는 분들은 절대 저 때문에 공개안하고 이러지 마세요 ㅠㅠㅠ 잘 쓰고 있습니다 ㅠㅠㅠㅠㅠㅠ
너무 반짝하고 나왔다가 유지보수 안되고 사라지는 오픈소스 프로젝트들이 많아졌습니다.
당연히 소스코드가 공개되었다고 모두 그게 유지보수가 되어야 한다고 생각하는건 아닙니다. 소스코드를 공개했다는 이유 만으로 프로젝트를 유지해야 한다는 책임감이 주어지는건 너무나도 무겁죠.
근데 지속적으로 유지보수할 프로젝트처럼 Repository를 구성해놓고 몇 주 지나니까 Archive 되어 있는 일은 이제는 없었으면 좋겠습니다.
이제 쓰던 프로젝트들이 아니면 안심하고 활용을 못하겠습니다. 너무 개발이 쉬워져서 일어나는 일인걸까요?
개발자가 하는 일은 코드를 작성하는 일이 전부가 아닙니다.
개발자의 업무는 특정 기능을 설계하는 곳에서부터 시작하고, 그걸 마지막까지 유지보수 하는 곳에서 끝난다고 생각합니다. 코드를 작성하는 것은 그 가운데에 있는 과정에 불과하죠.
이는 오픈소스 프로젝트에서도 마찬가지입니다. 오픈소스 프로젝트도 하나의 개발 프로젝트니까요.
저는 현재의 이 현상이 Vibe Coding 열풍이 불고, 그로 인해 새로운 사람들이 커뮤니티에 많이 유입되면서 생기는 과도기적인 현상이라고 생각합니다. 그리고 그 분들이 문제라고 생각하지 않아요, 아직 모를 뿐인거죠.
하지만 앞으로도 커뮤니티가 건강하게 유지되기 위해서는 개발 관련 활동을 하는 분들이 최소한의 기준은 가지고 활동했으면 좋겠다는 생각입니다.
AI는 결국 도구잖아요. 내 자리를 통째로 뺏을 무언가가 아니니까.
부족한 글임에도 불구하고 결론까지 읽어주셔서 감사합니다, 위 내용은 모두 제 개인적인 의견이며 다른 의견을 갖고 계신 분들과 건강한 의견 교환도 당연히 환영합니다.
유명 AI 연구자인 Andrej Karpathy가 만든 단어입니다. 소스코드를 직접 작성하지 않고 코딩 에이전트에게 작업의 대부분을 맡기는 개발 방식을 의미합니다. (https://x.com/karpathy/status/1886192184808149383) ↩
실제로 tldraw (https://github.com/tldraw/tldraw/issues/7695)는 외부 기여 PR을 자동으로 close하도록 정책을 변경했고, cURL (https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/) 의 경우 AI Slop 리포트로 인해 버그 바운티 프로그램을 종료했습니다. ↩
가장 유명한 사례로 matplotlib에서 AI 에이전트가 프로젝트 메인테이너에 대한 악의적인 게시글을 사례가 있었습니다. (https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me) ↩
프로젝트마다 방식은 다르지만, CONTRIBUTING.md 나 별도의 Contribute 가이드 (https://legacy.reactjs.org/docs/how-to-contribute.html) 를 제공하는 경우가 많습니다. ↩
개인적인 생각입니다. ↩
물론 자세하게 봐도 말도 안되는 내용인 경우가 많아요! ↩
재밌긴해요, 얼마나 말이 안되나 구경하고 있으면. ↩
물론 이전에 없었다는 건 아닙니다. 그 수가 많아졌다는 것 뿐입니다. ↩
물론 저격은 제 주특기가 아니니까 어느 프로젝트인지 명시하지는 않겠습니다 ^^‘7 ↩