어느 순간, 개발자들의 대부분이 “패키지 매니저를 쓰면 편리하다”는 말에 동조하지만, 한 개인이 35개의 모듈만으로 완전한 에디터 환경을 구축하고, 외부 패키지를 전혀 사용하지 않은 사례가 있음을 상상해 보라. 이 글은 그러한 사례의 두 해를 다루며, 그 안에서 드러난 디자인 철학과 실제적인 장단점을 탐구한다.
첫 번째 눈에 띄는 점은 “모듈 수”다. 35개의 모듈이란 숫자는 대부분의 사람들이 일상적으로 접하는 Emacs 패키지 한두 개를 넘어서지만, 그 수가 많다고 해서 복잡함을 의미하지 않는다. 오히려, 각 모듈이 명확한 책임 범위를 갖고 서로 독립적으로 동작하도록 설계되었기 때문에, 전체 시스템은 일종의 단일 원소로 느껴진다. 이는 마치 대형 주택에서 각각 다른 방에 전문 인테리어를 맡긴 뒤도 전체가 하나의 흐름으로 연결되는 것과 유사하다.
이러한 설계는 “외부 패키지 없이”라는 선언을 통해 더욱 강조된다. 외부 의존은 종종 버전 충돌, 보안 취약점, 그리고 업데이트 주기에 따른 불확실성을 낳는다. 한편으로는 개발자가 직접 코드를 작성하고 관리함으로써, 자신이 필요로 하는 기능만 골라내어 최적화할 수 있는 자유도 제공한다. 이는 특히 장기적으로 유지보수를 생각했을 때, 의존성 그래프가 작아지면 작은 변화에 대한 파급 효과를 최소화할 수 있다는 점에서 유리하다.
하지만 이 접근법이 전혀 단점이 없다는 것은 아니다. 첫째, 초기 개발 비용이 상당히 높다. 외부 패키지를 바로 끌어쓰는 대신 필요한 기능을 직접 구현해야 하므로 시간과 노력이 필요하다. 둘째, 커뮤니티에서 제공하는 방대한 자료와 플러그인을 활용할 수 있는 유연성이 줄어든다. 이 부분은 “독립적”이라는 가치가 얼마나 중요하냐에 따라 평가가 달라질 것이다.
두 번째 주목할 만한 점은 “완전 재구성”이다. 기존 코드를 한 번에 다 바꾸는 것은 흔히 위험을 동반하지만, 이 사례에서는 단계적으로 모듈을 교체하고 기능을 검증하며 진행되었다. 그 결과, 초기 설계에서부터 보편적인 패턴과 일관된 스타일이 유지되어 가독성과 유지보수성이 크게 향상되었다.
이러한 경험은 Emacs라는 도구가 단순히 텍스트 편집기를 넘어서는 “개발 환경”으로서의 잠재력을 보여준다. 한 사람의 손에 의해 35개의 모듈로 완성된 에디터는, 마치 소규모 팀이 공동으로 구축한 오픈소스 프로젝트처럼 느껴진다. 외부 의존을 최소화하면서도 기능을 충분히 제공하는 것은 단순히 기술적 선택이 아니라, 사용자가 자신만의 작업 흐름을 정밀하게 조정할 수 있는 자유를 주는 일종의 철학이다.
마지막으로, 이 사례가 우리에게 던지는 질문은 “필요한 것과 불필요한 것은 언제 구분되는가?”라는 것이다. 패키지를 사용하면 빠르게 기능을 추가하고 커뮤니티와 함께 성장할 수 있다. 반면, 직접 구현하고 관리한다면 그만큼 책임이 늘어나며, 그 책임을 감당할 준비가 되어 있어야 한다. 결국 선택은 개인의 가치관과 프로젝트의 목표에 따라 달라진다.
Emacs를 두 해 동안 독자적으로 운영하며 얻은 통찰력은, 단순히 한 개인의 개발 여정을 넘어, “도구를 어떻게 바라보고 활용하느냐”는 관점에서 우리 모두가 다시 생각해볼 필요가 있다. 그 과정 속에서 우리는 기술이 아닌, 인간 중심의 설계와 책임감이라는 가치를 재확인하게 된다.
원문 링크: https://www.rahuljuliato.com/posts/emacs-solo-two-years
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
