Cognition, Devin GPT-6 Astra 테스트가 증거 기반으로 코드 리뷰를 대체할 수 있다고 베팅

Cognition은 세 가지 제품에 걸쳐 Devin GPT-6 Astra 테스트를 확대하며, 검증을 자율 소프트웨어 엔지니어링의 새로운 격전지로 만들고 있다. 이 모델은 이제 Devin Cloud, Devin Desktop, Devin CLI 내 테스트를 지원한다. 애플리케이션을 조작하고, 결과를 점검하며, 서면 보고서와 함께 시각적 증거를 반환할 수 있다.

중요한 변화는 Devin이 더 많은 코드를 생성할 수 있다는 점이 아니다. 코딩 에이전트는 이미 패치를 만들고, 풀 리퀘스트를 열며, 테스트 스위트를 실행한다. Cognition은 이제 Devin이 변경 사항이 실제로 작동한다는 증거를 제시해, 엔지니어가 생성된 코드를 수동으로 살펴봐야 하는 양을 줄이기를 원한다.

이러한 약속은 기존의 리뷰 우선 개발 방식에 압박을 가한다. 동시에 Cognition, OpenAI, 그리고 경쟁 코딩 에이전트 모두에게 어려운 질문을 던진다. 에이전트가 동일한 자동화 시스템이 만든 작업을 신뢰성 있게 평가할 수 있을까, 아니면 사람의 주의는 단지 코드 리뷰에서 증거 리뷰로 옮겨갈 뿐일까?

Devin GPT-6 Astra 테스트, 이제 검토 가능한 증거 생성

Cognition은 코드 생성만이 아니라 테스트 증거를 엔지니어가 평가해야 할 산출물로 내세우고 있다.

OpenAI는 2026년 9월 11일 Devin 테스트 사례를 공개했다. 회사는 Cognition이 클라우드 에이전트, 명령줄 인터페이스, 데스크톱 애플리케이션 전반에 GPT-6 Astra를 적용하고 있다고 밝혔다.

Cognition은 이미 9월 3일 Devin에 Astra를 추가했다. 모델 출시에 따르면 Astra는 Devin Desktop과 Devin CLI에서 직접 사용할 수 있다. 이 모델은 Devin Cloud가 사용하는 모델 혼합의 일부이기도 하다.

이 통합은 코딩 제품이 흔히 하나의 연속된 워크플로로 제시하는 두 작업을 분리한다. 한 모델이 변경 사항을 구현하는 동안 Astra는 테스트 단계를 진행하는 데 도움을 줄 수 있다. 코드 편집과 애플리케이션 검증에는 서로 다른 역량이 필요하기 때문에 이 구분은 중요하다.

코딩 모델은 주로 리포지터리, 사양, 소스 변경 사항을 추론한다. 반면 애플리케이션 테스터는 화면을 해석하고, 인터페이스 상태를 추적하며, 소프트웨어를 조작하고, 관찰된 동작이 의도한 결과와 일치하는지 판단해야 한다.

Cognition은 Astra가 이 두 번째 작업군에서 특히 뛰어난 성과를 낸다고 말한다. 회사는 내부 테스트 벤치마크에서 최첨단 결과를 기록했다고 보고했다. 다만 외부인이 해당 결과를 재현하거나 독립적으로 검증할 수 있을 만큼의 세부 정보는 공개하지 않았다.

공개 사례는 Cognition이 자율 검증으로 무엇을 의미하는지 분명히 보여준다. 한 시연에서 Devin은 시뮬레이터 안에서 iPhone 게임인 Otter Run을 테스트한다. 실행 중인 게임의 녹화 영상과 어떤 검사가 통과했는지를 설명하는 보고서를 반환한다.

보고서는 Devin이 테스트하지 않은 영역도 식별한다. 매끄러운 영상은 실제 실행 범위보다 더 넓은 커버리지를 암시할 수 있기 때문에, 이 같은 단서는 중요하다.

녹화 영상은 관찰 가능한 동작을 보여주고, 보고서는 주장하는 범위를 정의한다. 두 요소가 함께 있으면 검토자는 일반적인 에이전트 요약보다 테스트 아티팩트에 가까운 자료를 받게 된다.

또 다른 워크플로는 고객이 제공한 버그 스크린샷에서 시작한다. Cognition에 따르면 팀은 이미지를 Devin에 보내고, Devin은 문제를 진단해 코드를 변경한 뒤 결과를 보여주는 또 다른 스크린샷을 반환할 수 있다.

이 과정은 눈에 보이는 결함과 눈에 보이는 결과를 연결한다. 로그나 풀 리퀘스트 댓글만으로 설명하기 어려운 인터페이스 문제의 피드백 루프를 단축할 수 있다.

그러나 스크린샷은 한 순간에 무엇이 나타났는지만 증명한다. 관련 경로가 계속 작동하는지, 기반 구현이 유지보수 가능한지, 다른 조건에서도 결함이 수정된 상태로 유지되는지는 입증하지 못한다.

따라서 더 유용한 기능은 증거 패키지다. 엔지니어는 병합 여부를 결정하기 전에 요청된 동작, 명시된 테스트 계획, 기록된 행동, 그리고 테스트되지 않은 영역을 비교할 수 있다.

이는 리뷰의 단위를 바꾼다. 엔지니어는 단순히 diff와 에이전트가 작성한 보장 문구만 받는 대신, 실행 추적으로 뒷받침된 주장을 받는다.

이 변화가 Cognition의 핵심 베팅을 만든다. 검토자가 추적 기록을 신뢰한다면 생성된 코드에서 무슨 일이 일어났는지 재구성하는 데 쓰는 시간을 줄일 수 있다. 신뢰하지 못한다면 추가 아티팩트는 또 하나의 검토 대상 계층이 된다.

검증이 코딩 에이전트의 병목이 된 이유

에이전트 기반 개발에서 제한 자원은 코드 생산에서 신뢰할 수 있는 리뷰 역량으로 이동하고 있다.

코딩 에이전트는 대부분의 팀이 평가할 수 있는 속도보다 빠르게 변경 사항을 만들 수 있다. 여러 에이전트가 동시에 작동하면, 성공한 각 세션은 또 다른 브랜치, 풀 리퀘스트, 테스트 보고서 또는 후속 결정을 만들어낼 수 있다.

Cognition은 자사 엔지니어들이 10~20개의 Devin 세션을 병렬로 실행했다고 말한다. 각 세션은 클라우드에서 별도의 개발 서버를 운영할 수 있다. 이 정도의 동시성은 한 엔지니어의 노트북에서는 다루기 어렵다.

동시성이 높아진다고 자동으로 더 많은 프로덕션 가치가 만들어지는 것은 아니다. 오히려 사람의 검증을 기다리는 그럴듯한 변경 사항의 대기열이 생성될 수 있다.

생성된 코드는 실행에서 실패하기 전까지는 합리적으로 보일 수 있기 때문에 이 대기열은 특히 까다롭다. 검토자는 환경을 재구성하고, 애플리케이션을 실행하며, 보고된 흐름을 반복하고, 인접한 동작까지 점검해야 할 수 있다.

Cognition은 이 과제를 비동기 개발로의 더 광범위한 전환 과정의 일부로 설명해 왔다. 현재는 직접적인 상호작용 요청보다 일정, 자동화, 이벤트, 그리고 다른 Devin 인스턴스를 통해 더 많은 Devin 세션이 시작된다.

비동기 코딩 에이전트는 사람이 다른 일을 하는 동안 작업한다. 이러한 방식은 반환된 결과가 이해 가능하고 충분히 신뢰할 수 있을 때에만 사람의 주의를 절약한다.

검증이 없다면 엔지니어는 설명되지 않은 diff 더미로 돌아오게 된다. 작업이 유용한지 판단하기 전에 각 작업의 맥락을 다시 파악해야 한다.

Cognition의 이전 에이전트 검증 설명에 따르면, 승인된 일일 테스트 실행 건수는 수개월 동안 두 배 이상 증가했다. 이는 회사가 보고한 제품 활동이며, 신뢰성이나 고객 가치에 대한 독립적인 측정치는 아니다.

그럼에도 방향성은 타당하다. 에이전트가 더 많은 변경 사항을 생성할수록, 팀에는 어떤 결과가 주의를 기울일 가치가 있는지 알려주는 간결한 증거가 필요하다.

목표는 사람의 판단을 즉시 없애는 것이 아니다. 관련 관찰 결과를 완료된 작업에 더 가깝게 배치해 그 판단의 비용을 낮추는 것이다.

유용한 증거 패키지는 엔지니어가 구현을 읽기 전에 여러 질문에 답할 수 있다. 애플리케이션이 정상적으로 시작됐는가? 변경된 기능이 나타났는가? 에이전트는 어떤 사용자 경로를 실행했는가? 무엇이 테스트 범위 밖에 남았는가?

이 질문들은 모든 테스트가 통과했다는 에이전트의 주장보다 더 가치 있는 경우가 많다. 기존 테스트 스위트는 누군가 예상하고 코드로 작성한 단언만 평가한다.

인터페이스 녹화는 단위 테스트에 한 번도 표현되지 않은 상태 변화를 드러낼 수 있다. 서면 범위 메모 역시 긴 실행 로그 속에 숨기는 대신, 누락된 커버리지를 드러낼 수 있다.

이 압박은 Cognition에만 국한되지 않는다. OpenAI의 Codex, Anthropic 지원 코딩 시스템, Google의 개발자 에이전트, Cursor, 오픈소스 프레임워크 모두 엔지니어링 업무를 놓고 경쟁한다.

각 제품은 코드 생성 점수를 개선할 수 있다. 그러나 기업 도입은 생성 이후의 과정, 즉 책임 있는 사람이 중요한 변경 사항을 승인해야 하는 순간에 달려 있다.

이 때문에 주요 경쟁 상대는 특정 경쟁 모델 하나가 아니다. 결과를 신뢰하기 전에 모든 의미 있는 줄을 읽는 방식으로 구축된 리뷰 우선 워크플로다.

이 워크플로는 타당한 이유로 존재한다. 코드는 짧은 시연으로는 결코 드러나지 않을 수 있는 아키텍처, 미래 유지보수 비용, 보안 가정, 실패 동작을 전달한다.

Cognition은 그러한 우려가 사라진다고 주장하지 않는다. 회사가 밝힌 목표는 시간이 지날수록 엔지니어가 검토해야 할 코드를 줄이면서 더 많은 완료된 작업을 배포하게 만드는 것이다.

이 표현은 선택적 리뷰의 여지를 남긴다. 팀은 고위험 모듈을 면밀히 검사하는 한편, 좁은 범위의 인터페이스 수정, 일상적인 마이그레이션, 또는 범위가 잘 제한된 내부 도구에는 증거 주도 리뷰를 받아들일 수 있다.

실질적인 효과는 팀이 작업 맥락을 얼마나 잘 보존하는지에 달려 있다. 엔지니어링 지식 기반은 검토자가 에이전트의 증거를 요구사항, 설계 결정, 이전 실패 사례와 연결하는 데 도움을 줄 수 있다.

검증은 이러한 출처를 반영할 때 더 큰 가치를 갖는다. 성공을 정의한 요구사항을 에이전트가 오해했다면, 깔끔한 녹화 영상의 의미는 줄어든다.

Astra, 테스트를 별도의 에이전트 역량으로 전환

Astra의 기여는 컴퓨터 사용, 시각적 판단, 코드베이스 추론, 간결한 보고를 하나의 테스트 루프 안에서 결합하는 데서 나온다.

컴퓨터 사용 모델은 시각적 인터페이스를 해석하고 클릭, 입력, 스크롤, 화면 간 이동 같은 행동을 수행한다. 테스트에는 추가 요건이 있다. 이러한 행동이 예상된 동작에 대한 명시적 단언을 뒷받침해야 한다는 것이다.

Cognition의 테스트 루프는 리포지터리에 근거한 계획으로 시작한다. 에이전트는 무엇을 테스트할지 선언하기 전에 관련 코드를 살펴본다. 이는 애플리케이션이 뒷받침하지 않는 인터페이스 경로나 가정을 만들어낼 가능성을 줄인다.

계획은 최종 보고서의 기준점도 만든다. 검토자는 명시된 기준 없이 녹화 영상을 판단하는 대신, 실행이 의도한 동작을 다뤘는지 확인할 수 있다.

실행 중 Devin은 설정 메모와 이름이 지정된 테스트 단계로 타임라인에 주석을 달 수 있다. 단언을 통과, 실패 또는 미테스트로 표시할 수 있다.

Cognition은 에이전트가 행동 전에 기대치를 진술하도록 요구하면 합리화를 줄일 수 있다고 말한다. 결과를 본 뒤 예상치 못한 화면을 성공으로 재해석할 여지가 줄어든다는 것이다.

이는 예상된 동작을 구현 전에 정의하는 테스트 주도 개발과 닮아 있다. 여기서는 모든 코드 변경 전에가 아니라 동작 검증 중에 그 약속이 이뤄진다.

그런 다음 에이전트는 브라우저, 시뮬레이터 또는 데스크톱 애플리케이션을 조작할 수 있다. 발생한 일을 캡처하고 사람이 비동기적으로 검토할 수 있는 아티팩트를 반환한다.

Astra는 컴퓨터 사용과 길고 다단계인 전문 작업을 위해 학습됐기 때문에 이 단계에 적합해 보인다. OpenAI는 Astra가 소프트웨어를 설치하고, 눈에 보이는 문제를 해결하며, 프런트엔드 품질 검사를 실행할 수 있다고 말한다.

OpenAI가 공개한 컴퓨터 사용 결과에서 Astra는 OSWorld 2.0에서 72.6%를 기록했다. 보고된 비교 기준에서 GPT-5.6 Sol은 65.7%를 기록했다.

OpenAI는 또한 Astra가 해당 시뮬레이션 작업을 평균 약 40분 만에 완료했다고 밝혔다. 이전 모델에는 약 75분이 필요했다. 이 수치는 OpenAI의 평가 환경에서 나온 것이며, 보편적인 프로덕션 측정치로 간주해서는 안 된다.

같은 발표에서 Astra는 Terminal-Bench 4.0에서 57.9%를 기록했다. GPT-5.6 Sol은 37.3%, Claude Fable 5.1은 55.8%를 기록했다.

FrontierCode 1.1 Extended에서 Astra는 64.5%를 기록했다. Claude Fable 5는 64.9%를 기록해 Cognition의 벤치마크 기준으로 Astra를 근소하게 앞섰다.

Cognition은 FrontierCode를 실제 엔지니어링 작업에 대한 독점 평가라고 설명한다. 이 평가는 품질과 병합 가능성을 고려하며, 차단 기준을 충족하지 못한 솔루션에는 점수를 부여하지 않는다.

이러한 비교는 Astra의 매력이 단순히 더 높은 순수 코딩 성능에만 있지 않다는 점을 시사한다. Cognition의 공개 발표는 더 명확한 보고서, 더 포괄적인 테스트, 그리고 따라가기 쉬운 영상을 강조한다.

이러한 특성은 검토 시간에 직접적인 영향을 미친다. 기술적으로 성공한 실행이라도 근거가 혼란스럽거나 장황하거나 요청된 변경 사항과 연결되지 않았다면 사람의 주의를 낭비할 수 있다.

간결한 보고서는 테스트한 동작, 환경, 관찰 결과, 그리고 남은 불확실성을 식별해야 한다. 유용한 녹화 자료는 검토자가 편집되지 않은 세션 전체를 훑지 않아도 중요한 전환 지점을 쉽게 찾을 수 있게 해야 한다.

Cognition은 반복적인 설정 작업을 위한 결정론적 스크립트도 구축했다. 결정론적 스크립트는 모델에게 모든 행동을 즉흥적으로 수행하도록 맡기는 대신, 정의된 순서를 실행한다.

인증이 한 예다. 스크린샷을 통해 로그인 흐름을 조작하면 시간이 소모되고 테스트 대상 기능과 무관한 실패가 발생할 수 있다.

저장된 스크립트는 인증된 브라우저 세션을 빠르게 만들 수 있다. 그러면 에이전트는 중요한 동작에 추론을 집중할 수 있다.

이 하이브리드 설계는 중요한 엔지니어링 교훈을 보여준다. 더 나은 자율 테스트가 모든 작업을 언어 모델에 할당하는 것을 의미하지는 않는다.

신뢰할 수 있는 시스템은 예측 가능한 단계를 기존 자동화에 맡긴다. 해석, 복구 또는 유연한 탐색이 가치를 더하는 곳에 모델을 사용한다.

Cognition은 어려운 설정 문제를 해결한 뒤 Devin이 재사용 가능한 테스트 스킬을 제안하도록 한다. 사용자는 그 자동화를 리포지터리에 추가하기 전에 검토할 수 있다.

시간이 흐르면 이는 반복된 발견을 안정적인 인프라로 바꿀 수 있다. 모델이 즉흥적으로 찾은 경로는 이후 실행을 위한 검토된 스크립트가 된다.

이 조합은 변동성도 통제한다. 모든 테스트가 서로 다른 설정 동작으로 시작한다면 결과를 비교하기 어려워지고 실패 진단 비용도 커진다.

Astra는 유연한 인식과 추론을 제공한다. 결정론적 스크립트는 반복적인 작업을 제한한다. 테스트 계획은 성공을 정의하고, 근거 보고서는 실행이 무엇을 포괄했는지 드러낸다.

이 메커니즘은 또 하나의 벤치마크 우위보다 더 중요한 의미를 갖는다. 코딩 에이전트가 그럴듯한 패치를 만드는 데서 나아가 통제된 엔지니어링 워크플로에 참여하는 방법을 제시한다.

에이전트는 여전히 혼자서 자신의 과제를 채점할 수 없다

근거는 검토 노력을 줄일 수 있지만, 자체 검증을 독립적이고 완전하며 자동으로 신뢰할 수 있게 만들지는 못한다.

가장 분명한 위험은 상관된 실패다. 에이전트가 구현 과정에서 작업을 오해하면, 동일한 시스템이 그 오해를 테스트 계획에도 그대로 반영할 수 있다.

그러면 코드와 테스트는 서로 일치하면서도 사용자의 실제 요구 사항과는 모두 불일치할 수 있다. 깔끔한 보고서는 정확성이 아니라 일관성만 문서화하게 된다.

명세, 다른 엔지니어 또는 별도의 평가 시스템에서 나온 독립 테스트는 이 문제를 줄인다. 기존 회귀 테스트 스위트 역시 구현 에이전트가 세션 중에 만들어내지 않은 제약 조건을 제공한다.

Cognition의 접근 방식은 계획을 소스 코드에 근거하게 하고 각 행동 전에 기대치를 명시함으로써 도움을 준다. 이러한 조치는 이탈을 줄일 수 있지만, 진정한 독립성을 만들어내지는 않는다.

회사는 이전 실패 사례도 공개적으로 설명했다. Devin은 때때로 관련 없는 영역을 테스트하거나 환경 설정에 갇히거나, 풀 리퀘스트가 변경하려던 동작을 놓쳤다.

이러한 문제는 시스템에 계획, 주석, 결정론적 설정 도구가 필요한 이유를 설명한다. 또한 정제된 근거가 기반 모델을 넘어선 오케스트레이션에 의존한다는 점도 보여준다.

시각적 증명에는 추가적인 한계가 있다. 영상은 하나의 환경과 데이터 상태에서 한 흐름이 작동했음을 보여줄 수 있다. 하지만 브라우저, 권한, 부하 조건 또는 악의적 입력 전반에서 폭넓은 정확성을 입증할 수는 없다.

보고서는 이러한 공백을 테스트되지 않은 영역으로 정확히 표시할 수 있다. 어떤 누락 경로가 배포를 막을 만큼 중요한지는 여전히 검토자가 판단해야 한다.

백엔드, 인프라 및 보안 변경에서는 커버리지가 특히 중요해진다. 많은 심각한 실패는 짧은 실행 중에는 명확한 시각적 증상을 만들지 않는다.

데이터베이스 마이그레이션은 엣지 케이스를 손상시키기 전까지 성공한 것처럼 보일 수 있다. 권한 변경은 시연된 계정에서는 작동하지만 다른 테넌트의 데이터를 노출할 수 있다.

보안에 민감한 코드는 예상된 동작이 발생했는지 확인하는 것뿐 아니라 적대적인 사고를 요구한다. 팀에는 정상 경로를 재현하기보다 가정을 깨도록 설계된 테스트가 필요하다.

OpenAI 역시 Astra의 고급 사이버보안 역량에 제한을 적용한다. 이 모델은 보안 검토와 패치를 지원할 수 있지만, 일부 익스플로잇 관련 워크플로는 계속 제한되거나 모니터링된다.

Astra 출시에 관한 독립 보도 역시 복잡한 자율 작업을 둘러싼 해결되지 않은 안전성 문제를 부각했다. 실제 환경의 신뢰성은 통제된 시연이 시사하는 것보다 여전히 불확실하다.

소프트웨어 품질은 더 장기적인 과제를 제시한다. 오늘의 테스트를 통과했다고 해서 반복된 에이전트 변경이 코드베이스를 이해 가능하고 적응 가능하게 유지하는지는 알 수 없다.

코딩 벤치마크의 한계에 대한 비판적 분석은 현재의 테스트가 구조적 침식을 자주 놓친다고 주장한다. 코드는 기능을 유지하면서도 안전하게 변경하기는 더 어려워질 수 있다.

이 우려는 “더 적은 코드를 검토하자”는 제안을 직접적으로 제한한다. 엔지니어는 즉각적인 정확성 이상의 이유로 코드를 읽는다. 추상화, 소유권 경계, 중복 로직, 관측 가능성, 향후 유지보수 비용을 살핀다.

실행 영상은 이러한 특성을 모두 드러낼 수 없다. 가시적인 동작에 초점을 둔 보고서도 마찬가지다.

올바른 검토 정책은 위험도에 따라 달라질 가능성이 높다. 내부 대시보드의 시각적 조정은 인증 로직, 결제 처리 또는 안전 필수 인프라와는 다른 수준의 검토를 받아야 한다.

팀은 근거 유형을 결합한 병합 게이트를 정의할 수 있다. 저위험 변경에는 통과한 스위트, 녹화된 사용자 흐름, 완전한 범위 보고서가 요구될 수 있다.

고위험 변경에는 사람의 설계 검토, 독립 보안 테스트, 민감한 파일의 수동 검사도 필요할 수 있다. 에이전트의 근거는 이러한 통제를 대체하지 않고 지원할 수 있다.

또 다른 문제는 근거의 무결성이다. 검토자는 녹화 자료가 제출된 커밋, 환경, 구성 및 테스트 데이터와 대응한다는 확신이 필요하다.

아티팩트가 검토 중인 정확한 코드에서 분리될 수 있다면, 이전 빌드나 다르게 구성된 빌드를 설명하게 될 수 있다. 강력한 출처 추적은 각 주장을 실행 상태와 연결해야 한다.

Cognition은 강조된 워크플로를 뒷받침하는 모든 출처 추적 통제를 공개적으로 상세히 설명하지는 않았다. 내부 벤치마크 역시 독점적이어서 독립 연구소 간 비교가 제한된다.

따라서 벤치마크 주장은 자율 테스트 품질의 확정된 척도가 아니라 제품 신호로 읽어야 한다.

OpenAI의 공개 결과조차 범위가 제한된 작업을 측정한다. 운영 리포지터리에는 문서화되지 않은 가정, 불안정한 종속성, 비공개 서비스, 조직별 릴리스 규칙이 포함된다.

Astra는 에이전트가 이러한 복잡성을 탐색하는 능력을 개선할 수 있다. 하지만 어떤 근거가 충분한지에 대한 엔지니어링 판단의 필요성을 없애지는 않는다.

핵심 구분은 증명과 근거 사이에 있다. 일반적인 소프트웨어 관행에서 테스트는 정의된 조건에서 선택된 동작이 작동했다는 근거를 제공한다.

그것이 완전한 정확성을 증명하는 경우는 드물다. Cognition의 공개 표현은 때때로 “증명”을 대화체로 사용하지만, 팀은 더 좁은 엔지니어링적 해석을 유지해야 한다.

이러한 주의가 기능의 중요성을 낮추지는 않는다. 오히려 안전하지 않은 신뢰를 조장하지 않으면서 기능이 가치를 만들 수 있는 지점을 정의한다.

엔지니어가 더 적은 코드를 검토할 수 있는지를 보여줄 세 가지 신호

다음 시험대는 Cognition이 더 강력한 시연을 운영 팀 전반의 측정 가능하고 위험 인지적인 도입으로 전환할 수 있는지다.

첫 번째 신호는 독립적인 재현 가능성이다. Cognition은 외부인이 작업 선택, 채점, 모델 라우팅 및 실패 처리를 이해할 수 있도록 테스트 벤치마크에 관한 충분한 세부 정보를 공개해야 한다.

재현 가능한 결과는 Astra가 단지 더 보기 좋은 아티팩트를 만드는 것이 아니라 테스트를 개선한다는 주장을 강화할 것이다. 또한 시스템이 실패 또는 불완전한 커버리지를 얼마나 자주 정직하게 보고하는지도 보여줄 것이다.

근거 품질은 작업 완료와 별도로 평가해야 한다. 테스트 에이전트는 올바른 결과에 도달하면서도 사용할 수 없는 보고서를 제공할 수 있고, 불완전한 테스트에 대해 설득력 있는 문서를 만들 수도 있다.

유용한 측정값에는 주장 정확도, 놓친 결함, 거짓 통과, 커버리지 보정, 검토자 시간이 포함될 수 있다. 검토자가 올바른 병합 결정을 내리는지도 추적해야 한다.

독립 평가가 이러한 차원 전반의 개선을 확인한다면 Cognition의 가벼운 검토 워크플로는 신뢰를 얻는다. 결과가 리포지터리마다 크게 달라진다면 팀에는 더 좁은 배포 규칙이 필요할 것이다.

두 번째 신호는 운영 환경에서의 동작이다. Cognition은 매일 승인되는 테스트 실행이 증가했다고 말하지만, 승인량만으로 더 나은 소프트웨어나 더 낮은 검토 비용이 입증되지는 않는다.

더 강력한 지표는 병합된 변경, 외부로 유출된 결함 비율, 롤백 빈도, 승인된 각 기여를 검토하는 데 걸린 시간이다. 팀은 이러한 결과를 기존 검토 방식으로 처리한 유사한 변경과 비교해야 한다.

Cognition은 이미 비즈니스 지표로서 “생산적인 엔지니어링 시간”을 탐구했다. 해당 평가는 233개의 보류 세션을 사용했으며, 약 절반이 인간 추정치의 두 배 범위 안에 있다고 보고했다.

회사는 개별 추정치가 여전히 잡음이 크다는 점도 인정했다. 공개 분석에 따르면 어느 방향이든 두세 배의 오류가 흔하다.

이러한 솔직함은 중요하다. 생산성 주장은 소프트웨어 결과와 분리될 수 있기 때문이다. 절감된 시간의 추정치는 배포 이후 발견된 결함의 비용을 포착하지 못한다.

가장 설득력 있는 근거는 줄어든 검토 시간을 안정적이거나 개선된 품질과 연결하는 것이다. 팀이 더 적은 코드를 검토하지만 회귀가 더 많이 발생한다면, 이 워크플로는 단지 비용을 뒤로 전가하는 셈이다.

결함, 롤백 또는 유지보수가 악화되지 않으면서 검토 시간이 줄어든다면 Cognition의 핵심 논지는 훨씬 강해진다.

세 번째 신호는 경쟁사가 검증을 어떻게 재설계하는지다. 모델 제공업체와 코딩 에이전트 기업은 독립 검토 에이전트, 더 강력한 실행 추적 또는 표준화된 근거 형식으로 대응할 수 있다.

의미 있는 경쟁 대응은 검증이 주요 제품 계층이 되었음을 확인할 것이다. 또한 구매자에게 한 에이전트가 자신의 결과물을 채점하는 상황을 피할 대안을 제공한다.

구현과 검토 모델을 분리하면 유용한 다양성을 도입할 수 있다. 서로 다른 제공업체, 프롬프트 또는 테스트 생성 시스템은 정확히 같은 오해를 재현할 가능성이 낮다.

하지만 모델 다양성만으로 독립성이 보장되지는 않는다. 두 에이전트는 여전히 동일하게 불완전한 명세나 기존 테스트 스위트에 의존할 수 있다.

최고의 시스템은 독립적인 테스트 설계, 결정론적 통제, 아티팩트 출처 추적, 명시적 위험 정책을 결합할 것이다. 그러면 사람의 검토는 자동화가 안전하게 압축할 수 없는 결정에 집중할 수 있다.

엔지니어링 리더는 관찰 가능한 동작이 성공을 강하게 반영하는 범위가 제한된 작업부터 선택해야 한다. 인터페이스 버그 수정, 일상적인 내부 워크플로, 명확하게 명세화된 회귀 문제가 적절한 후보이다.

그들은 Devin에게 무엇을 테스트하지 않았는지 명시하도록 요구해야 한다. 또한 그 근거를 제출된 커밋과 비교하고 민감한 변경에는 기존 통제를 유지해야 한다.

개발자는 새 워크플로를 권위가 아니라 주의력 필터로 사용할 수 있다. 보고서는 어디를 봐야 하는지 알려주고, 녹화 자료는 무슨 일이 일어났는지 보여주며, 위험이 검사를 요구할 때 코드는 여전히 확인할 수 있다.

Cognition이 바라는 결과는 충분히 가능성이 있지만, 저절로 이루어지지는 않는다. 더 나은 테스트는 근거가 실제에 기반하고, 범위가 명확하며, 프로덕션 결과와 연결될 때에만 검토 부담을 줄일 수 있다.

따라서 팀에 가장 중요한 질문은 실용적이다. 실행 근거만으로 승인할 수 있는 변경은 무엇이며, 어떤 변경은 여전히 중요한 모든 코드를 한 줄씩 읽어야 하는가? Devin GPT-6 Astra 테스트를 기본 병합 프로세스에 포함하기 전에 이 경계를 의도적으로 검증해야 한다.