어제까지 잘 돌던 프롬프트 스크립트가 오늘은 로그가 달라지고, 디버깅 화면에 못 보던 "추론 요약"이 끼어든다면 문제는 프롬프트가 아닐 수 있습니다. 우리가 LLM CLI를 "터미널에서 쓰는 채팅창"으로 이해하던 모델이 낡아가고 있습니다.
Simon Willison의 llm 0.32a2 알파에서 핵심 변화는 OpenAI의 다수 reasoning-capable 모델이 기존 /v1/chat/completions 대신 /v1/responses를 쓰도록 바뀐 점입니다. 이 변경은 GPT-5 계열 모델에서 도구 호출 사이에 추론을 이어가는 흐름을 지원하며, CLI 실행 시 요약된 reasoning tokens를 표준 에러에 별도 색상으로 보여줍니다.1
CLI는 이제 메시지를 보내는 껍데기가 아니다
기존 Chat Completions식 사고방식은 단순했습니다. 메시지 배열을 보내고, assistant의 텍스트를 받습니다. Ollama 같은 로컬 LLM 도구의 기본 chat API도 message.content 중심의 직관적 구조를 제공합니다.2
하지만 reasoning 모델과 도구 호출이 결합되면 응답은 더 이상 "최종 답변 문자열" 하나로 충분하지 않습니다. 모델은 중간에 도구를 부르고, 결과를 받아 다시 판단하며, 그 과정 일부를 요약된 추론 형태로 노출할 수 있습니다.
실무적으로는 두 가지 습관을 바꿔야 합니다.
첫째, CLI 출력 전체를 사람이 읽는 텍스트로만 보면 안 됩니다. stdout, stderr, 메타데이터, 도구 호출 흔적을 구분해야 합니다. llm 0.32a2가 reasoning 요약을 stderr에 둔 것은 stdout 파이프라인을 보호하려는 설계로 볼 수 있지만, CI 로그나 통합 로그 수집기는 stderr까지 저장하는 경우가 많습니다.
둘째, 모델 교체를 단순 성능 업그레이드로 보면 위험합니다. 이제 모델 선택은 엔드포인트 선택, 응답 구조 선택, 디버깅 방식 선택이기도 합니다.
reasoning tokens의 비용은 돈만이 아니다
요약된 추론이 보이면 개발자는 모델이 왜 특정 방향으로 갔는지 더 빨리 감을 잡을 수 있습니다. 특히 에이전트형 작업에서 "왜 이 도구를 불렀는가"를 보는 것은 실패 원인 분석에 도움이 됩니다.
하지만 반대편 비용도 있습니다. 터미널 출력이 길어지고, 로그에 민감한 맥락이 섞일 수 있으며, 재현성 판단이 복잡해집니다. reasoning 요약은 전체 chain-of-thought가 아니라 모델 또는 API가 제공하는 압축된 단서에 가깝습니다. 따라서 감사 로그처럼 취급하기엔 부족하고, 단순 노이즈처럼 버리기엔 아깝습니다.
llm이 -R 또는 --hide-reasoning 옵션을 제공하는 이유가 여기에 있습니다.1 사람과 함께 디버깅하는 실행에서는 보이게 두고, 스크립트·배치·CI에서는 숨기는 식의 분리가 필요합니다.
이번 주에 점검할 CLI 워크플로
지금 당장 모든 자동화를 갈아엎을 필요는 없습니다. 0.32a2는 알파이고, 확인된 변화도 "대부분의 reasoning-capable OpenAI 모델"에 해당합니다. 모든 모델과 모든 공급자에 대한 일반 법칙으로 확대하면 안 됩니다.
대신 다음을 점검하는 편이 현실적입니다.
llm ... | jq,grep,awk처럼 출력 형식을 가정한 스크립트stderr를 실패 신호로 간주하는 CI 설정
모델명만 기록하고 API 엔드포인트나 응답 타입은 기록하지 않는 로그
"최종 답변 문자열"만 비교하는 eval
사람이 보는 실행과 기계가 파싱하는 실행을 구분하지 않는 프롬프트
특히 eval은 바뀌어야 합니다. reasoning 모델은 지연시간, 중간 도구 호출, 요약 추론 노출 여부까지 결과 품질에 영향을 줍니다. 정답률만 비교하면 운영 비용과 디버깅 가능성을 놓칩니다.
더 큰 신호: 모델 인터페이스가 제품 경계가 된다
이 변화는 llm만의 이야기가 아닙니다. LiteLLM의 최근 릴리스 노트만 봐도 GPT-5.5 지원, Memory API, 프롬프트 압축, agent workflow tracking 같은 기능이 함께 등장합니다.3 LLM 도구 생태계가 단순 호출 래퍼에서 게이트웨이, 메모리, 도구 권한, 워크플로 관리 쪽으로 이동하고 있다는 뜻입니다.
모델 출시 속도도 빠릅니다. llm-stats는 298개 이상의 모델 릴리스를 추적하며, reasoning 모델과 멀티모달이 주요 흐름이라고 정리합니다.4 이런 환경에서는 "어느 모델이 더 똑똑한가"보다 "그 모델을 어떤 프로토콜로 다룰 것인가"가 점점 중요해집니다.
llm 0.32a2를 당장 프로덕션 표준으로 삼으라는 뜻은 아닙니다. 오히려 알파 릴리스답게 호환성 탐지기로 보는 편이 맞습니다. 내 스크립트가 chat-completions 시대의 가정에 얼마나 묶여 있는지 확인하는 계기입니다.
터미널에서 LLM을 자주 호출하는 개발자, 에이전트형 자동화를 붙이고 있는 팀, 모델별 API 차이를 추상화하려는 플랫폼 담당자는 지금 신경 써야 합니다. 앞으로의 CLI는 "질문을 보내 답을 받는 도구"가 아니라, reasoning·도구 호출·로그·정책이 얽힌 작은 워크플로 엔진에 가까워질 것입니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.