Lisp 작성은 AI 저항적이고, 나는 슬프다 — Dan's Musings

Dan's Musings

Lisp 작성은 AI 저항적이고, 나는 슬프다

2026년 4월 5일 게시

모욕적이면서도 아이러니한 일격으로, the neats, the scruffies는 Lisp 말고는 무엇이든 훨씬 더 선호해서 작성하는 AI를 만들어냈다.

나는 DevOps 엔지니어로서 일을 하기 위해 직장에서 에이전트형 AI를 많이 사용한다. 나는 OpenRouter를 Goose CLI tool과 함께 쓰고 있고, 거기에 꽤 괜찮은 configuration file을 만들어 두었다.

나는 최근 서로 다른 RSS 리더 형식 사이를 변환하는 도구를 작성하기 시작했다. 물론 Lisp로 쓰기 시작했다. 내가 가장 좋아하는 언어이기 때문이다.

그런데 문제가 있었다. 나는 AI에게 REPL을 사용하는 법을 가르쳐야 했다. 처음에는 tmux를 통해 REPL과 상호작용하도록 명령을 실행하게 했는데, 예를 들면

tmux capture-pane
-t 0.0 -p | tail -n 1

였다. 그럭저럭 작동했지만, REPL 개발이 AI에게는 매우 어렵다는 것을 알아차렸다. Claude는 정말 제자리에서 헛돌았다. 더 약한 AI들은 훨씬 더 심했을 것이다. 몇 분 만에 $10-$20를 날렸는데, 손에 남는 것은 내가 결국 다시 쓰게 된 그럭저럭 괜찮은 Lisp 코드뿐이었다. DeepSeek나 Qwen 같은 더 저렴한 AI로도 해보았는데, 이들은 직장에서 어떤 작업에는 괜찮다고 느꼈지만 여기서는 통하지 않았다.

나는 아마 REPL 개발을 더 매끄럽게 만들면 AI가 더 잘할지도 모른다고 생각했다. 일반 명령 권한은 여전히 막아 두면서도 REPL에는 goose에게 무제한 권한을 주고 싶었다. 그래서 tmux-repl-mcp라는 도구를 만들었다. 이 도구는 REPL과의 상호작용을 더 직관적으로 만들어준다. 수많은 토큰을 소비하고, 여러 sleep 명령을 실행하고, tmux 출력을 파싱하는 대신, 그냥 repl에서 execute_command를 실행하고 그 출력을 받을 수 있었다.

나는 이 도구를 Python으로 작성했다. 내 goose 설정 파일의 AI 도구 체계 상당수가 이미 uvx를 중심으로 짜여 있었기 때문이다. uvx만 설치하면 갑자기 goose가 이 모든 도구를 사용할 수 있게 된다는 점이 좋았다. 나는 이미 이 모든 것을 설정 파일에 구축해 두었으므로, 같은 방식으로 배포되면 사람들이 쓰기 더 쉬울 것이라고 생각했다. 게다가 MCP 서버 작성 공식 가이드도 어차피 Lisp가 아닌 언어로 되어 있었다.

AI와 함께 Python과 Lisp를 작성하는 경험의 차이는 물론 극적이었고, 정말 엄청났다. 나는 그걸로 코드 전체와 테스트 전체를 작성하게 만들 수 있었다. 반쯤 수동으로 디버깅해야 하기는 했지만, 그래도 하루나 이틀 만에 이 최소한 구색은 갖춘 도구를 뚝딱 만들 수 있었고, 그것도 저렴한 모델들로 가능했다. 가장 나쁜 점은, 내 경험 자체는 여러 면에서 같았다는 것이다. 둘 다에서 나는 AI에게 가난한 사람의 제품 책임자 노릇을 하며 코드를 썼고, 다만 Python에서는 AI가 잘 수행했다는 점만 달랐다. 나는 Lisp를 그냥 작성할 때 보통 느끼는 그 어떤 행복도 느끼지 못했다.

실제 프로젝트로 돌아가는 일은 고통스러웠다. 결국 파일 하나(src/newsboat.lisp)는 손으로 직접 작성했다. 그걸 디버깅하던 중에, AI와 함께 Lisp로 작성하는 것이 얼마나 더 어려운지 깨달았다. 나는 다시 Claude로 돌아갈 수밖에 없었는데, 적어도 다른 것들에 비하면 어느 정도는 진전 을 만들어내기 때문이다. tmux-repl-mcp 도구는 도움이 되었지만, 그래도 30분쯤 만에 $10를 써버렸다. 신호 대 잡음비, 다시 말해 AI 세션에서의 헛바퀴 대 진전 비율은 Python과 비교하면 하늘과 땅 차이였다. 그리고 AI에서는 잡음과 신호를 함께 돈 내고 사야 한다.

이제 나는 이걸 Go로 다시 쓸까 생각 중이다. AI와 함께라면 코드는 싸다. 하지만 AI가 훈련 데이터를 많이 가진 언어를 사용할 때만 그렇다.

또 다른 좌절은 도구 체계였다. Lisp에는 선택할 수 있는 도구가 많다. 예를 들어 나는 QuickLisp 대신 OCICL을 쓰는 편을 좋아하는데, AI에게 quicklisp를 쓰지 말라고 매 세션마다 말해줘야 했다. 마치 그걸 쓰도록 AI에 내장되어 있는 것 같았다. 이 경험은 또한 AI가 일종의 최소 저항 경로를 따라 코드를 생성한다는 사실을 깨닫게 해주었다.

훈련 데이터 부족 말고도 Lisp를 특히 AI 저항적으로 만드는 이유들이 있다. 우리가 AI API와 상호작용하는 높은 지연의 요청-응답 방식은 REPL과 잘 맞지 않는다. REPL 개발은 인간에게는 그 지연을 줄여 줌으로써 프로그래밍을 더 쉽고 더 좋게 만들지만, 이런 API들에는 이미 높은 지연이 존재한다. REPL을 사용하지 않을 때의 단점은 코드를 작성할 때 더 높은 정확도가 필요하고 또한 한 번에 큰 코드 묶음만 테스트할 수 있다는 점이지만, AI는 한 번에 수백 줄을 쓸 수 있으므로 REPL을 쓰지 않는 언어를 AI가 사용하는 편이 그냥 더 말이 된다.

Go나 Python 같은 인터넷상 물량이 많은 언어로 작성하는 것은 Lisp로 작성하는 것보다 몇 자릿수나 더 쉽고 더 저렴하다. AI의 등장은 언어 인기도를 백만 토큰당 실제 달러와 센트 비용 절감으로 바꾸어 놓았다. 게다가 한 언어로 만들든 다른 언어로 만들든, 내가 그 언어를 경험하는 방식에는 차이가 없다. 어느 쪽이든 이상적인 경우 나는 꽤 의견이 강하고 미세하게 간섭하는 제품 책임자일 뿐이다. 그건 정말 슬픈 일이다.

이것은 내 고향에서 Plank Road에 대해 들었던 이야기를 떠올리게 한다. Naperville, IL의 19세기 도로는 늘 진흙투성이였기 때문에, 어떤 투자자들이 널빤지를 깔아 만든, 즉 나무로 된 도로를 만들었다. 그 도로를 만든 사람들은 그 길을 사용하는 대가로 돈을 받았다. 나중에 철도가 Naperville을 통과하도록 짓겠다는 제안이 있었지만, 그들은 널빤지 도로에서 이미 돈을 충분히 벌고 있다며 거절했고, 그래서 철도는 다른 도시로 지어졌다. 모두가 철도를 선호하게 되면서 널빤지 도로는 더 이상 쓰이지 않게 되었고, 결국 원래 형태로는 아무도 사용하지 않은 채 이름만 남아 살아남았다.

적어도 나에게는 여기서 돈이 문제가 아니라는 것을 안다. 하지만 머릿속에서 그 비교를 하지 않을 수가 없다. Plank Road는 진흙길과 비교하면 분명 훨씬 더 지나가기 좋았을 것이고, 여행자들은 진흙 속 이동과 비교하며 기쁨을 느꼈을 것이다. 그것은 마치 내가 다른 무언가를 작성할 때와 비교해 Lisp를 쓸 때 느끼는 감정과 같다. 하지만 철도가 등장했을 때 농부들이 해야 할 일은 그저 짐을 화차에 싣는 것뿐이었다. 그렇게 쉬운데, 굳이 그 우스운 도로를 왜 쓰겠는가?

이것은 그저 Worse is Better의 또 다른 사례일 뿐이다. 하지만 Lisp는 이 더 나쁨이 더 낫다 식의 인터넷 시대를 수십 년 동안 살아남아 왔다. AI 시대까지도 살아남으면서 우리가 무엇을 배우게 될지 궁금하다. 나는 neats 진영을 좋아한다. 그쪽이 더 재미있기 때문이다. AI가 Lisp에서 더 잘 작동하게 만들려면 어떤 적응이 필요할지 궁금하다.

RSS로 구독 / 이메일로 구독.

Powered by mataroa.blog.