▲

RFC 406i - AI 생성 저품질 기여 거부 (RAGS) 표준 프로토콜

 (406.fail)
1P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • The Rejection of Artificially Generated Slop (RAGS)
  • 오픈소스 저장소나 포럼 등에서 AI가 생성한 저품질 기여물을 식별하고 폐기하기 위한 표준 절차를 정의
  • 자동화된 생성물의 특징을 구체적으로 열거하며, 인간 유지관리자의 검토 시간을 낭비하는 행위를 명확히 거부
  • 비대칭적 노력 구조를 지적하며, 프로젝트 관리자의 한정된 자원을 보호하기 위한 거부 원칙을 제시함
  • 사용자가 다시 기여하려면 직접 코드와 문서를 읽고, 인간으로서 검증 가능한 작업을 수행해야 함
  • RFC 406i는 AI 생성물의 남용에 대한 풍자적 경고이자, 인간 중심의 협업 복원 요구로서 의미를 가짐

개요

  • RFC 406i(RAGS)는 AI가 생성한 저품질 자동화 기여물을 처리하고 폐기하기 위한 표준 프로토콜 정의
    • 적용 대상은 소스 코드 저장소, 이슈 트래커, 취약점 보고 포털, 커뮤니티 포럼 등
    • 공개 오픈소스 프로젝트뿐 아니라 내부 기업 시스템에도 해당

1. 서론

  • 문서의 대상은 AI 생성물 방어 시스템에 의해 차단된 기여자
  • 유지관리자가 제출물을 보고 즉시 연결을 종료하고 이 URI를 전달하는 상황을 묘사
  • RFC 용어(MUST, SHOULD 등)는 “우리가 당신의 제출물을 얼마나 검토하고 싶지 않은가”로 해석됨

2. 진단 분석

  • 제출물은 AI가 작성한 비현실적 코드와 문장 구조로 식별됨
    • 예시: “Certainly! Here is the revised output:” 같은 문구, 존재하지 않는 utils.helpers 임포트, “In conclusion…”으로 끝나는 요약문 등
    • 허구의 API, 불필요한 장황한 설명, 비현실적 완벽 변수명 등이 주요 징후로 제시됨
  • 결론: “당신이 읽지 않았으므로, 우리도 읽지 않겠다”는 원칙 선언

3. 노력의 비대칭성

  • 유지관리자와 보안팀은 제한된 자원 속에서 운영
  • AI 생성물은 문법적으로 그럴듯하지만 실제 문제를 해결하지 못함
  • 프로젝트 공간은 복사-붙여넣기식 산출물이나 KPI용 자동화 결과물의 투기장이 아님
  • 동료 개발자를 무료 LLM 검증 서비스로 이용해서는 안 됨

4. 복구 절차

  • 기여자가 다시 권한을 회복하려면 다음 단계를 수행해야 함
    1. 해당 브랜치나 파일 삭제 (rm -rf)
    2. 자기 뇌를 재부팅
    3. 코드베이스와 문서를 직접 읽고 논리 검증
    4. 인간으로서 자각을 회복한 뒤 직접 타이핑

5. 보안 고려사항

  • 상태: REJECTED
  • 진단: “사용자가 트렌치코트 속의 형편없는 Python 스크립트처럼 동작함”
  • 조치: 연결 종료

6. 제재 및 계정 제한

  • AI 생성물 제출자는 Trough of Sorrow™ 상태로 강등됨
    • 저장소 권한이 WRITE에서 WISHFUL_THINKING으로 변경될 수 있음
    • git push -f 명령이 rm -rf /로 재매핑될 수 있음
    • IDE 폰트가 7pt Comic Sans로 고정될 수 있음
  • 시스템 관리자에게 항의 금지, 관리자는 비공개 Slack 채널에서 웃고 있음

7. FAQ

  • “AI가 작성한 제출물”임을 부정하는 질문에 대해 기계가 기계를 거부하는 상황으로 응답
  • 문법적 완벽함은 기여의 최소 기준일 뿐, 논리적 타당성이 결여됨
  • “AI가 미래다”라는 주장에 대해 농경사회로의 회귀를 환영한다고 풍자
  • “도움을 주려 했다”는 항변은 서비스 거부 공격과 유사하다고 지적
  • “AI가 쓴 증거가 없다”는 주장에는 인간의 게으름은 예측 가능하지만, 이 수준의 광기는 서버팜만 가능이라 응답
  • “테스트가 통과했다”는 항변에는 테스트가 True == True만 검증한다고 반박
  • “리뷰를 통해 배우고 싶다”는 요청에는 LLM 디버깅 프록시가 아님이라 거절
  • “GitHub 포트폴리오를 채우고 싶다”면 모니터에 초록색 마커로 직접 칠하라고 조언
  • “커뮤니티는 환영적이어야 한다”는 주장에는 인간적 사고를 가진 존재만 환영한다고 명시
  • “모욕적이다”는 반응에는 공감 SLA가 99년이라 응답
  • “매니저에게 항의하겠다”는 위협에는 AI가 대신 사직서를 작성해 HR에 보냈다고 응수
  • “Code of Conduct 위반” 주장에는 탄소 기반 존재만 보호 대상이라 명시
  • “항소 가능성”은 /dev/null로만 가능
  • “사과 방법”은 PR을 종이학으로 접어 삼키는 것

부록 A: 위반 시 조치

  • 반복 위반 시 저장소 접근권 철회, MAC 주소 블랙리스트 등록, 정규식 튜토리얼 구독

부록 B: 표준 거부 매크로

  • Pull Request: “예측 텍스트 매트릭스처럼 보임, 인간 기반 테스트 필요”
  • 이슈 보고: “온도 파라미터가 너무 높음, 재현 가능한 스택트레이스 요구”
  • 보안 보고: “기초 린터 경고를 위협 서사로 포장한 것은 유효하지 않음”
  • 포럼 글: “이 커뮤니티는 RL 실험장이 아님, 인간적 질문으로 돌아오라”

마무리

  • RFC 406i는 AI 생성물의 남용에 대한 풍자적 선언문으로,
    인간의 사고와 검증을 기반으로 한 협업 복귀를 요구하는 메시지로 구성됨
▲
GN⁺ 7시간전  [-]
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 해버린 것 같음
답변달기