Ollama v0.40.16, Ripple Preview 추가 및 코딩 에이전트 제어 강화

Ollama v0.40.16은 65B 코딩 모델을 추가하는 한편, 코딩 도구가 선택한 모델을 사용하고 제출된 컨텍스트를 보존하는지라는 덜 눈에 띄는 문제를 다룬다. 이번 업데이트는 Ripple Preview 지원과 메모리 사용량, 모델 라우팅, 요청 처리 변경을 결합했다. 로컬 코딩 에이전트를 평가하는 개발자라면 모델 역량과 함께 이러한 운영 세부 사항에도 주목할 필요가 있다.

핵심적인 긴장은 모델을 상호 교체 가능하게 만드는 것과 동작을 예측 가능하게 만드는 것 사이에 있다. 코딩 애플리케이션은 연결에 성공하더라도 모델 선택이나 지나치게 긴 대화를 운영자가 예상한 방식과 다르게 처리할 수 있다. 소프트웨어가 저장소 전체의 파일을 읽고, 편집안을 제안하며, 명령을 실행할 때 이 차이는 중요해진다.

LM Studio 역시 Claude Code를 대체 모델에 연결하는 기능을 지원하며, 이러한 접근 방식이 Ollama에만 국한되지 않음을 보여 준다. 실질적인 비교는 점점 전체 작업 세션을 포괄한다. 어떤 모델이 답변하는지, 어떤 정보가 유지되는지, 실패가 얼마나 명확하게 드러나는지가 여기에 포함된다. 이번 릴리스는 특정 모델이 이제 경쟁 모델보다 뛰어나다고 단정하지 않으면서도, 이러한 차원에서 살펴볼 수 있는 구체적인 변경 사항을 제공한다.

Ollama v0.40.16이 코딩 워크플로에 가져오는 변화

Ollama의 GitHub 페이지에 따르면 회사는 11월 9일 이 릴리스를 공개했다. 릴리스 변경 사항에는 Ripple Preview가 도입됐으며, Apple silicon에서 Qwen3.8 Flash Next의 메모리 사용량이 약 27 GiB 줄었다고 보고됐다. 또한 Claude Code 라우팅, 종료된 클라우드 모델, 입력 잘림, 비어 있는 모델 목록 문제도 다룬다.

이번 업데이트는 모델 가용성과 코딩 세션을 둘러싼 제어 기능을 모두 다룬다.

나머지 변경 사항에는 Windows on ARM용 CUDA 13.5 지원과 언어 모델 실행에 사용되는 엔진인 llama.cpp 업데이트가 포함된다. 이러한 추가 사항은 이번 릴리스의 범위를 단일 모델 발표 이상으로 넓힌다. 다만 릴리스 노트는 운영체제나 하드웨어 구성 전반의 일반적인 성능 비교를 제공하지는 않는다.

개발자에게 가용성과 사용성의 차이는 중요하다. 모델을 추가하면 작업을 위한 또 하나의 선택지가 생긴다. 주변 제어 기능을 개선하면 예기치 않은 결과가 어떤 구성 요소에서 비롯됐는지 불확실한 상태에서도 그 선택지를 더 쉽게 평가할 수 있다.

가상의 저장소 유지보수 작업을 생각해 보자. 개발자는 모델을 선택하고, 에이전트에게 관련 파일을 검토하도록 요청하며, 해당 파일에 근거한 수정안을 기대한다. 잘못된 모델에 작업이 할당되면 평가는 잘못된 가정에서 시작된다. 일부 입력이 사라지면 결과를 해석하기가 더 어려워진다.

두 상황 모두 명백한 충돌을 필요로 하지는 않는다. 개발자가 운영 조건을 오해하는 동안에도 애플리케이션은 그럴듯한 출력을 계속 생성할 수 있다. 이 때문에 구성과 요청 처리는 배경 관리 업무가 아니라 품질 문제의 일부가 된다.

릴리스 노트는 각 수정 사항을 완전히 설명하는 범위보다도 좁다. 모든 유발 조건, 영향을 받는 구성, 남아 있는 제한 사항을 설명하지 않고 변경된 동작을 식별한다. 따라서 독자는 문서화된 변경 사항과 신뢰성에 관한 더 폭넓은 결론을 구분해야 한다.

메모리 개선에도 같은 주의가 적용된다. Apple silicon에서 특정 모델의 사용량이 줄었다고 해서 Ripple Preview에서도 동등한 절감 효과가 입증되는 것은 아니다. 또한 모든 Mac 구성이 같은 작업량을 수용할 수 있다는 뜻도 아니다.

종합하면 이러한 변경 사항은 운영상 초점을 시사한다. 모델 선택의 신뢰도를 높이고 예외 상황을 더 잘 드러내는 것이다. 이러한 해석은 수정 사항들의 조합에서 나온다. 각 항목을 새로운 아키텍처 방향의 증거로 간주할 필요는 없다.

릴리스를 평가할지 결정하는 팀이라면 기존의 마찰 지점에서 출발하는 것이 유용하다. 적합한 모델이 없었던 경우에는 모델 카탈로그 확장이 가장 중요하다. 기존 워크플로가 검증이 필요한 가정에 의존했다면 라우팅 또는 컨텍스트 수정이 가장 중요하다.

메모리 사용량 감소가 배포 결정을 바꾼다

더 작은 메모리 점유량은 팀이 이미 보유한 하드웨어에서 어떤 작업량을 수용할 수 있는지를 바꿀 때 중요하다.

메모리 용량은 모델이 실행되는지 여부만 결정하지 않는다. 세션이 얼마나 많은 정보를 유지할 수 있는지와 다른 소프트웨어를 얼마나 계속 실행할 수 있는지도 제한한다. 개발자 워크스테이션에서 관련 환경에는 편집기, 터미널, 브라우저, 저장소 자체의 서비스가 포함된다.

따라서 보고된 Qwen 개선은 실질적인 질문을 제기한다. 이제 동일한 작업을 더 여유로운 운영 조건에서 실행할 수 있는가? 이를 확인하려면 동등한 설정을 사용한 비교가 필요하다. 컨텍스트 허용량이나 모델 변형이 다르면 결과의 정보 가치는 낮아진다.

컨텍스트 윈도우는 모델이 구성된 한도 내에서 고려할 수 있는 입력과 생성 텍스트의 양이다. 이 허용량을 늘리면 리소스 요구 사항이 커질 수 있다. 따라서 모델 파일을 메모리에 넣을 수 있다고 해서 긴 코딩 세션이 계속 원활하게 반응하는지까지 판단할 수는 없다.

이 구분은 로컬 환경을 유지하는 개발자에게 부담을 준다. 이들은 릴리스 주장을 작업량 결정으로 전환해야 한다. 유용한 결과는 유난히 유리한 조건에서 성공적으로 실행하는 것이 아니라, 일상 작업을 지원하는 재현 가능한 구성이다.

가상의 사례는 그 중요성을 보여 준다. 테스트 실패를 조사하는 엔지니어는 개발 서버, 브라우저 세션, 코딩 보조 도구를 함께 열어 둘 수 있다. 이러한 작업 구성을 유지할 수 있다면 추가 메모리 여유 공간은 가치가 있다. 다른 모든 것을 종료해야 한다면 이는 다른 배포 경험에 해당한다.

이번 릴리스는 개별 장비에서 그 결과를 예측하기에 충분한 정보를 제공하지 않는다. 보편적인 최소 메모리 요구 사항이나 백분율 개선도 제시하지 않는다. 그러한 수치는 문서화된 기준선과 일치하는 측정 조건을 필요로 한다.

메모리 절감이 작업 품질을 대체해서도 안 된다. 여유 있게 실행되는 모델이라도 저장소의 관례를 놓치거나 불완전한 수정안을 제안할 수 있다. 반대로 워크스테이션에 부담을 주는 유능한 모델은 개발자의 작업을 자주 중단시켜 유용성을 떨어뜨릴 수 있다.

이는 구매 결정을 요구하지 않으면서도 명확한 평가 체계를 만든다. 팀은 동일한 작업이 올바르게 완료되는지, 워크스테이션이 계속 사용 가능한지, 결과가 반복되는지를 살펴볼 수 있다. 각 관찰은 배포 문제의 서로 다른 부분에 답한다.

기업 구매자에게 이는 하드웨어 실현 가능성과 운영상 수용 가능성을 분리해야 한다는 점도 상기시킨다. 시연은 모델이 로컬에서 실행된다는 점을 보여 줄 수 있다. 수용에는 의도된 사용자가 모델 실행 중에도 계속 작업할 수 있다는 증거가 필요하다.

따라서 메모리 변경의 의미는 조건부이지만 구체적이다. 이는 명시된 모델에 대해 테스트할 가치가 있는 구성의 범위를 넓힌다. 일상 업무 방식을 바꾸는지는 작업, 설정, 그리고 장비를 함께 사용하는 애플리케이션에 달려 있다.

모델 선택은 런타임의 책임이 되고 있다

Ollama의 Claude Code 통합은 Anthropic 호환 API를 통해 코딩 애플리케이션을 로컬 또는 클라우드 모델에 연결한다. API는 애플리케이션이 요청과 응답을 교환하는 데 사용하는 인터페이스다. 이 구성에서 애플리케이션과 답변하는 모델은 별개의 선택 사항이다.

익숙한 코딩 인터페이스가 특정 모델이나 실행 위치를 보장하는 것은 아니다.

이러한 분리는 유연성을 만든다. 개발자는 기존 작업 인터페이스를 유지하면서 다른 모델을 평가할 수 있다. 동시에 책임도 생긴다. 시스템은 구성, 실행, 후속 요청 전반에서 개발자의 선택을 보존해야 한다.

이번 릴리스의 라우팅 수정은 이러한 책임에 속한다. 실질적 가치는 간단하다. 선택한 모델이 실제로 작업을 수행해야만 평가가 작성자가 주장하는 의미를 갖는다.

이 구분은 결과를 팀 내에서 공유할 때 중요하다. 성공적인 저장소 복구를 설명하는 보고서에는 사용한 모델에 대한 신뢰할 수 있는 설명이 필요하다. 그렇지 않으면 동료가 비교를 재현하거나 자신의 결과가 다른 이유를 이해할 수 없다.

실행 위치는 또 다른 별개의 문제다. Ollama는 이 통합에서 로컬 모델과 클라우드 모델을 모두 지원한다. 따라서 Ollama를 사용한다고 해서 특정 요청이 워크스테이션에 머문다는 사실이 자동으로 확립되지는 않는다.

로컬 인터페이스라도 구성에 따라 작업을 다른 곳으로 라우팅할 수 있다. 저장소 접근을 다루는 팀은 일반적인 도구 선택 과정의 일부로 이 경로를 이해해야 한다. 이번 릴리스의 모델 선택 변경을 새로운 개인정보 보호 보장으로 해석해서는 안 된다.

더 폭넓은 경쟁 환경 역시 통합 동작에 대한 이러한 초점을 뒷받침한다. LM Studio는 Anthropic 호환 엔드포인트와 Claude Code 연결 경로를 문서화하고 있다. 따라서 두 제품 모두 개발자가 이미 사용하는 인터페이스를 통해 코딩 애플리케이션을 원래 모델 제공업체와 분리하는 방법을 제공한다.

이러한 중복이 동등한 기능 지원이나 성능을 입증하는 것은 아니다. 이는 비교 가능한 제품 방향을 보여 준다. 대체 모델이 개발자가 이미 사용하는 인터페이스를 통해 접근 가능해진다는 것이다. 의미 있는 차이는 실제 작업, 구성 변경, 실패 복구 과정에서 드러난다.

Ollama 코딩 에이전트의 경우 모델 실행과 요청을 관리하는 소프트웨어인 런타임도 평가의 일부가 된다. 모델 품질은 여전히 필요하다. 그러나 개발자는 애플리케이션, 구성, 모델 간의 의도된 관계를 유지하기 위해서도 런타임에 의존한다.

이는 겉보기에는 작은 라우팅 수정이 모델 출시와 함께 언급될 만한 이유를 설명한다. 새 모델은 평가할 대상을 만든다. 올바른 선택은 그 평가를 해석 가능하게 한다.

실험을 문서화하는 팀에게 검색 가능한 지식 기반은 설정, 작업 설명, 관찰된 실패를 보존할 수 있다. 이 기록은 나중에 결과가 달라질 때 모델의 약점과 구성 차이를 구분하는 데 도움이 된다.

여기서 경쟁 압력은 통합 품질에 가해진다. 연결 지원은 출발점의 요건이다. 작업 세션 전반에 걸쳐 이해 가능한 동작을 유지하는 것은 지속적인 의무다.

명시적인 컨텍스트 처리는 실패를 더 쉽게 해석하게 한다

모델 상호작용을 위한 요청 엔드포인트인 /v1/responses 변경 사항은 Ripple Preview와 별개로 주목할 만하다. Ollama는 이제 truncation 설정을 준수하고 기본적으로 입력을 조용히 줄이지 않는다고 밝혔다. 잘림은 적용 가능한 한도에 맞추기 위해 입력을 제거하는 것을 의미한다.

가시적인 입력 한도는 개발자가 에이전트의 답변을 판단할 수 있는 더 명확한 근거를 제공한다.

조용한 축소는 해석 문제를 만든다. 일부 자료가 모델에 도달하지 않았는데도 개발자는 에이전트가 전체 작업을 고려했다고 믿을 수 있다. 그럴듯한 응답만으로는 시스템이 실제로 어떤 정보를 유지했는지 거의 보장할 수 없다.

가상의 코드 검토에서 누락된 자료에는 호환성 요구 사항에 대한 설명이 포함될 수 있다. 제안된 편집은 단독으로 보면 타당해 보이지만 그 요구 사항과 충돌할 수 있다. 입력 처리의 가시성이 없다면 검토자는 조사해야 할 또 하나의 불확실성에 직면한다.

명시적으로 잘림을 알린다고 해서 컨텍스트 한도 문제가 사라지는 것은 아니다. 애플리케이션은 여전히 자신이 사용할 수 있는 범위를 초과한 요청을 어떻게 처리할지 결정해야 하며, 여기에는 내용을 축약할지, 요약할지, 검색할지, 거부할지가 포함된다.

요약은 앞선 자료를 더 짧은 형태로 압축한다. 검색은 더 큰 정보 집합에서 관련 정보를 골라낸다. 두 접근법 모두 컨텍스트 관리에 도움이 될 수 있지만, 각각 무엇을 남길지에 대한 판단을 수반한다.

이러한 판단은 애플리케이션의 동작과 평가에 속한다. 세션 전체에서 제출된 모든 문자가 계속 이용 가능하다고 가정하는 문제로 사라져서는 안 된다. 이번 릴리스 변경으로 그 가정을 재검토하는 일이 더욱 중요해졌다.

Ollama의 호환성 문서는 OpenAI API의 일부 기능을 지원한다고 설명한다. 요청 형식이 공유된다고 해서 모든 기능이나 상태 관리 패턴까지 동일하게 지원되는 것은 아니므로, 이 단서는 중요하다.

따라서 기존 클라이언트는 기본 요청이 성공하더라도 검증이 필요할 수 있다. 중요한 질문은 해당 애플리케이션이 실제로 사용하는 기능에 관한 것이다. 완전한 호환성에 대한 광범위한 주장은 문서와 릴리스 노트의 범위를 벗어난다.

빈 모델 목록 변경은 더 작은 규모에서 관련된 문제를 다룬다. 빈 목록은 항목이 없는 컬렉션을 명확히 나타낸다. null 값은 그것이 부재를 의미하는지, 지원되지 않는 결과인지, 또는 다른 상태인지를 클라이언트가 판단하도록 요구한다.

선택기를 표시하기 전에 모델을 탐색하는 소프트웨어에서는 예측 가능한 응답 구조가 모호성을 줄인다. 이는 모델의 추론 능력을 개선하지는 않는다. 대신 애플리케이션이 환경을 정확하게 표현하는 능력을 향상한다.

지원 종료된 클라우드 모델에 대한 설명도 같은 일반적 목적을 가진다. 사용할 수 없는 모델과 일시적인 연결 실패에는 서로 다른 대응이 필요하다. 더 명확한 진단 정보는 사용자가 이 두 상황을 같은 것으로 취급하지 않도록 돕는다.

이러한 변경은 공통된 실용적 메커니즘을 공유한다. 즉, 주변 애플리케이션이 처리해야 하는 상태를 드러낸다. 이는 성공한 것처럼 보이는 인터페이스 뒤에 숨은 가정보다 명시적인 복구 동작에 주목하게 만든다.

유지관리자에게 즉각적인 의미는 기존 우회 로직을 검토해야 한다는 점이다. 이전 동작을 전제로 작성된 로직은 더 이상 필요 없거나 혼란스러운 결과를 낼 수 있다. 적절한 대응은 보편적인 마이그레이션 방법이 아니라 애플리케이션에 따라 달라진다.

Ripple Preview는 선택지를 넓히지만 성능을 확정하지는 않는다

Ricursive Intelligence는 Ripple Preview를 추론 중 사용되는 학습된 수치값인 650억 개의 매개변수를 가진 밀집형 모델이라고 설명한다. 밀집형이란 모델 텍스트의 단위인 각 토큰을 처리할 때 이러한 매개변수가 모두 참여한다는 뜻이다. 이 모델은 도구를 사용해 작업을 반복 수행하는 에이전트형 코딩에 초점을 둔다고 밝힌다.

Ripple 모델 카드는 코딩 벤치마크 결과를 제시하며, 평가 설정에 따라 점수가 달라질 수 있다고 경고한다. 회사가 보고한 이 결과는 모델을 살펴볼 근거가 된다. 그러나 모든 로컬 코딩 애플리케이션에서 동등한 성능을 입증하지는 않는다.

Ripple Preview의 이용 가능성은 일상적인 개발을 위한 검증된 순위가 아니라 평가 기회를 만든다.

벤치마크는 정의된 설정에서 성능을 측정한다. 개발자의 작업 환경에는 리포지토리 규칙, 도구 권한, 애플리케이션 동작, 하드웨어 제약이 추가된다. 기반 모델이 동일하더라도 이러한 조건의 차이는 중요할 수 있다.

이는 특히 모델 값을 표현하는 데 쓰이는 수치 정밀도를 낮추는 양자화와 관련이 있다. 양자화된 변형은 리소스 요구량을 줄일 수 있지만, 다른 정밀도에서 보고된 결과를 자동으로 적용해서는 안 된다.

동일한 구분은 모델 주변의 프롬프트, 도구, 실행을 제어하는 소프트웨어인 에이전트 하니스에도 적용된다. 모델과 하니스는 함께 작동해 결과를 만든다. 두 구성 요소 중 하나라도 바꾸면 비교 대상이 달라진다.

Ricursive가 공개한 자료는 모델을 조사해야 할 긍정적 근거를 제공하면서 평가의 복잡성도 인정한다. 이 한계를 의미 있게 만들기 위해 별도의 비판자를 만들어낼 필요는 없다. 가장 설득력 있는 회의적 관점은 보고된 평가 조건과 독자가 의도하는 배포 환경 사이의 거리다.

이 차이는 긴 작업에서 특히 중요하다. 단일 요청을 완료하는 일은 파일 검사, 명령 결과, 수정, 테스트 전반에서 올바른 계획을 유지하는 일과 다르다. 설득력 있는 시연은 실수와 복구를 포함한 과정을 보여줘야 한다.

리포지토리 유지관리 작업에서 유용한 결과에는 근거가 있는 수정과 관련 테스트 결과가 포함된다. 또한 개발자가 에이전트의 해석을 바로잡아야 했는지도 보여야 한다. 최종 패치만으로는 상당한 개입이 있었음을 숨길 수 있다.

유용한 출력이 도착하기까지의 지연인 지연 시간도 이 평가에 포함된다. 모델이 수용 가능한 답변을 내놓더라도 대화형 작업을 답답하게 만들 수 있다. 순수 출력 속도만으로는 계획을 다시 검토하거나 실패한 작업을 반복하는 데 드는 시간을 포착할 수 없다.

라이선스와 로컬 실행은 이러한 역량 문제와 별개다. 모델 가중치에 접근할 수 있다고 해서 워크스테이션에 편리하게 배포할 수 있는 것은 아니다. 마찬가지로 로컬에서 실행되는 모델이 자동으로 더 나은 리포지토리 판단을 내리는 것도 아니다.

Ollama v0.40.16은 Ripple Preview를 실용적인 비교에 포함하기 쉽게 만든다. 릴리스 자체가 팀의 작업에서 해당 모델이 기존 모델과 비교해 어떤 성능을 내는지는 해결하지 않는다.

적절한 결론은 구체적이다. 개발자는 Ollama 안에서 테스트할 또 하나의 코딩 중심 선택지를 얻었다. 우수성에 대한 주장은 비교 가능한 작업, 공개된 조건, 모델 출시 발표를 넘어서는 결과를 필요로 한다.

개발자가 향후 3개월 동안 주목해야 할 사항

다음으로 유용한 증거는 리소스 사용량, 구성 정확성, 완료된 코딩 작업을 연결할 것이다.

첫 번째 신호는 Apple silicon에서 Qwen3.8 Flash Next의 재현 가능한 메모리 측정치다. 보고서에는 머신, 모델 변형, 컨텍스트 설정, 측정 방식을 명시해야 한다. 동등한 조건은 보고된 절감 효과가 실제로 활용 가능한 여유 공간으로 이어지는 지점을 확인하는 데 도움이 된다.

여러 구성에서 나온 증거는 배포 가능성을 강화할 것이다. 일관되지 않은 결과는 그 가능성을 좁히고, 설명이 필요한 설정 또는 하드웨어 차이를 가리킬 것이다. 어느 쪽이든 운영 조건 없이 릴리스 수치만 반복하는 것보다 더 유익하다.

두 번째 신호는 실제 코딩 애플리케이션을 통한 Ripple Preview의 작업 단위 평가다. 유용한 보고서는 리포지토리 작업을 설명하고 최초 요청과 최종 결과 사이에 어떤 일이 있었는지 보여줄 것이다. 여기에는 실패한 시도와 사람의 수정도 포함된다.

비교 가능한 작업에서 성공한 실행 결과는 도입 근거를 강화할 것이다. 최종 코드가 테스트를 통과하더라도 상당한 개입이 필요했던 결과는 결론을 제한한다. 개발자는 결과를 만들어내기 위해 어느 정도의 감독이 필요했는지 알아야 한다.

이러한 평가는 모델의 한계와 통합 실패도 구분해야 한다. 잘못된 모델 선택은 모델 비교를 무효화한다. 누락된 입력은 비교를 복잡하게 만든다. 작업 결과의 작은 차이가 설득력을 얻으려면 주변 제어 기능이 먼저 신뢰할 수 있어야 한다.

세 번째 신호는 애플리케이션이 변경된 요청 동작을 어떻게 처리하는지다. 유지관리자는 과도한 크기의 요청이 이해할 수 있는 피드백을 제공하는지, 지원 종료된 모델 메시지가 사용자를 적절한 다음 행동으로 이끄는지 살펴봐야 한다. 명확한 복구는 명확한 거부만큼 중요하다.

예측 가능한 처리의 증거는 이번 릴리스의 운영상 가치를 뒷받침할 것이다. 반복되는 혼란은 그에 대응하는 애플리케이션 동작이 없다면 런타임 변경만으로는 충분하지 않음을 보여줄 것이다. 더 명시적인 응답에도 이를 합리적으로 해석하는 클라이언트는 필요하다.

이러한 신호를 함께 보면 극적인 시장 변화를 가정하지 않고 Ollama 코딩 에이전트를 따라갈 수 있는 현실적인 방법이 된다. 이는 명시된 조건에서의 리소스 사용량, 완료된 작업, 이해 가능한 실패라는 관찰 가능한 결과에 초점을 맞춘다.

또한 낙관적인 해석에 반하는 근거가 무엇인지도 분명히 한다. 이례적인 설정에서만 잘 작동하는 새 모델은 대상 사용자가 더 제한적이다. 일반적인 워크로드에서 사라지는 메모리 절감은 이점이 더 제한적이다. 애플리케이션이 숨기는 명시적 오류는 해결되지 않은 사용성 문제로 남는다.

이미 Ollama를 사용하는 개발자에게 이번 릴리스는 그 변경 사항이 기존 워크플로와 만나는 지점에서 주목할 가치가 있다. 도입을 검토하는 팀은 별개의 주장을 하나의 약속으로 합치는 일을 피해야 한다. 모델 이용 가능성, 더 낮은 메모리 사용량, 수정된 라우팅은 서로 다른 질문에 답한다.

Ollama v0.40.16을 팀이 이미 잘 이해하는 리포지토리 작업으로 평가하라. 이후 비교에서 신뢰할 수 있는 기준을 갖도록 작업 내용, 선택한 모델, 컨텍스트 설정, 관찰된 결과를 보존하라. 대화형 출력만으로 시스템을 판단하기보다 관련 파일을 읽고 수정 사항을 검증해야 하는 작업을 포함하라. 애플리케이션이 사용할 수 없는 모델을 식별하고 입력 한도 동작을 이해하기 쉽게 만드는지 살펴보라. 사용 범위를 확대하기 전에 이미 정착된 환경과 경험을 비교하라. 가장 유용한 결정은 이번 릴리스가 실제 작업에서 어디의 마찰을 줄이는지 아는 데서 나온다. 어떤 문서화된 변경이 그 작업을 개선하며, 팀의 다른 개발자를 설득하려면 어떤 증거가 필요한가?