Ollama v0.40.9, 릴리스 후보에서 llama.cpp 업데이트
Ollama v0.40.9는 2026년 10월 22일 릴리스 후보로 공개되었으며, 발표 내용은 간단했습니다. llama.cpp 업데이트입니다. 기반 변경 사항은 검증할 수 있지만, 릴리스 노트에는 벤치마크 결과나 애플리케이션 동작에 관한 자세한 약속이 없습니다. 개발자가 평가해야 할 것은 입증된 성능 향상이 아니라 의존성 업데이트입니다.
이 구분은 언어 모델을 실행하는 소프트웨어인 llama.cpp가 사용자가 속도, 호환성, 신뢰성으로 체감하는 애플리케이션 기능의 기반에 있기 때문에 중요합니다. 이 의존성을 갱신하면 애플리케이션의 눈에 보이는 인터페이스를 바꾸지 않고도 영향을 줄 수 있습니다. 다만 이 특정 업데이트가 실제 배포 환경을 개선하는지는 별개의 문제입니다.
핵심 긴장 관계는 업스트림 개발을 반영하는 일과 기존 워크로드의 예측 가능한 동작을 보존하는 일 사이에 있습니다. llama.cpp를 직접 실행하면 개발자에게 또 하나의 비교 기준이 생기며, vLLM은 별도의 서빙 접근 방식을 제공합니다. 어느 비교도 이번 릴리스만으로 우위를 입증하지는 않습니다. Ollama를 사용하는 팀의 당면 과제는 애플리케이션 아래에서 무엇이 바뀌었는지 이해하는 것입니다.
Ollama v0.40.9가 실제로 바꾸는 것
검증된 사건은 Ollama 프리릴리스로 배포된 llama.cpp 의존성 업데이트입니다. 이는 더 빠르거나 더 강력한 로컬 AI에 관한 일반적인 주장보다 범위가 좁습니다.
공식 릴리스 후보는 표시 제목으로 v0.40.9를 사용하지만 실제 태그는 v0.40.9-rc1입니다. GitHub는 이를 프리릴리스로 명시합니다. 더 짧은 제목을 접한 독자는 배포 준비 상태를 논의할 때 이 차이를 유지해야 합니다.
릴리스 본문에는 단 하나의 변경 항목이 있습니다. “llama.cpp update.” 측정된 속도 향상, 메모리 감소, 광범위하게 적용되는 호환성 개선은 발표하지 않습니다. 이러한 결과를 주장하려면 발표 문구를 넘어선 근거가 필요합니다.
릴리스 이력을 해석하기 전에 확인할 만한 문서 세부 사항도 있습니다. 게시된 변경 로그 링크는 rc1 릴리스 페이지에 표시되는데도 v0.40.8과 v0.40.9-rc0를 비교합니다. 이 엔드포인트 불일치가 소프트웨어 결함을 뜻하지는 않습니다. 다만 독자가 연결된 비교가 다루는 범위를 추정하는 데 한계를 둡니다.
따라서 발표를 검토하는 개발자가 던져야 할 유용한 질문은 검토 중인 정확한 후보에 관한 것입니다. 표시 제목은 릴리스 계열을 식별합니다. 태그는 후보를 식별합니다. 비교 엔드포인트는 특정 변경 범위를 식별합니다. 이 식별자들은 서로 다른 목적을 가집니다.
여러 사람이 업그레이드를 논의할 때 이 구분은 실질적으로 중요해집니다. 애플리케이션 엔지니어는 “v0.40.9”를 테스트했다고 보고할 수 있고, 인프라 엔지니어는 rc1 아티팩트를 가져올 수 있습니다. 완전한 식별자가 없으면 실제로 무엇이 실행됐는지에 대한 대화에 모호함이 남습니다.
이 릴리스는 모델 발표와도 구분해야 합니다. 런타임 업데이트는 모델 실행을 담당하는 소프트웨어를 변경합니다. 그 자체로 모델이 새 학습을 받았거나, 지식을 얻었거나, 추론 품질이 개선되었음을 입증하지는 않습니다.
마찬가지로, 의존성 갱신이 이전에 지원되지 않던 모든 모델이 이제 작동한다는 증거는 아닙니다. 호환성은 관련 아키텍처와 주변 애플리케이션에 통합되는 방식에 달려 있습니다. 짧은 발표는 포괄적인 보장을 제공하지 않습니다.
이는 구체적인 기술적 범위를 가진 유지보수 이벤트입니다. 중요성은 릴리스 노트의 길이가 아니라 변경된 의존성이 놓인 위치에서 비롯됩니다. 확립된 인터페이스 아래의 소프트웨어는 인터페이스가 익숙하게 유지되는 동안에도 바뀔 수 있습니다.
첫 번째 결론은 명확합니다. 이 후보는 실제 내용에 따라 평가할 가치가 있습니다. 릴리스 제목만으로 기존 배포가 이를 채택해야 하는지 답할 수 없으며, 발표 역시 달리 주장하지 않습니다.
업스트림 변경은 발표보다 더 구체적입니다
연결된 pull request는 의존성 범위를 식별하므로 개발자에게 더 확실한 조사 기반을 제공합니다. 이 근거는 다운스트림 결과를 입증하지 않으면서도 유용한 세부 정보를 더합니다.
Ollama의 병합된 의존성 업데이트는 llama.cpp 버전 b11738부터 b11803까지를 가리킵니다. 이 pull request는 2026년 10월 22일에 병합되어 릴리스 발표를 식별 가능한 업스트림 범위와 연결합니다.
대상 버전은 최근 개발에 관한 구체적인 단서도 제공합니다. 업스트림의 Flint 모델 지원 항목은 b11803에서 FlintForCausalLM이 추가되었음을 밝힙니다. 이는 대상 버전에서 업스트림 모델 구현 변경이 있었음을 확립합니다.
이는 모든 Ollama 플랫폼이나 실행 경로에서 완전한 Flint 지원을 입증하지는 않습니다. 업스트림 구현과 완성된 애플리케이션 통합은 관련된 이정표이지만 서로 다른 질문에 답합니다. 이 구분은 의존성 발표가 근거 없는 제품 주장으로 확대되는 것을 막습니다.
이 근거를 읽는 유용한 방식은 점점 더 구체적인 진술의 연결고리로 보는 것입니다. Ollama는 의존성 갱신을 발표합니다. 해당 pull request는 업스트림 범위를 식별합니다. 대상 릴리스는 모델 구현 변경을 명시합니다. 각 진술에는 출처와 제한된 범위가 있습니다.
이 연결고리는 독자의 노트북 성능에 관한 주장으로 곧바로 넘어가면 추측이 됩니다. 이 진술들 중 어느 것도 특정 기기에서의 응답 속도를 측정하지 않습니다. 또한 특정 모델의 메모리 사용량이나 특정 애플리케이션의 정확성을 입증하지도 않습니다.
동일한 절제는 버그 수정에도 적용됩니다. 업스트림 개발 범위에는 기존 사용자와 관련된 변경이 포함될 수 있습니다. 하지만 관련성을 판단하려면 특정 변경을 특정 동작과 연결해야 합니다. 일반적인 “update”라는 표현은 그 연결을 대체할 수 없습니다.
그럼에도 유지보수 담당자에게 식별 가능한 범위는 가치가 있습니다. 후보의 동작이 달라질 때 조사를 더 집중적으로 진행할 수 있게 해 줍니다. 엔지니어는 프로젝트 전체 이력을 검색하는 대신 의존성 전환을 검토할 수 있는 제한된 출발점을 갖게 됩니다.
이 경계는 업스트림 동작과 애플리케이션 통합을 구분하는 데도 도움이 됩니다. 문제가 llama.cpp 직접 실행과 Ollama에서 모두 나타난다면 공유 의존성은 합리적인 조사 대상이 됩니다. Ollama에서만 나타난다면 다른 계층도 주목할 만합니다.
이는 이번 릴리스에 관한 발견이 아니라 진단 가능성입니다. 발표만으로는 그러한 비교가 확립되지 않았습니다. 릴리스 노트가 짧더라도 정확한 의존성 정보가 중요한 이유를 설명한다는 데 가치가 있습니다.
이 지점에서 업데이트는 일반적인 유지보수 헤드라인보다 더 많은 정보를 제공합니다. 공개 기록은 추적 가능한 엔지니어링 변경을 제공합니다. 그러나 Ollama를 실행하는 다양한 시스템에서 이 변경이 무엇을 제공하는지 입증하는 데까지는 이르지 않습니다.
애플리케이션 팀이 즉각적인 평가 부담을 짊어집니다
즉각적인 압박을 받는 사람들은 예측 가능한 추론 동작에 의존하는 애플리케이션을 유지하는 개발자들입니다. 추론이란 학습된 모델을 실행해 출력을 생성하는 것을 뜻합니다.
이 개발자들에게 업그레이드 결정은 모델이 성공적으로 시작되는지 여부를 넘어섭니다. 애플리케이션은 요청, 모델, 실행 소프트웨어, 하드웨어 간 상호작용에 의존합니다. 의존성 업데이트는 그 관계의 일부를 바꿉니다.
예를 들어 설명용 내부 문서 지원 도구를 생각해 볼 수 있습니다. 이 도구는 기술 파일에서 구절을 검색하고 로컬 모델에 답변 생성을 요청합니다. 사용자는 완성된 응답을 평가하지만, 엔지니어링 팀은 검색 문제와 생성 문제를 구분해야 합니다.
업그레이드 후 지원 도구의 동작이 달라진다면 런타임은 가능한 원인 중 하나가 됩니다. 변경된 문서 컬렉션, 프롬프트 또는 모델 아티팩트도 다른 원인이 될 수 있습니다. 여러 구성 요소를 함께 변경하면 릴리스를 평가하기가 더 어려워집니다.
이 예시는 후보와 관련해 보고된 장애가 아닙니다. 팀이 자체 워크플로에 연결된 근거를 필요로 하는 이유를 보여 줍니다. 관련 없는 프롬프트에서 성공한 시연은 확립된 애플리케이션이 예상한 동작을 유지하는지 판단해 주지 않습니다.
문서 애플리케이션에서 응답 속도는 결정의 일부일 뿐입니다. 답변은 여전히 질문에 답하고 애플리케이션의 요구 사항을 준수해야 합니다. 결과가 추가 검토 작업을 만든다면 더 빠른 텍스트 생성의 가치는 제한적입니다.
더 넓은 지식 워크플로도 별도로 주목할 가치가 있습니다. 검색 가능한 지식 베이스를 구축하는 팀은 신뢰할 수 있는 소스 수집과 검색 역시 필요합니다. 실행 업데이트만으로는 이러한 주변 프로세스가 개선되지 않습니다.
따라서 애플리케이션 팀은 자원 배분에 관한 질문에 직면합니다. 평가는 시간을 소비하는 반면 업그레이드를 미루면 유용한 변경이 지연될 수 있습니다. 발표는 배포 환경별 이점도 의무적인 도입 기한도 제공하지 않으므로 보편적인 답을 제시하지 않습니다.
알려진 호환성 제약을 조사하는 개발자는 이미 만족스러운 워크로드를 운영하는 사람과는 다른 이유로 후보를 검토합니다. 전자는 다시 확인할 구체적인 동작이 있습니다. 후자는 변화를 도입할 더 명확한 이유가 필요합니다.
지원 팀도 정확한 릴리스 정보를 보존함으로써 이점을 얻습니다. 사용자가 업데이트 후 문제를 보고하면 전체 버전은 논의 중인 소프트웨어를 식별합니다. 최신 릴리스를 사용한다는 일반적인 설명은 덜 유용한 근거가 됩니다.
이는 위기를 암시하지 않으면서 유지보수 담당자에게 실질적인 부담을 줍니다. 어떤 애플리케이션 동작이 확인할 만큼 중요한지 결정해야 합니다. 적절한 범위는 발표의 주목도보다 배포 환경의 책임을 따릅니다.
후보를 평가할 수 있다는 점에서 압박은 즉각적입니다. 장기적 결과는 그 평가가 무엇을 밝혀내는지에 달려 있습니다. 짧은 릴리스 노트도 그 결과를 확립하지 않은 채 의미 있는 엔지니어링 결정을 시작할 수 있습니다.
직접 실행하는 llama.cpp와 vLLM은 서로 다른 비교를 제공합니다
대체 실행 스택은 평가 우선순위를 명확히 하는 데 도움이 되지만, 이번 릴리스는 비교 성능 순위를 제공하지 않습니다. 중립적인 비교는 각 선택지가 어떤 질문에 답하는 데 도움이 되는지에서 시작합니다.
llama.cpp 직접 실행은 발표에서 언급된 의존성과 가까운 참조 기준을 제공합니다. 이를 통해 조사자는 동작이 기반 실행 소프트웨어에 속하는지, 아니면 주변 애플리케이션 통합에 속하는지 질문할 수 있습니다.
이 참조 기준이 자동으로 직접 실행을 더 나은 배포 선택지로 만들지는 않습니다. 애플리케이션은 기존 스택이 제공하는 편의 기능과 운영 동작에 의존할 수 있습니다. 그러한 계층을 제거하면 비교 방식뿐 아니라 유지보수 책임도 달라집니다.
이번 업데이트에서 직접 실행은 조사용 참조로서 가장 유용합니다. 개발자에게 좁게 정의된 동작을 검토할 또 다른 방법을 제공합니다. Ollama 외부에서 전체 애플리케이션이 동일하게 동작한다는 사실을 입증할 수는 없습니다.
vLLM은 다른 비교 지점을 제공합니다. 추론 서빙 프로젝트는 처리량과 메모리 효율성에 중점을 둔다고 설명합니다. 이러한 지향점은 모델 요청을 서빙하는 데 필요한 사항을 논의할 때 관련성이 있습니다.
처리량은 시스템이 시간에 걸쳐 완료하는 작업량을 의미한다. 이는 개별 사용자가 체감하는 대기 시간과는 다르다. 배포 환경을 비교하려면 결과에 의미를 부여하기 전에 어떤 결과가 중요한지 먼저 식별해야 한다.
개인용 애플리케이션과 공동 서비스는 이러한 결과에 서로 다른 우선순위를 둘 수 있다. 대화형 응답을 기다리는 사용자는 그 상호작용에 관심을 둔다. 서비스 운영자는 요청이 동시에 도착할 때의 동작도 중요하게 본다.
이러한 사례는 광범위한 “Ollama 대 vLLM” 판정이 여기의 근거를 넘어서는 이유를 설명한다. 발표에는 공통 워크로드, 동일한 하드웨어 구성, 비교 측정치가 제공되지 않는다. 따라서 두 프로젝트 사이의 배포 선택을 결정할 수 없다.
주요 비교는 기존 Ollama 배포 환경 내부에서 이뤄진다. 즉, 확립된 동작과 후보 버전의 동작을 비교하는 것이다. 대체 스택은 맥락과 조사 선택지를 제공한다. 그러나 이야기의 중심에 있는 구체적인 의존성 전환을 대체해서는 안 된다.
이 구분은 독자가 프로젝트 활동을 제품 우수성과 혼동하지 않도록 보호하기도 한다. 업스트림 업데이트는 유지보수 작업이 이뤄졌음을 보여 준다. 그것이 이제 속도, 사용성 또는 신뢰성에서 모든 대안을 능가한다는 뜻은 아니다.
기업 구매자에게 관련된 시사점은 요구사항에 관한 것이다. 익숙한 애플리케이션 인터페이스가 실행 동작을 이해해야 할 필요를 없애지는 않는다. 반대로 더 많은 구성 선택지에 접근할 수 있다고 해서 평가 없이 더 나은 결과가 보장되는 것도 아니다.
독립 개발자에게 시사점은 노력에 관한 것이다. 당면한 질문이 단일 후보에 관한 것이라면, 사용 가능한 모든 스택을 비교할 필요는 없다. 확립된 배포 환경과의 집중적인 비교가 더 유용한 근거를 만들어 낼 수 있다.
따라서 경쟁 맥락은 이 기사의 핵심 긴장을 더욱 선명하게 한다. 업스트림 개발을 통합하면 호환성이나 동작을 개선할 기회가 생긴다. 확립된 애플리케이션 경험을 유지하려면 그 기회가 실제 이점으로 이어지는 지점을 보여야 한다.
이번 릴리스가 입증하지 않는 것
공개 근거는 소프트웨어 변경을 입증할 뿐, 하드웨어·모델·애플리케이션 전반의 일반적인 개선을 입증하지는 않는다. 이러한 경계는 어떤 평가에서도 명확히 유지돼야 한다.
발표와 관련 의존성 풀 리퀘스트는 광범위한 속도 향상을 보여 주는 비교 벤치마크를 제공하지 않는다. 또한 애플리케이션 출력이 더 정확해진다는 독립적 근거도 제공하지 않는다. 어느 결과에 대한 주장도 추가 취재나 측정이 필요하다.
이러한 측정이 없다고 해서 업데이트가 아무 이점도 제공하지 않는다는 증거는 아니다. 이는 현재 이용 가능한 근거로는 그 이점을 정량화할 수 없다는 의미다. 이 두 진술을 분리하면 불확실성을 홍보나 비판으로 바꾸지 않고도 유용한 분석을 할 수 있다.
같은 구분은 신뢰성에도 적용된다. 병합된 변경 사항은 프로젝트의 개발 과정을 거쳤다. 이는 모든 다운스트림 워크로드가 예상대로 동작한다는 증명과는 다르다. 애플리케이션 신뢰성은 배포 환경이 요구하는 동작에 달려 있다.
성공적인 실행은 제한적인 관찰이다. 특정 구성에서 해당 시도 동안 작동 가능한 상태에 도달했음을 보여 준다. 더 긴 요청, 반복 사용 또는 애플리케이션이 아직 실행하지 않은 상호작용에 관한 질문에는 답하지 못한다.
성능 관찰에도 맥락이 필요하다. 모델을 로드하는 일과 텍스트를 생성하는 일은 서로 다른 작업이다. 관찰자가 그 시간 구간에 무엇이 일어났는지 식별할 수 없다면, 달라진 대기 시간은 큰 의미가 없다.
하드웨어 배치는 또 다른 변수를 도입한다. 그래픽 처리 장치(GPU)는 컴퓨터의 주 프로세서와 함께 또는 이를 대신해 모델 계산을 실행할 수 있다. 서로 다른 배치는 겉보기에 유사한 실행 간 비교를 복잡하게 만들 수 있다.
Ollama의 실행 구성 문서는 프로세스 표시가 모델이 프로세서 메모리, GPU 메모리 또는 양쪽 모두에 로드됐는지를 식별한다고 설명한다. 이러한 기존 가시성은 조사자가 자신의 환경을 설명하는 데 도움이 된다. 이는 이 후보 버전에 새롭게 발표된 기능이 아니다.
다른 변수에는 모델 아티팩트와 요청 구성이 포함된다. 양자화 모델은 매개변수를 표현하기 위해 낮은 수치 정밀도를 사용한다. 서로 다른 표현을 비교하면 또 하나의 변경이 추가되므로 런타임 업데이트의 효과를 분리하기가 더 어려워진다.
구조화된 출력을 기대하는 애플리케이션에서는 완료 시간만큼 최종 결과도 중요하다. 구조화된 출력은 예상 형식으로 제한된 텍스트를 의미한다. 애플리케이션의 형식 요구사항을 위반하는 응답은 빠르게 도착하더라도 후속 작업을 만들 수 있다.
이러한 고려사항은 보고된 결함이 아니라 분석적 평가 기준이다. 이 기사를 위해 검토한 검증된 근거는 후보 버전이 그러한 문제를 일으킨다는 사실을 입증하지 않는다. 이는 배포 관련 주장을 뒷받침하는 데 필요한 관찰의 종류를 식별한다.
이 릴리스를 보안 비상사태로 묘사할 근거도 없다. 짧은 발표는 긴급한 보안 개선을 설명하지 않은 채 의존성 업데이트를 언급한다. 그러한 동기를 지어내면 독자에게 도입을 앞당길 근거 없는 이유를 제공하게 된다.
사전 릴리스 표기도 마찬가지로 정확하게 다뤄야 한다. 이는 이 아티팩트의 공개 상태를 식별한다. 후보 버전에 결함이 있음을 입증하지도, 팀이 더 광범위한 출시를 위해 요구할 수 있는 보증을 제공하지도 않는다.
공정한 평가는 제한적인 결과의 가능성을 남겨 둔다. 이 업데이트는 궁극적으로 특정 모델이나 구성에 가장 큰 의미를 가질 수 있다. 다른 배포 환경에서 눈에 띄는 차이가 거의 없더라도, 이는 여전히 유용한 유지보수를 의미한다.
따라서 가장 강한 회의적 관점은 근거의 품질에 관한 것이다. 독자는 폭넓게 명명된 의존성 변경에 보편적인 이점을 부여하지 말아야 한다. 적절한 결론은 관찰된 동작을 따르며, 모델·하드웨어·애플리케이션 맥락을 함께 제시해야 한다.
Ollama v0.40.9 이후 주목할 점
다음으로 유용한 근거는 릴리스 상태, 모델 통합, 재현 가능한 워크로드 결과에 관한 것이며, 이 순서로 중요하다. 각 신호는 서로 다른 미해결 질문에 답한다.
첫 번째 신호는 현재 후보 버전을 넘어선 릴리스의 진행이다. 후속 안정 버전 공개는 배포 상태의 변화를 입증한다. 함께 제공되는 노트는 최종 릴리스가 동일한 의존성 범위를 유지하는지도 명확히 할 수 있다.
수정되거나 업데이트된 비교 링크는 릴리스를 감사하기 쉽게 만들 것이다. 공개된 아티팩트는 rc1인데 현재 rc0 엔드포인트이므로 주의가 필요하다. 명확한 정렬은 변경 사항을 추적하는 독자의 모호성을 줄일 것이다.
어느 발전도 그 자체로 성능 향상을 입증하지는 않는다. 안정 버전 표기는 릴리스 상태를 다룬다. 완전한 비교는 추적 가능성을 다룬다. 두 요소 모두 워크로드 결과를 별도 근거에 맡기면서 릴리스를 정확히 설명하는 데 대한 신뢰를 높일 것이다.
두 번째 신호는 업스트림 모델 작업에 대한 명시적인 애플리케이션 수준 문서다. 대상 llama.cpp 버전은 FlintForCausalLM 지원을 식별한다. 더 구체적인 Ollama 정보는 독자가 이 업스트림 이정표를 지원되는 애플리케이션 동작과 연결하는 데 도움이 될 것이다.
유용한 근거는 관련 모델 아티팩트와 실행 환경을 식별할 것이다. 또한 성공적인 모델 로딩과 애플리케이션에서의 성공적인 사용을 구분할 것이다. 이러한 세부 사항은 실질적인 호환성 이점에 대한 근거를 강화할 것이다.
반대로 해결되지 않은 통합 제한 사항은 영향을 받는 사용자에게 업스트림 추가 기능의 중요성을 좁힐 것이다. 그렇다고 의존성 업데이트가 사라지는 것은 아니다. 이는 업스트림 구현이 사용 가능한 배포 경로와 분리된 상태로 남아 있는 지점을 보여 줄 것이다.
세 번째 신호는 대표적인 워크로드에서 얻은 재현 가능한 근거다. 유용한 비교는 소프트웨어 버전과 하드웨어를 식별하면서 모델과 애플리케이션 입력을 동일하게 유지할 것이다. 그러면 후보 버전의 효과를 더 쉽게 평가할 수 있다.
중요한 결과는 애플리케이션에 따라 달라진다. 대화형 도구에는 수용 가능한 응답 동작이 필요하다. 공동 서비스에는 수요를 예측 가능하게 처리하는 능력이 필요하다. 문서 어시스턴트에는 제공된 자료에 근거한 유용한 답변이 필요하다.
다른 개발자가 조건을 이해하고 재현할 수 있을 때 보고서는 더 설득력을 얻는다. 업데이트가 더 빠르게 느껴진다는 고립된 주장은 단서를 제공한다. 문서화된 비교는 다른 사람이 평가할 수 있는 근거를 제공한다.
결과는 그 범위도 유지해야 한다. 특정 구성에서의 개선은 해당 구성에 대한 근거를 강화한다. 이것이 요구사항이 다른 다른 모델, 기기 또는 애플리케이션으로 자동 이전되는 것은 아니다.
향후 몇 달 동안 이러한 신호는 업데이트가 일상적인 유지보수에 머무를지, 더 분명한 실질적 의미를 얻게 될지를 결정할 것이다. 현재 기록은 유지보수라는 설명을 뒷받침한다. 추가 근거는 이점을 더 구체적으로 만들 수 있다.
Ollama v0.40.9를 평가하는 개발자는 사용자에게 중요한 애플리케이션 동작부터 시작해야 한다. 비교를 기록할 때는 완전한 후보 식별자, 모델 아티팩트, 요청 입력, 하드웨어 맥락을 보존하라. 로딩, 생성, 답변의 사용성에 관한 관찰은 구분해서 유지하라. 후보 버전이 제한 사항을 해결한다면, 다른 개발자가 관련성을 평가할 수 있도록 그 제한 사항을 정확히 설명하라. 동작이 변하지 않았다면 이를 보편적인 판정으로 바꾸지 말고 해당 결과를 보존하라. 특히 상태나 모델 지원의 변경과 관련해 후속 릴리스 노트를 이러한 관찰과 함께 읽어라. 도입 결정은 워크로드가 만들어 내는 근거에 기반하고, 다른 사람이 같은 주장을 평가할 수 있을 만큼 충분한 맥락을 공유하라.
