Vibecoding 공개로 Emacs 패치가 거절됨

 (xlii.space)
1P by GN⁺ | ★ favorite | 댓글 1개
  • macOS용 Emacs 성능 개선을 위해 만든 작은 패치가 emacs-devel에 제출됐지만, LLM 보조 작업을 받지 않는 GNU 정책 때문에 받아들여지지 않음
  • 작업자는 GLM 5.2가 이슈를 찾고 초안을 만들었다고 공개하면서도, 본인이 정확성·영향 분석, 수정, 수동 테스트, 개인 책임을 맡았다고 밝힘
  • 거절된 패치는 범위가 좁은 92줄짜리였고, LLM 사용 사실을 숨길 수도 있었기 때문에 정책이 사용보다 정직한 공개를 불리하게 만든다고 비판함
  • GNU 쪽 우려는 LLM 산출물의 개방성·법적 사용 가능성에 가까웠지만, 그는 오픈 웨이트 모델과 실제 업계 사용 사례를 근거로 동의하지 않음
  • 그는 더 이상 Emacs 작업을 하지 않겠다고 했고, 하드드라이브에 있던 약 40개 성능 개선 패치 중 최근 확인한 일부만 공개함

macOS Emacs 성능 개선 작업

  • Przemysław Alexander Kamiński는 몇 달 동안 macOS에서 Emacs 성능을 개선하며 계측 연결과 벤치마크 작성에 시간을 썼음
  • 여러 LLM에 Emacs 코드베이스를 주고 특정 문제를 찾게 했지만, 대체로 결과는 좋지 않았음
    • 패치를 분석해 보면 영향이 작거나 문제를 잘못 이해한 경우가 많았음
  • 당시 성능 병목에 대한 판단은 다음과 같았음
    • macOS에서 주된 문제는 렌더링 이슈와 빠른 할당·해제로 인한 메모리 스래싱임
    • macOS의 시스템 malloc 방식은 메모리 압축 부재로 가상 메모리 팽창과 캐시 지역성 손실을 일으킴
    • Emacs 코어에도 성능 문제가 남아 있음
    • regexp 처리는 여러 곳에서 쓰이므로 개선 시 전체 성능에 영향을 줄 수 있음

GLM 5.2로 찾은 패치와 제출 과정

  • 친구에게 z.ai Max 플랜을 받아 GLM 5.2를 사용할 수 있었고, 그는 이 모델이 코드 최적화에 꽤 유능하다고 평가함
  • 이미 쌓아둔 지식을 바탕으로 Emacs 관련 구체적 질문을 던지고, GLM 5.2에 이슈 탐색과 분석을 맡김
  • 약 3시간 뒤 몇 개의 보고서를 받았고, 제안과 코드를 검토한 뒤 각 항목의 영향을 테스트하고 벤치마크를 실행함
  • 패치 제출용 정리에 시간이 들기 때문에 가장 유망한 항목 하나를 골라 작업했고, 글을 쓰기 이틀 전 emacs-devel 메일링 리스트에 보냄
  • 다음 날 GNU에 LLM 보조 작업을 받지 않는 정책이 있어 패치가 받아들여지지 않는다는 사실을 알게 됨

제출 메일에 공개한 LLM 사용 범위

  • 메일링 리스트에 패치를 보낼 때 LLM 사용 사실과 자신의 검토 범위를 함께 명시함
    • 이슈 발견과 패치 초안 작성은 GLM 5.2가 했으며, GLM 5.2는 중국의 오픈 웨이트 모델이라고 밝힘
    • 이슈 보고서의 정확성과 영향을 직접 분석함
    • 패치를 검토하고 수정함
    • 패치를 수동 테스트함
    • 법적 목적에서 제출물의 저작자성을 선언했고, 자신의 기여가 LLM보다 크다고 주장할 준비가 되어 있다고 밝힘
    • 제출물에 대한 전적인 개인 책임을 지겠다고 선언함
  • 제출물은 구현 범위가 매우 좁고 규모도 작았음
    • 공개한 패치는 92줄이며, 주석 안에 존재 이유가 포함돼 있음
  • 그는 이 패치를 “slop”으로 분류할 수 없다고 보지만, 각자 판단해도 된다고 덧붙임

GNU 정책에 대한 반박

  • 그는 GNU의 정책을 존중하지만 동의하지 않으며, 정책에 충분한 근거가 없다고 봄
  • LLM 사용 사실을 숨길 수도 있었지만 명시적으로 공개했고, 그 결과 제출이 불리해졌다고 판단함
    • 그래서 이 정책은 LLM 사용 자체보다 정직한 공개를 처벌한다고 비판함
    • 그는 LLM을 전혀 신뢰하지 않기 때문에 LLM 보조 작업에는 더 적은 검토가 아니라 더 많은 검토와 시선이 필요하다고 봄
  • 정책의 전체 맥락은 내부 GNU 리스트에서 논의되므로 알 수 없고, 과거 대화에서 접한 의문은 LLM 기여가 충분히 열려 있는지와 법적으로 사용할 수 있는지에 가까웠다고 정리함
  • 오픈 웨이트 모델의 개방성을 문제 삼는 논리에는 동의하지 않음
    • 예를 들어 로컬 환경에서 Qwen 3.6을 쓰면 괜찮지만 OpenRouter를 통해 쓰면 안 된다는 식의 구분은 부조리하다고 봄
    • GLM 5.2는 오픈 웨이트 모델이며, 256GB RAM과 24GB VRAM이 있다면 로컬에서 실행해 “SaaS는 닫혀 있다”는 논점을 피할 수 있다고 말함
    • 인터넷에는 비자유 콘텐츠가 많으므로, 같은 논리라면 제출물을 만들 때 인터넷 접근도 금지해야 하느냐고 반문함
  • 법적 우려에도 동의하지 않음
    • 게임 회사들은 IP와 LLM에 더 민감하지만 LLM 사용이 보이고, ChatGPT는 10억 활성 사용자를 갖고 있으며, 수십만에서 수백만 조직이 매일 LLM 출력을 사용한다고 말함
    • 그는 미국 변호사가 아니라고 전제하면서, 저작권 등록 문제는 저작권 표시를 붙이는 쪽에 있다고 이해함
    • GNU가 자신들의 변호사와 의견에 가장 큰 무게가 있다고 믿는 태도에는 동의하지 않음

Emacs 작업 중단과 공개된 패치

  • 그는 GNU가 스스로 결정할 자유가 있고 자신도 비판할 자유가 있다고 말함
  • 내부에서 정책을 논의하면서 사용자에게 투명하지 않은 방식은 Meta가 Facebook 방향을 내부 결정하는 것만큼만 열려 있다고 비판함
  • 결과적으로 그는 더 이상 Emacs 작업을 하지 않겠다고 밝힘
    • 자발적으로 하는 작업에서 “막대를 잘못 잡고 있다”는 말을 듣는 상황을 싫어한다고 함
  • 하드드라이브에는 약 40개 성능 개선 패치가 있으며, 일부는 서로 겹치고 일부는 실제 영향이 아직 입증되지 않았음
  • 최근 확인해 동작하고 의미 있는 영향을 보인 일부 패치만 공개했으며, 그는 해당 패치들이 실제로 차이를 만든다고 말함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • "open weight"의 open이 무슨 뜻인지 저자가 오해한 것 같음
    최종 행렬 덩어리가 공개되어 있고 어느 정도 미세조정할 수 있다고 해서, 그걸 만드는 데 쓴 학습 자료까지 오픈소스였다는 뜻은 아님. OSI seems to agree도 비슷하게 보는 듯하고, 그렇다면 저작권 문제는 전혀 해결된 게 아님
    선의로 대가 없이 기여하려는 사람에게 공감은 가지만, GNU는 규칙을 명확히 적어두었고 거기에 가서 "조금만 어겼고, 여기 패치가 있다"고 하면 거절당해도 이상하지 않음. 거절된 이유는 정직함이 아니라, 명시적으로 하지 말라고 한 일을 했기 때문임

    • 비공개 계약이 걸린 데이터시트를 바탕으로 작성된 드라이버도 전부 자유 소프트웨어가 아닌 건가? 제조사 직원이 내부 문서와 전문 지식을 활용해 드라이버를 작성한 경우는 또 어떻게 봐야 하나?
    • 학습 자료가 왜 관련 있는지 잘 모르겠음. 산출물을 자유롭게 사용, 재배포, 수정할 수 있다면 꽤 open에 가깝다고 봄

  • 수십억 명이 틀릴 수도 있다는 걸 저자가 오늘 배우면 좋겠음. Normalization of deviance는 일탈을 정당화하지 않고, 그 일탈이 계속 퍼지는 방식을 설명할 뿐임
    chatbot psychosis에서 보이는 패턴 중 하나는 반대하거나 다른 의견을 내는 인간을 적대자로 인식하는 것임. 챗봇이 학습한 narremes에는 사용자가 주인공이고, 어깨너머 카메라와 읽기 쉬운 개인 서사를 가진다는 관점이 포함되어 있음. 챗봇의 후처리된 선호 서사가 사용자에게 주인공 의식을 강화하면서 직접 영향을 주고, 사용자가 충분히 이온화되면 중립적 입장도 받아들이지 못하게 됨
    이 경우 저자가 링크하거나 인용하지 않은 the original discussion를 읽어보길 권함. Emacs 커뮤니티는 저자에게 친절하고, 수용적이며, 질문하고, 관심을 보이고, 받아들이는 태도를 보였음. 패치를 거절할 때도 저자를 비난하기보다 GNU 정책에 초점을 맞춰 부드럽게 말함

    • 실제 논의 링크를 글에 넣지 않은 건 솔직히 큰 위험 신호임. 못 알아챈 게 믿기지 않을 정도임
    • narremes라는 Wikipedia 문서는 단락 하나뿐인데 [incomprehensible] 태그가 붙어 있음
      그래도 문맥상 무슨 뜻인지는 알겠고, 여기에는 유용하고 잘 맞는 개념처럼 보임

  • GNU Project는 미국 저작권 문제만이 아니라 전 세계 저작권 우려를 고려해야 함. 미국 법도 완전히 정리된 상태가 아님
    GNU는 중요한 기여에 대해 자신들이 저작권을 100% 보유한다고 확신하고 싶어함. 여기서 저자의 법 해석은 중요하지 않고, GNU Project는 안전하게 가는 중임. LLM에 대해 아마 갖고 있을 다른 우려는 아직 고려하지도 않은 상태임

    • 솔직히 현재 판례 기준으로 보면 저자의 미국 법 이해도 틀렸음[1]. 기존 판례상 LLM 생성 코드는 저작권 보호를 받을 수 없고, 따라서 라이선스를 붙일 수도 없으며 자동으로 퍼블릭 도메인이 됨
      게다가 저장소에 LLM 생성 코드가 들어 있는데 그 코드가 명확히 구분·표시되어 있지 않다면, 저장소 전체가 저작권 보호도 라이선스 부여도 불가능한 것으로 간주됨
      달리 말하면 저자가 거짓말해서 코드가 커밋되게 했다면, Emacs 코드베이스 전체의 라이선스 효력을 위험에 빠뜨릴 수 있었음
      이 모든 건 "IANAL이지만 변호사들이 명백히 틀렸다"는 망상에 가까운 오만한 태도와는 별개임. 관련 법 조항 일부만 보면서, 동시에 변호사들을 오만하다고 비난하고 있음
      [1] 약 두 달 전 회사 법무팀과 이런 대화를 나눴을 때 기준으로는 최신임

  • "거짓말했으면 받아들여졌을 것"이 의미 있는 논거인지는 잘 모르겠음

    • 똑같은 논리를 라이선스에도 쓸 수 있음. 독점 코드베이스에서 뭔가 복사해 와서 직접 썼다고 거짓말하면 패치가 받아들여질 수 있음. 하지만 사실대로 말하면 거절됨. 그러니 결론은 라이선스가 나쁘다는 건가?
    • 맞음. no-LLM 정책에 대해 "그러면 사람들은 그냥 거짓말할 텐데"라는 주장을 자주 들음
      그건 해당 사람들에 대해 좋은 얘기는 전혀 아니지 않나?
      관리자들을 LLM 찬반 정책 때문에 괴롭혀도 좋을 건 없다고 봄. 그들이 일을 하고 있고, 어떤 기여를 평가하고 받아들이고 거절할지 선택할 권리가 있음
      물론 불평하는 건 괜찮다고 봄. 이 사람은 블로그에서 자기 입장을 밝히고 있고, 그렇게 논의를 맞춰가는 것이니까. 다만 framing에는 동의하지 않음. 여기서 문제는 "정직함"이 아님. no-LLM 정책이 공지되어 있었다면, 그런 기여를 원하지 않는 프로젝트에 LLM을 써서 기여하려고 시간을 쓴 책임은 본인에게 있음
      이건 비건에게 고기나 치즈가 든 음식을 주고, 재료를 "정직하게" 말했기 때문에 안 먹는다고 불평하는 것과 다르지 않음. "말 안 했으면 유제품이 들어간 줄 몰랐을 텐데"는 좋게 보이지 않고, "말 안 했으면 내가 LLM을 쓴 줄 몰랐을 텐데"도 마찬가지임
    • 동의함. 새 제목으로 Vibecoding gets Emacs patch rejected를 제안했음. 바이브 코딩을 인정한 정직함은 저작권 침해를 인정한 정직함과 비슷함. 거절의 근본 원인은 정직함이 아님
    • LLM을 쓰고 정직하게 밝히는 건 패치가 거절될 이유라고 봄. LLM을 쓰고 거짓말하는 건 패치 거절에 더해 이후 기여 시도까지 금지될 이유임

  • GNU와 FSF는 전문적인 법률 자문을 받는 데 꽤 많이 투자함. 그런데 이 잠재 기여자는 인터넷의 어떤 사람이 하는 말에 따라 그 전문 자문을 무시하라고 권하는 셈임
    전문 자문에 비용을 냈다면 그 조언을 따르는 게 합리적이고, 동의하지 않는다면 다른 전문가를 찾아야 함. 무작위 인터넷 댓글러의 조언 때문에 그걸 무시하는 건 "거의 풍자적"인 게 아니라 그냥 어리석음

    • 프로젝트에 기여한다는 건 자신을 드러내고 취약한 위치에 서는 일임. 특히 "코드는 작동하고" 개인적인 불편을 해결해주는 경우라면 거절이 더 힘들 수 있음
      거절과 별개로, 앞으로 꽤 흥미로운 법정 사례들이 생길 수 있을 것 같음. 대형 모델 제공사들이 어떤 형태의 면책을 제공하고 "우리가 도와 만든 코드이니 원하는 대로 저작권을 주장해도 된다"고 할 수도 있고, 반대로 문제를 밀어붙여 자신들이 소유하며 특정 용도에는 라이선스를 받아야 한다고 할 수도 있음. Claude는 현재 코드를 사용자에게 주지만, 어떤 면책을 제공하는지는 모르겠음. 다른 모델들도 잘 모르겠음

  • 범죄는 잡혔을 때만 불법이라는 사실을 알고 있었나

  • GNU의 열렬한 팬은 전혀 아니지만, LLM 코딩 도구는 GNU 철학의 정반대에 있는 것 아닌가? 고양이 카페에 개를 데려가고 쫓겨났다고 화내는 느낌임

  • 제목을 "Honesty gets Emacs patch rejected"에서 Vibecoding gets Emacs patch rejected로 바꾼 건 매우 부정직하다고 봄
    저자처럼 AI 도구의 도움을 받았더라도 코드에 그 정도 시간과 이해를 들였다면 명백히 바이브 코딩이 아님. "Emacs를 더 빠르게 만들어줘"라고 AI에 던져놓고 결과를 눈감고 제출했다면 바이브 코딩이겠지만, 글을 읽어보면 분명히 그런 일은 아니었음

    • "honesty"라는 제목도 부정직했음. 패치가 거절된 건 정직함 때문이 아니라 정책 위반 때문임
    • "바이브 코딩"이라는 용어에 대한 해석에는 동의하지만, 사람들이 그 용어를 워낙 다르게 쓰는 걸 보면 그렇게까지 부정직하다고 보진 않음
      나라면 "Breaking contribution policy gets Emacs patch rejected" 정도로 했을 것 같음. 여전히 빈정대지만, 반박하기는 더 어려움

  • 여기서 눈에 띄는 건 저자가 두 달 동안 꾸준히 작업했다고 주장하면서, 문제를 찾고 해결하는 데 사용했다는 모델은 12일 전 출시됐다고 설명한다는 점임
    저자가 꽤 화가 난 건 이해하지만, 결국 오픈소스는 어떤 권리를 주는 게 아니라 이미 만들어진 코드를 쓸 수 있는 특권에 가깝다고 봄. 장점이 있다면, 아마 있을 것이고 macOS에 대해 쓴 내용은 대체로 맞으니 Emacs 개발자들이 시간을 내서 살펴볼 수도 있음. 다만 macOS가 그들의 주된 관심사는 아닐 것 같음

  • 이 정책이 얼마나 어리석은지 증명하는 쉬운 해결책이 있음. 두 번째 모니터에 LLM 보조 PR diff를 띄워두고, 기본 모니터에서 수정 내용을 처음부터 손으로 다시 작성하면 됨. 변수 이름과 주석 내용도 조금 바꾸면 됨
    이제 사람이 작성한 코드가 되었으니 병합될 수 있음

    • 전 세계 여러 관할권에서 LLM 산출물을 둘러싼 저작권과 법적 쟁점을 보면, 그건 매우 순진한 관점임
답변달기