LLM으로 질문에 답하고 분석·요약·정제·검사·제안·검토하는 건 괜찮지만 창작에는 쓰지 않는다는 명확하고 합리적인 정책이 마음에 듦

이 한 줄에도 “LLM 출력을 명확히 표시하고 직접 판단한다는 전제 아래 검토에 사용할 수 있다”는 조건이 들어가면 좋겠음. 아래 본문은 훌륭하게 설명하지만 이 문구만 보면 너무 모호하거나 잘못된 인상을 줄 수 있음

이 문구는 요약일 뿐이고, 글에 링크된 생성 코드의 여러 예외 조건이 있음. 다만 설명이 길어서 세부 내용을 제대로 이해했는지는 확신하기 어려움

“모국어로 작성한 메시지도 환영하며 영어 번역은 필요하지 않다”는 방침을 매우 환영함. 이제부터 rust-lang/rust의 모든 댓글을 한국어로 작성할 예정임

전혀 구사하지 못하는 언어로 기계 번역한 글보다 모국어 원문을 받는 편이 언제나 나음. 내가 조금이라도 아는 언어라면 직접 읽고, 그 언어를 아는 사람에게 부탁하거나, 기계 번역이 이상할 때 사전과 다른 방법으로 검증할 수 있기 때문임
기계 번역문만 받으면 이런 확인이 불가능해 번역이 정확하기만을 바라야 함. 작성자가 상대 언어를 어느 정도 구사한다면 대부분은 어차피 기계 번역을 쓰겠지만 작성자가 더 잘 번역할 수도 있어 균형을 따져야 함

토론이 많은 Rust 팀에 있을 때, 영어 원어민들에게 동료가 영어를 잘 쓰더라도 여전히 추가적인 인지 부담이 든다는 점을 자주 상기시켰고 토론 강도를 낮추는 게 도움이 됐음
각자 모국어로 생각을 정리한 뒤 번역하는 방식도 충분히 괜찮음

“코드 자체는 변경에서 가장 작고 어떤 면에서는 가장 덜 중요한 부분”이라는 문장이 강하게 와닿아 팀에 글까지 작성했음. 어제 검토한 동료의 LLM 생성 PR은 버그 원인을 찾아 고치긴 했지만 루브 골드버그 장치처럼 터무니없이 복잡했으며, 동료가 PR을 만들기 전에 변경 사항을 검토했는지조차 모르겠음

둘 중 하나만 골라야 한다면 개인이 Fable을 실행해 만든 코드를 팀에 던져 검토하게 하기보다, 팀이 프롬프트와 구현 계획을 함께 검토하고 Fable이 작성한 코드는 검토하지 않는 편을 택하겠음. 물론 LLM이 등장하기 수십 년 전부터 설계 검토를 선호했음

질문·분석·요약·정제·검사·제안·검토도 결국 모두 창작 행위임

이런 공지에는 요약이나 TL;DR을 넣어야 함. 누가 작성했는지는 관심 없고, 정부 문서처럼 여러 페이지를 뒤지지 않아도 어떤 행동을 기대하는지 알고 싶음
공식적인 소통은 가장 짧은 요약으로 시작하고 필요와 관심에 따라 점차 자세한 내용을 읽을 수 있는 점진적 공개 방식을 따라야 함
Rust의 새 정책은 비공개로 코드 이해·아이디어 구상·요약·자기 작업 검토에 LLM을 쓰는 것은 허용하지만, 이슈·PR 설명·댓글·문서·진단 메시지·중요 코드 주석 등 공개 산문은 대체로 금지함. LLM을 활용한 검토와 버그 발견은 공개를 전제로 허용하되 사람이 검증하고 결정해야 하며, 생성 코드 PR은 사전 합의·사용 공개·강력한 테스트·사람의 이해를 갖추고 대개 중요하지 않은 코드에만 허용됨. 관련 LLM 사용은 공개해야 하지만 문체만으로 공개적으로 의심해서는 안 됨
목표는 검토자의 시간과 책임성, 진정한 기술적 이해를 보호하는 것이며 합리적으로 보임. 이 요약은 LLM이 생성했음

정책은 사실상 “LLM으로 질문에 답하고 분석·요약·정제·검사·제안·검토하는 건 괜찮지만 창작에는 쓰지 않는다”는 한 줄인데도 TL;DR이 필요한지 의문임