본 글은 Robin Moffatt이 2026년 5월 6일 공개한 글 AI Slop is Killing Online Communities를 기반으로, ‘AI 슬롭(AI slop)’이 오픈소스 커뮤니티에 끼치는 구조적 영향과 한국 개발 팀이 점검해야 할 기여 기준을 정리합니다.
전제: 본 글은 AI 사용 자체를 비판하지 않습니다. 원문 저자도 “AI를 쓰지 않는 것은 직무 유기에 가깝다”라고 명시합니다. 문제는 결과물의 품질·기여 의도·커뮤니티 영향이며, 글 후반부의 점검표는 이 세 축을 기준으로 합니다.
1. AI 슬롭이란 무엇인가
‘AI 슬롭(AI slop)’은 LLM·에이전트 코딩 도구가 빠르게 생성한 저품질 콘텐츠를 가리킵니다. 원문 정의에 따르면 “공헌 의도 없이 커뮤니티에 떠넘겨진 저노력 결과물”이며, vibe-coded 깃허브 저장소·LLM이 작성한 블로그 글·자가 출판 ebook 등이 대표적 형태입니다.
주의할 점은 ‘AI로 만든 모든 결과물’이 슬롭은 아니라는 것입니다. 원문은 “AI로 도움받았다는 사실 자체는 문제가 아니며, 그 결과물을 어디에 어떻게 쓰는지가 기준”이라고 구분합니다. 즉 슬롭의 정의는 결과물의 출처가 아니라 ‘커뮤니티에 끼치는 비용 대비 가치’에 가깝습니다.
2. 왜 지금 커뮤니티가 무너지는가 — Brandolini 법칙의 비대칭
원문이 인용한 핵심 이론은 Brandolini의 법칙입니다. 이 법칙은 “헛소리(bullshit)를 반박하는 데 드는 에너지는 그것을 만드는 데 드는 에너지보다 한 자릿수(an order of magnitude) 크다”라고 정리합니다.
LLM은 헛소리 생성 비용을 사실상 0에 수렴하도록 만들었습니다. 반면 검증·반박 비용은 Brandolini 법칙의 비대칭 그대로 유지됩니다. 결과적으로 메인테이너·리뷰어 측에 비용이 몰리며, Reddit·Hacker News·Slack 같은 비공식 커뮤니티는 신호 대 잡음비가 빠르게 악화됩니다.
원문은 이 흐름이 지속되면 커뮤니티가 두 갈래로 끝난다고 경고합니다. 하나는 시들어 죽는 길이고, 다른 하나는 사람 없이 AI 에이전트끼리 대화하는 디스토피아적 형태입니다. 두 결말 모두 한국 개발자가 영어권 OSS에서 정보·인맥·일자리 기회를 얻어 온 경로를 닫습니다.
3. 슬롭의 전형적 패턴
원문이 정리한 ‘Step 0: Profit’ 패턴을 한국 개발자 환경에 맞춰 4가지로 재구성합니다. 자신·동료가 다음 패턴 중 하나에 해당하는지부터 점검해야 합니다.
3-1. vibe-coded 프로젝트 별 구걸
에이전트 코딩으로 하루 만에 만든 저장소를 깃허브에 올리고, 모든 서브레딧·디스코드·카카오 오픈채팅에 동시 공유하는 패턴입니다. 본인이 그 코드를 다시 열어 본 적도 없고 이슈·PR을 받을 준비도 안 된 상태가 대부분입니다.
3-2. LLM이 쓴 기술 블로그
특정 기술 키워드를 주제로 LLM에게 통째로 글을 시키고 그대로 게시하는 방식입니다. 원문은 “독자가 Claude가 쓴 글임을 알아챈다”라고 단정합니다. 한국어 블로그도 다르지 않으며, 동일 LLM이 만든 어순·표현 패턴이 검색 결과 상위에 누적되면 SERP 자체가 슬롭 풀이 됩니다.
3-3. 무성의한 PR 폭격
에이전트가 자동 생성한 대규모 패치를 충분한 검증 없이 오픈소스 저장소에 던지는 패턴입니다. Brandolini 법칙대로 메인테이너가 “왜 이 PR을 머지할 수 없는지”를 작성자에게 설명해야 하므로, 잘못된 PR 한 건이 정상 PR 여러 건의 검토 시간을 잠식합니다.
3-4. 자가 출판 ‘AI 책’·동영상
LLM에게 인터넷을 긁어 정리시킨 결과물을 ebook 또는 유튜브 강의로 포장해 무료·유료 배포하는 흐름입니다. 학습 자료로 신뢰하기 어렵고, 잘못된 정보가 검색 결과·LLM 학습 데이터로 다시 흘러 들어가 슬롭의 자기 강화 루프를 만듭니다.
4. AI를 잘 쓰는 방법 — Built with AI, not by AI
원문이 강조한 모범 사례 표어는 “Built with AI, not by AI”입니다. AI는 도구이며, 사고·지시·검증의 책임은 사람에게 남는다는 의미입니다. 원문은 Gunnar Morling의 Apache Parquet 파서 프로젝트 ‘Hardwood’를 예시로 들며, “AI를 도구로 쓰되 4개월간 로드맵·디자인·커뮤니티 관리를 사람이 끌고 갔다”라는 점에서 슬롭과 구분된다고 설명합니다.
실무 관점에서 ‘with AI’와 ‘by AI’를 가르는 기준은 단순합니다. 결과물에 대해 작성자가 이슈·리뷰·반증에 책임 있게 대응할 수 있는가, 그리고 동일 프롬프트를 다른 사람이 실행했을 때 본질적으로 같은 결과가 나오는가입니다. 후자가 “예”라면 그 산출물의 가치는 프롬프트 기술이지 결과물 자체가 아닙니다.
5. 오픈소스 프로젝트의 정책 대응
슬롭 유입에 대응해 일부 프로젝트는 명문화된 정책으로 문을 닫고 있습니다. Zig 프로젝트의 행동 강령에 포함된 Strict No LLM / No AI Policy가 대표적입니다. 이 정책은 이슈·풀 리퀘스트·버그 트래커 코멘트(번역 포함) 모든 영역에서 LLM 사용을 금지합니다.
모든 프로젝트가 Zig만큼 엄격하게 가는 것은 아닙니다. 다수 OSS 프로젝트는 “AI 사용 사실 공개 + 작성자가 코드를 이해하고 변호할 수 있을 것”을 요구하는 중간 정책을 채택하고 있습니다. 한국 팀이 사내 컨트리뷰션 가이드를 만든다면 두 모델 중 어느 쪽을 따를지 먼저 결정해야 합니다.
운영 리스크 측면에서 한 가지 더 짚어야 할 것은, OSS 정책이 갑자기 강화되면 사내 의존 라이브러리의 PR·이슈 처리 속도가 느려질 수 있다는 점입니다. 자동 PR 봇·에이전트 기반 dependency 업데이트 도구를 운용 중인 팀은, 외부 프로젝트가 “AI 생성 PR 거부”로 전환했을 때의 영향 범위를 미리 점검해 두는 것이 안전합니다.
6. 기여 전 점검 체크리스트
원문의 ‘Contribution / Respect the community / Asymmetry of bullshit’ 세 절을 한국 개발 팀이 사내·외부 기여 전에 적용할 수 있는 체크리스트로 정리합니다.
- 책임 가능성: 결과물에 대해 이슈·리뷰에 한국어·영어로 응답할 준비가 되어 있는가.
- 차별성: 같은 프롬프트로 누구나 만들 수 있는 결과물이라면 공유 가치는 프롬프트가 아니라 본인의 재해석에 있는가.
- 공동체 결: 대상 커뮤니티의 게시 톤과 관행을 최소 1주 이상 lurking해 본 적이 있는가.
- 비용 비대칭: 검토자가 들일 시간이 작성자가 들인 시간보다 짧은가, 아니면 더 긴가.
- AI 사용 명시: 어떤 부분에 LLM·에이전트가 개입했는지 글·PR 본문에 투명하게 적었는가.
다섯 항목 중 하나라도 “아니오”가 나오면, 공유 채널을 좁히거나 발행 자체를 보류하는 것이 안전합니다. 원문 저자가 강조한 것처럼, 슬롭의 비용은 작성자 본인보다 커뮤니티 전체가 부담합니다.
7. 관련 글
AI 도구·오픈소스 정책·커뮤니티 운영 리스크를 함께 다룬 기존 글을 정리합니다.
- 에이전트 우선 워크플로의 사내 도입 영향: Warp 터미널 오픈소스 전환 — AGPL과 agent-first 도입 점검표.
- vibe coding 비용 구조 변화 맥락: GitHub Copilot 청구 전환 — AI Credits 시행 한국 개발자 점검표.
- 오픈소스 운영 리스크 관점에서 함께 볼 사례: Ghostty가 GitHub을 떠난다 — 한국 개발 조직이 점검할 운영 리스크.
- OSS 프로젝트 정책·언어 전환의 사회적 신호: Bun이 Zig에서 Rust로 — Phase-A 포팅 가이드와 한국 팀 점검표.
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요