레거시 메인프레임 현대화
메인프레임 현대화 프로젝트의 70~80%가 실패합니다. 기술이 잘못되어서가 아니라, 도구가 코드를 토폴로지가 아닌 텍스트로 취급하기 때문입니다. 우리는 단 한 줄도 손대기 전에 여러분의 코드베이스 지도를 먼저 구축하여, 다른 이들이 수백만 달러를 쏟아붓고도 아무것도 내놓지 못한 곳에서 여러분의 마이그레이션이 성공하도록 합니다.
1조 5,200억 달러
미국 기술 부채
Pragmatic Coders, 2025
연 10%
COBOL 인력 감소율
IEEE Spectrum, 2025
70~80%
현대화 실패율
업계 메타 분석, 2025
"COBOL을 붙여넣으면 Java가 나온다"고 약속하는 도구는 컴파일되는 코드를 만들어냅니다. 그것은 쉬운 부분입니다. 어려운 부분은 그 도구가 볼 수 없는 코드입니다.
전신 송금 처리 프로그램을 생각해 봅시다. 이 프로그램에는 다음 변수를 사용하는 COMPUTE 문이 들어 있습니다: TRN-LIMIT. AI 코딩 어시스턴트는 이 문장을 Java BigDecimal 연산으로 번역합니다. 코드는 컴파일됩니다. 단위 테스트도 통과합니다.
UAT 단계에서, 첫 번째 트랜잭션이 데이터베이스 일관성 검사를 무너뜨립니다.
원인 분석: TRN-LIMIT 는 AI가 번역한 소스 파일에 정의되어 있지 않았습니다. 그것은 실행 체인에서 수천 줄 앞쪽에 포함된 카피북(copybook)에 정의되어 있었습니다. 그 카피북에는 REDEFINES 절이 들어 있었는데, 이는 동일한 메모리 주소를 완전히 다른 모듈에서 설정된 플래그에 따라 두 가지 서로 다른 데이터 타입으로 해석할 수 있게 하는 COBOL 구문입니다.
AI는 TRN-LIMIT 를 단순한 숫자 필드로 보고 표준 정수 타입으로 가정했습니다. 메인프레임에서 그 메모리 주소는 패킹 십진수(COMP-3)를 담고 있었습니다. Java 애플리케이션은 손상된 바이너리 데이터를 데이터베이스 컬럼에 기록했고, 이는 참조 무결성 오류를 유발했습니다.
코드는 구문적으로 완벽했습니다. 실패의 원인은 맥락에 대한 맹목성이었습니다. AI는 자신의 시야 밖에 존재하는 의존성을 놓쳤습니다.
하나의 COBOL 프로그램이 40개 이상의 카피북을 참조할 수 있습니다. 각 카피북은 또 다른 카피북을 COPY할 수 있습니다. 변수 정의가 포함 체인에서 5단계 깊이까지 들어가 있을 수 있습니다. 텍스트 기반 AI 도구는 이 중 어느 것도 보지 못합니다.
여러분의 COBOL은 독립적으로 실행되지 않습니다. CA-7 또는 TWS가 의존성 체인을 가진 2,000~5,000개의 JCL 작업을 스케줄링합니다. 작업 A가 새벽 2시에 데이터셋을 기록하면 작업 B가 그것을 읽습니다. COBOL은 마이그레이션하면서 JCL을 놓치면, 자정에 운영 환경이 무너집니다.
COBOL의 COMP-3 패킹 십진수는 Java에 동등한 타입이 없습니다. Java의 double 은 부동소수점 반올림 오차를 일으킵니다. BigDecimal 조차 COBOL의 ROUNDED 절에 맞추려면 명시적인 반올림 모드 설정(HALF_EVEN)이 필요합니다. 단 1센트의 오차가 수백만 건의 트랜잭션에 걸쳐 누적됩니다.
이제 모든 주요 기술 벤더가 메인프레임 현대화를 판매하고 있습니다. 각 벤더가 실제로 무엇을 제공하며 어디에 공백이 남아 있는지 살펴봅니다.
| 벤더 / 접근 방식 | 무엇을 하는가 | 일반적 비용 | 무엇을 놓치는가 |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | ADDI 의존성 분석을 활용한 에이전트형 COBOL-Java 번역. 멀티 에이전트 아키텍처(Orchestrate, Architect, Code 에이전트). PL/I 및 IMS 지원. | 200만 달러 이상 (엔터프라이즈 라이선스 + z/OS 요구사항) | ADDI는 z/OS에서 실행되어 마이그레이션 중 벤더 종속을 만듭니다. 파서가 85년 이전 COBOL 구문(ALTER 문)에서 어려움을 겪습니다. 동작 동등성 테스트가 없습니다. JCL 의존성 매핑이 없습니다. |
| Anthropic Claude Code | AI 기반 코드 분석, 문서화, 의존성 매핑. 발견 및 탐색 단계에 강합니다. 점진적 마이그레이션 및 API 래핑을 지원합니다. | 사용량 기반 API 요금 | 범용 AI. 전이적 의존성 해소를 위한 내장 지식 그래프가 없습니다. JCL 스케줄링, 동작 동등성 테스트, 규제 감사 추적은 다루지 않습니다. |
| Microsoft Azure Migration Factory | Semantic Kernel을 통한 모듈형 에이전트. COBOL 전문가 + Java 전문가 에이전트. Java Quarkus를 타깃으로 합니다. Azure Copilot 마이그레이션 에이전트는 프리뷰 단계입니다. | Azure 사용량 + 컨설팅 | 타깃 플랫폼에 대한 Azure 종속. 오픈소스 에이전트는 참조 구현일 뿐, 규제 환경에 바로 투입할 수 있는 프로덕션 수준이 아닙니다. CICS/IMS 지원이 제한적입니다. |
| DXC Technology | 특허받은 자동 코드 변환(COBOL/RPG/JCL을 Java로). 수십 년의 메인프레임 전문성. 하이브리드 클라우드 + 서비스형 메인프레임 모델. | 100만~1,000만 달러 이상 | 독점 도구로, 변환 로직에 대한 투명성이 제한적입니다. 대기업 중심입니다. 18~36개월에 이르는 프로젝트 기간이 일반적입니다. |
| TCS / Infosys / Accenture | 독점 프레임워크(MasterCraft, Cobalt)를 갖춘 대형 시스템 통합 사업. 대규모 딜리버리 팀. 엔드투엔드 프로그램 관리. | 50만~500만 달러 이상 | 플랫폼 중심 접근. 이들은 벤더 도구를 도입하는 것이지, 맞춤형 인텔리전스를 구축하지 않습니다. 대형 SI 계약 모델의 간접비. 한 SI는 10억 호주달러 규모의 은행 마이그레이션을 주도했는데 5년이 걸렸고 예산이 두 배로 불어났습니다. |
| Micro Focus (OpenText) Visual COBOL | COBOL을 .NET/JVM에서 네이티브로 실행. 실용적인 "스트랭글러 피그(strangler fig)" 출발점. COBOL 컴파일러 시장 선두주자. | 20만~50만 달러 라이선스 | 현대화가 아니라 리호스팅입니다. COBOL 로직은 여전히 COBOL로 남습니다. 기술 부채는 그대로입니다. 인력 문제를 해결하지 못합니다. |
| 오픈소스 AI를 활용한 자체 구축(DIY) | XMainframe LLM(70억/105억 파라미터, COBOL에서 DeepSeek보다 30% 우수). Tree-sitter 파싱. 맞춤형 파이프라인. | 엔지니어링 시간 + 인프라 | 깊은 COBOL + 그래프 엔지니어링 전문성이 필요합니다. 모든 IBM Enterprise COBOL v6.x 구문을 다루는 프로덕션급 COBOL 파서는 없습니다. 파서의 공백을 토대에 그대로 쌓아 올릴 위험이 큽니다. |
다섯 가지 역량으로, 각각 현대화 도구 체인의 특정 공백을 메웁니다. 우리는 벤더 중립적입니다. 지식 그래프는 여러분의 타깃이 AWS, Azure, GCP, 온프레미스 Java 중 무엇이든 상관없이 작동합니다.
우리는 여러분의 COBOL 소스, 카피북, JCL 라이브러리, DB2 카탈로그 익스포트, CICS 트랜잭션 정의, IMS 세그먼트 계층을 하나의 통합 그래프 데이터베이스로 수집합니다. 모든 변수, 모든 PERFORM 체인, 모든 REDEFINES 절, 모든 배치 의존성이 명시적인 그래프 엣지가 됩니다. 복잡한 전이적 폐쇄(transitive closure) 쿼리가 사용 사례를 지배할 때는 Neo4j를, 인터랙티브 탐색에서 실시간 순회 속도가 중요할 때는 Memgraph를 선택합니다.
그래프는 수집 과정에서 하루에 약 20만~30만 줄을 처리합니다. 200만 LOC 규모의 코드베이스라면 최초 수집부터 검증되고 쿼리 가능한 그래프까지 8~12주가 걸립니다. 그 산출물은 영구적인 자산입니다. 불투명한 텍스트 파일이 아니라, 검색 가능한 토폴로지로서의 여러분의 코드베이스입니다.
어떤 코드 번역도 시작하기 전에, 우리는 네 가지 차원에 걸쳐 그래프 분석을 수행합니다. 결합도 점수(이 모듈에 의존하는 다른 모듈의 수), REDEFINES/COMP-3 밀도(데이터 타입 함정이 얼마나 많은지), 데드 코드 비율(일반적으로 코드베이스의 20~30%), 그리고 배치 스케줄링 중요도(어떤 JCL 작업이 언제 이 모듈을 건드리는지)입니다.
그 산출물은 스트랭글러 피그 마이그레이션을 위한 순위가 매겨진 추출 순서입니다. 결합도가 가장 낮고 데이터 타입이 가장 단순한 모듈을 먼저 추출합니다. 50개 이상의 다른 모듈이 호출하는 "신(god) 프로그램"은 마지막에 추출합니다. 이 순서 결정이 통제된 롤아웃과 연쇄 장애 사이의 차이를 만듭니다.
우리의 번역 에이전트는 각 Java 모듈을 생성하기 전에 지식 그래프에 쿼리하여 의존성의 전체 전이적 폐쇄를 가져옵니다. 에이전트는 세 디렉터리 떨어진 카피북 안의 REDEFINES 절을 봅니다. 반올림 동작을 결정하는 패킹 십진수 정의도 봅니다. COBOL의 암묵적 전역 상태 대신 명시적 매개변수 전달(의존성 주입)을 사용하는 Java를 생성합니다. 그런 다음 샌드박스에서 컴파일하고, 동작 동등성 테스트를 실행하며, 스스로 수정합니다.
모듈의 복잡도에 맞는 기반 모델을 그때그때 사용합니다. 단순한 PERFORM-메서드 변환에는 더 작은 모델로 충분합니다. 중첩된 REDEFINES, 제어 흐름 평탄화가 필요한 GOTO 스파게티, 또는 EXEC CICS 내장 트랜잭션 로직이 있는 모듈에는 사용 가능한 가장 강력한 모델을 투입하고 전체 그래프 컨텍스트로 보강합니다.
대부분의 벤더가 건너뛰고 대부분의 마이그레이션이 실패하는 바로 그 부분입니다. 우리는 3계층 검증 시스템을 구축합니다. 그래프에서 도출한 제어 흐름 경로로부터 생성한 심볼릭 단위 테스트, 캡처한 운영 트랜잭션을 사용해 1센트까지 정확하게 필드 단위로 비교하는 골든 데이터셋 재생, 그리고 메인프레임 모듈을 폐기하기 전에 두 시스템이 30~90일간 실시간 트랜잭션을 처리하는 병렬 운영 실행입니다.
금융 계산에는 COBOL의 ROUNDED 절에 맞추기 위해 HALF_EVEN 반올림 모드를 사용하는 BigDecimal이 필요합니다. 날짜 계산에는 세기 윈도잉(century windowing) 로직을 적용하여 COBOL의 6자리 날짜 형식(YYMMDD)을 처리해야 합니다. 우리는 이러한 변환 규칙을 QA 중에 발견되는 임시 패치가 아니라, 테스트 하니스 안에 미리 구축해 둡니다.
우리는 여러분의 JCL 작업 네트워크, CA-7/TWS/Control-M 의존성 체인, 배치 처리 순서를 지식 그래프로 파싱합니다. 각 JCL 작업은 그것이 실행하는 COBOL 프로그램, 그것이 읽고 쓰는 데이터셋, 그것이 의존하는 스케줄링 조건(시간 트리거, 데이터셋 가용성, 선행 작업 완료)으로의 엣지를 가진 노드가 됩니다.
COBOL 모듈이 Java로 마이그레이션될 때, 우리는 동시에 여러분의 타깃 오케스트레이션 플랫폼(Apache Airflow, AWS Step Functions, Azure Data Factory, 또는 분산 환경의 Control-M)에 동등한 스케줄링을 구축합니다. 의존성 체인은 보존되고 원래의 CA-7/TWS 정의에 대조하여 검증됩니다. 일반적인 중견 은행은 2,000~5,000개의 JCL 작업을 가지고 있습니다. 우리는 그것들을 모두 다뤄봤습니다.
그래프 기반 의존성 해소가 가장 흔한 마이그레이션 실패 패턴을 어떻게 방지하는지 단계별로 살펴봅니다.
파서가 PROG-WIRE-01.cbl을 처리하며 COPY CB-ACCT-LIMITS를 만나고 포함 체인을 따라갑니다. 3단계 깊이로 중첩된 카피북 안의 변수를 포함하여 모든 변수 선언에 대한 AST 노드를 구축합니다.
그래프 엔진이 엣지를 생성합니다: PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT. 이는 TRN-LIMIT 의 데이터 타입이 다른 필드의 런타임 플래그에 의존한다는 사실을 포착합니다.
그래프는 바깥쪽으로 순회합니다: 어떤 다른 프로그램들도 CB-ACCT-LIMITS를 COPY하는가? 어떤 프로그램들이 LIMIT-TYPE-FLAG를 설정하는가? 어떤 JCL 작업들이 그 프로그램들을 실행하며, 어떤 순서로 실행하는가? 그 결과는 완전한 영향 체인입니다. TRN-LIMIT 가 어떻게 번역되는지를 바꾸면 이 체인의 모든 프로그램에 영향을 미칩니다.
번역 에이전트가 PROG-WIRE-01을 처리할 때, GraphRAG는 소스 파일만이 아니라 카피북 정의, REDEFINES 관계, 플래그 필드, 그리고 그 플래그를 설정하는 모든 프로그램을 검색해 옵니다. 에이전트는 타입 안전 유니온 패턴을 가진 Java 클래스를 생성합니다: TransactionLimit 객체로, 이는 기반 바이트를 BigDecimal (패킹 십진수 모드) 또는 String (알파 모드) 중 어느 것으로 해석할지 정하기 전에 플래그를 확인합니다.
그래프가 없으면: AI는 TRN-LIMIT 를 단순한 숫자 필드로 가정하고 Java에서 long 을 생성하며, 첫 번째 전신 송금이 데이터베이스를 손상시킵니다. 그래프가 있으면: AI는 전체 의존성 체인을 보고 두 가지 해석을 모두 올바르게 처리하는 타입 안전 코드를 생성합니다. 이것이 UAT에서만 작동하는 마이그레이션과 프로덕션에서 작동하는 마이그레이션의 차이입니다.
네 단계로, 각 단계마다 명확한 산출물이 있습니다. 우리는 3년짜리 일정을 제시하고 사라지지 않습니다. 각 단계는 여러분이 소유하고 독립적으로 활용할 수 있는 산출물을 만들어냅니다.
산출물: 진단 보고서 + 예비 지식 그래프 프로토타입
산출물: 쿼리 가능한 지식 그래프 + 순위가 매겨진 추출 순서 + 영향 분석 도구
산출물: 프로덕션에 투입된 마이그레이션 Java 모듈 + 갱신된 지식 그래프 + 스케줄링 동등물
산출물: 검증된 프로덕션 배포 + 규제 문서화 패키지 + 갱신된 그래프
여러분의 환경에 관한 일곱 가지 질문에 답하십시오. 이 진단은 Veriprajna와 함께하든 그렇지 않든, 마이그레이션 프로젝트를 시작하기 전에 해결해야 할 여러분의 준비도 수준과 구체적인 장애물을 식별합니다.
일반적인 복잡도(IBM Enterprise COBOL v6.x, DB2 임베디드 SQL, 500개 이상의 카피북)를 가진 200만 LOC 코드베이스의 경우, 그래프 구축에는 8~12주가 걸립니다. 처음 3주는 파서 구성 및 검증입니다. COBOL 방언은 충분히 다양하기 때문에, 전체 코드베이스를 수집하기 전에 파서가 여러분의 REDEFINES, OCCURS DEPENDING ON, EXEC CICS/SQL 블록의 특정 사용 방식을 처리하는지 검증해야 합니다.
4주 차부터 8주 차까지는 자동 수집, 엔티티 추출, 관계 매핑입니다. 파서는 하루에 약 20만~30만 줄을 처리하지만, 병목은 엔티티 해소입니다. 구체적으로는 프로그램 A의 ACCT-NUM 과 카피북 CB-ACCT-01 의 ACCT-NUM 이 같은 변수인지 판별하는 작업입니다.
9주 차부터 12주 차까지는 전이적 폐쇄 계산 및 검증입니다. 우리는 그래프 완전성 검사를 수행합니다: 모든 PERFORM 타깃은 단락(paragraph)으로 해소되어야 하고, 모든 COPY 문은 카피북으로 해소되어야 하며, 모든 DB2 테이블 참조는 스키마 정의에 매핑되어야 합니다. 공백은 수동 검토를 위해 플래그가 지정됩니다. 그 산출물은 "CB-GLOBAL-01의 INTEREST-RATE를 바꾸면 어떻게 되는가?" 같은 질문을 던지고, 그것을 직접 또는 전이적으로 참조하는 모든 프로그램에 걸친 완전한 영향 체인을 얻을 수 있는 쿼리 가능한 지식 그래프입니다.
예, 그리고 강력히 권장합니다. 스트랭글러 피그 패턴은 메인프레임 마이그레이션에서 입증된 실적을 가진 유일한 접근 방식입니다. 전면 재작성은 모든 것을 동시에 교체하려고 시도하여 단일의 거대한 장애 지점을 만들기 때문에 70~80%의 확률로 실패합니다.
스트랭글러 피그 접근 방식에서는 지식 그래프가 어떤 모듈이 가장 낮은 결합도 점수를 갖는지, 즉 다른 모듈로부터의 인바운드 의존성이 가장 적은지를 식별합니다. 이것들이 여러분의 추출 후보입니다. 우리는 일반적으로 DB2에서 읽기만 하고 공유 상태를 갱신하지 않는 배치 리포팅 모듈이나 독립형 계산 루틴으로 시작합니다. 새로운 Java 서비스가 메인프레임과 나란히 실행됩니다. 메인프레임이 다른 모든 것을 계속 처리하는 동안, 그 특정 기능에 대한 프로덕션 트래픽은 새 서비스로 라우팅됩니다. 여러분은 COBOL 모듈을 폐기하기 전에 실제 프로덕션 데이터에서 동작 동등성을 검증합니다.
대부분의 조직은 첫해에 15~20개의 모듈을 추출하여 MIPS 소비량을 20~30% 줄이고, 다음 단계를 위한 자금을 댈 만큼의 비용 절감을 만들어냅니다. 지식 그래프는 각 추출의 영향 반경(blast radius)을 보여주기 때문에 이를 안전하게 만듭니다. 모듈 A가 47개의 다른 프로그램에 의해 호출된다면, 그것은 여러분의 첫 추출 후보가 아닙니다. 모듈 B가 2개의 프로그램에 의해 호출되고 1개의 DB2 테이블에서 읽는다면, 거기서 시작하십시오.
이것은 대부분의 현대화 프로젝트가 6~12개월 차에 예상치 못한 장애를 만나는 계층입니다. 여러분의 COBOL 프로그램은 고립되어 실행되지 않습니다. 이들은 CA-7, TWS(Tivoli Workload Scheduler), 또는 Control-M이 관리하는 JCL 작업 스트림에 의해 오케스트레이션됩니다. 일반적인 중견 은행은 복잡한 의존성 체인을 가진 2,000~5,000개의 JCL 작업을 보유합니다: 작업 A는 작업 B가 시작되기 전에 완료되어야 하고, 작업 C는 매월 마지막 영업일에만 실행되며, 작업 D는 작업 E가 읽는 VSAM 파일을 갱신하는 CICS 트랜잭션을 트리거합니다.
우리는 JCL을 COBOL과 함께 동일한 지식 그래프로 파싱합니다. 각 JCL 작업은 그것이 실행하는 COBOL 프로그램, 그것이 읽고 쓰는 데이터셋, 그것이 의존하는 스케줄링 조건으로의 엣지를 가진 노드가 됩니다. COBOL 모듈을 Java로 마이그레이션할 때, 우리는 동시에 여러분의 타깃 플랫폼이 Apache Airflow든, AWS Step Functions든, Azure Data Factory든 거기에 동등한 스케줄링을 구축합니다. 의존성 체인은 보존되고 원본에 대조하여 검증됩니다.
우리는 코드 마이그레이션은 완벽하게 성공했지만, 매일 밤 새벽 2시에 전처리 단계를 실행하던 CA-7 작업을 아무도 매핑하지 않아 프로덕션이 무너진 프로젝트들을 봤습니다.
IBM Watsonx Code Assistant for Z(현재 v2.8.20, Project Bob은 2026년 하반기 예정)는 깊은 메인프레임 통합을 갖춘 강력한 제품입니다. 의존성 분석을 구축하려면 IBM ADDI(Application Discovery and Delivery Intelligence)가 필요하며, ADDI는 z/OS에서 실행됩니다. 이는 여러분의 의존성 분석 도구가 여러분이 벗어나려고 하는 바로 그 메인프레임 위에 존재한다는 뜻입니다. 또한 이는 IBM이 분석 계층을 통제한다는 뜻이며, 이는 마이그레이션의 가장 중요한 단계에서 벤더 종속을 만듭니다.
우리의 지식 그래프는 메인프레임 밖에서 실행됩니다. 우리는 소스 코드 익스포트, JCL 라이브러리, DB2 카탈로그 익스포트, 카피북 저장소를 수집합니다. 그래프는 IBM 라이선스와 무관하게 여러분의 클라우드 환경 또는 온프레미스 인프라에 존재합니다. 둘째, Watsonx는 COBOL-Java 번역에 집중합니다. 우리는 먼저 이해, 그다음 번역에 집중합니다. 지식 그래프는 마이그레이션이 완료된 한참 후에도 영향 분석, 문서 생성, 아키텍처 거버넌스에 기여하는 영구적인 자산입니다.
셋째, ADDI의 COBOL 파서는 85년 이전 COBOL 구문, 특히 ALTER 문과 특정 중첩 REDEFINES 패턴에 대해 문서화된 한계를 가지고 있습니다. 우리는 각 고객의 방언에 맞춘 커스텀 파서 확장을 구축합니다.
끝으로, IBM의 가격 정책은 대기업을 겨냥합니다. 우리의 계약 모델은 200만 달러 이상의 IBM 계약이 예산에 들어맞지 않는 중견 기관에 적합합니다.
동작 동등성은 대부분의 AI 보조 마이그레이션이 무너지는 지점입니다. 컴파일되고 단위 테스트를 통과하는 코드라도 패킹 십진수 반올림 차이, EBCDIC-ASCII 인코딩 불일치, 또는 Java 객체로 번역되지 않는 REDEFINES 메모리 오버레이 의미론 때문에 여전히 잘못된 결과를 낼 수 있습니다.
우리는 3계층 검증 하니스를 구축합니다. 계층 1은 심볼릭 동등성입니다: 우리는 음수 금액, 0으로 나누기 방어, 윤년 날짜 계산 같은 엣지 케이스를 포함하여 원래 COBOL 제어 흐름의 모든 분기를 다루는 단위 테스트를 지식 그래프로부터 생성합니다. 계층 2는 골든 데이터셋 재생입니다: 우리는 메인프레임에서 대표적인 운영 트랜잭션 세트(입력 레코드, DB2 읽기, CICS 상호작용)를 캡처하여 새로운 Java 서비스를 통해 재생합니다. 출력은 필드 단위로 비교됩니다. 금융 계산의 경우, COBOL의 ROUNDED 절 동작에 맞추기 위해 HALF_EVEN 반올림을 사용하는 BigDecimal로 1센트까지 정확한 정밀도를 검증합니다.
계층 3은 병렬 프로덕션 실행입니다: 두 시스템이 동일한 실시간 트랜잭션을 30~90일간 동시에 처리합니다. 불일치는 로깅되고, 조사되며, 메인프레임 모듈이 폐기되기 전에 수정됩니다. 이것이 가장 긴 단계이지만, 30년간의 프로덕션에서 누적되어 어떤 테스트 스위트도 완전히 예측할 수 없는 엣지 케이스를 잡아내는 단계이기도 합니다.
DORA(디지털 운영 복원력 법, Digital Operational Resilience Act)는 2025년 1월 17일부터 완전히 시행되고 있으며, 메인프레임 시스템을 운영하는 모든 EU 규제 대상 금융 기관에 직접적인 영향을 미칩니다. 제11조는 실제 공격 시나리오에 기반한 정기적 복원력 테스트와 위협 주도형 침투 테스트를 포함하는 ICT 위험 관리 프레임워크를 요구합니다. 대부분의 메인프레임 환경은 이런 종류의 테스트를 위해 설계되지 않았습니다. 상당한 라이선스 및 인프라 비용 없이는 침투 테스트를 실행할 복제 z/OS 환경을 쉽게 띄울 수 없습니다.
DORA는 또한 상세한 ICT 자산 인벤토리, 특정 기한 내 사고 보고, 그리고 여러분의 메인프레임 벤더를 포함하는 핵심 ICT 서비스 제공자에 대한 제3자 위험 관리를 요구합니다. 현대화는 두 가지 방식으로 도움이 됩니다. 첫째, 지식 그래프 자체가 DORA가 요구하는 ICT 자산 인벤토리 역할을 합니다. 그것은 모든 프로그램, 모든 데이터 흐름, 모든 외부 의존성을 매핑합니다. 규제 당국은 그것을 직접 쿼리할 수 있습니다.
둘째, 클라우드 인프라에서 실행되는 마이그레이션된 구성 요소는 본질적으로 복원력 테스트가 더 쉽습니다. 필요에 따라 테스트 환경을 띄우고, 카오스 엔지니어링 시나리오를 실행하며, 프로덕션에 영향을 주지 않고 복구 절차를 검증할 수 있습니다. 우리는 마이그레이션이 완료되기 전에도 기관들이 자신의 기술 자산을 이해하고 있음을 입증하기 위해 규제 심사에서 지식 그래프를 증거로 사용하는 것을 봤습니다.
이 솔루션 페이지의 방법론은 레거시 현대화와 지식 그래프 아키텍처에 관한 우리의 발표된 연구에 근거하고 있습니다.
저장소 인식 지식 그래프와 GraphRAG가 엔터프라이즈 COBOL 시스템에서 AI 코드 번역을 실패하게 만드는 "Lost in the Middle" 증후군을 어떻게 극복하는가.
1년 차의 20~30% MIPS 절감은 일반적으로 중견 기관에 연간 50만~200만 달러를 절약해 줍니다.
지식 그래프 진단에는 4~6주가 걸립니다. 여러분은 마이그레이션을 진행하든 안 하든, 코드베이스의 완전한 의존성 지도, 데드 코드 보고서, 그리고 순위가 매겨진 추출 순서를 얻습니다. 그 진단 자체가 영구적인 자산입니다.