Human Emacs

• Human Emacs는 GNU의 최종 정책과 무관하게 LLM 생성 기여를 받지 않는 Emacs를 사용하고 개발하겠다는 참여자들의 선언임
• GNU Emacs의 현재 금지는 모든 GNU 패키지에 적용할 GNU 공통 정책이 확정될 때까지만 유지되는 예방적 임시 조치임
• GNU가 LLM 생성 기여를 허용하면 과거 Emacs 포크의 갈등과 낮은 성공 가능성을 감수하고서라도 별도의 LLM 비사용 Emacs를 유지할 방침임
• LLM 성능이나 공개 가중치 모델은 핵심 쟁점이 아니며, 출처를 속인 LLM 생성 패치는 기존 표절 사례와 같은 방식으로 다룰 수 있다고 봄
• GNU 공통 정책이 허용하더라도 Emacs 유지보수자가 더 엄격한 추가 정책을 둘 수 있으므로, 현재의 임시 금지를 영구화할 수 있다는 입장임

---

Emacs가 GNU 공통 정책을 우려하는 이유

• Emacs는 윤리적 원칙을 훼손하지 않으면서 사용자의 역량을 강화하는 자유 소프트웨어 프로젝트이며, 참여자들은 앞으로도 선의로 사용하고 기여할 수 있기를 원함
• 참여자들은 2026년 들어 신뢰해 온 소프트웨어 프로젝트들이 잇달아 LLM 기반 개발을 채택했다고 봄
  • Vim과 rsync도 LLM 기반 개발을 적극적으로 받아들이면서 핵심 사용자층을 소외시켰다고 평가함
  • 그 결과 나타난 포크 사례로 vim-classic을 들고 있음
• GNU Emacs 지도부는 현재 LLM 생성 기여를 받지 않고 있음
  • emacs-devel 논의에 따르면, GNU 프로젝트가 모든 GNU 패키지에 적용할 정책을 정할 때까지 유지되는 예방 조치임
  • Emacs 프로젝트만의 결정이 아니라 GNU 전체 차원에서 정할 사안이라는 입장임
• 참여자들은 향후 GNU 정책이 GNU가 역사적으로 유지해 온 높은 윤리적 기준에 미치지 못할 가능성을 우려함
  • LLM의 부정적 외부효과가 크다고 보지만 아직 명확한 정책 방향이 나오지 않았고, 최종 정책이 관련 문제를 막지 못할 수 있다고 걱정함

LLM 생성 기여가 없는 Emacs 유지 방침

• GNU가 어떤 정책을 선택하더라도 LLM 생성 기여가 없는 Emacs를 사용하고 개발할 계획임
  • GNU가 비용을 고려해 같은 결정을 내리면 계속 지원함
  • GNU가 다른 결정을 내리면 결과물이 GNU Emacs가 아니더라도 별도 버전을 유지함
• Emacs 포크는 역사적으로 큰 논쟁을 불렀고 항상 성공한 것도 아니어서, 참여자들 역시 포크 가능성을 가볍게 받아들이지 않음
• 그러나 GNU Emacs가 LLM 생성 기여를 허용한다면 선택지가 많지 않다고 봄
  • 많은 참여자에게 Emacs를 포기하는 일은 컴퓨팅 전체, 또는 컴퓨팅에서 즐거움을 주는 부분을 포기하는 것과 비슷함
• GNU의 상위 정책이 문제를 다루지 않더라도 Emacs 유지보수자는 그 위에 추가 정책을 마련할 수 있다고 봄
  • GNU 공통 정책과 충돌하지 않는 범위에서 현재의 임시 금지를 영구 정책으로 전환할 수 있다는 입장임

인간이 만드는 소프트웨어를 지키려는 근거

• Guix 합의 문서 Standing up for human crafting는 Emacs처럼 의존도가 높은 프로그램에 이런 정책이 필요한 이유를 상세히 다룸
• 참여자들은 LLM의 피해가 충분히 분명하다고 보고, 같은 근거를 다시 열거하는 대신 이 문서를 참고 대상으로 삼음
• 다만 Guix는 Emacs처럼 임시 금지 조치를 먼저 마련하지 않아 정책에 일부 예외를 남길 수밖에 없었다고 평가함

핵심 논의에서 제외한 쟁점

• LLM의 성능

  • LLM이 주장된 기능을 실제로 얼마나 잘 수행하는지는 논의 대상이 아님
  • 성능과 별개로 LLM 사용이 사용자 역량 강화를 지향하는 원칙 있는 소프트웨어 운동에 포함될 수 있는지를 문제로 삼음

• 공개 가중치 모델

  • 공개 가중치 모델도 대안으로 다루지 않음
  • 이런 모델 역시 기업이 데이터센터를 통해 웹 데이터를 파괴적으로 수집하고 지역사회에 피해를 주는 기반 위에서 만들어진다고 봄
  • 최종 사용자가 동의를 받아 수집한 데이터로 모델 전체를 직접 학습할 수 있을 때에만 논의할 수 있으며, 현재로서는 공상과 추측의 영역으로 판단함

• 패치 출처를 속이는 기여

  • 악의적인 기여자가 패치의 출처를 숨길 가능성도 별도 쟁점으로 보지 않음
  • 기여자가 패치의 라이선스나 저작권 문제를 속일 위험은 이전부터 존재해 왔음
  • LLM 생성 패치를 다른 형태의 표절과 같은 방식으로 다루면 충분하다고 봄

논의 참여와 운영

• 논의는 메일링 리스트와 Libera Chat의 #human-emacs 채널에서 진행함
  • 메일링 리스트에 가입하지 않아도 글을 보낼 수 있음
• 서명에 이름과 선택적인 URL을 추가하려면 메일링 리스트에 게시하거나 #human-emacs 채널에서 요청하면 됨
• 사이트의 소스 코드도 공개되어 있음

[GN⁺]

Lobste.rs 의견들

• Emacs 사용자는 아니지만, 핵심 개발 도구를 저품질 AI 생성물과 그 추종자들로부터 지키겠다는 단호한 선언을 보니 든든함

• 앞으로의 GNU 정책이 역사적으로 지켜 온 높은 윤리적 기준을 Emacs에도 유지하지 못할 수 있다는 우려는 왜 생긴 것인가? GNU가 결국 대부분 비자유 모델인 LLM을 자사 소프트웨어에 허용하려는 것인가?

  • 충분히 타당한 질문임. 여기서는 올바른 대응이 매우 명확하고 쉬운데도 GNU가 아직 실행하지 않았다는 사실부터 첫 번째 위험 신호로 보임
    다른 GNU 프로젝트에서도 윤리적 행동에 기반한 정책에 상당한 반발이 있으며, GNU 프로젝트 중 지도부를 가장 신뢰하는 Guix조차 아직 대응 방안을 논의하고 있음: https://codeberg.org/guix/guix-consensus-documents/pulls/13
    GNU는 역사적으로 다른 모든 요소를 희생하면서까지 라이선스와 저작권에만 근시안적으로 집중해 왔음. LLM 지지자들이 라이선스상 문제가 없다는 논리를 만들면, GNU가 그 너머에 있는 수많은 문제를 더는 논의하지 않을까 우려됨
    물론 GNU가 올바른 결정을 내려 이 모든 준비가 불필요해질 수도 있으며, 그것이 우리가 바라는 최선의 결과임
  • 그럴 가능성은 낮아 보임. FSF 관계자들에게 들은 바로는 이 사안을 매우 신중하게 다루고 있음
    GNU 철학에서 LLM은 적어도 명시적으로는 윤리 문제가 아니며, 많은 자유 소프트웨어 개발자는 별개로 윤리적 이유에서 LLM에 반대함. 더 직접적인 우려는 LLM 생성 코드가 저작권 보호를 받지 못해 카피레프트를 무효화할 수 있다는 데 있음
    이미 너무 많은 프로젝트가 LLM을 받아들이는 모습을 봤으므로, 실제로 벌어지기 전에 대비할 필요가 있음

• rsync가 LLM을 적극 도입했다고 하지만, 최근에는 LLM 특유의 흔적 때문에 rsync 기여가 거절됐다는 내용을 읽지 않았나?

  • 다른 프로젝트와 혼동한 것 같음. 최근 게시물에서는 그런 내용을 찾지 못했지만, rsync가 LLM을 사용했다는 사실은 확인했음

• Emacs는 GNU가 결정을 내릴 때까지 LLM 생성 기여를 받지 않고 있으므로, 이 선언은 다소 앞서 나간 태도로 보임

  • 해당 페이지도 그 사실을 전제로 작성됐으며, 세 번째 문단쯤에서 직접 다루고 있음

• LLM은 이전에는 개선하기 어려웠던 영역에서 Emacs를 발전시킬 수 있음. 이미 많은 작업이 필요했던 매우 복잡한 버그와 추상화 계층을 개선한 전례도 있음

  • 이 움직임의 동기는 전적으로 윤리에 있음
    ‘논의하지 않는 사항’ 절에서 밝히듯, LLM이 주장만큼 효과적인지는 논점이 아님. 핵심은 LLM 사용이 사용자 권한 강화를 지향하는 원칙 있는 소프트웨어 운동의 일부가 될 수 있느냐는 것임