Common Lisp로 LLM 코드 생성을 하자는 주장, HN은 '엘리트' 표현과 방언 혼동 문제를 지적

'엘리트'라고 자칭하는 분위기가 흥미롭고 좀 거슬림. 컴퓨터 과학의 거장 중에도 이렇게 자기 과시하는 사람이 있었나 싶음.

이 분야에서 l33t나 엘리트라고 부르는 건 아주 오래된 문화임. 다만 나도 CL을 25년 썼는데 저 표현은 민망했음.

Lisp는 표현력이 높고 제약이 적어서 각자 강한 의견을 갖기 쉬움. 그게 엘리트 의식으로 이어지는 면은 있는 듯함.

글의 엘리트 타령은 과하지만, 기술에서 배움과 숙련을 없애려는 '민주화' 담론도 싫음. 숙련이 필요한 도구가 완성 후에는 더 효과적인 경우도 있음.

Lisp를 오래 파고들면 다른 언어 사용자에게 우월감을 느끼기 쉬움. 원래 AI 언어였던 Lisp를 주력으로 썼다면 LLM 발전도 더 나았을 거라고 생각해서 나도 약간은 그렇게 느낌.

나는 저 표현을 CL의 희소성과 Lisp의 표현력이 주는 힘을 과장한 농담으로 읽었음.

저자가 자신을 엘리트라고 한 건 아니라고 봄. 엘리트를 위해 설계된 도구를 쓰고 싶다는 말과 본인이 엘리트라는 말은 다름.

'엘리트'라는 말은 Lisp 팬에게서 자주 보는데, 실제 세상은 C/C++로 돌아감. 남들이 모르는 진실을 안다고 여기는 음모론자 같은 태도로 보일 때도 있음.

예전에 Common Lisp 코드 생성을 써 보니 LLM이 Lisp 방언과 언어별 기능을 자주 섞었음. Clojure에서는 그 문제가 덜했음.

Sonnet 3.7부터 CL에 LLM을 써 왔지만 그런 혼동은 겪지 않았음. 주변 코드에 다른 Lisp가 섞여 있었던 것 아닌가 싶고, 이상한 실패 양상임.

요지는 매몰 비용 오류라는 한마디로도 설명됨. 짧고 재귀 적용도 가능해서 조심해야 하지만.

지난 1년간 FoundationDB 클라이언트, 분산 시스템 프리미티브, CL 관측성 라이브러리와 로그·메트릭·트레이싱 플랫폼을 약 20만 줄로 만들었음. 언어 선택은 익숙함과 취향 문제가 크고, LLM 시대에는 어떤 언어로도 큰 시스템을 만들 수 있으며 토큰 비용과 실행 성능이 더 중요해질 수 있다고 봄.

그런데 LLM이 밀도 높은 Common Lisp를 쓸까? 그 밀도는 잘 설계한 도메인 특화 매크로에서 나오는데, 사람이 충분히 지시하지 않으면 모델은 매크로를 만들 이유가 없음.

LLM을 텍스트 편집기가 아니라 Lisp REPL 안에서 운용한다는 대목은 더 읽고 싶음. 실제로 어떤 방식으로 연결하고 질의하는지 궁금함.

최근 CL 프로젝트에서 SBCL과 SLIME의 디버깅, CLOS의 유연성은 좋았음. Claude는 꽤 괜찮았지만 로컬 모델은 문서와 학습 코드가 적어서 약했고, Omnicoder 9B에서는 괄호 토큰화 때문에 블록 시작과 종료 괄호가 자주 틀어졌음.