Lisp를 쓰는 것은 AI에 저항하고 나는 슬프다

I’m ready to translate the text, but I don’t see the article content you’d like me to translate—only the source line is provided. Could you please paste the text you want translated? Once I have it, I’ll keep the source line unchanged and translate the rest into Korean while preserving all formatting, markdown, and technical terms.

“네이츠”에 대한 아이러니한 타격

네이츠들을 조롱하고 아이러니하게 타격하기 위해, 스크러피들은 Lisp를 전혀 쓰지 않는 AI를 만들었습니다.

저는 업무에서 에이전트 AI를 많이 사용해 DevOps 엔지니어 일을 수행합니다. 저는 Goose CLI 도구와 함께 OpenRouter를 사용하고 있으며, 꽤 좋은 설정 파일을 만들었습니다.

The Lisp Project

나는 최근에 서로 다른 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 개발을 더 원활하게 만들기

REPL 개발을 좀 더 원활하게 하면 AI가 더 좋은 결과를 낼 수 있지 않을까 생각했습니다. 저는 Goose에게 REPL에 대한 무제한 권한을 부여하면서도 일반 명령에 대한 권한은 보호하고 싶었습니다. 그래서 tmux-repl-mcp 라는 도구를 만들었습니다. 이 도구를 사용하면 REPL과의 상호작용이 훨씬 간단해집니다. 많은 토큰을 소비하고, 여러 sleep 명령을 실행하고, tmux 출력을 파싱하는 대신 AI는 REPL에서 execute_command 를 실행하고 그 출력을 바로 받을 수 있습니다.

저는 이 도구를 Python 으로 작성했습니다. 이유는 제 Goose 설정 파일에 있는 많은 AI 도구들이 이미 uvx 를 중심으로 구축되어 있었기 때문입니다. uvx 만 설치하면 goose 가 이 모든 도구들을 바로 사용할 수 있다는 점이 마음에 들었습니다. 제 설정 파일에 이미 이런 것들이 구축돼 있었으니, 같은 방식으로 배포하면 다른 사람들도 더 쉽게 사용할 수 있을 것이라고 생각했습니다. 게다가 MCP 서버를 작성하는 공식 가이드는 비‑Lisp 언어를 대상으로 하고 있었습니다.

Python vs. Lisp with AI

Python과 Lisp를 AI와 함께 작성하는 차이는 물론 극적이었으며—그야말로 난폭했습니다. 저는 AI에게 모든 코드 와 그 코드에 대한 모든 테스트를 작성하도록 했습니다. 저는 반자동으로 디버깅을 해야 했지만, 저렴한 모델을 사용해 하루 이틀 만에 이 거의 무(無)인 도구를 겨우 만들어낼 수 있었습니다.

가장 안타까운 점은, 제 경험이 여러 면에서 동일했다는 것입니다: 저는 두 언어 모두에 대해 AI의 가난한 제품 소유자 역할을 했지만, AI는 Python에서만 잘 작동했습니다. Lisp를 작성할 때는 평소 느끼던 즐거움이 전혀 없었습니다.

실제 프로젝트로 돌아가는 것은 고통스러웠습니다. 저는 파일 중 하나(src/newsboat.lisp)를 직접 손으로 작성하게 되었습니다. 디버깅을 하던 중 Lisp에서 AI를 사용해 코드를 작성하는 것이 얼마나 더 어려운지 깨달았습니다. 최소한 다른 모델에 비해 어느 정도 진전을 보이는 Claude로 다시 전환해야 했습니다. tmux-repl-mcp 도구가 도움이 되었지만, 저는 약 30분 만에 10달러를 다 써버렸습니다.

AI 세션에서의 신호‑대‑잡음 비율—즉, 진행 대비 휠‑스핀 비율—은 Python과 비교했을 때 밤과 낮의 차이가 있었습니다. 그리고 AI에서는 잡음 와 신호 모두에 비용을 지불하게 됩니다.

Go로 다시 작성 고려하기

이제 도구를 Go로 다시 작성하는 것을 생각하고 있습니다. AI와 함께라면 코드는 저렴하지만—AI가 학습 데이터가 풍부한 언어를 사용할 때만 그렇습니다.

또 다른 불만은 도구 체인입니다. Lisp에는 선택할 수 있는 도구가 많이 있습니다. 예를 들어 QuickLisp 대신 OCICL을 사용하는 것을 좋아하지만, AI에게 Quicklisp을 매 세션마다 사용하지 말라고 말해야 했습니다. AI에 내장된 듯이 그것을 사용하려고 했습니다. 이것은 AI가 최소 저항 경로를 따라 코드를 생성한다는 것을 깨닫게 해주었습니다.

Lisp가 특히 AI에 저항적인 이유

• 고지연 요청/응답 AI API와의 상호작용은 REPL과 잘 맞지 않는다. REPL 개발은 인간의 지연을 줄여주지만, API 지연은 여전히 높다.
• REPL이 없으면 코드를 작성할 때 더 높은 정확성이 필요하고 그리고 한 번에 큰 코드 배치를 테스트할 수밖에 없다. AI는 한 번에 수백 줄을 작성할 수 있기 때문에, REPL에 의존하지 않는 언어를 선호하는 것이 논리적이다.
• Go와 Python 같은 고인터넷 트래픽 언어로 작성하는 것이 Lisp보다 수십 배 더 쉽고 저렴하다. AI의 등장으로 언어 인기가 실제 백만 토큰당 달러와 센트 수준의 비용 절감으로 이어졌다.

어느 언어로 개발하든 내가 언어를 경험하는 방식에는 차이가 없다; 이상적인 경우라면 나는 꽤 의견이 강하고, 세세하게 관리하는 제품 소유자다. 그건 정말 슬프다.

Source: …

플랭크 로드 비유

이 이야기는 내가 고향인 일리노이 주 네이퍼빌에서 들은 플랭크 로드 이야기가 떠오르게 합니다. 19세기에는 도로가 항상 진흙투성이였기 때문에, 투자자들이 나무로 만든 도로—플랭크 로드—를 건설했습니다. 그들은 이용료를 받았습니다.

그 후, 철도가 네이퍼빌을 통과하는 노선을 건설하겠다고 제안했지만, 투자자들은 플랭크 로드에서 충분히 돈을 벌고 있다며 거절했습니다. 철도는 다른 곳에 건설되었습니다. 사람들은 철도를 이용하기 위해 플랭크 로드 사용을 중단했고, 플랭크 로드는 이름만 남고 원래 형태로는 아무도 사용하지 않게 되었습니다.

돈은 개인적으로 큰 문제가 되지 않습니다. 하지만 두 상황을 비교하지 않을 수 없습니다:

• 플랭크 로드는 진흙길보다 더 편안하게 지나갈 수 있었고, 여행자들에게 즐거움을 주었습니다—마치 Lisp가 다른 언어보다 나에게 주는 느낌과 같습니다.
• 철도가 등장했을 때, 농부들은 단지 물건을 기차에 싣기만 하면 되었습니다. 그만큼 편리했으니, 왜 “바보 같은” 도로를 계속 사용해야 할까요?

이것은 더 나은 경험이더라도, 더 저렴하고 편리한 대안이 나타나면 버려질 수 있다는 또 다른 예시입니다.

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.