- 마츠야마 토모히로(松山朋洋) (2010/2/22)
이 문서는 마츠야마 토모히로 님의 Emacsは死んだ를 번역한 것입니다. 영문 번역은 Takafumi Arakaki님의 github.io에서 보실 수 있습니다.
이 문서는 다소 옛날에 작성된 것으로 지금의 Emacs 계와는 조금 달라진 부분들이 있습니다. 세세한 내용보다는 큰 줄기를 보고 읽어주셨으면 합니다.
무엇보다도 꽤 감상적인 제목을 붙인 것에 대해 먼저 사과드립니다. 이 기사를 조금이라도 읽어보시면, 제가 얼마나 Emacs를 사랑하고 있는지 영원히 불멸할 것이라고 생각하고 있는지 이해해주실 거라 생각합니다. 그런 점이 지나쳤기 때문에 이런 제목을 붙여버렸다고 생각합니다. 어째튼 여러분이 관대함을 갖고 봐주셨으면 합니다.
이 문서는 제가 미토 유스(未踏ユース)의 첫 발표회에 가서 했던 프리젠테이션 일부를 발췌하여 문서화한 것입니다. 제 HDD와 머리에 영원히 남겨둘 수도 있었습니다만, 혹시라도 사회적 가치가 있을 지도 모른다고 생각해서 문서화했습니다. 여러분이 재미없다고 생각하면 가치가 없을 지도 모르겠습니다만, 재밌다고 생각한다면 조금은 가치가 있을 지도 모르겠습니다. 어느 쪽이든 제 장래엔 큰 문제가 없겠죠. 광고는 이쯤해두고 본론으로 들어가봅시다.
처음부터 단언합니다만 여기서 말하는 "Emacs의 사상"이라고 하는 것은 제가 멋대로 만들어낸 것입니다. 제가 알고 있는 한, 리처드 스톨만을 포함해서 누구도 "Emacs의 사상"을 말하는 걸 본 적이 없습니다. 특히 스톨만은 그가 가진 위대한 목표인 "자유의 이상(自由の思想)"을 향한 운동을 계속해 왔기 때문에 "Emacs의 사상" 같은 작은 문제는 안중에도 없겠죠. 어째튼 말하고 싶은 점은, 후원이 없으므로 사상적 가치가 현저하게 낮다는 것입니다. 그 점만큼은 기억해주세요.
우선 말할 것도 없다고 생각하지만, Emacs의 가장 큰 특징은 Emacs Lisp입니다. Emacs Lisp는 Lisp에서 나온 갈래 중의 하나로, 솔직히 말하면 (Vim 스크립트 정도는 아니지만) Ruby나 Python과 같은 다른 동적타입 언어와 비교하여 런타임 및 라이브러리의 충실도가 크게 떨어집니다. 그래도 Emacs의 C 코어의 최소화나 Lisp 특유의 확장성 때문에 Emacs 사용자는 자신의 취향에 맞게 상당히 큰 규모로 Emacs를 변경할 수 있습니다. 혁신적인 인터페이스로 Emacs 계를 놀라게 한 anything.el이나, 최근 개인적으로 열광하고 있는 undo-tree.el는 Emacs Lisp의 토양이 없었다면 결코 실현될 수 없었을 것입니다. 그런데 방금 말씀드린 대로, Emacs Lisp는 런타임에서 우수하다고 말할 수 없습니다. 문제점은 다음과 같습니다.
- 멀티스레드 지원 불가
- 공유 라이브러리 지원 불가
- 파일입출력 같은 저수준의 API 지원 없음
이러한 문제점은 Emacs Lisp에서 고급 기능을 구현하는 데에 큰 장벽이 되고 있습니다. 예를 들어 멀티스레드 대응이 되지 않기 때문에, 사용자가 편집 작업 중에 백그라운드에서 무거운 처리를 하는 것이 쉽지 않습니다. 또, 공유 라이브러리 지원이 없기 때문에 고급 기능을 가진 공유 라이브러리를 사용할 수가 없습니다. 또, 저수준의 API가 없기 때문에 Emacs Lisp만으로는 보다 진보된 고속 프로세싱을 구현할 수가 없습니다.
이러한 문제를 해결하기 위한 일반적인 방법으로 예로부터 외부 프로그램을 사용하는 수법을 사용해 왔습니다. 예를 들어 원격 컴퓨터의 파일을 직접 편집할 수 있는 Tramp는 Emacs Lisp에서 처리하지 않고 ssh나 ftp 같은 복잡한 외부 프로그램을 Emacs 상의 편집 인터페이스에서 제공합니다. 또, 버전 관리 기능을 가진 VC는 복잡한 svn이나 git 같은 외부 프로그램을 이용하여 마치 Emacs에서 버전 관리를 할 수 있는 것처럼 보이게 합니다. 이외에도 표준탑재되고 있는 기능의 다수가 외부 프로그램에 의존하는 형태로 구현되어 있습니다. 이 수법의 훌륭한 점은, Emacs Lisp를 그 전문 분야인 사용자 인터페이스 집중하고 다른 복잡한 부분은 외부 프로그램에 맡겨버린다는 점입니다. Emacs Lisp는 런타임으로써 열등하므로 이러한 작업 분담은 큰 의미가 있습니다. 그리고 그 작업분담의 기분 좋은 부작용으로 Emacs의 뛰어난 기능을 외부 프로그램으로 정의할 수 있다는 점입니다. 한층 더 기분 좋은 점은 Emacs Lisp와 외부 프로그램의 데이터 통신은 프로세스 간 통신으로 가시화되기 때문에 엄청난 재사용성을 가집니다.
여기서 한 가지 사고실험을 해봅시다. 예를 들어 Eclipse와 Emacs에서 Ruby용 코드 자동 완성 기능을 구현한다고 쳐봅시다. Eclipse는 Java를 베이스로한 플러그인 아키텍처를 채택하고 있으며 (그 외에도 많은 제품이라고도 말할 수는 있지만) 데이터 구조를 내포하여 고효율로 처리할 수 있는 점이 훌륭합니다. 그러나 Ruby를 위한 코드 자동 완성이라는 멋진 기능을 Eclipse에서 구현하려고 한다면, 그건 Eclipse에서만 가능합니다. 시험 삼아 "Eclipse Ruby"로 검색해보세요. 일부 플러그인을 찾을 수 있지만 모두 Eclipse에서만 사용할 수 있다는 점을 알 수 있습니다. 그리고 그것들은 Eclipse와 강하게 결합하여 있기 때문에, Eclipse 이외의 플랫폼에서 사용하기 매우 어렵습니다. 설령 그것이 가능하더라도 반복되는 병합(merge) 때문에 개발자들을 지치게 만들 것입니다.
그런데 Emacs는 어떨까요. Emacs Lisp는 실제적인 이유, 런타임 문제 때문에 Eclipse와는 다르게 Emacs 위에서 직접 Ruby용 코드 자동 완성을 구현하는 건 어려워 보입니다. 그래서 거기서 외부 프로그램화를 떠올려봅시다. 외부 프로그램화는 특별한 제한이 없습니다. 자신이 좋아하는 것을 구현하여 커맨드라인 인터페이스 또는 네트워크 통신 인터페이스를 만들기만 하면 됩니다(커맨드 라인 인터페이스를 권장) 나중에 Emacs Lisp에서 그 외부 프로그램과 프로세스 간 통신, 네트워크 통신으로 원하는 기능을 구현할 수 있습니다.
이미 눈치채셨다고 생각합니다만 Eclipse와 Emacs에서의 가장 큰 차이점은 외부 프로그램화를 할 수 있는지 아닌지의 여부입니다. Eclipse에서는 이용형태가 제한되는 반면, Emacs에서는 이용형태가 Emacs만으로 제한되지 않습니다. 조금만 코드를 더 작성하면 Vim에서도 TextMate에서도 사용할 수 있게 될 것입니다. 이렇게 사회적 가치를 증대시키는 방법은 GPL과 비슷하다고 느낄 수 있습니다. 즉 개개인의 자유를 조금씩 제한하여 전체의 자유를 최대화시킨다는 겁니다.
내용을 요약하면, Emacs Lisp에서는 런타임으로써 결함이 있기 때문에 결과적으로 외부 프로그램에 의한 잠재적인 사회적 가치를 극대화하는 인센티브가 작동하기 쉬워진다고 생각할 수 있습니다. 그러나 이건 역사적 해석에 지나지 않을지도 모릅니다. 현재 (저의) 시점에서 말하자면, 역으로 사회적 가치를 극대화하기 위해 Emacs Lisp 런타임에 일부러 결함을 두었다고 말하는 편이 옳다고 생각합니다. 정확한 이야기인지 확실하지는 않지만, 아마 스톨만도 Emacs Lisp에서 공유 라이브러리를 사용할 수 있도록 하는 변경에 대해서는 단호하게 반대하고 있었던 것 같습니다. 그 이면에는 지금까지 말했던 사회적 가치의 최대화 문제가 있었을지도 모릅니다. 저는 Emacs Lisp의 의도적(인지는 모릅니다만) 제한은 소프트웨어의 사회적 가치를 증대시킨다는 "Emacs의 사상"을 근거로 하여 이것이 영원히 지켜져야 한다고 생각합니다.
컴퓨터의 성능 향상은 주목할 만한 점이 있습니다. 성능이 향상되었기 때문에 다양한 분야에서 새로운 요구사항과 연구가 생겨나고 있고 Emacs 계에서도 유래없는 새로운 물결이 도래하고 있습니다. 그중에서도 특히 언급하고 싶은 것이 js2-mode와 Semantic입니다. 먼저 js2-mode부터 말해보려 합니다.
js2-mode는 Steve Yegge라는 좀 별난 개발자에 의해 만들어진 새로운 javascript용 주 모드로써, Emacs Lisp에서 구현된 javascript 인터프리터를 가지고 있는 점이 특징입니다. 그는 Emacs가 javascript 인터프리터를 가지게 되면, 보다 인터랙티브한 오류 검사, 코드 자동 완성, 게다가 리팩토링을 할 수 있게 된다고 생각하고 있습니다. 그 기능이 제대로 구현될지는 알 수 없지만, 그의 추측은 말이 됩니다. 종래에는 구문 오류 등의 오류 검사를 기본 탑재된 Flymake라는 확장으로 구현하고 있었습니다. Flymake는 버퍼가 저장된 시점이나 자동 저장된 시점에서 적절한 오류 검사 프로그램을 기동하고, 그 결과물을 분석하여 오류가 있으면 버퍼 상의 문제 행을 하이라이트하는 단순한 구조로 되어 있습니다. (Emacs에서는 일반적이지만) 이처럼 외부 프로그램에 의존하는 경우 외부 프로그램과의 데이터 불일치 때문에 위와 같은 기능을 구현하기 어려운 경우가 좀 있습니다. 그래서 그는 그런 점을 Emacs Lisp로 작성된 javascript 인터프리터에서 커버하려고 생각하는 것입니다만, 이 아이디어는 불행히도 Eclipse와 같은 전철을 밟게 될 것입니다. 만약 js2-mode가 최고로 잘 나가는 소프트웨어가 되고 Emacs 사용자들이 고맙게 생각하게 되더라도, 그것이 Vim이나 Textmate, 다른 소프트웨어에서 사용할 수 없다면 나는 그것을 대단한 사회적 가치가 있다고 생각하지 않습니다. 만약 제가 말씀드린 "Emacs의 사상"이 옳다고 생각하신다면 이러한 배타적인 전략을 취하는 것에 동의하지 않을 것입니다. 데이터의 불일치 같은 넘어야 할 벽은 많이 있지만 우선 우리가 Emacs를 사용하고 있는 이상, 우리는 사회적 가치의 최대화를 중시해야 한다고 생각합니다.
다음으로 Semantic의 문제를 이야기하려 합니다. 이것은 js2-mode 이상으로 심각한 문제라고 생각합니다. 왜냐하면, Semantic이 모든 Emacs Lisp로 구현된 파서들을 제공하려고 하고 있기 때문입니다. 게다가 더 큰 문제는 Emacs의 메인 라인에 병합되어 다음 릴리즈에서 표준 탑재되어 버린다는 점입니다. 우선 Semantic 자체에 대해 설명해 드리죠. Semantic은 Emacs Lisp를 기술하는 파서 제너레이터 또는 파서 군이며, Semantic의 야심적인 목표로는 예를 들어 C의 코드 완성과 같은 큰 것에서부터, 태그 점프와 같은 작은 것까지 있습니다. 개발 자체는 꽤 옛날부터 조금씩 진행됐는데, Emacs와 코드 자동 완성을 검색해서 나온 문서의 대부분이 Semantic과 관련이 있습니다. 오랜 시간의 축적도 있고, 그럭저럭 잘 동작하고 있어서 여러분도 (모르는 사이에) Semantic의 기능을 사용하고 있을 겁니다. Semantic에 관하여 내가 유일하게 지지하고 있는 것은, Emacs Lisp의 텍스트 처리 능력을 눈여겨볼 수 있었다는 점뿐입니다. 그러나 겸허하게 지지하고 있는 것조차도 상기 언급한 런타임의 결함이 보기 좋게 마무리된 것뿐이므로 결국 저로서는 무엇도 지지할 수 없게 되었습니다.
그러면 Semantic의 문제로 갑시다. 상기한 바와 같이 Semantic(뿐만 아니라 그 부모패키지인 CEDET)에는 이하 두 가지의 치명적인 문제가 있습니다.
- Emacs Lisp로 작성되어 있다
- Emacs 23.2에서 표준 탑재될 예정
(1)의 문제는 js2-mode와 동일한 문제로, 요컨대 Semantic에서 실현된 가치가 Emacs로만 제한되어 있어서 사회적 가치의 증대를 도모할 수 없다는 것이 문제가 됩니다. 이것은 "Emacs의 사상"에 상반되는 것이며, Eclipse처럼 되기 위한 위험한 발걸음을 내딛고 있다는 증거입니다. 그리고 그 위험성을 몇 배나 더 증가시키는 것이 (2)의 문제로 이것은 요컨대 Emacs 개발팀이 "Emacs의 사상"을 완전히 무시했다는 것을 의미합니다. 이것은 다른 소프트웨어와의 배타행위이며, 사회적으로 도덕이 결여된 행위라고 생각합니다. 이것이 문제시되지 않고 더 진행되면, Emacs의 플랫폼은 Emacs 전용의 소프트웨어만을 만들도록 장려될 수 있습니다. Emacs의 플랫폼이 뛰어난 것은 OS와 협력하고 있기 때문이며, 그 자체가 뛰어나기 때문만은 아닙니다.
작은 것을 조합하여 큰 것을 만들어 나가는 아름다운 Unix의 전통이 Emacs에는 줄기차게 계승됐습니다. 그리고 그 아름다움이야말로 제가 Emacs를 사용하는 가장 큰 이유입니다. 그러나 이제 과거의 일이 되어 가고 있는지도 모릅니다. 아름다움과 사상이 사라지고 이익만 남은 세계에 무슨 의미가 있을까요. Emacs가 그렇게 되어 버리는 건 슬퍼도 어쩔 수 없습니다.
이것은 어려운 문제입니다. 좀 지나치게 비관적일지도 모릅니다. 어쨌튼 우리가 할 수 있는 것을 말하자면 "Emacs의 사상"에 최대한 따르는 것으로 생각합니다. 소프트웨어의 사용을 멈추는 것 같은 실력행사는 피해야 할 것입니다. 가능한 관용을 가지고 좋은 수단을 제안해가는 것이 가장 좋다고 봅니다.
이 문서는 Creative Commons Attribution-Noncommercial-No Derivative Works 3.0의 라이센스를 따르고 있습니다.