2026년에 Common Lisp를 개발한다면 — 현대적 개발 도구 생태계 톺아보기

왜 지금 Common Lisp 개발 환경을 이야기하는가

Common Lisp는 1984년에 표준화된 프로그래밍 언어입니다. 40년이 넘은 언어라고 하면 대부분 "아직 쓰는 사람이 있어?"라고 반응할 수 있지만, 실제로 Common Lisp는 꾸준히 특정 도메인에서 활용되고 있으며 그 개발 도구 생태계도 계속 진화하고 있습니다. 최근 공유된 Common Lisp 개발 도구에 대한 심층 가이드는 이 언어의 현재 개발 경험이 어떤 모습인지를 잘 보여줍니다.

Common Lisp가 흥미로운 이유는 이 언어가 제공하는 개발 경험이 현대 언어들이 이제서야 따라잡고 있는 개념들을 이미 수십 년 전에 구현했기 때문입니다. REPL 기반 개발, 핫 리로딩, 인터랙티브 디버깅, 매크로 시스템 — 이 모든 것이 Common Lisp에서는 언어 수준에서 지원됩니다.

SLIME과 SLY: Emacs 기반의 강력한 IDE 경험

Common Lisp 개발의 중심에는 SLIME(Superior Lisp Interaction Mode for Emacs)이 있습니다. SLIME은 단순한 에디터 플러그인이 아닙니다. 실행 중인 Lisp 프로세스에 직접 연결하여, 코드를 작성하면서 동시에 실행하고, 결과를 확인하고, 함수 정의를 수정하면, 재시작 없이 즉시 반영되는 환경을 제공합니다.

이것이 일반적인 "파일 저장 → 재빌드 → 재실행" 사이클과 근본적으로 다른 점입니다. Python이나 JavaScript에서 REPL을 사용해본 개발자라면 어느 정도 비슷한 경험을 떠올릴 수 있지만, Common Lisp의 REPL은 차원이 다릅니다. 실행 중인 프로그램의 어떤 부분이든 검사하고 수정할 수 있으며, 에러가 발생하면 디버거가 뜨면서 콜 스택의 각 프레임에서 변수를 검사하고, 값을 바꿔서 실행을 재개할 수도 있습니다. 이런 "조건부 재시작(restart)" 시스템은 Common Lisp만의 독보적인 기능입니다.

SLY는 SLIME의 포크로, 더 현대적인 인터페이스와 몇 가지 개선된 기능을 제공합니다. 스텐실 기반 REPL, 더 나은 자동 완성, 향상된 트레이스 기능 등이 특징입니다. 두 도구 모두 활발하게 유지보수되고 있으며, 선택은 대체로 개인 취향의 문제입니다.

Emacs 너머: 다양한 에디터 지원

Common Lisp 개발이 반드시 Emacs를 요구하는 것은 아닙니다. VSCode에서는 Alive 확장이 LSP(Language Server Protocol)를 통해 Common Lisp 지원을 제공합니다. 코드 자동완성, 정의로 이동, 인라인 평가 등 현대적 IDE에서 기대하는 기능들을 사용할 수 있습니다. Vim/Neovim에서는 Vlime이라는 플러그인이 SLIME과 유사한 경험을 제공합니다.

빌드 시스템으로는 ASDF(Another System Definition Facility)가 사실상 표준입니다. 현대 언어의 패키지 매니저와 빌드 도구를 합쳐놓은 것과 비슷한 역할을 합니다. 라이브러리 관리에는 Quicklisp가 오랫동안 쓰여왔으며, 최근에는 Ultralisp 같은 대안적 배포판도 등장하고 있습니다. Quicklisp의 등장은 Common Lisp 생태계에 큰 전환점이었는데, "라이브러리 설치가 너무 어렵다"는 오래된 불만을 해소했기 때문입니다.

현대 언어들이 Lisp에서 가져간 것들

흥미로운 관점은 현대 프로그래밍 언어 트렌드를 Common Lisp의 렌즈로 바라보는 것입니다. 요즘 "핫 리로딩"은 프론트엔드 개발에서 혁신적인 기능으로 소개되지만, Common Lisp 개발자들은 1980년대부터 이것을 당연한 기능으로 사용해왔습니다. Clojure의 REPL 기반 개발, Elixir의 핫 코드 스왑, 심지어 Jupyter Notebook의 셀 단위 실행까지 — 이들의 원류를 추적하면 Lisp 계열 언어의 인터랙티브 개발 모델에 닿습니다.

매크로 시스템도 마찬가지입니다. Rust의 proc_macro, Elixir의 매크로, 심지어 TypeScript의 데코레이터까지 — 컴파일 타임에 코드를 생성하고 변환하는 메타프로그래밍의 아이디어는 Lisp의 매크로에서 출발했습니다. 다만 Common Lisp의 매크로는 이들보다 훨씬 강력합니다. Lisp에서는 코드 자체가 데이터(리스트)이기 때문에, 매크로가 코드를 다루는 데 별도의 특수 구문이 필요 없습니다. 이것이 "homoiconicity(동형성)"라는 Lisp의 핵심 특성입니다.

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

Common Lisp를 실무에서 바로 도입하라는 이야기가 아닙니다. 하지만 이 언어의 개발 도구가 제공하는 경험을 이해하면, 여러분이 사용하는 언어에서도 더 나은 개발 워크플로우를 만들 수 있습니다.

REPL 기반 개발을 진지하게 활용해보세요. Python, Node.js, Clojure 등 REPL을 제공하는 언어를 사용한다면, 단순히 한 줄씩 실행하는 것을 넘어 실행 중인 프로세스에 연결하여 개발하는 워크플로우를 시도해보세요. Clojure를 배워본다면 Common Lisp의 사상을 JVM 위에서 현대적으로 경험할 수 있습니다.

프로그래밍 언어의 계보를 이해하면 더 나은 개발자가 됩니다. 새로운 프레임워크의 기능이 "왜" 그렇게 설계되었는지를 이해하려면, 그 아이디어의 원류를 아는 것이 도움됩니다. Common Lisp는 그 원류 중 가장 중요한 것 중 하나입니다.

마무리

40년 된 언어의 개발 도구가 여전히 현대적이라는 것은, 그 설계 철학이 시대를 초월했다는 의미입니다. Common Lisp의 인터랙티브 개발 경험은 오늘날에도 대부분의 메인스트림 언어가 완전히 재현하지 못한 영역입니다. 여러분이 사용하는 언어에서 가장 "Lisp적"이라고 느끼는 기능은 무엇인가요?