뜨거운 (Big) 철을 놓고 때려라
Source: Dev.to
번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다. 현재는 링크만 포함되어 있어 번역할 내용이 없습니다. 텍스트를 복사해서 알려주시면 바로 도와드릴게요.
레거시 시스템 전환을 간단하고 빠르게, 안전하게
메인프레임 현대화 프로젝트는 개발 비용이 지속적으로 상승하고 납기일이 계속 미뤄지는 등으로 인해 종종 실패합니다. 이러한 실패는 복잡성을 과소평가하고 안전하고 효율적인 변화를 위한 기반을 마련하기 전에 야심찬 전환을 시도하기 때문입니다.
올바른 전략과 적절한 도구만 있다면 현대화는 효율적이고 효과적이며 안전하게 진행될 수 있습니다.
제안된 3단계 접근법
- Rewrite – COBOL을 이식 가능하고 단위 테스트된 Java로 변환합니다.
- Replatform – Java 코드를 z/OS에서 클라우드로 이동합니다.
- Rearchitect – 유지 보수성을 향상하고 새로운 기능을 제공하도록 리팩터링하고 재구성합니다.
이러한 단계들을 제한된 범위의 반복으로 진행함으로써 현대화는 시스템 안정성을 유지하면서 꾸준히 진전할 수 있으며, 점진적인 기술 및 지식 전환을 가능하게 하고, 지속적으로 확대되는 시스템과 비용의 함정을 피할 수 있습니다.
현대화 프로젝트가 실패하는 이유
레거시 시스템은 유지보수와 테스트가 어렵습니다. 성공은 변환을 시도하기 전에 소프트웨어를 변경하기 쉽게 만드는 데서 옵니다. 다시 말해, “철이 뜨거워진 뒤에만 때리라”는 의미입니다.
레거시 COBOL 애플리케이션의 특징
- 자동화된 안전망 부재 – 단위 테스트 라이브러리, CI/CD 파이프라인, 혹은 스모크 테스트 스위트가 없어 의도치 않은 결과를 잡아낼 수 없습니다.
- 밀접하게 결합된 모놀리식 – 대부분의 구성 요소가 다목적으로 설계돼 있어 격리하거나 추출하기가 매우 어렵습니다.
- 무결함 허용도 없음 – 생명과 직결된 거래(메디케어, 사회보장, 실업 급여 등)를 처리합니다.
- 하드웨어 효율 설계 – 수십 년 동안 IBM 하드웨어에 최적화돼 있어 비효율적인 변경에 사용할 수 있는 성능 여유가 거의 없습니다.
- 지속적인 규제 변동 – 대규모 변환을 위한 “동결 기간”이 없습니다.
이러한 도전 과제가 모두 동시에 존재하면, 이를 잘 모르는 개발 팀이 레거시 시스템을 변환하는 난이도를 과소평가하기 쉽습니다.
현대화 팀에 대한 일반적인 오해
- 워터폴이 유일한 장벽이라고 가정하기 – 더 깊은 아키텍처 문제를 해결하지 않고 스크럼을 즉시 도입할 수 있다고 믿는 것.
- 레거시 설계를 부수적인 것으로 보는 것 – 시스템 아키텍처를 “개발자들이 더 나은 방법을 몰랐던” 유물처럼 취급하는 것.
- 고고학적 은유 사용하기 – 시스템을 매일 유지하는 사람들의 전문성을 무시하고 발견 과정을 “유물을 발굴한다”는 식으로 묘사하는 것.
밝고 유능한 엔지니어들은 최신 스택에서 뛰어나지만, 곧 예상치 못한 제약과 레거시 시스템과의 과도한 통합에 얽히게 된다. 그들의 스크럼 의식은 진정한 애자일 개발을 가능하게 하는 것이 아니라 단순히 투명성을 보여주는 메커니즘에 불과해진다.
그들이 잡아당기는 모든 실이 전체 스웨터를 풀어버릴 위협처럼 보인다. 설정된 모든 목표나 마감일은 늦게 발견된 제약 앞에서 약해지거나 물러나는 것처럼 보인다.
팀이 데모 슬롯을 채우기 위해 스프린트 시간을 저수준 기술 세부 사항에 소비할 때, 프로젝트 매니저는 경보를 울리고 투자 대비 수익에 대한 까다로운 질문을 해야 한다.
사고 실험
메인프레임은 잠시 제쳐두세요. 여러분이 수백만 줄의 코드로 이루어진 거대한 소프트웨어 시스템을 물려받았고, 앞으로 20년 동안 그 시스템을 전담해야 한다고 상상해 보세요.
- 첫 번째 변경 요청이 들어옵니다: 처리 규칙을 수정하고, 데이터 모델을 확장하며, 감사/보고 서브시스템을 조정합니다.
- 코드를 파고들어 보니 테스트가 전혀 없는 거대한 루브 골드버그 기계를 발견합니다.
- 여러 곳에 흩어져 있는 암호 같은 이름의 플래그를 손볼 때마다 부작용을 예측할 수 없어서 등골이 오싹해집니다.
대부분의 엔지니어와 마찬가지로 여러분도 수정하기 전에 테스트를 작성하는 것이 직감일 것입니다—예상치 못한 부작용이 수백만 달러의 생명을 구하는 비용을 낭비하게 만들 수 있다는 것을 알기 때문이죠. 이 내용이 공감된다면, 다음에 제시되는 제안들은 상식처럼 느껴질 것입니다.
핵심 요약
복잡한 레거시 시스템을 성공적으로 현대화하려면 안전하게 변혁적인 변화를 만들기 위한 기반을 마련하는 것이 필요합니다. 3단계 접근 방식(Rewrite → Replatform → Rearchitect)은 위험, 범위 및 비용을 관리하면서 그 목표를 달성하기 위한 구조화된 경로를 제공합니다.
Phase 1 – Rewrite → Portable, Tested Java
Goal: COBOL 프로그램을 이식 가능하고 철저히 테스트된 Java 코드로 변환합니다.
Note: 이것은 시장을 떠들썩하게 하는 저품질 “JOBOL” 트랜스파일러에 관한 것이 아닙니다. 최신 LLM을 활용하면 훨씬 더 나은 결과를 얻을 수 있습니다.
What We Do
- 각 COBOL 프로그램을 함수‑및‑인터페이스‑동등 Java 구현으로 교체합니다.
- 플랫폼‑추상화 레이어를 도입하여 모든 플랫폼‑특정 코드를 명확히 정의된 인터페이스 뒤에 숨깁니다.
- 단위 테스트를 작성해 기능적 동등성을 검증하고 병렬 프로덕션 테스트를 위한 안전망으로 활용합니다.
Why It Matters
| 핵심 혜택 | 설명 |
|---|---|
| 테스트 커버리지 | 단위 테스트 커버리지는 변경 검증을 크게 가속화하여 빠르고 안전한 배포를 가능하게 합니다. |
| 이식성 | 추상화 레이어 덕분에 동일한 코드와 테스트를 어떤 플랫폼(로컬 워크스테이션, z/OS, 클라우드)에서도 실행할 수 있습니다. 메인프레임을 떠날 때 비즈니스 규칙을 다시 작성할 필요가 없습니다. |
| 병렬 테스트를 통한 안전성 | 동일한 함수와 인터페이스 덕분에 새로운 Java 컴포넌트를 레거시 COBOL 버전과 나란히 실행할 수 있어, 프로덕션에 도달하기 전에 회귀를 잡아낼 수 있습니다. |
Practical Tips
- 프로그램‑별 재작성은 이중 유지보수 비용을 낮추고 빠른 재통합을 가능하게 합니다.
- 가이드를 프레임워크로 여기고, 법칙이 아니라는 점을 기억하세요—인터페이스 경계와 LLM‑구동 생산성을 기준으로 작업 규모를 조정합니다.
- 안정적인 인터페이스에 집중하세요. 이는 플랫폼 추상화를 구현하는 동안 병렬 테스트에서 활용될 수 있습니다.
Phase 2 – 클라우드 인프라로 마이그레이션
Goal: 검증된 포터블 Java 코드를 z/OS에서 클라우드 환경으로 옮긴다.
“클라우드 마이그레이션”은 궁극적인 결승선처럼 들릴 수 있지만, 신중히 따져야 할 트레이드‑오프가 있다.
클라우드의 장점
- Pay‑as‑you‑go 하드웨어 리소스 → 유연한 비용 모델.
- Built‑in redundancy 다중 데이터센터에 걸친 중복성 → 재해 복구 능력 향상.
- Separate CI/CD pipeline → 메인프레임 릴리스 사이클에 방해되지 않는 보다 쉬운 배포.
- 방대한 마켓플레이스를 통한 개발 생산성, 분석, 모니터링 도구 접근.
예상되는 과제
| Challenge | Impact |
|---|---|
| Complexity | 애플리케이션을 여러 플랫폼에 분산시키면 이해와 트러블슈팅이 더 어려워진다. |
| Latency | 서브‑밀리초 수준의 로컬 호출을 ~50 ms API 호출로 대체하면 대규모 배치 사이클 타이밍에 위협이 될 수 있다. |
| Cost | 새로운 클라우드 리소스는 비용이 발생하고 온‑프레미스 비용을 즉시 상쇄하지 않는다; 또한 클라우드‑네이티브 스킬을 가진 엔지니어가 필요하다. |
마이그레이션 권장 사항
- Start Small – 데이터 경계가 명확하고 규모가 큰 독립형 기능 컴포넌트만 마이그레이션한다.
- Assess Data Locality – 네트워크 지연으로 인한 런타임 성능 저하를 해당 컴포넌트가 감당할 수 있는지 확인한다.
- Limit Cross‑Platform Glue – 임시 통합 레이어를 최소화한다; 레이어마다 비용, 마찰, 위험이 추가된다.
- Maintain Simplicity – 현대화된 시스템을 간결하게 유지해 속도를 보존하고 유지보수 부담을 줄인다.
3단계 – 재구성 → 유지보수성 및 새로운 기능
목표: 시스템을 더 나은 유지보수성을 위해 리팩터링하거나 재구성하고, 또는 새로운 기능 제공을 시작합니다.
이제 애플리케이션이:
- 변경이 쉬워짐 (현대적인 테스트 덕분).
- 배포가 쉬워짐 (CI/CD 파이프라인 덕분).
팀은 안전하게 더 깊은 변화를 추구할 수 있습니다.
앞으로 나아갈 두 가지 경로
| 경로 | 적합한 상황 |
|---|---|
| 유지보수성‑우선 | 새 기능을 추가하기 전에 테스트 가능성, 모듈성 및 전반적인 코드 품질을 계속 개선하고 싶을 때. |
| 기능‑우선 | 이제 안전하게 제공할 수 있는 사용자 경험 개선 또는 비즈니스 핵심 기능이 백로그에 있을 때. |
왜 이것이 효과적인가
- 재작성 단계에서는 의도적으로 대규모 재설계를 피했으며, 코드베이스를 안정적이고 충분히 테스트된 상태로 유지했습니다.
- 이러한 안전망이 확보된 상태에서 리팩터링(예: 서비스 추출, 도메인 주도 설계 도입)이나 재구성(예: 마이크로서비스로 전환)도 위험이 낮아집니다.
Final Thoughts
Mainframe 레거시 애플리케이션은 크고, 복잡하며, 미션‑크리티컬합니다. 그 기능과 구조는 긴밀하게 결합된 다목적 컴포넌트로 진화했습니다.
시스템을 완전히 이해하고 안전망을 구축하기 전에 전면적인 변환을 시도하는 것은 재앙을 부르는 레시피와 같습니다—한 걸음마다 갈퀴에 밟는 느낌이 듭니다.
“쇠가 뜨거울 때 치라.”
3단계 접근법의 모멘텀을 활용하되, 테스트와 병렬 실행을 가드레일로 삼아 신중하게 진행하십시오.
전략 권고
시스템을 근본적으로 변형하려고 시도하기 전에 시스템을 더 쉽게 변경할 수 있도록 만드는 데 시간을 투자하십시오.
- COBOL 재작성을 이식 가능하고 단위 테스트된 Java로 전환하면서 기능 및 인터페이스 동등성을 유지하고,
- 범위 확대를 방지하고,
- 병렬 생산 테스트를 가능하게 하며,
- 소프트웨어 유연성에 가장 효율적인 경로가 됩니다.
이 중요한 첫 단계—COBOL에서 보다 생산적인 언어로 전환하는 것—은 다음과 같이 될 수 있습니다:
- 가장 쉬운 단계라면 전적으로 집중할 때이며, 또는
- 이러한 레거시 시스템의 근본적인 과제를 무시한다면 지속적인 부담이 되어, 결국 물에 빠지거나 헤엄칠지 결정하게 됩니다.
여기서 다루지 않는 주제들
- 데이터 현대화
- 인터페이스 현대화
- COBOL/Java 통합을 가능하게 하는 소프트웨어 유틸리티(즉시 작업을 시작할 수 있도록 도와줍니다)
- 프로젝트 계획, 관리 및 성공 지표
관심이 충분히 있다면 이 주제들에 대해 글을 쓸 수도 있습니다. 관심 있는 분들과 언제든지 이와 관련된 이야기를 나누고 싶습니다.
연락하기
이 전략이 마음에 들고 귀하의 특정 프로젝트에 적용하는 데 도움이 필요하시면 기꺼이 도와드리겠습니다.
- Email: sbwiley@pm.me
- LinkedIn: Sam Wiley
저자 소개
Sam Wiley – 소프트웨어 엔지니어이자 Boring Technology 옹호자로, 메인프레임 현대화에 전문성을 가지고 있습니다.
- IBM Redbooks에 묻힌 지식을 활용해 새로운 기능을 구축하는 현대화 팀의 수석 개발자.
- 연간 수십억 달러를 처리하는 소프트웨어에 대한 성공적인 프로덕션 현대화 배포를 수행했습니다.
- 다학제 팀 간 현대화 작업을 조정하고, 다수의 프로젝트를 계획·감독하는 기술 고문.
- 기술 혁신과 운영 안정성을 균형 있게 맞추는 실용적이며 위험·비용을 최소화한 전환 전략을 강조합니다.