SageMaker JumpStart의 NVIDIA Nemotron: Super VL, 멀티모달 배포 선택지 확대

NVIDIA의 1,200억 파라미터 Nemotron 3.5 Super VL을 이제 Amazon SageMaker JumpStart를 통해 이용할 수 있어, 기업용 멀티모달 애플리케이션에 또 하나의 배포 옵션이 추가되었습니다. SageMaker JumpStart에 Nemotron이 도입되면서 AWS의 모델 배포 워크플로 내에서 텍스트, 이미지, 비디오 처리가 가능해졌습니다. 또한 모델 기능과 배포 설정의 차이가 특히 중요해졌습니다.

AWS는 2026년 11월 9일 이 이용 가능성을 발표했습니다. Super VL 배포는 압축 수치 형식인 NVFP4와 더 높은 정밀도의 기준 변형인 BF16을 제공합니다. 지원 하드웨어에는 NVFP4용 G7 인스턴스와 BF16용 P5en이 포함됩니다. 이번 발표는 새로 출시된 모델이 아니라 접근성과 서빙 옵션에 관한 것입니다.

기업 개발자에게 핵심적인 절충점은 배포 편의성과 구성 제어 간의 균형입니다. JumpStart는 패키지화된 출발점을 제공하지만, 애플리케이션 팀은 여전히 워크로드 설계와 평가를 책임집니다. 같은 카탈로그에는 이미 Qwen3-VL과 DeepSeek OCR 같은 대안이 포함되어 있습니다. NVIDIA는 문서 해석, 시각적 추론, 에이전트 워크플로를 아우르는 모델로 기존의 선택 과정에 참여합니다.

SageMaker JumpStart의 Nemotron이 바꾸는 점

즉각적인 변화는 기존 멀티모달 모델을 위한 지원되는 AWS 배포 경로입니다.

비전 언어 모델은 시각 자료를 텍스트와 함께 처리하고 텍스트 응답을 생성합니다. 이에 따라 Super VL은 스크린샷, 스캔 기록, 다이어그램, 비디오를 다루는 애플리케이션에 적합할 수 있습니다. JumpStart를 통한 제공은 개발자에게 AWS 환경 안에서 이러한 기능을 평가할 또 다른 방법을 제공합니다.

NVIDIA의 BF16 기준 모델은 총 1,200억 개의 파라미터와 처리 중 활성화되는 120억 개의 파라미터를 명시합니다. 파라미터는 모델의 동작을 형성하는 학습된 수치 값입니다. 이 모델의 전문가 혼합 아키텍처는 모든 토큰에 대해 모든 파라미터를 사용하는 대신 네트워크 일부를 선택적으로 활성화합니다.

토큰은 텍스트 조각과 시각 입력의 표현을 포함해 모델이 처리하는 단위입니다. NVIDIA는 최대 100만 토큰의 컨텍스트 길이를 지원한다고 홍보합니다. 컨텍스트에는 모델에 제공되는 자료와 모델이 생성하는 응답이 포함됩니다.

AWS 구성은 더 제한적입니다. 공개된 JumpStart 서빙 프로필은 520~15,600토큰 범위이며, 패키지 구성에서는 추측 디코딩이 비활성화되어 있습니다. 추측 디코딩은 미래 토큰을 제안하고 검증해 생성을 가속합니다. 광고된 컨텍스트 상한이나 모든 아키텍처 기능이 배포된 엔드포인트에 자동으로 적용되는 것은 아닙니다.

이 차이는 구매자가 이번 발표를 해석하는 방식에 영향을 주어야 합니다. 모델 목록은 배포 기회를 제시합니다. 그렇다고 모든 애플리케이션이 즉시 모델의 최대 광고 설정을 사용할 수 있다는 뜻은 아닙니다.

개발 팀에 유용한 질문은 구체적입니다. 제공되는 구성이 실제 작업을 수용하는가? 스크린샷 해석 기능, 문서 검토 서비스, 비디오 분석 애플리케이션은 각기 다른 요구사항을 가집니다. 이들을 서로 교환 가능한 멀티모달 워크로드로 취급하면 그러한 차이가 가려집니다.

제안된 송장 검토 애플리케이션을 생각해 보겠습니다. 목표에는 보이는 필드 추출, 누락 정보 식별, 직원용 응답 준비가 포함될 수 있습니다. 성공 여부는 정확한 해석과 불확실성의 적절한 처리에 달려 있습니다. 배포 경로만으로는 어느 결과도 보장할 수 없습니다.

같은 차이는 데모에도 적용됩니다. 선택된 사례에 대한 인상적인 응답은 추가 테스트의 근거가 될 수 있습니다. 그러나 회사의 전체 문서 컬렉션이나 운영 프로세스 전반에서의 신뢰성을 입증하지는 못합니다.

따라서 SageMaker JumpStart의 Nemotron은 평가의 출발점을 바꿉니다. 팀은 다른 배포 접근 방식과 함께 AWS 패키지 옵션을 고려할 수 있습니다. 결정은 카탈로그 제공 여부에서 끝나는 것이 아니라 워크로드 적합성으로 향합니다.

이미 NVIDIA 모델을 평가 중인 구매자에게 이는 실질적인 선택지 확대입니다. 다른 모든 이에게는 증거가 필요한 또 하나의 후보입니다. 모델의 규모는 아키텍처를 설명할 뿐이며, 애플리케이션의 결과가 그 유용성을 결정해야 합니다.

기업 팀은 더 구체적인 구매 결정을 내려야 합니다

압력은 애플리케이션이 실제로 수행하는 작업에 맞춰 모델 선택을 정당화해야 하는 팀에 집중됩니다.

멀티모달 기능에 대한 일반적 주장은 기업 구매 결정을 내리기에 충분하지 않습니다. 조달 팀은 어떤 작업이 개선되는지, 어떤 작업은 여전히 어려운지, 어떤 운영 책임이 따르는지에 대한 설명이 필요합니다. 개발자에게도 같은 설명이 측정 가능한 형태로 필요합니다.

Nemotron 비전 언어 모델은 여러 작업 범주를 검토 대상으로 가져옵니다. 그러나 광범위한 기능 목록은 더 좁은 평가 계획으로 이어져야 합니다. 문서 추출을 찾는 조직은 후보 모델이 비디오도 지원하더라도 문서 추출부터 시작해야 합니다.

이러한 초점은 내부 이해관계자와의 대화를 바꿉니다. 모델이 전반적으로 유능해 보이는지를 묻는 대신, 팀은 특정 프로세스에 대해 허용 가능한 출력을 정의할 수 있습니다. 그런 다음 정의되지 않은 지능의 기준을 두고 논쟁하지 않고도 실패 사례를 검토할 수 있습니다.

예를 들어 공급업체 양식을 검토하는 서비스를 상상해 보겠습니다. 관련 평가는 읽기 쉬운 양식, 모호한 레이아웃, 불완전한 제출물, 에스컬레이션이 필요한 기록을 포함할 것입니다. 이는 보고된 고객 결과가 아니라 제안된 테스트 사례입니다.

중요한 비즈니스 질문은 전체 검토의 결과에 관한 것입니다. 그럴듯해 보이지만 광범위한 수정이 필요한 답변은 신뢰성 있게 사용할 수 있는 추출과 다른 이점을 제공합니다. 둘 다 측정할 가치가 있지만 같은 이름으로 분류해서는 안 됩니다.

더 작은 대안도 이 평가에 포함되어야 합니다. AWS의 이전 멀티모달 카탈로그 확장에는 Qwen3-VL-8B-Instruct와 DeepSeek OCR이 포함되었습니다. AWS는 Qwen을 비전 언어 작업용으로, DeepSeek OCR을 문서 처리용으로 제시했습니다. 이러한 설명은 Super VL과의 순위를 확정하지 않은 채 사용 사례가 겹친다는 점을 보여 줍니다.

좁은 문서 워크플로는 전문화를 선호할 수 있습니다. 더 광범위한 애플리케이션은 여러 작업에서 공통 모델을 사용하는 가치를 높게 볼 수 있습니다. 실제 입력과 출력을 테스트하지 않으면 어느 선호도 결정의 근거가 될 수 없습니다.

이는 플랫폼 팀과 모델 공급업체 모두에게 압력을 가합니다. 플랫폼 팀은 애플리케이션에 특정 모델의 폭넓은 기능이나 규모가 필요한 이유를 설명해야 합니다. 공급업체는 기능 주장을 구매자의 운영 조건과 관련 있게 만들어야 합니다.

비교에는 예외를 처리하는 사람도 포함되어야 합니다. 직원이 불확실한 답변을 조사해야 한다면, 그 노력은 평가에 포함되어야 합니다. 작업을 보이지 않는 검토 대기열로 옮기는 워크플로는 일상적 사용보다 데모에서 더 좋아 보일 수 있습니다.

지식 근로자에게는 관련된 우려가 있습니다. 유용한 해석은 검색 가능한 증거와 연결된 상태를 유지해야 합니다. 독자가 그 배경 자료를 찾을 수 없으면 생성된 요약은 신뢰하기 어려워집니다. 처리와 검색 간의 이러한 관계는 AI 지식 베이스를 설계할 때도 중요합니다.

실질적인 구매 결과는 더 큰 구체성입니다. 팀은 명시적인 검토 요구사항을 갖춘 정의된 작업에 맞춰 후보 시스템을 비교해야 합니다. 카탈로그 접근성은 비교를 시작하기 쉽게 만들며, 문서화된 평가는 최종 선택을 방어 가능하게 만듭니다.

Nemotron NVFP4와 BF16은 배포 결정입니다

정밀도 선택은 품질과 운영 동작을 함께 고려하는 완전한 배포 구성으로 평가해야 합니다.

NVIDIA의 NVFP4 모델 카드는 메모리 요구사항을 줄이도록 설계된 양자화 릴리스를 설명합니다. 양자화는 더 적은 비트로 모델 값을 표현합니다. NVIDIA는 압축 변형을 만들면서 동작을 보존하려는 학습 과정인 양자화 인식 증류를 사용합니다.

이 릴리스는 혼합 정밀도를 사용하므로 서로 다른 모델 구성 요소가 서로 다른 수치 형식을 유지합니다. 따라서 이를 4비트 모델이라고 부르더라도 모든 구성 요소가 동일한 정밀도를 사용한다는 의미로 받아들여서는 안 됩니다. NVIDIA는 이 변형을 텍스트 및 비전 언어 에이전트의 효율적인 배포용으로 제시합니다.

BF16은 다른 기준 역할을 합니다. NVIDIA는 BF16 가중치가 맞춤화, 도메인 적응, 전체 정밀도 평가에 적합하다고 설명합니다. 이러한 용도는 이용 가능한 모델 가중치와 더 폭넓은 개발 옵션에 관한 것이며, 모든 호스팅 엔드포인트의 자동 기능은 아닙니다.

NVIDIA가 공개한 비교에서는 표준화된 평가 작업인 여러 벤치마크에서 두 변형이 유사한 결과를 보입니다. 회사는 BF16과 NVFP4에 대해 동일한 62.82의 MMLongBench-Doc 점수와 각각 32.85 및 32.54의 Video-MME v2 점수를 보고했습니다. 이는 여전히 공급업체가 보고한 측정치입니다.

이 수치는 압축 변형을 진지하게 검토할 근거를 제공합니다. 하지만 특정 기업의 문서, 스크린샷, 비디오에서 동등한 동작을 보장하지는 않습니다. 벤치마크 비교는 평가를 이끌 수 있지만 이를 대체할 수는 없습니다.

구매자에게 유용한 Nemotron NVFP4 대 BF16 질문은 배포된 애플리케이션에 관한 것입니다. 어느 구성이든 요구되는 품질 기준을 충족하는가? 요청이 더 어려워지거나 동시에 들어올 때 각각은 어떻게 동작하는가?

하드웨어도 이 비교에 속합니다. 하나의 가속기 구성에서 얻은 결과를 수치 정밀도에 대한 보편적 주장으로 바꾸어서는 안 됩니다. 그렇지 않으면 평가가 전체 시스템의 동작을 하나의 모델 설정에 귀속시킬 위험이 있습니다.

공정한 애플리케이션 비교는 동일한 작업 정의와 채점 규칙을 유지해야 합니다. 검토자는 단지 문구만 바꾸는지, 아니면 의미 있는 결과에 영향을 주는지를 살펴야 합니다. 수정된 문장은 무해할 수 있지만, 변경된 송장 합계는 그렇지 않습니다.

평가는 일반 사례와 중요한 예외도 구분해야 합니다. 두 변형이 명확한 문서를 비슷하게 처리하지만 모호한 스캔에서는 차이를 보인다고 가정해 보겠습니다. 전체 평균이 유사해 보여도 그 차이는 주목할 가치가 있습니다.

운영상 고려사항은 출력 품질과 함께 중요합니다. 더 큰 인프라 투입이 필요한 배포는 애플리케이션 요구사항과 연결된 이유를 제시해야 합니다. 반대로 오류가 의도한 워크플로를 훼손한다면 더 작은 구성에 우선권을 주어서는 안 됩니다.

이것이 Nemotron NVFP4 대 BF16이 시스템 평가에 포함되어야 하는 이유입니다. 이 결정에는 모델 동작, 서빙 선택, 하드웨어, 검토 노력이 포함됩니다. 이를 정밀도 라벨로 축소하면 기업 구매자의 핵심 질문은 답을 얻지 못합니다.

이번 발표는 이 결정을 위한 이용 가능한 구성을 넓혔습니다. 보편적으로 선호되는 변형을 확정하지는 않습니다. 가장 강력한 선택은 대표적인 조건에서 문서화된 요구사항을 충족하는 구성입니다.

패키지화된 서빙은 모델 외부의 애플리케이션 작업을 남깁니다

관리형 배포는 접근성을 간소화하지만, 애플리케이션은 여전히 인식, 근거, 행동을 연결할 책임이 있습니다.

AWS는 JumpStart foundation models를 고객이 액세스하고 머신러닝 워크플로에 통합할 수 있는 모델로 설명합니다. 이는 모델을 사용할 수 있게 하는 플랫폼의 역할을 분명히 합니다. 반면 애플리케이션별 프로세스는 개발자가 설계해야 합니다.

에이전트, 즉 모델 출력을 활용해 행동을 선택하거나 요청하는 애플리케이션을 살펴보면 이러한 구분이 더 명확해집니다. 스크린샷을 이해하는 일은 이러한 시스템의 일부입니다. 어떤 행동이 허용되는지 결정하려면 추가적인 애플리케이션 로직이 필요합니다.

직원이 비즈니스 기록을 업데이트하도록 돕는 내부 어시스턴트를 생각해 보겠습니다. 어시스턴트는 화면에 보이는 내용을 해석하고 관련 필드를 식별하며 행동을 제안할 수 있습니다. 하지만 주변 애플리케이션은 그 행동이 적절한지 여전히 판단해야 합니다.

화면에 대한 그럴듯한 설명이 기반 애플리케이션을 올바르게 제어한다는 사실을 보장하지는 않습니다. 어시스턴트는 직원의 목표를 오해하거나 부적절한 행동을 선택할 수 있습니다. 따라서 평가는 실수로부터의 복구를 포함해 완료된 작업을 검토해야 합니다.

문서에서도 책임은 유사하게 나뉩니다. 모델이 페이지를 정확히 해석하더라도 더 큰 워크플로가 이를 잘못된 기록과 연결할 수 있습니다. 해석 단계가 성공했더라도 이는 여전히 실패한 비즈니스 프로세스입니다.

따라서 제안되는 문서 서비스는 답변과 출처 간의 연결을 유지해야 합니다. 검토자는 어떤 기록에서 추출 결과가 나왔는지, 불확실성이 어디에서 발생했는지 알아야 합니다. 그렇지 않으면 이의가 제기된 답변을 조사하기가 불필요하게 까다로워집니다.

비디오는 또 다른 형태의 평가 복잡성을 더합니다. 매끄러운 요약은 설득력 있게 들릴 수 있지만 사용자의 질문에 중요한 사건을 빠뜨릴 수 있습니다. 유용한 테스트는 응답이 유창하게 읽히는지가 아니라 필요한 근거를 포착하는지를 물어야 합니다.

이러한 사례는 흔한 애플리케이션 설계 문제를 보여 줍니다. 멀티모달 입력은 시스템이 검사할 수 있는 범위를 넓히지만, 유용한 출력은 작업 정의에 달려 있습니다. 시스템은 어떤 근거가 중요한지, 그 근거가 없을 때 무엇을 해야 하는지 알아야 합니다.

엔터프라이즈 팀의 경우, 이는 모델과 함께 주변 워크플로도 평가해야 한다는 뜻입니다. 입력 준비, 기록 연결, 출력 검증, 사람의 검토는 모두 결과에 영향을 줍니다. 어느 구성 요소를 개선하든 애플리케이션의 유용성이 달라질 수 있습니다.

상업적 함의는 분명합니다. 패키지형 모델 엔드포인트는 초기 평가에 도달하기 위한 작업을 줄일 수 있습니다. 하지만 책임 있는 비즈니스 프로세스를 구축하는 데 필요한 작업까지 없애지는 않습니다.

SageMaker JumpStart의 Nemotron은 이러한 구분을 염두에 두고 평가해야 합니다. 관리형 경로는 시작 구성과 배포 워크플로를 제공합니다. 모델 응답을 신뢰할 수 있는 사용자 결과로 전환하는 책임은 애플리케이션 팀에 남아 있습니다.

이 책임은 설계를 비교할 기회이기도 합니다. 팀은 범위가 더 좁은 워크플로가 폭넓게 자율적인 어시스턴트보다 더 일관되게 작동한다는 점을 발견할 수 있습니다. 그러한 발견은 덜 극적인 시연으로 이어지더라도 유용한 제품 판단을 반영합니다.

공개된 벤치마크로는 엔터프라이즈 결과가 확정되지 않는다

벤더 평가는 모델 행동에 관한 근거를 제공하지만, 엔터프라이즈 신뢰성은 의도한 워크플로를 테스트해야 확인할 수 있습니다.

NVIDIA의 Super VL research는 이 모델 계열에 관한 기술 및 평가 맥락을 제공합니다. 이는 회사가 보고한 작업을 이해하기 위한 1차 출처입니다. 동시에 모델 개발사가 생성한 근거로 읽어야 합니다.

이러한 출처 표기는 출시 발표가 여러 주장을 하나의 인상으로 압축할 수 있기 때문에 중요합니다. 아키텍처, 벤치마크 결과, 배포 가능 여부, 애플리케이션 준비 상태는 서로 다른 질문에 답합니다. 어느 하나도 다른 하나를 조용히 대체해서는 안 됩니다.

발표와 모델 문서는 Super VL이 제공되며 의도된 용도를 설명한다는 점을 확인합니다. 그러나 임의의 엔터프라이즈 워크로드 전반에서 독립적으로 검증된 성공을 입증하지는 않습니다. 이 글은 모델을 독립적으로 벤치마크하거나 JumpStart 엔드포인트를 배포하지 않았습니다.

회의적인 평가는 출시를 일축하지 않으면서도 이러한 구분을 유지해야 합니다. 제공 가능 여부는 검증 가능한 뉴스입니다. 더 폭넓은 상업적 가치는 제공 가능 여부를 넘어서는 근거에 달려 있습니다.

추출 품질과 운영상 수용의 차이를 생각해 보십시오. 시스템은 대부분의 보이는 필드를 올바르게 재현할 수 있지만 라우팅을 결정하는 필드에서는 실패할 수 있습니다. 이 상황에서 종합 품질 점수는 신중하게 해석해야 합니다.

또 다른 불확실성은 오류가 사용자에게 어떻게 나타나는지에 관한 것입니다. 불확실성을 명시하는 것은 자신 있게 전달된 오답과는 다른 검토 문제를 만듭니다. 엔터프라이즈 평가는 정확성과 실패를 둘러싼 행동을 모두 기록해야 합니다.

워크로드 다양성은 또 다른 과제를 만듭니다. 기업의 기록은 부서, 문서 출처, 언어, 시각적 레이아웃에 따라 달라질 수 있습니다. 편의상 선택한 사례에 집중한 테스트는 더 폭넓은 배포를 위한 약한 근거를 제공할 것입니다.

같은 논리는 에이전트 작업에도 적용됩니다. 통제된 시연에서의 성공적인 행동은 변화하는 화면과 중단된 워크플로 전반에서 신뢰할 수 있는 행동을 보장하지 않습니다. 팀은 가정이 실패할 때 애플리케이션이 어떻게 대응하는지 평가해야 합니다.

이는 문서화된 Nemotron 고유의 결함이 아니라 제안된 평가 고려 사항입니다. 이용 가능한 출처는 특정 실패를 지어내거나 익명의 분석가에게 비판을 귀속할 근거가 되지 않습니다. 불확실성은 공개된 근거와 개별 구매자의 요구 사항 사이의 간극에 있습니다.

조달 결정에서도 모델 평가와 통합 노력을 구분해야 합니다. 성능이 좋은 모델도 상당한 애플리케이션 작업이 필요할 수 있습니다. 더 단순한 모델이 더 관리하기 쉬운 워크플로로 좁은 작업을 충분히 수행할 수도 있습니다.

그렇다고 폭넓은 역량이 중요하지 않다는 뜻은 아닙니다. 광범위한 모델은 애플리케이션이 실제로 그 역량 범위를 필요로 할 때 가치가 있습니다. 구매자는 그러한 필요를 식별하고 그 영향을 입증할 수 있어야 합니다.

방어 가능한 결론은 여전히 제한적입니다. Super VL은 상세한 벤더 문서의 지원을 받는, 엔터프라이즈 평가를 위한 신뢰할 만한 후보를 추가합니다. 신뢰할 수 있는 비즈니스 결과에 관한 주장은 실제 사용한 구성과 연결된 대표적 테스트 결과를 따라야 합니다.

JumpStart 출시 이후 주목할 점

다음으로 유용한 근거는 워크로드 평가, 서빙 업데이트, 문서화된 도입 사례에서 나올 것입니다.

향후 몇 달 동안 가장 먼저 주목할 신호는 대표적인 엔터프라이즈 입력을 활용한 독립 평가입니다. 유용한 보고서는 배포한 변형, 하드웨어, 작업 정의, 채점 과정을 식별할 것입니다. 또한 실패와 사람의 검토 요구 사항도 설명해야 합니다.

문서 애플리케이션의 경우, 근거는 모델 출력을 직원이 완료해야 하는 업무와 연결해야 합니다. 시각적 에이전트의 경우 완료된 작업과 복구 행동을 설명해야 합니다. 비디오의 경우 응답이 질문과 관련된 근거를 유지하는지 검토해야 합니다.

이러한 결과가 현실적인 조건에서 일관된 결과를 보인다면 도입 근거는 강해질 것입니다. 광범위한 수정이 필요한 결과는 모델의 적합한 용도를 좁힐 것입니다. 어느 결과든 또 하나의 선별된 시연보다 구매자에게 더 나은 지침을 제공합니다.

두 번째 신호는 서빙 구성의 문서화된 변경입니다. 모델 역량과 호스팅 설정은 다르므로, 구성 업데이트는 어떤 워크로드가 적합한지를 바꿀 수 있습니다. 독자는 초기 배포 범위가 영구적이라고 가정하기보다 출시 세부 사항을 검토해야 합니다.

더 큰 지원 워크로드는 패키지형 구성의 제약을 받았던 애플리케이션의 근거를 강화할 것입니다. 반대로 안정적인 한계는 개발자가 기존 범위를 중심으로 설계하도록 유도할 것입니다. 어느 결과도 발표되지 않은 기능을 제공하지 못한 실패로 취급해서는 안 됩니다.

세 번째 신호는 의미 있는 운영 세부 정보를 포함한 문서화된 프로덕션 도입입니다. 고객사 이름만으로는 워크로드 규모, 품질 요구 사항, 검토 노력에 대해 거의 알 수 없습니다. 유용한 사례는 애플리케이션이 무엇을 하고, 소유자가 성공을 어떻게 판단하는지 설명할 것입니다.

그 근거에는 출력 결과를 다루는 사람들도 포함되어야 합니다. 사용자가 시스템이 자신의 프로세스에 어떤 영향을 주는지 설명할 수 있을 때 도입은 더 많은 정보를 제공합니다. 이러한 세부 사항이 없는 배포 발표는 비즈니스 가치를 평가하기 어렵게 만들 것입니다.

이러한 신호는 이야기의 중심에 있는 구분을 유지합니다. AWS는 익숙한 배포 플랫폼을 통해 멀티모달 모델에 대한 접근성을 확대했습니다. 엔터프라이즈 유용성은 그 구성과 구매자가 수행해야 하는 업무 간의 관계에 달려 있습니다.

SageMaker JumpStart에서 Nemotron을 평가하는 팀은 입력, 허용 가능한 출력, 검토 프로세스를 이미 이해하고 있는 작업부터 시작해야 합니다. 동일한 사례를 기준으로 후보 구성을 비교하고 각 결과를 뒷받침하는 근거를 보존하십시오.

일반적인 기록과 함께 어려운 기록도 포함하십시오. 검토자가 개입하는 시점, 시스템이 불확실성을 표현하는 시점, 답변이 의도된 행동을 뒷받침하지 못하는 시점을 추적하십시오. 이후 변경 사항을 비교할 수 있도록 배포 설정을 기록하십시오.

그런 다음 이러한 발견을 바탕으로 더 폭넓은 테스트가 정당한지 결정하십시오. 워크플로의 어떤 부분이 시각적 이해의 혜택을 받을 수 있으며, 어떤 관찰 가능한 결과가 그 혜택을 입증할 수 있을까요? 이 질문에 답하면 출시를 조직에 유용하게 활용할 수 있습니다.