TL;DR

  • LLM이 코드를 빠르게 작성하는 시대에는 빌드와 실행 후 피드백까지 걸리는 시간이 개발 속도를 좌우하며, Common Lisp는 이 피드백 루프를 거의 없앰.
  • 메모리상의 실행 이미지에서 함수를 즉시 교체하고, 오류가 나면 전체 스택과 변수 정보를 담은 디버거를 열어 프로그램을 재개할 수 있음.
  • 코드와 데이터가 같은 리스트 구조이고 매크로로 언어를 확장할 수 있어, 문제 영역에 맞는 도메인 언어를 만들 수 있음.
  • Common Lisp로 만든 앱은 경험상 Python 버전보다 약 6~7배 짧으며, 코드와 토큰이 줄어 LLM 개발 비용을 낮추고 컨텍스트에 더 많은 프로그램을 담을 수 있음.
  • ANSI 표준이 1994년 이후 바뀌지 않아 기반 언어가 안정적이며, 부족한 라이브러리는 LLM으로 직접 작성하거나 다른 언어에서 포팅할 수 있음.

피드백 루프가 짧은 언어

  • 여러 프로그래밍 언어 가운데 더 나은 언어가 있다면 그중 하나는 최고일 수 있으며, LLM이 코드를 작성하는 시대의 그 언어는 Common Lisp라는 주장임.
  • LLM은 코드를 매우 빠르게 작성하므로, 과거와 달리 코드 작성보다 프로그램이 실제로 작동하는지 확인하는 과정이 느린 부분이 됨. 확인 전에 프로그램을 다시 빌드해야 하며, 빌드에는 몇 분이 걸릴 수 있음.
  • 사람이 코드를 작성하던 때는 작성 시간이 컴파일과 실행을 기다리는 시간보다 훨씬 길었지만, 지금은 피드백 루프에 걸리는 시간이 개발 속도를 결정함.
  • Common Lisp에서는 읽기 시간, 컴파일 시간, 실행 시간 사이에 실질적인 구분이 거의 없으며, 이 특성은 Paul Graham의 설명에 연결됨.
  • Common Lisp는 이미지 기반 언어임. 프로그램 전체가 메모리상의 실행 이미지로 작동하므로, 함수의 새 버전이 이전 버전을 즉시 대체하고 재시작이 필요하지 않음.
  • 대부분의 언어에서는 오류가 프로그램을 중단시키지만, Common Lisp에서는 프로그램이 멈추고 전체 스택과 모든 변수 정보를 담은 디버거가 열림. LLM이 디버거 정보를 바탕으로 수정한 뒤 프로그램을 재개할 수 있음.
  • 이러한 특성을 모두 갖춘 주류 언어는 아는 한 Common Lisp뿐임.

코드와 데이터, 그리고 매크로

  • Lisp는 ‘리스트 처리(List Processing)’를 뜻하며, Common Lisp에서는 코드를 리스트로 작성함. 예를 들어 (+ 1 2)는 두 수를 더하는 프로그램인 동시에 기호 +와 숫자 1, 2로 이루어진 리스트임.
  • 코드는 데이터 저장에 쓰이는 것과 같은 종류의 리스트이며, 리스트를 다루는 언어 도구를 코드에도 적용할 수 있음. 프로그램이 다른 프로그램을 변환해 (+ 1 2)를 (* 1 2)로 바꾸고 결과를 즉시 실행할 수 있음.
  • 매크로는 코드를 받아 그 자리에 들어갈 새 코드를 반환하는 함수임. 이를 통해 언어 자체에 새로운 구문을 추가할 수 있음.
  • 언어를 확장할 수 있으므로, Lisp에서는 단순히 프로그램을 작성하는 데 그치지 않고 문제 영역에 맞는 언어를 만든 뒤 그 언어로 프로그램을 작성함.

도메인 언어와 제품의 관점

  • 프로그램의 가치를 만드는 요소는 그 안에 담긴 관점이며, LLM으로 사용자가 제품을 직접 바꾸기 쉬워지면서 소프트웨어 회사가 사용자의 제품 변경을 허용하는 방향으로 나아가고 있다는 주장임.
  • 회사가 제품을 위한 관점이 뚜렷한 도메인 언어를 만들면, 사용자가 그 위에 구축하는 결과물은 처음부터 회사의 관점을 바탕으로 하므로 더 나아질 수 있음.
  • ERP는 회사마다 운영 방식이 조금씩 달라 거의 모든 회사가 변경을 필요로 하는 사례임. ERP가 자체 도메인 언어로 작성돼 있다면 LLM에 해당 언어로 변경을 요청할 수 있음.
  • 이 변경은 도메인 언어의 기반 관점을 자연스럽게 따르므로 제품을 깨뜨리는 대신 제품에 맞게 작동함.

코드 규모와 LLM 비용

  • 매크로를 사용하면 반복 패턴을 추상화해 언어 자체의 일부로 만들 수 있으므로 Lisp 프로그램은 흔히 훨씬 간결함. 프로그램이 커질수록 코드 길이 차이도 커짐.
  • 직접 구축한 Common Lisp 앱은 Python 버전보다 약 6~7배 짧은 경험적 사례임.
  • LLM 사용에서는 코드가 적을수록 토큰이 줄어듦. 토큰 사용량이 비용을 결정하므로 개발 비용도 낮아짐.
  • 프로그램에서 더 큰 부분을 LLM의 컨텍스트 창에 넣을 수 있음. 전체 프로그램이 컨텍스트에 들어가면 LLM이 의도를 온전히 파악해 더 나은 결정을 내릴 수 있음.
  • 프로그램의 나머지 부분을 보지 못한 채 일부만 변경하는 상황에서 LLM 오류가 자주 발생하며, Common Lisp에서는 이런 일이 덜 발생한다는 경험임.

안정적인 표준과 라이브러리 생태계

  • Common Lisp는 ANSI 표준이며 1994년 이후 업데이트되지 않았음. 제품을 사용자가 직접 변경하는 경우 기반 언어가 바뀌지 않아 그 위에 구축한 것이 깨지지 않는다는 점에서 이를 장점으로 봄.
  • Common Lisp로 프로그램을 작성할 때 필요한 라이브러리를 찾지 못하는 경우가 잦음. 주요 Common Lisp 패키지 관리자 Quicklisp에는 수천 개 프로젝트가 있는 반면, npm에는 수백만 개가 있음.
  • 다만 현재 많은 프로그램은 계속 침해되는 패키지에서 수백만 줄의 코드를 가져오며, 이런 의존성을 피하고 싶다는 관점임.
  • LLM을 이용해 필요한 부분을 직접 작성하거나 라이브러리 전체를 포팅할 수 있으며, LLM은 코드 포팅에 특히 능숙해 보임.

엔지니어 채용

  • 사업 구축을 목표로 프로그래밍하는 사람이 많아지는 상황에서 Common Lisp 제품 개발에 대한 명백한 우려는 이를 아는 사람이 적어 엔지니어 채용이 어렵다는 점임.
  • 성공적인 회사를 세우려면 새로운 것을 빠르게 배우는 최고의 기술 인력을 채용하는 것이 중요하다는 주장임.
  • 코딩 인터뷰에서 지원자에게 Common Lisp를 배우게 하면 습득 속도를 확인할 수 있으며, 잘하는 사람은 계속 학습해 능숙해질 가능성이 있음.

결론

  • 다음에 프로그램을 작성할 때 Common Lisp를 사용하라는 권고임.

참고 문헌

  • Graham, Paul. “What Made Lisp Different.” Paul Graham, 2002년 5월. paulgraham.com/diff.html. 2026년 10월 5일 열람.