Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

LLM 사용 정책

이 문서는 rust-lang/rust에서 LLM을 어떻게 사용하는지에 대한 모더레이션 정책입니다. 정책 자체에 대한 추가 정보는 부록을 참조하십시오.

개요

rust-lang/rust 작업 중 LLM을 사용하는 것은 주의를 기울여 수행할 경우 조건부로 허용됩니다. LLM은 사고를 대체하는 것이 아니며, 프로젝트에 대한 우리의 공유된 사회적·기술적 이해를 잃을 위험이 있는 방식으로 사용하는 것을 허용하지 않으며, 강력한 커뮤니티를 만들고자 하는 우리의 목표를 해치는 방식으로도 허용하지 않습니다.

이 정책의 많은 조항이 강제할 수 없다는 것을 알고 있습니다. 저희의 목표는 모든 위반을 적발하는 것이 아닙니다 (아래 탐정 역할은 여러분의 일이 아닙니다 참조). 대신 저희의 목표는 그럴듯한 부인 가능성을 제거하는 것입니다: 정책을 따르는 것과 의도적으로 위반하는 것 사이에서 선택을 강제하는 것입니다. 동기에 대한 더 많은 배경은 자금 세탁과 AML 준수를 참조하십시오.

이 정책의 지침은 대략 다음과 같습니다:

질문에 답하기, 분석하기, 요약하기, 다듬기, 확인하기, 제안하기, 검토하기에 LLM을 사용하는 것은 괜찮습니다. 하지만 창작하는 데는 사용할 수 없습니다.

LLM은 더 빠르게가 아니라 더 낫게 쓰기 위한 도구로 사용될 때 가장 잘 작동합니다.

저희는 이 정책의 향후 개정에 참고하기 위해 “실험“을 위한 공간을 마련해 둡니다.

모더레이션 대 지침

이 문서는 저희의 모더레이션 정책만을 담고 있습니다. 기술적 지침과 제안은 rustc-dev-guide를 참고하십시오.

규칙

범례

  • ✅ 허용됨.
  • ❌ 금지됨.
  • ⚠️ 단서를 조건으로 허용됨. LLM이 사용되었음을 공개해야 합니다.
  • ℹ️ 정책에 추가적인 세부 사항을 더합니다. 이 항목들은 규범적입니다.
  • 💡 이 항목에 대한 제안이 dev-guide에 있음을 나타냅니다.
  • 🔨 이 조항을 위반하는 것은 행동 강령 위반에 해당합니다.

요약

  • ✅ 허용됨: 개인적 사용.
  • ❌ 금지: LLM이 작성한 댓글, 문서, 또는 진단 메시지. 인간의 판단을 LLM의 판단으로 대체하는 것. 기여하기 위해 LLM 사용을 강제하는 것.
  • ⚠️ 조건부 허용: 사소한 변경, 기계 번역, LLM 리뷰 및 리뷰 봇, 실험 규칙 하에서의 LLM이 작성한 코드.
  • 🔨 모더레이션 페널티 대상: 거짓말.

비배타적 정책

이 정책은 완전한 목록을 목표로 하지 않습니다. 이 목록에 없는 LLM 사용 사례가 떠오른다면 다른 사람들과 논의하고, 이 개요의 취지에 따라 판단하십시오:

  • 자신의 개인적인 용도로 LLM을 사용하는 것은 대체로 허용됩니다 ✅
  • 요청받지 않은 상태에서 LLM 출력을 다른 사람에게 보여주는 것은 대체로 금지됩니다 ❌
  • LLM 출력에 근거하여 타인에게 영향을 미치는 결정을 내리는 경우 공개가 필요합니다 ⚠️

✅ 허용

다음 사항들은 허용됩니다.

  • 출력 결과를 오직 자신만 보는 경우의 모든 LLM 사용. 예를 들면:
    • 기존 코드베이스에 대해 LLM에게 질문하는 것.
    • 이슈나 PR의 댓글을 요약해 달라고 LLM에게 요청하는 것.
      • ℹ️ 이는 요약본을 공개적으로 재게시하는 것을 허용하지 않습니다. 이는 오직 자신의 개인적인 용도만을 포함합니다.
    • 자신의 코드나 글을 비공개로 검토해 달라고 LLM에게 요청하는 것.
      • ℹ️ 이는 LLM이 남기는 공개 댓글에는 적용되지 않습니다. 아래 ⚠️ 항목의 “리뷰 봇“을 참조하십시오.
    • 자신의 개인적인 용도를 위해 LLM을 사용하여 개발 도구를 작성하는 것.
    • LLM을 사용하여 이슈에 대한 가능한 해결책을 생성하고, 이를 통해 학습한 뒤 자신만의 스타일로 처음부터 무언가를 작성하는 것.
  • crater나 perf를 실행하는 등 도구적 이유로 rust-lang/rust에 풀 리퀘스트로 존재해야 하지만 리뷰 대상은 아닌, 명백히 실험적인 코드 변경을 만드는 데 LLM을 사용하는 경우입니다.
    • “명백히 실험적인“이라 함은 S-experimental 레이블, [PERF] 제목, r? ghost 댓글과 같은 표식을 포함합니다.
    • 실험적 PR이 LLM 사용 사실을 공개할 것을 강력히 권장하지만, 의무는 아닙니다. 이는 다른 사람들이 LLM이 생성한 것임을 모른 채 초안 작업을 이어받는 상황을 방지하기 위한 것입니다.
    • ℹ️ PR이 더 이상 명백히 실험적인 것으로 표시되지 않는 경우, 그 시점부터는 공개가 필요합니다.

❌ 금지

다음 사항들은 금지됩니다.

  • 개인 사용자 계정에서 게시된, 원래 LLM이 작성한 댓글.
    • ℹ️ 이는 이슈 본문 및 PR 설명에도 적용됩니다.
    • ℹ️ 이는 LLM이 원래 작성하거나 대본을 작성한 음성/영상 콘텐츠에도 적용됩니다.
    • ℹ️ LLM 콘텐츠가 명확히 인용되고 표시된 경우에는 적용되지 않으며, 이러한 경우에는 게시할 수 있습니다. 다만, 댓글의 내용은 LLM 콘텐츠 없이도 그 자체로 성립해야 하며, 이는 여러분 자신의 말을 대체할 수 없습니다.
    • ℹ️ 아래 ⚠️의 “기계 번역” 항목도 참고하십시오.
    • ℹ️ 아래 부록의 “범위” 항목도 참고하십시오.
  • LLM이 원래 작성한 문서입니다.
    • ℹ️ 이는 문서 주석, 안전성 주석, 또는 여러 단락으로 이루어진 비문서 주석 등 사소하지 않은 소스 주석을 포함합니다.
    • ℹ️ 이는 컴파일러 진단 메시지를 포함합니다. LLM은 진단 메시지를 둘러싼 로직을 지원하는 데에는 조건부로 허용됩니다(아래 “실험: LLM이 생성한 코드 변경” 참고). 하지만 메시지 자체를 작성하는 데에는 사용될 수 없습니다.
    • ℹ️ 이는 “사소한” 변경(아래 ⚠️ 참고)을 포함하지 않습니다.
  • LLM이 실행해야 하도록 작성된 정책 또는 프로세스입니다.
    • 예를 들어, AGENTS.md로 테스트가 어디에 있는지 알리기만 해서는 안 됩니다. 문서는 우선적으로 사람을 위해 작성되어야 하며, LLM 문서는 이를 요약할 수 있을 뿐 새로운 세부 사항을 추가해서는 안 됩니다.
  • LLM 리뷰를 변경 사항을 병합하거나 거부하기에 충분한 조건으로 취급하는 것입니다. LLM 리뷰는 활성화되어 있더라도 반드시 참고용이어야 합니다. 팀은 리뷰 없이 코드를 병합할 수 있다는 정책을 가질 수도 있고, 최소 한 명의 사람이 코드를 리뷰해야 한다는 정책을 가질 수도 있지만, LLM 리뷰가 사람의 리뷰를 대체한다는 정책을 가질 수는 없습니다.
    • ℹ️ 아래 ⚠️의 “리뷰 봇” 항목을 참고하십시오.
    • ℹ️ LLM 리뷰는 자체 검토를 대체하지 않습니다. 작성자는 게시 전과 각 변경 이후에 자신의 코드를 스스로 검토해야 합니다.

⚠️ 유의사항을 전제로 허용

이러한 사용은 아래 규칙에 따라 사안별로 허용됩니다. 신규 기여자라면 리뷰어와 아직 신뢰를 쌓지 못했으므로 기존 기여자보다 더 면밀히 검토받게 될 것으로 예상해야 합니다.

“⚠️ 조건부로 허용됨“에 해당하는 모든 사용은 반드시 LLM이 사용되었음을 밝혀야 합니다.

  • 원문 메시지를 게시하지 않고 모국어에서 기계 번역(예: 구글 번역)을 사용하는 것은 허용되지만 권장되지 않습니다. 이렇게 하면 원래는 없었던 새로운 오해가 생길 수 있으며, 해당 언어를 구사하는 사람이 더 나은 번역을 제공할 기회를 막게 됩니다.
    • ℹ️ 원문 메시지와 번역본을 모두 게시하는 것은 언제나 괜찮지만, 그럼에도 기계 번역이 사용되었음을 공개해야 합니다.
  • “사소한” 코드 또는 문장 변경입니다.
    • ℹ️ 다른 방식으로 작성할 방법이 없거나, 다른 방식들이 거의 동일한 경우 변경 사항은 사소한 것으로 간주됩니다. 예를 들어, 다음은 모두 사소한 변경입니다.
      • 오타 수정
      • 마크다운 링크
      • 단어를 동의어로 바꾸기
      • 트레이트 구현에 대한 타입 시그니처
    • ℹ️ 사소한 변경만으로 구성된 PR에는 주의를 기울이십시오. 컴파일러 팀의 오타 수정 정책도 참고하십시오.
    • 💡 추가 제안 사항은 dev-guide를 참고하십시오.
    • 이 정책에 영감을 준 개념에 대한 더 자세한 배경은 독창성 임계값과, API 선언을 복사하는 것이 공정 이용이라는 구글 대 오라클 판결을 참고하십시오.
  • 직접 버그를 검증하는 한, LLM을 사용해 버그를 발견하는 것. 퍼저에 대한 저희 가이드라인을 참고하십시오.
    • ℹ️ 여기에는 병합되지 않은 코드에서 결함을 발견하기 위해 LLM을 사용하는 리뷰어도 포함됩니다.
    • ℹ️ 위 ❌ 항목의 “개인 사용자 계정에서 게시된 댓글 […]“도 참고하십시오.
  • PR에 대한 “리뷰 봇“으로 LLM을 사용하는 것.
    • ℹ️ 메인테이너의 승인 없이 게시하는 리뷰 봇은 차단됩니다. (12번 내용에 통합됨)
    • ℹ️ 리뷰 봇은 LLM임을 명확히 표시하는 별도의 GitHub 계정을 반드시 가져야 합니다. 봇의 분석에 대한 본인의 개인적인 해석과 함께 명확히 인용된 경우가 아니라면, 개인 계정으로 LLM 리뷰를 그대로 게시(또는 도구가 게시하도록 허용)해서는 안 됩니다.
    • ℹ️ 리뷰 봇 계정은 표준 GitHub 사용자 차단 메커니즘을 통해 개별 사용자가 차단할 수 있어야 합니다. (일부 GitHub “앱” 계정은 사용자처럼 보이는 댓글을 게시하지만 차단할 수 없다는 점에 유의하십시오.)
    • ℹ️ LLM 댓글은 차단용으로 사용되어서는 안 되며, 리뷰어는 어떤 댓글을 해결해야 하는지 명시해야 합니다.
      • 다시 말해, 리뷰어는 PR을 차단하기 전에 LLM 댓글을 명시적으로 지지해야 합니다. 리뷰어는 LLM 댓글에 대한 본인의 분석에 책임을 지며, 이를 CI 실패로 취급할 수 없습니다.
    • ℹ️ 이는 리뷰를 위해 LLM을 개인적으로 사용하는 경우에는 적용되지 않습니다. 위의 ✅를 참고하십시오.
    • 💡 추가 제안 사항은 dev-guide를 참고하십시오.

실험: 검토를 위해 만들어진 LLM 생성 코드 변경

저희는 향후 정책에 참고하기 위해 LLM으로 실험할 여지를 남겨두고 있습니다. (23번 내용에 통합됨)

규칙

원래 LLM이 만든 것으로, 사전 조율되고 중요하지 않으며 품질이 높고 충분히 테스트되고 충분히 검토된 코드 변경은 공개를 전제로 허용됩니다.

  1. “사전 조율됨“이란 리뷰어가 LLM으로 작성된 풀 리퀘스트를 리뷰할 의향이 있음을 미리 전달했다는 것을 의미합니다.
    • ℹ️ 신규 기여자는 먼저 리뷰어와 이야기하지 않고서는 LLM을 사용하여 풀 리퀘스트를 만들 수 없습니다. 이는 해당 풀 리퀘스트에 배정될 리뷰어와 동일한 리뷰어여야 합니다.
    • 물론 저자는 리뷰어를 찾기 전에 변경 작업을 시작하는 것이 허용됩니다. 그러나 풀 리퀘스트를 열기 전에 리뷰어를 찾아야 합니다. 리뷰어를 찾기 전에 r? @ghost로 LLM이 작성한 풀 리퀘스트를 여는 것은 허용되지만 권장되지는 않습니다. 대신 포크에 푸시한 뒤 예비 리뷰어를 위해 Zulip에 링크를 게시할 것을 제안합니다. 이러한 PR도 여전히 공개가 필요합니다.
  2. “비핵심적“이란 해당 풀 리퀘스트가 건전성 회귀를 일으킬 가능성이 극히 낮다는 것을 의미합니다.
    • ℹ️ 예시:
      • tidy, x setup, linkchecker와 같은 내부 도구에 대한 변경은 대체로 괜찮습니다.
      • 트레이트 시스템, MIR 빌딩, 쿼리 시스템처럼 건전성에 강한 영향을 미치는 변경은 아마도 허용되지 않을 것입니다.
  3. “고품질“은 다른 코드 변경과 최소한 동일한 기준을 적용받는다는 것을 의미합니다. 저자와 리뷰어뿐 아니라 모두가 코드를 읽습니다. 우리는 코드베이스의 품질을 저하시키는 “바이브 코딩된” 풀 리퀘스트에는 관심이 없습니다.
  4. “충분히 테스트됨“이란 여러분이나 리뷰어가 생각할 수 있는 모든 엣지 케이스를 다루었다는 것을 의미합니다.
    • ℹ️ LLM이 작성한 PR은 사람이 작성한 PR보다 더 높은 기준을 적용받습니다. LLM은 테스트 작성을 더 쉽게 만들기 때문입니다.
    • ℹ️ 코드의 특정 부분에 기존 테스트 스위트가 없다면, 새 테스트 스위트를 작성하거나 PR을 닫아야 합니다. “테스트 작성이 어려워 보인다“는 이유로 예외는 인정되지 않습니다.
  5. “충분히 리뷰됨“이란 저자와 리뷰어 모두가 코드를 완전히 이해하기로 약속했다는 것을 의미합니다.
    • ℹ️ 기존 리뷰 정책의 모든 리뷰 요구 사항이 여전히 적용됩니다.
    • ℹ️ 프로젝트 구성원의 리뷰가 자체 검토(self-review)를 대체하지는 않습니다. 저자는 게시 전과 각 변경 후에 자신의 코드를 직접 검토해야 합니다.
    • 💡 추가 제안은 dev-guide를 참고하십시오.

예외적으로 rust-lang 조직의 구성원은 “중요하지 않음” 조항에 구속되지 않습니다. 저자와 리뷰어가 스스로 판단을 내릴 것으로 신뢰하기 때문입니다. 그러나 이 조항을 활용하는 것은 강력히 권장하지 않습니다. LLM은 그럴듯해 보이는 코드를 생성하는 데 매우 뛰어나며, 건전성은 테스트하기 어렵습니다.

예외적으로 이 정책이 시행되기 전에 작성된 PR은 “중요하지 않음” 조항에서 면제됩니다.

절차

LLM으로 작성된 풀 리퀘스트에는 새로운 llm-assisted 레이블을 붙여야 합니다. 이러한 모든 풀 리퀘스트는 rust-lang 조직의 모든 구성원이 접근할 수 있는 새로운 (비공개) Zulip 채널에 게시됩니다. 이 채널의 목표는 LLM이 작성한 PR에 대한 추가적인 관문 역할을 하는 것이 아닙니다. 대신 이 실험이 효과가 있는지에 대한 정보를 수집하는 것이 목표입니다: 사람들이 LLM으로 흥미롭고 유용한 일을 하고 있습니까? 그들이 배우고 있습니까? 그들이 반복적으로 기여하고 있습니까?

새 채널이 비공개이기 때문에, 주제에 부합한다고 인정되는 기준이 평소보다 높게 적용됩니다. 예를 들어 다음은 주제에 부합합니다:

  • PR이 실험적 예외 기준을 충족하는지 여부
  • PR이 정책을 전반적으로 준수하는지 여부

그리고 다음은 주제와 무관합니다:

  • 기술 및 설계 논의. 이는 풀 리퀘스트에 직접 또는 공개 Zulip 채널에 게시되어야 합니다.
  • 노력, 커뮤니케이션 스타일, 의도에 관한 논의
  • LLM 정책에 관한 일반적인 논의

서킷 브레이커

LLM이 코드베이스를 “압도“하거나 사실상 필수 요건이 되는 위험을 피하기 위해, 병합될 수 있는 LLM 생성 PR의 수에 제한을 둡니다. 6주 기간 동안 병합된 PR 중 절반 이상이 LLM 생성 PR인 경우, 50% 미만으로 돌아갈 때까지 새로운 LLM 생성 PR의 병합을 허용하지 않으며, 최소 냉각 기간은 10일입니다. 이 기간은 기존 릴리스 주기에 맞춰 선택되었으며, 냉각 기간은 허용과 금지 사이를 오락가락하는 것을 방지하기 위한 것으로, FCP 프로세스에 맞춰 기간이 선택되었습니다.

냉각 기간은 다음과 같은 논의를 장려하기 위한 것입니다:

  • 실험은 어떻게 진행되고 있습니까?
  • 우리는 AI를 지속 가능한 방식으로 채택하고 있습니까? LLM을 사용하지 않기로 선택한 기여자들을 포함하고 있습니까?
  • 우리 정책에 변경하고 싶은 사항이 있습니까?

일관되지 않은 시행과 그로 인한 반감을 피하기 위해, 이 서킷 브레이커는 자동화할 것을 강력히 권장합니다.

부록

범위

이 정책은 rust-lang/rust에만 적용되며, 이를 승인한 팀들 — 컴파일러, 라이브러리, 타입, rustdoc, bootstrap 및 그 하위 팀들 — 에만 적용됩니다. 다음은 범위에 포함되지 않으며 자체 정책을 자유롭게 정할 수 있습니다:

  • rust-lang의 다른 저장소
  • 서브모듈, 서브트리, crates.io 의존성
  • 언어 팀, 에디션 팀 등 정책을 비준하지 않은 팀

예를 들어, 다음은 이 정책의 적용 대상이 아닙니다:

  • T-lang을 위한 추적 이슈
  • T-lang 제안
  • T-lang 안정화 보고서
  • 언어 문서
  • 스타일 가이드
  • 컴파일러 린트의 이름. 이는 이름 자체에만 적용되며, 진단 메시지는 여전히 이 정책의 적용 대상입니다.
  • 문서나 진단 메시지에서 위 내용을 그대로 인용하는 경우입니다.

동기와 지침 원칙

Rust 프로젝트 내에서 AI 기반 도구를 언제/어떻게/어디서 사용하는 것이 허용 가능한지에 대한 합의는 존재하지 않으며, 아마 앞으로도 존재하지 않을 것입니다. Rust 프로젝트와 커뮤니티의 많은 구성원이 AI에서 가치를 찾는 반면, 다른 많은 이들은 사회와 기후에 미치는 부정적 영향이 심각하여 어떠한 사용도 용납할 수 없다고 느낍니다. 또 다른 이들은 아직 자신의 의견을 정리하는 중입니다.

이러한 차이에도 불구하고, 우리 모두가 공유하는 가치가 많이 있습니다.

  • 우리 공동 프로젝트에 대한 깊은 전문 지식을 갖춘 커뮤니티를 구축하는 것입니다.
  • 모두가 환영받고 존중받는다고 느끼는 포용적인 커뮤니티를 구축하는 것입니다.

그리고 우리가 동의하는 많은 사실들이 있습니다.

  • 많은 사람들이 LLM이 생성한 코드와 글을 읽거나 검토하는 것이 매우 불쾌하다고 느낍니다.
  • 많은 사람들이 LLM을 학습과 발견에 상당한 도움이 된다고 느낍니다.
  • LLM은 새로운 기술이며, 우리는 아직도 이를 사용하고, 조정하고, 개선하는 방법을 배우는 중입니다.

이러한 사실과 가치를 염두에 두고, 이 정책은 다음 목표를 위해 설계되었습니다.

  • Rust가 알려진 품질 기준을 유지할 수 있도록 의도적으로 보수적인 정책을 수립합니다.
  • “더 나은 것이지, 더 빠른 것이 아니다“라는 우리의 지침이 단순한 말뿐이 아님을 보여주기 위해, LLM 기여를 최고 수준의 품질로 제한하는 것입니다.
  • 정책을 강제할 수 있고 조정하기 쉽게 만드는 것입니다.
  • 자세히 읽지 않은 사람들도 이해하고 요약하기 쉽도록 정책을 일관되게 만드는 것입니다.
  • LLM을 사용하지 않기로 선택한 기여자를 포용하고 Rust가 “페이 투 플레이“가 되는 것을 피하기 위해, LLM을 기여의 필수 요건으로 만드는 것을 피합니다.

조정 정책

탐정 역할을 하는 것은 여러분의 일이 아닙니다

“사기의 최적 수준은 0이 아닙니다”. 누군가 LLM을 사용했는지에 대해 경찰 노릇을 하려 하지 마십시오. LLM이 관여했는지 여부를 “적극적으로 찾아볼” 의무는 없습니다. 누군가 LLM을 사용했는지에 대해 경찰 노릇을 하려 하지 마십시오. LLM이 관여했는지 여부를 “적극적으로 찾아볼” 의무는 없습니다.

문체는 증거가 아니며, 영어를 외국어로 사용하는 화자, 신경다양인, 그리고 지나치게 설명이 많은 사람들이 LLM처럼 글을 쓴다는 비난을 받기 가장 쉽습니다.

누군가 규칙을 어겼다는 것이 명백하다면 이 정책을 알려주십시오. 그렇지 않다면 공개적인 비난보다는 모더레이터에게 신고하는 것을 강력히 선호하십시오. 모더레이션에 신고하는 것은 처벌을 의도한 것이 아닙니다. 모더레이션 팀은 위반 사례뿐 아니라 위반이 아닌 사례를 확인하는 데에도 관심이 있습니다. 언제나 그렇듯, 모더레이션 팀은 자신들의 판단과 재량을 자유롭게 행사할 수 있습니다.

정직하십시오

반대로, 여러분은 LLM 사용 여부와 그 사용 정도에 대해 정직해야 합니다. 하고 싶은 일이 이 정책에서 어디에 해당하는지 확실하지 않다면, 모더레이션 팀에 문의하십시오. 그것을 숨기려 하지 마십시오.

LLM 사용을 고의로 잘못 전달하는 것은 환영받지 못하며 모더레이션 조치로 이어질 수 있습니다.

처벌

🔨로 표시된 정책은 행동 강령과 동일한 지침을 따릅니다: 위반 시 먼저 경고가 주어지며, 반복 위반 시 차단될 수 있습니다.

  • 🔨 “정직할 것” 항목 위반

그 외 위반 사항은 리뷰어와 모더레이터의 재량에 맡깁니다. 경미한 위반의 경우, 정책을 준수할 때까지 PR을 검토할 수 없다고 작성자에게 알리고 정확히 무엇을 해야 하는지 안내할 것을 권장합니다. 중대한 위반이나 추출적 PR의 경우, PR이나 이슈를 닫을 것을 권장합니다.

LLM을 사용했다는 이유로 기여자를 괴롭히는 것은 허용되지 않습니다. 모든 기여자는 존중받아야 합니다. 행동 강령은 Rust 프로젝트 내의 모든 대화에 적용됩니다.

책임

기여 내용에 대한 책임은 본인에게 있으며, LLM에 책임을 전가할 수 없습니다.

  • ℹ️ 여기에는 원래 LLM이 작성한 리뷰 코멘트를 처리하도록 요청하는 경우도 포함됩니다. 위의 ⚠️ 항목에 있는 “리뷰 봇“을 참고하십시오.

“원래 LLM이 작성한“의 의미

이 문서에서는 “원래 LLM이 작성한“이라는 문구를 “LLM에 의해 생성된(그리고 이후 사람이 편집했을 수도 있는) 텍스트“라는 의미로 사용합니다. 아무리 편집을 하더라도 원래 어떻게 작성되었는지는 바뀌지 않습니다. 원본이 초기 스타일을 결정하며, 그 스타일은 한 번 정해지면 바꾸기가 매우 어렵습니다.

유사한 논증에 대한 더 많은 배경 지식은 “What Colour are your bits?”를 참고하십시오.

이 정책은 채팅 인터페이스에서 나온 LLM 출력과 에디터 자동완성에서 나온 출력을 구분하지 않습니다. 대부분의 경우 그 출력은 “사소한” 것이지만(위의 ⚠️ 항목 참고), 그렇더라도 이 정책에서는 특별히 다르게 취급하지 않습니다.

수정 또는 폐지 조건

이 정책은 고정불변이 아니며, LLM을 다루는 경험이 쌓임에 따라 발전시켜 나갈 수 있습니다.

오탈자 수정과 같은 사소한 변경은 일반적인 PR 승인만 있으면 됩니다. 새로운 규칙 추가나 기존 규칙 폐지와 같은 주요 변경은 이 정책을 승인한 각 팀으로부터 성공적인 MCP(주요 변경 제안)(승인 2건, 반대 의견 없음)를 받아야 합니다. rustc-dev-guide의 지침 변경에는 수정에 대한 특별한 요건이 없습니다.

이 정책은 다음 몇 가지 방식으로 폐지될 수 있습니다:

  • 정책을 비준한 팀들에 의한 승인된 FCP입니다.
  • 리더십 위원회 FCP로 결정되는, 해당 정책이 Rust 프로젝트에 끼치고 있는 실질적인 해악에 대해 증거와 함께 제기된 객관적인 우려입니다.
  • 제안된 LLM 위원회(또는 이와 유사한 프로젝트 전체 전담 기구)가 구성될 경우, 그 위원회가 정하는 정책은 이 정책보다 우선합니다.

위의 메커니즘으로 이 정책을 발전시키는 것이 실행 불가능하다고 판명될 경우, 특히 어떤 팀이 자신의 관할에 속하는 사안을 자율적으로 결정하는 데 있어 상당히 방해를 받게 될 경우, 이러한 수정 조건은 리더십 위원회 FCP로 조정될 수 있습니다.