▲

AI 코드 생성기 사용을 금지하는 정책 정의

 (github.com/qemu)
1P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • QEMU 커뮤니티가 오픈소스 머신 및 사용자 공간 에뮬레이터인 QEMU의 개발, 기여, 유지 관리 방식에 대해 정책을 명확히 정의함
  • 최근 AI 코드 생성기를 사용한 코드 제출을 공식적으로 금지하는 정책이 도입됨
  • QEMU는 다양한 가상화 및 에뮬레이션 기능을 제공하여 여러 운영체제와 플랫폼에서 동작 가능함
  • 개발자는 기여 규칙과 코드 스타일을 엄격히 따라야 하며, 패치 제출과 관련된 체계적인 절차를 안내함
  • 버그 리포트, 커뮤니티 연락 및 기타 개발 문서를 통해 투명하고 안정적인 개발 환경을 제공함

QEMU 소개

  • QEMU는 오픈소스 및 범용 머신/사용자 공간 에뮬레이터로 다양한 하드웨어 가상화 및 에뮬레이션 기능을 제공함
  • 소프트웨어만으로 전체 머신을 에뮬레이팅할 수 있으며, 동적 번역을 통해 높은 성능을 달성함
  • Xen 및 KVM 하이퍼바이저와 통합하여, CPU 관리는 하이퍼바이저가 담당하면서 하드웨어 에뮬레이션이 가능하며, 이로 인해 거의 네이티브에 가까운 성능을 얻음
  • QEMU는 서로 다른 아키텍처 간 바이너리 실행을 지원함
    • 예: ARMv7 보드용 OS를 x86_64 PC에서 구동 가능, ABI 호환성 및 시스템 콜 에뮬레이션 지원
  • 폭넓은 사용 사례(직접 호출, 고수준 관리 도구와 통합, libvirt와의 연동 등)를 목표로 개발됨

정책 및 라이선스

  • 전체 QEMU 프로젝트는 GNU GPL 2 라이선스로 배포됨
  • 최근 정책 수정으로 AI 코드 생성기(예: Copilot, ChatGPT 등)의 사용 및 해당 도구를 통한 코드 제출이 금지됨
  • 정책 목적은 코드 품질 및 라이선스 준수, 법적 책임 방지를 위함임

문서

빌드 방법

  • QEMU는 Linux, OS-X, Win32, 기타 UNIX 플랫폼에서 빌드 가능함(광범위한 호환성 보장)
  • 표준 빌드 방식은 다음과 같음
    • build 디렉토리 생성 후 configure, make 사용
  • 상세 빌드 정보는 QEMU 공식 위키에서 플랫폼 별로 확인 가능

패치 제출

  • QEMU는 GIT 기반으로 소스 코드가 관리됨
  • 패치 제출시 'Signed-off-by' 라인 필수
  • 스타일 가이드와 개발자 가이드(https://www.qemu.org/docs/master/devel/style.html)를 준수해야 함
  • 패치 관련 추가 지침 및 워크플로우(예: git-publish 도구)는 QEMU 위키에서 제공
  • 정기적 또는 일련의 패치 시 git-publish 사용을 권장함

버그 리포팅

  • QEMU는 GitLab Issues를 통해 버그를 추적함
  • 배포판에서 제공되는 바이너리를 사용할 경우, 우선 공급업체 이슈 트래커에 보고 권장
  • 업스트림 코드에 해당하는 버그는 QEMU GitLab에도 리포팅 가능

변경 이력 및 연락처

  • 버전 히스토리, 릴리즈 노트는 https://wiki.qemu.org/ChangeLog/ 에서 알 수 있음
  • 커뮤니티 연락 방법:
    • 이메일(qemu-devel@nongnu.org)
    • 메일링 리스트, IRC(#qemu on irc.oftc.net)
  • 추가 커뮤니티 접촉 경로는 QEMU 위키에 안내됨

결론

  • QEMU는 다양한 아키텍처 및 하이퍼바이저 통합을 지원하는 대표적인 오픈소스 가상화 플랫폼임
  • 정책 강화로 AI 기반 코드 생성 도구 사용이 명확히 금지되어, 개발 투명성과 품질 및 법적 안정성을 제고함
  • 모든 기여자는 공식 가이드와 정책을 숙지해 협업해야 함
▲
GN⁺ 12시간전  [-]
Hacker News 의견
  • 오픈 소스 및 자유 소프트웨어는 AI로 생성된 코드가 침해 저작물로 간주되거나 퍼블릭 도메인으로 결정될 경우 특히 취약함을 느끼는 중임. 만약 AI 편집과 인간 편집을 구분해야 하는 상황이 오면 프로젝트가 법적 문제로 수년간 묶일 수밖에 없고, 소송 비용도 마련할 수 없음. AI가 만든 코드가 앞으로 인간에 의해 수정되거나 기존 코드에 통합된다면, 후속 인간 편집이 공정 이용을 벗어난 2차 저작물로 볼 수 있는지의 여부도 논점임. 만약 AI 생성 코드가 퍼블릭 도메인으로 결정되면, 소스 코드 중 일부만 오픈소스/프리소프트웨어 라이선스가 적용되는 프로젝트는 라이선스 오남용을 하는 기업을 상대로 강력하게 대처할 수단이 급격히 줄어드는 상황임. 라이선스 위반자가 인간이 만든, 즉 라이선스가 정해진 코드를 썼다는 사실까지 증명해야 하는 굉장한 부담임. 반면, 독점 소프트웨어는 이런 상황에서 상대적으로 타격이 약함. 왜냐면 AI 생성 코드가 무단 인용이라고 주장하려면 결국 누군가 자사 바이너리를 분해해 원 코드와 비교해야 하고, 이미 독점 소프트웨어 코드에도 퍼블릭 도메인 코드가 섞여있는 경우 많음
    • MIT 라이선스에는 오히려 이 상황이 이로운 결과임을 생각함
    • 경험 많은 개발자 입장에서, 지식 없는 "개발자"들이 무작위로 AI 코드를 기여하는 걸 원치 않는 사람 많음에 공감함. AI 코드를 한 줄 한 줄 인간이 직접 검토하는 건 법적 문제를 떠나서도 수년간 인력을 묶을 일임. 첫째, 앞으로 AI로 생성된 코드임을 검증할 실질적인 방법은 거의 없을 전망임. 둘째, 정말 100% 인간만으로 개발된 소프트웨어는 앞으로 AI가 지원하거나 작성한 프로젝트보다 경쟁력이 떨어질 게 분명함. 그 유일한 반론은 인간이 반도체나 전기를 더 이상 대량 생산하지 못하는 아포칼립스 수준의 붕괴 정도 임. 셋째, 만약 어떤 프로젝트가 AI 코드 기여를 완전히 배제할 수 있다 해도, (어떻게 가능할지는 불확실하지만 AI에 반대 입장인 소수만 기여한다 해도) 결국에는 누군가가 그 코드를 복제해 법적으로 위험한 부분만 제거하고 새로운 프로젝트로 갈아탈 것임. 포크가 허용된 라이선스면 그대로 포크될 수도 있지만, 복제 후 정리를 더 선호할 수도 있음. 오픈소스 프로젝트에 아직 길이 남아 있고 미래의 소프트웨어는 양적으로 폭발적으로 늘어날 것이며, 그중 99%는 허접일지라도 정말 가치 있는 소프트웨어도 많아질 예감임
    • AI 저작권 문제와 관련된 주제로 US 저작권국이 AI 아트 관련 입장 발표한 news.artnet.com 최신 기사와 원숭이 셀카 판결 위키 링크 공유하며, 해당 논의는 이미 되돌릴 수 없는 길에 들어섰음을 언급함
    • 만약 어떤 소프트웨어가 "이 코드로 뭐든 원하면 다 해라, 우리 상관 안 한다"라는 의미의 진정한 와이드 오픈 소스라면 AI로 인해 걱정할 일은 전혀 없음
  • LLVM 정책보다는 확실히 더 강경한 입장이라는 인상을 받음. LLVM 개발자 정책에서 자세히 볼 수 있음. 나는 오래된 올드 개발자로서, 저자도 이해 못하고 나 역시 이해하지 못하는 코드를 리뷰하는 상황을 절대 원하지 않음
    • 저자가 자기 코드조차 모르는데 내가 그걸 리뷰해야 하는 상황이 정말 불쾌함. 실제로 누군가 내게 어떤 작업을 부탁하면서 본인이 AI에게 받은 설명을 전달하며 “이렇게 하면 된대요”라고 하는데, 그냥 솔직히 “이거 해주세요”라고 말하는 게 훨씬 낫다는 생각임. 오히려 모욕적으로 느껴짐
    • 내가 관리하는 모든 오픈소스 프로젝트에 DCO(Developer Certificate of Origin)를 추가하기 시작했고, CONTRIBUTING.md에 다음과 같은 LLM 코드 기여 정책을 넣을 예정임

    LLM-Generated Contribution Policy
    Color 라이브러리는 복잡한 수학과 미묘한 의사결정이 가득한 라이브러리임. 모든 이슈나 PR은 제출자 본인의 깊은 이해 하에 작성되어야 하고, 특히 PR의 경우 개발자가 각 커밋에 대해 DCO를 증명해야 함. LLM 도움을 받아 PR을 작성했다면 커밋 메시지와 PR에서 명시해야 함. 증거 없이 LLM 도움이 검출되면 PR 거절임. LLM이 만든 내용을 리뷰 없이 제출하는 것은 무조건 거절임

    SECURITY.md에도 LLM-Generated Security Report Policy로, LLM이 생성한 보안 제보는 무조건 접수하지 않을 계획임

    혼자서 프로젝트를 책임지는 입장에서 균형을 잡으려 하지만 개인적으로 LLM 코드 기여는 선호하지 않음
    • 나는 개인 프로젝트에서는 GitHub Copilot을 활용함. 다만 이걸 “똑똑한 오토컴플리트”가 아닌 방식으로는 쓰지 않음. 내가 입력하려던 코드랑 충분히 유사하면 그제서야 받아들임. 그 덕에 내 코드는 내가 100% 이해하게 되고, 실수로 인한 버그나 저작권 논란도 피할 수 있음. Copilot을 이런 방식으로 쓰면 개발이 빨라짐. 사실 타이핑이 느려서가 아니라, 잡생각에 휩쓸리거나 지루할 때가 많기 때문임. Copilot 덕분에 다음 사고 또는 디버깅 페이즈로 신속히 넘어감.
      도저히 다른 사람이 자기 코드조차 이해하지 못한 채 PR을 제출할 수 있다는 생각은 상상하기 어려움. 그런 사람들이 Policies 때문에 내가 오토컴플리트 수준으로 LLM을 써도 제한당하는 현실에 조금 불만임.
      자동 리팩토링 과제 정도는 Copilot에게 시키고 싶지만, 실험해보면 엉망으로 망가지는 경우가 대부분이고, 전체 블록을 새로 생성하는 방식이 많아서 내가 손으로 하는 것보다 오히려 느려지는 경험임.
      흥미로운 건, 만약 내가 입력 도중 버그를 적고 있으면 Copilot이 그 버그까지 그대로 완성해주는 상황이 많음. 변수명 오타 등 명백한 맥락 상의 실수까지 그대로 자동 완성함
    • LLM을 코딩 업무에서 쓸 때는 예를 들어 “이 YAML 내용을 구조체로 변환해 반복 패턴은 변수로 추출해줘” 식의 요청임. 이걸 결정론적 도구로도 할 수 있지만, AI가 30초만에 깔끔하게 해주고, 결과가 입력과 동일함을 테스트하기도 쉬움
      내가 하는 하이레벨 작업은 절대로 AI에게 맡길 수 없지만, 반복적이고 중요성이 낮은 작업은 AI가 받아서 속도를 높이고 있음. 예를 들어 Claude Code에게 데이터베이스 벤치마크 결과 CSV 파일을 입력해 각종 그래프와 아웃라이어 분석을 연결시켜달라고 하면, 개념적으론 쉽지만 라이브러리를 찾거나 셋업하는 데 시간이 오래 걸리는 작업을 빠르게 완성해줌
    • 저자가 자신의 코드를 이해하지 않는 경우 리뷰하지 않겠다는 심정은 충분히 이해함. 하지만, 숙련된 인간이 올바르게 가이드하면 AI 도구도 상당히 고급 코드를 만들어냄. 최근 몇 달마다 더 강력해지기도 하고, 자연어 지시만으로도 결과물을 만드는 경우가 많음
      코드 “이해”의 의미에 대해 고민 중임. 내가 하는 한 프로젝트는 기존 VM 오케스트레이션 시스템에 새로운 스토리지 백엔드를 완전히 새로 넣는 일임. 기존 코드를 모르는 입장에서, 직접 구현할 시간도 내기 어렵지만, 테스트 클러스터를 구축하고 다양한 시나리오를 돌리며 설계와 테스트 관점에서 전체 그림은 충분히 파악 중임
      나 또한 오픈소스 유지자로서 품질 낮은 LLM “슬롭” PR이 들어오는게 얼마나 큰 스트레스인지 상상 가능함. 결국 저자가 코드를 이해하든 아니든 유지자는 무조건 코드를 리뷰해야 함.
      앞으로는 이러한 도구를 적절히 활용하고, 제출 코드의 품질 수준을 다른 개발자에게 신호로 줄 방법을 모색해야 한다고 봄. 초기 리눅스 ZFS 포트에서 찾아낸 미묘한 버그에서 배운 건, 인간이 한 줄 한 줄 리뷰하고 저술하는 것 못지않게 철저한 테스트가 대단히 중요하다는 점임
  • 내 블로그 “yes i will judge you for using AI”에서 예측한 결과가 현실이 됨. 오픈소스는 전통적으로 기여자 실력의 숨은 신호(competency markers)에 많이 의존했는데, LLM은 경험이 전혀 없는 사람도 실력 있어 보이는 코드를 내놓게 만듦. 경험 많은 사람에게는 정말 혼란스러운 충격임. 앞으로는 실제 PR과 무관한 소셜 증명(가상 또는 대면 회의 등)이 대형 프로젝트 진입에 갈수록 더 필요해질 것임
    • 회사에서도 이런 현상을 겪는 중임. 동료들이 LLM로 코드 리뷰 코멘트를 만들고 수준이 너무 높아 보이니까 잠시 속게 됨. 그래서 코멘트가 맞는지 검증하느라 시간을 엄청 잡아먹게 되고, 실제로는 복붙한 사람이 쏟은 노력보다 내가 훨씬 더 많은 에너지를 소모하게 됨
    • 블로그 링크를 요청함
  • RedHat 중심으로 서명된 정책임. RedHat은 상당히 진지하고 기업 지향적임. 아마 RedHat의 걱정은 “누가 AI로 생성물의 저작권을 가질 수 있느냐”보다 AI가 학습 과정에서 가져온 타 프로젝트 소스가 무심코 튀어나오는 상황일 듯함. 대부분의 하이퍼바이저는 클로즈드 소스이고, 소송 좋아하는 기업이 많음
    • AI가 학습 데이터에서 "다른 프로젝트 코드"를 그대로 내뱉을 위험이라면, 실제로 AI가 생성하는 거의 모든 코드에 해당하는 문제라고 생각함
    • 언어모델은 종종 미묘한 논리적 오류를 더 쉽게 만들 위험이 높고, 하이퍼바이저의 보안 경계까지 침범할 수도 있음. AI 도움을 많이 받은 사용자는 이런 실수를 발견할 준비가 부족하므로 더 위험하다고 봄
  • IBM에 인수된 RedHat 사람들이 주로 이 정책에 서명한 점을 주목함. IBM은 워트슨을 만들었고, 2011년 제퍼디 게임도 이긴 기업임. “이제 막 시작 단계”라는 AI 소프트웨어 개발 담론이 진짜인지, 아니면 IBM식 인수 파괴의 한 장면일지 의문임.
    Dotnet Runtime은 AI를 적극적으로 받아들이고 있음. 외부에서는 비웃을지 몰라도, 스티븐 타우브, 데이빗 파울러 같은 뛰어난 엔지니어들이 지지하는 점을 주목해야 함.
    기업들에게, 다음번 IBM이 AI 서비스를 팔러 올 때 진짜 미래지향적인 파트너를 찾아보길 권함.
    North Carolina 출신으로서 IBM과 RedHat이 제대로 방향을 잡길 바라는 소망임
  • 정말 법적 동기일지 궁금함. 일부 프로젝트는 단지 AI가 만든 허접한 코드 리뷰에 지친 것 같기도 함
    • QEMU는 산업에서 매우 핵심적인 소프트웨어임. 데스크탑 VM, 클라우드, 빌드 서버, 보안 샌드박스, 크로스 플랫폼 환경 등 정말 곳곳에 쓰임. 아주 작은 법적 위험도 업계에 심각한 영향을 줄 수 있음
    • 정책은 명확하고도 제한적임. 알고리즘적으로 생성된 코드의 저작권 귀속을 안전하게 할 수 없다는 점을 강조하는 듯함. 일부러 “알고리즘적으로”를 사용함. 현 정책도 그런 취지로 보이고, “우리는 오늘에 가장 엄격하고 안전하게 시작하고, 차후 완화한다”라는 문장처럼 시작부터 합리적으로 보임. 소위 ‘대량의 슬롭’을 거부하는 것도 맞겠지만, 법적 리스크와 귀속 정리부터 하는 전략임. curl의 정책보다 훨씬 낫다고 느낌
    • 몬산토가 씨앗 권리를 집요하게 집행하는 사례를 들어 경계함
    • AI가 중간 수준 코드의 질을 어떻게 변화시킬지 솔직히 확신 없지만, 인간도 쓸모없는 코드를 주로 내놓음. 코밋이 너무 많고 관리가 어려우면 프로젝트별로 트리아지 팀이 필요한 것 아닐지 고민함. 대부분의 기여는 선의로 이루어진다고 생각함.
      법적 리스크 때문에 AI를 피하는 사람도 이해하지만, 과도하게 걱정하는 것도 의문임. 진짜로 어떤 가능성을 0으로 만들었다 믿는 사람은 아직 충분히 생각하지 않았다고 봄
    • 이 흐름으로 가면 오픈소스가 망가질 수도 있음. 복붙 코드가 너무 쉽게 나오고, 검토 및 거부하는 시간이 너무 많이 듬. 앞으로 더 많은 프로젝트가 “누구나 소스코드는 다운받을 수 있지만, 외부인이 실제로 기여하기는 거의 불가능”한 안드로이드형 모델로 바뀔 것 같음
  • LLM을 IDE에서 똑똑한 자동완성 도구로 쓰는 것과, 고수준 지침을 주고 전체 코드를 대거 생성하게 만드는 상황은 구분이 필요하다는 희망이 있음. 회색지대임은 인정하지만, Copilot 같은 자동완성 정도는 저작권 위험 없이 활용했으면 함. 예를 들어, case문 시리즈 작성 시 Copilot이 패턴을 감지해 입력을 크게 줄여줌
    • 나아가 나의 사고와 신체 일부처럼 AI 안경이 되는 미래를 꿈꿔봄. 지금의 일반 안경처럼 시력을 보완하듯, 스마트 안경이 생각까지 보조할 수 있음.
      내 뇌도 사실 폐쇄 소스 코드를 많이 학습했는데, AI의 저작권 논의가 서구식 NIMBY(지역이기주의) 사고임을 꼬집음. 이런 법적 ‘만약’을 핑계로 멋진 테크를 거부하다 보면 서구 문명 자체가 무너질 수 있다고 우려함
  • 이런 정책이 등장한 이유는 이해하지만, 실수라고 생각함. AI와 저작권 이슈 관련해 법적 판단이 불분명하고 입법도 거의 없다고 봄.
    AI 기여 금지 정책과 별개로, 오히려 “이런 부분에서는 AI를 쓸 수 있습니다”라는 명확한 영역화도 필요하다고 봄. 예를 들어 QEMU의 CI 셋업 등은 보안을 지켜야 할 핵심 영역이 아님. 흥미롭고 새로운 테스트 케이스나 환경을 위한 기여는 AI를 일정 조건하에 허용하는 방식도 충분히 가능하다고 봄
    • 이 정책을 시행하지 않으면 어떤 리스크가 있을지 고민함. 조금 느릴지라도 더 나은 코드가 나올 테고, 속도를 희생하더라도 QEMU처럼 중요한 프로젝트에는 그 정도 리스크는 감수해야 한다고 봄. 저자들이 GenAI 자체에 부정적이라기보다, 한 번 돌아가면 되돌릴 수 없는 상황이라 신중하게 접근하는 것 같음
    • 단순하게 “법적 상황이 명확해질 때까지 기다린다”가 가장 쉬운 해결책임. QEMU는 거의 대부분 코드가 GPL 2.0인데, 만약 GenAI 코드가 잘못 도입되고, 추후 법적으로 “원 코드 라이선스를 반드시 따라야 한다”는 판례가 나오면, 관련 코드 롤백 및 다운스트림 전체에 부담이 생김. 애초에 “이 부분은 AI, 재사용 금지” 식 라벨링을 해도 추후 전면 재작성 이슈가 남음.
      결국 “일단 지금은 안 받는 것”이 모두에게 덜 복잡하고, 덜 드라마틱한 선택임
      관련 자료로 QEMU 라이선스와 비자유 라이선스 목록 링크를 첨부함
    • 이런 문제는 수십 년 갈 법적 논쟁이 아니라, 이미 관련 소송 수십 건이 법원에 올라가 있어 수년 내에 판례가 나올 예정임. QEMU는 AI 없이 22년간 훌륭히 성장했으니, 몇 년 더 기다려도 전혀 나쁠 거 없음
    • 이 정책의 겉과 속을 잘 읽어보라는 조언임. 모든 행동은 법적 리스크가 있지만, 세계적 대기업들은 오히려 이런 리스크도 감수함. QEMU가 유별난 게 아니라, 실은 단지 LLM 코드를 정말로 쓰고 싶지 않아서 이런 입장을 내세운 걸로 읽힘. “변호사에게 알아보라 → 법적으로 리스크 → 못 쓴다”는 명분으로 논쟁 자체를 종식시키려는 전략임. 회사에서도 똑같이 벌어지는 패턴임
    • 컴퓨팅 업계엔 “코드를 표절하지 않는다”는 오래된 관행이 있음. 아주 짧은 코드라도, 법적으로 ‘공정 사용’에 해당하더라도 원 코드를 복사하지 않는 문화임
  • “엄격하고 안전하게 시작하고, 차츰 완화한다”는 명분이 정말 합리적임
    그러나 AI 생성 코드와 인간이 어디선가 베낀 코드를 실질적으로 구분할 방법이 있는지 고민임. 오픈소스는 누구나 기여 가능한 만큼, 인간이 코드에서 타 소스 영향을 받는 경우도 마찬가지임
    현재 관점에선, AI 생성 코드는 그 자체로 독립된 아이덴티티가 있다기보다 인간의 손에 달린 도구에 더 가깝다고 생각함
    • “AI 생성 코드는 인간이 쥔 파워쏘(강력한 전동톱)와 같다”는 비유임. 강력한 도구라 인간 다음에 따라 위험해질 수도 있음.
      이제 이 비유도 더 이상 쓸 필요 없을 정도로 길게 늘어졌다고 느낌
  • 이런 정책은 현실적으로 전혀 시행 불가능해 보임. Zed, Cursor, VS code 모든 에디터가 AI 기반 자동완성을 제공하고, 내가 타이핑한 코드와 AI 힌트 코드의 구분은 전혀 불가능함.
    마치 내가 막대기 그림을 그렸다가 “그 그림이 혹시 남의 막대기 그림을 베낀 걸 수 있으니 제출할 권리가 없다”라는 주장과 같음
    정책의 진짜 목적은, 결국 언젠가 누군가가 AI 코드와 뒤섞인 것을 제출한다 해도 “어쩔 수 없다”고 말할 명분쌓기용임. 정책 입안자들이 본인들도 그 정책이 무의미하다는 점을 모를 리 없다고 생각함
    • 이런 정책은 “정책적으로 의심되는 코드가 제출되면 우리도 어쩔 수 없었다”라는, 책임 회피 명분을 자명히 확보하려는 성격임. 커밋 메시지나 패치에 “코드 생성기의 라이선스 문제는 법적으로 정립되지 못했다”라는 입장도 포함됨.
      법적 이슈 말고도, AI 코드를 쓸 때 생기는 다양한 다른 문제도 분명히 존재함
    • Neovim은 AI를 강제하지 않음. 본인이 직접 설정해야 작동함. 에디터가 AI를 끌 수 없게 만든다면, 그 에디터 자체에 심각한 문제가 있다고 생각함
답변달기