▲

RFC 406i — AI가 생성한 쓰레기 기여물 거부(RAGS) 표준 프로토콜

 (406.fail)
10P by GN⁺ 1달전 | ★ favorite | 댓글 1개
  • 오픈소스 저장소, 커뮤니티 등에서 AI가 생성한 저품질 기여물을 자동 거부하기 위한 표준 프로토콜을 유머러스한 RFC 형식으로 정의한 문서
  • 프로젝트 메인테이너가 해당 URI를 붙여넣는 것만으로 "AI 슬롭(slop) 감지" 거부 신호를 전달하는 표준화된 수단으로 작동
  • AI 생성 기여물의 전형적 특징 목록을 나열하며, 유지보수 자원의 낭비와 검증되지 않은 출력물의 위험성을 직접 지적
  • LLM 기반 제출물이 테스트를 통과하고 문법이 맞더라도, 논리와 아키텍처 이해가 없으면 근본적으로 무가치하다는 입장을 명확히 함
  • RFC 형식을 차용한 풍자 문서이지만, 오픈소스 생태계에서 AI 자동화 기여 남용에 대한 메인테이너들의 실질적 피로감을 반영

Abstract - 이 문서의 목적

  • 소스코드 저장소, 이슈 트래커, 취약점 신고 포털, 커뮤니티 포럼에 제출되는 저노력·AI 생성 기여물의 처리 및 폐기 표준 프로토콜
  • 공개 오픈소스 프로젝트와 내부 기업 시스템 모두에 적용

1. Introduction - 왜 이 페이지로 안내되었는가

  • 귀하의 기여물이 자동화 또는 수동 AI 슬롭 감지 시스템을 작동시켰기 때문에 이 페이지로 안내되었음
  • 구체적으로, 메인테이너 또는 시니어 엔지니어가 제출물을 보고 "심오한 실존적 한숨"을 내쉰 후 즉시 연결을 종료하고 이 URI를 붙여넣었음
  • 이 문서에 사용된 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 키워드는 "우리가 얼마나 이 제출물을 검토하고 싶지 않은지" 의 척도로 해석할 것

2. Diagnostic Analysis - 귀하의 제출물에서 감지된 특징

  • 제출하신 자료의 어휘 및 구조 분석 결과, 귀하의 프롬프트 엔지니어링은 잘못되었으며, 따라서 귀하는 스스로 부끄러워해야 한다는 결론에 도달함
  • 확률론적 앵무새에게 PR·취약점 공개·이슈 코멘트·포럼 게시물을 대신 쓰게 한 결과 그것은 우리 모두에게 거짓말을 했음
  • 다음 특징들이 압도적으로 명백하게 감지되었음:
    • 과도하게 공손하고 로봇 같은 어투 사용
    • 높은 확신으로 제시된 완전히 존재하지 않는 API 포함
    • 실제 문제를 하나도 해결하지 못하는 비대한 보일러플레이트 코드
    • PR 설명에 "delve"를 진지하게 사용
    • 독스트링, 주석, 또는 보안 보고서 내부에 "Certainly! Here is the revised output:" 같은 LLM 출력 잔재물이 그대로 남아 있음
    • 단순 오타 수정에 600단어 커밋 메시지 또는 거대한 이론적 에세이 첨부
    • utils.helpers 같은 존재하지 않는 환각 라이브러리 임포트
    • 사소한 버그 리포트에 "In conclusion, this robust and scalable solution..."으로 시작하는 마무리 단락 추가
    • 카페인과 수면 부족으로 작동하는 인간 프로그래머가 절대 달성할 수 없는 기이하고 무균적인 변수·함수 명명
    • 실제 시스템 아키텍처나 위협 모델에 대한 이해 없이 regex나 환각된 개념에만 전적으로 의존
    • "fix this" 또는 "find a bug" 프롬프트에 관련 없는 대규모 컨텍스트 블록을 맹목적으로 붙여넣은 흔적
    • 커밋 히스토리에서 컴파일러에게 사과하는 행위
  • 자동화된 쓰레기의 기본 정리에 따라: 귀하가 읽지 않았으므로, 우리도 읽지 않겠음

3. The Asymmetry of Effort - 노력의 비대칭성

  • 프로젝트 메인테이너, 보안 트리아지 팀, 커뮤니티 모더레이터는 무급 자원봉사자든 지친 사내 동료든 엄격한 자원 제약 하에 운영됨
  • 귀하의 제출물 트랜잭션 기록을 검토하면:
    • a. 첫인상에서 스마트하게 보였는가? - 아마도
    • b. 검증된 재현 가능한 문제를 실제로 해결했는가? - 아니오
    • c. 인간 리뷰어의 유한한 시간을 낭비하려 했는가? - 예
  • 프로젝트 트래커·포럼·저장소는 GitHub 잔디 채우기, 근거 없는 버그 바운티 수집, 스프린트 속도의 인위적 부풀리기, 또는 기업 KPI 지표의 악의적 준수를 위한 검증되지 않은 복붙 출력물의 쓰레기통이 아님
  • 귀하의 동료들은 무료 LLM 검증 서비스가 아님

4. Resolution Protocol - 복구 절차

  • 쓰기 권한 복구와 동료의 신뢰 회복을 위해 아래 절차를 순서대로 이행해야 함:
    • 1. 해당 제출물을 생성한 로컬 브랜치, 텍스트 파일, 또는 환각된 취약점 스크립트에 rm -rf 실행
    • 2. 유기체 두뇌의 하드 리부팅 수행
    • 3. 실제 코드베이스, 프로젝트 문서, 또는 위협 모델을 읽고 자신의 작업 상태와 논리를 수동으로 검증
    • 4. 검증 가능한 의식을 달성하고 인간의 손가락으로 직접 타이핑할 준비가 될 때까지 복귀 금지

5. Security Considerations

  • 상태: 거부됨
  • 진단: 트렌치코트 속에 숨겨진 조악하게 작성된 Python 스크립트로 운영 중
  • 조치: 연결 종료

6. Punitive Actions - 징벌적 조치 및 계정 강등

  • AI 생성 슬롭 제출의 결과로 귀하의 계정은 자동으로 Trough of Sorrow™(슬픔의 구유) 로 이전되었으며, 보호 관찰 기간 동안 아래 제한이 적용될 수 있음:
    • 저장소 권한이 WRITE에서 WISHFUL_THINKING으로 강제 다운그레이드
    • 모든 향후 PR은 시안 리본이 영구 소진된 도트 매트릭스 프린터에 연결된 14.4k 보 다이얼업 모뎀을 통해 라우팅
    • git push -f 입력 시 rm -rf / 실행 및 슬픈 트럼본 사운드 재생으로 git alias 리매핑
    • IDE 기본 폰트가 7pt Comic Sans로 영구 고정
  • 시스템 관리자에게 연락 불가 - 관리자는 현재 개인 Slack 채널에서 귀하를 비웃는 중

7. FAQ

  • "대체 무슨 소리야?": 간단히 정리하면 - 기계가 귀하의 제출물을 작성했고, 기계가 현재 귀하의 제출물을 거부하고 있음. 귀하는 이 교환에서 완전히 불필요한 고기 기반 중간자(meat-based middleman) 임
  • "코드가 컴파일됩니다 / 보고서가 상세합니다 / 문법이 맞습니다": 잘 포맷된 협박 편지도 그렇게 가능. 문법과 구문은 기여의 최소 기준이지 천장이 아님. 귀하의 논리는 여전히 환각된 열병 꿈(hallucinated fever dream)
  • "AI가 기술의 미래입니다": 이 제출물이 미래를 대표한다면, 농경 사회로의 전환을 기꺼이 가속하겠음
  • "도움이 되려 했습니다": 귀하의 "도움"은 현재 정중한 인사말로 포장된 로컬 서비스 거부 공격과 유사함. 진정으로 도움이 되고 싶다면 귀하가 직접 소유하고 유지보수하는 저장소로 생성 에너지를 돌릴 것
  • "AI가 작성했다는 증거가 없습니다": 인간의 무능함은 물리 법칙과 게으름에 의해 제한됨. 귀하의 제출물은 기가와트의 전기를 태우는 서버 팜만이 생산할 수 있는 수준의 자신만만하고 문법적으로 완벽한 광기를 달성했음
  • "CI/CD가 통과했고 테스트가 초록불입니다": 귀하의 생성 모델이 True == True만 단언하도록 테스트 스위트를 재작성해줬기 때문
  • "오류를 지적해 주면 배우겠습니다": 불가. 메인테이너는 귀하의 LLM 디버깅 루프를 위한 역방향 프록시가 아님. 피드백이 필요하다면 이 사태를 만든 바로 그 채팅 창에 스택 트레이스를 다시 붙여넣을 것
  • "GitHub 잔디가 필요합니다": 녹색 화이트보드 마커를 구입해 모니터에 직접 그리는 것을 권장. 우리의 시간을 훨씬 덜 소비하면서 잠재적 고용주에게 동일한 수준의 전문적 존경을 얻을 수 있음
  • "오픈소스 메인테이너의 역할은 환영하는 커뮤니티를 만드는 것 아닌가요": 역할은 소프트웨어를 유지보수하는 것. "환영"은 실제 사고를 기여하는 의식 있는 존재에게 적용되며, 이슈 트래커에서 확률론적 되새김질을 수행하는 자율 봇넷에게는 해당 없음
  • "이 메시지가 불쾌합니다": 좋은 반응. LLM에게 맞춤형 공감 사과 편지 생성을 요청할 것. 현재 동정 재고 소진, 감정 지원 SLA는 99년
  • "관리자에게 이 적대감을 보고하겠습니다": 이미 예측하여 귀하의 선호 LLM이 생성한 800단어 사직서를 HR에 발송했음. "delve"가 여섯 번 사용되었고 관리자의 "시너지적 패러다임"을 칭찬하는 내용
  • "Code of Conduct 위반입니다": CoC는 인간 기여자를 보호함. 분석에 따르면 귀하는 현재 OpenAI API 키를 감싼 얇은 고기 껍데기로 운영 중. 권리는 수치심을 경험할 수 있는 탄소 기반 존재에게 예약되어 있음
  • "이의 제기할 수 있나요": 가능. 모든 이의 제기는 /dev/null로 직접 라우팅됨. 귀하가 본인 제출물에 기울인 것과 정확히 동일한 수준의 주의로 모니터링 중
  • "사과하고 바로잡을 방법이 있나요": 있음. 원본 PR을 두꺼운 용지에 출력하고, 날카로운 종이학으로 접어 정중히 드셔주기 바람. 그때야 비로소 치유가 시작될 것임

Appendix A - 에스컬레이션 경로

  • RFC 406i 반복 위반 시 저장소·프로젝트·도구 및 기타 접근 권한 전면 취소
  • MAC 주소 블랙리스트 등록
  • 이메일이 공격적으로 복잡한 regex 튜토리얼 일일 다이제스트에 강제 구독 등록
  • 좋은 하루 되시기를.

Appendix B - 표준화된 거부 매크로

메인테이너 및 리뷰어가 즉시 복사·붙여넣기 가능한 표준 거부 문구:

  • PR / MR:
    • PR closed. 귀하의 diff는 컨텍스트 창을 잃은 예측 텍스트 매트릭스처럼 읽힘. 우리는 자동화된 추측 게임이 아닌 수동의 탄소 기반 테스트와 실제 논리적 연속성을 요구함. 참조: https://406.fail
    • PR closed. Your diff reads like a predictive text matrix that lost its context window. We require manual, carbon-based testing and actual logical continuity, not automated guessing games. See: https://406.fail
  • 이슈 / 버그 리포트:
    • Issue closed. 이 보고서의 temperature 파라미터가 너무 높게 설정됨. 우리는 검증 가능한 버그를 설명하지 못하는 깔끔한 생성 에세이가 아닌, 의식 있는 사용자의 원시 재현 가능한 스택 트레이스를 요구함. 참조: https://406.fail
    • Issue closed. The temperature parameter on this report is set too high. We require raw, reproducible stack traces from a sentient user, not a neatly formatted generative essay that fails to describe a verifiable bug. Protocol at: https://406.fail
  • 보안 / 버그 바운티:
    • Report rejected. 기본 린터 경고를 LLM에 넣어 파국적 위협 서사를 생성하는 것은 유효한 취약점 공개가 아님. 우리는 계산 비용이 높은 합성 공황에 대한 바운티는 지급하지 않음. 참조: https://406.fail
    • Report rejected. Feeding basic linter warnings into an LLM to generate a catastrophic threat narrative does not constitute a valid vulnerability disclosure. We do not pay bounties for computationally expensive, synthetic panic. Refer to: https://406.fail
  • 메일링 리스트 / 토론 포럼:
    • Thread locked. 이 커뮤니티는 정렬되지 않은 프롬프트 실험을 위한 강화 학습 샌드박스가 아님. 자신의 인지 부하를 사용해 질문을 작성할 수 있을 때 복귀할 것. 참조: https://406.fail
    • Thread locked. This community is not a reinforcement learning sandbox for your unaligned prompt experiments. Please return when you can author a question using your own cognitive load. Diagnostics: https://406.fail

함께 보면 좋은 글 β

▲
GN⁺ 1달전  [-]
Hacker News 의견들

  • 진짜로 도움이 되고 싶다면, 자신이 직접 소유하고 유지보수하는 저장소에 그 에너지를 쏟는 게 좋음
    사람들도 이런 습관을 배워야 함. 포크를 공개하는 건 쉬워졌지만, 본인이 실제로 쓰지 않는 코드를 남이 써주길 기대하면 안 됨
    GitHub에서 하루에 몇 개의 프로젝트에 PR을 보내는지 통계를 보면, 99%는 하나, 1%는 두 개, 0.1%는 세 개임. 5개 이상 PR을 보내는 계정은 거의 전부 봇이나 스크립트였음. 등록되지 않은 봇은 속도 제한을 걸어야 함

    • 이런 상황이라면, 내 포크가 원본 저장소 위에 주기적으로 리베이스되는 영구 패치 모드 같은 기능이 있으면 좋겠음. 예를 들어 한 줄짜리 수정이라도 자동으로 최신화되는 식으로

  • 나는 Ghostty의 AI 정책을 더 선호함
    “AI의 도움 없이 변경 사항이 무엇을 하고 시스템 전체에 어떤 영향을 주는지 설명할 수 없다면, 이 프로젝트에 기여하지 말라”는 문장이 특히 마음에 듦

    • 좋은 아이디어이긴 한데, 실행 방법이 문제임. AI에게 설명을 시키고 그걸 자기 말로 다시 쓰면 사실상 우회가 가능함

  • 오픈소스 기여가 일종의 통과의례처럼 되어버린 게 문제라고 생각함
    진짜 기여보다 ‘기여했다는 사실’이 중요해지면 이런 얕은 PR이 생김. 예전엔 취약점 제보도 비슷했음 — “null을 넣으면 NullPointerException이 난다” 수준의 제보들
    개발 속도 같은 잘못된 지표를 중시하는 것도 문제임. 예전 회사에서 AI로 빠르게 개발한다고 자랑하던 동료의 PR을 봤더니 테스트가 전부 실패했음. 결국 AI 보조의 게임화 현상임

    • 나도 요즘 AI로 작성된 지원서를 많이 받음. 그중 일부는 GitHub 기여를 강조하더라. 아마 이런 식의 PR이 실제로 통과되는 경우가 있는 듯함. 프로젝트의 별 개수를 채용 지표로 삼는 문화가 이런 스팸을 부추김
    • “수학을 정말 빨리 할 수 있다” → “그럼 137*243은?” → “132,498” → “틀렸어” → “그래도 빨랐잖아” 같은 느낌임

  • 이건 그냥 재미로 쓴 블로그 글임. AI로 저품질 PR을 보내는 사람들은 이런 글을 읽지도 않음
    내가 하는 방식은 간단함:

    1. PR 닫기
    2. 너무 성의 없으면 사용자 차단
      최근엔 문자열 정의에 ‘’ 대신 ''를 써서 CI 전체가 실패한 PR도 있었음. 바로 차단함
    • PR을 닫을 때 이 페이지 링크를 댓글에 첨부하는 게 좋을 듯함

  • 버그라면 수정이 확인되는 빨간 줄(diff) 이 있어야 하고, 기능이라면 최소한 승인 기준이 필요함
    문서라면 읽어서 이해만 되면 됨. 도움을 받는 기준은 꽤 낮음

  • “오픈소스 유지보수자는 환영하는 커뮤니티를 만들어야 하지 않나?”라는 질문에 대해, 그건 의무가 아님
    유지보수자는 프로젝트의 주인이며, 친절할 필요도 없음. 마음에 안 들면 포크하거나 떠나면 됨

    • 이런 주장은 사실 감정적 조종에 가깝다고 봄. “우리의 시간을 감정적으로 낭비하지 말고, 왜 LLM이 생성한 PR이 쓸모없는지 이해하라”고 말하는 게 더 낫다고 생각함. 우리도 LLM을 쓸 줄 알고, 그 이후의 실제 작업량이 얼마나 큰지도 알고 있음

  • 정말 통쾌함. 이런 글이 무성의한 PR 제출자들을 부끄럽게 만드는 데 널리 쓰였으면 좋겠음. FAQ의 직설적이고 무례한 어조가 오히려 시원함

    • 하지만 그런 사람들은 부끄러움을 느끼지 않음. 전화 사기꾼에게 화내는 것과 같음 — 그냥 끊고 다시 시도할 뿐임

  • 회사에서 있었던 일임. AI로 작은 기능 요청을 해결하는 코드를 만들었는데, 코드베이스를 잘 몰라서 정확성을 확신할 수 없었음
    1분 프롬프트, 5분 정리, 30분 리뷰로 2일치 엔지니어링 시간을 절약할 수도 있었지만, 결국 신뢰가 문제였음
    여러 의견을 들은 결과, 그냥 기능 요청만 올리고 diff는 포함하지 않기로 함.
    흥미롭게도 AI 찬성파는 “AI를 더 써서 자신감을 높이라”고 조언했는데, 오히려 계속 수정하다 보니 코드가 꼬여서 완전히 신뢰를 잃음

    • 만약 LLM이 만든 코드를 실제로 쓰고 싶다면, 모든 변경을 이해하고, 그걸 직접 요약해 기능 요청에 첨부하는 게 좋음
      나도 LLM이 만든 PR을 여러 번 받았는데, 대화가 안 되고, 기존 패턴을 무시한 코드라 결국 버려야 했음.
      사람이라면 자신의 관점에서 문제를 설명해주길 바람. 그게 훨씬 도움이 됨
    • 당신은 좋은 엔지니어링 감각을 가지고 있음. 업계에 이런 사람이 더 많았으면 함
    • “2일치 엔지니어링 시간 절약”이란 말이 이해가 안 됨. 코드베이스를 아는 사람이 똑같이 AI를 쓸 수도 있잖음. 왜 AI 출력물을 남에게 검증시키려는지 모르겠음. 우리도 LLM을 쓸 줄 앎
      관련 글: Prompting에 대한 글
    • 나도 비슷한 접근을 함. Claude가 만든 코드를 완전히 이해하지 못할 때는, “이 부분은 왜 이렇게 했어?” “엣지 케이스는 어떻게 처리돼?” 같은 질문을 던지고, 수정하지 말고 설명만 하라고 요청함. 이렇게 하면 결과를 내 것으로 만들 수 있음
    • 그 라이브러리를 실제로 사용 중이라면, 스테이징 환경에서 테스트해보고 리뷰를 제출하는 게 좋음

  • 마지막의 plonk 표현이 너무 좋았음
    Plonk(Usenet) 참고

    • BOFH Task Force라면 그 정도는 당연히 할 줄 알았음

  • “rm -rf로 로컬 브랜치나 헛소리 스크립트를 지워라”는 문장이 너무 웃김
    “유기적 뇌를 하드 리부트하라”는 표현도 완벽함

    • 사실 LLM이 이미 그런 PR 작성자들의 뇌를 rm -rf 해버린 것 같음
답변달기