AI한테 "읽어도 돼, 근데 쓰지는 마" — 러스트 공식 LLM 정책 전문 해설

SVIL - Singularity Visual Intelligence Lab 2026. 08. 05 26 min read

AI한테 "읽어도 돼, 근데 쓰지는 마"라고 못 박은 프로젝트가 나왔어요

버그 리포트 100건 중 진짜는 5건. 나머지 95건은 그럴듯하게 잘 쓰였지만 알맹이가 없었어요. 세계에서 가장 널리 쓰이는 네트워크 라이브러리 중 하나인 cURL이 6년간 운영하던 버그 바운티를 2026년 1월에 접은 이유예요. 상금을 8만 6천 달러나 지급했는데, 정작 사람이 심사하는 시간이 감당이 안 됐거든요.

그리고 2026년 8월 5일, 프로그래밍 언어 러스트(Rust)의 핵심 저장소가 공식 LLM 정책을 채택했어요. 한 줄로 요약하면 이래요. "AI로 읽고, 분석하고, 검토하는 건 괜찮아요. 그런데 AI가 만든 걸 저장소에 넣지는 마세요."

AI 코딩 도구가 이렇게 좋아진 시대에, 왜 하필 지금 이런 선을 그었을까요. 오늘은 이 정책 문서를 처음부터 끝까지 뜯어볼게요.

2026년 8월 5일, 인사이드 러스트 블로그에 올라온 글

발표는 러스트 프로젝트의 내부 소식 채널인 인사이드 러스트 블로그(Inside Rust Blog)를 통해 나왔어요. 제목은 담백해요. "rust-lang/rust가 LLM 정책을 채택합니다."

이 정책은 어느 날 갑자기 튀어나온 게 아니에요. 몇 달에 걸친 논의의 결과물이에요. 러스트 리더십 카운슬(leadership council) 저장소에는 "저품질 기여 금지(No low-effort contributions)"라는 제목의 이슈가 올라와 있었고, RFC 저장소에는 AI 생성물 기여 정책을 다루는 제안이 두 건이나 병렬로 진행 중이었어요. 이번 정책은 그 논의들 가운데 가장 먼저 실제로 발효된 결과물이에요.

이 정책이 적용되는 정확한 범위

먼저 오해를 막고 갈게요. 이 정책은 러스트 프로젝트 전체에 적용되는 게 아니에요. 적용 대상은 rust-lang/rust 모노레포 한 곳이고, 그 저장소를 관리하는 다섯 개 팀이 채택한 규칙이에요.

모노레포(monorepo)라는 건 여러 프로젝트를 하나의 저장소에 몰아 넣은 구조를 말해요. 러스트의 경우 컴파일러, 표준 라이브러리, 문서 도구, 테스트 인프라가 전부 이 한 저장소 안에 들어 있어요. 러스트 언어의 심장부라고 보면 정확해요.

그래서 이 정책은 "러스트 커뮤니티는 AI를 싫어한다"가 아니라, "러스트의 심장부에 들어오는 코드에 대해서는 이 기준을 적용한다"에 가까워요. 이 구분은 생각보다 중요해요. 뒤에서 다시 짚을게요.

정책의 핵심 한 줄: 생각 도구는 되고, 생산 도구는 안 돼요

정책 전체를 관통하는 원칙이 하나 있어요. LLM을 '생각을 돕는 도구(thinking aid)'로 쓰는 것과, '저장소에 커밋될 결과물을 만들어내는 도구'로 쓰는 것을 구분한다는 거예요.

비유하자면 이래요. 시험 공부할 때 참고서를 읽고, 인터넷 강의를 듣고, 친구한테 개념을 설명해 달라고 하는 건 전부 괜찮아요. 그런데 시험지에 적는 답은 내가 이해한 내용으로 내 손으로 써야 하잖아요. 러스트가 그은 선이 딱 그 위치예요.

여기서 중요한 건 "AI를 쓰지 마세요"가 아니라는 점이에요. AI를 도구로 쓰는 건 오히려 명시적으로 허용돼요. 다만 그 출력물이 그대로 저장소에 들어가는 경로만 막은 거예요.

허용되는 것 — 생각보다 넉넉해요

초안 정책이 명시적으로 허용한 용도를 정리하면 이래요.

질문에 답하기 — "이 매크로가 어떻게 확장되는 건가요?" 같은 질문
코드 분석하기 — 낯선 모듈의 구조를 파악할 때
코멘트나 스레드를 개인적으로 요약하기 — 300개 넘게 달린 이슈를 따라잡을 때
비공개 코드 리뷰나 문장 검토 — 내가 쓴 걸 남에게 보내기 전에 점검하는 용도
해법 제안받기 — 접근 방향을 브레인스토밍하는 용도
정제하고, 다듬고, 검증하기

이 목록을 보면 알 수 있어요. 개발자가 LLM을 쓰는 상황의 상당 부분이 여기 들어가요. "AI 금지"라는 헤드라인만 보고 지레짐작하면 놓치는 지점이에요.

신경 필라멘트로 이루어진 전구와 기계식 조립 라인을 대비시킨 개념 이미지

금지되는 것 — 문서와 주석에 특히 엄격해요

반대로 명확히 막힌 영역이 있어요. 가장 눈에 띄는 게 문서예요. 정책은 LLM이 생성한 문서를 금지하는데, 그 범위가 꽤 넓어요.

사소하지 않은 소스 코드 주석
독 코멘트(doc comment) — 문서로 자동 변환되는 특수 주석
세이프티 코멘트(safety comment) — 안전하지 않은 코드 블록의 안전성 근거를 적는 주석
여러 문단짜리 소스 주석
컴파일러 진단 메시지 — 에러가 났을 때 사용자에게 보여지는 문구

코드보다 문서에 더 엄격해 보이는 게 처음엔 좀 의아할 수 있어요. 그런데 러스트 프로젝트의 성격을 생각하면 납득이 가요.

왜 하필 '문서'였을까 — 세이프티 코멘트의 무게

러스트에는 unsafe라는 키워드가 있어요. 컴파일러의 메모리 안전성 검사를 개발자가 직접 책임지고 우회하는 영역이에요. 그리고 러스트 커뮤니티에는 강한 관습이 있어요. unsafe 블록을 쓸 때는 반드시 "왜 이게 안전한가"를 주석으로 설명해야 한다는 거예요. 이게 세이프티 코멘트예요.

이 주석은 단순한 설명문이 아니에요. 증명이에요. "이 포인터는 이러이러한 이유로 항상 유효하다"는 논증이고, 나중에 누군가 코드를 고칠 때 이 논증이 여전히 성립하는지 확인하는 기준선이 돼요.

그런데 LLM이 만든 세이프티 코멘트는 위험해요. 문장은 자연스럽고 전문적으로 읽히지만, 실제 코드의 불변식(invariant)을 검증한 결과가 아니라 "이런 상황에서 사람들이 보통 쓰는 문장"을 재현한 것일 수 있거든요. 형식은 완벽하고 내용은 근거가 없는 상태예요. 다리에 붙은 안전 검사 표지판이 실제 검사 없이 붙어 있는 것과 같아요.

컴파일러 진단 메시지도 비슷해요. 러스트가 개발자들에게 사랑받는 큰 이유 중 하나가 "에러 메시지가 친절하다"는 건데, 그 친절함은 수많은 사람이 실제 사용자 혼란을 관찰하고 문구를 다듬어 온 결과예요. 그럴듯하게 생성된 문구로는 대체가 안 돼요.

정책이 겨냥한 세 가지 문제

정책 문서는 이 규칙을 만든 이유를 세 가지로 정리하고 있어요. 하나씩 볼게요.

잘 다듬어진 기술 결과물이 더 이상 노력과 이해의 증거가 되지 못한다
사람들이 LLM에 기계적으로 복사·붙여넣기를 왕복하는 것은 시간 낭비다
이 문제들이 커져서 전용 채널과 모더레이션 정책이 필요한 수준까지 왔다

이 세 줄이 사실 이번 정책의 전부예요. 나머지는 다 각론이에요.

문제 1: 잘 다듬어진 결과물이 더는 노력의 증거가 아니에요

오픈소스 협업은 오랫동안 하나의 암묵적 신호에 기대어 굴러갔어요. "잘 정리된 기여물 = 그만큼 시간을 들인 사람"이라는 신호요.

깔끔한 커밋 메시지, 조리 있는 PR 설명, 잘 정돈된 코드 스타일. 이런 것들은 메인테이너에게 "이 사람은 이 문제를 이해했구나, 진지하게 볼 만하다"는 힌트였어요. 리뷰할 게 산더미인 상황에서 어디에 시간을 먼저 쓸지 고르는 기준이었죠.

그런데 LLM이 이 신호를 무료로 만들어 낼 수 있게 되면서, 신호가 신호로서 기능하지 않게 됐어요. 겉이 잘 다듬어진 PR을 봐도 안을 열어보기 전엔 알 수가 없어요. 표면을 거울처럼 광낸 구슬인데 안이 텅 비어 있을 수도 있는 거예요.

이건 리뷰어에게 치명적이에요. 예전엔 훑어보고 걸러낼 수 있던 것을, 이제는 전부 다 열어봐야 하니까요. 심사 비용이 구조적으로 올라간 거예요.

문제 2: 기계적 복붙의 왕복 — 시간이 사라지는 구조

두 번째 문제는 더 구체적이에요. 리뷰어가 "여기 이 부분이 왜 이렇게 되어 있나요?"라고 물으면, 기여자가 그 질문을 그대로 LLM에 붙여넣고, 나온 답을 그대로 다시 붙여넣는 상황이에요.

이러면 대화가 무한 루프에 빠져요. 리뷰어는 사람과 이야기하고 있다고 생각하는데 실제로는 모델과 이야기하고 있고, 기여자는 중간에서 전달자 역할만 하고 있어요. 리뷰어가 쓴 시간은 온전히 사라져요. 기여자도 배우는 게 없고요.

정책 문서가 이 상황을 "시간 낭비"라고 딱 잘라 표현한 게 인상적이에요. 도덕적 비난이 아니라 비용 계산이에요. 이 왕복에서 가치가 생산되지 않는다는 관찰이죠.

문제 3: 방치하면 모더레이션 문제로 번져요

세 번째는 이 문제가 커진 속도에 관한 거예요. 정책 문서는 이 이슈들이 "전용 채널과 모더레이션 정책이 필요할 만큼 커졌다"고 적고 있어요.

여기가 중요해요. 처음엔 개별 PR의 품질 문제였던 게, 어느 순간 커뮤니티 운영의 문제로 성격이 바뀐 거예요. 개별 사안으로 하나씩 대응하는 게 불가능해지면 규칙을 명문화하는 수밖에 없어요. 이번 정책이 나온 직접적 계기가 그거예요.

배경: 오픈소스 메인테이너가 겪고 있는 홍수

러스트만의 이야기가 아니에요. 2026년 오픈소스 생태계 전반에서 같은 일이 벌어지고 있어요.

구조를 한 문장으로 요약하면 이래요. AI 코딩 도구가 PR을 만들어내는 공급 측은 폭발적으로 늘었는데, 그걸 심사하는 리뷰 측 용량은 그대로예요. 심사하는 쪽은 여전히 사람이고, 대부분 무보수 자원봉사자예요.

결과적으로 메인테이너들은 애초에 제출되지 말았어야 할 코드를 평가하는 데 시간의 상당 부분을 쓰고 있어요. 그 시간은 진짜 기여를 검토할 시간을 밀어내고, 번아웃을 앞당겨요. 인터넷의 핵심 인프라를 관리하는 사람들에게 지속 가능하지 않은 상황이에요.

실제 사례 1: cURL이 6년 된 버그 바운티를 닫았어요

가장 상징적인 사건이에요. cURL은 거의 모든 운영체제와 기기에 들어가 있는 데이터 전송 라이브러리예요. 창시자이자 리드 개발자인 다니엘 스텐베리(Daniel Stenberg)는 AI가 만들어낸 저품질 보안 리포트에 대해 오랫동안 공개적으로 문제를 제기해 왔어요.

숫자가 그 심각성을 보여줘요. 스텐베리에 따르면 2025년 후반 기준으로 유효한 리포트 비율이 20건 중 1건, 혹은 30건 중 1건 수준까지 떨어졌어요. 예전엔 훨씬 높았던 비율이에요.

그래서 2026년 1월, cURL은 6년간 운영하며 총 8만 6천 달러를 지급해 온 버그 바운티 프로그램을 종료했어요. 유효 리포트 비율이 약 5% 수준으로 내려앉은 상태였어요. 보상 제도가 오히려 슬롭 제출을 유인하는 구조가 되어버린 거예요.

스텐베리는 이 상황을 "AI 슬롭이 오픈소스를 디도스(DDoS) 하고 있다"고 표현했어요. 악의는 없지만 결과적으로 서비스 거부 공격과 똑같은 효과를 낸다는 뜻이에요.

실제 사례 2: Ghostty와 tldraw — 더 단순하고 더 극단적인 선택

다른 프로젝트들은 각자의 방식으로 대응했어요.

Ghostty는 터미널 에뮬레이터 프로젝트예요. 창시자 미첼 하시모토(Mitchell Hashimoto)는 사전 승인 없는 AI 생성 코드를 금지했어요. 러스트와 비슷한 방향이지만 훨씬 단순한 규칙이에요.

tldraw는 웹 기반 화이트보드 라이브러리예요. 스티브 루이스(Steve Ruiz)는 더 과감한 선택을 했어요. 외부에서 온 풀 리퀘스트를 전부 자동으로 닫아버려요. AI 생성물만 걸러내는 게 아니라, 외부 PR이라는 입구 자체를 닫은 거예요.

이 세 가지 대응을 나란히 놓고 보면 스펙트럼이 보여요. 러스트는 "용도별로 선을 긋는다", Ghostty는 "허가제로 운영한다", tldraw는 "입구를 닫는다". 프로젝트 규모와 커뮤니티 성격에 따라 선택이 갈린 거예요.

실제 사례 3: 깃허브가 고민한 '킬 스위치'

플랫폼 차원의 움직임도 있었어요. 2026년 2월, 깃허브(GitHub)가 AI 슬롭을 막기 위한 풀 리퀘스트 '킬 스위치'를 검토하고 있다는 보도가 나왔어요.

메인테이너가 필요할 때 외부 PR 접수를 통째로 잠글 수 있는 기능이에요. 소방 호스에 밸브를 다는 것과 비슷해요. 흥미로운 건 이게 tldraw가 스스로 구현한 대응을 플랫폼 기본 기능으로 올리는 방향이라는 점이에요. 개별 프로젝트의 임시방편이 업계 표준 도구가 되어가는 과정이죠.

숫자로 보는 구조 — 공급은 늘고 심사는 그대로

이 모든 사례가 가리키는 건 하나의 구조적 불균형이에요.

AI 코딩 도구를 쓰면 한 사람이 하루에 만들 수 있는 PR 수가 몇 배로 늘어요. 그런데 그 PR을 읽고, 이해하고, 테스트하고, 판단하는 데 걸리는 시간은 줄지 않아요. 오히려 앞서 말한 이유로 늘어났어요. 겉만 보고 거를 수 없게 됐으니까요.

저울의 한쪽 접시에는 기여물이 쏟아지고, 반대쪽 접시에는 사람의 시간이 그대로 있어요. 이 저울이 기울어지면 결국 무너지는 건 심사 쪽이에요. cURL의 바운티 종료가 그 첫 번째 붕괴였어요.

왜 '금지'가 아니라 '정책'인가 — 러스트가 조심한 지점

여기서 러스트의 선택이 흥미로워요. 가장 쉬운 길은 "AI 생성 코드 전면 금지"였을 거예요. 그런데 그렇게 하지 않았어요.

대신 용도를 잘게 쪼개서, 읽기·분석·검토는 열어두고 생성·커밋만 막았어요. 망치가 아니라 메스를 쓴 거예요.

이유는 짐작할 만해요. 전면 금지는 집행이 불가능하거든요. 누군가 LLM으로 개념을 이해한 뒤 자기 손으로 코드를 짰다면 그건 금지 대상인가요? 판별할 방법도 없고, 판별한다 해도 막을 이유가 없어요. 반면 "LLM 출력을 그대로 커밋하지 마라"는 훨씬 구체적이고, 리뷰 과정에서 드러날 가능성도 높아요.

이 정책이 '아닌' 것 — 러스트의 공식 입장이 아니에요

정책 문서 자체가 이 점을 분명히 밝히고 있어요. 이 정책은 LLM에 대한 러스트 프로젝트의 공식 입장이 아니고, 러스트 프로젝트 전체에 적용되지도 않아요.

다섯 개 팀이 자기들이 관리하는 저장소에 대해 채택한 실무 규칙이에요. 다른 러스트 관련 저장소들은 각자 다른 규칙을 쓸 수 있어요. 프로젝트 전체에 적용되는 정책은 RFC 3959번에서 별도로 논의되고 있어요.

이 구분을 강조한 게 현명해 보여요. 언어 생태계 전체의 입장을 한 번에 정하려 했다면 합의가 훨씬 오래 걸렸을 테고, 그동안 문제는 계속 커졌을 거예요. 급한 곳부터 막고 큰 논의는 따로 진행하는 방식이에요.

기여자 입장에서 실제로 달라지는 것

rust-lang/rust에 PR을 보내려는 사람 입장에서 정리하면 이래요.

LLM으로 코드베이스를 공부하고 접근 방법을 잡는 건 그대로 괜찮아요
내가 쓴 코드를 LLM에게 사전 리뷰받는 것도 괜찮아요
다만 커밋되는 코드와 주석은 내가 이해한 내용으로 내가 써야 해요
문서·독 코멘트·세이프티 코멘트·진단 메시지는 특히 조심해야 해요
리뷰어 질문에 LLM 답변을 그대로 붙여넣는 건 하면 안 돼요

실질적으로 요구되는 건 하나예요. 제출하는 내용을 본인이 설명할 수 있어야 한다는 것.

리뷰어와 모더레이터 입장에서 달라지는 것

정책은 리뷰어와 모더레이터에게도 적용돼요. 이 사람들에게 생기는 가장 큰 변화는 근거가 생겼다는 점이에요.

정책이 없을 때는 "이거 AI로 만든 것 같은데요"라고 말하는 것 자체가 부담스러웠어요. 증명하기 어렵고, 상대를 의심하는 모양새가 되니까요. 명문화된 규칙이 있으면 개인 판단이 아니라 정책 위반 여부의 문제가 돼요. 대화가 훨씬 덜 감정적으로 흘러가요.

또 하나, 저품질 기여를 닫을 때 긴 설명을 쓰지 않아도 돼요. 이것도 시간이에요.

LLM으로 '발견한' 이슈는 어떻게 되나

정책의 적용 대상에는 "LLM을 사용해 이슈를 발견한 사람"도 포함돼 있어요. 이건 cURL 사례와 직접 연결되는 부분이에요.

AI에게 코드베이스를 훑게 해서 "여기 취약점이 있을 것 같다"는 결과를 받고, 그걸 그대로 이슈로 올리는 패턴이요. 이게 cURL의 바운티를 무너뜨린 바로 그 패턴이에요.

핵심은 발견 도구로 LLM을 쓴 것 자체가 아니에요. 발견한 것을 사람이 검증했는지예요. 실제로 재현되는지, 조건이 맞는지 확인하고 올리면 가치 있는 기여지만, 확인 없이 그대로 넘기면 심사 부담만 남겨요.

다른 생태계와 비교하면 어디쯤인가요

러스트의 위치를 가늠하려면 다른 프로젝트들과 나란히 놓아보면 좋아요.

tldraw처럼 외부 PR을 아예 닫아버리는 게 가장 강경한 쪽이고, Ghostty의 사전 승인제가 그다음이에요. 러스트는 용도별 구분이라는 점에서 중간에 가까워요. 반대편 끝에는 아직 명시적 정책 없이 개별 판단으로 처리하는 다수의 프로젝트들이 있고요.

주목할 건 방향이에요. 2026년 들어 정책 없는 쪽에서 정책 있는 쪽으로 이동하는 프로젝트가 계속 늘고 있어요. 러스트처럼 큰 프로젝트가 움직였다는 건, 다른 프로젝트들이 참고할 템플릿이 하나 생겼다는 뜻이기도 해요.

반대 목소리도 있어요 — 집행 가능성과 형평성

이 정책에 이견이 없는 건 아니에요. 자주 나오는 반론을 정리하면 이래요.

집행 가능성. LLM이 쓴 주석과 사람이 쓴 주석을 실제로 어떻게 구분하나요? 탐지 도구는 오탐이 많고, 결국 리뷰어의 감에 의존하게 돼요. 규칙은 있는데 적용은 들쭉날쭉해질 수 있어요.

형평성. 영어가 모국어가 아닌 기여자에게 LLM은 언어 장벽을 낮춰주는 도구이기도 해요. 문서 생성을 엄격히 막으면 이 사람들이 상대적으로 불리해질 수 있다는 지적이 있어요. 다만 정책이 "검토·정제·다듬기"를 허용한 건 이 우려를 어느 정도 반영한 설계로 보여요.

시대 흐름과의 충돌. AI 코딩 도구가 표준이 되어가는 상황에서 핵심 저장소가 반대 방향으로 가는 게 장기적으로 맞느냐는 의문도 있어요. 이건 몇 년 지나야 답이 나올 문제예요.

기업 개발팀에도 그대로 옵니다

이 문제를 오픈소스만의 일로 보면 놓치는 게 있어요. 구조가 똑같이 재현되는 곳이 사내 개발팀이에요.

AI 코딩 도구를 도입하면 PR 수가 늘어요. 그런데 리뷰는 여전히 같은 팀원들이 해요. 리뷰 대기열이 길어지고, 리뷰 품질이 떨어지고, 결국 "일단 승인"이 늘어나요. 오픈소스에서 먼저 터진 문제가 시차를 두고 사내로 오는 셈이에요.

러스트 정책에서 가져올 만한 건 규칙 자체보다 사고방식이에요. AI 사용을 전면 금지하거나 전면 허용하는 이분법 대신, 용도별로 선을 긋는 것. 특히 "이 결과물을 제출한 사람이 설명할 수 있는가"를 기준으로 삼는 것. 이건 어느 조직에나 옮겨 붙일 수 있는 원칙이에요.

앞으로 볼 지점 — RFC 3950과 3959

이번 정책은 끝이 아니라 시작에 가까워요. 지켜볼 흐름이 두 갈래 있어요.

RFC 3950번은 AI 생성물에 대한 기여 정책을 다루는 제안이고, RFC 3959번은 프로젝트 전체에 적용되는 LLM 정책을 다루는 제안이에요. 두 건 모두 러스트 RFC 저장소에서 논의 중이에요.

이번에 발효된 건 rust-lang/rust 한 저장소용 실무 규칙이지만, 이 규칙이 실제로 어떻게 작동하는지가 위 RFC 논의의 실증 데이터가 될 거예요. 리뷰 부담이 실제로 줄었는지, 기여자 이탈이 생겼는지, 집행 과정에서 마찰이 있었는지 같은 것들요.

핵심 정리

오늘 내용을 정리할게요.

무슨 일: 2026년 8월 5일, 러스트의 핵심 저장소 rust-lang/rust에 LLM 사용 정책이 채택됐어요. 다섯 개 팀이 함께 만든 규칙이에요.
핵심 원칙: LLM을 생각 도구로 쓰는 건 되고, 저장소에 들어갈 결과물을 생성하는 도구로 쓰는 건 안 돼요.
허용: 질문, 분석, 요약, 비공개 리뷰, 해법 제안, 검증과 정제.
금지: LLM이 생성한 문서 — 독 코멘트, 세이프티 코멘트, 여러 문단짜리 주석, 컴파일러 진단 메시지.
이유 세 가지: 잘 다듬어진 결과물이 노력의 증거가 되지 못하게 됐고, 기계적 복붙 왕복이 시간을 낭비하며, 문제가 모더레이션 차원으로 커졌어요.
배경: cURL은 유효 리포트가 20~30건 중 1건 수준으로 떨어져 8만 6천 달러를 지급하던 버그 바운티를 2026년 1월에 종료했어요. Ghostty는 사전 승인제, tldraw는 외부 PR 자동 종료를 택했고, 깃허브는 PR 킬 스위치를 검토했어요.
범위 주의: 이 정책은 러스트 프로젝트 전체의 공식 입장이 아니에요. 전체 정책은 RFC 3959번에서 별도 논의 중이에요.
가져갈 원칙: 금지냐 허용이냐의 이분법 대신 용도별로 선을 긋는 것. 그리고 "제출자가 설명할 수 있는가"를 기준으로 삼는 것.

여러분은 어떻게 생각하세요?

AI 코딩 도구를 쓰다 보면 이 질문이 남 일 같지 않으실 거예요. 코드는 AI에게 맡기고 주석은 직접 쓰시나요, 아니면 반대이신가요? 팀에 AI 사용 기준이 따로 있으신가요?

러스트가 "문서에 더 엄격한 기준"을 적용한 게 특히 논쟁적인 지점 같아요. 이 선택에 공감하시는지, 아니면 반대로 보시는지 댓글로 이야기 나눠 주세요. 다음 글에서 더 깊이 다뤄볼게요.

출처

Inside Rust Blog, "rust-lang/rust is adopting an LLM policy" — https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/
rust-forge LLM usage policy draft — https://github.com/jyn514/rust-forge/blob/llm-policy/src/policies/llm-usage.md
rust-lang/rust-forge PR #1040, "Add an LLM policy for rust-lang/rust" — https://github.com/rust-lang/rust-forge/pull/1040
rust-lang/rfcs PR #3950, "Add contribution policy for AI-generated work" — https://github.com/rust-lang/rfcs/pull/3950
rust-lang/rfcs PR #3959, "Project-wide LLM policy" — https://github.com/rust-lang/rfcs/pull/3959
rust-lang/leadership-council Issue #273, "Policy proposal: No low-effort contributions" — https://github.com/rust-lang/leadership-council/issues/273
Socket.dev, "Rust Moves to Restrict LLM Use in Contributions" — https://socket.dev/blog/rust-moves-to-restrict-llm-use-in-contributions
The New Stack, "cURL's Daniel Stenberg: AI slop is DDoSing open source" — https://thenewstack.io/curls-daniel-stenberg-ai-is-ddosing-open-source-and-fixing-its-bugs/
The New Stack, "Open source maintainers are drowning in AI-generated pull requests" — https://thenewstack.io/ai-generated-code-crisis/
The Register, "GitHub ponders kill switch for pull requests to stop AI slop" — https://www.theregister.com/software/2026/02/03/github_ponders_kill_switch_for_pull_requests_to_stop_ai_slop/
LeadDev, "Open source has a big AI slop problem" — https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem
Linuxiac, "Rust May Limit AI-Generated Work in Its Core Repository" — https://linuxiac.com/rust-may-limit-ai-generated-work-in-its-core-repository/