Rust-lang/rust, LLM 사용 정책 도입

TL;DR Highlight

Rust가 LLM 코드는 엄격히, 답변·분석·리뷰용 사용은 공개 조건으로 허용

Who Should Read

오픈소스 프로젝트에 LLM으로 만든 PR이나 이슈를 올리거나, 그런 PR을 리뷰해야 하는 개발자

Core Mechanics

정책은 Rust 전체가 아니라 rust-lang/rust 저장소용
- 5개 팀이 채택했고, Rust 프로젝트의 공식 LLM 입장은 아니다.
- 대상은 PR 리뷰·중재자, LLM 코드 PR 작성자, LLM으로 이슈를 찾은 사람, LLM 출력을 인용하는 사람이다.
핵심은 만들지 말고 도움만 받으라는 것
- 질문, 분석, 요약, 다듬기, 점검, 제안, 리뷰에는 LLM을 써도 된다.
- 만드는 용도는 크게 제한되고, 공개 문서·PR 설명·GitHub 댓글의 LLM 출력은 명확히 표시해야 한다.
LLM 코드 PR은 사람보다 기준이 높다
- 사전 협의된, 핵심이 아닌, 고품질이고 테스트와 리뷰를 거친 LLM 코드만 공개 조건으로 허용된다.
- LLM PR에는 테스트가 필수이고, 해당 분야 전문가가 아니면 soundness(타입·메모리 안전 보장)에 걸린 변경은 금지다.
정책을 만든 이유는 세 가지 문제
- 완성도 높은 PR이 더 이상 작성자의 노력과 이해를 보증하지 않는다.
- 코드 작성이 쉬워질수록 부족한 리뷰 시간 문제가 더 심해진다.
- 리뷰 댓글을 LLM에 복붙해서 답을 다시 붙이는 건 모두의 시간 낭비이고 신뢰 위반이다.
리뷰어에게는 닫을 권한과 면책이 있다
- 정책을 어긴 PR은 이유를 따지지 않고 닫아도 되고, #llm-mentoring 채널을 안내한다.

Community Reactions

새 기여자는 리뷰어를 모른다는 지적
- 새 기여자는 PR 전에 리뷰어와 먼저 이야기해야 한다는데 아는 리뷰어가 없다는 의견이 있었다.
- 올바른 절차가 무엇인지 묻는 질문이었다.
괴롭힘 금지와 감시 금지 조항 환영
- LLM 사용자를 괴롭히지 못하게 한 조항이 좋다는 의견이 있었다.
- 포럼에서 심한 모욕을 받아 본 경험이 있다는 댓글도 있었다.
- 누가 LLM을 썼는지 경찰처럼 찾지 말라는 규칙이 특히 좋다는 의견이 있었다.
공개 의무가 마녀사냥을 부른다는 반론
- 공개 규칙이 외형만 보고 의심하는 풍토로 이어질 수 있다는 우려가 나왔다.
- 신규 기여자를 막는 폐쇄적 커뮤니티로 흐를 수 있다는 주장이다.
강제할 수 있느냐는 회의론
- 줄표를 빼는 식으로 숨기면 AI 생성물인지 알 수 없다는 의견이 있었다.
- 이미 Rust 코드베이스에 AI 코드가 있다는 지적도 있었다.
금지보다 새 병목 해결에 집중하자는 의견
- 앞으로 개발자가 손으로 코드를 쓰지 않게 되므로 금지 정책은 역효과라는 주장이 있었다.
- 병목이 리뷰로 옮겨 갔고 CI/CD처럼 해법이 나올 거라는 의견이었다.

How to Apply

PR 템플릿에 LLM 사용 여부 칸 추가하기
- 오늘 저장소의 PR 템플릿에 'LLM으로 생성·분석·번역했는가, 어느 부분인가' 체크박스를 넣어라.
- 판별 책임을 작성자에게 두어 리뷰어가 의심할 필요를 없애라.
LLM 사용을 만들기와 돕기로 나눈 규칙 쓰기
- 팀 CONTRIBUTING 문서에 질문·분석·요약·리뷰는 허용, 코드 생성은 사전 협의와 테스트 필수로 적어라.
- 공개 댓글에 붙는 LLM 출력은 표시하도록 명시하라.
LLM PR 요건을 리뷰 체크리스트에 넣기
- 테스트 유무, 사전 합의 여부, 핵심 영역 포함 여부를 먼저 확인하라.
- 하나라도 어기면 사유를 정책 조항으로 적고 닫아라.
리뷰 답변은 직접 쓰기 규칙 정하기
- 리뷰 댓글을 LLM에 붙여넣고 답을 그대로 올리지 말라고 팀 규칙에 적어라.
- LLM을 썼다면 어느 부분인지 인용 표시하게 하라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 붙여넣기 (Rust LLM 정책 아이디어를 내 저장소 CONTRIBUTING 초안으로 옮기는 간이 버전)

너는 오픈소스 메인테이너다. 아래 원칙으로 우리 저장소 CONTRIBUTING의 'LLM 사용 정책' 초안을 한국어로 써줘.
- 질문, 분석, 요약, 다듬기, 점검, 제안, 리뷰에는 LLM을 써도 된다. 새로 만드는 용도는 크게 제한한다.
- 공개 문서, PR 설명, 댓글의 LLM 출력은 명확히 표시해야 한다.
- LLM 코드 PR은 사전 협의, 테스트 필수, 핵심 영역 금지 조건을 둔다.
- 리뷰어는 정책 위반 PR을 닫을 수 있고, LLM 사용 여부는 작성자가 밝힌다.
- 문체만으로 LLM 사용을 의심하거나 사용자를 괴롭히는 건 금지한다.

우리 저장소 정보: {{저장소 설명}}
우리가 핵심 영역으로 지정할 부분: {{핵심 영역}}

이어서 해 볼 것: 같은 내용으로 PR 템플릿 체크박스 문구도 만들어 달라고 요청해 보세요.

Terminology

soundness-critical change언어가 약속하는 안전 보장이 깨질 수 있는 변경이다. 건물 하중을 받는 기둥을 건드리는 공사와 비슷해서 전문가만 해야 한다.

모노레포(monorepo)여러 구성요소를 한 저장소에 넣어 관리하는 방식이다. rust-lang/rust가 대표적인 예다.

MIRRust 컴파일러가 코드를 변환하는 중간 표현이다. 최적화 PR이 이 단계를 건드리기 때문에 위험할 수 있다.

shotgunning리뷰어에게 PR을 산탄총처럼 무더기로 던지는 행위다. 리뷰어의 판단 비용만 늘린다.