Autolith, Common Lisp 실행 이미지를 직접 고치고 복구하는 터미널 코딩 에이전트 공개

Smalltalk이나 Erlang의 액터와 메일박스 모델로 비슷한 걸 생각했었음. 아직 만들진 않았지만 이번 주말에 Elixir로 해볼까 싶음.

나도 처음엔 Smalltalk를 생각했는데 Common Lisp를 더 잘 알고 플랫폼 지원과 생태계도 낫다고 봤음. Elixir 에이전트도 괜찮을 듯하고, 만들면 소식 듣고 싶음.

에이전트 성능은 언어의 학습 데이터 양이 가장 중요하다는 말이 있는데, 결과를 빨리 내려면 왜 Lisp를 고르는지 모르겠음. Python이나 JavaScript, 성능까지 보면 C/C++/Rust가 더 낫지 않나.

링크한 글도 인기 언어를 써야 한다는 근거는 약하다고 명시함. 그 전제를 너무 강하게 잡은 것 같음.

Lisp는 자기 수정 프로그램을 쓰기 좋은 언어임. Scheme과 Clojure에서 LLM 보조 코드를 관리해보니 함수형 스타일은 공유 상태와 결합이 적어서 문맥 통제가 더 쉬웠음.

Sonnet 3.5 이후로 LLM이 Common Lisp를 꽤 잘 썼고 Opus 4.5부터는 거의 흠이 없었음. Autolith처럼 이미지 안에서 정의된 심볼을 직접 조사할 수 있으면 희소 언어라는 문제가 크지 않음.

Lisp의 규칙적인 문법은 LLM이 실행 이미지에서 직접 작업할 때 오히려 장점임. 지금 LLM 기준으로 언어를 고르면 Common Lisp와 Emacs Lisp를 최상단에 둘 것 같음.

내가 Lisp를 좋아하고, 살아 있는 이미지를 자기 수정하는 에이전트에는 가장 실용적이라고 봐서 Common Lisp로 만들었음. 지난 몇 달 사이 Scheme과 CL의 모델 품질이 충분해졌다고 판단했음.

Cursor와 비교하면 어떤 차이를 말하는 건지 궁금함. 질문 의도를 알면 구체적으로 답할 수 있을 듯함.

Lisp는 유연하고 성능도 괜찮으며 확장과 디버깅 기능이 좋아서 사람들이 좋아하는 거임.

Common Lisp의 몰더블한 성질은 에이전트가 실험해서 맞는 일을 하게 만들기 좋다고 봄. RLM 섹션도 있던데 Prime Agent와 비교하는 에이전트 벤치마크 결과를 보고 싶음.

코딩 에이전트가 나오고 나서 예전의 자기 개선 Lisp 프로그램을 다시 만드는 느낌이었음. 다음 단계는 에이전트가 프로그램 자체가 되는 것일 수도 있겠음.

에이전트가 자기 자신을 바꿔야 할 경우가 언제인지 잘 모르겠음. 필요한 도구를 파일로 만들고 호출하게 하면 되고, Emacs 설정을 읽게 하는 편이 에이전트가 내 Emacs 세션 안에서 실행되는 것보다 편함.