Emacs도 보안이 필요해 — '신뢰할 수 있는 Emacs'를 향한 새로운 제안

무슨 일이 있었나요

Eshel Yaron이라는 개발자가 "Towards Trust in Emacs(Emacs에서의 신뢰를 향하여)"라는 글을 공개했어요. Emacs는 1970년대부터 이어져 온 전설적인 텍스트 에디터인데, 사실 에디터라기보다 "Lisp 인터프리터 위에 텍스트 편집 기능이 얹힌 운영체제"에 가까워요. 그만큼 강력하지만, 동시에 보안 측면에서는 굉장히 위험한 면이 있거든요. 이 글은 그 문제를 정면으로 다루고 있어요.

왜 지금 이 이야기가 중요한가? 요즘 개발자들은 GitHub에서 남의 설정 파일(dotfiles)을 가져다 쓰거나, MELPA 같은 패키지 저장소에서 수많은 확장을 설치해서 써요. 그런데 Emacs는 이 모든 코드를 "내가 쓴 코드와 똑같은 권한"으로 실행해버려요. 악성 패키지 하나만 설치해도 내 SSH 키, 브라우저 쿠키, GPG 비밀키까지 다 털릴 수 있다는 뜻이에요.

핵심 내용 — 신뢰 모델이 뭐가 문제인가

현재 Emacs의 동작 방식을 한번 풀어볼게요. 여러분이 .emacs 파일이나 init.el 파일을 만들면, Emacs가 시작할 때 그 파일에 적힌 Lisp 코드를 모두 실행해요. 패키지를 설치하면 그 패키지의 코드도 같은 방식으로 실행되고요. 심지어 다른 사람이 보낸 텍스트 파일에 "파일 로컬 변수(file-local variables)"라는 게 들어 있으면, 그것도 코드로 실행될 수 있어요.

이게 뭐냐면, 모든 코드가 "동일한 신뢰 수준"으로 돌아간다는 거예요. 내가 직접 작성한 함수와 어제 처음 설치한 낯선 패키지가 똑같이 모든 권한을 가져요. 파일을 읽고, 네트워크에 접속하고, 셸 명령을 실행하고, 다른 함수를 재정의(redefine)하는 것까지 다 가능해요. 이걸 보안 용어로는 "권한 분리(privilege separation)가 없다"고 표현해요.

Yaron이 제안하는 방향은 "코드마다 신뢰 등급을 나누자"는 거예요. 예를 들어 내가 직접 쓴 코드는 fully trusted, 잘 알려진 패키지는 partially trusted, 처음 보는 외부 코드는 untrusted로 분류하는 거죠. 그리고 untrusted 코드는 샌드박스 안에서만 실행되도록 제한해요. 파일 시스템 접근을 막고, 네트워크 호출을 차단하고, 핵심 함수 재정의를 금지하는 식으로요.

구현 측면에서는 Emacs Lisp 인터프리터 자체에 손을 대야 해서 쉬운 일이 아니에요. 함수 호출 시점마다 "호출자의 신뢰 등급"을 확인하고, 위험한 동작은 거부해야 하거든요. 이걸 캐퍼빌리티 기반 보안(capability-based security)이라고 부르는데, 어떤 권한을 명시적으로 가진 코드만 그 동작을 할 수 있게 만드는 모델이에요.

업계 맥락 — 다른 도구들은 어떻게 하고 있나

비교 대상으로 떠올리기 좋은 게 VS Code예요. VS Code는 'Workspace Trust'라는 기능이 있어서, 처음 보는 폴더를 열면 "이 작업 공간을 신뢰합니까?"를 물어봐요. 신뢰하지 않으면 자동 실행 작업이나 디버거 설정 같은 위험한 기능이 막혀요. 또 확장 프로그램은 별도 프로세스에서 돌아가서, 일정 수준의 격리가 있어요.

Vim/Neovim도 비슷한 흐름이에요. Neovim은 외부 플러그인을 LSP나 별도 프로세스로 띄워서 쓰는 게 일반적이라, 적어도 텍스트 편집기 본체와는 분리돼 있어요. 반면 Emacs는 모든 게 한 프로세스 안에서 같은 Lisp 환경을 공유해서 돌아가요.

웹 브라우저는 이 영역에서 가장 앞서 있는 사례예요. 브라우저는 사이트마다 별도 프로세스로 격리하고, 권한도 카메라/마이크/위치 등 종류별로 따로 받죠. Emacs도 결국 이런 방향으로 진화해야 한다는 게 이번 글의 큰 그림이에요.

한국 개발자에게 주는 시사점

Emacs를 안 쓰는 분이라도 이 이야기는 의미가 커요. 왜냐하면 우리가 매일 쓰는 도구들 — VS Code 확장, npm 패키지, pip 패키지, vim 플러그인 — 전부 동일한 보안 문제를 갖고 있거든요. 작년에도 npm에서 악성 패키지가 발견돼서 수많은 개발자의 환경 변수가 유출된 사건이 있었죠.

실무에서 바로 적용할 수 있는 교훈은 이거예요. 첫째, 처음 보는 패키지는 일단 의심하고, 다운로드 수나 메인테이너 이력을 확인하는 습관을 들이세요. 둘째, 개발 환경을 컨테이너나 별도 사용자 계정으로 격리하는 것도 고려해보세요. 셋째, 프로덕션 자격증명(예: AWS 키)은 절대 개발용 머신에 평문으로 두지 마세요. 도구 하나가 뚫리면 다 같이 뚫리거든요.

Emacs 사용자라면 이번 제안이 어떻게 진화하는지 지켜볼 만해요. 만약 신뢰 등급 시스템이 들어온다면, 패키지 설치 경험이 꽤 달라질 거예요.

마무리

50년 넘은 에디터에 현대적 보안 모델을 얹는 일은 쉽지 않지만, 꼭 필요한 일이에요. 우리가 쓰는 도구의 신뢰 모델을 한 번쯤 점검해볼 좋은 계기예요.

여러분이 쓰는 에디터의 확장 프로그램, 마지막으로 코드를 직접 들여다본 게 언제인가요?