프로그래밍 언어에 우열이 있다면 그중 가장 좋은 하나가 있을 것이고, 그것은 커먼 리스프(Common Lisp)라는 주장이 한 개발자의 개인 블로그 글을 통해 제기됐다. 글쓴이는 이를 "일기(diary)"라고 스스로 규정하지만, 그 논지는 LLM이 코드를 빠르게 써주는 지금 상황에서 되짚어볼 만한 지점을 담고 있다. 핵심은 언어 자체의 우아함이 아니라, 코드 작성이 더 이상 병목이 아니게 된 개발 환경의 변화다.
병목이 옮겨간 자리
과거에는 사람이 코드를 쓰는 데 걸리는 시간이 압도적으로 길었기 때문에, 빌드하고 실행해 결과를 확인하는 몇 분의 대기는 상대적으로 사소했다. 그러나 LLM이 코드를 순식간에 써내는 지금은 "이 프로그램이 실제로 동작하는가"를 확인하는 과정, 즉 피드백 루프의 길이가 개발 속도를 좌우한다. 글쓴이는 바로 이 지점에서 커먼 리스프가 구조적 이점을 가진다고 본다.
커먼 리스프는 이미지 기반(image-based) 언어다. 프로그램이 메모리 안에 살아 있는 이미지로 존재하기 때문에, 함수 하나를 새로 정의하면 전체를 재시작하지 않고도 기존 함수가 즉시 교체된다. 읽기 시점·컴파일 시점·실행 시점의 구분이 사실상 없다는 폴 그레이엄의 오래된 관찰이 LLM 협업 맥락에서 새 의미를 얻는 셈이다. 또한 대부분의 언어에서 오류는 프로그램을 종료시키지만, 커먼 리스프에서는 프로그램이 멈추는 대신 전체 스택과 변수 상태를 담은 디버거가 열린다. 글쓴이는 이 디버거를 LLM에게 그대로 가리키면, LLM이 수정을 가한 뒤 멈춘 지점부터 실행을 재개할 수 있다고 설명한다.
코드가 곧 데이터라는 오래된 특성
리스프에서 코드는 리스트로 작성된다. (+ 1 2)는 두 수를 더하는 프로그램인 동시에 기호 +와 숫자 두 개로 이뤄진 리스트이기도 하다. 데이터를 다루는 도구가 그대로 코드를 다루는 데 쓰이므로, 프로그램이 다른 프로그램을 받아 변형하고 즉시 실행할 수 있다. 이것이 매크로를 가능하게 하는 토대이며, 매크로를 통해 언어 자체에 새로운 구문을 더할 수 있다. 그래서 리스프에서는 프로그램을 짜기 전에 그 문제 영역에 맞는 언어를 먼저 만든다는 발상이 성립한다.
글쓴이가 이 특성에 지금 더 큰 의미를 부여하는 이유는, 사용자가 제품을 직접 수정하는 방향으로 소프트웨어가 움직이고 있다고 보기 때문이다. 예시로 든 ERP가 대표적이다. 회사마다 운영 방식이 달라 거의 모두가 수정을 필요로 하는데, 제품이 자체 도메인 언어로 쓰여 있다면 사용자는 LLM에게 그 언어로 변경을 요청하면 된다. 변경이 도메인 언어에 깔린 전제를 자연스럽게 따르므로, 제품을 깨뜨리기보다 결에 맞게 확장된다는 논리다.
간결함, 그리고 토큰 경제
매크로로 반복 패턴을 언어의 일부로 흡수할 수 있어 리스프 프로그램은 대체로 더 짧다. 글쓴이는 자신이 만든 앱들이 파이썬 버전보다 약 6~7배 짧았다고 밝힌다. 코드가 적다는 것은 LLM 입장에서 토큰이 적다는 뜻이고, 토큰은 곧 비용이다. 더 중요하게는 프로그램의 더 많은 부분이 컨텍스트 창에 들어가므로 LLM이 전체 의도를 보고 판단하게 된다. 그는 LLM 버그의 상당수가 나머지를 보지 못한 채 한 조각만 고치는 데서 비롯된다고 말한다. 여기에 1994년 이후 갱신되지 않은 ANSI 표준이라는 안정성이 더해져, 사용자가 올려 쌓은 것이 바닥의 변화로 무너지지 않는다는 점을 장점으로 꼽는다.
작은 생태계는 약점으로 지적된다. Quicklisp의 프로젝트는 수천 개 수준으로 npm의 수백만 개와 비교되지 않는다. 다만 글쓴이는 외부 패키지에 수백만 줄을 의존하는 관행이 공급망 침해 위험을 키운다고 보고, 필요한 부분은 LLM으로 직접 작성하거나 라이브러리를 이식하면 된다고 반박한다. 인재 확보 문제에 대해서도 면접에서 지원자에게 커먼 리스프를 배우게 해 학습 능력을 가늠하라는, 다소 낙관적인 제안을 내놓는다.
이 글은 벤치마크나 제3자 검증이 아니라 한 사람의 경험과 신념에 기댄 주장이라는 점을 분명히 할 필요가 있다. 6~7배라는 코드 길이 차이나 디버거 기반 LLM 워크플로의 실효성은 일화적 근거이며, 이를 지원하는 도구 생태계도 아직 성숙했다고 보기 어렵다. 1994년에 멈춘 표준은 안정성인 동시에 현대적 편의의 부재이기도 하다. 그럼에도 "코드 작성이 아니라 검증과 피드백 루프가 병목"이라는 진단, 그리고 도메인 언어를 통해 사용자가 제품을 안전하게 변형하게 한다는 구상은, 언어 선택을 떠나 LLM 시대의 개발 설계를 고민하는 실무자에게 곱씹을 만한 관점이다.