AI Slop이 온라인 커뮤니티를 죽이고 있다

4 days ago 9

AI Slop은 저노력 AI 생성물을 필요로 하지 않는 사람들에게 밀어 넣는 행위로, 선의에서 나온 결과물이라도 온라인 커뮤니티의 신호를 흐리고 구성원을 지치게 만듦
프롬프트만 실행해 만든 GitHub 저장소, 블로그 글, 영상, 전자책을 여러 subreddit과 Slack에 뿌리는 방식은 기여보다 커뮤니티 부담이 되기 쉬움
공유 전에는 실제로 유용한지, 만든 사람이 직접 쓰는지, 문서와 테스트가 충분한지, 이슈와 PR을 책임질 준비가 됐는지 확인해야 함
좋은 AI 활용은 Built with AI, not by AI처럼 사람이 생각하고 지시하고 검증해 이전에는 어려웠던 기여를 가능하게 하는 경우이며, Gunnar Morling의 Hardwood처럼 설계와 로드맵을 갖춘 프로젝트가 이에 해당함
커뮤니티를 존중하려면 먼저 분위기를 살피고, 관련 있는 내용만 공유하며, AI 사용 여부와 범위를 명확히 밝혀야 하고, 그렇지 않으면 리뷰어와 독자에게 불필요한 영향을 떠넘기게 됨

AI 생성물 공유가 커뮤니티에 미치는 영향

인터넷에는 AI로 만든 결과물을 공유하는 사람이 늘고 있으며, 그중 상당수는 만든 사람의 개인 공간에 둘 만한 결과물일 뿐 넓은 커뮤니티에 배포할 만한 내용은 아니라고 봄
AI 자체에 반대하는 입장은 아니며, AI를 받아들이지 않는 태도는 시대 흐름에 어긋난다고 봄
문제는 악의가 없더라도 가치 있는 커뮤니티가 저품질 AI 생성물의 공세 속에서 서서히 약해지고 있다는 데 있음
“Kafka를 COBOL로 다시 썼다”, “Kafka 블로그 글을 썼다”, “Kafka 영상을 만들었다”, “Kafka 전자책을 냈다” 같은 결과물이 실제로는 Claude가 만든 낮은 품질의 산출물이라면 유용한 학습 자료나 커뮤니티 기여로 보기 어려움
프롬프트를 입력하고 실행한 것만으로 새 GitHub 저장소의 star를 요구하거나, AI가 만든 글과 저장소를 여러 subreddit과 Slack에 무차별로 공유하는 방식은 커뮤니티에 부담을 줌

공유하기 전에 멈춰야 할 지점

반복되는 패턴은 대체로 다음과 같음
- 에이전트형 코딩(agentic coding)을 발견하고 큰 충격을 받음
- 프로젝트를 GitHub에 올림
- AI로 열광적인 블로그 글을 쓰게 한 뒤, 관련성 여부와 상관없이 찾을 수 있는 모든 subreddit과 Slack 그룹에 공유함
두 번째 단계 뒤에서 멈추고, 무엇을 만들었는지와 왜 공유하려는지 깊이 생각해야 함
“멋져서”가 이유라면 충분하지 않음
- 에이전트형 코딩은 더 이상 신기한 것이 아니며, 이제는 작업 방식의 일부가 됐다고 봄
- 프롬프트를 생각할 수 있으면 AI가 작성할 수 있다는 사실만으로는 큰 의미가 없음
널리 공유하기 전 확인해야 할 질문이 있음
- 실제로 유용한가
- 만든 사람이 직접 쓰고 있는가
- 문서가 충분히 좋은가
- 사용할 수 있는 상태인가
- 코드를 반복해서 다시 살펴보고 충분히 시험했는가
- 단발성으로 Claude와 만든 뒤 다음 날에는 별로 좋은 생각이 아니었다고 느끼는 수준은 아닌가
소프트웨어라면 사람들이 이슈를 올리고 PR을 보낼 수 있는 대상으로 책임질 준비가 필요함
글이라면 자신이 읽고 싶을 만한 글이어야 하며, 커뮤니티의 누적 이해에 실제로 보탬이 되어야 함
단지 LLM이 자동완성하듯 만들어낸 텍스트라면 만든 사람도 쓰기 싫고 독자도 읽기 싫은 결과물이 될 수 있음

왜 문제가 되는가

AI slop은 커뮤니티의 소음을 키우고, 신호를 점점 구분하기 어렵게 만듦
Reddit 같은 공간이 점점 vibe-coded AI 결과물로 뒤덮이고 있으며, 많은 경우 선의에서 나왔더라도 커뮤니티에 기여하지 못한다고 봄
커뮤니티가 이런 내용으로 오염될수록 구성원은 AI slop을 헤치고 다니는 데 지쳐 물러나게 됨
구성원이 물러나면 커뮤니티의 유기적 생명력이 더 줄어드는 하향 나선이 생길 위험이 있음
이런 흐름이 계속되면 온라인 커뮤니티는 시들어 죽거나, 인간 없이 AI 에이전트끼리 “대화”하는 디스토피아적이지만 평범한 MoltBook 같은 형태로 수렴할 수 있음

좋은 AI 활용과 나쁜 AI slop

AI Slop이라는 표현은 최근 널리 쓰이고 있음
일반적으로는 AI가 만든 저노력 자료를, 그 자료가 도움이 되지 않는 사람들에게 밀어 넣는 행위를 부정적으로 가리킴
다만 일부는 AI가 쓴 것이 아니더라도 AI에 대해 쓴 모든 것을 “AI Slop”이라고 부르며, 이런 태도는 AI를 혐오하는 쪽과 강하게 겹칠 가능성이 있다고 봄
AI의 도움으로 만든 자료 자체가 나쁜 것은 아님
- 핵심은 그것이 어떤 목적에 쓰이는가임
좋은 AI 활용은 이전에는 할 수 없던 일을 가능하게 하고, 이전에는 기여하지 못하던 사람이 커뮤니티에 기여하게 만드는 경우임
뒤에 인간의 주의와 좋은 의도가 있다면 AI 활용은 분명한 순효과가 될 수 있음
나쁜 AI slop은 커뮤니티 발전이 아닌 다른 목적을 위해 담장 너머로 쓰레기를 던지는 것과 같음
- 스팸
- 참여 유도용 저품질 게시물
- 해당 목적의 공간이 아닌 곳에 던져지는 무심한 소음

공유의 기준

온라인에서 콘텐츠를 공유하는 일은 훌륭하며, 인터넷을 지금의 모습으로 만든 중요한 요소임
중요한 요령은 무엇을, 누구에게, 왜 공유하는지 이해하는 것임
Geocities 시대에는 고등학생 너드들이 각자 홈페이지를 만들었고, Under Construction 애니메이션 GIF, 웹 카운터, 웹링 배너를 넣기도 했음
그런 홈페이지를 만들었다고 해서 듣는 모든 사람에게 공유해야 하는 것은 아님
- 친구나 부모에게 보여줄 수는 있음
- 일반 인터넷 전체에 공유할 만한지는 별개의 문제임
AI 생성 콘텐츠도 같은 기준이 적용됨
- vibe-coded 앱이든 블로그 글이든, 만들었다는 이유만으로 모두에게 공유할 필요는 없음
2026년 초 인터넷은 Claude Opus 4.5의 힘을 발견하며 집단적 충격을 겪었고, 그 자체는 매우 멋진 일이었다고 봄
새로운 것을 발견하면 사람들은 친구들과 공유하고 싶어 함
여기에 이미 과열된 AI 과장 마케팅이 결합되면서 subreddit과 Slack이 AI 생성물로 넘쳐나게 됨

무엇을 공유해야 하는가

AI에 의해 만들어진 것이 아니라 AI와 함께 만든 것
- Gunnar Morling의 최근 글에 나온 “Built with AI, not by AI”라는 구분이 핵심임
- AI는 강력한 도구이며, 업무 도구함에 포함하지 않는 것은 거의 직무 태만에 가깝다고 봄
- 그러나 AI는 도구일 뿐이며, 생각하고 지시하고 확인하는 일은 사람이 해야 함
- Gunnar Morling은 AI를 사용해 Apache Parquet용 새 파서인 Hardwood를 만들었음
- Hardwood는 지금까지 4개월이 걸린 프로젝트이며, 탄탄한 로드맵, 커져 가는 커뮤니티, 신중한 설계를 갖추고 있음
- 이런 프로젝트는 AI를 사용했다는 이유만으로 비판 대상이 되지 않음
기여
- 공유하려는 것이 커뮤니티에 실제로 기여하는지 따져야 함
- 본질적으로 에이전트형 코딩 도구에 프롬프트를 넣은 결과물에 불과한지 확인해야 함
- 같은 프롬프트를 다른 사람이 실행해도 비슷한 결과가 나온다면, 그 자체가 해당 주제에 대한 의미 있는 기여인지 의심해야 함
- 프롬프트 엔지니어링은 재미있고 흥미로운 연구 대상이지만, 커뮤니티가 다루는 주제 자체와는 곁가지일 수 있음
- 화려한 가구 애호가 커뮤니티에 흥미로운 끌 세트를 보여주고 싶다는 이유로 Ikea풍 가구를 계속 던지는 것과 비슷함
- Claude로 만들 수 있는 모든 멋진 앱을 공유할 필요는 없음
- 버리는 도구나 작은 스크립트는 괜찮으며, 인터넷은 사람들이 만들고 공유한 이상한 작은 스크립트 위에 세워진 면도 있음
- 다만 그런 도구는 gist나 GitHub에 올리면 충분하며, Steve Jobs의 재림처럼 출시 블로그 글까지 필요하지 않음
커뮤니티 존중
- Usenet, Reddit, lobste.rs 등 온라인 플랫폼에서 기본 예절은 먼저 “숨어서 지켜보기(lurk)”임
- 한동안 머물며 글을 읽고, 그 공간의 분위기를 파악해야 함
- 어떤 커뮤니티에서 무엇이 허용되는지는 개인이 아니라 커뮤니티 구성원이 결정함
- Kafka 프로토콜의 새로운 구현을 vibe coding으로 만들었더라도, 사람들이 보고 싶어 할지 확실하지 않다면 분위기를 읽어야 함
- 확신이 없다면 물어보는 편이 좋음
- 커뮤니티를 존중하는 또 다른 방법은 기여물에서 AI를 사용했는지, 어떻게 사용했는지, 어디에 사용했는지를 매우 공개적이고 명확하게 밝히는 것임
헛소리의 비대칭성
- 기여가 다른 사람에게 어떤 영향을 주는지 봐야 함
- 헛소리를 반박하는 데 드는 에너지는 헛소리를 만드는 데 드는 에너지보다 한 자릿수 규모로 더 큼
- 말이 안 되는 글을 쏟아내면, 읽을 가치가 없다는 사실을 독자가 직접 깨닫는 부담을 떠안게 됨
- 충분한 주의 없이 복잡한 PR을 프로젝트에 던지면, 리뷰어가 코드를 살펴보고 병합할 수 없는 이유를 설명해야 하는 부담을 떠안게 됨
- 이런 경우 커뮤니티는 그 기여가 없는 편이 더 나음
- 나쁜 의미의 AI slop이 너무 많아지면서 커뮤니티와 프로젝트는 기여의 영향을 처리하는 데 어려움을 겪고 있음
- 일부는 AI가 닿은 모든 것을 엄격히 금지하는 정책까지 채택함
- Vouch 같은 프로젝트는 이 문제를 해결하려고 등장했지만, 이미 되돌리기 어려운 선을 넘었고 어디로 갈지는 불확실함
- AI 이전에는 기여에 필요한 노력이 일종의 작업 증명 역할을 했음
- 그 노력은 사람들을 단념시키거나 실제 헌신을 보여줬고, 커뮤니티는 낮은 품질의 기여도 감당할 수 있었음
- 선의를 갖고 배우려는 사람은 멘토링을 받아 중요한 구성원으로 성장할 수 있었고, 스팸에 가까운 사람은 양이 적어서 처리할 수 있었음