NLnet Labs의 LLM 사용 정책

 (nlnetlabs.nl)
1P by GN⁺ | ★ favorite | 댓글 1개
  • NLnet Labs는 프로젝트 기여와 커뮤니케이션에서 LLM 사용을 제한하며, 정책 위반 제출물은 사전 통지 없이 닫히거나 삭제될 수 있음
  • 코드와 문서 기여는 사람이 직접 작성해야 하며, LLM이나 다른 확률적 도구가 생성한 내용은 포함할 수 없음
  • 취약점·버그 보고에서는 LLM이 제안한 수정안을 예외적으로 받을 수 있지만, 사람 기여자가 문제와 심각도를 검증해야 함
  • 이슈, 취약점 보고, 포럼 게시처럼 NLnet Labs와 상호작용할 때는 LLM 사용 공개가 필요하며, 기계 번역도 오역 가능성 때문에 공개가 권장됨
  • LLM을 linting, 분석, 리뷰에 활용할 수는 있지만, 외부에 공유하는 정보의 정확성을 이해하고 검증할 책임은 기여자에게 남아 있음

정책 범위와 기본 의무

  • NLnet Labs는 조직과 프로젝트 맥락에서 Large Language Models(LLMs) 사용 방식을 제한함
  • 정책을 따르지 않는 제출물은 사전 통지 없이 닫히거나 삭제될 수 있음
    • 대상에는 PR, 이슈, 댓글, 포럼 게시물 등이 포함됨
  • 이 정책과 함께 code of conduct와 각 프로젝트의 CONTRIBUTING.md도 따라야 함

기여물 작성 원칙

  • 코드와 문서 기여는 사람이 작성해야 함
    • LLM 또는 다른 확률적 도구가 생성한 내용은 포함할 수 없음
    • 취약점 또는 버그 보고에 포함된 LLM 제안 수정안은 예외적으로 허용됨
    • 이 예외는 초기 검토 중 문제의 근본 원인을 더 쉽게 찾기 위한 용도임
  • PR을 열 때도 LLM 생성 기여는 받지 않음
    • 제출하는 코드는 LLM이 생성한 것이면 안 됨
    • PR 설명은 자신의 말로 간결하게 작성해야 함
    • 일반적으로 새 기능 PR은 먼저 NLnet Labs와 이야기하지 않고 열면 안 됨
    • 소프트웨어 변경 아이디어는 community forum에 자신의 생각으로 공유할 수 있음

LLM 사용 공개와 번역

  • NLnet Labs와 상호작용할 때는 LLM 사용 여부를 공개해야 함
    • 이슈 개설, 취약점 보고, 커뮤니티 포럼 게시가 포함됨
  • 영어가 모국어가 아닐 때 기계 번역은 도움이 될 수 있음
    • 기계 번역을 사용했다면 오역으로 인한 의사소통 문제 가능성을 양쪽이 인지할 수 있도록 공개가 권장됨
    • 번역의 정확성을 판단할 수 없다면 모국어로 작성할 수도 있음
    • LLM 번역은 생성적 특성 때문에 논의를 쉽게 하기보다 혼란스럽게 만들 가능성이 높아 권장되지 않음

허용되는 활용과 검증 책임

  • LLM을 linting, 분석, 리뷰에 사용하는 것은 허용됨
  • LLM이 문제 발견이나 분석을 도왔더라도, 공유하는 정보의 정확성을 이해하고 검증할 책임은 사용자에게 있음

취약점 보고

  • NLnet Labs는 LLM으로 찾은 취약점 보고를 받을 수 있음
    • 보고서에 LLM 제안 수정안을 포함해 문제 위치 파악을 도울 수 있음
    • 사람인 기여자가 문제와 추정 심각도를 검증해야 함
    • sep@nlnetlabs.nl로 보고할 때 LLM 사용을 공개해야 함
    • 취약점 보고 절차는 security report 페이지를 참고해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 이런 규칙의 배경 논리를 듣고 싶음
    예를 들어 주된 동기가 법적 불확실성인지, 품질이나 유지보수 우려인지, 혹은 다른 이유인지 궁금함

    • NLnet Labs의 Alex Band가 this toot에서 꽤 절제된 방식으로 설명했듯이, 누군가 훌륭하고 필요한 기능을 기여하려고 프롬프트를 잘 써서 기능상 의도대로 보이는 1만 줄 코드를 생성할 수는 있음
      하지만 NLnet Labs 팀에 풀 리퀘스트로 제출하기 전에, 생성된 모든 줄을 검토했고 이해했으며 책임질 수 있는지가 핵심임. 지난 1년 경험상 그런 경우는 드물었고, 선의의 선물처럼 코드가 문 앞에 놓이지만 검토하고 책임지고 main 브랜치에 병합하는 부담은 팀에게 넘어감. 이 소프트웨어가 인터넷의 근간을 이루는 핵심 인프라에서 동작한다는 점을 생각하면 큰 요구임. 리뷰 과정에서는 문제 영역과 제안된 해법의 세부를 양쪽이 함께 이해한 상태로 대화할 수 있어야 하는데, LLM 사용은 제출자에게 그런 이해를 제공하지 못하고 장기 유지보수에도 악영향을 줌
    • 이 문서 작성에 나선 직접적인 이유는 개발자들의 시간을 보호하기 위해서였음
      물론 저작권, 품질 관리, 장기 유지보수, 윤리적 우려도 모두 고려했음

  • 사람이 패치를 작성하고 리뷰하는 데 초점을 둔 점도 좋고, 취약점 보고서의 패치 제안은 예외로 둔 점도 좋음
    단순하고 핵심만 짚은 경우라면 그런 제안은 읽어볼 가치가 있음

  • 사람들이 AI 생성물에 지치는 이유를 이해할 수 있고, 특히 규모가 커지면 더 그렇다 봄
    내가 일하는 작은 팀에서도 짜증나는 일이 생김. “왜 이렇게 했나요?”라고 물으면 “아, Claude가 그렇게 했어요”라는 답이 돌아오는데, 그건 답이 아님. 사람들이 사고 과정뿐 아니라 책임까지 기계에 떠넘기는 셈임. 지금은 보수적으로 사용하는 편이 꼭 나쁘지 않고, 이 기술을 대규모로 책임 있게 쓰는 법을 알게 된 뒤에야 완화하는 게 맞다고 봄. 현재로서는 아무도 그 방법을 모름

  • 이건 NLnet Labs 자체 정책일 뿐이고, NLnet의 지원을 받는 프로젝트들이 반드시 채택해야 하는 정책은 아님

  • 이런 결정을 내린 배경은 이해되지만, 집행 방식이 “전부 안 된다”에 가까워서 시야가 좁아 보임

    • 그 규범적 판단이 어디서 나오는지 설명해줄 수 있나? 다른 사람이 자기 프로젝트에 LLM 생성 제출물을 받아들이는 데 왜 이해관계가 있는지, 그들이나 사회가 무엇을 얻는지 궁금함
      나는 이 논리가 일관되고 합리적이며, 요즘 같은 시기에는 건강한 보호 조치라고 봄. 이런 이유로 당신의 제출물이 거절될까 봐 걱정하는 건지, 이미 그런 일을 겪은 건지도 궁금함. 이 정책을 따르는 게 그렇게 어려운 일일까? 본인이 핵심 인프라의 장기 유지관리자로서 매일 이슈 트래커에 쏟아지는 저품질 잡음을 처리하고 있나? 사람 중심 워크플로에서 거짓 양성의 홍수로 인한 영향을 줄이면서 동기를 유지하려면 어떻게 해야 한다고 보나?
    • 시야가 좁다기보다는 신중하다고 부르겠음
    • 관련 커뮤니티가 모두의 이해관계를 더 정확히 반영하는 개방적이고 복잡한 규칙을 감당하지 못한다는 것이 드러나면, 좁고 단순한 규칙이 정해지는 일은 꽤 흔함
      이게 나쁜 일은 아님. 개발자들이 조금 더 성숙해지면 다시 검토할 수 있을 것임
답변달기