Rust 기여자와 유지관리자들이 AI 도구 사용에 대해 제시한 다양한 관점과 쟁점을 모아 요약하고, 코딩·비코딩 활용, 윤리·법적 문제, 오픈 소스에 미치는 영향, 그리고 가능한 대응 방향을 정리한다.
← 또는 → 를 눌러 장 사이를 이동
S 또는 / 를 눌러 책에서 검색
? 를 눌러 이 도움말 표시
Esc 를 눌러 이 도움말 숨기기
1. [AI는 잘 다루는 법을 배워야 하는 도구다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-is-a-tool-that-one-must-learn-to-wield-well)
2. [많은 사람들은 코딩이 아닌 작업에서 AI의 가치를 찾는다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#many-people-find-value-in-ai-for-non-coding-tasks)
1. [검색과 탐색](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#searching-and-discovery)
2. [코드 검토와 아이디어 탐색](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#reviewing-code-and-exploring-ideas)
3. [반구조화 데이터의 대규모 처리](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#large-scale-processing-of-semi-structured-data)
3. [하지만 AI로 글을 잘 쓰는 것은 까다롭다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#writing-with-ai-however-is-tricky-to-do-well)
4. [AI로 코딩하는 것에 대한 의견은… 제각각이다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#opinions-on-coding-with-ai-are-varied)
1. [AI는 제약이 분명한 작업에 강하다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-is-good-for-well-constrained-tasks)
2. [AI에 의존하면 코드와의 연결이 약해질 수 있다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#leaning-on-ai-can-cause-one-to-lose-ones-connection-to-the-code)
3. [AI가 생성한 코드는 신중한 검토가 필요하며, 이를 잘하기는 어렵다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-generated-code-needs-careful-reviewing-and-that-is-hard-to-do-well)
4. [AI는 전문가의 속도를 높일 수 있지만, 초보자가 전문가가 되기는 더 어려워질 수 있다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-can-help-experts-move-faster-but-can-make-it-harder-for-new-folk-to-become-experts)
5. [AI 사용의 윤리](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#the-ethics-of-ai-usage)
1. [AI 데이터는 인터넷 전반에서 스크레이핑되었다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-data-was-scraped-from-the-internet-at-large)
2. [AI는 접근 비용이 비쌀 수 있으며 권력을 집중시킬 수 있다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-can-be-expensive-to-access-and-can-concentrate-power)
3. [AI는 편향을 전파하고, 그것을 만들어낸 사회의 병폐를 강화할 수 있다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-can-propagate-bias-and-reinforce-the-ills-of-the-society-that-produced-it)
4. [AI는 전력을 많이 소비한다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ais-consume-a-lot-of-power)
6. [AI 사용의 합법성](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#the-legality-of-ai-usage)
7. [AI와 오픈 소스](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#ai-and-open-source)
1. [기여자가 리뷰어 코멘트를 LLM에 그대로 중계하는 것은 좌절감을 준다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#contributors-proxying-reviewer-comments-to-llm-is-frustrating)
2. [저품질 PR이 수와 빈도 모두 증가하고 있다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#poor-quality-prs-are-increasing-in-both-number-and-frequency)
3. [코드베이스는 코드 그 이상이다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#codebases-are-more-than-code)
4. [신뢰의 침식과 노력을 감지할 수 없음](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#erosion-of-trust-and-inability-to-detect-effort)
5. [LLM이 생성한 버그 리포트를 분류하는 일은 어렵다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#triaging-llm-generated-bug-reports-is-difficult)
6. [기여자와의 논의가 적대적으로 변할 수 있다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#discussions-with-contributors-can-become-hostile)
7. [격앙된 분위기가 대화를 어렵게 만들고 있다](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#the-charged-atmosphere-is-making-conversation-difficult)
8. [그렇다면 이 모든 것에 대해 우리는 무엇을 해야 할까?](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#so-what-should-we-do-about-all-this)
1. [보편 정책](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#universal-policy)
2. [공개와 책임](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#disclosure-and-accountability)
3. [영어가 편하지 않다면 모국어로 쓰도록 장려하기](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#encourage-people-to-write-in-their-native-language-if-they-are-not-comfortable-with-english)
4. [AI 기업이 Rust 유지보수에 투자하도록 장려하기](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#encourage-ai-companies-to-invest-in-rust-maintenance)
5. [기여자와 유지관리자를 위한 AI 도구 사용권 후원](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#sponsored-access-to-ai-tooling-for-contributors-and-maintainers)
6. [평판 프로그램](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#reputation-programs)
7. [불에는 불로 맞서기](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#fight-fire-with-fire)
9. [메타 관찰과 마무리 생각](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#meta-observations-and-closing-thoughts)
1. [공통 기반](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#common-ground)
2. [핵심 긴장](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#core-tensions)[](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html)
1. [깊은 통합 vs 도덕적 이유로 거부](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#deep-integration-vs-rejection-on-moral-grounds)
2. [AI를 “지원”하는 것 vs AI를 “지지”하는 것](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#supporting-ai-vs-endorsing-ai)
3. [“AI에서 빠져나오기” vs “AI가 도움이 될 수 있다”](https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html#opting-out-from-ai-vs-ai-can-help)
3. 3. 모든 코멘트
2월 6일부터 프로젝트는 공유 문서에 AI에 대한 관점을 수집하기 시작했다. 이 문서는 그 코멘트들을 요약한 것으로, 2월 27일 즈음 nikomatsakis가 작성했다.
이 문서의 목표는 양측에서 제기된 주장과 논거의 종류를 포함해, 언급된 논점의 전체 범위를 다루어 의견 지형을 이해하는 것이다. 대체로 나는 요약을 최소화하고 사람들의 인용문이 스스로 말하게 두려고 했다. 원문 코멘트를 읽고 싶다면 여기에서 찾을 수 있다.
이 요약을 성격 규정할 때는 주의하자. 여기의 코멘트들은 “Rust 프로젝트의 견해”를 나타내는 것이 아니라, 각 코멘트를 남긴 개인들의 견해를 나타낸다. Rust 프로젝트는 현재 AI 도구 사용에 관해 일관된 견해나 입장을 갖고 있지 않으며, 이 문서는 그 입장을 형성하기 위한 한 걸음이다.
또한 이 논의는 “rust-lang 크레이트에서의 AI 사용”과 “다른 곳에서 Rust 개발자가 AI를 사용하는 것”으로 명확히 나뉘어 있지 않다. 많은 인용문이 둘 중 하나 또는 둘 다를 전제로 하므로, 해석할 때 주의가 필요하다.
AI에서 가장 좋은 결과를 얻는 사람들은 거기에 도달하려면 진짜 엔지니어링이 필요하다고 말한다. “AI가 잘 된다/안 된다”의 문제가 아니라, AI가 잘 되도록 만드는 문제다:
좋은 결과를 내기 위해서는 주의와 세심한 엔지니어링이 필요하다. 모델이 비행 가능 영역(flight envelope) 안에 머물도록 노력해야 한다. 문제를 신중히 구조화하고, 올바른 맥락과 가이드를 제공하며, 적절한 도구와 좋은 환경을 제공해야 한다. 컨텍스트 윈도우를 최적화하는 것도 생각해야 하고, 그 한계를 인지해야 한다.
– TC
게다가 모델은 계속 개선되고 있다:
눈에 띄지 않을 수도 있지만 지난 2-3개월 동안 얼마나 많은 것이 바뀌었는지다. 한때는 진지한 작업에 모델을 쓰는 것을 정당화하기가 어려웠다. 하지만 최첨단 모델은 이제 무시하기엔 너무 좋다.
– TC
이는 사람들이 AI에 대해 서로 매우 다른 경험을 하는 이유를 설명해 준다:
나는 내가 깊이 존경하는 사람들이 이런 도구에서 가치를 찾는 것을 보면서도, 동시에 사람들이 주장하는 가치의 99%가 실체 없는 연기라고 느끼는 인지 부조화를 겪고 있었다. 그리고 니코 같은 사람에게도 그게 맞는지 궁금했다. 하지만 Jayan의 관점에서 보면 입력과 이 도구들을 사용하는 방식이 여전히 영향을 줄 수 있고, 그래서 니코 같은 사람이 엔지니어링 배경 없이 무작정 도구를 쓰는 사람들보다 더 나은 결과를 낼 수 있다는 점을 이해할 수 있다.
– yaahc
AI 논의의 상당 부분은 코딩에 집중되어 있는데, 이는 많은(하지만 전부는 아닌) 사람들이 다른 종류의 작업에서도 AI를 성공적으로 사용하고 있다는 사실을 가린다.
AI는 낯선 코드베이스나 문서를 탐색할 때 도움이 될 수 있다:
나는 조사/리서치 같은 것에 가치가 있다고 느낀다. Arm에는 내부 AI 도구가 있는데, 10,000페이지가 넘는 아키텍처 문서를 검색하기가 훨씬 쉬워진다. 나는 그게 매우 가치 있다고 느낀다. 덕분에 업스트림 이슈에 더 신속하게 대응하기가 훨씬 쉬워졌다.
AI는 조사 같은 것에 종종 훌륭하다. 예를 들어, “지금 여기 있는데
Span이 필요하다; 어디서 얻지?” 같은 질문에서 큰 성공을 거뒀다.– scottmcm
또 다른 관련 주제는 AI를 “러버덕(rubberduck)”이나 “브레인스토밍”에 쓰거나, 대화형으로 아이디어를 탐색하는 것이다:
내가 한 일을 재확인하는 데 쓰거나, 질문을 하도록 만들어봤는데, 그 질문이 – 멍청하긴 해도 – 내가 올바른 아이디어를 탐색하게 만들었다.
AI는 코드 리뷰에도 매우 유용할 수 있다:
[AI에 대한 내 유보에도 불구하고,] 나는 코드 리뷰에 LLM을 탐색해 보고 싶다. 리눅스 커널 쪽 사람들 중 일부는 LLM 에이전트가 리뷰를 돕도록, 프로젝트에 매우 특화된 신중하게 만든 프롬프트를 사용해 좋은 성과를 냈다고 한다. 물론 이것이 인간 코드 리뷰와 승인을 대체할 수는 없지만, 잘 하면 리뷰어의 효율을 높이는 데 도움이 될 수 있다. 시도해 볼 만해 보인다. 다만 프로젝트 운영을 위해 LLM에 건강하지 않은 의존이 생기지 않도록 조심해야 한다. 오픈 웨이트 모델 중 일부가 대형 독점 모델에 꽤 근접하고 있다는 얘기도 들었다. 그런 모델을 자체 호스팅하면 앞서 언급한 우려를 일부 완화할 수도 있다.
– RalfJung
특히 반구조화 데이터와 함께 작업할 때, AI는 도저히 하기 힘든 일을 훨씬 쉽게 달성하도록 만들 수 있다. 문서에는 여러 예가 있었고, 여기에는 FLS의 한 예가 있다:
FLS의 오래된 문제 중 하나는 용어집과 장의 본문 내용이 별도로 유지관리된다는 점이다. 이로 인해 용어집의 정의와 (본질적으로 여전히 정의인) 용어 사용이 미묘하게 달라지는 유지관리 실수가 발생하고, 그 결과 FLS에 버그가 생긴다. 지시 형식이 확정되고 나자, 에이전트는 조금씩 조금씩 모든 용어집을 장들로 옮겨 단일한 진실의 원천(single source of truth)을 만들었고, 그로부터 용어집을 한 번에 생성할 수 있게 했다. 개인적으로 말하자면, 이런 일은 너무 지루한 작업이라 우리가 아마도 손대지 못했을 것 같은 종류의 일이다. 아직 머지되지는 않았고, 리뷰가 더 쉬운 단계적 방식으로 들어올 수 있게 재작업 중이다.
AI가 비코딩 작업에 도움이 될 수는 있지만, 모든 영역에서 똑같이 잘 동작하는 것은 아니다. 특히 AI 글쓰기는 말은 많은데 정보나 구조가 부족하다는 언급이 많았다:
[AI가 생성한 프로젝트를 설명하며:] 문서는 문장 수준에서는 매우 좋았고, 문단 수준에서는 좋았지만, 그보다 큰 수준에서는 끔찍했다. 구조가 나쁘고, 반복적이며, 순서나 흐름에 대한 감각이 없었다. 그저 관련 있는 것들의 무작위 모음처럼 느껴졌다. 이 프로젝트에는 README 파일이 많이 있었는데, 그것들을 가로질러 보면 문제는 더 심했다. 중복된 정보가 엄청나게 많았다.
코딩에서 AI를 사용하는 경험은 정말 제각각이다. 어떤 사람들은 효과적이지 않다고 느꼈다:
내가 원하는 코드를 만들도록 AI 도구를 몰아붙이고, 그 뒤에 리뷰와 수정까지 하는 데 드는 시간이, 그냥 내가 직접 코드를 쓰는 것보다 더 많이 든다.
새 기능을 구현할 때는, 내가 직접 구현하는 것보다 실제 소요 시간(wall time) 면에서 더 느리다고 느낀다.
하지만 많은 가치를 느낀 사람들도 있다:
내가 AI를 쓰는 느낌을 한 단어로 고르라면 권한 부여됨(empowered) 이다. 이 느낌이야말로, 결함이 많음에도(정말 많다) AI가 앞으로도 남아 있을 것이라고 나를 설득한다.
갑자기 거의 어떤 문제든 떠맡을 수 있을 것처럼 느껴진다 – AI가 일을 대신 해준다는 뜻이 아니다. AI가 내가 그 문제를 통과해 작업하도록 도와주고, 귀찮은 일도 일부 맡아준다는 뜻이다. 그리고 확실히 어떤 영역(github actions, HTML/CSS)은 예전에는 나를 완전히 멈춰 세웠겠지만, 이제는 문제가 아니다 – 그런 것들을 만들어 실제로 동작하게 할 수 있다.
나는 2025년 중반쯤부터 LLM 에이전트를 써 왔고, 기능 개발, 버그 수정, 데이터 분석에서 진짜로 유용했다. 기본적으로 도구(화려한 자동완성)처럼 다루고, PR을 올리기 전에 항상 결과물을 리뷰하고 다듬는다.
– Turbo87
코딩에는 대체로 AI를 쓰지 않는 몇몇 사람들도, 특정한 종류의 작업에는 도움이 될 수 있다고 언급했다:
나는 에이전트(Claude Code)를 지루하거나 짜증나는 것(리팩터링, 보일러플레이트, REST API 호출 생성 등)을 자동화하거나, 복잡한 코드베이스를 이해하고 X를 어떻게 할지에 대한 제안을 얻는 데 쓴다.
– kobzol
코드 작성자 관점에서, 나는 proc macro 코드를 쓸 때 LLM이 좋았다. 그건 재미도 없고 정확성에 아주 민감한 것도 아니라서. 요즘은 Rust 코드를 꽤 잘 쓰게 됐다.
많은 코멘트는 AI 코딩 도구 사용이 코딩 스킬을 “퇴화”시키거나 약화시키는 느낌이 들며, 코드가 어떻게 동작하는지에 대한 감각을 잃게 만든다고 언급했다:
내가 직접 쓰지 않은 코드에 대해서는 “깊은 인상”을 유지하거나 코드베이스의 멘탈 모델을 개발하는 것이 정말 어렵다.
Peter Naur가 쓴 “Programming as Theory Building”라는 에세이를 나는 매우 좋아한다. 이 글은 프로그램이 단지 소스 코드로만 존재하는 것이 아니라 프로그래머의 뇌 속 멘탈 모델로도 존재하며, 그 멘탈 모델이 소스 코드만큼 중요하거나 더 중요하다고 주장한다. 이것이 프로그래머들이 대체 가능하지 않은 이유다. 좋은 멘탈 모델을 가진 프로그래머는 프로그램을 효과적으로 수정할 수 있지만, 나쁜 멘탈 모델을 가진 사람은 그러지 못한다. 원 개발자가 떠난 소스 코드는 열화된 상태이며, 누군가가 인수하면 자신의 멘탈 모델을 새로 쌓아야 하는데, 그 모델은 원 저자의 것과 다를 수도 있다. 이런 멘탈 모델을 구축하고 유지하는 것은 어려운 일이고, 프로그래밍의 엄청난 부분을 차지한다. 그렇다면 그 모든 것을 LLM에 외주 준다는 것은 무슨 의미인가? 나는 좋은 결과가 나올 것이라 보기 어렵다.
리뷰를 더 강하게 해서 품질을 보장하는 것은 어려울 것이다. 특히 미묘하게 틀린 경우가 많아서 검토가 어렵기 때문이다:
나는 “인간이 결과 코드를 철저히 리뷰한다”가 통하지 않는다고 생각한다. search graph 작업 중 VSCode의 인라인 스니펫으로 실험해 보니, 틀렸지만 그럴듯해 보이는 코멘트를 제안했다. 나는 그것들이 틀렸다는 것을 깨닫지 못한 채 일부를 쓰기까지 했다. LLM이 철저한 리뷰가 불필요할 정도로 충분히 좋아지거나(또는 문제가 충분히 단순해져서), 그런 수준이 되지 않는 한, 나는 LLM을 이용한 코드 생성이나 대화 참여를 지지하고 싶지 않다.
– lcnr
어떤 코멘터들은 AI가 리뷰의 난이도뿐 아니라 리뷰의 목적 자체를 바꾼다고 느꼈다:
코드 리뷰는 세부 자잘한 것(minutia)을 잡아내는 데 적합하지 않고, 대신 일반적으로 버스 팩터를 줄이기 위해 다른 사람들이 변경 사항을 따라가도록 하고, 문화와 모범 사례를 공유하고, [그리고] 더 많은 눈으로 사각지대의 영향을 제한하는 데 초점이 맞춰져 있다 — 하지만 AI가 필요로 하는 것은 자잘한 것 검토이고, AI를 쓰는 기여자는 더 이상 “저자”가 아니라 “리뷰어”가 된다. 게다가 평소 리뷰도 많은 사람에게 활력을 주기보다는 소진시키는 활동일 수 있는데, 이를 자잘한 것 검토로 전환하면 참여 이탈, 맹목적 승인(LGTM), 또는 번아웃으로 이어질 것이다.
– epage
여러 코멘터가 AI가 학습과 교육에 미치는 영향에 대한 우려를 제기했다. 새로 온 사람들이 너무 이르게 AI에 과도하게 의존하면, 유능한 기여자가 되게 해줄 깊은 이해를 결코 쌓지 못할 수도 있다:
즉, LLM은 전문가의 손에 들리면 훌륭한 도구가 될 수 있지만, 너무 이르게 너무 많이 사용하면 사람이 전문가가 되는 것 자체를 방해할 수 있다.
– RalfJung
또 다른 사람들은 이 우려가 타당함을 시사하는 연구를 언급했다:
과학은 반복해서, 시간 투입 면에서 순손실이거나 학습 능력이 저해된다는 것을 보여준다. 그러는 동안 참가자들은 자신이 더 빨랐거나 각각 잘 배웠다고 믿는다.
– oli-obk
선택 구조(choice architecture) 관점에서 보면, AI 사용을 허용/촉진하는 것은 저노력·저참여를 가장 편리한 경로로 만들 위험이 있다:
선택 구조 관점에서 본다면, AI 사용을 허용하거나 가능하게 하는 것은 저노력 & 저참여를 가장 편리하게 만들 위험이 있다. 이는 교육과 전문 환경에서 우리가 일관되게 보는 주제다: 어떤 작업이 흥미롭지 않으면, AI가 하게 함으로써 그것을 “고친다”.
많은 코멘트는 AI의 도덕적·윤리적 차원에 관한 것이었다. 많은 사람에게 LLM 학습 데이터의 출처는 근본적인 우려다 — 법적 문제일 뿐 아니라 도덕적 문제이기도 하다:
LLM은 훔친 데이터로 학습된다. LLM을 학습하는 데 필요한 데이터 양을 고려하면, 현재 모델에 견줄 만한 것을 라이선스된 데이터로 학습시키는 것은 불가능할 것처럼 보인다.
다른 이들은 AI 접근이 비싸고, 그 결과 개발자들 사이에 고르게 퍼지지 않는다는 점을 들었다:
이것은 또한 새로운 형태의 폐쇄형 정원(closed gardens)이다. 이용 가능한 최고의 LLM은 소수 기업이 소유하고 있고, 그들은 무료 “체험”을 줄이는 동시에 가격을 계속 올리고 있으며, 그로 인해 감당할 수 있는 사람들과 그렇지 못한 사람들 사이의 격차가 더 커진다.
또한 모델이 소수 기업에 권력을 집중시키고, 조작 가능성을 낳는다는 점도 있다:
더 나아가, 이런 모델을 만드는 데 드는 비용 때문에 이를 제공하는 기업은 소수뿐이며, 사람들의 프로그래밍 행동에 대한 막대한 권력과 통제가 소수의 손에 집중된다. 이것들은 중앙집중적이고 독점적인 서비스로, 공급자가 누가 언제 어디서 무엇을 하기 위해 사용하는지를 완전히 통제한다 – 이는 FOSS, 즉 개인을 권한 부여하는 것과 정반대다. 이 모든 것은 우리가 LLM과 그것이 현재 구축되는 방식에 대해 지지하는 인상을 주는 것을 매우 조심해야 함을 의미한다.
– RalfJung
여러 사람이 사회의 다른 영역에서 AI가 갖는 부정적 효과를 언급했다:
많은 회사가 이력서 스캐닝 도구를 사용해 특정 직무에서의 역량을 추정하려고 하는데, 나는 그중 최소 하나가 최근 연구에서 우리가 발견한 전형적인 LLM 함정을 그대로 따라가고 있음을 확인했다: 이름처럼 무관한 파라미터에 매우 민감하며(참 편리하게도, 이름은 차별하기에 아주 좋은 수단이다!), 참고 자료에 대한 실질적 이해를 보여주는 것 같지도 않다.
– Clar Fon
많은 코멘터가 AI 전력 사용과, 그것이 기후변화 완화/중단 노력에 미친 영향에 대한 우려를 제기했다:
에너지 수요는 대기 중 온실가스 배출을 줄이기는커녕 늘린다. 폐쇄 예정이던 석탄 발전소가 계속 가동되고 있다. 대형 기술 기업들이 탈탄소화 약속을 되돌리고 있다. 이것은 절대 정당화될 수 없다.
말 그대로 범위는 화석연료 사용을 현재 수준으로 유지하는 것을 넘는다. 아직 시추조차 하지 않은 곳에서 석유를 캐기 위해 전쟁을 시작할 정도로 화석연료 사용을 확대하고 있다. [이는 기후변화 완화 노력을 약화시키는 것뿐 아니라] 오히려 기후변화를 적극적으로 가속하려는 욕망이다.
– Clar Fon
도덕적·윤리적 우려와는 별개로, AI를 둘러싼 법적 환경은 복잡하며 빠르게 변하고 있다. 미국에서는 AI 학습에 대한 공정 이용(fair use)의 한계를 판정하려는 여러 관련 소송이 법원을 통과하고 있다. 출판사와 AI 제조사 사이의 합의도 여럿 있었는데, 그중 상당수는 비공개다. EU의 AI Act는 학습 데이터 출처에 대한 투명성 요구를 부과하기 시작하고 있다.
또한 AI가 생성한 출력물 에 대한 저작권 문제도 있다. 라이선스 조건을 주장할 수 있어야 하는 오픈 소스 프로젝트에게 이는 중요한 미해결 위험이다:
해결되지 않은 저작권 이슈, 그리고 해결책이 보이지 않는다. 현재의 생각은 선의(good faith)를 가정 하고 최선을 기대하는 것이다. FOSS 프로젝트에겐 이는 거대한 다모클레스의 검이다.
– apiraino
나는 변호사는 아니지만, 지금까지 배운 바로는 OSS 프로젝트가 AI 기여를 더 받아들일수록 라이선스 조건(예: 저작자 표시)을 주장하지 못할 위험이 커진다. 결국 사람이 전달했다는 것을 증명할 수 없는 모든 기여가 잠재적 문제가 된다.
여러 사람은 에이전트가 “그럴듯해 보이는”(하지만 틀린) PR을 만들기 너무 쉽게 해주고, 환각 성향이 기여자에게 인위적 자신감을 부여해 코드베이스를 실제보다 훨씬 더 이해하고 있다고 착각하게 만든다고 말했다:
공식적인 “승인 도장”은, 이전에는 LLM 쓰레기를 기여물로 내놓지 않았을 사람들이 죄책감을 덜 느끼며 그렇게 하게 만드는 데 필요한 마지막 추진력이 될 때가 많다. 물론 이것이 모든 사람을 대표하는 것은 아니지만, (다소) 성장하는 다수의 사람들을 대표한다. 이 개발자 하위 집단은 LLM을 사용하는 또 다른 부류, 즉 더닝-크루거 효과를 특히 잘 드러내는 사람들과 크게 겹친다. 이 사용자들에게 AI는 더닝-크루거 효과에 대한 스테로이드 같은 것이다. 자신감을 올리지만, 사용자의 역량에는 영향을 준다. 이는 LLM을 쓰면 무능해진다는 말이 아니다; 경험 많은 많은 개발자들이 LLM을 활용해 워크플로를 개선하고 있다. 문제는 LLM 자체가 아니라, 그것을 사용하는 방식에서 온다.
특정한 지적 하나는, 기여자가 자신의 지식으로 답하는 대신 리뷰 코멘트를 그냥 LLM에 전달해 버리는 경우가 있다는 점이었다:
- 몇몇 기여자는 심지어 리뷰어와 LLM 사이에서 프록시처럼 행동하면서, 리뷰어의 질문을 복사해 넣고 LLM이 생성한 답변으로 되돌려준다. 제발 좀.
이게 믿을 수 없을 만큼 좌절스럽다는 걸 강조하고 싶다. 이것은 내게 번아웃이 올 수 있는 가장 큰 요인이다.
가장 눈에 띄는 문제는 저품질 PR이 많고, 그것을 감지하기 어렵다는 점이다:
- “그래, 그럴듯한 걸 빠르게 만들었지만 사실 미묘하게 틀렸고 이제 모두의 시간을 낭비하고 있다” 문제를 어떻게 해결해야 할지 모르겠다. 우리는 실제로는 해결하지 못하는 것들을 “고치려는” PR을 너무 많이 받는데, 그 대부분이 AI에서 나온 것 같고 AI가 없었다면 존재하지 않았을 것이다.
다른 말로 하면, 나는 여전히 프로젝트에 대한 가장 큰 위협이 리뷰 대역폭 부족이라고 생각하며, LLM은 현실적인 개선 가능성 없이 그 상황을 더 악화시키고 있을 뿐이다. (만약 LLM이 진짜 문제를 감지할 수 있다면 애초에 그런 PR을 피할 수 있었을 것이다.)
– scottmcm
품질을 넘어, AI가 생성한 기여의 순수 물량 자체도 가속되고 있다:
특히 최근 OpenClaw, MCP 같은 것들이 등장하면서, 완전히 AI가 생성한 쓰레기들의 순수 물량이 리뷰/모더레이션 역량에 진짜 부담이 되고 있다.
몇몇 코멘터는 AI가 생성한 기여의 문제가 코드 품질보다 더 깊다고 지적했다:
이걸 쓴 뒤에 이 기괴한 사건이 발생했고, 나는 더 생각하게 됐다. 나는 “코더가 아니라 코드를 평가하라”가 앞으로 우리가 자주 듣게 될 주장이라고 생각한다. 그리고 내가 그게 나쁜 주장이라고 생각하는 이유는 여러 가지가 있다.
- 오픈 소스 프로젝트는 단지 코드베이스만이 아니다.
- 그 주변에는 사람들의 커뮤니티가 있다.
- 그 사람들은 프로젝트에 대한 공동의 헌신을 공유한다
- 그 사람들은 프로그램이 무엇을 하고 왜 그런지에 대한 공동의 이해를 공유한다. (이는 위에서 언급한 Naur 에세이와 연결된다.)
- 스쳐 지나가는 LLM 기여는 이런 비코드 측면에 기여하지 않는다. 기술적으로 유효한 기여라 해도, 오히려 그것들을 약화시키기도 한다.
예를 들어, E-Easy 이슈를 LLM이 고치는 것은 인간의 학습 기회를 빼앗는다.
우리가 컴파일러+도구라는 코드 산출물 너머로 함께 구축하는 것은, 다시 돌아오고, 배우고, 이해를 공유하고, 취향을 맞추고, 커뮤니티의 입력을 받아들이는 사람들의 집단이다 등등. LLM이 생성한 PR을 머지하는 것은 프로젝트의 “동작하는 코드가 있다” 부분만을 먹여 살릴 뿐이고, 프로젝트를 살아 있게 만드는 다른 모든 피드백 사이클에 참여하는 것은 아니다.
AI가 작성한 기여는 과거에 존재했던 암묵적 계약을 깨뜨린다. 과거에는 기여자가 “그럴듯해 보이는” PR을 준비하려면 대개 상당한 노력을 투자해야 했다. 그 결과 기여자와 유지관리자/리뷰어 사이의 신뢰가 침식된다:
내 주요 우려는 LLM이 우리가 현재 노력을 감지하는 거의 모든 방법을 깨뜨린다는 것이다. 이로 인해 우리는 리뷰와 멘토링 역량을 잘못 배분하게 된다.
– lcnr
AI 기여 논의의 상당 부분은 코드에 집중해 왔지만, AI는 오픈 소스 프로세스에 다른 방식으로도 영향을 준다. AI가 생성한 이슈 설명과 글쓰기는 특히 많은 사람이 좌절감을 느끼는 영역이다:
나는 버그 리포트에는 어떤 종류의 AI 보조 도구든 전면 금지를 솔직히 제안한다. 문법 실수, 어색한 영어, 심지어 리포터가 모국어를 쓰는 것조차 나는 신경 쓰지 않는다. 그건 다 다루기 쉽다. 하지만 나는 LLM 쓰레기 스타일의 버그 리포트를 정말 혐오한다 – 텍스트는 잔뜩 있는데 재현에 실제로 필요한 정보는 어떻게든 들어있지 않다. 더 나쁜 건, 이 리포터들 중 일부는 완전히 쓸모없거나 틀린 분석을 포함시키고, 분류(triage)하는 유지관리자는 그 안에 뭔가 진짜가 있을지 몰라 시간을 낭비하며 들여다봐야 한다. 분류도 유지관리자의 시간을 쓴다. 제발 이 점을 과소평가하지 말라.
– Jieyou Xu (강조는 원문)
그리고 어떤 사람들은 AI를 사용하는 코멘터가 그것에 대해 질문받으면 빠르게 적대적으로 변할 수 있다고 언급했다:
나는 이와 관련해 다른 생각도 있지만, 즉각 떠오르는 것은 내가 최근에 만난 이슈 리포터 중 LLM을 노골적으로 사용한 사람이 꽤 적대적이었다는 것이다(참고: rust#151868). 나는 그 리포터에게 이슈 리포트에 핵심 재현 정보가 빠졌다고 말했다. 그 리포트는 우리가 직접 지원하지 않는 도구(
bazel)를 참조했을 뿐 아니라, 그 도구들이 요구하는 기본 입력이나 그것을 어떻게 얻었는지에 대한 설명도 생략했다(분명bazel build겠지만, 어떤MODULE.bazel로?). 대신 컴파일러 빌드 출력에 대한 LLM 생성 “분석”을 포함했는데, 너무 “요약”되어 있어서 무엇을 설명하려 했는지 거꾸로 추적하는 것이 불가능했다. 게다가 그 리포트는 명확한 이유도 없이 이슈와 전혀 무관한 사람들을 핑(ping)하기도 했다.[..]
이것은 특별히 유일한 일이 아니다. LLM 주도의 이슈와 풀 리퀘스트는 종종 코드든 에러 리포트든, 그 정보를 어떻게 얻었는지에 대한 방어심에 의해 뒷받침된다. 간단한 답이 있어야 할 단순한 질문들이 너무 완전히 회피되어서, 되레 심문 같은 대응이 필요해진다. 초기 리포트가 충분한 근거를 제공해 반박이 명백한 경우에도, 사실관계를 끝까지 캐묻는 일은 지친다.
– Jubilee Young (강조는 글쓴이)
AI를 둘러싼 감정의 강도 때문에, 개방적이고 생산적인 대화를 나누기 어렵다. 한쪽에서는 AI를 받아들이면 일부 기여자와 사용자를 소외시키게 된다:
AI를 받아들이는 데에는 기존 및 잠재 기여자를 잃는 비용이 있을 것이다. 모더레이터로서, AI 사용과 확산이 초래한 엄청난 해악을 고려하면 AI 긍정적 프레이밍을 CoC 위반으로 왜 막지 않느냐는 질문을 받기도 했다. 나는 프로젝트가 AI에 올인했을 때의 부정적 사례 보고는 많이 보지만, AI를 전면 거부한 게시물에 대해서는 많아야 일부 칭찬 정도만 본다. “AI 거부” 게시물의 댓글 깊숙한 곳에서도, 그것 때문에 [사람들이] [기여를] 중단한다는 이야기는 보지 못한다.
반대로, 이 주제의 열기 때문에 사람들이 실제로 AI를 어떻게 사용하는지에 대한 전체 그림을 못 보고 있을 수도 있다. 어떤 사람들은 자신의 경험을 공개적으로 말하기를 꺼린다:
우리가 스스로를 어떻게 제시하느냐는 사람들이 우리에게 무엇을 말해줄지에 영향을 주며, 우리는 그에 대한 책임이 어느 정도 있다. 나는 Zulip에서 AI 사용에 대해 공개적으로 말하기를 꺼린다는 메시지를 여러 사람에게서 받았다.
나는 AI에 가치가 있다고 본다, 당연히. 하지만 내가 더 중요하게 생각하는 것은 Rust가, 특히 이전에는 그런 일을 할 수 없다고 느꼈던 사람들이 기반 소프트웨어를 만드는 데 성공하도록 돕는 데 초점을 맞춘 장소가 되는 것이다.
상황을 더 복잡하게 만드는 것은, 어떤 사람들은 직장에서의 하향식 압력 때문에 AI에 대해 부정적으로 말하기를 꺼린다고 사적으로 연락해 왔다는 점이다.
이 모든 정보를 고려할 때, Rust 프로젝트의 올바른 행동 방침은 무엇일까? “쓰레기 PR(sloppy PR)” 문제와, 저품질 AI 생성 기여가 유지관리자에게 부과하는 부담이 커지고 있다는 점에 대해서는 뭔가를 해야 한다는 것이 분명하다.
어떤 프로젝트들은 PR 준비 시 AI 사용을 금지하기로 했고, 문서에도 이 접근을 옹호하는 이들이 있다. 다른 이들은 그런 금지는 집행하기 어렵고, 사람들이 AI 사용을 멈추게 하지도 못하며, 심지어 Rust와 함께 AI를 쓰는 것을 막지도 못할 것이라고 지적한다. 여기에는 AI에 강하게 반대 의견을 표한 사람들도 포함된다:
일반적으로 Rust 프로젝트가 AI의 전 세계적 상태에 대해 할 수 있는 일은 사실상 없다. 이미 고양이는 자루 밖으로 나왔고, 거품이 꺼지고 업계 전체가 AI가 지속 가능하지 않다는 것을 발견하지 않는 한 되돌아가지 않을 것이다. 여기서 여러 사람은 윤리적 이유로 AI에 강하게 반대하는 의견을 표현했다. 그것들은 모두 타당하다. 하지만 불가피성이라는 이유로, 우리는 머리를 모래에 파묻고 그냥 사라지길 바라서는 안 된다. 그래서 프로젝트의 모든 수준에서 AI에 대해 생각하고 이야기하는 것이 필요하다고 본다.
전면 금지까지는 아니더라도, 리뷰어의 부담을 줄이고 AI를 쓴다면 책임 있게 쓰도록 보장하는 데 도움이 될 수 있는 여러 단계를 사람들이 제안했다.
컴파일러 팀은 이미 리뷰에 관한 확립된 정책을 갖고 있는데, 이는 “착취적(extractive)”으로 보이는 PR을 리뷰어가 빠르게 거절하기 쉽게 하는 것을 목표로 한다. 우리는 이 정책을 다시 검토하고, (일부 수정과 논의 후) 더 널리 알려지고 보편적으로 적용되게 만들 수 있다.
나는 이런 AI 기여 정책이 다음을 포함하길 제안한다:
기여자는 자신의 기여에 대해 책임을 지고 책임을 물을 수 있어야 한다. AI 생성 콘텐츠를 스스로 검토하지 않은 채 제출하는 것은 절대 용납할 수 없다.
기여자는 자신이 기여한 변경을 이해해야 한다. 리뷰어가 변경에 대해 질문하면 답할 수 있어야 한다.
기여의 상당 부분이 AI가 생성한 것이라면 기여자는 이를 책임 있게 공개해야 한다.
리뷰어는 주로 AI가 생성한 기여(제안 및 코멘트 포함)에 대해 리뷰/상호작용을 거절할 권한이 있다.
쓰레기를 제출하면 즉시 밴.
리뷰어/유지관리자의 질문을 LLM에 넣고 LLM의 답을 그대로 게시하면 즉시 밴.
여러 코멘터가 공개를 요구하고, 기여자가 자신의 책임을 인지하도록 만드는 것을 언급했다.
그래서, 첫 단계로, PR 준비 과정의 일부로 기여자에게 자신이 PR 전체(PR 설명 포함)를 직접 작성했거나 직접 검토했으며, 그 내용에 대해 스스로 질문에 답할 수 있음을 명시적으로 확인하게 해야 한다고 생각한다. 또한 좋은 PR 설명을 쓰는 방법에 대한 가이드를 제공할 수도 있다(LLM이 정보 밀도가 낮은 매우 장황한 설명을 쓰는 효과를 상쇄하기 위해). 물론 사람들은 거짓말할 수 있지만, 많은 사람은 그저 돕고 싶어 할 뿐이고, 나머지의 경우에도 이는 명확한 선을 그어준다.
– RalfJung
목표는 리뷰어가 “간접적으로” LLM과 일하게 되는 현상을 다루는 것이다:
이해하거나 검토하지도 않은 LLM 출력물을 PR에 그대로 넣는 사람들과 상호작용하는 것, 또는 “LLM 프록시”를 통해 나와 소통하는 것은 믿을 수 없을 만큼 짜증난다.
– kobzol
글쓰기와 의사소통에서의 AI 사용은 특히 큰 좌절 요인이었다. 하지만 영어를 못 하는 사람들이 프로젝트와 소통할 수 있게 하는 유효한 사용 사례는 여전히 존재한다. 한 가지 방법은 사람들이 원하면 모국어로 쓸 수 있음을 명확히 하고, 프로젝트가 우리 쪽에서 번역을 사용하거나 해당 언어를 하는 사람을 찾아 도움을 받는 것이다:
솔직히 리포터가 영어가 아닌 모국어로 쓰는 편이 더 낫다. 적어도 그것 은 리포터의 실제 감정을 반영하고, 번역을 교차 비교할 수 있다(즉 “원문”에 접근할 수 있다). 특히 예를 들어 중국어(만다린)는 유지관리자 중에 실제로 유창한 사람이 있을 수도 있다! 반면 누군가가 LLM이 번역한 내용을 그냥 붙여 넣으면, 원래 버전이 무엇이었는지 누가 알겠는가?
기적처럼 모든 것을 해결해주진 않겠지만, 자원봉사 리뷰어의 업무량을 늘리는 제품을 높은 기업가치의 회사들이 만들고 있다는 사실은 지속 가능하지 않다. 유료 유지관리자 펀드 같은 새로운 기회를 추구하면서, AI 기업으로부터 직접 지원을 받을 수도 있다:
더 나아가, 프로젝트로서 AI 기업(내가 이해하기로는 Rust를 꽤 많이 쓴다)으로부터 유지관리자 지원 자금을 끌어올 가능성도 충분히 있다. 많은 사람이 이런 기술들, 특히 그 배후 회사들에 대해 타당한 이의를 제기하더라도, 나는 유지관리자를 지원하기 위해 그들의 돈을 받았으면 한다.
이 문서의 내용은 아니지만, RFMF 프로그램의 일환으로 인터뷰한 Python Developer in Residence의 다음 인용문이 떠오른다:
이것이 유급 직무가 되면, 잡무에 대한 심리적 사고방식이 많이 바뀐다. 더 오래 기간 동안 자원봉사 기여자로서 정기적으로 이런 일을 한다는 건 상상도 못하겠다. ‘내 자유 시간을 이렇게 쓰고 있는 건가? 끔찍하다’ 같은 느낌이니까. 하지만 이것이 직업이라면 ‘그래, 이게 오늘의 내 업무다’가 된다. 회사 내부 일을 하는 것보다 낫다.
– Python Developer in Residence (AI에 대해 구체적으로 말하는 것은 아님)
우리가 고사양 원격 데스크톱 접근 권한을 제공하는 것처럼, 프로젝트 기여자와 유지관리자에게 AI 도구 접근 권한을 후원으로 제공할 수도 있다:
이런 도구들을 프로젝트 구성원에게 널리 접근 가능하게 만들고, 그런 도구들을 신중하고 생산적으로 사용하는 방법의 사례를 공유하는 것 — 우리 기준을 낮추는 것이 아니라 높이면서, 유지관리자의 부담을 늘리는 것이 아니라 줄이는 방식으로 — 이것이 우리가 거기에 도달할 가능성이 높은 길이다.
– TC
전면 금지 대신, 다른 오픈 소스 프로젝트들은 웹-오브-트러스트(web-of-trust) 보증이나, 새 기여자가 더 높은 수준의 헌신을 보여주지 않은 채 저품질 PR을 여는 것을 억제하는 기법을 탐색하고 있다:
“팀 멤버가 Rust 작업에 AI를 쓰는 건 괜찮아 보인다. 우리는 이미 신뢰가 구축되어 있다. 하지만 불행히도 새 기여에 대해서는 AI가 아님이 명백하도록 기준을 올려야 한다고 생각한다.”
– oli-obk
“프로젝트 멤버거나 이미 N번 기여한 사람들의 PR로 필터링할 수 있게 해서, 리뷰어가 어떤 종류의 PR을 리뷰할지 결정할 수 있게 하기.”
“이것은 이메일 같은 안티스팸 필터나, 명시적인 웹-오브-트러스트 스타일 보증을 포함하게 될 것이라 예상한다.”
몇몇 사람은 저품질 PR을 식별하고 다루거나, 이슈 분류를 돕는 데 AI 자체가 유용할 수 있다고 제안했다:
우리는 리뷰어를 가능한 모든 방식으로 돕는 데 자원을 투자해야 한다. 몇 가지 무작위 아이디어: [..]
- AI가 PR을 1차로 리뷰해서 일부 이슈를 자동으로 찾아내도록 해서, 리뷰어가 시간을 절약하게 한다.
- AI가 이슈를 1차로 분류(triage)하게 한다(인간이 확인).
- PR 작성자에게 묻는다:
코드를 쓰는 데 AI를 사용했는지/어떻게 사용했는지(Turbo87이 제안했듯이)
장기적으로 팀 멤버가 되고 싶은지, 아니면 일회성 기여만 하려는지.
한 사람은 AI 리뷰에 대한 직접 경험을 언급하며 도움을 제안했다:
AI 쓰레기와 “AI 에이전트”가 github 사용자처럼 이슈와 PR을 제출하는 것은 최악이다. 하지만 Matter 저장소에서는 LLM PR 요약 + 리뷰가 꽤 도움이 됐다. 동료들에게서 Rust 저장소의 리뷰어 시간이 현재 꽤 귀하다는 얘기를 들었고, LLM이 1차 패스 + 요약을 하면 리뷰어의 부담을 줄이는 데 도움이 될 수 있다. AI에서 나온 PR에 대해 되받아치는 데에도 도움이 될 수 있다. 우리 저장소의 예시 #367이 있다. 이것을 rust 저장소에 설정하는 것(처음에는
/gemini review로 옵트인만 제공) 에 사람들이 관심이 있다면, 기꺼이 돕겠다.– gmarcosb
이 문서를 쓰는 내 명시적 목표는 사람들이 말한 것을 요약하고, 이후 논의에서 사용할 공통 기반을 모두에게 제공하는 것이다. 이를 위해, 우리가 앞으로 논의에서 다뤄야 할 몇 가지 긴장을 짚어보는 것이 유용하다고 생각했다.
날카로운 의견 차이에도, 공통 기반은 많다:
스펙트럼 한쪽 끝에서는 Rust 프로젝트가 열정적으로 AI를 수용하길 바라는 사람이 있다:
[사람들이 우려가 있다는 걸 알기에 제안하진 않지만,] 내가 바라는 것은 Rust 프로젝트가 결함을 인정하면서도 Rust를 사용하는 1급 방식(유일한 방식은 아니고)으로 AI를 열정적으로 받아들이는 것이다. 기본적으로, 우리의 도구가 AI 에이전트를 잘 지원하도록 열심히 노력하고, 에이전트와 긴밀히 동작하는 툴링을 만들고, AI를 포함하는 워크플로를 설계하며, 또한 효율/전력 사용/불평등/접근성/오픈 소스 우려를 해결하기 위해 노력하겠다는 성명을 내는 것이다.
다른 끝에서는 AI에 대한 어떤 “타협” 입장도 비도덕적 행동의 공범이 되는 것이라고 느끼는 사람이 있다:
AI에 대해 “서로 살자”는 태도를 제공하는 것은, AI에 마땅히 가져서는 안 될 도덕적 중립성을 부여한다. 이런 방식에서 AI 사용자인 개발자를 지원하는 것은 AI를 _지지_하는 것이다. 이는 AI의 인간적 비용이 받아들일 만하다는 뜻을 내포한다. 나는 그것이 역겹다.
어느 쪽도 타협의 여지가 크지 않다: 깊은 통합은 기술을 도덕적으로 잘못된 것으로 취급하는 것과 양립할 수 없고, 도덕적으로 잘못된 것으로 취급하는 것은 그 기술을 사용하는 것으로써 그것을 지지하는 공간에 참여하는 것을 허용하지 않는다.
중간 지대는, 프로젝트 차원에서는 어느 방향도 지지하지 않으면서 개인들이 AI 사용에 대한 선택을 하도록 허용하는 것이다:
우리 중 많은 사람이 이 기술들의 윤리와 도덕성에 대해 강한 감정을 갖고 있음은 분명하다. 하지만 나는 프로젝트가 그에 대해 입장을 취하는 것은 적절하지 않다고 생각한다 - 궁극적으로 이는 개인적 결정이며, 합리적인 사람들이 서로 다르게 결론 내릴 수 있다 - 그리고 이것이 프로젝트의 전반적 건강에 중요하다고 본다. 동료 프로젝트 구성원들이 도달한 명백히 열정적이고 숙고된 결론을 폄하하려는 의도는 없다. 나는 이것이 많은 이슈에 대해 우리가 취해야 할 건강한 태도라고 생각한다 - Rust 프로젝트는 큰 텐트가 되어, 서로 다른 국가, 문화, 배경, 경험을 가진 사람들이 모여 놀라운 프로그래밍 언어를 만드는 곳이어야 하며, 그런 과정은 이런 이슈들에 대한 차이를 관용하는 것을 필연적으로 포함한다. 이런 입장을 취하는 데에는 Rust가 자신에게 맞지 않는다고 판단한 기여자들을 잃는 보이지 않는 비용이 늘 존재한다. 그렇다고 해서 우리가 이런 기술들이 프로젝트와 유지관리자에게 미치는 부정적 영향을 명확하고 단호하게 말하지 말아야 한다는 것은 아니다. 말해야 한다. 또한 각 유지관리자가 AI와 상호작용하고 싶은지 여부에 대한 의사를 존중하지 말아야 한다는 것도 아니다. 존중해야 한다.
앞선 논점을 이어서, AI 사용자를 “지원”하여(예: AGENTS.md 추가) AI 도구가 더 잘 동작하게 하면 우리가 받는 PR의 품질을 높이는 데 도움이 될 수 있지만, 많은 사람에게는 그것이 _지지_처럼 느껴지거나, 인간에게서 자원을 빼앗는 것처럼 느껴질 수 있다:
Rust 주변에 어떤 AI 도구나 문서를 원한다면, 그것이 우리 프로젝트의 자원을 집어삼키는 꼴은 보고 싶지 않다. 우리는 개선해야 할 사람에게 처리 가능한 문서가 충분히 많고, AI도 그걸 읽을 수 있다고도 계속 듣는다. 어떤 AI용 일을 목표로 하지 않는다면 그런 자원이 존재하지 않을 수도 있지만, 그 작업은 논의에서 공간을 차지하는 것만으로도 우리 프로젝트의 자원을 소비할 것이다.
– oli-obk
메타 노트로, 나(nikomatsakis)는 인간 대상 문서를 두고, AI가 올바른 곳을 가리키도록 하는 AI 표지(signposts)를 추가해 둘 모두에 이득이 되게 문서를 구성하는 것이 가능하다고 믿는다. 하지만 이것을 올바르게 설정하려면 노력이 든다. 그리고 여기서 긴장이 생긴다. 그 노력을 들여 AI를 “돕는” 사람의 기여를 받아들이는 것이 AI를 “지지”하는 것과 동치인가?
AI 사용을 싫어하는 사람들이, 스스로 AI 사용에서 빠져나오거나, 노골적인 방식(리뷰 코멘트를 LLM에 먹이는 사람을 통한 “대리” 포함)으로 AI와 상호작용하지 않도록 허용하는 것은 자연스러워 보인다. 동시에, 여러 사람은 코멘트와 토론 같은 “비정형 데이터”를 분류하고 다루거나, 언어 간 번역에서 AI의 힘을 들었다. 프로젝트가 어떤 형태로든 AI를 배치해 도움을 받을 여지가 있을까? 있다면, 사람들의 “옵트아웃” 권리를 존중하면서 어떻게 할 수 있을까?