Rust의 LLM 정책 초안은 올바른 선을 긋습니다

2026년 4월 17일에 열린 Rust Forge 풀 리퀘스트는 rust-lang/rust를 위한 LLM 사용 정책을 제안합니다. 2026년 5월 17일 현재 이 풀 리퀘스트는 아직 열려 있으며, 이슈 댓글 65개와 검토 댓글 284개가 달려 있습니다. 따라서 이 제안은 아직 채택된 정책이 아닙니다.¹

그럼에도 이 초안은 지금 중요합니다. 대부분의 AI 코딩 가이드가 피하는 경계를 정확히 짚기 때문입니다. LLM은 사람이 생각하고, 배우고, 확인하고, 실험하는 데 도움을 줄 수 있습니다. 하지만 프로젝트가 판단, 취향, 책임, 공동의 이해를 보존해야 하는 자리에서 사람의 저작을 대신해서는 안 됩니다.²

이 제안은 Rust의 기존 기여 규범과도 잘 맞습니다. 현재 Rust Forge 기여 가이드는 이미 기여자에게 신뢰를 쌓고, 검토자의 시간을 존중하고, 자신이 완전히 이해한 작업을 제출하고, 제출 전에 작업을 꼼꼼히 확인하고, 댓글은 간결하게 유지하라고 말합니다.³ 컴파일러 검토 정책도 검토자가 검토 중인 코드를 충분히 이해해야 하며, 검토 시간은 제한되어 있다고 말합니다.⁴ LLM 초안은 AI의 도움을 받는 작업에 대해 이런 오래된 기대치를 구체적인 규칙으로 바꿉니다.

요약

Rust 초안은 학습, 요약, 비공개 검토, 개인 도구, 실험을 위한 사적인 LLM 사용을 허용합니다.² 반면 LLM에서 비롯된 공개 댓글, 이슈 본문, 풀 리퀘스트 설명, 문서, 컴파일러 진단 메시지, 그리고 LLM 검토만으로 코드를 병합하거나 거부해도 된다고 보는 모든 절차는 금지합니다.² LLM이 만든 코드 변경에 대해서는 좁은 실험 경로를 둡니다. 요청된 작업이어야 하고, 핵심 위험 영역이 아니어야 하며, 공개되어야 하고, 품질이 높아야 하며, 충분히 테스트되어야 하고, 작성자와 검토자가 모두 완전히 이해해야 합니다.² 제 해석은 이렇습니다. 이 정책이 좋은 이유는 산출물의 양이 아니라 지적 책임의 보존을 최적화하기 때문입니다.

핵심 요점

• 유지관리자에게: 정책은 생산성을 말하기 전에 검토 역량, 프로젝트의 목소리, 책임을 먼저 보호해야 합니다.
• AI 코딩 팀에게: 사적인 사용은 넓게 허용하되, 공개 저작, 문서, 진단 메시지, 병합 권한에는 더 엄격한 선을 그어야 합니다.
• 기여자에게: 공개는 사람이 여전히 작업을 책임질 때만 의미가 있습니다. “모델이 작성했습니다”가 변명이 되어서는 안 됩니다.
• 도구 제작자에게: 검토 봇에는 별도 정체성, 차단 가능성, 낮은 오탐 압력, 조언자 지위가 필요합니다.
• 에이전트 팀에게: 초안에서 가장 좋은 규칙은 기술적 규칙이 아니라 문화적 규칙입니다. AI는 더 빨리 쓰기 위해서가 아니라 더 잘 쓰기 위해 사용해야 합니다.²

초안은 사고와 저작을 분리합니다

대부분의 LLM 정책은 서로 다른 두 행위를 하나의 범주로 뭉뚱그립니다. 바로 AI 사용입니다. Rust 초안은 이 행위를 사적인 사고와 공개 저작으로 나눕니다.

사적인 사고에는 넓은 허용 범위가 주어집니다. 기여자는 LLM에게 코드베이스에 대해 질문할 수 있고, 자신의 이해를 위해 댓글을 요약할 수 있으며, 자신의 코드나 글을 비공개로 검토할 수 있습니다. 개인 개발 도구를 만들 수도 있고, 직접 해결책을 쓰기 전에 배움의 재료로 가능한 해결책을 생성할 수도 있습니다.²

공개 저작에는 엄격한 선이 그어집니다. 초안은 개인 계정에서 올리는 댓글이라도 원래 LLM이 만들었다면 금지합니다. 같은 규칙은 이슈 본문과 풀 리퀘스트 설명에도 적용됩니다.² 초안은 LLM이 원래 작성한 문서도 금지합니다. 여기에는 의미 있는 소스 주석, 문서 주석, 안전 주석, 여러 문단으로 된 댓글, 컴파일러 진단 메시지가 포함됩니다.²

이 구분은 타당합니다. 공개 산출물은 프로젝트의 목소리를 담기 때문입니다. 컴파일러 진단 메시지, 안전 주석, 문서는 단순히 정보를 옮기는 역할만 하지 않습니다. 사용자에게 Rust가 어떻게 생각하는지를 가르칩니다. 또한 프로젝트가 장기적으로 유지해야 할 부담의 일부가 됩니다.

LLM이 생성한 글은 그럴듯하게 다듬어진 것처럼 보이면서도 그 부담을 약하게 만들 수 있습니다. 검토자는 이제 이렇게 물어야 합니다. 이 표현은 누가 선택했는가, 그 함의는 누가 이해하고 있는가, 경계 사례는 누가 책임지는가, 나중에 혼란이 생기면 누가 고칠 것인가? 초안은 기여자가 인간 계정의 신뢰성은 유지하면서 그 책임만 외주화하는 일을 허용하지 않습니다.

가장 강한 규칙: AI 검토를 병합 권한으로 삼지 않기

초안은 LLM 검토를 변경 사항을 병합하거나 거부하기 위한 충분조건으로 취급하는 일을 금지합니다.² 검토 봇은 존재할 수 있지만, 초안은 봇이 조언자 위치에 머물러야 한다고 요구합니다. 검토자가 풀 리퀘스트를 막으려면 LLM 댓글을 명시적으로 승인해야 하며, 작성자는 여전히 자기 검토 의무를 집니다.²

이 규칙은 유혹적인 실패 방식을 피하게 해줍니다. 팀은 AI 검토를 추가하고 작업 흐름이 더 안전해졌다고 말할 수 있습니다. 하지만 새 도구가 실제로는 아무도 평가할 시간이 없는 주장 흐름을 하나 더 만든 것뿐일 수 있습니다. 봇은 실제 버그를 찾을 수 있습니다. 동시에 사소한 이의 제기, 낡은 스타일 조언, 환각된 제약, 이해하지 못한 코드에 대한 확신에 찬 댓글도 만들 수 있습니다.

Rust 초안은 이 문제를 구조적으로 다룹니다.

요점은 LLM 검토에 가치가 없다는 말이 아닙니다. 검토 권한은 사람과 프로젝트 절차에 속한다는 말입니다. 기계는 검토자를 도울 수 있습니다. 하지만 기록상 검토자가 될 수는 없습니다.

코드 예외는 의도적으로 좁습니다

초안은 LLM이 만든 모든 코드를 금지하지 않습니다. 대신 5가지 조건을 충족하는 코드 변경에 대해 실험 경로를 만듭니다. 요청된 작업, 핵심 위험이 낮은 작업, 고품질, 충분한 테스트, 충분한 검토입니다.²

각 단어는 실제 역할을 합니다.

요청된 작업이라는 말은 검토자가 LLM이 만든 풀 리퀘스트를 검토하겠다고 사전에 동의했다는 뜻입니다. 새 기여자는 PR에 배정된 같은 검토자와 먼저 이야기하지 않는 한 이 경로에서 LLM을 사용할 수 없습니다.²

핵심 위험이 낮은 작업은 AI가 만든 변경을 건전성 회귀를 일으킬 수 있는 영역에서 멀리 두려는 장치입니다. 초안은 내부 도구를 더 그럴듯한 예로 들고, trait system, MIR building, query system 같은 영역은 아마 적절하지 않다고 봅니다.²

고품질은 코드가 적어도 다른 변경과 같은 기준을 충족해야 한다는 뜻입니다. 초안은 코드베이스의 품질을 떨어뜨리는 PR을 명시적으로 거부합니다.²

충분한 테스트는 기준을 더 높입니다. LLM이 만든 PR에는 더 높은 테스트 기대치가 적용됩니다. LLM은 테스트 작성을 더 쉽게 만들기 때문입니다. 기존 테스트 스위트가 해당 코드를 다루지 않는다면, 작성자는 새 테스트를 작성하거나 PR을 닫아야 합니다.²

충분한 검토는 작성자와 검토자가 모두 코드를 완전히 이해하겠다고 약속한다는 뜻입니다. 프로젝트 멤버의 검토는 자기 검토를 대체하지 않습니다.²

이 실험은 유용한 형태를 갖고 있습니다. AI가 만든 코드가 도움이 될 수 없다고 가장하지 않습니다. 동시에 “AI의 도움을 받은 기여”의 게으른 버전도 거부합니다. 기여자가 패치를 생성하고, 유지관리자에게 그것을 분류해 달라고 맡기며, 이해에는 인간의 노력을 들이지 않는 방식 말입니다.

더 빠르게가 아니라 더 잘

초안에서 가장 중요한 문장은 LLM이 사람들이 더 빠르게 쓰도록 할 때가 아니라 더 잘 쓰도록 할 때 가장 잘 작동한다고 말합니다.²

이 문장은 AI 코딩의 기본 기준이 되어야 합니다.

속도만 추구하면 작업은 작성자에게서 검토자에게 넘어갑니다. 기여자는 패치 생성으로 1시간을 아낄 수 있습니다. 그러면 유지관리자는 쓸 만한 코드와 이상한 테스트, 부풀린 댓글, 모호한 진단 메시지, 책임자가 없는 설계 선택을 분리하는 데 3시간을 씁니다. diff가 결국 컴파일되더라도 프로젝트는 손해를 봅니다.

더 잘한다는 기준은 다른 질문을 던집니다. 도구가 사람이 더 날카로운 이해를 형성하도록 도왔는가? 작성자가 검증한 경계 사례를 찾아냈는가? 작성자가 이해하는 테스트 초안을 만드는 데 도움이 되었는가? 최종 기여가 검토하기 쉽고, 유지하기 쉽고, 신뢰하기 쉬워졌는가?

Rust 초안은 이 구분을 집행 가능하게 만듭니다. 사적인 LLM 사용은 작성자의 이해를 개선할 수 있습니다. 공개된 LLM 기반 저작은 프로젝트의 공동 이해를 약화할 수 있습니다. 실험적인 AI 생성 코드는 요청, 범위, 품질, 테스트, 검토가 모두 추가 부담을 감당할 때만 진행될 수 있습니다.

이 조합은 무조건적인 낙관론과 무조건적인 금지보다 낫습니다. 기술이 도움이 될 수는 있지만, 모델이 싸게 만들었다는 이유만으로 책임이 희박한 산출물을 프로젝트가 떠안지는 않겠다고 말하기 때문입니다.

조정 섹션은 마녀사냥을 피합니다

초안은 집행도 보기 드물게 신중하게 다룹니다. 기여자에게 LLM 사용 여부를 탐정처럼 조사할 필요는 없다고 말합니다. 위반이 명확해 보이면 정책을 가리키면 됩니다. 경계선에 있는 사례처럼 보이면 조정 담당자에게 보고하고 넘어가면 됩니다.²

같은 섹션은 LLM 사용에 대해 거짓말하는 일을 행동 강령 문제로 다룹니다. 동시에 LLM을 사용했다는 이유로 기여자를 괴롭히는 일도 허용되지 않는다고 밝힙니다.² 이 조합은 중요합니다. 의심을 부추기는 정책은 막으려는 AI 생성 콘텐츠보다 더 빠르게 커뮤니티를 망칠 수 있습니다.

좋은 AI 정책에는 2가지 경계가 필요합니다.

초안은 모든 검토자를 조사관으로 만들지 않으면서도 책임을 기여자에게 둡니다. 이는 코드만큼이나 검토 문화를 보호합니다.

다른 프로젝트가 따라 배워야 할 점

Rust 제안이 주목할 만한 이유는 막연한 분위기가 아니라 역할을 정의하기 때문입니다.

LLM은 다음처럼 사용하세요.

• 사적인 교사;
• 사적인 검토자;
• 자신의 이해를 위한 요약 도구;
• 사람이 버그를 검증할 때의 버그 발견 보조 수단;
• 검토자가 동의하고 범위가 낮은 위험에 머무를 때의 실험 원천.

LLM을 다음처럼 사용하지 마세요.

• 공개 댓글의 작성자;
• 프로젝트 문서의 목소리;
• 컴파일러 진단 메시지의 작성자;
• 인간 검토의 대체물;
• 작성하지 않은 테스트에 대한 변명;
• 자신이 이해하지 못한 코드를 유지관리자가 검토하게 만드는 방법.

이 목록은 유지관리자에게 도덕적 주장보다 나은 것을 줍니다. 운영할 수 있는 정책을 줍니다.

제 해석

이 초안은 AI 코딩이 만드는 품질 문제와 맞닿아 있습니다. 코드는 더 싸게 생산됩니다. 하지만 검토 주의력, 취향, 일관성, 프로젝트의 목소리, 사회적 신뢰는 더 싸지지 않습니다. 희소성은 더 위층으로 이동합니다.

산출물의 양을 최적화하는 프로젝트는 그럴듯한 diff 속에 유지관리자를 빠뜨릴 것입니다. 책임 있는 보유를 최적화하는 프로젝트는 여전히 AI를 사용할 수 있습니다. 다만 인간 작성자를 더 유능하게 만들고 검토자의 부담을 줄이는 방식으로만 사용할 수 있습니다.

Rust 초안은 희소한 층을 보호합니다. 진단 메시지, 댓글, 문서, 검토 권한을 교체 가능한 텍스트가 아니라 프로젝트의 일부로 다룹니다. 테스트와 자기 검토를 부속물이 아니라 의무로 봅니다. 실험에는 길을 열어 주지만 백지 수표를 주지는 않습니다.

진지한 소프트웨어 프로젝트라면 이 방향이 맞습니다. Rust가 무언가를 채택하기 전에 정확한 규칙은 바뀔 수 있습니다. 하지만 기본 형태는 바뀌지 않아야 합니다. AI는 사람이 더 나은 작업을 하도록 도울 수 있지만, 기여는 여전히 사람이 책임져야 합니다.

FAQ

이 Rust 정책은 채택되었나요?

아니요. 2026년 5월 17일 현재 이 정책은 “rust-lang/rust의 LLM 정책 추가”라는 제목의 열린 Rust Forge 풀 리퀘스트로 존재합니다. 현재 rust-lang/rust-forge main branch에는 아직 src/policies/llm-usage.md가 없습니다.¹⁵

초안은 모든 AI 사용을 금지하나요?

아니요. 초안은 학습, 요약, 검토, 개인 도구, 아이디어 생성을 위한 사적인 LLM 사용을 조건부로 허용합니다. 또한 공개되고, 요청되었고, 핵심 위험이 낮고, 품질이 높고, 충분히 테스트되었고, 충분히 검토된 LLM 생성 코드에 대해 좁은 실험 경로를 만듭니다.²

초안은 무엇을 금지하나요?

초안은 LLM에서 비롯된 공개 댓글, 이슈 본문, 풀 리퀘스트 설명, 문서, 컴파일러 진단 메시지, 그리고 LLM 검토만으로 코드를 병합하거나 거부해도 된다고 보는 행위를 금지합니다.²

초안은 왜 문서와 진단 메시지를 그렇게 엄격하게 다루나요?

문서와 진단 메시지는 프로젝트의 목소리, 사용자 안내, 장기 유지보수 의무를 담습니다. 초안은 일부 경우에 LLM이 주변 논리를 보조하는 것은 허용하지만, 메시지 자체를 LLM이 만들지는 못하게 합니다.²

AI 코딩 팀은 이 제안에서 무엇을 배워야 하나요?

사적인 보조와 공개 저작을 분리해야 합니다. AI가 다른 사람에게 영향을 미치는 곳에서는 공개를 요구해야 합니다. 검토 권한은 사람에게 남겨야 합니다. AI가 코드 생성을 도울 때는 테스트와 자기 검토 기준을 높여야 합니다. 더 많은 산출물이 아니라 더 나은 작업을 최적화해야 합니다.

참고 문헌