Claude Opus 5.5 코드 보안, GPT-6-Sol과 73% 동률…검증은 여전히 필수

Veracode의 가을 평가에서 Claude Opus 5.5 코드 보안은 GPT-6-Sol과 73% 동률을 기록하며 벤치마크의 최고점을 끌어올렸지만, 상당한 실패 사례도 남겼다. 이 결과는 이 특정 지표에서 Anthropic과 OpenAI가 동등한 수준임을 보여준다. 동시에 더 나은 코딩 모델이 실제로 얼마나 많은 검증 작업을 줄여주는지라는 구매 판단의 질문을 더욱 선명하게 만든다.

Veracode는 2026년 10월 29일 이 결과를 발표하며 평균 보안 통과율이 56%에서 62%로 상승했다고 밝혔다. 이 회사는 Python, C#, JavaScript, Java 전반에서 18개 모델을 평가했다. 이 회사의 코드 보안 결과는 프로덕션 애플리케이션에 포함될 수 있는 모든 실패가 아니라 선별된 취약점을 다룬다.

핵심 긴장은 더 나은 초안과 신뢰할 수 있는 릴리스 사이에 있다. 모델 선택은 출발점에 영향을 주지만, 검토·테스트·수정 조치는 사용자에게 도달하는 결과를 결정한다. 새 점수는 엔지니어링 리더에게 진전의 근거를 제공하지만, 더 어려운 운영상 비교는 여전히 미완으로 남는다.

Claude Opus 5.5 코드 보안, 벤치마크 최고점 끌어올려

보고된 동률은 Veracode 평가 내에서 더 높은 점수를 확립하지만, 실제 애플리케이션 전반의 동등한 보안을 입증하지는 않는다.

Veracode의 발표에 따르면 Claude Sonnet 5.5는 72%로 선두 바로 뒤를 이었고, GPT-5.6-Sol은 70%로 뒤따랐다. 이 결과는 단순한 승자 발표보다 경쟁 구도를 더 유용하게 만든다. 구매자는 여러 근접한 선택지를 갖고 있으며, 작은 벤치마크 격차가 배포 결정을 이끌기 전에는 맥락이 필요하다.

이전의 보고된 최고점은 2026년 7월 GPT-5.5의 68%였다. 이 수치와 현재 선두 모델을 비교하면 연구 시리즈 안에서의 변화를 확인할 수 있다. 그러나 최고점이 높아졌다는 사실만으로 최신 모델이 낯선 저장소, 이례적인 요구사항 또는 보안에 민감한 변경을 얼마나 일관되게 처리하는지는 알 수 없다.

벤치마크는 정해진 조건에서 채점되는 정의된 과제 집합이다. 그 가치는 산발적인 개발자 인상보다 비교를 더 통제된 방식으로 가능하게 하는 데 있다. 한계 역시 같은 경계에서 비롯된다. 과제는 선별된 상황을 대표하며, 점수는 선별된 결과를 포착한다.

Claude Opus 5.5 vs GPT-6-Sol을 비교하는 독자에게 공개된 동률은 측정된 과제에 관한 좁은 질문에 답한다. 어느 어시스턴트가 특정 기업에서 더 적은 수정 작업을 요구할지는 판단하지 못한다. 이는 주변 애플리케이션과 개발 프로세스에 달려 있다.

이 구분은 프로덕션 변경이 고립된 답변 하나를 적절하게 만드는 것 이상의 의무를 지니기 때문에 중요하다. 기존 동작을 유지하고, 접근 규칙을 준수하며, 현지 관례에 맞고, 다른 구성 요소와 안전하게 상호작용해야 한다. 긍정적인 코드 생성 점수는 이러한 의무를 없애지 않는다.

점수에도 신중한 표현이 필요하다. 보안 통과율은 평가자가 테스트된 출력물을 분류한 결과를 뜻한다. 이를 고객 애플리케이션의 동등한 비율이 안전할 것이라는 예측이나, 남은 실패가 사고를 일으킬 것이라는 주장으로 확대해서는 안 된다.

마찬가지로 실패가 영향을 받은 모든 출력의 심각도를 확정하는 것은 아니다. 도달할 수 없는 예시의 취약점은 민감한 고객 데이터를 처리하는 노출된 결함과 다르다. 그 차이를 판단하려면 헤드라인의 백분율이 제공할 수 없는 애플리케이션 맥락이 필요하다.

따라서 유의미한 진전은 더 나은 측정된 출발점이다. 팀은 그 출발점이 검토 노력, 반복되는 실수 또는 수정 시간을 줄이는지 물을 수 있다. 이는 순위의 자동적인 결과가 아니라 검증해야 할 실질적인 가설이다.

이 해석은 뉴스를 과장하지 않으면서 보존한다. Anthropic과 OpenAI는 보고된 선두를 공유하며, 분야의 측정된 성과는 개선됐다. 다음 질문은 누가 이 개선을 신뢰할 수 있는 소프트웨어로 전환해야 하는지에 관한 것이다.

엔지니어링 리더는 여전히 릴리스 결정을 책임진다

이 결과는 구매자가 모델 이름을 통해 보안을 구매하기보다 전체 개발 프로세스를 측정해야 한다는 압박을 준다.

엔지니어링 리더는 여러 변수가 움직이는 결정을 마주한다. 이들은 어시스턴트를 선택하고, 검토 역량을 배분하며, 어떤 변경에 추가적인 검토가 필요한지 결정한다. 더 높은 벤치마크 점수는 이 판단에 도움이 되지만, 그 자체로 릴리스 판단을 대신할 수는 없다.

AI가 생성한 계정 조회 기능 변경을 받는 가상의 고객 지원 애플리케이션을 생각해 보자. 제안된 코드는 일반적인 테스트 중에는 예상한 레코드를 반환한다. 그러나 검토자는 사용자가 다른 사람의 레코드를 조회할 수 없는지 여전히 확인해야 한다.

이 사례는 가상의 예시이며 Veracode 평가에서 문서화된 실패 사례가 아니다. 이는 성공적인 코드 생성과 허용 가능한 애플리케이션 동작에 서로 다른 근거가 필요한 이유를 보여준다. 모델의 답변은 조직의 실제 권한과 데이터 경계를 기준으로 평가돼야 한다.

선두 모델을 선택한 팀도 해결되지 않은 결과를 책임질 사람을 필요로 한다. 그렇지 않으면 추가 탐지는 릴리스된 소프트웨어를 개선하지 못한 채 늘어나는 대기열만 만들 수 있다. 결정, 수정, 확인의 책임은 여전히 운영 비용의 일부다.

조달 측면의 함의는 간단하다. 구매자는 보안 작업 감소라는 약속을 뒷받침하는 근거가 무엇인지 물어야 한다. 벤치마크 점수만으로 검토자 시간 감소, 더 빠른 수정 또는 배포 후 노출 감소를 입증할 수는 없다.

애플리케이션 보안 팀의 과제는 기술적 결과를 릴리스 기준으로 옮기는 데 있다. “AI 코드를 신중히 검토하라”는 말은 개별 개발자에게 지나치게 많은 해석의 여지를 남긴다. 명확한 기대치는 어떤 변경이 전문가의 주의를 필요로 하는지 더 쉽게 결정하게 한다.

개발자에게 중요한 점은 그러한 기대치가 일상 업무에 맞는지다. 변경이 완료된 뒤에야 도착하는 요구사항은 피할 수 있는 재작업을 낳는다. 의도한 동작과 수용 조건이 처음 과제와 함께 제공될 때 보안 결정을 더 쉽게 평가할 수 있다.

여기에서 문서는 실질적인 역할을 한다. 검색 가능한 지식 베이스는 엔지니어가 이전 결정, 승인된 패턴 및 관련 기술 맥락을 찾아내는 데 도움을 줄 수 있다. 문서는 검토를 지원하지만 생성된 코드를 인증하지는 않는다.

저장소 맥락을 받는 어시스턴트에도 같은 구분이 적용된다. 더 많은 정보는 활용할 추가 자료를 제공하지만, 그 정보가 존재한다고 해서 올바른 적용이 입증되는 것은 아니다. 검토자는 제안된 변경이 관련 제약을 따랐다는 근거를 여전히 필요로 한다.

조직은 구매 결정과 릴리스 결정을 구분해야 한다. 어시스턴트를 선택하면 개발자에게 제공되는 도구가 정해진다. 특정 변경을 수용하려면, 해당 어시스턴트가 공개 평가에서 좋은 성과를 냈더라도 그 변경에 관한 근거가 필요하다.

보고된 개선은 이 대화를 더 구체적으로 만든다. 구매자는 초기 품질 신호와 이후 필요한 작업을 비교할 수 있다. 이는 실제 절충점을 드러낸다. 더 강력한 생성은 도움이 될 수 있지만, 신뢰할 수 있는 릴리스 동작에는 여전히 작동하는 검증 프로세스가 필요하다.

익숙한 보안 패턴은 개선의 일부만 설명한다

Veracode는 개선의 상당 부분을 특정 취약점 범주에 돌리고 있으며, 이는 폭넓은 보안 추론에 관한 주장을 제한한다.

Veracode는 가을 벤치마크 분석에서 기본적인 크로스 사이트 스크립팅을 개선의 주요 원인으로 지목했다. 크로스 사이트 스크립팅, 즉 XSS는 안전하지 않은 콘텐츠가 웹 페이지에서 실행 가능한 스크립트가 될 때 발생한다. 이 회사는 익숙한 안전 패턴이 개선을 설명하는 데 도움이 된다고 주장한다.

이 설명은 단순히 점수를 보고하는 대신 메커니즘을 제시하기 때문에 출처를 밝혀야 한다. 모델이 더 안전하고 익숙한 패턴을 선택하면 측정된 결과가 개선될 수 있다. 그렇다고 어떤 학습 변경이 모델이 그러한 선택을 하게 했는지는 정확히 입증되지 않는다.

Veracode는 테스트된 다른 범주에서는 변화가 더 적었다고 보고하며, 로그 처리와 관련한 지속적인 약점을 강조한다. 이 회사의 해석은 이 어려움을 함수 전반에서 정보를 추적하는 문제와 연결한다. 이는 코딩 모델의 보안 성능이 전반적으로 향상됐다는 일반적 주장보다 더 구체적인 이야기를 만든다.

근본적인 XSS 문제는 애플리케이션이 들어오는 데이터를 사용하는 맥락과 관련된다. MITRE의 스크립트 무력화 정의는 후속 웹 처리 과정에서 스크립팅 요소로 해석할 수 있는 문자를 무력화하지 못하는 실패를 설명한다. 이 정의는 겉보기에 평범한 표시 작업에도 보안에 민감한 처리가 필요할 수 있는 이유를 설명하는 데 도움이 된다.

예를 들어 고객이 제출한 메시지를 표시하는 지원 대시보드를 상상해 보자. 애플리케이션은 텍스트를 보여주려 하지만, 보안 요구사항은 그 텍스트가 활성 페이지 콘텐츠가 되지 않도록 막는 데 달려 있다. 관련 질문은 애플리케이션이 그 값을 어떻게 처리하는가에 있다.

그 상황에서 모델이 예상되는 안전 패턴을 인식하는 것은 유용한 개선이다. 그러나 같은 값이 나중에 애플리케이션의 다른 부분에 나타날 수 있다. 원래 작업에 대한 신뢰를 이후의 모든 사용에 자동으로 이전할 수는 없다.

로그 처리는 또 다른 맥락적 문제를 보여준다. 서비스는 일반적인 오류 경로에서 고객이 제어하는 텍스트를 기록할 수 있다. 개발자는 대입문만 판단하기보다 로깅 시스템과 이후의 읽는 이들이 그 텍스트를 어떻게 해석하는지 고려해야 한다.

MITRE의 로그 인젝션 정의는 로그에 기록되는 외부 입력의 부적절한 처리를 설명한다. 그 결과의 예시에는 위조된 항목과 해석의 방해가 포함된다. 이러한 결과는 겉보기에 일상적인 진단 코드도 검토할 가치가 있는 이유를 보여준다.

이 비교는 기사를 코딩 튜토리얼로 바꾸지 않으면서도 유용하다. 두 사례 모두 자체 해석 규칙을 가진 맥락으로 정보가 넘어가는 문제와 관련된다. 설득력 있어 보이는 함수도 그 경계를 잘못 처리할 수 있으며, 실질적인 결과는 주변 애플리케이션이 결정한다.

Claude Opus 5.5 코드 보안에 있어 이는 순위 뒤에 있는 가장 중요한 단서다. 익숙한 상황에 집중된 개선은 낯선 애플리케이션 동작 전반의 개선보다 더 좁은 결론을 뒷받침한다. 구매자는 내부적으로 결과를 논의할 때 이 구분을 유지해야 한다.

이 메커니즘은 더 강한 근거가 어떤 모습일지도 시사한다. 추가 맥락과 상호작용을 포함한 테스트는 더 안전한 선택이 현재 과제 집합을 넘어 지속되는지 보여줄 수 있다. 그때까지 더 폭넓은 보안 역량은 추가 평가가 필요한 질문으로 남는다.

같은 점수는 워크플로 비교를 열어 둔다

구매자가 첫 답변만이 아니라 검증된 변경을 비교할 때 Claude Opus 5.5 vs GPT-6-Sol은 더 많은 정보를 제공한다.

첫 답변은 많은 개발 프로세스에서 중간 결과일 뿐이다. 개발자는 코드를 수정하고, 검사를 실행하며, 실패를 살피고, 수정을 요청한다. 초기 출력을 평가하면 유용한 정보를 얻을 수 있지만, 더 긴 프로세스의 동작은 여전히 해결되지 않은 채 남는다.

그러한 단계 이후에는 경쟁 구도가 달라질 수 있다. 더 나은 답변으로 시작한 어시스턴트가 목표에 맞춘 수정을 하는 데 어려움을 겪을 수도 있다. 또 다른 어시스턴트는 의도한 동작을 유지하면서도 구체적인 발견 사항에 잘 대응할 수 있다.

이는 평가해야 할 가능성일 뿐, 가을 순위로 확정된 결론은 아니다. 공동 1위라는 사실만으로 어느 패턴이 Anthropic 또는 OpenAI에 해당하는지 판단할 근거는 없다. 이를 동일한 동작의 증거로 간주하는 것은 승자를 지어내는 것만큼이나 근거가 부족하다.

관련 연구는 이러한 질문들을 분리해 살펴볼 필요성을 뒷받침한다. Mikhail Surikov의 2026년 8월 remediation pipeline study는 이전 Claude 모델을 활용해 생성, 탐지, 수정 및 후속 검증을 평가했다. 이 연구는 초기 생성 성능이 가장 좋았던 모델이 전체 파이프라인 성과도 가장 우수했던 것은 아니라고 보고했다.

이 논문은 제한된 실험 범위의 석사 실습 프로젝트를 다룬 프리프린트다. Veracode의 새 순위를 재현하거나 현재 상용 모델의 우승자를 확정하지는 않는다. 이 연구의 의미는 초기 출력 품질과 검증 이후 결과를 구분했다는 데 있다.

이 연구는 수정 과정에서 추가 취약점이 도입된 사례도 보고했다. 이 발견은 어시스턴트의 설명만을 충분한 증거로 받아들이기보다 제안된 수정을 검증해야 한다는 점을 시사한다. 그렇다고 모든 자동화된 수정 과정이 유사하게 동작한다는 뜻은 아니다.

구매자에게 분석상 시사점은 같은 유형의 개발 프로세스를 비교해야 한다는 것이다. 한 어시스턴트에는 상세한 발견 사항을 제공하면서 다른 어시스턴트는 수정되지 않은 답변으로 평가하면 비교 조건이 달라진다. 차이를 공개하지 않은 채 서로 다른 수준의 수정 기회를 허용하는 경우도 마찬가지다.

비교할 가치가 있는 출력은 동일한 수용 조건을 충족하는 완료된 변경이다. 그러면 초기 보안 점수와 함께 검토 노력, 미해결 발견 사항, 보존된 기능이 드러난다. 이러한 지표는 공개 리더보드와는 다른 질문에 답한다.

서로 다른 작업에 서로 다른 모델을 배정하는 모델 라우팅도 또 하나의 판단 요소다. 조직은 민감한 변경이나 까다로운 수정 작업에 특정 어시스턴트를 우선 배정할 수 있다. 그러한 정책의 근거는 제품군에 대한 가정보다는 관련 작업에서 나와야 한다.

다른 모델들의 보고된 순위가 근소하게 차이 난다는 점에서 이는 특히 중요하다. 공동 선두 모델과 함께 Claude Sonnet 5.5를 고려하는 구매자는 전체 결과를 평가해야 한다. 순위만으로는 검토 노력, 응답 시간, 수정 품질 간 최적의 균형을 확정할 수 없다.

벤더의 모델 체계 역시 그 균형을 확정할 수는 없다. 제품 포지셔닝은 벤더의 제공 사항을 설명하지만, 조직의 평가는 자체 업무량을 설명한다. 특히 작은 보안 차이가 광범위한 구매 선택에 영향을 미칠 때는, 이 둘을 연결하려면 비교 가능한 증거가 필요하다.

따라서 가을 결과는 프로세스 수준의 경쟁이 필요하다는 주장을 더욱 강화한다. 더 나은 생성은 여전히 가치 있지만, 운영상 가치는 변경 사항이 출시 가능해지기 전에 어떤 일이 일어나는지에 달려 있다.

공개된 수치는 방법론적 검토가 필요하다

핵심 순위는 문서화되어 있지만, 더 폭넓은 해석 중 일부는 헤드라인 수치만으로는 제공되지 않는 정보를 필요로 한다.

원래 shattered.io 헤드라인은 검증 가능한 Veracode 발표로 연결된다. 이는 공동 1위를 출처가 명시된 벤치마크 결과로 보도하는 근거가 된다. 그렇다고 결과를 둘러싼 모든 설명까지 독립적으로 확립된 사실이 되는 것은 아니다.

공개와 재현은 서로 다른 목적을 지닌다. 공개는 평가자의 발견 사항을 검토할 수 있게 한다. 재현은 다른 평가자가 충분히 유사한 조건에서 작업을 반복해, 독자가 결과가 원래 실행을 넘어 유지되는지 판단할 수 있게 한다.

여기서 검토한 주요 자료는 이 정확한 공동 1위 결과의 독립적 재현을 확립하지 않는다. 이는 보고된 점수가 거짓이라는 증거가 아니라 신뢰도에 관한 한계다. 적절한 대응은 출처 표기를 유지하고 보편적인 결론을 피하는 것이다.

인접한 점수를 해석할 때는 표본 크기와 반복 실행도 중요하다. 반올림된 백분율은 기초 건수의 차이를 가릴 수 있다. 불확실성 추정치가 없다면, 독자는 작은 수치 차이가 모델 간 안정적인 차이를 의미한다고 가정해서는 안 된다.

명확히 할 필요가 있는 또 다른 가시적 문제가 있다. 발표문은 함께 제공된 분석에서 논의된 여러 광범위한 하위 그룹 평균보다 높은 전체 평균을 보고한다. 해당 그룹이 같은 가중치 아래 동일한 전체 모집단을 설명한다면, 이 관계에는 설명이 필요하다.

서로 다른 모집단이나 가중치 규칙이 그러한 제시 방식을 설명할 수 있다. 공개된 요약본은 어느 설명이 적용되는지 확립하지 않는다. 구매자는 이러한 하위 그룹 수치를 구매 규칙의 근거로 사용하기 전에 관련 분모를 요청해야 한다.

이는 모델 크기나 전문화에 관한 주장과 특히 관련이 있다. 어느 분류가 더 우수한지에 대한 광범위한 주장은 명확히 정의된 구성원과 비교 가능한 채점을 필요로 한다. 그렇지 않으면 독자는 겉으로 보이는 차이가 모델, 작업 구성, 또는 집계 방식 중 무엇을 반영하는지 알 수 없다.

평가자의 상업적 위치도 명확히 공개할 필요가 있다. Veracode는 애플리케이션 보안 제품을 판매하며, 그 해석은 생성과 보안 검증의 결합을 선호한다. 이러한 이해관계가 벤치마크를 무효화하는 것은 아니지만, 비교 제품 주장은 별도로 검토할 가치가 있다.

예를 들어, 스캐닝과 결합된 모델이 더 나은 결과를 제공한다고 주장하려면 그 조합에 관한 증거가 필요하다. 생성 리더보드만으로는 스캐너 적용 범위, 수정 품질, 운영상 절감 효과를 확립할 수 없다. 그러한 주장은 이를 측정하도록 설계된 평가를 필요로 한다.

동일한 기준은 모델 벤더에도 적용되어야 한다. 유리한 점수가 어시스턴트가 기존 검토 관행을 대체한다는 것을 확립하지는 않는다. 설득력 있는 주장은 작업, 주변 도구, 수용 기준 및 남은 실패 사례를 구체적으로 명시해야 한다.

따라서 Claude Opus 5.5 코드 보안은 정의된 범위의 출처가 명시된 결과로 이해하는 것이 가장 적절하다. 이러한 틀은 유용한 경쟁 신호를 유지하면서도 신중한 구매자가 여전히 답을 필요로 하는 질문을 보존한다.

남은 불확실성은 명시적으로 드러내면 관리할 수 있다. 팀은 순위를 활용해 평가 후보의 우선순위를 정한 뒤, 누락된 운영상 증거를 검토할 수 있다. 리더보드를 출발점으로 삼으면 의사결정이 측정된 범위에 걸맞게 유지된다.

다음 증거는 더 높은 점수와 더 나은 릴리스를 연결해야 한다

가장 유용한 다음 진전은 벤치마크 성과 향상이 비교 가능한 개발 작업에서 미해결 보안 문제를 줄인다는 사실을 보여주는 것이다.

첫 번째로 주목할 신호는 앞으로 몇 달간 더 명확해지는 벤치마크 보고다. 상세한 작업 수, 채점 규칙, 반복 실행 결과 및 집계 방식 설명은 현재 순위를 더 쉽게 평가하게 해 줄 것이다. 독립적으로 재현된 평가는 원래 발행자의 발견을 넘어서는 증거를 추가할 것이다.

비교 가능한 조건에서 선두 결과가 유지된다면 더 큰 투명성은 신뢰를 강화할 것이다. 반복 후 의미 있는 변화가 나타난다면 현재 순위가 안정적이라는 주장은 약화될 것이다. 어느 결과든 가정을 검토 가능한 증거로 대체함으로써 구매 의사결정의 질을 높일 것이다.

두 번째 신호는 더 폭넓은 취약점 범주와 애플리케이션 맥락에서의 개선이다. 익숙한 안전 패턴을 넘어선 더 강한 결과는 생성 코드 보안에 관한 더 광범위한 주장을 뒷받침할 것이다. 현재 강점에 국한된 진전은 더 제한적인 해석을 뒷받침할 것이다.

이 신호가 중요한 이유는 실제 운영 애플리케이션이 개별 사례에서는 분리할 수 있는 동작들을 결합하기 때문이다. 구성 요소 간 상호작용을 포함하는 평가는 더 안전한 선택이 그러한 조합에서도 유지되는지 시험할 것이다. 구매자는 더 큰 헤드라인 점수만이 아니라 명시적인 범위 설명을 찾아야 한다.

세 번째 신호는 완전한 개발 프로세스에 관한 공개 비교다. 이 비교는 일관된 조건에서 초기 생성, 발견 사항, 수정 및 최종 승인된 변경을 평가해야 한다. 이는 모델 역량을 조직이 실제로 완료해야 하는 업무와 연결해 줄 것이다.

더 나은 초기 점수가 더 나은 검증 결과로 이어진다는 증거는 모델 도입의 근거를 강화할 것이다. 반대로 겉보기 우위가 수정과 검토 과정에서 사라진다면, 단순한 리더보드 기반 구매 논거는 약화될 것이다.

어느 결과도 미리 가정할 필요는 없다. 더 안전한 생성의 상업적 가치는 제거하는 작업과 남기는 실패에 달려 있다. 둘 다 측정하면 엔지니어링 및 보안 리더가 의사결정을 위한 공통 기반을 갖게 된다.

개발자에게도 이는 성공적인 시연이 어떤 모습이어야 하는지를 바꾼다. 유창한 답변은 쉽게 보여줄 수 있지만, 요구사항이 보존되었다는 증거는 더 세심한 관리가 필요하다. 유용한 평가는 어시스턴트의 자신감에 의존하지 않고 그 증거를 가시화한다.

엔터프라이즈 구매자에게 보고된 공동 1위는 즉각적인 결론의 범위를 좁힌다. Anthropic과 OpenAI는 공개된 지표에서 선두를 공유하며, 어느 결과도 보편적인 선택을 확립하지 않는다. 구매 문제는 여전히 조직이 사용할 것으로 예상하는 작업과 검증 프로세스에 따라 구체적으로 달라진다.

Claude Opus 5.5 코드 보안을 다음 어시스턴트 평가의 근거를 검토하는 계기로 활용하라. 동일한 요구사항 아래 대표적인 변경 사항을 비교하고, 수용 또는 거부를 설명하는 발견 사항을 보존하라. 어떤 시스템이 팀이 확신을 가지고 검증, 수정 및 유지할 수 있는 작업을 만들어 내는지 물어보라. 유리한 헤드라인이 애플리케이션 맥락을 대체하지 않도록 벤치마크 결과를 이러한 현지 관찰과 함께 유지하라. 벤더가 검토 노력 감소를 주장한다면 이를 직접 측정하는 비교를 요청하라. 모델 성능이 좋더라도 책임 범위를 확대하기 전에 남은 실패 사례를 검토하라. 출시 결정의 순간에 어떤 어시스턴트가 엔지니어에게 더 적은 미해결 보안 의문을 남기는가?