AI로 찍어낸 콘텐츠가 개발자 커뮤니티를 망치고 있다는 경고

• 저자는 먼저 선을 확실히 긋고 시작함. “AI 싫어하는 사람”이 아니라, AI로 만든 저품질 산출물을 커뮤니티에 마구 던지는 문화가 싫다는 얘기임

  • AI 자체는 강력한 도구고, 앞으로 안 쓰는 쪽이 오히려 이상해질 수 있다고 봄
  • 문제는 프롬프트 넣고 엔터 한 번 친 결과물을 마치 대단한 기여처럼 포장해서 뿌리는 흐름임

• 요즘 개발자 커뮤니티에서 반복되는 패턴은 꽤 익숙함

  • 에이전트 코딩을 처음 써보고 “와 미쳤다” 상태가 됨
  • 바로 GitHub 저장소를 올림
  • AI가 써준 과장된 블로그 글까지 붙여서 Reddit, Slack, 커뮤니티 여기저기에 홍보함
  • 저자는 여기서 “2단계에서 멈추고 숨 좀 고르라”고 말함. 이제 에이전트 코딩은 신기한 장난감이 아니라 그냥 도구가 됐다는 것

• “AI로 만들었다”는 사실만으로는 더 이상 뉴스가 아님

  • 저자의 기준은 단순함. 실제로 유용한가, 본인이 계속 쓰고 있는가, 문서가 괜찮은가, 다른 사람이 이슈를 올리거나 PR을 보내도 감당할 준비가 되어 있는가
  • 글이라면 스스로 읽고 싶을 정도인가, 커뮤니티의 누적 지식에 뭔가를 더하는가를 봐야 함
  • 그냥 LLM이 자동완성한 텍스트라면, 쓰는 사람도 읽는 사람도 별로 얻는 게 없음

• 왜 이렇게 예민하게 보냐면, 커뮤니티의 신호 대 잡음비가 실제로 망가지고 있다고 보기 때문임

  • Reddit 같은 공간이 점점 바이브 코딩 산출물과 AI 생성 글로 뒤덮이고 있다고 말함
  • 각각은 악의가 없을 수 있지만, 누적되면 유용한 글을 찾기 어려워짐
  • 그렇게 피로도가 쌓이면 진짜 사람들은 점점 덜 참여하고, 커뮤니티의 생명력이 줄어드는 악순환이 생김

• 저자는 AI slop에도 좋은 쪽과 나쁜 쪽이 있다고 구분함

  • 좋은 AI 활용은 사람이 원래 못 하던 기여를 가능하게 만들고, 그 뒤에 인간의 의도·검토·책임이 있는 경우임
  • 나쁜 AI slop은 커뮤니티에 도움이 되지 않는 스팸, 관심끌기, 무성의한 홍보, 생각 없는 소음에 가까움
  • 그래서 “AI가 조금이라도 들어가면 다 쓰레기”라는 식의 반응도 틀렸고, “AI로 만들었으니 다 공유해도 됨”도 틀렸다는 입장임

• “Built with AI, not by AI”라는 표현이 글의 핵심에 가까움

  • AI로 만들 수는 있지만, 생각하고 지시하고 확인하는 건 사람이 해야 한다는 뜻임
  • 예시로 Gunnar Morling의 Hardwood 프로젝트를 듦. Apache Parquet용 새 파서를 AI 도움을 받아 만들고 있지만, 4개월 동안 개발됐고 로드맵, 커뮤니티, 신중한 설계가 있다는 점에서 단순한 AI 산출물과 다르다고 봄
  • 즉 “AI를 썼다”가 감점 요소가 아니라, “AI 말고 사람이 한 일이 뭐냐”가 판단 기준임

• 커뮤니티에 뭔가를 공유하기 전에는 “이게 기여인가?”를 먼저 물어야 함

  • 내가 넣은 프롬프트를 다른 사람이 그대로 실행했을 때 비슷한 결과가 나온다면, 그건 주제 자체보다 프롬프트 놀이에 가까울 수 있음
  • 작은 도구나 스크립트 자체가 나쁘다는 말은 아님. 인터넷은 원래 그런 자잘한 도구들로 굴러왔음
  • 다만 모든 즉석 도구에 거창한 출시 블로그와 대대적인 홍보가 필요한 건 아니라는 얘기임

• 커뮤니티마다 분위기가 다르기 때문에, 먼저 읽고 맥락을 파악하는 태도가 필요하다고 말함

  • 예전 인터넷 문화에서 말하던 “눈팅 먼저 하라”는 규칙과 비슷함
  • Usenet, Reddit, lobste.rs 같은 곳마다 받아들이는 기준이 다르니, 내가 만든 Kafka 프로토콜 구현체가 환영받을지부터 봐야 함
  • 확실하지 않으면 묻고, AI를 어디에 어떻게 썼는지도 투명하게 밝히는 게 커뮤니티에 대한 예의라는 것

• 글에서 가장 현실적인 지적은 “헛소리의 비대칭성”임

  • 저품질 글이나 복잡한 PR은 만들기는 쉬운데, 읽고 검토하고 반박하는 데는 훨씬 많은 에너지가 듦
  • 엉성한 글을 던지면 독자는 시간을 들여 “이거 읽을 가치 없네”를 판단해야 함
  • 엉성한 PR을 던지면 메인테이너는 왜 머지할 수 없는지 설명해야 함

• AI 이전에는 기여 자체에 어느 정도 비용이 있었고, 그 비용이 일종의 필터 역할을 했음

  • 글을 쓰거나 코드를 만들려면 시간이 들었기 때문에, 최소한의 의지와 몰입이 어느 정도 드러났음
  • 퀄리티가 낮아도 진심인 기여자는 커뮤니티 안에서 배우고 성장할 수 있었음
  • 반대로 스팸성 기여는 양이 적어서 상대적으로 처리 가능했음

• AI 이후에는 이 균형이 흔들렸다는 게 저자의 진단임

  • 산출물의 양이 너무 많아져서 커뮤니티와 프로젝트가 감당하기 어려워짐
  • 일부 프로젝트는 AI가 닿은 기여 자체를 강하게 막는 쪽으로 가고 있음
  • Vouch 같은 프로젝트가 이런 문제를 다루려 등장했지만, 앞으로 어디까지 갈지는 아직 불명확하다고 봄

• 결론은 꽤 단순하지만 묵직함. AI는 즐겁게 쓰되, 커뮤니티를 존중하라는 것

  • LLM과 에이전트 코딩 도구가 주는 “와 이게 되네” 감각은 충분히 즐겨도 됨
  • 하지만 그 감정이 곧바로 공개 홍보의 이유가 되지는 않음
  • 진짜 관련 있고, 유용하고, 사람이 책임질 수 있는 것만 공유하라는 게 글의 메시지임

---

기술 맥락

• 이 글에서 중요한 선택지는 “AI 사용 여부”가 아니라 “AI 산출물을 커뮤니티 기여로 취급할 조건”이에요. 저자는 AI를 개발 도구로 쓰는 건 당연해질 수 있지만, 결과물을 공개 공간에 올릴 때는 사람의 검증과 책임이 붙어야 한다고 봐요.

• 왜냐하면 생성 비용과 검토 비용이 완전히 비대칭이 됐거든요. LLM으로 글, 저장소, PR을 찍어내는 건 몇 분이면 되지만, 커뮤니티 구성원이 그걸 읽고 쓸모를 판단하거나 메인테이너가 코드를 리뷰하는 데는 훨씬 더 많은 시간이 들어요.

• 그래서 “Built with AI, not by AI”가 실무적으로 꽤 중요한 기준이 돼요. AI가 코드를 썼더라도 사람이 설계 방향을 잡고, 반복해서 써보고, 문서화하고, 이슈와 PR을 받을 준비를 했다면 그건 도구를 활용한 프로젝트에 가까워요.

• 반대로 프롬프트 결과물을 거의 그대로 올리고 블로그까지 자동 생성해서 홍보한다면, 기술적으로는 그럴싸해 보여도 커뮤니티 입장에서는 잡음이 돼요. 특히 오픈소스에서는 이런 잡음이 메인테이너의 리뷰 큐와 운영 정책에 직접 부담을 줘요.

• 한국 개발자 커뮤니티에도 그대로 적용되는 얘기예요. AI로 만든 사이드 프로젝트를 공유할 때는 “어떻게 만들었는지”보다 “누가 왜 써야 하는지, 내가 어디까지 책임질 건지”가 먼저 보여야 반응이 좋아질 가능성이 커요.