# Vibecoding 공개로 Emacs 패치가 거절됨 > Clean Markdown view of GeekNews topic #30856. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30856](https://news.hada.io/topic?id=30856) - GeekNews Markdown: [https://news.hada.io/topic/30856.md](https://news.hada.io/topic/30856.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-26T23:04:12+09:00 - Updated: 2026-06-26T23:04:12+09:00 - Original source: [xlii.space](https://xlii.space/eng/honesty-gets-emacs-patch-rejected/) - Points: 1 - Comments: 1 ## Topic Body - 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보다 크다고 주장할 준비가 되어 있다고 밝힘 - 제출물에 대한 전적인 개인 책임을 지겠다고 선언함 - 제출물은 구현 범위가 매우 좁고 규모도 작았음 - 공개한 [패치](https://github.com/exlee/emacs-patches/blob/69febf1e32582bce850f008750d8bc447a7dabf9/ns_color_cache_0001.patch)는 **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개 성능 개선 패치**가 있으며, 일부는 서로 겹치고 일부는 실제 영향이 아직 입증되지 않았음 - 최근 확인해 동작하고 의미 있는 영향을 보인 일부 패치만 [공개](https://github.com/exlee/emacs-patches)했으며, 그는 해당 패치들이 실제로 차이를 만든다고 말함 ## Comments ### Comment 60397 - Author: neo - Created: 2026-06-26T23:04:14+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/omq8rt/vibecoding_gets_emacs_patch_rejected) - "open weight"의 **open**이 무슨 뜻인지 저자가 오해한 것 같음 최종 행렬 덩어리가 공개되어 있고 어느 정도 미세조정할 수 있다고 해서, 그걸 만드는 데 쓴 학습 자료까지 오픈소스였다는 뜻은 아님. [OSI seems to agree](https://opensource.org/ai/open-weights)도 비슷하게 보는 듯하고, 그렇다면 저작권 문제는 전혀 해결된 게 아님 선의로 대가 없이 기여하려는 사람에게 공감은 가지만, GNU는 규칙을 명확히 적어두었고 거기에 가서 "조금만 어겼고, 여기 패치가 있다"고 하면 거절당해도 이상하지 않음. 거절된 이유는 정직함이 아니라, 명시적으로 하지 말라고 한 일을 했기 때문임 - 비공개 계약이 걸린 데이터시트를 바탕으로 작성된 드라이버도 전부 자유 소프트웨어가 아닌 건가? 제조사 직원이 내부 문서와 전문 지식을 활용해 드라이버를 작성한 경우는 또 어떻게 봐야 하나? - 학습 자료가 왜 관련 있는지 잘 모르겠음. 산출물을 자유롭게 사용, 재배포, 수정할 수 있다면 꽤 **open**에 가깝다고 봄 - 수십억 명이 틀릴 수도 있다는 걸 저자가 오늘 배우면 좋겠음. [Normalization of deviance](https://en.wikipedia.org/wiki/Normalization_of_deviance)는 일탈을 정당화하지 않고, 그 일탈이 계속 퍼지는 방식을 설명할 뿐임 [chatbot psychosis](https://en.wikipedia.org/wiki/Chatbot_psychosis)에서 보이는 패턴 중 하나는 반대하거나 다른 의견을 내는 인간을 적대자로 인식하는 것임. 챗봇이 학습한 [narremes](https://en.wikipedia.org/wiki/Narreme)에는 사용자가 주인공이고, 어깨너머 카메라와 읽기 쉬운 개인 서사를 가진다는 관점이 포함되어 있음. 챗봇의 후처리된 선호 서사가 사용자에게 주인공 의식을 강화하면서 직접 영향을 주고, 사용자가 충분히 이온화되면 중립적 입장도 받아들이지 못하게 됨 이 경우 저자가 링크하거나 인용하지 않은 [the original discussion](https://lists.gnu.org/archive/html/emacs-devel/2026-06/msg00515.html)를 읽어보길 권함. 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 산출물을 둘러싼 **저작권과 법적 쟁점**을 보면, 그건 매우 순진한 관점임