왜 지금 Common Lisp가 최고의 프로그래밍 언어인가

AI 요약

글쓴이는 LLM이 코드를 빠르게 작성하면서 개발의 병목이 코드 입력에서 검증으로 옮겨갔다고 봅니다. 이 관점에서 Common Lisp의 라이브 개발 환경과 매크로를 통한 언어 확장이 LLM 시대에 유리하다고 주장합니다. 다만 글의 주장은 경험담과 전망을 바탕으로 하며, Hacker News 토론에서는 각 장점이 Common Lisp만의 것인지, 실제 제품 개발에서 얼마나 유효한지를 두고 의견이 엇갈립니다.

빠른 피드백과 실행 중 수정

Common Lisp에서는 읽기·컴파일·실행 시점의 경계가 약하고, 프로그램을 메모리에 올린 이미지(image) 상태로 운영합니다. 실행 중 함수 정의를 다시 컴파일하면 프로세스를 재시작하지 않고도 다음 호출부터 새 구현을 적용할 수 있습니다. 글쓴이는 오류가 나면 스택과 변수 상태를 살펴보고, 수정한 뒤 멈춘 지점부터 실행을 재개하는 디버거도 장점으로 듭니다. LLM이 오류 로그를 읽고 프로그램을 다시 실행하는 대신, 디버거의 상태를 보고 고칠 수 있다는 설명입니다.

토론에서는 이 흐름이 다른 언어에도 있는지, 웹 서버에서 오류가 난 요청을 멈춘 채 두면 연결이 시간 초과되지 않는지 질문이 나옵니다. 일부 참여자는 Python, JavaScript, Visual Studio의 편집 후 계속 실행 기능도 비슷한 작업을 지원한다고 지적합니다. Common Lisp 쪽 참여자는 단순히 예외를 멈춰 살펴보는 데 그치지 않고, 실행 중인 이미지에 연결해 코드를 바꾼 뒤 해당 상태에서 이어가는 점이 다르다고 설명합니다. 다만 운영 환경에서 대화형 디버거를 쓰는 방식은 연결 시간 초과나 변경 이력 관리 문제를 낳을 수 있다는 우려도 제기됩니다. 글은 개발 흐름의 장점을 강조하지만, 이 기능이 다른 환경보다 얼마나 독보적인지는 토론에서도 합의되지 않습니다.

매크로와 도메인 언어

Common Lisp의 코드는 리스트 형태로 표현되며, 데이터와 코드를 같은 도구로 다룰 수 있습니다. 매크로는 코드를 입력받아 새 코드로 바꾸므로, 반복되는 패턴을 언어 문법처럼 만들어 도메인 특화 언어(DSL)를 구성할 수 있습니다. 글쓴이는 ERP를 예로 듭니다. 회사마다 업무 방식이 다르더라도 제품이 도메인 언어를 제공하면, 사용자는 LLM에 그 언어로 변경을 요청하고 제품이 정한 구조와 규칙 안에서 기능을 확장할 수 있다는 주장입니다.

댓글에서는 업종과 회사마다 ERP의 의미와 업무 흐름이 달라 공통 DSL을 만들기 어렵고, 사업 변화가 모델을 빠르게 낡게 할 수 있다는 반론이 나옵니다. 회사별로 맞춤 시스템을 만들면 기존 제품의 규모의 경제도 놓칠 수 있다는 지적입니다. 반대로 특정 회사나 좁은 업무 영역에 맞춘 DSL은 실용적일 수 있다는 의견도 있습니다. 한 참여자는 운동 앱처럼 겉보기엔 비슷하지만 종목별 데이터 구조와 기능이 크게 다른 영역에서 Lisp의 작은 프로그램 단위가 유용했다고 설명합니다.

코드 길이와 LLM 비용

글쓴이는 매크로가 반복 패턴을 언어 수준으로 추상화하므로 프로그램이 커질수록 코드가 짧아진다고 주장합니다. 본인의 경험에서는 Common Lisp 앱이 Python으로 만든 같은 앱보다 코드가 6~7배 짧았다고 합니다. 코드가 짧으면 LLM에 보내는 토큰을 줄이고, 더 많은 프로그램 내용을 컨텍스트 창에 넣어 전체 의도를 반영한 수정이 쉬워진다는 설명입니다.

댓글에서는 짧은 코드가 곧 적은 토큰 사용으로 이어지는 것은 아니라고 반박합니다. LLM이 DSL을 배우도록 설명서와 예시를 제공해야 하며, 코드 구조와 모듈 경계가 언어 선택보다 컨텍스트 사용량에 더 크게 작용할 수 있다는 지적입니다. 다른 참여자는 입력 토큰보다 출력 토큰 비용이 크고, 추상화로 접착 코드까지 줄어들면 절약 효과가 커질 수 있다고 답합니다. 이를 뒷받침할 비교 데이터가 필요하다는 의견도 나옵니다.

안정성과 생태계

Common Lisp는 ANSI 표준이며 1994년 이후 표준이 바뀌지 않았습니다. 글쓴이는 언어가 안정적이면 사용자나 고객이 만든 확장이 언어 변화 때문에 깨질 위험이 낮다고 봅니다. 반면 Quicklisp의 패키지는 수천 개 수준으로 npm의 수백만 개와 차이가 난다고 인정합니다. 다만 의존 패키지가 많으면 공급망 공격 위험도 커지며, LLM을 이용해 필요한 기능을 직접 만들거나 기존 라이브러리를 포팅할 수 있다고 주장합니다.

이에 대해 댓글에서는 라이브러리를 직접 포팅하면 문서화가 부족한 동작을 다시 찾아야 하고, 보안 검증도 직접 맡아야 한다고 지적합니다. Common Lisp 생태계에 여러 공통 작업을 돕는 라이브러리가 있다는 답변과, C 라이브러리나 JVM 기반 구현을 활용할 수 있다는 설명도 나옵니다. 다른 언어의 장점을 지지하는 참여자들은 정적 타입이 LLM에 명확한 제약과 오류 메시지를 주므로 동적 언어보다 코드 수정에 유리할 수 있다고 주장합니다. 토론 전반에서는 특정 언어가 LLM 시대의 절대적인 최선이라는 결론보다, 피드백 속도·타입·라이브러리·팀의 숙련도 같은 선택 기준이 서로 다르다는 점이 드러납니다.

Hacker News 반응

• @tzmudzin — DSL은 의미에 대한 합의를 전제로 하지만, 여러 산업이나 사업 변화에 걸쳐 그 합의를 이루기가 가장 어려운 일인 경우가 많습니다.
• @sroerick — 그렇다면 특정 회사 하나를 위한 DSL은 어떨까요?
• @tzmudzin — 규모의 경제를 잃고 회사 맞춤 ERP를 처음부터 만들게 됩니다. 또 사업이 바뀌면 모델이 빠르게 무효가 될 수 있습니다. 유통업체를 통해 팔던 회사가 온라인 상점을 열면, 고객을 아는 사업체 몇 곳만 상대하던 방식과 달라집니다.
• @frollogaston — 웹 서버처럼 계속 운영하는 시스템에서도 오류가 나면 항상 실행을 재개할 수 있나요?
• @vindarel — 앱 전체가 멈추지는 않습니다. Hunchentoot에서는 기본 설정으로 요청을 처리하는 스레드가 오류로 끝나고 역추적을 출력합니다. 설정을 바꾸면 개발 중 대화형 디버거를 띄우거나 브라우저에 역추적을 표시할 수 있습니다.
• @randallsquared — 운영 중인 프로그램을 멈추고 살펴본 뒤 즉석에서 수정하는 방식은 위험한 변경이 이력 관리나 변경 절차를 거치지 않고 반영될 수 있습니다. 저는 멈추고 살펴보고 종료한 뒤 수정하고 다시 시작하는 편이 더 안전하다고 느꼈습니다.
• @ellg — Smalltalk나 Erlang에서도 대부분 가능한 것 아닌가요? LLM이 있는데 매크로가 DSL을 만들어야 하는 이유도 잘 모르겠습니다.
• @misterchocolat — LLM이 일을 하려고 DSL이 꼭 필요한 건 아닙니다. 제품을 만든 사람이 가진 관점을 DSL에 담는 것이 더 중요합니다.
• @UncleOxidant — DSL이 토큰을 줄인다는 주장에는 근거가 더 필요합니다. LLM에 새 DSL의 설명서를 알려줘야 한다면 그 비용은 어떻게 되나요?
• @VikramBhamre — 해당 언어의 지원이 부족하면 제가 직접 작성하고 유지해야 할 기반 코드가 늘지 않나요?
• @ehe78qhe — 주로 제가 연결하려는 시스템의 문서화되지 않은 동작과 특이점을 다시 알아내야 한다는 점이 문제입니다. 다른 사람이 이미 보안 테스트를 한 라이브러리 대신 직접 침투 테스트와 레드팀 작업도 해야 합니다.
• @alexjurkiewicz — DSL은 LLM의 선택지를 제한해 코드 품질을 도울 수 있습니다. 하지만 왜 정적 타입과 borrow checker, Clippy를 제공하는 Rust가 아니라 제약이 적은 Common Lisp에서 DSL을 만들어야 하나요?
• @qalmakka — Haskell, Rust, OCaml 같은 언어의 강한 타입과 안전장치는 LLM이 논리를 따라가기 쉬운 의미 있는 타입 정보를 주므로 큰 도움이 됩니다. 동적인 코드에서는 사람처럼 LLM도 흐름을 놓치는 경우가 있습니다.
• @nickm12 — 이 글은 실제로 어떤 언어가 LLM에 가장 좋은지 평가하기보다, Common Lisp를 좋아하는 사람이 그 언어의 장점을 LLM 시대와 연결한 글처럼 읽힙니다. 정적 언어 쪽과 동적 언어 쪽 모두 익숙한 장점을 되풀이해 주장합니다.
• @gorgoiler — 어떤 프로그래밍 언어가 다른 언어보다 낫다고 해서 반드시 하나의 최고 언어가 존재하는 것은 아닙니다. 부분 순서에서는 최댓값이 없을 수도 있습니다.
• @rspeele — 사람들은 자신이 원래 좋아하던 언어가 에이전트 시대에도 완벽하다고 설명하기 쉽습니다. 저도 F#을 좋아해서 같은 방식으로 장점을 늘어놓을 수 있습니다.
• @clx75 — Clojure nREPL에 LLM 에이전트를 연결해 JVM 안에서 코드를 평가하게 했습니다. 테스트 코드를 디스크에서 수정하고 영향을 받은 네임스페이스를 다시 불러온 뒤 테스트를 실행합니다. 빠른 테스트와 가정 검증이 특히 마음에 듭니다.

원문: Hacker News / 번역·요약: Trawling