LiteLLM의 새 버전은 중계 서버가 같은 컴퓨터에서 명령을 실행해 연결하는 도구 서버를 기본으로 껐다. 이 방식을 쓰던 개발·운영팀은 업그레이드 때 도구 연결 설정을 점검해야 한다. 처음 설치하는 사용자를 위해 중계 서버와 데이터베이스, 관리 화면을 한 명령으로 띄우는 시작 절차도 추가했다.
1. 등록은 남기고 실행을 막는다
2026년 10월 18일 공개된 이번 버전의 핵심 변경은 stdio 방식의 기본 비활성화다. MCP 서버는 모델이 쓸 외부 도구를 제공하며, 여기서 바뀐 방식은 프록시가 있는 컴퓨터에서 명령을 실행해 연결하는 것이다. 원격 서버에 접속하는 방식과 구분된다.
변경 제안서는 대다수 배포가 원격 서버만 필요하지만 기존에는 로컬 실행 방식을 끌 수 없었다고 설명한다. 이제 서버 등록 정보는 남아도 프로세스는 시작되지 않는다. 원격 HTTP·SSE 서버는 이 차단 대상이 아니다.
2. 차단 신호는 요청에 따라 다르다
꺼진 서버의 도구 목록을 REST API로 조회하면 빈 목록이 나오고, 도구를 직접 호출하면 접근을 거부하는 상태 코드 403과 안내 메시지가 반환된다. 같은 방식의 서버 생성·수정은 요청 검증 오류인 422로 거절된다. 다만 기존 서버를 원격 연결 방식으로 바꾸는 수정은 예외다.
관리 화면은 서버 카드에 비활성화 배지를 붙이고 생성·수정 화면의 해당 전송 방식을 회색으로 막는다. 기존 서버의 상세 화면 등에는 다시 켜는 방법을 안내하는 배너를 표시한다.
모델 요청이 차단된 서버를 가리킬 때는 오류 대신 도구 없이 성공할 수 있다. 따라서 요청 성공 여부만으로 연결을 판단하기보다 도구 제공 여부도 확인해야 한다. 이 제한은 프록시에 적용되며, 개발 도구 모음인 SDK의 MCP 클라이언트에는 적용되지 않는다.
3. 다시 켜려면 프로세스 환경을 바꾼다
계속 사용하려면 프록시 프로세스 환경에 LITELLM_ENABLE_MCP_STDIO=true를 설정하고 프록시를 재시작한다. 활성화 값은 true뿐이며, 대소문자와 앞뒤 공백은 구분하지 않는다.
프록시 옆의 .env 파일도 프로세스 환경으로 인정된다. 반면 설정 파일이나 데이터베이스에 저장한 값은 무시되며 경고가 남는다. 관리 화면이나 설정 갱신 API로 저장하는 경로도 활성화 수단이 아니다. 도구 연결을 다시 허용하는 결정은 프록시 실행 환경을 관리하는 쪽에서 내려야 한다는 뜻이다.
4. 기본 차단의 이익과 운영 비용
이 변경은 프록시 컴퓨터에서 로컬 명령을 실행하는 경로를 기본으로 닫는다는 이익이 있다. 대가는 기존 연결의 연속성이다. 종전 방식에 의존한 배포는 관리자 조치 전까지 도구를 잃으므로, 업데이트 작업에 연결 방식 점검과 환경 설정 변경을 포함할 필요가 있다.
변경 제안서에는 비활성화 상태에서 작업 프로세스 4개로 실행한 검증도 실렸다. 이 조건에서 화면 설정 조회 40회가 모두 비활성화를 보고했고, 도구 호출 60회는 모두 403이었으며 해당 도구 서버 프로세스는 시작되지 않았다. 이는 해당 검증 조건의 동작 확인이지 처리 속도 개선 수치는 아니다.
5. Docker 시작 절차와 이미지 검증
릴리스 노트는 Docker 한 명령 시작 절차가 게이트웨이, Postgres 데이터베이스, 관리 화면을 함께 띄운다고 설명한다. Windows용 PowerShell 시작 절차도 추가됐다. 다만 제공된 원문에는 실제 시작 명령과 배포 파일 내용이 제시되지 않았다.
노트에 실린 다음 코드는 시작 명령이 아니라 이미지 서명 확인 예시다. LiteLLM은 이미지를 cosign으로 서명하며, 변경되지 않는 커밋 해시로 공개 키 위치를 고정한 검증 방식을 권장한다.
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.106.0이번 버전은 설치 진입 절차를 줄이면서도, 로컬 도구 실행 허용은 관리자가 명시적으로 결정하도록 바꾼 릴리스다.