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은 사고를 대신할 수 없습니다. 따라서 프로젝트에 대해 저희가 함께 쌓아 온 사회적·기술적 이해를 잃을 위험이 있는 방식이나, 강한 커뮤니티를 만든다는 저희의 목표를 해치는 방식으로 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에 PR로 올려야 하는, 명백히 실험적인 코드 변경을 만드는 데 LLM을 사용하는 것.
    • “명백히 실험적“이라는 표시에는 S-experimental 레이블, [PERF] 제목, r? ghost 댓글 등이 포함됩니다.
    • 실험적인 PR에서 LLM 사용 사실을 공개하는 것을 필수로 요구하지는 않지만 강력히 권장합니다. 다른 사람이 LLM으로 생성된 것임을 모른 채 초안 작업을 이어받는 일을 막기 위해서입니다.
    • ℹ️ PR에 더 이상 명백히 실험적이라는 표시가 없다면 그 시점부터는 공개가 필수입니다.

❌ 금지

다음은 금지됩니다.

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

⚠️ 조건부 허용

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

“⚠️ 조건부 허용“에 해당하는 모든 사용은 LLM을 사용했다는 사실을 반드시 밝혀야 합니다.

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

실험: 리뷰를 받기 위해 LLM으로 만든 코드 변경

향후 정책 수립에 참고하기 위해 LLM을 실험해 볼 여지를 열어 둡니다. 이 실험은 향후 실험 단계가 아닌 정식 정책을 수립하는 데 참고하기 위한 것이며, 영구적인 LLM 사용 정책이 되려는 것이 아닙니다.

규칙

처음에 LLM으로 만든 코드 변경이라도 사전에 합의되었고, 핵심적이지 않으며, 품질이 높고, 충분히 테스트되고 리뷰되었다면 그 사실을 밝히는 조건으로 허용됩니다.

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

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

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

절차

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

새 채널은 비공개이므로, 주제에 맞는 내용으로 인정되는 기준이 평소보다 높습니다. 예를 들어, 다음은 주제에 맞는 내용입니다.

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

반면 다음은 주제에서 벗어난 것입니다:

  • 기술 및 설계에 관한 논의. 이러한 논의는 PR에 직접 게시하거나 공개 Zulip 채널에 게시해야 합니다.
  • 들인 노력, 소통 방식 또는 의도에 관한 논의
  • LLM 정책에 관한 일반적인 논의

서킷 브레이커

LLM이 코드베이스를 “압도“하거나 사실상 필수가 되는 위험을 피하기 위해, 병합될 수 있는 LLM이 작성한 PR의 수에 제한을 둡니다. 6주 기간 동안 병합된 PR 중 절반 이상이 LLM이 작성한 PR이면, 그 비율이 다시 50% 미만으로 내려갈 때까지 새로운 LLM이 작성한 PR의 병합을 허용하지 않으며, 최소 유예 기간은 10일입니다. 이 기간은 기존 릴리스 주기에 맞추어 정했으며, 냉각 기간은 허용과 불허 사이를 오락가락하는 것을 피하기 위한 것으로, 그 길이는 FCP 절차에 맞추어 정했습니다.

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

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

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

부록

적용 범위

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

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

예를 들어, 다음은 이 정책의 적용을 받지 않습니다:

  • T-lang의 추적 이슈
  • T-lang 제안
  • T-lang 안정화 보고서
  • 언어 문서
  • 스타일 가이드
  • 컴파일러 린트의 이름. 이는 이름 자체에만 해당하며, 진단 메시지는 여전히 이 정책의 적용을 받습니다.
  • 위 항목 중 어느 것이든 문서나 진단 메시지에 그대로 인용하는 것.

동기와 기본 원칙

AI 기반 도구를 언제, 어떻게, 어디에서 사용하는 것이 허용되는지에 대해 Rust 프로젝트 내에는 합의가 없으며, 앞으로도 합의에 이르지 못할 가능성이 큽니다. Rust 프로젝트와 커뮤니티의 많은 구성원은 AI에서 가치를 발견합니다. 반면 AI가 사회와 기후에 미치는 부정적 영향이 너무 심각하여 어떠한 사용도 용납할 수 없다고 느끼는 구성원도 많습니다. 아직 자신의 의견을 정리하고 있는 구성원도 있습니다.

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

  • 우리가 함께하는 프로젝트에서 깊은 전문성을 갖춘 사람들의 커뮤니티를 만드는 것.
  • 모두가 환영받고 존중받는다고 느끼는 포용적인 커뮤니티를 만드는 것.

또한 우리가 동의하는 사실도 많습니다.

  • 많은 사람은 LLM이 생성한 코드와 글을 읽거나 리뷰하는 것을 매우 불쾌하게 느낍니다.
  • 많은 사람은 LLM이 학습과 탐구에 큰 도움이 된다고 느낍니다.
  • LLM은 새로운 기술이며, 우리는 LLM을 사용하고, 관리하고, 개선하는 방법을 아직 배워 가는 중입니다.

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

  • Rust 하면 떠오르는 품질 기준을 유지할 수 있도록 의도적으로 보수적인 정책을 수립합니다.
  • “더 빠르게가 아니라 더 좋게“라는 우리의 지침이 말뿐이 아님을 보여 주기 위해, LLM을 활용한 기여는 최고 수준의 품질을 갖춘 경우로만 제한합니다.
  • 정책을 집행할 수 있고 모더레이션하기 쉽게 만듭니다.
  • 정책을 자세히 읽지 않은 사람도 쉽게 이해하고 요약할 수 있도록 일관되고 알기 쉽게 만듭니다.
  • LLM 사용을 기여의 필수 조건으로 만들지 않습니다. 이는 LLM을 사용하지 않기로 한 기여자도 포용하고, Rust가 “돈을 내야 참여할 수 있는” 프로젝트가 되지 않도록 하기 위함입니다.

모더레이션 정책

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

“사기의 최적량은 0이 아닙니다”. 누군가가 LLM을 사용했는지 단속하려 하지 마십시오. LLM이 관여했는지 “적극적으로 찾아낼” 필요는 없습니다.

문체는 증거가 되지 않습니다. 영어를 제2언어로 사용하는 사람, 신경다양인, 설명을 길게 하는 사람이 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를 승인하는 경우.
  • 이 정책이 Rust 프로젝트에 실제로 해를 끼치고 있다는 객관적인 우려가 증거와 함께 제기되고, 리더십 위원회 FCP로 그렇게 결정된 경우.
  • 제안된 LLM 위원회(또는 이와 유사하게 프로젝트 전체를 담당하는 전담 기구)가 구성되면, 그 기구가 정하는 정책이 이 정책보다 우선합니다.

위의 절차로 이 정책을 발전시키는 것이 불가능하다고 판명되는 경우, 특히 어떤 팀이 자신의 관할에 관한 결정을 자율적으로 내리는 데 크게 방해를 받게 되는 경우에는 리더십 위원회 FCP를 통해 이 수정 조건을 조정할 수 있습니다.