Google Cloud 가상 차량, AAOS를 넘어 가장 작은 컨트롤러까지 확장

Google Cloud가 콕핏을 넘어, 소프트웨어 팀이 하드웨어를 기다리게 만드는 소형 컨트롤러까지 가상 차량 개발 방식을 확장하고 있다. 10월 20일 발표에서는 Google의 차량 운영체제인 Android Automotive OS를 RemotiveLabs를 통해 시뮬레이션된 차량 네트워크와 연결하는 방안을 설명한다. Google Cloud 가상 차량은 이처럼 분리된 시스템을 더 이른 통합 테스트 단계로 끌어들이기 위한 것이다.

핵심적인 긴장은 실무적이다. 대시보드를 독립적으로 테스트한다고 해서 그것이 차량의 나머지 부분과 올바른 정보를 주고받는다는 사실까지 확인할 수는 없다. 기능이 상당 부분 소프트웨어에 의존하는 소프트웨어 정의 차량은 여전히 구성요소 간 조율된 동작이 필요하다. Google은 이미 원격 테스트가 가능한 소프트웨어 팀과, 여전히 물리적 장비에 묶여 있는 팀 사이의 간극을 겨냥하고 있다.

AWS는 앞서 상호 연결된 가상 자동차 구성요소를 설명한 바 있으며, 이는 Google의 접근 방식을 이해하는 데 유용한 기준점이 된다. 구매자가 던져야 할 질문은 이러한 환경이 실제 양산 차량의 동작을 얼마나 반영하는지, 그리고 실제로 어떤 개발 지연을 없애는지다. 시연이 설득력 있는 가상 콕핏을 보여줄 수 있는지보다 이 구분이 더 중요하다.

Google Cloud 가상 차량, 콕핏을 넘어 통합 단계로 이동

이번 발표는 개별 차량 애플리케이션 실행에서 차량 시스템 간 연결 테스트로 관심을 옮긴다.

Google의 virtual vehicle architecture는 Android의 가상 테스트 환경과 연결된 차량 구성요소를 설명하고 실행하는 도구인 RemotiveTopology를 결합한다. 명시된 목표는 콕핏 컴퓨팅에서 제어 시스템에 내장된 소형 컴퓨터인 마이크로컨트롤러 유닛(MCU)까지 이어진다.

이는 차량 하드웨어가 더 이상 필요 없게 되었다는 발표가 아니라 개발 방식에 관한 제안이다. 또한 엔지니어가 소프트웨어를 구축하고 테스트하는 위치와도 관련된다. 독자는 클라우드 기반 개발이 주행 중인 차량이 원격 서버에 의존해야 한다는 의미로 해석해서는 안 된다.

전자 제어 장치(ECU)는 특정 차량 기능을 담당하는 컴퓨터다. 중요한 통합 질문은 한 구성요소의 출력이 다른 구성요소의 입력이 될 때 무엇이 일어나는가다. 구성요소는 개발자의 의도대로 작동하면서도 공유 신호에 대한 다른 팀의 해석과 불일치할 수 있다.

예를 들어 주행 모드 변경 상황을 생각해 볼 수 있다. 콕핏은 요청된 모드를 표시하지만, 다른 구성요소는 여전히 이전 상태를 보고할 수 있다. 각 애플리케이션은 개별 검사를 통과할 수 있지만, 함께 작동할 때는 일관성이 없을 수 있다. 상호작용을 테스트하면 이러한 불일치가 드러난다.

이 사례는 가상 차량에 보기 좋은 화면 이상이 필요한 이유도 설명한다. 유용한 산출물은 소프트웨어, 연결, 입력 및 예상 응답을 실행 가능하게 구성한 것이다. 그 가치는 이러한 구성이 어떤 엔지니어링 질문에 답할 수 있는지에 달려 있다.

따라서 이러한 환경을 평가하는 제품 관리자는 개발 프로세스에서 무엇이 달라졌는지 물어야 한다. 장비가 도착하기 전에 팀이 인터페이스 불일치를 조사할 수 있는가? 다른 엔지니어가 실패를 재현할 수 있는가? 공급업체가 소프트웨어를 업데이트한 뒤에도 동일한 시나리오를 실행할 수 있는가?

이 질문들은 광범위한 인프라 발표를 평가 가능한 엔지니어링 제안으로 바꾼다. 또한 주장에 대한 경계를 설정한다. 통신 오류를 일찍 포착하는 환경은 양산 차량의 모든 물리적 특성을 재현하지 않더라도 가치가 있을 수 있다.

개발자에게 즉각적인 기회는 인접 시스템에 더 일찍 접근하는 것이다. 프로그램 리더에게는 통합 가정에 대한 더 이른 근거를 제공한다. 이러한 이점은 단순히 더 많은 클라우드 용량이 아니라, 참여 구성요소를 유용하게 표현하는 방식이 필요하다.

이 때문에 Google이 소형 컨트롤러를 강조하는 점이 중요하다. 개발 환경은 의미 있는 테스트를 가로막는 의존성까지 도달할수록 더 관련성이 높아진다. 다만 범위 확장은 추가된 구성요소가 엔지니어가 실제로 검토해야 하는 동작을 나타낼 때만 도움이 된다.

공급업체는 더 이른 시점에 테스트 가능한 동작을 제공해야 한다는 압박에 직면한다

더 이른 통합은 언제 해당 정보가 활용 가능해져야 하는지를 포함해 자동차 제조사가 공급업체에 요구하는 바를 바꾼다.

Google이 설명하는 접근 방식에서는 개발 이정표가 공유 환경에서 실행 가능한 기여물 쪽으로 이동한다. 그 기여물에는 양산 소프트웨어 또는 예상 동작을 제한적으로 표현한 모델이 포함될 수 있다. 어느 경우든 그 범위는 명확해야 한다.

공급업체에는 협의해야 할 추가 납품물이 생긴다. 네트워크 설명만 제공한다고 해서 구성요소가 어떻게 반응하는지에 관한 모든 질문에 답할 수는 없다. 실행 가능한 소프트웨어를 제공하면 접근 권한, 유지보수, 그리고 해당 소프트웨어의 허용된 사용 방식에 관한 별도의 질문이 생긴다.

자동차 제조사에도 이에 상응하는 책임이 있다. 누군가는 어떤 구성요소 버전이 함께 속하는지, 어떤 가정이 잠정적인지, 어떤 실패가 추가 개발을 막는지를 결정해야 한다. 테스트 시점을 앞당긴다고 해서 책임 소재가 자동으로 정해지는 것은 아니다.

이 지점에서 일정 압박은 조직적 압박이 된다. 가상 환경은 물리적 통합 이전에 불일치를 드러낼 수 있지만, 참여 팀은 여전히 이를 해결할 프로세스가 필요하다. 답을 얻지 못한 인터페이스 문제는 테스트가 어디에서 실행되든 여전히 미해결 상태다.

유용한 수용 기준은 공급업체의 기여물이 지원해야 하는 동작을 식별한다. 예를 들어 팀은 구성요소가 상태 전환을 보고하고 거부된 요청을 처리하도록 요구할 수 있다. 이는 가상 차량과의 일반적인 호환성을 요청하는 것보다 더 실행 가능하다.

이 구분은 소규모 공급업체에도 중요하다. 구매자는 유용한 가상 기여물을 제작하고 유지하는 데 필요한 노력을 평가해야 한다. 그렇지 않으면 누가 비용을 부담하고 최신 상태를 유지할지에 대한 명확한 합의 없이 작업이 상류로 이전될 수 있다.

기존 엔지니어링 지식도 실행 가능한 환경을 따라가야 한다. 결정 사항이 메시지, 인터페이스 문서, 회의 기록에 흩어져 있으면 테스트 결과를 해석하기 어려워진다. 재현 가능한 실패에도 참여 팀이 무엇을 기대했는지에 대한 설명이 필요하다.

searchable engineering knowledge base는 팀이 기술 문서와 함께 그러한 결정을 찾아볼 수 있도록 돕는다. 이는 테스트 환경과 다른 목적을 수행한다. 즉, 결과를 이해하고 해결하는 데 필요한 맥락을 보존하는 역할이다.

따라서 압박은 임베디드 소프트웨어 개발자에게만 가해지지 않는다. 아키텍처 팀에는 일관된 정의가 필요하고, 조달 팀에는 명확한 납품물이 필요하며, 프로그램 관리자에게는 관찰 가능한 동작과 연결된 이정표가 필요하다. 가상 통합 전략은 이 모든 책임에 영향을 미친다.

엔터프라이즈 구매자에게 이는 구체적인 평가 방식을 시사한다. 기존 통합 의존성 하나를 선택해 각 참여자가 무엇을 제공해야 하는지 추적하라. 이 과정은 제안된 플랫폼이 대기 시간을 없애는지, 아니면 누락된 합의를 더 일찍 드러낼 뿐인지를 보여줄 것이다.

두 결과 모두 정보를 제공한다. 조기 가시성은 유용하지만, 구매자는 공급업체의 진척 주장 평가 시 이를 완료된 해결과 구분해야 한다.

Vehicle-as-code는 연결 관계를 소프트웨어의 일부로 만든다

이 메커니즘은 내부에서 실행되는 소프트웨어와 함께 시스템 구성을 재현 가능하게 만드는 데 달려 있다.

Vehicle-as-code는 도구가 해석하고 실행할 수 있는 파일로 차량의 전자 아키텍처를 표현하는 것을 의미한다. 아키텍처 설명은 엔지니어가 검토하고, 버전 관리하고, 재사용할 수 있는 대상이 된다. 이는 참여 구성요소를 위한 공통 참조점을 제공한다.

RemotiveLabs의 vehicle-as-code concepts는 플랫폼 설명과 실행 가능한 인스턴스를 구분한다. 플랫폼은 사용 가능한 구성요소와 통신 경로를 설명한다. 인스턴스는 실행할 특정 구성을 선택한다.

이 구분은 중요한 오해를 막는다. 완전한 아키텍처를 설명한다고 해서 그 아키텍처의 모든 구성요소가 모든 테스트에서 실행된다는 뜻은 아니다. 범위가 계속 드러나는 한, 집중된 구성은 더 좁은 질문에 답할 수 있다.

문서는 또한 양산 소프트웨어, 구성요소 동작을 모방하는 행동 모델, 그리고 테스트로 제어되는 응답을 제공하는 모의를 구분한다. 이러한 표현은 서로 다른 목적에 사용된다. 이들이 존재한다는 사실은 엔지니어가 통과 결과를 해석하는 방식에 영향을 줘야 한다.

예를 들어 모의는 디스플레이의 오류 처리 기능을 테스트하는 데 필요한 정확한 응답을 제공할 수 있다. 그 결과는 디스플레이에 대해 유용한 정보를 제공한다. 하지만 최종 양산 컨트롤러가 동등한 조건에서 그 응답을 생성할지에 대해서는 더 적은 정보를 제공한다.

분석상의 장점은 이러한 구분을 숨기지 않고 추적하는 데서 나온다. 테스트 환경은 실제로 무엇이 실행됐는지 식별할 수 있어야 한다. 그렇지 않으면 “full vehicle”이라는 표현이 아키텍처 적용 범위와 양산 소프트웨어 적용 범위의 차이를 가릴 위험이 있다.

구성 일관성도 또 다른 제약이다. RemotiveLabs의 platform descriptions는 시스템 또는 통신 정보를 설명하는 ARXML 및 DBC 형식을 포함해 기존 자동차 네트워크 파일을 통합할 수 있다. 관련 파일을 결합할 때는 호환되는 이름, 설정 및 버전이 필요하다고 문서에서 명시한다.

파일을 가져온다고 해서 상충하는 엔지니어링 결정이 조정되는 것은 아니므로 이 요구 사항은 주목할 만하다. 팀이 호환되지 않는 정의를 제공하면 자동화된 환경에서도 여전히 해결이 필요하다. 재현성은 불일치를 조사하기 쉽게 만들지만, 어느 정의가 옳은지를 결정하지는 않는다.

Google Cloud 가상 차량의 실질적 약속은 소프트웨어와 주변 시스템 간의 관계를 검토 가능하게 만드는 것이다. 소프트웨어 변경은 알려진 구성에 맞춰 평가할 수 있다. 아키텍처 변경도 마찬가지로 검토의 명시적인 일부가 될 수 있다.

변경 사항을 자동으로 빌드하고 테스트하는 관행인 지속적 통합은 이러한 관계를 위한 기반을 제공한다. 유용한 증거 단위는 식별된 구성 내에서 테스트된 소프트웨어 개정본이 된다. 그 구성에서 분리된 결과는 신뢰하기 어렵다.

이는 팀이 적용 범위를 논의하는 방식도 바꾼다. 연결된 구성요소 수를 세는 것만으로는 충분하지 않다. 구매자는 어떤 상호작용이 실행됐는지, 어떤 구현이 참여했는지, 그리고 나머지 동작은 어떤 가정에 의해 제공됐는지 알아야 한다.

따라서 가장 강력한 시연은 엔지니어링 불일치가 재현 가능해지고 이후 해결되는 과정을 보여줄 것이다. 이는 전체 차량이 클라우드에서 시작될 수 있다는 광범위한 주장보다 독자에게 더 많은 정보를 제공한다.

AAOS 가상 테스트에는 하드웨어 경계가 남는다

충실한 소프트웨어 환경에도 하드웨어 의존적 동작에 대한 명확한 경계가 필요하다.

Cuttlefish는 Android의 구성 가능한 가상 기기로, 이 아키텍처에서 이미 확립된 요소입니다. Google의 virtual Android devices 문서는 이를 로컬 또는 원격에서 실행하는 방법을 설명하며 Android 프레임워크 동작에 대한 높은 충실도를 강조합니다. 또한 하드웨어별 구현과 관련된 차이도 명시합니다.

이 단서는 발표 내용과 직접적으로 관련됩니다. 일반적으로 AAOS로 줄여 부르는 Android Automotive OS는 모든 참여 하드웨어 상호작용을 동등하게 만들지 않으면서도 더 큰 테스트 구성에 참여할 수 있습니다. 환경의 적용 범위를 확장한다고 해서 그 안의 차이가 사라지는 것은 아닙니다.

하드웨어 추상화 계층은 운영체제를 기기별 기능에 연결하는 소프트웨어입니다. Cuttlefish 문서는 이 영역을 물리적 기기와 차이가 발생하는 원인으로 명확히 지목합니다. 구매자는 더 광범위한 가상 차량 주장을 해석할 때 이 단서를 유지해야 합니다.

공유 프로세서 아키텍처에도 같은 주의가 필요합니다. 유사한 실행 기반은 개발 전략을 뒷받침할 수 있지만, 구매자에게는 여전히 특정 대상에 관한 근거가 필요합니다. 소프트웨어 호환성에 관한 설명은 비교 대상 소프트웨어, 하드웨어 가정, 그리고 동작을 식별해야 합니다.

이는 헤드라인의 범위가 콕핏 컴퓨팅에서 가장 작은 MCU까지 확장될 때 특히 중요합니다. 컨트롤러의 메시지를 표현하는 일은 그 컨트롤러의 프로덕션 소프트웨어를 실행하는 일과 다릅니다. 그 소프트웨어를 실행하는 일도 물리적 주변 환경과의 모든 상호작용을 재현하는 일과는 다릅니다.

이러한 구분이 가상 테스트의 가치를 훼손하는 것은 아닙니다. 오히려 결과가 무엇을 입증하는지 규정합니다. 가정이 엔지니어가 답하려는 질문과 일치한다면, 범위가 좁은 결과도 매우 유용할 수 있습니다.

문제는 전달 과정에서 범위가 확대될 때 발생합니다. 성공적인 인터페이스 테스트가 완전한 시스템 동등성에 대한 주장으로 바뀔 수 있습니다. 클라우드 시연은 남은 검증 작업이 사라졌다는 주장으로 바뀔 수 있습니다. 어느 결론도 자동으로 도출되지는 않습니다.

Google과 RemotiveLabs는 초기 고객 참여에서 통합 주기가 10배 이상 빨라졌다고 보고합니다. 이 발표는 해당 수치를 일반적인 벤치마크로 취급하기에 충분한 방법론적 세부 정보를 제공하지 않습니다. 독자는 이를 자신의 프로그램에 적용하기 전에 기준선, 측정한 활동, 남은 작업을 알아야 합니다.

평가에서는 경과 대기 시간과 엔지니어링 노력을 구분해야 합니다. 장비 대기열을 없애는 것은 가치가 있지만, 결함 조사 시간을 줄이는 것과는 다른 내용을 측정합니다. 이런 결과를 하나의 가속 수치로 합치면 실제 이점이 가려질 수 있습니다.

구매자는 테스트 환경이 바뀌어도 발견 사항이 유지되는지도 물어야 합니다. 가상 환경에서 식별된 문제가 예상한 물리 조건에서도 나타나는가? 제안된 수정안이 두 환경 모두에 적용되는가? 이는 보편적 동등성을 요구하지 않으면서 관련성을 평가하는 데 유용한 질문입니다.

따라서 도출되는 판단은 하드웨어가 대체되었다는 주장보다 더 제한적이고 실용적입니다. AAOS 가상 테스트는 엔지니어가 어떤 결론이 하드웨어 경계를 넘어 적용되는지 계속 확인하는 동안 더 이른 통합을 지원할 수 있습니다.

AWS는 연결형 가상 구성 요소의 선례를 제공합니다

Google의 접근 방식은 자동차 통합을 물리적 개발 대상에 덜 의존하게 만들려는 기존 노력에 합류합니다.

AWS는 2024년 6월 13일 Panasonic Automotive vSkipGen과 ETAS RTA-VRTE StarterKit을 사용하는 관련 아키텍처를 설명했습니다. 이들의 interconnected virtual targets는 더 이른 통합을 지원하기 위해 공급업체 환경을 연결했습니다. 공개된 구성은 참여자가 소스 코드를 공개하지 않아도 협업할 수 있는 방안도 다뤘습니다.

이 선례는 현재 발표를 이해할 맥락을 제공합니다. 클라우드 인프라를 통해 자동차 소프트웨어 구성 요소를 연결하는 것은 이미 확립된 방향입니다. Google의 기여는 특정 통합 경로, 지원 환경, 참여 엔지니어링 팀에 대한 유용성을 기준으로 평가해야 합니다.

이 비교가 승자를 결정하는 것은 아닙니다. 인용된 자료는 서로 다른 구성을 설명하며 공통 벤치마크를 제공하지 않습니다. 상대적 완성도나 성능에 관한 주장을 하려면 동등한 워크로드와 명확히 일치하는 평가 기준이 필요합니다.

경쟁 관점에서 Google 가상 차량을 이해하려는 독자에게 유용한 비교는 개발 의존성에 관한 것입니다. 어떤 접근 방식이 프로그램에서 이미 사용하는 구성 요소에 맞는가? 어떤 공급업체 기여분이 참여할 수 있는가? 기존 테스트를 실행 가능하게 만들기 전에 어떤 작업이 남아 있는가?

그 비교에서는 보안 경계도 주목할 만합니다. 공급업체는 자신의 작업에 대한 접근을 통제하면서 협력해야 합니다. 구매자는 제안된 구성이 필요한 협업을 지원하고 참여자 간 합의된 경계를 보존하는지 평가해야 합니다.

이 질문들은 핵심 긴장을 계속 보여 줍니다. 즉, 더 이른 공동 테스트와 물리적 장비를 기다리는 통합 사이의 긴장입니다. 클라우드 공급업체 경쟁은 보조 맥락입니다. 엔지니어링 결정은 특정 구성이 실제 프로그램에서 այդ 의존성을 바꾸는지에 달려 있습니다.

따라서 구매자는 클라우드 브랜드를 통합 계획의 대체물로 간주하지 않아야 합니다. 이용 가능한 컴퓨팅 리소스는 구성의 일부일 뿐입니다. 구성 요소, 권한, 테스트 소유권, 재현 가능한 구성이 팀이 그 리소스를 효과적으로 사용할 수 있는지를 결정합니다.

이식성도 당연한 이점으로 가정하기보다 합리적으로 평가해야 할 또 다른 질문입니다. 팀은 어떤 설명, 테스트, 모델을 다른 환경에서 재사용할 수 있는지 식별해야 합니다. 또한 대체가 필요한 의존성도 파악해야 합니다.

이는 엔지니어링 투자가 초기 시연을 넘어 이어지기 때문에 중요합니다. 유용한 시나리오를 개발한 팀은 구성 요소가 바뀌어도 이를 유지하고자 할 것입니다. 대규모 테스트 집합이 이에 의존하기 전에, 평가는 그 유지보수 경로를 검토해야 합니다.

Google Cloud vehicle simulation에서 경쟁 기회는 기존 개발 워크플로를 시스템 경계 전반으로 더 쉽게 확장하는 데 있습니다. 구매자에게는 그러한 적합성에 대한 근거가 필요합니다. 가상 콕핏 시연만을 기반으로 한 비교로는 핵심 통합 질문에 답할 수 없습니다.

따라서 AWS의 선례는 이 범주에 대한 근거를 강화하는 한편 차별화 기준도 높입니다. Google의 접근 방식은 특정 조합이 엔지니어가 이미 수행하는 작업을 어디에서 개선하는지 보여줘야 합니다.

적용 범위, 측정된 결과, 재현 가능한 사례를 지켜보세요

다음 근거는 무엇이 실행되고, 무엇이 개선되며, 다른 팀이 무엇을 재현할 수 있는지를 보여줘야 합니다.

앞으로 몇 달 동안 주목할 첫 번째 신호는 더 명시적인 구성 요소 적용 범위입니다. 유용한 공개 정보라면 프로덕션 소프트웨어와 동작 모델, 그리고 테스트 제어 대체물을 구분해야 합니다. 또한 관련 운영 환경과 대상 가정도 식별해야 합니다.

그 세부 정보는 범위를 평가할 수 있게 만들어 Google Cloud 가상 차량의 근거를 강화할 것입니다. 이에 상응하는 구현 세부 정보가 없는 광범위한 아키텍처 다이어그램은 핵심 불확실성을 해소하지 못합니다. 독자는 완성도에 관한 더 큰 주장보다 참여 구성 요소에 관한 근거를 찾아야 합니다.

적용 범위는 실제 엔지니어링 작업과도 연결되어야 합니다. 새롭게 지원되는 컨트롤러는 관련 상호작용을 가능하게 하거나 의존성을 제거할 때 중요합니다. 지원 발표는 엔지니어가 이제 검토할 수 있는 시나리오를 포함할 때 더 유익해집니다.

다음 신호는 경계가 명확히 정의된 측정 고객 결과입니다. 유용한 사례 연구는 기존 워크플로, 바뀐 활동, 이후에도 필요한 작업을 식별해야 합니다. 또한 장비 대기, 테스트 실행, 결함 조사를 구분해야 합니다.

그러한 보고는 구매자가 보고된 가속 효과가 자신의 상황에 적용되는지 판단하는 데 도움이 됩니다. 좁게 선정된 통합 활동에서 나온 결과는 그 활동과 계속 연결되어 있어야 합니다. 측정 범위 없이 속도 향상만 반복하는 것은 근거를 거의 추가하지 못합니다.

독자는 초기 이야기를 복잡하게 만드는 결과도 살펴봐야 합니다. 어떤 환경은 접근 지연을 줄이는 대신 구성 유지보수를 늘릴 수 있습니다. 더 많은 결함을 더 일찍 발견하면서도 프로그램 기간을 즉시 단축하지 못할 수 있습니다. 이런 결과도 접근 방식이 어디에서 효과를 내는지 설명하는 데 도움이 됩니다.

마지막 신호는 공개 사례에서 유지되는 평가로 이어지는 더 명확한 경로입니다. RemotiveLabs의 virtual vehicle examples는 Android 관련 사례를 포함해 구체적인 출발점을 제공합니다. 이 리포지토리는 MIT 라이선스 예제 코드와 기반이 되는 RemotiveLabs 소프트웨어를 구분합니다.

이 구분은 평가를 계획하는 모든 사람에게 중요합니다. 공개적으로 재사용 가능한 예제가 필요한 모든 의존성에 동일한 라이선스가 적용된다는 것을 입증하지는 않습니다. 구매자는 제한 없는 재사용을 가정하기 전에 전체 런타임 구성과 접근 요구 사항을 검토해야 합니다.

재현 가능성은 발표의 실질적 가치를 강화할 것입니다. 엔지니어는 예제 버전을 식별하고, 그 가정을 이해하며, 어떤 프로덕션 질문을 다루는지 파악할 수 있어야 합니다. 다른 팀이 그 한계를 설명할 수 있을 때 성공적인 시연은 더 설득력을 얻습니다.

엔지니어링 리더에게 즉각적인 조치는 기존 프로그램에서 해결되지 않은 통합 질문 하나를 선택하는 것입니다. 필요한 장비가 도착하기 전에 제안된 가상 환경이 그 질문에 답할 수 있는지 물어보세요. 어떤 구성 요소에 프로덕션 소프트웨어가 포함되는지, 어떤 구성 요소가 대체물을 사용하는지, 어떤 결론에 여전히 물리적 확인이 필요한지 기록하세요.

해석 가능한 결과를 낼 수 있을 만큼 평가 범위를 좁게 유지하세요. 설정 및 유지보수 노력을 포함해 현재 프로세스와 조사를 비교하세요. 소프트웨어 수정 버전, 구성, 예상 동작, 관찰 결과를 함께 보존하세요. 이 기록을 활용해 환경을 확장하는 것이 또 다른 의존성을 제거할지 판단하세요. Google Cloud 가상 차량은 이 근거가 더 이른 엔지니어링 결정을 뒷받침하는 곳에서 가장 유용할 것입니다. 현재 팀이 테스트할 수 없는 상호작용부터 시작한 뒤, 신뢰할 수 있는 가상 결과가 무엇을 입증할지 물어보세요.