llm --tool CodeInterpreter 'いまのPythonとSQLiteのバージョンを教えて'

라고 입력하면, Python이 실행되어 버전이 반환된다. 하지만 그 Python은 당신의 머신에서 실행되고 있는 것이 아니다. OpenAI의 서버 위에서 코드가 실행되고, 결과만이 수중에 도착한다.

8월 4일에 출시된 LLM 0.32는 이 「도구가 어디서 실행되는가」라는 설계를 정면으로 다룬 릴리스다. 제작자인 Simon Willison 스스로가 「프로젝트 시작 이래 가장 큰 업데이트」라고 쓰고 있다. 단순한 CLI 버전 업데이트처럼 보이지만, 에이전트(Agent)의 실행 모델과 관련된 변화가 포함되어 있다.

혼란스러울 수 있지만, 여기서 말하는 llm은 「대규모 언어 모델 (Large Language Model)」의 약칭이 아니라, Simon Willison이 만들고 있는 동명의 커맨드라인 도구 겸 Python 라이브러리를 말한다. OpenAI, Anthropic, 로컬 모델 등 수백 개의 모델을 동일한 llm '프롬프트'라는 문법으로 호출할 수 있는 얇은 래퍼(Wrapper)이며, 응답을 SQLite에 전부 기록해 주는 것이 특징이다. 데이터 처리 계열 엔지니어들 사이에서 정석적인 도구라는 위치로 파악하면 이해하기 쉽다.

기존의 llm에서도 「도구 (Tool)」는 사용할 수 있었다. 다만 그것은 모델이 「이 함수를 호출하고 싶다」라고 요청하면, llm이 당신의 머신 위에서 그 Python 함수를 실행하고 결과를 모델에 반환하는 방식이었다. 모델은 생각하고, 도구를 휘두르는 것은 로컬에서 수행하는 분담 구조였다.

0.32에서 추가된 것이 「서버 측 도구 (server-side tools)」다. 이름 그대로 도구를 휘두르는 장소가 모델 프로바이더(Provider) 측으로 옮겨간다.

서두의 CodeInterpreter가 바로 그것이며, 코드를 실행하는 샌드박스 (Sandbox)는 OpenAI의 인프라 측에 있다. 로컬의 Python 환경도, 네트워크 포트도 일절 사용하지 않는다. 마찬가지로 WebSearch를 전달하면, 모델은 검색을 자신의 서버에서 마치고 요약본만을 반환한다.

호출은 기존 도구와 동일한 -T (--tool의 단축형) 플래그를 사용하여 이름만 전달하면 된다.

# OpenAI의 서버 측에서 코드 실행
llm -T CodeInterpreter '1부터 100까지의 소수를 세어줘'
# 샌드박스에 메모리 상한 전달
...

프로바이더마다 사용할 수 있는 도구가 다르다는 점이 실무상의 주의점이며, 그 부분은 표로 확인해 두는 것이 좋다.

흥미로운 점은 Anthropic 측의 AnthropicMCP로, 외부의 MCP 서버를 모델의 실행 환경에서 직접 호출할 수 있게 한다. 제작자는 자신의 블로그 데이터베이스를 예로 들고 있다.

llm -m claude-sonnet-5 \
-T 'AnthropicMCP("https://datasette.simonwillison.net/-/mcp")' \
'how many rows in the blog_blogmark table?'

어떤 모델이 어떤 서버 측 도구에 대응하는지는 llm tools -m 모델명으로 확인할 수 있다.

이러한 분담의 이동에는 장점과 주의점이 양면으로 존재한다. 장점은 샌드박스나 검색 기반의 운용을 프로바이더에게 통째로 맡길 수 있다는 것이다. 로컬에 Docker를 띄우거나 네트워크 권한을 관리할 필요 없이, 코드 실행이나 웹 검색 기능이 에이전트에 탑재된다. 반면, 코드 실행이 프로바이더 측의 블랙박스(Black box)로 들어가기 때문에 무엇이 어떻게 작동했는지 로컬에서 완전히 감사(Audit)하기는 어려워진다. 어디까지 신뢰하고 맡길 것인가라는 트레이드오프 (Trade-off)를 스스로 결정해야 한다. 개인적인 견해로는, 외부 데이터에 접하는 웹 검색은 서버 측에서 처리하게 하고, 사내 고유 로직은 기존 방식대로 클라이언트 측 도구로 유지하는 방식이 현실적이라고 생각한다.

또 하나, 미미하지만 효과적인 것이 로그의 재구성이다.

서버 측 도구를 사용하면 모델은 「생각한다 → 검색한다 → 다시 생각한다」와 같이 도구 호출을 넘나들며 추론을 이어간다. 이는 OpenAI의 Responses API를 기본적으로 사용하게 된 것과 짝을 이루며, 추론 (Reasoning)과 도구 호출이 하나의 체인 (Chain) 안에서 교차하며 실행된다.

그 대가는 로그(Log)다. 에이전트적인 상호작용은 매 턴(Turn)마다 그때까지의 모든 메시지 열을 API로 다시 보낸다. 정직하게 기록하면 동일한 대화 이력의 JSON이 여러 번 중복되어 저장되어 버린다. 저자는 다음과 같이 적고 있다.

If we're going to support the pattern where the message sequence is appended to on every request, ideally we can avoid logging all of that duplicate JSON for every turn.

0.32는 이를 Git에서 영감을 얻은 방식으로 해결했다. 메시지를 해시(Hash)로 내용 주소 지정(Content-addressable)하여, 동일한 내용의 메시지는 한 번만 저장한다. SQLite의 스키마도 스레드(Thread)·턴(Turn)·메시지(Message)라는 단위로 재구성되었다. Git이 동일한 내용의 파일을 하나의 오브젝트(Object)로 공유하는 것과 같은 발상으로, 장시간 작동하는 에이전트의 로그가 대화의 길이에 비례하여 불어나는 것을 막으려는 목적이다. 이용을 위해서는 sqlite-utils 4.0 이상이 필요하다.

화려하지는 않지만 일상에서 유용한 것은 추론 트레이스(Reasoning Trace)의 출력 대상이다. 추론 모델의 '생각하는 도중'은 표준 에러 출력(stderr)으로 흐르고, 최종적인 답변만 표준 출력(stdout)으로 나온다. 즉 llm ... | jq와 같이 파이프(Pipe)로 후단에 넘기는 내용은 답변으로만 유지되어, 사고의 중간 과정이 섞이지 않는다. 파이프라인을 구축하는 사람에게는 은근히 고마운 설계이며, 사고 과정을 보고 싶지 않을 때는 -R (--hide-reasoning)로 중단할 수 있다.

Python 라이브러리 측도 구조화된 메시지(Structured Message) 방식으로 개편되어, model.prompt(messages=[llm.user("Hello")])와 같이 타입이 지정된 메시지를 전달할 수 있다. response.stream_events()를 통해 추론·텍스트·도구 호출이 섞인 스트림(Stream)을 다룰 수 있으며, 도구 구현에서 llm.PauseChain을 던지면 승인을 거치기 위해 실행 체인(Chain)을 일시 중단했다가 나중에 재개할 수도 있다. 인간의 승인을 워크플로(Workflow)에 삽입하고 싶을 때 기초가 된다.

또한 기본 모델은 새로운 gpt-5.6-luna로 변경되었으며, gpt-5.6-sol과 gpt-5.6-terra도 추가되었다.

llm을 평소에 사용하지 않더라도, 이번 릴리스가 보여주는 방향은 파악해 둘 가치가 있다. 에이전트의 도구는 '수중에 두고 돌리는 것'에서 '프로바이더(Provider)가 보유하는 것'으로 이층화되고 있으며, 그만큼 로그나 감사(Audit) 설계가 새로운 과제가 된다. 0.32는 그 양쪽 모두를 다룬 구현 사례로 읽을 수 있다. 먼저 시도해 보려면 pip install -U llm으로 업데이트한 뒤, llm -T WebSearch '最近のニュースを3つ'를 실행하여 그 상호작용이 llm logs에 어떻게 쌓이는지 살펴보는 것이 빠르다. 도구가 어디에서 작동하고 있는지를 의식하게 되는 좋은 입구가 될 것이다.

출처는 다음과 같다.