Gemini 4 Carbon: 차세대 프런티어 모델, 제한된 접근으로 시작

Google은 2026년 10월 28일 Gemini 4 Carbon을 발표했지만, 최신 모델의 출발점은 폭넓은 공개 접근이 아니라 선별된 사이버보안 방어 담당자다. “Gemini 4 Carbon: Our next frontier model”이라는 제목의 발표는 강화된 엔지니어링 성능 주장과 의도적으로 제한된 출시를 함께 제시한다. 이것이 이번 출시를 규정한다. Google은 안전장치를 계속 평가하는 동안 방어 담당자들이 이 모델을 사용하기를 원한다.

경쟁 구도에는 OpenAI와 Anthropic이 포함되지만, 핵심 긴장은 Google의 배포 전략 안에 있다. 향상된 취약점 발견 및 수정 기능은 유용한 방어 역량이다. 그러나 관련 역량은 누가 사용할 수 있는지, 무엇을 할 수 있는지에 대한 신중한 통제도 요구한다.

개발자와 기업 구매자에게 이는 성능과 이용 가능성에 관한 별개의 질문을 만든다. Carbon에는 독립적으로 공개된 인텔리전스 점수를 포함해 살펴볼 만한 측정 결과가 있다. 그러나 이러한 결과만으로는 폭넓게 배포되고 보호된 제품이 일상적인 엔지니어링 작업 전반에서 어떻게 작동할지를 입증하지 못한다.

Gemini 4 Carbon: 차세대 프런티어 모델은 사이버 방어 담당자부터 시작한다

Google은 Carbon을 발표했지만, 출시는 선별된 방어 담당자와 신뢰할 수 있는 파트너부터 시작된다.

Google의 Carbon 발표는 일부 사이버보안 방어 담당자에게 초기 접근 권한을 제공하고, 이후 Fairwind Program을 통해 확대할 계획이라고 설명한다. 또한 회사는 출시 전 모델 테스트를 위한 미국 정부의 자발적 절차에 참여하고 있다고 밝혔다.

개발자, 기업, 소비자를 위한 더 폭넓은 이용 가능성은 발표에서 명확한 날짜 없이 목표로 제시됐다. 독자는 이러한 약속과 실제로 이용 가능한 제품을 구분해야 한다. 발표는 방향을 제시하지만, 사용 가능한 접근 권한은 관련 제품 또는 개발 인터페이스를 통한 실제 출시를 필요로 한다.

이 구분은 접근 권한이 누가 이러한 주장을 평가할 수 있는지를 결정하기 때문에 중요하다. 선별된 파트너는 합의된 조건에서 성능을 조사할 수 있다. 다른 엔지니어링 팀은 아직 자신의 리포지토리, 권한 시스템 또는 배포 환경이 비슷하게 작동할 것이라고 가정할 수 없다.

초기 대상층은 앞으로 나타날 가능성이 높은 증거의 성격도 좌우한다. 사이버보안 방어 담당자는 발견 사항이 유효한지, 수정안이 원인을 해결하는지, 민감한 정보가 보호되는지를 평가한다. 이들의 우선순위는 범용 글쓰기 보조 도구를 선택하는 사람의 우선순위와 다르다.

따라서 성공적인 초기 배포에는 인상적인 시연만으로는 충분하지 않다. 유용한 증거는 원래의 문제, 모델의 기여, 필요한 사람의 검토, 최종 결과를 설명해야 한다. 이러한 맥락이 없다면 눈에 띄는 사례도 구매 결정으로 연결하기는 어렵다.

제한된 출시는 팀이 출시 보도를 해석하는 방식도 바꾼다. Carbon이 폭넓게 접근 가능한 모델과 함께 언급된다고 해서 배포 상황까지 동등해지는 것은 아니다. 비교에는 역량뿐 아니라 접근 조건도 반영해야 한다.

엔지니어링 리더에게 즉각적인 시사점은 계획 수립의 엄격함이다. Carbon은 평가 관찰 목록에 올려둘 대상이다. 마이그레이션을 확정하려면 실제로 이전할 워크플로우에서의 이용 가능성 확인과 증거가 필요하다.

보안 리더에게 기회는 더 구체적이다. 초기 접근은 취약점 조사와 수정에 관한 통제된 실험을 지원할 수 있다. 이러한 실험에서는 모델이 작업을 시작하기 전에 승인된 대상, 예상 출력, 검토 책임을 정의해야 한다.

가상의 내부 소프트웨어 감사를 생각해 보자. 유용한 산출물에는 재현 가능한 발견 사항, 영향을 받는 동작에 대한 설명, 제안된 수정안이 포함될 것이다. 이런 뒷받침 자료가 없는 설득력 있는 서술은 방어 담당자에게 상당한 검증 작업을 남긴다.

이 사례는 이번 출시의 핵심에 있는 배포상 절충점을 보여준다. 접근을 제한하면 Google과 파트너는 민감한 역량을 검토할 여지를 얻는다. 동시에 대부분의 잠재 사용자는 스스로 재현할 수 있는 증거를 기다리게 된다.

이번 발표는 Google의 모델 로드맵을 즉시 바꾼다. 일상적인 엔지니어링에 미치는 영향은 접근, 테스트, 통합의 다음 단계에 달려 있다.

보안 팀은 생산성을 다르게 정의해야 한다

Carbon의 실질적 가치는 이후에 이어지는 사람의 검토를 포함해, 얼마나 많은 검증된 작업이 완료되는지에 달려 있다.

사이버보안 보조 도구는 팀이 조사할 수 있는 속도보다 더 빠르게 발견 사항을 생성할 수 있다. 이는 탐지와 해결 사이에 병목을 만들 수 있다. 방어 담당자가 어떤 결과에 주목할 가치가 있는지 식별할 수 있을 때만 더 많은 출력이 도움이 된다.

따라서 구매자에게 관련 있는 생산성 단위는 완료된 조사 또는 승인된 수정이다. 생성된 보고서 수만 세면 실패를 재현하고, 오탐을 기각하고, 제안된 변경을 점검하는 데 필요한 작업을 놓치게 된다.

이는 Carbon의 방어적 포지셔닝에서 도출되는 분석적 함의이지, 출시에서 측정된 결과는 아니다. 모델 활동이 결과를 책임지는 팀의 전체 부담을 줄일 때 배포 근거는 더 강해진다.

가상의 유지보수 작업은 이 차이를 구체적으로 보여준다. 보조 도구가 의존성에서 의심스러운 동작을 식별하고 변경을 제안한다. 팀은 여전히 영향을 받은 경로에 실제로 도달할 수 있는지, 수정안이 의도된 동작을 보존하는지를 판단해야 한다.

보조 도구가 신뢰할 수 있는 재현 절차와 집중된 테스트를 제공한다면, 그 검토를 더 쉽게 만들 수 있다. 불확실한 주장과 광범위한 재작성을 제공한다면 추가 작업을 만들 수 있다. 두 출력 모두 시연에서는 생산적으로 보일 수 있다.

같은 논리는 자율 실행에도 적용된다. AI 에이전트는 모델을 사용해 행동을 선택하고 도구를 운용하는 시스템이다. 더 많은 자유를 부여하면 권한, 로깅, 개입 기회의 중요성이 커진다.

코드를 실행하고 검토하기 위한 격리 환경인 개발 샌드박스는 평가의 유용한 출발점을 제공한다. 팀은 더 민감한 시스템에 대한 접근을 고려하기 전에 제안된 행동을 검토할 수 있다.

엔지니어링 관리자는 조정 문제에도 직면한다. 보조 도구가 장기간에 걸쳐 문제를 조사할 때 사람들은 그것이 무엇을 시도했는지 이해할 필요가 있다. 그렇지 않으면 검토자는 확립된 발견 사항과 포기된 가설을 구분하기 어려울 수 있다.

이 때문에 읽기 쉬운 작업 기록은 제품 유용성의 일부가 된다. 최종 답변은 결론을 뒷받침하는 증거와 아직 완료되지 않은 점검 항목을 식별해야 한다. 매력적인 요약은 이러한 구분을 대체할 수 없다.

보안 구매자는 결함 발견과 수정 승인도 구분해야 한다. 유효한 발견 사항이 곧바로 프로덕션 서비스를 변경할 정당성을 제공하는 것은 아니다. 기존의 소유권 및 릴리스 절차가 누가 제안된 수정을 수용하는지 계속 결정한다.

지식 근로자도 소스 코드를 전혀 검토하지 않더라도 관련된 관심사가 있다. 보조 도구가 문서를 조사하거나 여러 도구의 정보를 결합할 때마다 같은 질문이 적용된다. 독자가 결론을 뒷받침 자료까지 추적할 수 있는가?

평가 메모를 검색 가능한 지식 기반에 보관하면 팀이 그 연결을 유지하는 데 도움이 될 수 있다. 기록은 관찰된 동작, 공급업체의 진술, 미해결 질문을 구분해야 한다.

Carbon의 경우 압력은 결국 배포 근거에 집중된다. Google은 잠재 사용자가 추가 역량이 실제로 사용할 수 있는 결과를 낳는다는 점을 확인하도록 해야 한다. 구매자는 이러한 결과가 자신의 책임 범위에 맞는지 판단할 충분한 증거가 필요하다.

리더보드는 중요한 한계와 함께 Google의 입지를 뒷받침한다

Carbon은 일반 역량에 관한 독립적 증거를 갖추고 있지만, 개별 작업에는 별도의 비교가 여전히 필요하다.

Artificial Analysis는 intelligence index에서 Carbon을 59점으로 제시하며, 요약에 표시된 모델 가운데 1위에 올려놓았다. 이 지수는 여러 유형의 작업에 걸친 평가를 결합한다. 이는 Google 자체의 설명을 넘어서는 증거를 제공한다.

종합 점수는 조사할 가치가 있는 모델을 식별하는 데 유용하다. 다양한 결과를 공통의 기준점으로 압축한다. 그러나 이러한 압축은 구매자가 특정 워크플로우를 중요하게 여길 때 필요한 차이를 가리기도 한다.

Google의 모델 벤치마크 결과는 이러한 변화를 보여준다. 해당 표는 FrontierSWE 2에서 Carbon이 61.2%를 기록했으며, GPT-6 Astra의 65.5%와 Claude Opus 5.5의 62.3%보다 낮다고 제시한다.

같은 표에서 Carbon은 오프라인 OSWorld-2.1 하위 집합에서 81.5%를 기록했으며, Claude Opus 5.5는 87.2%에 도달했다. 이러한 비교는 전체 선두가 보편적 우월성의 주장으로 바뀌어서는 안 되는 이유를 보여준다.

벤치마크는 정해진 작업 집합에서 성능을 측정하도록 설계된 표준화된 평가다. 그 관련성은 해당 작업이 팀이 수행해야 하는 업무와 얼마나 유사한지에 달려 있다.

익숙하지 않은 소프트웨어를 유지보수하는 구매자에게는 리포지토리 조사가 인터페이스 조작보다 더 중요할 수 있다. 다른 팀에는 애플리케이션 탐색이 핵심일 수 있다. 어느 팀도 추가 테스트 없이 종합 순위에 판단을 맡겨서는 안 된다.

비교는 평가 설정도 보존해야 한다. 광범위한 추론이나 넉넉한 실행 시간으로 얻은 결과는 엄격하게 제한된 실행과는 다른 실무적 질문에 답한다. 두 결과 모두 명확하게 표기된다면 유용한 정보를 제공할 수 있다.

이는 Google의 이전 모델인 Argon과 Carbon을 비교하는 데 더 유용한 틀을 만든다. 핵심 질문은 새 모델이 평가와 궁극적인 도입을 정당화할 만큼 작업 완료 방식을 어디에서 바꾸는가이다. 이름이 다르다는 사실만으로는 그 기준을 입증하지 못한다.

OpenAI 및 Anthropic과의 비교도 같은 방식으로 작동한다. 이들의 존재는 구매자가 조사할 대안을 제공한다. 그렇다고 해서 보고된 모든 백분율이 동일한 환경이나 독립적으로 반복된 실험에서 나왔다고 가정할 근거는 되지 않는다.

신중한 후보 목록은 특정 작업에 대한 불확실성을 유지하면서 Carbon의 전체적 입지를 인정할 수 있다. 이 접근 방식은 강력한 독립 결과의 중요성을 폄하하지 않으면서 증거 기반 조달을 뒷받침한다.

예를 들어 가상의 기업 비교는 후보 모델 전반에 걸쳐 동일한 과거 유지보수 이슈를 사용할 수 있다. 검토자는 완료된 수정, 근거 없는 결론, 개입 필요성, 재현성을 살펴볼 것이다. 이러한 평가는 공개 순위가 해결할 수 없는 현지의 질문에 답한다.

이런 테스트는 과제에 답을 미리 포함하지 않아야 한다. 프롬프트가 이미 알려진 수정안을 드러낸다면, 성공은 조사 역량에 대해 거의 말해주지 않는다. 과거 사례는 검토 중인 행동을 드러낼 만큼 충분한 현실성을 갖춰야 한다.

“Gemini 4 Carbon: Our next frontier model”이라는 헤드라인 문구는 Google의 포지셔닝을 설명한다. 리더보드는 이러한 포지셔닝을 진지하게 받아들일 근거를 제공한다. 그러나 모델 선택은 여전히 중요한 업무, 설정, 접근 조건으로 주장을 좁혀 검토해야 한다.

사이버보안 점수는 업무의 서로 다른 부분을 측정한다

Carbon의 방어적 유용성을 판단할 때 발견, 악용, 수정 결과는 분리해서 봐야 한다.

Google의 평가 방법론은 사이버 보안 결과가 어떤 방식으로 도출됐는지를 구분한다. 비율 수치는 그것을 만들어 낸 조건 없이는 의미가 제한적이므로, 이 문서는 중요하다.

SEC-bench Pro의 경우 Google은 JavaScript 엔진 작업 분할에 대해 자체 산출한 결과를 설명한다. ExploitGym의 경우 인터넷 접속이 없는 오픈 소스 설정을 사용해 자체 평가한 결과를 보고한다. 경쟁사 수치는 공개된 기술 자료에서 가져온 것이다.

이 문서는 CWE-bench 결과가 여러 모델에 걸친 Collinear AI의 평가에서 나온 것이라고 명시한다. 또한 대부분의 Gemini 결과는 단일 시도 점수이며, 예외와 추가 세부 사항은 별도로 규정된다고 설명한다.

이러한 구분은 보도에서 흔히 발생하는 오류를 막아 준다. 벤치마크는 Google 외부 기관의 것일 수 있지만, 특정 모델 결과는 Google이 산출했을 수 있다. 벤치마크의 이름만으로 누가 테스트를 수행했는지는 알 수 없다.

각 단계 역시 서로 다른 질문에 답한다. 취약점 발견은 가능한 결함을 식별한다. 익스플로잇은 의도하지 않은 동작을 유발하는 방법을 입증한다. 수정은 근본 문제를 해결하기 위해 소프트웨어를 변경하는 일이다.

방어 담당자는 조사 과정에서 이 모든 단계가 필요할 수 있지만, 한 단계에서의 성공이 다른 단계에서의 성공을 보장하지는 않는다. 재현 가능한 실패도 불완전한 수정으로 이어질 수 있다. 그럴듯한 수정안도 원래 결함을 해결했다는 증거가 없을 수 있다.

평가 환경은 결과를 일관되게 채점할 수 있도록 이러한 관계 중 일부를 단순화한다. 실제 배포에는 소프트웨어 소유권, 릴리스 요건, 허용 가능한 변경 사항 등 추가 맥락이 개입한다. 이 맥락은 구매자의 평가에 포함돼야 한다.

따라서 Carbon과 Argon을 비교할 때 의미 있는 개선은 구체적이어야 한다. Carbon은 이전 모델이 놓친 결함을 식별하는가? 검토자가 받아들일 수 있는 수정안을 만들어 내는가? 다음 조사를 이끌 만큼 불확실성을 정확하게 설명하는가?

이 질문들은 출시로 입증된 발견 사항이 아니라 제안된 평가 기준이다. 그 목적은 보고된 역량 범주를 보안팀이 내려야 하는 의사결정과 연결하는 데 있다.

실행 예산을 비교할 때도 방법론에 주목할 필요가 있다. 시간이 더 주어지면 에이전트는 추가 경로를 탐색할 수 있다. 결과는 설정과 무관한 내재적 특성으로 취급하기보다 허용된 도구 및 실행 시간과 함께 해석해야 한다.

테스트가 운영 환경과 다르다는 이유만으로 이를 무시할 필요는 없다. 통제된 평가는 동작을 분리해 살펴볼 수 있기 때문에 가치가 있다. 오류는 설계가 뒷받침하는 범위를 넘어 결론을 확대하는 데 있다.

가상의 패치 검토 워크플로에서 팀은 원래 재현 과정, 제안된 변경 사항, 영향을 받지 않은 동작에 대한 테스트를 점검할 수 있다. 이후 검토자는 모델이 조사 노력을 줄였는지, 아니면 단지 다른 곳으로 옮겼는지를 판단할 수 있다.

점수화된 작업과 승인된 작업 사이의 이러한 연결이 주목할 만한 메커니즘이다. 발견이 수정으로, 수정이 검증된 해결로 이어진다는 증거가 있을 때 Carbon의 방어적 활용 사례는 더욱 설득력을 얻는다.

더 강력한 보호 장치도 배포 환경에서의 증거가 필요하다

보고된 안전성 개선은 사용자가 실제로 Carbon을 받게 될 조건에서 면밀히 검토할 가치가 있다.

Google의 더 폭넓은 Gemini 안전성 접근 방식은 단계적 배포의 맥락을 제공한다. Argon에 대한 설명은 보안 작업 사례와 함께, 더 폭넓은 출시 이전에 일부 방어 담당자에게 접근 권한을 제공했다고 전한다.

Google은 Wiz가 이전 모델들이 놓친 병원 소프트웨어 버그를 Argon으로 발견했다고 말한다. 이는 보고된 Argon 사례다. 이를 입증된 Carbon 결과로 다시 분류해서는 안 된다.

이 구분은 이전 모델의 경험이 후속 모델의 신뢰성을 입증하지는 않으면서도 배포 전략을 뒷받침할 수 있기 때문에 중요하다. Carbon에는 자체 동작, 설정 및 출시 구성에 연결된 증거가 필요하다.

Google의 Carbon 발표에 따르면 사이버 보안 벤치마크는 허용된 동작을 제한하는 보호 통제 장치인 가드레일 없이 평가됐다. 따라서 원시 역량과 배포된 유용성의 관계가 특히 중요해진다.

보호된 제품은 기저 역량을 측정하는 데 사용된 구성과 다르게 동작할 수 있다. 제한은 부적절한 요청을 차단하는 동시에 정당한 조사에도 영향을 미칠 수 있다. 출시된 시스템의 평가는 두 결과를 모두 살펴봐야 한다.

프롬프트 인젝션, 즉 읽는 자료에 삽입된 지시문을 통해 어시스턴트의 방향을 바꾸려는 시도는 또 다른 배포 우려를 더한다. 보안 어시스턴트는 승인된 작업 중 신뢰할 수 없는 텍스트를 마주칠 수 있다. 시스템은 그 자료를 처리하면서도 사용자의 지시를 유지해야 한다.

벤치마크는 선택된 공격에 대한 저항성을 테스트할 수 있다. 그러나 향후의 모든 입력이나 환경에 대한 면역성을 입증할 수는 없다. 구매자는 유리한 결과를 범위가 보존된 평가 사례에 관한 증거로 읽어야 한다.

정직성과 지시 준수에 관한 주장에도 같은 주의가 필요하다. 유용한 평가는 어시스턴트가 누락된 증거를 보고하는지, 불완전한 검사를 식별하는지, 맡은 업무의 경계를 지키는지를 살펴봐야 한다.

이러한 동작은 모델이 작업을 미완으로 남긴 채 자신감 있게 말할 수 있기 때문에 중요하다. 평가자는 인정된 한계와 근거 없는 완료 주장 사이를 구분해야 한다. 그 차이는 사람이 안전하게 작업을 이어갈 수 있는지에 영향을 미친다.

가상의 감사 사례가 이 문제를 보여 준다. 어시스턴트가 발견 사항을 재현하는 데 필요한 종속성에 접근할 수 없다. 유용한 응답은 누락된 접근 권한을 설명하고 결론의 범위를 좁혀, 검토자에게 명확한 다음 단계를 제시한다.

신뢰할 수 없는 응답은 그럼에도 재현에 성공한 것처럼 암시할 것이다. 이러한 동작을 탐지하려면 최종 보고서와 함께 실행 기록을 검토해야 한다. 문구만 읽어서는 불일치를 놓치게 된다.

따라서 배포상의 절충점은 접근 제한을 넘어선다. Google에는 유용하고 승인된 작업을 보존하는 보호 장치가 필요하다. 잠재적 사용자는 보호된 구성이 여전히 효과적이며 그 한계를 명확히 전달한다는 증거가 필요하다.

제한된 접근은 이러한 질문을 조사할 기회를 만든다. 그러나 그것만으로 질문이 해결되지는 않는다. 실제 운영 제약 아래 Carbon을 사용하는 사람들로부터 구체적 결과가 나오면서 단계적 접근의 가치는 더 분명해질 것이다.

접근성, 검증된 결과, 동등 조건의 평가를 지켜봐야 한다

다음으로 유용한 신호는 더 폭넓은 이용 가능성, 문서화된 방어적 결과, 동등한 조건에서의 비교다.

첫 번째 신호는 접근성의 구체적인 변화다. 향후 수개월 동안 명시된 제품 인터페이스, 자격 요건 및 개발 문서를 살펴봐야 한다. 이러한 세부 정보는 일반적인 출시 의도를 팀이 평가할 수 있는 형태로 바꿔 줄 것이다.

더 폭넓은 접근은 Carbon이 선별된 파트너 배포를 넘어 발전하고 있다는 근거를 강화할 것이다. 지속되는 제한은 일반 개발자와 기업 워크플로에 대한 유용성의 불확실성을 유지할 것이다. 어느 결과도 그것만으로 기술적 품질을 입증하지는 않는다.

이용 가능성도 정확하게 설명돼야 한다. 관리형 인터페이스를 통한 접근은 기존 엔지니어링 워크플로를 지원하는 접근과 다를 수 있다. 팀은 자신에게 제공되는 도구, 권한 및 운영 조건을 살펴봐야 한다.

두 번째 신호는 방어적 사용에서 나온 문서화된 결과다. 가장 강력한 사례는 발견 사항을 검증된 수정과 연결하고 사람의 기여를 설명할 것이다. 이러한 증거는 Google의 초기 대상 고객에 대한 논리를 직접 뒷받침할 것이다.

상세한 사례는 호의적인 인상만 모아 놓은 것보다 더 많은 정보를 제공한다. 독자는 시스템이 무엇을 발견했는지, 검토자가 무엇을 확인했는지, 그리고 궁극적으로 무엇이 바뀌었는지를 이해해야 한다. 민감한 세부 사항은 보호하면서도 평가 방법은 명확하게 유지할 수 있다.

실패 역시 유용한 정보가 될 수 있다. 거부된 발견 사항이나 불완전한 수정에 대한 기록은 성공 사례가 놓치는 경계를 드러낼 수 있다. 이러한 보도는 잠재적 사용자가 Carbon이 자신의 워크플로에서 어디에 속하는지 결정하는 데 도움이 될 것이다.

세 번째 신호는 일치하는 작업과 조건을 사용하는 비교다. Carbon과 Argon의 비교는 최신 모델이 관련 작업을 실질적으로 개선하는지 보여 줄 것이다. 다른 공급업체와의 비교는 이용 가능한 대안이 어디에서 다른지 명확히 할 것이다.

동등한 권한, 실행 예산 및 검토 기준은 이러한 비교를 더욱 유용하게 만든다. 결과는 작업 완료와 이를 검증하는 데 필요한 노력을 구분해야 한다. 더 많은 작업을 마치지만 광범위한 검토를 요구하는 모델은 다른 도입 결정을 제시한다.

Carbon이 이런 조건에서도 우위를 유지한다면 Google의 배포 근거는 더 강해진다. 보호된 구성에서 우위가 좁혀진다면 구매자는 활용 범위에 대한 더 명확한 경계를 얻게 된다. 어느 결과든 논의의 질을 높일 것이다.

현재로서는 Gemini 4 Carbon: Our next frontier model은 독립적으로 등재된 지능 결과와 미해결 배포 질문을 지닌, 검증된 발표다. 그 중요성은 엔지니어링 야심과 통제된 접근의 결합에서 나온다.

마이그레이션 결정을 내리기 전에 발표, 벤치마크 방법론 및 이후의 배포 증거를 함께 검토해야 한다. 자신의 작업에서 대표적인 과제를 선택하고, 수용 가능한 결과를 정의하며, 검토자가 확인해야 할 사항을 기록하라. 적절한 접근 권한이 제공되면 Carbon을 현재 그 작업을 수행하는 모델과 비교하라. 성공 사례와 함께 실패한 시도도 보존하고, 제안된 수정과 승인된 변경을 구분하라. 이러한 기록을 관리하는 팀이라면 공유된 평가 이력을 통해 나중의 결정이 기억에 남는 시연에만 의존하는 일을 막을 수 있다. 이 평가에서 던져야 할 질문은 구체적이다. Carbon은 팀이 실제로 부여할 수 있는 권한 아래, 관리 가능한 검토 부담으로 검증된 결과를 제공하는가?