운영체제는 여러 프로그램이 공유하도록 만든 가상 머신임. 보통은 자신이 실행되는 명령어 집합 구조(ISA)의 대부분을 노출하지만 Inferno, Taos, AS/400 같은 예외도 있음

LISP 머신이 성공했더라도 그 위에서 실행되는 편집기가 운영체제가 되지는 않음. 플랫폼과 운영체제를 혼동하면 웹 브라우저나 심지어 Roblox까지 운영체제라고 부를 수 있게 됨

client, server, request를 충분히 넓게 정의하면 무엇이든 클라이언트/서버 구조에 끼워 맞출 수 있음. LISP 함수가 한 가지 일을 잘 수행한다는 이유만으로 Emacs가 Unix 철학을 따른다고 애써 주장하던 것과 비슷함
Emacs가 LISP 머신의 발상을 따른다는 데는 대부분 동의할 수 있고, 그 위에서 사실상 원하는 무엇이든 구현할 수 있음. CLI 도구와 훌륭하게 연동되지만 이를 클라이언트/서버라고 정의해서 무엇을 얻는지는 불분명함
수십 년간 여러 유행을 거치며 기능을 흡수해 왔고, 내부에는 지금 거의 쓰이지 않는 CEDET 의미 분석 엔진도 있음. 이후 LSP가 등장했고, 이제는 에이전트 시대인데 Emacs는 에이전트용 프런트엔드로도 꽤 괜찮음

Emacs는 Unix 세계로 피신한 LISP 난민임. Unix 철학이 아니라 LISP 철학을 따르지만 Unix와 잘 통합됨

과거에는 대부분의 IDE가 자체 의미 분석 엔진을 갖는 것이 흔했음. 최초의 Java 언어 서버도 Eclipse의 Java 의미 분석 엔진에서 분리돼 나온 것으로 기억함

Emacs를 25년 넘게 사용했지만 지난해 이직한 회사에서는 Emacs가 특히 잘 맞는 작업에도 쓰지 못하게 함. 모든 팀원이 같은 도구를 써야 한다는 이유였고, 다른 사람들을 Emacs로 전환시키는 데는 실패함
이제 작업마다 별도의 단일 목적 도구를 훨씬 비효율적으로 사용하면서 새로운 UI와 키 매핑까지 계속 익히는 중임

회사가 커지면서 설치 소프트웨어를 통제하기 시작했고, Microsoft Intune으로 설치 허용·차단을 관리하는 듯함. Emacs를 더는 쓰지 못할까 봐 노트북 업데이트나 교체도 미루고 있음
관리자는 새 프로젝트에서 모두 Visual Studio Code를 쓰자고 하겠지만, 사용하는 소비 모델은 VSCode도 지원하지 않음. Git과 배포 절차만 맞춘다면 편집기는 각자 잘 쓰는 것을 선택해도 되는데, Microsoft가 지원하지 않는 오픈 소스라 위험하고 회사가 검증하지 않은 소프트웨어라는 답이 돌아올 것 같음
Emacs는 매일 쓰는 핵심 도구라 금지된다면 사직할 생각임. 관리자는 이해하거나 논리적으로 판단하려는 게 아니라 다른 IT 부서의 지시를 따를 뿐임

모든 팀원에게 telnet을 쓰게 하고 ssh를 금지해도 타당하다고 할 것인가? Emacs 사용 허가를 묻지 말고 그냥 쓰는 것이 중요함
회사가 범용 텍스트 편집기를 지정했다면 Notepad를 실행해도 문제가 되는지, 개인용 할 일 관리 도구까지 지정했는지 확인해볼 만함. Emacs가 수행할 수 있으면서 아직 회사가 도구를 지정하지 않은 범주를 찾아 그 용도로 설치하면 됨

서로 다른 성격을 관리하려면 사람마다 다르게 대해야 해서 비효율적이니, 팀원 전원에게 전두엽 절제술을 시행했다는 논리와 같음

다른 도구에도 Emacs만큼의 자유와 개조 가능성이 있었다면 Emacs 사용자도 모든 업무를 그 안에 욱여넣으려 하지 않았을 것임. Emacs가 무조건 우월하다기보다 다른 도구가 더 제한적이고 자체 문서화가 부족함

모든 팀원이 같은 도구를 써야 한다는 주장이 왜 타당한지 의문임

Emacs는 플랫폼이고 운영체제 역시 여러 플랫폼 중 하나임. 플랫폼은 그 위에 새로운 것을 만들 수 있도록 설계된 소프트웨어 계층이므로, 만들려는 Y에 어떤 플랫폼 X가 적합한지를 물어야 함
내게 X는 Emacs일 때가 많지만 Racket이나 Rust일 수도 있음. 응용 프로그램이면서 좋은 플랫폼이기도 한 도구라면 단순한 응용 프로그램보다 더 많은 학습 투자를 할 가치가 있음

Emacs를 충분히 사용해 “Emacs는 운영체제다”라는 말을 농담이 아니라 실제로 믿을 수 있는 개념으로 이해한 순간이 경력의 중요한 전환점이 됨

이미 운영체제도 있었고 프로그래밍도 할 수 있었는데 Emacs가 정말 새로운 능력을 제공했는지는 의문임. Emacs는 IDE나 범용 자동화 실행 환경이 아니라 텍스트 편집기인데, MSPaint에 Lisp를 추가한다고 갑자기 대단한 도구가 된다는 논리는 이해하기 어려움

org mode를 써보려고 몇 년 전 Emacs를 시작했고, 극단적으로 높은 유연성 때문에 계속 사용하게 됨

한동안 Spacemacs를 사용했지만 Caps Lock을 재프로그래밍할 수 있는 Keychron G6 Pro를 구했으니, 이제 본격적으로 init.el을 직접 구성해볼 생각임

Emacs는 텍스트 편집기가 내장된 프로그래밍 환경에 더 가까움. 일부 Smalltalk 이미지와 비슷하다고 보면 꽤 흥미로운 도구임

Emacs는 운영체제가 아니라 셸에 가깝지만, 셸이라는 개념 자체가 널리 이해되지는 않음

셸을 다른 도구를 사용하는 수단으로 본다면 vi가 오히려 셸에 더 가까움. 많은 기능을 :.!로 다른 표준 Unix 프로그램에 맡겨야 하기 때문임
반면 Emacs는 운영체제처럼 온갖 기능을 하나의 거대한 배포판에 포함

Emacs 자체를 클라이언트와 서버로 실행할 수 있음. emacs --daemon으로 서버를 시작한 뒤 emacsclient로 연결하면 터미널과 GUI의 모든 인스턴스가 같은 서버를 사용하며 열린 파일과 버퍼를 공유함
아쉽게도 로컬에서만 동작했고, Emacs 서버 소켓을 ssh로 전달해 원격 클라이언트에서 연결하려 했지만 실패함

돌이켜 보면 emacsclient라는 이름은 좋지 않았음. 2026년에 Emacs를 처음 접하는 사람은 REST 클라이언트처럼 네트워크를 통해 클라이언트와 서버의 실행 상태를 동기화한다고 기대하기 쉬움
여기서 클라이언트와 서버는 Unix 로컬 도메인, 즉 파일 시스템 소켓을 통해 클라이언트가 간단한 제어 명령을 보내는 구조를 뜻함. 이후 네트워크 소켓도 지원하게 됐지만 클라이언트가 보내는 것은 여전히 단순한 제어 명령뿐임

소켓 전달은 안 되지만 X11을 사용한다면 ssh -X로 원격 Emacs의 프레임을 로컬 X 서버에 띄울 수 있음. 단, 비-PGTK GTK 빌드에서는 새 프레임을 닫을 때 원격 Emacs가 충돌할 수 있으니 주의해야 함