메인프레임 현대화는 단일 의사결정인 경우가 거의 없습니다. 그것은 여러 뚜렷이 다른 전략 사이의 선택이며, 각 전략은 매우 다른 비용, 기간, 위험 프로필을 가지고 있고, 올바른 답은 기술적 선호가 아니라 비즈니스 목표에 달려 있습니다. replatform으로 충분한데 “모든 것을 다시 작성"하기를 선택하거나, 진짜 문제가 유지보수 불가능한 코드인데 “lift and shift"를 선택하는 것이 현대화 프로그램이 수백만을 낭비하는 방식입니다.
이 가이드는 주요 현대화 전략을 비교하고, 각 전략이 언제 타당한지, 그리고 어떻게 선택하는지 설명합니다.
TL;DR
- 주요 전략은 rehost, replatform, refactor, rearchitect/rewrite, replace, retire이며, 대부분은 흔히 rehost, replatform, refactor/rewrite로 묶입니다
- rehosting은 가장 빠르고 저렴하지만 변화가 가장 적습니다. rewrite는 가장 현대적인 결과를 제공하지만 비용과 위험이 가장 큽니다
- 올바른 선택은 비즈니스 동인에 달려 있습니다. 비용 절감, 민첩성, 위험, 인력 확보 가능성, 기존 코드의 상태입니다
- 대부분의 대규모 영국 프로그램은 모든 것에 단일 접근 방식을 적용하기보다 자산 전반에 걸쳐 전략을 혼합합니다
애초에 왜 메인프레임을 현대화하는가
동인은 영국 기업 전반에 걸쳐 일관됩니다. COBOL과 메인프레임 인력 풀이 은퇴하고 있고, 메인프레임 운영 비용이 높으며, 시스템은 빠르게 변경하기 어렵고, 현대적인 클라우드, 데이터, AI 플랫폼과의 통합이 까다롭습니다. 아무것도 하지 않는 것은 전문성이 사라짐에 따라 커지는 자체 위험을 수반합니다. 질문은 대개 현대화를 할지 말지가 아니라 어떻게 하느냐입니다.
메인프레임 현대화 전략
업계 프레임워크는 6~7개의 선택지를 나열하지만, 실무에서는 몇 가지 의미 있는 선택으로 묶입니다.
Rehost(“Lift and Shift”)
기존 애플리케이션을 거의 변경 없이 새 인프라로 이전합니다. 예를 들어 클라우드나 범용 하드웨어에서 메인프레임 환경을 에뮬레이션합니다. COBOL 코드는 대체로 그대로 유지됩니다.
- 장점: 가장 빠르고 비용이 낮은 선택지. 낮은 딜리버리 위험. 메인프레임 하드웨어 및 라이선스 비용에서 즉시 탈출.
- 단점: 코드에 대해 거의 아무것도 바꾸지 않습니다. 여전히 COBOL이 있고, 여전히 인력 문제가 있으며, 민첩성은 거의 얻지 못합니다. 소프트웨어 자체의 현대화가 아니라 비용 대책입니다.
- 가장 적합한 대상: 메인프레임 하드웨어에서 신속히 벗어나고 더 깊은 현대화를 미루어야 하는 조직.
Replatform
일부 조정을 거쳐 새 플랫폼으로 이전합니다. 예를 들어 COBOL을 재컴파일해 Linux나 클라우드에서 실행하거나, 데이터베이스를 DB2에서 현대적인 동등물로 옮기되, 비즈니스 로직은 다시 작성하지 않습니다.
- 장점: 적당한 노력으로 의미 있는 인프라 및 비용 이점. 검증된 비즈니스 로직을 그대로 유지. rewrite보다 낮은 위험.
- 단점: 애플리케이션은 근본적으로 여전히 기존 애플리케이션입니다. 민첩성 이득은 제한적이고, 코드 수준의 인력 문제는 지속됩니다.
- 가장 적합한 대상: 작동하는 로직을 보존하고 위험을 제한하면서 클라우드와 비용 이점을 원하는 조직.
Refactor
기존 코드를 재구성하고 개선하며, 흔히 외부 동작을 바꾸지 않은 채 현대적인 언어로 변환합니다. 여기에 COBOL에서 현대적인 언어로의 자동 변환이 들어맞으며, 건강한 개발자 풀을 가진 언어로 유지보수 가능한 코드를 생성합니다.
- 장점: 주류 언어로 이동해 인력 문제를 해결. 유지보수성 향상. 동작 보존. 점진적으로 수행 가능.
- 단점: rehost나 replatform보다 노력이 큼. 엄격한 출력 동등성 테스트가 필요. 자동 변환도 데이터 접근과 정밀도에 대해서는 여전히 사람의 작업이 필요.
- 가장 적합한 대상: 로직은 견실하지만 언어와 구조가 부담이 되는 시스템. 이것이 대부분의 COBOL 현대화에 최적의 선택지입니다.
Rearchitect / Rewrite
시스템을 재구축하고, 아키텍처를 재설계하며(예: 서비스 또는 클라우드 네이티브 설계로), 현대적인 스택 위에서 비즈니스 로직을 다시 구현합니다.
- 장점: 가장 현대적이고 민첩하며 유지보수 가능한 결과를 제공. 누적된 기술 부채를 완전히 제거.
- 단점: 가장 높은 비용, 가장 긴 기간, 가장 큰 위험. 수십 년치의 문서화되지 않은 비즈니스 규칙을 처음부터 다시 구현하는 것이 대규모 프로그램이 실패하는 지점입니다.
- 가장 적합한 대상: 현재 설계가 지원할 수 없는 역량을 비즈니스가 필요로 하는, 진정으로 목적에 부적합한 시스템.
Replace 및 Retire
시스템을 상용 기성품(COTS)이나 SaaS 제품으로 교체하거나, 더 이상 필요하지 않으면 완전히 폐기합니다.
- 장점: 적합한 제품이 존재하거나 기능이 진부해진 경우 가장 비용 효율적인 결과가 될 수 있습니다.
- 단점: COTS가 맞춤형 로직과 정확히 일치하는 경우는 드뭅니다. 마이그레이션과 변화 관리가 상당합니다. 진정으로 차별화된 시스템에는 실행 불가능합니다.
- 가장 적합한 대상: 성숙한 제품이 존재하는 커모디티 기능(예: 급여 또는 총계정원장).
전략 비교
| 전략 | 비용 | 기간 | 위험 | 현대화 이점 |
|---|---|---|---|---|
| Rehost | 최저 | 최단 | 낮음 | 낮음(인프라만) |
| Replatform | 낮음~중간 | 짧음~중간 | 낮음~중간 | 중간 |
| Refactor | 중간 | 중간 | 중간 | 높음(코드와 인력) |
| Rewrite | 최고 | 최장 | 높음 | 최고 |
| Replace / Retire | 가변 | 가변 | 중간~높음 | 가변 |
어떻게 선택할 것인가
기술이 아니라 비즈니스 동인이 결정하게 하십시오.
- 주요 동인이 비용과 신속한 하드웨어 탈출인 경우: rehost 또는 replatform으로 시작합니다.
- 주요 동인이 인력 부족과 유지보수성인 경우: refactor, 일반적으로 COBOL을 주류 언어로 변환합니다.
- 주요 동인이 기존 설계가 지원할 수 없는 새 역량인 경우: 필요한 부분을 rearchitect 또는 rewrite합니다.
- 그 기능이 커모디티인 경우: replace를 고려합니다.
실무에서 대규모 영국 자산은 접근 방식을 혼합합니다. 안정적인 부분은 replatform, 유지보수하기 어려운 코드는 refactor, 새 역량이 필요한 소수의 시스템은 rewrite, 더 이상 사용되지 않는 것은 retire합니다. 선택한 경로가 COBOL을 현대적인 언어로 변환하는 것을 포함한다면, COBOL 마이그레이션 개요 는 C#, Java, Python, Go, C++, Rust 같은 대상 언어를 비교하고, COBOL 마이그레이션 비용 가이드 는 현실적인 예산을 제시합니다.
Mecanik 레거시 메인프레임 마이그레이션 서비스 는 코드 마이그레이션과 함께 인프라 폐기를 다루고, COBOL 현대화 서비스 는 코드 수준의 refactor 및 변환 작업을 다룹니다.
핵심 요점
- 메인프레임 현대화는 rehost, replatform, refactor, rewrite, replace/retire 사이의 선택이며, 각각 뚜렷한 비용-위험 프로필을 가집니다.
- rehost는 가장 빠르고 저렴하지만 현대화가 가장 적습니다. rewrite는 가장 변혁적이지만 가장 비싸고 위험합니다.
- refactoring(흔히 COBOL을 현대적인 언어로 변환하는 것)은 로직은 견실하지만 언어와 인력이 문제일 때 최적의 선택지입니다.
- 대부분의 대규모 프로그램은 자산 전반에 걸쳐 전략을 혼합합니다. 기술적 선호가 아니라 비즈니스 동인이 결정하게 하십시오.
자주 묻는 질문(FAQ)
메인프레임 애플리케이션의 rehosting과 refactoring의 차이는 무엇인가요? rehosting(“lift and shift”)은 기존 애플리케이션을 코드를 거의 변경하지 않고 새 인프라로 옮기므로 하드웨어 비용은 해결하지만 코드나 인력 문제는 해결하지 못합니다. refactoring은 코드를 재구성하고 흔히 동작을 보존하면서 현대적인 언어로 변환하므로 유지보수성과 인력 문제를 해결합니다.
COBOL은 다시 작성하는 것이 나을까요, 마이그레이션하는 것이 나을까요? 시스템에 따라 다릅니다. 비즈니스 로직은 견실하지만 언어가 부담이라면, COBOL을 현대적인 언어로 변환(refactoring)하는 것이 일반적으로 rewrite보다 위험과 비용이 낮습니다. 완전한 rewrite는 현재 설계가 비즈니스가 필요로 하는 역량을 지원할 수 없을 때만 정당화됩니다.
어떤 메인프레임 현대화 전략이 가장 저렴한가요? rehosting이 일반적으로 가장 저렴하고 빠르지만, 애플리케이션이 근본적으로 동일하게 유지되므로 현대화가 가장 적습니다. replatforming은 적당한 비용으로 적당한 이점을 더합니다. rewriting이 가장 비쌉니다.
메인프레임을 점진적으로 현대화할 수 있나요? 예. 점진적(strangler fig ) 현대화는 시스템의 각 부분을 한 번에 하나씩 교체하거나 변환해 빅뱅 위험을 줄입니다. 대부분의 대규모 영국 프로그램은 전략을 혼합하고 자산 전반에 걸쳐 점진적으로 전개합니다.
메인프레임 현대화에서 가장 큰 위험은 무엇인가요? 수십 년치의 문서화되지 않은 비즈니스 로직을 다시 구현하는 것, 특히 완전한 rewrite에서의 그것과 불충분한 출력 동등성 테스트입니다. 검증된 로직을 보존하는 전략(replatform, refactor)은 처음부터 다시 만드는 rewrite보다 이 위험을 덜 안습니다.
댓글