비슷한 규모의 COBOL 포트폴리오를 보유한 두 조직이 서로 다른 현대화 전략을 세웠습니다. 한 조직은 리플랫폼 방식을 택하여 AWS 메인프레임 현대화 솔루션이나 COBOL 에뮬레이션 레이어를 활용해 COBOL 프로그램을 클라우드 인프라로 이전하고, 물리적 메인프레임을 없애면서 코드는 그대로 유지했습니다. 그 결과 18개월 만에 인프라 비용을 40% 절감했고, 성공적인 프로그램으로 평가받았습니다. 반면 다른 조직은 같은 방식을 시도했지만 12개월 만에 난관에 부딪혀 아키텍처를 재설계하는 방향으로 전환했습니다. 가장 중요한 프로그램들을 Java 마이크로서비스로 재구축하는 데에 원래 예산의 두 배에 달하는 비용이 소요되었고, 완료하는 데 3년이 더 걸렸습니다.
출발점은 같았지만 결과는 완전히 달랐습니다. 차이점은 도구, 공급업체, 또는 팀 때문이 아니었습니다. 두 번째 조직은 아키텍처적 제약 때문에 새로운 플랫폼이 수용할 수 없는 시스템, CICS 트랜잭션 종속성, VSAM 파일 구조, 그리고 근본적인 재설계 없이는 충족할 수 없는 실시간 요구 사항 때문에 시스템 리플랫폼을 선택했습니다. 이러한 결정은 누구도 시스템을 제대로 이해하지 못한 상태에서 내려진 것이었습니다.
재설계의 걸림돌을 초기에 찾아내세요
SMART TS XL CICS 결합 깊이, VSAM 복잡성 및 전체 COBOL 포트폴리오에서 사용되지 않는 코드를 자동으로 식별합니다.
더 많은 정보COBOL에서 각 경로가 실제로 의미하는 바는 무엇일까요?
일반적인 정의는 잘 알려져 있습니다. 중요한 것은 각 경로가 COBOL 프로그램에 구체적으로 어떤 의미를 갖는지입니다. COBOL 프로그램은 아키텍처, 실행 모델 및 데이터 구조가 최신 애플리케이션과 다르기 때문에 어떤 경로가 적합한지가 직접적인 영향을 받습니다.
COBOL 플랫폼 재구축
리플랫폼화는 COBOL 프로그램을 새로운 운영 환경, 일반적으로 클라우드 인프라로 옮기는 과정으로, 코드 자체는 크게 변경되지 않습니다. COBOL은 새로운 플랫폼에서 컴파일 및 실행되는데, 네이티브 방식으로 실행되거나(IBM의 Linux 기반 COBOL 컴파일러 사용) 메인프레임 관련 호출(CICS, VSAM, JES)을 가로채 클라우드 네이티브 방식으로 변환하는 에뮬레이션 계층을 통해 실행됩니다.
플랫폼 개편 후에도 유지되는 것:
- COBOL 소스 코드
- 프로그램의 논리, 계산 및 비즈니스 규칙
- 배치 실행 모델(PERFORM 루프, 순차적 파일 처리)
- 데이터 구조(레코드 레이아웃, 카피북 정의)
- JCL 작업 구조(새로운 스케줄러에 맞춰 재작성되었지만 논리적으로는 동일함)
플랫폼 변경으로 인한 변화:
- 물리적 인프라(z/OS → 클라우드 기반 Linux)
- I/O 서브시스템(VSAM → 관리형 파일 저장소 또는 데이터베이스, 사용하는 도구에 따라 다름)
- 작업 스케줄러(JES2/JES3 → AWS Batch, Azure Logic Apps 또는 이와 동등한 프로그램)
- 비용 모델 (MIPS 기반 청구 → 사용량 기반 클라우드 청구)
핵심 요점: 플랫폼 재구축은 문제가 플랫폼 자체, z/OS 운영 비용, 인프라 의존성, MIPS 청구 모델에 있을 때 올바른 해결책입니다. 하지만 문제가 코드나 아키텍처에 있을 때는 잘못된 접근 방식입니다.
COBOL 재설계
재설계는 시스템의 근본적인 설계를 변경합니다. 비즈니스 로직은 그대로 유지되거나 COBOL 소스 코드에서 다시 파생되지만, 새로운 언어와 새로운 실행 모델, 그리고 새로운 데이터 계층을 사용하여 구현됩니다. 결과적으로 COBOL이 수행했던 기능을 그대로 수행하면서도 구조적으로는 COBOL과 전혀 다른 시스템이 탄생합니다.
재설계로 인해 변경되는 사항:
- 프로그래밍 언어 (COBOL → Java, Python, Go, C#)
- 실행 모델(배치 처리 → 이벤트 기반, 스트리밍 또는 API 기반)
- 데이터 계층(VSAM 파일 → 관계형 데이터베이스, NoSQL, 클라우드 네이티브 스토리지)
- 트랜잭션 모델(CICS 의사 대화형 → RESTful 상태 비저장 서비스)
- 통합 패턴(공유 데이터 세트 → API 계약, 메시지 큐)
재설계 시 보존해야 할 사항:
- COBOL이 구현하는 모든 비즈니스 규칙(문서화되지 않은 예외 상황 포함)
- 팩형 십진수 연산의 수치 정밀도 특성을 포함한 모든 계산
- MOVE 문에서의 암시적 변환을 포함한 모든 데이터 변환
- 하위 시스템이 의존할 수 있는 특정 파일 상태 코드 및 비정상 종료 동작을 포함한 모든 오류 조건
주의하세요: 가장 흔한 재설계 실패 원인은 COBOL 코드에 비즈니스 규칙이 포함되어 있지만, 그 규칙이 어디에도 문서화되지 않았다는 사실을 발견하는 것입니다. 새 시스템이 특정 예외 상황에서 이전 시스템과 다르게 동작하는 이유는 구현 오류 때문이 아니라, 명세가 불완전했기 때문입니다. 재설계를 시작하기 전에 COBOL 소스 코드에서 비즈니스 로직을 추출하고 문서화해야 합니다.
COBOL 관련 요인이 이러한 결정에 미치는 영향
일반적인 현대화 프레임워크는 플랫폼 재구축 및 아키텍처 재설계를 주로 비용, 일정 및 위험에 대한 결정으로 간주합니다. 그러나 COBOL의 경우, 언어 및 런타임 환경에 특정한 여러 기술적 요인이 결정 방향을 크게 좌우합니다.
CICS 트랜잭션 종속성
CICS(고객 정보 제어 시스템)는 많은 COBOL 프로그램이 대화형 워크로드에 사용하는 트랜잭션 처리 미들웨어입니다. EXEC CICS 호출을 하는 COBOL 프로그램은 화면 관리, 터미널 통신, 작업 디스패칭 및 프로그램 제어를 위해 CICS 트랜잭션 서버에 암묵적으로 의존합니다.
플랫폼 재구축 시 고려 사항: Micro Focus CICS 에뮬레이션, OpenFrame, 그리고 일부 AWS 메인프레임 현대화 기능과 같은 도구들은 CICS 시맨틱스를 에뮬레이션합니다. CICS 사용 방식이 표준적이고 정상적인 경우 에뮬레이션이 제대로 작동할 수 있습니다. 하지만 프로그램이 CICS 내부 기능, 공통 영역 조작, 동기화 지점 제어, 태스크 수준 저장소 등에 의존하는 경우 에뮬레이션 정확도가 저하될 수 있습니다.
재설계 필요성: CICS 프로그램을 REST API로 변환할 경우, 기존의 의사 대화형 트랜잭션 모델을 상태 비저장 상호 작용으로 재설계해야 합니다. 이는 단순한 코드 변환이 아닌 아키텍처 변경입니다.
아키텍처 재설계를 유도하는 신호: 복잡한 공통 영역 처리, 백엔드 트랜잭션 체이닝 또는 동기화 지점 로직을 사용하는 CICS 환경이 많이 사용됨.
VSAM 파일 아키텍처
VSAM(Virtual Storage Access Method)은 대부분의 COBOL 프로덕션 프로그램에서 사용하는 인덱스 파일 시스템입니다. VSAM 파일은 KSDS(키 순차 접근), ESDS(항목 순차 접근), RRDS(상대 레코드 접근)와 같은 특정 접근 패턴을 가지는데, 이러한 패턴은 클라우드 네이티브 스토리지에는 직접적으로 대응하는 방식이 없습니다.
플랫폼 재구축 시 고려 사항: 에뮬레이션 계층은 VSAM 읽기 및 쓰기 작업을 기본 파일 또는 데이터베이스 작업으로 변환합니다. 단순한 순차적 접근이나 키 기반 접근의 경우 이 방식이 효과적입니다. 그러나 복잡한 대체 키 접근, 여러 프로그램에서 공유되는 VSAM 클러스터 또는 성능에 민감한 임의 접근 패턴의 경우 에뮬레이션으로 인해 지연 시간과 복잡성이 증가합니다.
아키텍처 재설계의 의미: VSAM을 관계형 데이터베이스로 교체하려면 레코드 레이아웃을 테이블 스키마에 매핑하고, 암시적인 데이터 유형 변환을 처리하고, 모든 파일 접근 방식을 SQL 또는 ORM을 사용하도록 다시 작성해야 합니다.
재설계를 촉구하는 신호: 여러 프로그램에서 공유되는 VSAM 파일, 대체 인덱스 액세스 패턴 또는 에뮬레이션으로는 충족할 수 없는 실시간 성능 요구 사항.
배치 처리 요구사항과 실시간 처리 요구사항 비교
COBOL 배치 프로그램은 예약된 시간 간격 내에 대량의 레코드를 순차적으로 처리하도록 설계되었습니다. 많은 은행, 보험 및 정부 시스템에서는 여전히 수백만 건의 거래를 처리하고 보고서를 생성하며 마스터 파일을 업데이트하는 야간 배치 작업을 실행합니다.
플랫폼 변경의 의미: 배치 처리 방식은 클라우드 배치 실행(AWS Batch, Azure Batch)에 잘 적용됩니다. 순차 처리 모델은 플랫폼 변경 후에도 유지됩니다. 따라서 단순히 더 저렴한 인프라에서 동일한 배치 작업을 실행하는 것이 목적이라면, 플랫폼 변경을 통해 문제를 직접적으로 해결할 수 있습니다.
아키텍처 재설계의 의미: 비즈니스 요구사항이 변경된 경우, 예를 들어 야간 배치 처리에서 거의 실시간 처리로, 파일 기반 교환에서 API 통합으로, 단일 배치 실행 방식에서 개별적으로 실행되는 마이크로서비스로 변경된 경우, 플랫폼 재구축만으로는 새로운 요구사항을 충족할 수 없습니다. 아키텍처를 변경해야 합니다.
아키텍처 재설계를 촉구하는 신호: 이해관계자들이 요구하는 실시간 처리, API 기반 통합, 이벤트 기반 아키텍처 또는 배치 처리 방식으로는 제공할 수 없는 1초 미만의 응답 시간.
외부 사양 없이 내장된 비즈니스 로직
이는 COBOL 특유의 가장 과소평가된 요소입니다. 주요 위험으로는 수십 년 된 코드에 내재된 핵심 비즈니스 규칙의 손실과 시스템 동작에 대한 불충분한 문서화가 있습니다. COBOL 프로그램은 종종 비즈니스 규칙에 대한 유일하게 남아 있는 명세를 담고 있습니다. 특정 계산을 요구하는 규정은 1983년에 작성되었고, 이를 이해했던 비즈니스 분석가는 2001년에 은퇴했습니다. COBOL 코드는 단순한 구현체가 아니라, 바로 그 문서입니다.
리플랫폼의 의미: 코드가 보존되기 때문에 비즈니스 규칙은 그대로 유지됩니다. 이는 리플랫폼의 가장 강력한 장점 중 하나입니다.
재설계 시 고려 사항: 비즈니스 규칙은 재구현 전에 COBOL 소스 코드에서 추출해야 합니다. <cite index=”28-1″>문서화되지 않고 긴밀하게 결합된 코드는 모든 단계에서 작업량을 증가시킵니다.</cite> 추출이 불완전할 경우, 새 시스템은 이전 시스템과 사양이 달라지고, 이러한 차이점이 실제 운영 환경에서 드러나게 됩니다.
의사결정 프레임워크: 8가지 질문
진로를 선택하기 전에, 이 여덟 가지 질문을 통해 추측이 아닌 확신을 가지고 결정을 내리는 데 필요한 근거를 얻을 수 있습니다.
1. 이러한 현대화의 주요 원동력은 무엇입니까?
- 인프라 비용 → 플랫폼 재구축으로 충분함
- 플랫폼 종속성(z/OS) → 플랫폼 재설치로 충분합니다
- 실시간 요구사항 → 재설계 필요
- 통합 요구사항(API) → 재설계가 필요할 가능성이 높음
- 유지보수성/인재 확보 → 재설계 또는 리팩토링
2. CICS 결합 수준은 어느 정도입니까? 모든 EXEC CICS 호출을 열거하십시오. 20개 이상의 서로 다른 CICS 명령을 사용하는 프로그램의 수를 세십시오. CICS 결합도가 높은 프로그램은 에뮬레이션 정확도가 불확실한 경우 플랫폼 재구축에 적합하지 않습니다.
3. VSAM 접근 패턴은 무엇입니까? 대체 키, 공유 클러스터 또는 성능에 민감한 임의 접근 방식을 사용하여 VSAM 파일에 접근하는 프로그램을 식별하십시오. 이는 플랫폼 이전 위험을 나타내는 지표입니다.
4. 비즈니스 로직이 외부 문서로 작성되었습니까? COBOL 소스 코드가 유일한 공식 명세인 경우, 재설계를 위해서는 비즈니스 로직 추출이 필수 단계이며, 별도의 병렬 작업으로 처리할 필요는 없습니다.
5. 배치 처리 시간 허용 오차는 얼마입니까? 더 낮은 비용으로 동일한 배치 처리 모델이 필요한 경우 플랫폼을 재구축하십시오. 실시간으로 동일한 처리가 필요한 경우 아키텍처를 재설계하십시오.
6. 의존성 복잡성은 어느 정도입니까? 하위 프로그램, 데이터 세트, JCL 호출자 등 50개 이상의 의존성을 가진 프로그램은 독립 실행형 유틸리티보다 재설계 위험이 더 높습니다. 의존성 구조는 마이그레이션 순서와 테스트 범위를 결정합니다.
7. 코드 중 사용되지 않는 코드의 비율은 얼마나 될까요? 변환 전에 사용되지 않는 코드를 범위에서 제외하면 두 경로 모두에 필요한 노력이 줄어듭니다. 프로그램을 재설계하는 경우, 제외되지 않은 사용되지 않는 코드는 전체 비용을 들여 변환된 후 폐기됩니다.
8. 복잡도 분포는 어떻게 되나요? 프로그램당 순환 복잡도가 50을 초과하거나 포함된 카피북이 20개를 넘는 경우, 해당 프로그램은 재설계 비용이 많이 들고 플랫폼 변경 위험이 높은 프로그램임을 나타냅니다. 이러한 프로그램은 일괄 처리 방식보다는 개별적으로 접근해야 합니다.
프레임워크 적용: 네 가지 COBOL 시스템 프로필
| 프로필 | 형질 | 추천 경로 | 이론적 해석 |
|---|---|---|---|
| 안정적인 배치 유틸리티 | 순차 파일 I/O, CICS 불필요, 잘 문서화된 로직, 낮은 복잡성 | 리플랫폼 | 플랫폼 비용이 문제이지, 코드가 제약 조건이 아닙니다. |
| CICS 중심의 온라인 거래 | EXEC CICS 사용량이 많고, 공통 영역 종속성이 있으며, 유사 대화형 모델을 사용합니다. | 재설계자 | CICS 에뮬레이션 위험이 높으며 실시간 요구 사항이 있을 가능성이 큽니다. |
| VSAM 마스터 파일 프로세서 | 복잡한 VSAM 접근 패턴, 여러 프로그램에서 공유됨, 높은 읽기 볼륨 | 먼저 에뮬레이션의 정확도를 평가하고, 에뮬레이션이 제대로 작동하면 플랫폼을 변경하십시오. | VSAM 에뮬레이션은 결정 변수입니다. |
| 비즈니스 로직 재무 | 문서화되지 않은 규칙, 외부 사양 없음, 높은 규제 중요성 | 먼저 논리를 추출한 다음 선택하세요. | 비즈니스 로직을 사전에 추출하지 않고 재설계를 진행하는 것은 위험 부담이 너무 큽니다. |
핵심 요점: <cite index=”30-1″>실제로 대규모 자산 관리에서는 여러 접근 방식을 혼합하여 사용합니다. 안정적인 부분은 플랫폼을 재구축하고, 유지 관리가 어려운 코드는 리팩토링하며, 새로운 기능이 필요한 소수의 시스템은 재작성하고, 더 이상 사용하지 않는 시스템은 폐기합니다.</cite> 이러한 결정은 포트폴리오 차원이 아니라 워크로드 차원에서 이루어지며, 각 프로그램 또는 프로그램 그룹에 대해 증거에 기반하여 개별적으로 적용됩니다.
하이브리드 접근 방식: 우선 플랫폼 재구축, 필요한 경우 아키텍처 재설계
실용적인 규칙은 다음과 같습니다. 피해를 신속하게 막기 위해 호스팅을 변경하거나 플랫폼을 교체한 다음, 진정한 경쟁 우위 요소가 되는 시스템을 리팩토링하거나 재설계하십시오.
COBOL 포트폴리오가 방대한 대부분의 조직에서 실제적인 순서는 다음과 같습니다.
1단계, 재플랫폼화가 적합한 프로그램부터 시작합니다. CICS가 필요 없고, 순차적 I/O가 간단하며, 로직이 문서화되어 있고, 복잡성이 낮은 프로그램은 예측 가능한 노력과 위험으로 재플랫폼화를 진행할 수 있습니다. 이를 통해 인프라 비용을 신속하게 절감하고 조직의 신뢰를 구축할 수 있습니다.
2단계, 복잡한 프로그램 평가. CICS 연동, 복잡한 VSAM 패턴 또는 문서화되지 않은 비즈니스 로직이 포함된 프로그램은 해결 방안을 선택하기 전에 개별 분석이 필요합니다. 이 단계에서 비즈니스 로직 추출 및 구조 분석을 통해 재설계가 필요한지 여부와 범위가 결정됩니다.
3단계에서는 아키텍처적 제약 조건을 고려하여 프로그램을 재설계합니다. 재플랫폼화된 인프라에서 비즈니스 요구 사항, 실시간 요구 사항, API 통합, 이벤트 기반 처리 등을 충족할 수 없는 프로그램은 스트랭글러(Strangler) 패턴을 사용하여 재설계합니다. 이 패턴은 재플랫폼화된 프로그램과 함께 새로운 서비스를 구축하고, 각 구성 요소의 유효성을 검증하면서 트래픽을 점진적으로 새로운 구현으로 라우팅하며, 모든 트래픽이 마이그레이션되면 기존 프로그램을 폐기하는 방식으로 진행됩니다.
4단계, 사용되지 않는 코드 폐기. 구조 분석 중에 사용되지 않는 것으로 확인된 프로그램은 두 경로 모두에서 제외되고 서비스가 중단되어 전환 작업 없이 지속적인 유지 관리 비용이 절감됩니다.
어떠한 결정이 내려지기 전에 분석을 통해 반드시 도출되어야 할 사항은 무엇인가?
위의 의사결정 프레임워크는 추정치가 아닌 증거를 입력값으로 사용할 때 더 나은 결과를 도출합니다. 이러한 입력값을 제공하는 구조 분석은 문서나 개발자 지식에 의존하는 대신 실제 COBOL 소스 코드를 분석해야 합니다.
분석을 통해 각 프로그램에 대해 밝혀내야 할 사항은 다음과 같습니다.
문서에 포함되지 않은 프로그램을 포함한 전체 프로그램 목록. 대규모 COBOL 환경에서는 문서화되지 않은 프로그램의 수가 전체의 20%를 넘는 경우가 많습니다. 어떤 프로그램이 다른 프로그램을 호출하는지, 어떤 데이터 세트가 공유되는지, 어떤 JCL 작업이 어떤 프로그램을 호출하는지를 보여주는 종속성 그래프. 모든 프로그램에 대한 CICS 명령 목록(호출 횟수, 유형 및 복잡도). VSAM 액세스 패턴 분석(액세스 방법, 프로그램 간에 공유되는 파일, 대체 인덱스를 가진 파일). 순환 복잡도 분포(구조적으로 단순한 프로그램과 변환 시 위험도가 높은 프로그램). 데드 코드 식별(입력 실행 경로가 없는 프로그램 및 단락). 비즈니스 로직 추출(각 프로그램이 구현하는 규칙, 두 경로 모두의 출력을 검증하는 데 사용할 수 있는 형식).
이러한 인벤토리가 없으면 불완전한 정보에 기반하여 경로 결정이 이루어집니다. 프로그램은 계획 단계에서는 드러나지 않았던 아키텍처적 제약 조건이 에뮬레이션을 통해 밝혀지면서 잘못된 것으로 판명되는 가정에 근거하여 재플랫폼화 대상으로 지정됩니다.
방법 SMART TS XL 사전 결정 증거를 생성합니다.
SMART TS XL의 레거시 현대화 분석은 위에서 설명한 구조적 인벤토리를 자동화하여 모든 COBOL 프로그램, 카피북, JCL 작업 및 VSAM 파일 참조를 동시에 구문 분석하여 경로 결정을 증거 기반으로 만드는 통합 종속성 모델을 구축합니다.
애플리케이션 종속성 매핑은 프로그램 간 호출 그래프와 데이터셋 공유 맵을 생성하여 종속성 복잡성을 결정합니다. 이 요소는 플랫폼 재구축 에뮬레이션 위험과 재설계 범위 및 순서에 가장 직접적인 영향을 미치는 요소입니다.
정적 코드 분석은 포트폴리오에 있는 모든 프로그램에 대해 복잡도 지표, CICS 호출 목록 및 사용되지 않는 코드 식별 정보를 생성합니다. 순환 복잡도 임계값을 초과하고 CICS와의 결합도가 높은 프로그램은 일괄적으로 플랫폼 재구축 대상으로 지정되는 대신 자동으로 재설계 또는 평가 대상 프로그램으로 분류됩니다.
JCL 확장은 기호 매개변수를 해석하고 완전한 배치 실행 종속성 체인을 구축합니다. 이 체인에는 어떤 JCL 작업이 어떤 프로그램을 어떤 순서로 어떤 데이터 세트를 사용하여 호출하는지가 명시되어 있으며, 이를 통해 배치 일정을 충족하기 위해 각 경로의 출력이 어떻게 동작해야 하는지를 결정하는 운영 컨텍스트가 제공됩니다.
영향 분석 기능을 통해 프로그램 시작 전에 각 경로의 범위를 구체화할 수 있습니다. 재설계 대상으로 선정된 모든 프로그램에 대해 영향 분석은 업데이트, 재테스트 또는 재설계 구성 요소와의 조정이 필요한 모든 종속 프로그램을 열거합니다. 플랫폼 재구축 후보의 경우, 동일한 분석을 통해 일관성 있게 처리해야 하는 프로그램 간 종속성을 생성하는 공유 데이터 세트 및 공유 하위 프로그램을 식별합니다.
엔터프라이즈 검색 기능을 통해 프로그램 전체에서 전체 인벤토리를 쿼리할 수 있습니다. 특정 CICS 명령을 사용하는 모든 프로그램, 특정 VSAM 클러스터에 액세스하는 모든 프로그램, 특정 데이터 구조를 정의하는 모든 카피북을 수백만 줄의 COBOL 코드에서 단 몇 초 만에 찾을 수 있습니다.
이러한 결정을 올바르게 내리는 조직은 프로젝트 계획의 가정이 아닌 구조적 증거에 근거하여 결정을 내리는 조직입니다. 구조적 증거란 바로 이것입니다. SMART TS XL 생성합니다.
