Google Cloud, AI 기반 단계적 경로로 메인프레임 빅뱅 마이그레이션 거부

Google Cloud는 AI 분석, 코드 생성, 데이터 변환, 전환 전 병렬 검증을 활용하는 위험한 메인프레임 마이그레이션의 4단계 대안을 제시했다.

이 제안은 익숙한 선택지에 도전한다. 기업은 노후 시스템을 계속 유지하거나, 작업이 시작된 후에야 종속성이 드러나는 대규모 마이그레이션을 시도할 수 있다. Google은 어느 쪽도 가장 어려운 문제, 즉 기존 시스템이 실제로 무엇을 하는지 이해하는 문제를 해결하지 못한다고 주장한다.

Google의 해법은 Mainframe Assessment Tool, Gemini CLI, Mainframe Connector, Dual Run을 하나의 연속적인 프로세스로 연결한다. 팀은 먼저 비즈니스 규칙과 종속성을 복원한다. 이어 검토된 요구사항을 토대로 클라우드 애플리케이션을 구축하고, 관련 데이터를 옮긴 뒤 실제 워크로드에서 두 환경을 비교한다.

이 순서는 이를 단순한 코드 변환 발표 이상으로 만든다. 핵심 경쟁 구도는 클라우드 인프라와 메인프레임 하드웨어의 대결이 아니라, 반복적 현대화와 빅뱅 마이그레이션의 대결이다.

Google은 이미 자리 잡은 대안들과도 경쟁하고 있다. IBM은 IBM Z의 중심적 역할을 유지하면서 AI를 적용하고 있다. AWS는 생성된 요구사항과 코드를 메인프레임 소스까지 추적하는 에이전틱 서비스를 홍보하고 있다. 각 공급업체는 코드 생성만으로 대체 시스템이 올바른지 판단할 수 없다는 점을 인식하고 있다.

따라서 핵심 질문은 Gemini가 COBOL을 번역할 수 있는지 여부가 아니다. Google의 연결된 워크플로가 수십 년간 축적된 숨은 비즈니스 동작을 보존하면서 기업이 관리 가능한 단위로 현대화하도록 지원할 수 있는지가 관건이다.

Google Cloud, 네 가지 도구를 하나의 마이그레이션 경로로 통합

중요한 변화는 평가, 생성, 데이터 이동, 프로덕션 검증 간의 연결이다.

Google의 현대화 프레임워크는 리버스 엔지니어링에서 시작한다. Mainframe Assessment Tool은 소스 코드, 데이터베이스 구조, 트랜잭션 모니터, 스케줄러 구성, 자산 간 관계를 조사한다.

이 도구는 COBOL 프로그램, copybook, JCL 작업, 프로시저, include 및 관련 아티팩트를 지원한다. Gemini를 사용해 해당 자료에서 요약, 기술 명세, 제안된 비즈니스 규칙을 생성한다.

비즈니스 규칙은 자격 조건, 이자 계산, 트랜잭션 라우팅 결정처럼 애플리케이션 내부에 인코딩된 정책을 뜻한다. 오래된 프로그램의 관찰 가능한 동작은 남아 있는 문서를 넘어서는 경우가 많기 때문에 중요하다.

Google에 따르면 팀은 추출된 규칙을 내보내기 전에 검토, 필터링, 검증할 수 있다. 이 사람의 점검 단계는 이 제안을 모든 줄을 Java나 다른 현대적 언어로 번역하라는 단순한 지시와 구분한다.

평가는 자산을 비즈니스 도메인과 더 작은 마이그레이션 가능 단위로 나눌 수도 있다. 마이그레이션 가능 단위란 인접 서비스에 문제를 일으키지 않고 함께 이전할 수 있는 프로그램, 데이터, 종속성의 경계가 명확한 집합이다.

이 분할은 반복적 프로그램의 기반을 만든다. 은행은 결제 승인을 건드리기 전에 하나의 보고 흐름을 분리할 수 있다. 보험사는 보험금 정산은 메인프레임에 남겨두고 문서 처리 서비스를 이전할 수 있다.

평가 후 Gemini CLI는 포워드 엔지니어링을 지원한다. 즉, 팀은 오래된 코드베이스를 목표 설계로 간주하는 대신 검증된 요구사항을 사용해 목표 아키텍처를 계획하고 새 코드를 생성한다.

이 워크플로는 Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB, Cloud SQL 전반의 데이터 모델과 서비스를 제안할 수 있다. 생성된 권고안은 운영상의 결정이 아니므로 여전히 아키텍처 검토가 필요하다.

Mainframe Connector는 자주 과소평가되는 또 다른 문제를 처리한다. EBCDIC로 인코딩된 레코드를 포함한 메인프레임 데이터를 복사하고 변환해 Google 서비스가 사용할 수 있는 형식으로 만든다.

EBCDIC는 IBM 메인프레임 환경과 연관된 문자 인코딩이다. 레코드에는 packed decimal, copybook 레이아웃, 애플리케이션별 관례가 포함될 수 있으므로 이를 올바르게 변환하려면 텍스트 표현만 바꾸는 것 이상이 필요하다.

Dual Run은 제안된 루프를 완성한다. 기존 메인프레임 환경과 클라우드 환경에서 워크로드를 실행한 뒤, 프로덕션 전환 전에 그 결과를 비교한다.

연결된 프로세스는 팀이 신뢰를 두는 위치를 바꾼다. 일회성 변환을 신뢰하는 대신 발견, 규칙 검토, 구현, 데이터 테스트, 병렬 실행 전반에서 증거를 축적한다.

이것이 이번 발표의 핵심 주장이다. Google은 현대화를 단일 변환 프로젝트가 아니라 통제된 증거 체계로 제시하고 있다.

메인프레임 현대화가 코드 번역 작업이 아닌 이유

문법적으로 올바른 변환도 잘못된 비즈니스 시스템을 재현할 수 있다.

대규모 메인프레임 자산은 깔끔하게 분리된 독립 애플리케이션 모음처럼 동작하는 경우가 드물다. 야간 배치 작업은 다음 날 아침 온라인 트랜잭션이 소비하는 데이터를 업데이트할 수 있다. 공유 copybook은 여러 비즈니스 부문에서 사용되는 레코드의 형태를 결정할 수 있다.

일부 종속성은 코드에 존재한다. 다른 것들은 스케줄러, 데이터베이스 관례, 운영 런북, 또는 수십 년간 워크로드를 유지해 온 직원들의 지식에 자리하고 있다.

이 때문에 직접적인 코드 번역은 불완전한 모델이다. 언어 모델은 COBOL 루틴에서 그럴듯한 Java를 생성할 수 있지만, 그 루틴이 왜 다른 작업 이후에 실행되는지는 놓칠 수 있다. 또한 비즈니스가 더 이상 원하지 않는 로직을 그대로 보존할 수도 있다.

반대 방향의 위험도 마찬가지로 심각하다. 생성된 대체 시스템은 중복적으로 보이지만 드문 규제 예외를 처리하는 동작을 단순화할 수 있다. 이런 실패는 드문 트랜잭션이나 분기 말 처리에서만 나타날 수 있다.

Google의 평가 우선 설계는 이러한 관계를 점검 가능하게 만들려 한다. 문서에 따르면 이 도구는 호출 트리, 종속성 보고서, 비즈니스 규칙 요약, 제안된 마이그레이션 가능 단위를 생성한다.

평가 시스템은 MCP 서버도 지원한다. 이를 통해 AI 에이전트는 Model Context Protocol을 이용해 평가 데이터를 질의할 수 있다. MCP는 모델을 외부 도구 및 구조화된 컨텍스트와 연결하는 표준 인터페이스다.

이 아키텍처는 Gemini에 소스 파일 폴더 이상의 것을 제공한다. Gemini는 발견된 관계, 검토된 명세, 특정 애플리케이션 도메인에 연결된 비즈니스 규칙을 활용할 수 있다.

하지만 더 풍부한 컨텍스트가 정확한 해석을 보장하지는 않는다. 생성된 명세는 엣지 케이스를 빠뜨릴 수 있고, 정적 분석은 런타임 구성이나 외부 운영을 통해 만들어지는 모든 종속성을 관찰할 수 없다.

따라서 인간의 검토는 여전히 메커니즘의 일부다. 도메인 전문가는 제안된 비즈니스 규칙이 유효한지, 폐기되었는지, 불완전한지, 또는 잘못 이해된 것인지 판단해야 한다.

이는 인력 이탈에 직면한 기업에 실질적인 제약을 만든다. 이 워크플로에는 대체하기 가장 어려운 시점에 경험 많은 운영자가 가장 필요하다. AI는 이들의 검토를 체계화할 수 있지만, 누락된 조직의 기억을 사후에 제공할 수는 없다.

Google의 접근 방식은 레거시 코드의 목적도 바꾼다. 팀은 각 구문을 보존해야 할 대상으로 다루는 대신, 자산을 의도된 비즈니스 동작에 관한 증거로 다룰 수 있다.

이 구분은 클라우드 네이티브 재설계를 뒷받침한다. 관리형 서비스가 동일한 검토된 요구사항을 충족할 수 있다면 트랜잭션 모니터에 문자 그대로의 대응물이 필요하지 않다. 타이밍과 일관성 제약이 허용된다면 배치 프로세스는 이벤트 기반 서비스가 될 수 있다.

그러나 재설계는 검증 부담을 확대한다. 목표 아키텍처가 원래 구현에서 멀어질수록 줄 단위 비교의 유용성은 떨어진다.

팀은 결과, 부작용, 타이밍, 데이터 무결성, 장애 복구를 비교해야 한다. 이것이 Dual Run이 Google의 설명에서 선택 사항이 아니라 핵심인 이유다.

약속하는 것은 완벽한 번역이 아니다. 레거시 증거에서 검토된 규칙, 생성된 구현, 측정된 동등성으로 이어지는 추적 가능한 사슬이다.

진짜 경쟁은 반복적 현대화와 빅뱅의 대결

Google의 가장 강력한 주장은 조직적이다. 더 작은 마이그레이션 단위는 불확실성의 영향을 제한한다.

빅뱅 마이그레이션은 하나의 전환에 수많은 가정을 집중시킨다. 팀은 광범위한 범위에서 종속성을 이해하고, 코드를 변환하며, 데이터를 옮기고, 인터페이스를 테스트하고, 운영자를 교육하고, 롤백 절차를 준비해야 한다.

잘못 파악된 종속성 하나가 전체 프로그램을 지연시킬 수 있다. 더 나쁜 경우, 원래 환경을 복구하기 어려워진 뒤에야 결함이 프로덕션에 도달할 수 있다.

반복적 현대화는 이러한 영향 범위를 줄인다. 팀은 경계가 명확한 도메인을 선택하고, 그 관계를 문서화하며, 목표 구현을 구축하고, 인접 워크로드를 변경하지 않은 채 이를 검증할 수 있다.

이것이 현대화를 단순하게 만드는 것은 아니다. 실패가 나타나는 방식을 바꾸는 것이다.

하나의 마이그레이션 단위에서 발견된 문제는 다음 단위의 평가 규칙을 개선할 수 있다. 테스트 불일치는 기업이 더 광범위한 전환을 결정하기 전에 문서화되지 않은 동작을 드러낼 수 있다.

Dual Run은 운영상의 연결 고리를 제공한다. Google의 이전 병렬 테스트 모델은 메인프레임을 기본 시스템으로 유지하는 한편, 클라우드 사본이 동일한 워크로드를 보조 시스템으로 실행하도록 한다.

그런 다음 클라우드 출력은 기존 결과와 비교할 수 있다. 반복되는 차이는 변환된 로직, 데이터 변환, 또는 환경 가정의 결함을 드러낸다.

이는 특히 트랜잭션이 많은 시스템과 관련이 있다. 단위 테스트는 알려진 계산을 검증할 수 있지만, 실제 입력 패턴, 스케줄링 조건, 다운스트림 통합 간의 모든 상호작용을 재현할 수는 없다.

병렬 실행은 새 시스템에 즉시 프로덕션 권한을 부여하지 않고도 더 폭넓은 증거를 제공한다. 팀은 허용 기준을 설정하고, 차이를 조사하며, 책임을 전환하기 전에 테스트를 반복할 수 있다.

그 대가로 공존 기간이 길어진다. 두 환경을 운영하려면 동기화, 모니터링, 중복 처리 제어, 각 출력을 어느 시스템이 소유하는지에 대한 명확한 결정이 필요하다.

전환 기간에는 비용도 중복될 수 있다. Google은 이러한 운영 부담을 없애지는 않는다. 대신 그 부담이 전부 아니면 전무인 이벤트보다 안전한 경로를 제공한다고 주장한다.

점진적 모델은 거버넌스 문제도 제기한다. 팀은 마이그레이션 단위를 선택하는 규칙과 애플리케이션이 충분한 동등성을 입증한 시점을 판단하는 기준이 필요하다.

어떤 비즈니스 규칙이 수용되었는지, 누가 이를 승인했는지, 어떤 테스트 증거가 이를 뒷받침하는지, 검증 후 무엇이 바뀌었는지를 추적해야 한다. 이러한 기록이 없으면 반복적 작업은 파편화된 하이브리드 자산을 만들 수 있다.

여기서 아키텍처 규율이 중요하다. 고립된 클라우드 프로젝트의 연속은 새로운 서비스, 큐, 데이터베이스, 문서화되지 않은 인터페이스를 통해 메인프레임의 복잡성을 재현할 수 있다.

Google의 도구는 아티팩트를 매핑하고 생성할 수 있지만, 기업에는 여전히 일관된 목표 아키텍처가 필요하다. 또한 클라우드로 대체되는 모든 메인프레임 구성 요소에 대한 폐기 계획도 필요하다.

이 접근 방식은 반복이 누적적인 단순화를 낳을 때 성공한다. 이전되는 모든 단위가 레거시 자산으로 이어지는 또 하나의 영구적 연결 고리를 추가할 때는 실패한다.

이것이 경쟁 구도가 속도와 신중함의 대결이 아닌 이유다. 성급한 빅뱅은 극적으로 실패할 수 있고, 끝없는 점진적 프로그램은 조용히 실패할 수 있다.

의미 있는 척도는 완성된 비즈니스 역량이다. 각 마이그레이션 단위는 검증된 프로덕션 운영에 도달하고, 그에 상응하는 레거시 책임을 제거해야 한다.

Google Cloud, IBM 및 AWS와는 다른 조건에서 경쟁하다

세 공급업체 모두 이제 AI를 활용하지만, 현대화된 워크로드를 어디에 배치할지와 동등성을 어떻게 확립할지에서는 차이가 있다.

IBM의 입장은 메인프레임의 지속적인 가치에서 출발한다. IBM의 watsonx Code Assistant for Z는 IBM Z를 중요한 런타임으로 유지하면서 탐색, 설명, 리팩터링, 코드 생성, 최적화 및 변환을 지원한다.

IBM은 자사의 어시스턴트가 COBOL, PL/I, REXX, Assembler 및 JCL을 설명할 수 있다고 말한다. 또한 선택한 프로그램을 모듈형 서비스로 리팩터링하거나 COBOL을 객체 지향 Java로 변환할 수도 있다.

이 회사의 AI 현대화 도구에는 의미론적 동등성을 위한 자동화된 단위 테스트가 포함된다. 이 용어는 구조가 바뀌더라도 새 코드가 원본과 동일한 의도된 동작을 만들어야 한다는 뜻이다.

이 경로는 모든 워크로드를 하이퍼스케일 클라우드로 이전하지 않으면서 더 나은 개발 관행을 원하는 기업에 적합할 수 있다. 또한 팀이 메인프레임을 기한이 정해진 대상으로 취급하지 않고, 이를 중심으로 현대화할 수 있게 한다.

AWS는 클라우드 목적지 측면에서 Google과 더 가까운 입장이지만, 현재 메시지는 에이전트 기반 실행과 추적 가능성을 강조한다. AWS Transform for mainframe은 평가, 비즈니스 규칙 추출, 요구사항, 코드 생성, 테스트 및 배포를 포괄한다.

AWS는 생성된 각 산출물이 요구사항을 거쳐 원본 소스까지 추적될 수 있다고 말한다. 또한 에이전트 기반 워크플로는 Kiro 같은 코딩 에이전트 및 오픈 프로토콜을 통한 기존 개발 환경과 통합된다.

이러한 추적 가능성은 Google의 Dual Run과 동일한 신뢰 격차를 겨냥한다. 검토자에게 요구사항이나 생성된 구성 요소의 출처를 보여주는 감사 경로를 제공한다.

Google의 차별점은 맥락 기반 평가를 데이터 변환 및 워크로드 수준의 병렬 검증과 결합하는 데 있다. Gemini는 이해와 생성을 지원하고, Dual Run은 기준이 되는 운영 시스템에 대해 동작을 테스트한다.

이들은 명확하게 분리된 제품 범주가 아니다. IBM도 탐색과 테스트를 제공한다. AWS도 자동화된 기능 동등성 검증을 주장한다. 각 공급업체는 전체 수명 주기 전반으로 영역을 확장하고 있다.

따라서 경쟁 압력은 구현 증거로 이동할 것이다. 구매자는 각 워크플로가 자사 환경의 어떤 언어, 스케줄러, 데이터베이스, 트랜잭션 시스템 및 데이터 형식을 처리하는지 알아야 한다.

또한 제품 역량과 서비스 제공을 구분해야 한다. 메인프레임 프로그램에는 시스템 통합업체, 내부 전문가, 공급업체 전문 인력, 그리고 수년간의 애플리케이션 이력이 관여하는 경우가 많다.

어떤 모델도 이러한 제공 구조와 독립적으로 작동하지 않는다. AI는 수동 분석을 줄이고, 사양 초안을 작성하며, 코드를 생성할 수 있지만 통합 결정은 여전히 각 환경에 따라 달라진다.

공급업체 종속성도 또 다른 고려 사항이다. 생성된 아키텍처는 한 공급업체의 데이터베이스, 컴퓨팅 플랫폼, 모니터링 시스템 및 AI 서비스를 선호할 수 있다.

이러한 정렬은 배포를 단순화할 수 있다. 그러나 기업이 이후 클라우드 전략을 변경하거나 여러 환경에 워크로드를 유지할 때 전환 비용을 높일 수도 있다.

따라서 기업은 데모뿐 아니라 산출물을 평가해야 한다. 내보낼 수 있는 규칙, 읽기 쉬운 사양, 이식 가능한 테스트, 추적 가능한 승인은 초기 변환 이후에도 중요하다.

시장은 AI 지원 현대화로 수렴하고 있다. 해결되지 않은 경쟁 요소는 사람이 어디에서 작업을 검증하는지, 공급업체가 동등성을 어떻게 측정하는지, 그리고 어떤 플랫폼이 결과를 소유하는지에 관한 것이다.

Google Cloud의 AI 워크플로가 여전히 보장할 수 없는 것

이 워크플로는 특정 마이그레이션 위험을 줄이지만, 생성된 비즈니스 규칙이나 대상 코드가 정확하다는 것을 확립하지는 않는다.

첫 번째 불확실성은 탐색 단계에서 나타난다. 정적 분석은 소스 관계와 선언된 호출을 식별할 수 있지만, 동적 동작은 런타임 값, 운영자 선택 또는 외부 시스템에 따라 달라질 수 있다.

AI가 생성한 요약도 근거가 허용하는 수준보다 더 확신에 차 보일 수 있다. 드물게 실행되는 분기를 누락했더라도 설명이 읽기 쉽다는 이유로 검토자가 승인할 수 있다.

이는 사람들이 시스템의 권고를 과도하게 신뢰할 때 발생하는 자동화 편향을 만든다. 잘 다듬어진 사양은 기반 환경에 존재하는 모호성을 숨기기 때문에 이 위험을 키울 수 있다.

Google의 자체 워크플로는 추출된 규칙을 위한 검토 단계를 유지한다. 기업은 이 단계를 행정적 체크포인트가 아니라 통제 수단으로 다뤄야 한다.

검토에는 지정된 책임자, 연결된 근거 및 명시적인 처리 결과가 필요하다. 규칙은 생성된 코드를 안내하기 전에 승인됨, 거부됨, 수정됨 또는 미해결로 표시되어야 한다.

보안은 또 다른 계층을 더한다. Google은 Mainframe Assessment Tool이 수집된 평가 데이터를 배포된 가상 머신 내에 유지한다고 말한다. 문서에는 소스 코드가 Gemini Enterprise Agent Platform에 업로드된다고도 명시되어 있다.

같은 문서는 모델이 해당 코드에서 추출된 정보로 보강되지 않는다고 밝힌다. 조직은 여전히 자사 워크로드에 대한 리전 제어, 액세스 정책, 보존 동작 및 계약상 요구사항을 검증해야 한다.

테스트에도 한계가 있다. Dual Run은 관찰된 출력 간의 차이를 감지할 수 있지만, 동등성은 커버리지와 비교 품질에 달려 있다.

두 환경에 일반적인 트랜잭션만 입력된다면 드문 사례는 테스트되지 않은 채 남는다. 비교 로직이 타이밍, 순서 또는 다운스트림 부작용을 무시한다면, 두 출력은 동일해 보이면서 시스템은 다르게 동작할 수 있다.

병렬 테스트는 잘못된 레거시 동작도 재현할 수 있다. 마이그레이션 중 메인프레임과 일치하는 것은 유용하지만, 상속된 모든 규칙이 바람직하거나 현재 정책을 준수한다는 것을 증명하지는 않는다.

팀은 두 가지 질문을 분리해야 한다. 클라우드 구현은 원본처럼 동작하는가, 그리고 원본 동작은 유지되어야 하는가?

두 번째 질문에는 비즈니스, 법률, 보안 및 운영 측면의 판단이 필요하다. 코드 분석만으로는 답할 수 없다.

성능 주장에도 프로덕션과 유사한 증거가 필요하다. 생성된 서비스는 기능 테스트를 통과할 수 있지만, 피크 볼륨에서 용인할 수 없는 지연 시간, 인프라 소비 또는 데이터베이스 경합을 유발할 수 있다.

운영 복구도 같은 수준의 주의를 기울여야 한다. 팀은 권한을 이전하기 전에 재시도, 부분 실패, 지연된 메시지, 중복 트랜잭션 및 롤백 절차를 테스트해야 한다.

마지막으로, 이 워크플로는 프로그램 완료를 보장할 수 없다. 기업은 단 하나의 메인프레임 워크로드도 폐기하지 않은 채 훌륭한 평가와 프로토타입을 만들 수 있다.

성공을 위해서는 각 마이그레이션 단위의 종료 기준이 필요하다. 이러한 기준은 기능적 증거, 운영 준비 상태, 데이터 조정, 보안 승인, 비용 예상치 및 실제 레거시 폐기를 다뤄야 한다.

Google의 전략은 불확실성을 더 이른 단계에서 드러내기 때문에 더 안전하다. AI가 참여한다는 이유만으로 안전한 것은 아니다.

Google Cloud가 방법론에서 증거로 이동할 때 주목할 점

다음 시험대는 단계적 방법이 더 설득력 있는 생성 코드가 아니라 반복 가능한 프로덕션 전환을 만들어 내는지 여부다.

첫 번째 신호는 완료된 마이그레이션 단위와 연결된 고객 증거다. 구매자는 병렬 테스트를 통과하고 기준 시스템의 책임을 이전한, 이름이 명시된 프로덕션 워크로드를 찾아야 한다.

유용한 사례 연구는 범위, 지원된 산출물, 발견된 종속성, 검증 기간, 불일치 처리 방식 및 최종적으로 폐기된 메인프레임 구성 요소를 설명할 것이다. 더 빠른 분석에 관한 일반적인 언급은 제공하는 정보가 적다.

반복된 전환은 워크플로가 신중하게 선택된 애플리케이션을 넘어 확장된다는 Google의 주장을 강화할 것이다. 프로덕션 폐기가 없는 평가는 이를 약화할 것이다.

두 번째 신호는 도구 체인 전반의 더 깊은 추적 가능성이다. Google의 릴리스 이력은 비즈니스 규칙 추출, MCP 액세스, 언어 지원 범위 및 대규모 환경 분석에 대한 지속적인 작업을 보여준다.

중요한 발전은 승인된 각 규칙을 소스 근거, 생성된 구성 요소, 테스트, 비교 결과 및 사람의 승인과 연결하는 것이다. 이 연결 고리는 감사와 이후 유지보수 시 검토를 더 쉽게 만들 것이다.

또한 팀이 오류가 프로세스의 어느 지점에서 유입됐는지 식별하는 데 도움이 된다. 불일치는 잘못된 추출, 변경된 요구사항, 생성된 코드, 변환된 데이터 또는 검증 하니스까지 거슬러 올라갈 수 있다.

명확한 추적 가능성은 지식이 마이그레이션 단위 전반에 축적되도록 하므로 반복 모델을 강화할 것이다. 파편화된 산출물은 각 단위를 별도 프로젝트처럼 느끼게 할 것이다.

세 번째 신호는 IBM과 AWS가 비교 가능한 검증 증거로 어떻게 대응하는지다. 기능 목록은 이미 겹치므로, 공급업체는 자사 방법이 실제 종속성과 어려운 전환을 어떻게 처리하는지 보여줘야 한다.

IBM은 현대화가 IBM Z를 포기할 필요는 없다고 주장할 수 있다. AWS는 소스부터 산출물까지의 추적 가능성과 자동화된 테스트를 강조할 수 있다. Google은 맥락 기반 평가와 Dual Run의 결합이 더 나은 위험 경계를 제공한다는 점을 입증해야 한다.

이 경쟁은 기업 구매자에게 도움이 될 것이다. 논의를 원시적인 코드 생성 데모에서 증거, 거버넌스, 이식성 및 완료된 결과로 옮긴다.

기술 리더에게 즉각적인 조치는 전사 환경 전체의 마이그레이션을 승인하는 것이 아니다. 의미 있는 하나의 도메인을 선택해 전체 사슬을 테스트하는 것이다.

해당 도메인은 되돌릴 수 없는 첫 번째 움직임이 되지 않으면서도 실제 종속성과 비즈니스 영향을 포함해야 한다. 평가는 코드, 데이터, 일정, 인터페이스 및 운영 지식을 포함해야 한다.

팀은 추출된 규칙 중 수정이 필요한 비율, 병렬 결과가 불일치하는 빈도, 각 불일치를 해결하는 데 걸리는 시간을 기록해야 한다. 이러한 지표는 생성 코드의 양보다 더 많은 것을 보여준다.

성공적인 전환 이후 무엇이 종료되는지도 결정해야 한다. 원본 워크로드, 라이선스 부담, 운영 프로세스 및 지원 책임이 모두 남아 있다면 마이그레이션 단위는 불완전하다.

Google Cloud는 기업에 무기한 유지보수와 위험한 빅뱅 사이의 경로를 제시하고 있다. 이 경로가 신뢰할 만한 이유는 현대화를 탐색, 재구성 및 증명으로 다루기 때문이다.

그 가치는 고객이 영구적인 하이브리드 미로를 만들지 않고 복잡한 환경 전반에서 이 주기를 반복할 수 있는지에 달려 있다. 다음 AI 생성 데모보다 다음 프로덕션 전환이 더 중요할 것이다.