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

> Clean Markdown view of GeekNews topic #27288. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27288](https://news.hada.io/topic?id=27288)
- GeekNews Markdown: [https://news.hada.io/topic/27288.md](https://news.hada.io/topic/27288.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-08T02:37:28+09:00
- Updated: 2026-03-08T02:37:28+09:00
- Original source: [406.fail](https://406.fail/)
- Points: 10
- Comments: 1

## Summary

**저품질 기여물 거부(RAGS)** 프로토콜은 오픈소스 커뮤니티가 자동화된 ‘AI 슬롭’을 식별하고 차단하기 위한 풍자적 RFC 형식의 제안서입니다. 메인테이너가 특정 URI를 붙여넣는 것만으로 거부 신호를 표준화해 전달할 수 있으며, 문서는 LLM 기반 제출물이 문법적으로 완벽하더라도 **논리·아키텍처 이해가 결여된 출력물의 무가치함**을 지적합니다. 유머러스한 형식을 취하지만, 실제로는 AI 자동화 기여 남용으로 인한 **유지보수 피로와 자원 낭비**라는 현실적 문제를 드러냅니다.

## Topic Body

- 오픈소스 저장소, 커뮤니티 등에서 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`

## Comments



### Comment 52572

- Author: neo
- Created: 2026-03-08T02:37:28+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47267947) 
- 진짜로 도움이 되고 싶다면, **자신이 직접 소유하고 유지보수하는 저장소**에 그 에너지를 쏟는 게 좋음  
  사람들도 이런 습관을 배워야 함. 포크를 공개하는 건 쉬워졌지만, 본인이 실제로 쓰지 않는 코드를 남이 써주길 기대하면 안 됨  
  GitHub에서 하루에 몇 개의 프로젝트에 PR을 보내는지 통계를 보면, 99%는 하나, 1%는 두 개, 0.1%는 세 개임. 5개 이상 PR을 보내는 계정은 거의 전부 **봇이나 스크립트**였음. 등록되지 않은 봇은 속도 제한을 걸어야 함
  - 이런 상황이라면, 내 포크가 원본 저장소 위에 주기적으로 리베이스되는 **영구 패치 모드** 같은 기능이 있으면 좋겠음. 예를 들어 한 줄짜리 수정이라도 자동으로 최신화되는 식으로

- 나는 [Ghostty의 AI 정책](https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md)을 더 선호함  
  “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에 대한 글](https://claytonwramsey.com/blog/prompt/)  
  - 나도 비슷한 접근을 함. Claude가 만든 코드를 완전히 이해하지 못할 때는, “이 부분은 왜 이렇게 했어?” “엣지 케이스는 어떻게 처리돼?” 같은 질문을 던지고, **수정하지 말고 설명만 하라**고 요청함. 이렇게 하면 결과를 내 것으로 만들 수 있음
  - 그 라이브러리를 실제로 사용 중이라면, **스테이징 환경에서 테스트**해보고 리뷰를 제출하는 게 좋음

- 마지막의 *plonk* 표현이 너무 좋았음  
  [Plonk(Usenet)](https://en-wikipedia--on--ipfs-org.ipns.dweb.link/wiki/Plonk_%28Usenet%29) 참고
  - BOFH Task Force라면 그 정도는 당연히 할 줄 알았음

- “rm -rf로 로컬 브랜치나 헛소리 스크립트를 지워라”는 문장이 너무 웃김  
  “**유기적 뇌를 하드 리부트하라**”는 표현도 완벽함
  - 사실 LLM이 이미 그런 PR 작성자들의 **뇌를 rm -rf** 해버린 것 같음