# Human Emacs

> Clean Markdown view of GeekNews topic #31416. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31416](https://news.hada.io/topic?id=31416)
- GeekNews Markdown: [https://news.hada.io/topic/31416.md](https://news.hada.io/topic/31416.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-14T09:19:39+09:00
- Updated: 2026-07-14T09:19:39+09:00
- Original source: [human-emacs.org](https://human-emacs.org/)
- Points: 1
- Comments: 1

## Topic Body

- **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](https://vim-classic.org/)을 들고 있음
- GNU Emacs 지도부는 현재 **LLM 생성 기여를 받지 않고 있음**
  - [emacs-devel 논의](https://lists.gnu.org/archive/html/emacs-devel/2026-03/msg00425.html)에 따르면, 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](https://codeberg.org/guix/guix-consensus-documents/pulls/13/files)는 Emacs처럼 의존도가 높은 프로그램에 이런 정책이 필요한 이유를 상세히 다룸
- 참여자들은 LLM의 피해가 충분히 분명하다고 보고, 같은 근거를 다시 열거하는 대신 이 문서를 참고 대상으로 삼음
- 다만 Guix는 Emacs처럼 **임시 금지 조치**를 먼저 마련하지 않아 정책에 일부 예외를 남길 수밖에 없었다고 평가함

### 핵심 논의에서 제외한 쟁점
- ## LLM의 성능
  - LLM이 주장된 기능을 실제로 얼마나 잘 수행하는지는 논의 대상이 아님
  - 성능과 별개로 LLM 사용이 사용자 역량 강화를 지향하는 **원칙 있는 소프트웨어 운동**에 포함될 수 있는지를 문제로 삼음
- ## 공개 가중치 모델
  - **공개 가중치 모델**도 대안으로 다루지 않음
  - 이런 모델 역시 기업이 데이터센터를 통해 웹 데이터를 파괴적으로 수집하고 지역사회에 피해를 주는 기반 위에서 만들어진다고 봄
  - 최종 사용자가 동의를 받아 수집한 데이터로 모델 전체를 직접 학습할 수 있을 때에만 논의할 수 있으며, 현재로서는 공상과 추측의 영역으로 판단함
- ## 패치 출처를 속이는 기여
  - 악의적인 기여자가 패치의 출처를 숨길 가능성도 별도 쟁점으로 보지 않음
  - 기여자가 패치의 라이선스나 저작권 문제를 속일 위험은 이전부터 존재해 왔음
  - **LLM 생성 패치**를 다른 형태의 표절과 같은 방식으로 다루면 충분하다고 봄

### 논의 참여와 운영
- 논의는 [메일링 리스트](https://lists.sr.ht/~technomancy/human-emacs)와 [Libera Chat](https://libera.chat/)의 `#human-emacs` 채널에서 진행함
  - 메일링 리스트에 가입하지 않아도 글을 보낼 수 있음
- 서명에 이름과 선택적인 URL을 추가하려면 메일링 리스트에 게시하거나 `#human-emacs` 채널에서 요청하면 됨
- 사이트의 [소스 코드](https://git.sr.ht/~technomancy/human-emacs.org)도 공개되어 있음

## Comments



### Comment 61758

- Author: neo
- Created: 2026-07-14T09:19:40+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/t0aqzy/human_emacs) 
- 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 기여가 거절됐다는 내용을 읽지 않았나?
  - 다른 프로젝트와 혼동한 것 같음. [최근 게시물](https://lobste.rs/search?q=rsync&what=stories&order=newest)에서는 그런 내용을 찾지 못했지만, rsync가 LLM을 사용했다는 사실은 확인했음

- Emacs는 GNU가 결정을 내릴 때까지 **LLM 생성 기여를 받지 않고 있으므로**, 이 선언은 다소 앞서 나간 태도로 보임
  - 해당 페이지도 그 사실을 전제로 작성됐으며, 세 번째 문단쯤에서 직접 다루고 있음

- LLM은 이전에는 개선하기 어려웠던 영역에서 **Emacs를 발전시킬 수 있음**. 이미 많은 작업이 필요했던 매우 복잡한 버그와 추상화 계층을 개선한 전례도 있음
  - 이 움직임의 동기는 전적으로 **윤리**에 있음  
    ‘논의하지 않는 사항’ 절에서 밝히듯, LLM이 주장만큼 효과적인지는 논점이 아님. 핵심은 LLM 사용이 사용자 권한 강화를 지향하는 원칙 있는 소프트웨어 운동의 일부가 될 수 있느냐는 것임