An agent in 100 lines of Lisp

TL;DR Highlight

Common Lisp의 eval 함수 하나를 도구로 주면 agent 루프 전체를 8줄 재귀함수로 구현할 수 있다는 실험적 글로, LLM agent의 본질이 얼마나 단순한지 잘 보여준다.

Who Should Read

AI agent 시스템을 직접 구현하거나 프레임워크 없이 최소한의 코드로 agent를 만들어보고 싶은 백엔드 개발자. Lisp에 관심이 있거나 agent 루프의 내부 구조를 이해하고 싶은 개발자에게도 유용하다.

Core Mechanics

AI agent의 핵심 루프는 놀랍도록 단순하다. 메시지 리스트를 모델에 보내고, 모델이 텍스트로 답하면 끝내고, 도구를 요청하면 실행 결과를 메시지에 추가해서 다시 호출하는 것이 전부다.
이 루프를 while문 + 상태변수로 구현할 수도 있지만, 저자는 재귀함수로 표현하는 것이 더 자연스럽다고 본다. 상태가 따로 없고 메시지 리스트 자체가 재귀 인자로 흘러가는 구조다.
실제 구현은 Common Lisp 8줄짜리 재귀함수 `agent-loop`가 전부다. HTTP 클라이언트 dexador와 JSON 파서 shasht, 두 라이브러리만 써서 SBCL 위에서 OpenRouter API를 호출한다.
Lisp의 homoiconicity(동형성, 코드와 데이터가 같은 구조인 특성) 덕분에 도구 카탈로그를 따로 만들 필요가 없다. `eval` 하나만 도구로 주면 모델이 직접 Lisp 코드를 작성해서 실행할 수 있기 때문이다.
30번째 피보나치 수를 '기억에서 꺼내지 말고 직접 계산하라'고 요청했더니, 모델이 재귀 함수를 작성하고 실행해서 832040이라는 결과를 돌려줬다. 모델이 언어 자체를 도구로 사용하는 셈이다.
저자가 강조하는 핵심 포인트는, 일반적인 agent에서 Python이나 Bash 스크립트는 별도 프로세스로 실행되지만, Lisp eval을 쓰면 agent 하네스 자체의 프로세스 안에서 코드가 실행된다는 점이다. 이론적으로 agent가 자기 자신을 실행 중에 수정할 수 있다.
2000년대 초 대학 AI 수업에서 배운 Lisp이 '심볼릭 AI(기호 기반 AI, 규칙과 논리로 추론하는 고전 AI)'의 언어였는데, 딥러닝 시대에 LLM agent를 구현하는 데 다시 딱 맞는 언어가 됐다는 것이 저자의 감상이다.
전체 구현은 약 100줄이며, 복잡한 프레임워크(LangChain 등) 없이 순수 Common Lisp으로 작동하는 완전한 agent다.

Evidence

eval을 도구로 쓰는 것이 Lisp만의 특별한 점이냐는 반론이 있었다. JS, Python, Ruby 등 런타임 기반 언어는 모두 eval이 있고, 안 쓰는 이유는 기능 부재가 아니라 보안 문제라는 지적이다. Python `-c` 옵션이나 bash tool과 본질적으로 뭐가 다르냐는 회의적 댓글도 있었다.
하지만 이에 대해 핵심 차이는 '프로세스 내부 실행'이라는 반론도 제기됐다. Python/Bash 스크립트는 별도 프로세스로 돌지만, Lisp eval은 agent 하네스와 같은 프로세스 안에서 실행되므로 agent가 자신의 런타임 자체를 수정·확장할 수 있다는 점이 다르다는 의견이다. 다만 이 때문에 매우 위험해서 반드시 샌드박스 환경에서만 써야 한다는 경고도 함께 나왔다.
보안 우려가 여럿 언급됐다. 'Claude Code의 `--dangerously-skip-permissions`로 모든 권한을 열어두는 것과 동급'이라는 댓글이 있었고, agent가 자기 수정 코드를 실행하는 것은 강력하지만 매우 불안정하며 실용 agent에서 원하는 특성과 정반대라는 의견도 나왔다.
9줄 Python으로 동일한 shell-tool agent를 구현한 코드를 댓글에 직접 올린 사람도 있었다. Lisp이 우아하긴 하지만 다른 언어로도 충분히 간결하게 만들 수 있다는 대조 사례였다.
LLM과의 대화에서 매 요청마다 전체 대화 이력이 다시 전송된다는 사실을 이 글을 보고 처음 알았다는 댓글도 화제가 됐다. 서버에 상태가 저장되는 게 아니라 클라이언트가 매번 전체 메시지 리스트를 보내는 구조임을 많은 사람이 간과하고 있었다는 점이 드러났다.
Prolog가 더 나은 선택이었을 것이라는 댓글도 있었고, elisp(Emacs Lisp)으로 순수 함수만 통과시키는 샌드박스 eval을 구현한 오픈소스 프로젝트(macher-agent)를 공유한 사람도 있었다.

How to Apply

최소한의 agent 구조를 이해하고 싶다면, 어떤 언어든 상관없이 '메시지 리스트를 받아 → 모델 호출 → tool call이면 실행 후 재귀, 아니면 반환'하는 재귀함수 하나로 agent를 직접 구현해보면 된다. 프레임워크 없이 OpenAI/OpenRouter API만 써도 동작하는 완전한 agent를 만들 수 있다.
실험적 sandbox 환경에서 'code interpreter' 스타일 agent를 만들 때, Python subprocess 대신 언어 자체의 eval을 도구로 주는 방식을 검토해볼 수 있다. 단, 반드시 격리된 컨테이너나 샌드박스 환경에서만 실행해야 하며 프로덕션에는 절대 적용하지 말 것.
기존에 LangChain 같은 무거운 agent 프레임워크를 쓰고 있다면, 실제로 필요한 핵심 로직이 얼마나 작은지 파악하기 위해 이 글의 구현을 참고해 직접 간소화 버전을 작성해보면 프레임워크 의존도와 복잡도를 줄일 수 있다.

Code Example

snippet

(defun agent-loop (messages)
  (let* ((message (ref (call-model messages) "choices" 0 "message"))
         (tool-calls (gethash "tool_calls" message)))
    (if (and tool-calls (plusp (length tool-calls)))
        (agent-loop (append messages (list message)
                            (map 'list #'execute tool-calls)))
        (append messages (list message)))))

;; eval을 유일한 도구로 사용
(defun lisp-eval (form-string)
  (handler-case
      (format nil "~s" (eval (read-from-string form-string)))
    (error (e) (format nil "ERROR: ~a" e))))

Terminology

homoiconicity코드와 데이터가 동일한 구조로 표현되는 언어 특성. Lisp에서는 프로그램 자체가 리스트(데이터)이기 때문에, 프로그램이 다른 프로그램을 마치 데이터 처리하듯 생성하고 실행할 수 있다.

eval문자열이나 데이터 구조로 표현된 코드를 실제로 실행하는 함수. Lisp에서는 리스트 형태의 코드를 바로 eval에 넘겨 실행할 수 있다.

SBCLSteel Bank Common Lisp의 약자로, 성능이 좋고 널리 쓰이는 오픈소스 Common Lisp 컴파일러/런타임이다.

OpenRouter여러 LLM 제공업체(OpenAI, Anthropic 등)의 API를 단일 엔드포인트로 통합해주는 API 라우팅 서비스.

symbolic AI딥러닝 이전의 고전 AI 접근법. 명시적인 규칙과 논리 기호를 조작해서 추론하는 방식으로, 전문가 시스템이나 정리 증명기 같은 것들이 여기에 해당한다.

agent loopLLM이 도구 사용을 요청할 때마다 실행하고 결과를 다시 모델에 넘기는 반복 실행 구조. 모델이 텍스트로 최종 답변을 낼 때까지 반복된다.