Lisp 작성은 AI에 저항하고 나는 슬프다
Source: Hacker News
프로젝트
최근에 저는 서로 다른 RSS‑리더 형식 간을 변환하는 도구를 만들고 있습니다.
당연히 Lisp—제가 가장 좋아하는 언어—로 시작했습니다.
문제점
AI에게 REPL 사용 방법을 가르쳐야 했습니다.
처음에는 tmux를 통해 REPL과 상호작용하는 명령을 실행했는데, 예를 들어:
tmux capture-pane -t 0.0 -p | tail -n 1이 방법은 어느 정도 동작했지만, AI에게 REPL 개발은 매우 어려웠습니다.
Claude는 계속 멈춰 섰고, 더 작은 모델들은 상황이 더 악화되었습니다. 저는 몇 분 만에 $10‑$20 정도를 쓰면서도 형편없는 Lisp 코드를 얻었고, 나중에 직접 다시 작성해야 했습니다.
또한 **DeepSeek**와 Qwen 같은 저렴한 모델들을 시도해 보았지만, 작업용으로는 괜찮지만 이 REPL 중심 워크플로에는 실패했습니다.
REPL 상호작용을 더 원활하게
Goose에게 REPL에 대한 무제한 권한을 부여하면서도 일반 명령 권한은 보호하고 싶었습니다.
그래서 tmux-repl-mcp 라는 도구를 만들어 REPL과의 상호작용을 보다 간단하게 만들었습니다.
많은 토큰을 소모하고, 여러 sleep 명령을 실행하며, tmux 출력 결과를 파싱하는 대신, 이제 AI는 REPL에서 단순히 다음을 실행하면 됩니다:
execute_command그리고 바로 출력 결과를 얻을 수 있습니다.
이 도구를 Python으로 작성한 이유는 제 Goose 도구 대부분이 이미 uvx 를 사용하고 있기 때문입니다. uvx를 설치하면 goose가 이 모든 도구를 바로 사용할 수 있게 되고, Python 패키지를 제 설정과 함께 배포하는 것이 자연스러웠습니다.
MCP 서버를 작성하기 위한 공식 가이드도 비‑Lisp 언어에 초점을 맞추고 있어, Python이 적합했습니다.
AI와 함께하는 Python vs. Lisp
차이는 극적이었습니다:
- Python – AI가 모든 코드 와 테스트를 작성했습니다. 저는 가벼운 반자동 디버깅만 필요했을 뿐입니다. 저렴한 모델을 사용했음에도 불구하고 하루 이틀 만에 기능적인 도구를 조립했습니다.
- Lisp – AI가 어려움을 겪었습니다. Lisp에서 느끼는 평소의 즐거움이 전혀 없었습니다. 결국
src/newsboat.lisp파일을 직접 손으로 작성했으며, 디버깅하면서 AI가 진전을 이루게 하는 것이 얼마나 더 어려운지 깨달았습니다. Claude로 다시 전환했을 때 약간의 진전은 있었지만, 30분 정도에 $10을 소모했습니다.
신호‑대‑잡음 비율(또는 휠‑스핀‑대‑진전 비율)은 Python에 비해 밤과 낮의 차이였습니다. AI에서는 신호 와 잡음 모두에 비용을 지불하므로, 비효율성은 비용이 크게 증가합니다.
Go로 재작성 고려하기
이제 도구를 Go로 다시 작성하는 것을 고민하고 있습니다. AI와 함께라면, 코드가 저렴해지는 것은 오직 해당 언어에 충분한 학습 데이터가 있을 때만입니다.
도구 사용에 대한 좌절감
Lisp에는 많은 패키지 매니저가 있습니다. 저는 QuickLisp보다 **OCICL**을 선호하지만, AI에게 매 세션마다 QuickLisp를 사용하지 말라고 알려야 했습니다:
https://www.quicklisp.org/beta/AI가 QuickLisp를 기본값으로 하드와이어된 것처럼 느껴졌습니다. 이는 AI가 최소 저항의 경로를 따르는 경향이 있음을 강조했습니다.
Why Lisp Is “AI‑Resistant”
- High‑latency request/response interaction with AI APIs doesn’t mesh well with REPL workflows.
- REPL development reduces latency for humans, but the API latency remains a bottleneck.
- Without a REPL, you need higher accuracy in each code‑generation batch, and you can only test large chunks at once.
- AI can generate hundreds of lines in one go, so it prefers languages that don’t rely on an interactive REPL.
In short, it’s orders of magnitude cheaper and easier to write in high‑traffic languages like Go or Python than in Lisp. AI has turned language popularity into a concrete dollars‑per‑million‑tokens cost metric.
플랭크 로드 비유
내 고향(일리노이주 나퍼빌)에는 플랭크 로드에 관한 이야기가 있습니다.
19세기에 진흙길이 여행자들을 괴롭혔기에 투자자들이 나무 판자로 만든 도로를 건설하고 통행료를 받았습니다.
이후 철도가 나퍼빌을 통과하도록 제안했지만, 투자자들은 이미 플랭크 로드로 충분히 돈을 벌고 있다며 거절했습니다.
철도는 다른 곳에 건설되었고, 결국 플랭크 로드는 사용되지 않게 되었으며 이름만 남았습니다.
이 비유는 적절해 보입니다:
- 플랭크 로드 = Lisp – 진흙길(‘하드’ 언어)보다 부드럽고 즐겁게 이동할 수 있음.
- 철도 = Go/Python – 더 빠르고 저렴하며 널리 채택됨.
플랭크 로드가 더 좋았음에도 불구하고, 철도로 전환하는 경제적 유인(화물을 차에 싣는 편리함)이 오래된 도로를 구식으로 만들었습니다. 마찬가지로 Lisp의 즐거움에도 불구하고, 주류 언어들의 낮은 비용과 높은 효율성이 실용적인 선택이 됩니다.
요점
돈이 저에게 유일한 문제는 아니지만, 비교를 무시하기는 어렵습니다. Plank Road (Lisp)는 더 풍부한 경험을 제공했지만, Railroad (Go/Python)는 속도, 비용, 그리고 생태계 지원 면에서 승리합니다.
AI를 활용해 개발한다면, 언어를 선택할 때 총 소유 비용—토큰 사용량, 지연 시간, 도구 등을 포함—을 고려하세요.
example of [Worse is Better](https://dreamsongs.com/WorseIsBetter.html). However, Lisp has survived this worse‑is‑better internet era for decades. I wonder what we'll learn as it survives the AI era as well. I like the neats camp. It's more *fun*. I wonder what adaptations will be necessary to make AIs work better on Lisp.