Emacs, 100% Lisp의 확장성은 축복인가, 저주인가?
Lisp 기반 시스템의 확장성은 강력하지만, 모든 부분을 확장하는 것은 유지보수와 호환성 문제를 야기함
Emacs의 경우, 내부 함수를 오버라이드하는 과정에서 의도치 않은 부작용과 업데이트 충돌이 발생할 수 있음
el-patch와 같은 도구를 사용해도, 근본적인 문제인 코드 변경에 따른 영향은 피할 수 없으며, 강력한 캡슐화가 필요함
Lisp 확장성의 양면성
Lisp의 유연성은 시스템의 모든 부분을 확장할 수 있는 자유를 제공하지만, 내부 함수의 변경은 예기치 않은 문제를 발생시킬 수 있다. 구체적으로, Emacs의 org-export-get-reference 함수를 오버라이드하는 과정에서, 직접 호출되는 org-html--reference 함수까지 수정해야 하는 상황이 발생한다. 따라서, 시스템의 복잡성 증가와 유지보수 어려움을 초래한다.
el-patch를 활용한 확장과 그 한계
el-patch는 Lisp 코드를 패치하여 기능을 수정할 수 있는 강력한 도구이지만, 근본적인 문제 해결은 아니다. 패치 적용은 코드의 특정 부분을 변경하는 것이므로, 시스템 업데이트 시 호환성 문제가 발생할 수 있다. 반면, el-patch-validate를 통해 패치의 유효성을 검증할 수 있지만, 모든 상황을 커버하지는 못하며, 패치 관리의 부담은 여전히 존재한다.
확장 가능한 시스템 설계의 딜레마
확장성을 높이기 위해 모든 부분을 노출하면 호환성 문제가 발생하고, 캡슐화를 강화하면 커스터마이징의 한계에 직면한다. 따라서, 시스템 설계 시 확장성과 안정성 사이의 균형을 찾는 것이 중요하다. 결과적으로, Emacs와 같이 강력한 확장성을 제공하는 시스템은 API 설계와 코드 컨벤션을 통해 무분별한 확장을 방지하고, 지속적인 관리를 위한 노력이 필요하다.
