💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 죽었다고 했지만 여전히 거기 있다

"메인프레임은 죽었다"라는 헤드라인은 1990년대부터 매년 나왔다. 그런데 2026년 5월, 당신이 ATM에서 돈을 뽑거나, 신용카드를 긁거나, 비행기 좌석을 예약하거나, 세금을 내거나, 정부에 출생신고를 하는 그 순간, 트랜잭션의 마지막 한 줄은 매우 높은 확률로 **메인프레임 위의 COBOL 프로그램**을 거친다.

- **IBM Z** — 2025년 9월 z17 출시, Telum II 프로세서, 칩-온-칩 AI 가속.

- **IBM i (구 AS/400)** — 130,000개 이상 회사가 운영 중. ERP·창고관리·보험.

- **COBOL** — 추정 200~220B(2,000억) 라인이 프로덕션에서 돈다. 매일.

- **RPG / JCL / CICS / DB2 z/OS / IMS / PL/I** — 여전히 현역.

- **Fujitsu BS2000 / NEC ACOS / Unisys ClearPath** — IBM이 아닌 메인프레임의 세계.

그리고 이 거대한 레거시는 2023년 이후 **AI**라는 새 변수를 만나며 다시 현대화의 사이클로 들어간다. IBM **watsonx Code Assistant for Z**는 COBOL을 Java로 번역하고, **GitHub Copilot**은 COBOL 자동완성을 지원하며, **AWS Mainframe Modernization**은 메인프레임 워크로드를 클라우드로 옮긴다.

이 글은 2026년 시점의 메인프레임을 다룬다. 어떻게 죽지 않았는가, 새 하드웨어는 무엇인가, AI는 어떻게 이 거대한 레거시를 깎고 있는가, 그리고 — 만약 당신이 개발자라면 — 왜 어떤 사람들은 지금 COBOL을 배우기로 결심하는가.

1장 · 2026년 메인프레임 — 죽지 않은 거인

먼저 숫자부터 보자. 2026년 기준 메인프레임 생태계의 추정치:

| 항목 | 추정 규모 |

| --- | --- |

| 프로덕션 COBOL 라인 수 | 200~220B 라인 |

| IBM i 운영 사이트 | 130,000+ 회사 (Forrester/IBM 추정) |

| IBM Z 시스템 설치 | 전 세계 약 10,000+ 개 사이트 |

| 일일 처리 비즈니스 트랜잭션 (IBM Z) | 약 300억 건 |

| Fortune 500 중 메인프레임 사용 비율 | 약 70% |

| Top 50 글로벌 은행 중 메인프레임 사용 비율 | 약 92% |

| 메인프레임에 의존하는 신용카드 트랜잭션 비율 | 약 87% |

(출처: IBM, Forrester, Gartner 시장 추정 — 정확한 수치는 출처별로 차이가 있음. 이 글의 모든 수치는 2024~2025년 공개 보고서 기반의 추정이다.)

"왜 안 바꿨나"는 잘못된 질문이다. 옳은 질문은 **"왜 바꾸지 않는 게 합리적이었나"**다. 답은 세 가지로 압축된다.

1. **검증된 신뢰성** — z/OS 시스템의 가용성은 흔히 99.999% (5 nine) 이상으로 보고된다. 연간 다운타임 5분 수준. 새 시스템이 이걸 매칭하려면 수년이 걸린다.

2. **테스트되지 않은 변경의 리스크 > 변경의 가치** — 2,000만 줄짜리 보험사 코어를 Java로 다시 쓴다고 가정해보자. 2년에 1억 달러. 그동안 새 기능은 못 만든다. CFO가 사인하지 않는다.

3. **데이터 중력** — DB2 z/OS, IMS, VSAM에 수십 년간 쌓인 데이터는 그 자리에 있다. 데이터를 옮기는 게 코드를 옮기는 것보다 어렵다.

그래서 메인프레임은 죽지 않았다. 그리고 죽는 대신, **천천히 진화한다**. 그게 이 글의 주제다.

2장 · IBM z17 (2025.9) — Telum II + 통합 AI

2025년 9월, IBM은 **z17**을 발표했다. 이전 세대(z16)는 2022년 4월에 나왔으니, 약 3년 주기다. z17의 핵심은 두 가지:

Telum II 프로세서

- 5nm급 공정 (정확한 노드는 IBM이 일반적으로 공개하지 않음)

- 8 코어, 5GHz대 클럭 (z16의 Telum I 대비 코어당 성능 향상)

- **칩-온-칩 AI 가속기** — Telum I의 온칩 AI 추론을 강화한 것. 트랜잭션 흐름 안에서 사기 탐지 등 ML 추론을 1ms 이내로 처리.

- 향상된 L2 캐시 구조, NUMA 토폴로지 최적화.

요약: Telum II는 **트랜잭션 도중에 AI 추론을 끼워 넣을 수 있다**. 카드 결제가 일어나는 그 순간에, 같은 칩 위에서 사기 탐지 모델이 돈다. 데이터를 GPU 클러스터로 보낼 필요가 없다.

Spyre 가속기 (옵션)

z16에서 처음 소개된 **IBM Spyre AI 가속기**(별도 PCIe 카드)가 z17에서도 옵션으로 제공된다. Spyre는 더 큰 모델(생성형 AI 추론)을 위한 별도 가속기 카드로, Telum II의 칩-온-칩 가속과 함께 쓸 수 있다.

무엇이 새로운가 (z16 대비)

| 항목 | z16 (2022.4) | z17 (2025.9) |

| --- | --- | --- |

| 프로세서 | Telum I | Telum II |

| 칩-온-칩 AI | 있음 (1세대) | 강화됨 (2세대) |

| Spyre 가속기 | 옵션 (후기 도입) | 옵션 (확장) |

| 메모리 대역폭 | - | 향상 (세부 수치는 IBM 자료 참조) |

| 보안 | Crypto Express 8S, 양자내성 알고리즘 지원 | 동일 흐름 + 강화 |

| 가용성 | 99.999% 이상 | 동일 클래스 |

z17은 혁명이라기보다는 **AI 통합의 심화**다. 트랜잭션 + AI 추론 + 보안을 한 칩에서 끝낸다는 IBM의 메시지가 더 강해졌다.

누가 z17을 살까

- **글로벌 은행·카드사** — 사기 탐지를 트랜잭션 인라인으로.

- **대형 보험사** — 클레임 처리 + 리스크 스코어링.

- **정부·세무** — 대량 배치 + 보안.

- **항공·물류** — 예약·재고 시스템의 백본.

가격은 공개되지 않는다. 보통 "수백만 달러부터"라고만 말한다. 그리고 그 돈을 쓰는 회사들은 그게 합리적이라고 믿는다.

3장 · IBM z16 — 여전히 현역

z17이 나왔다고 z16이 사라진 게 아니다. **2022년 4월에 출시된 z16은 2026년 현재도 활발히 판매되고 설치되고 있다.** 메인프레임의 라이프사이클은 길다 — 한 번 들어가면 10년은 간다.

z16의 특징을 정리하면:

- **Telum I** 프로세서 — IBM이 처음으로 칩-온-칩 AI 가속을 도입한 세대.

- **양자내성 암호** (Quantum-Safe Cryptography) — Crypto Express 8S 카드와 함께. NIST 표준화된 PQC 알고리즘 일부 지원.

- **펜타이드(IBM Telum) 캐시 구조** — L2를 가상 L3·L4로 활용해 256MB급 가상 L4 캐시를 만드는 독특한 설계.

- **z/OS 2.5 / 3.1 지원**

은행이 z16을 막 들였다면 z17으로 갈아탈 이유가 약하다. **z16 + 펌웨어 업데이트** 조합으로 2030년대 초반까지는 운영할 회사가 많다.

4장 · IBM i (구 AS/400) — 130K+ 회사

IBM Z만큼 유명하진 않지만, IBM의 또 다른 메인프레임 라인이 있다. 바로 **IBM i** — 1988년에 나온 **AS/400**의 후계.

이름의 역사

- **System/38** (1978)

- **AS/400** (1988) — Application System/400. 80~90년대 중견기업 ERP의 상징.

- **eServer iSeries** (2000)

- **System i** (2006)

- **IBM i** (2008~현재) — 운영체제 이름이자 플랫폼 이름.

하드웨어는 IBM **Power** 서버 위에서 돈다. 즉 IBM i는 **Power Systems 하드웨어 + IBM i OS** 조합이다. 2026년 기준으로 Power10 위에서 IBM i 7.5 / 7.6 등이 돈다.

왜 아직 130,000개 회사가 쓰나

- **단일 객체 모델** — 파일·프로그램·DB 객체가 같은 시스템 객체 모델 안에 있다. 운영이 단순하다.

- **TIMI (Technology Independent Machine Interface)** — 하드웨어 추상화. 새 Power 칩이 나와도 컴파일된 프로그램이 그대로 돈다.

- **내장 DB2 for i** — DB를 별도로 운영하지 않아도 된다.

- **운영 비용 낮음** — 메인프레임치곤. 한 대로 ERP·창고·재무를 다 돌릴 수 있다.

누가 쓰나

- 미국·유럽의 중견 제조업

- 일본의 식품·소매·물류 기업

- 한국에서도 일부 중견 제조·유통이 운영 (자세한 사이트 수는 비공개가 많음)

- 유럽 보험사

- 거래·소매 체인

ERP 패키지로는 **JD Edwards**, **Infor (구 SSA Global)**, **BPCS** 같은 것들이 IBM i 위에서 돈다.

RPG — IBM i의 주력 언어

IBM i의 주력 프로그래밍 언어는 **RPG (Report Program Generator)**다. 다음 장에서 깊게 본다.

5장 · COBOL — 추정 200~220B 라인 in production

COBOL은 1959년에 그레이스 호퍼(Grace Hopper)를 비롯한 위원회가 설계한 언어다. **이름의 뜻은 COmmon Business Oriented Language.** 60년이 넘은 언어가 여전히 200B 라인이 돈다.

왜 그렇게 많은가

- **금융 코어 시스템** — 거의 모든 대형 은행의 코어 뱅킹.

- **보험 클레임/계약 처리** — 자동차·생명·재해.

- **정부 세무·복지** — 미국 IRS, 한국 국세청 일부, 영국 HMRC 등의 일부 시스템.

- **항공 예약** — Sabre, Amadeus 같은 글로벌 분배 시스템(GDS)의 백본 중 일부가 여전히 COBOL.

- **소매·제조 ERP** — IBM i 위에서 RPG와 함께.

200B 라인이라는 수치는 **누적**이다. 매년 새로 쓰이는 COBOL은 줄지만, 지워지지도 않는다. 그래서 라인 수는 늘어난다.

COBOL 코드의 모양

IDENTIFICATION DIVISION.

PROGRAM-ID. INTEREST-CALC.

AUTHOR. YJ.

ENVIRONMENT DIVISION.

CONFIGURATION SECTION.

SOURCE-COMPUTER. IBM-Z.

OBJECT-COMPUTER. IBM-Z.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-PRINCIPAL PIC 9(7)V99 VALUE 1000000.00.

01 WS-RATE PIC 9(3)V99 VALUE 3.50.

01 WS-YEARS PIC 9(2) VALUE 5.

01 WS-INTEREST PIC 9(9)V99.

01 WS-TOTAL PIC 9(9)V99.

PROCEDURE DIVISION.

CALC-INTEREST.

COMPUTE WS-INTEREST = WS-PRINCIPAL * (WS-RATE / 100) * WS-YEARS.

COMPUTE WS-TOTAL = WS-PRINCIPAL + WS-INTEREST.

DISPLAY "Principal : " WS-PRINCIPAL.

DISPLAY "Interest : " WS-INTEREST.

DISPLAY "Total : " WS-TOTAL.

STOP RUN.

COBOL의 특징:

- **자연어처럼 보이는 문법** — `COMPUTE`, `DISPLAY`, `STOP RUN`. 영어 문장 같다.

- **고정 컬럼 포맷** (전통적) — 1-6 시퀀스, 7 표시자, 8-11 영역 A, 12-72 영역 B. 현대 COBOL은 free-format도 지원.

- **PIC 절** — 데이터의 모양(picture)을 정의. `PIC 9(7)V99`는 정수 7자리, 소수 2자리.

- **DIVISION 구조** — IDENTIFICATION, ENVIRONMENT, DATA, PROCEDURE 네 부분.

COBOL 표준의 흐름

- COBOL-60 → COBOL-68 → COBOL-74 → COBOL-85 (오랫동안 사실상 표준) → COBOL 2002 → COBOL 2014 → COBOL 2023.

- 현대 표준은 OOP, 유니코드, XML/JSON 처리도 지원한다.

COBOL 컴파일러

- **IBM Enterprise COBOL for z/OS** — z/OS의 정통.

- **IBM COBOL for AIX / Linux on Z**

- **Micro Focus Visual COBOL** (현재 OpenText 소유) — 윈도우/리눅스/메인프레임 호환.

- **GnuCOBOL** — 오픈소스. C로 트랜스파일. (다음 장에서 더)

6장 · RPG / JCL / CICS / DB2 z/OS / IMS / PL/I

COBOL은 메인프레임 언어 중 가장 유명할 뿐이다. 메인프레임 환경에는 다른 핵심 기술들이 있다.

RPG (Report Program Generator) — IBM i의 주력

이름은 "보고서 생성기"지만 현대 RPG는 범용 비즈니스 언어다. 흐름:

- **RPG II** (1960년대~)

- **RPG III** (System/38)

- **RPG IV / RPG/ILE** (AS/400 시대 ~ 현재)

- **Free-format RPG** (현대) — COBOL의 free-format처럼 컬럼 위치에 묶이지 않는 형태.

현대 free-format RPG 예시:

**free

ctl-opt main(main);

dcl-proc main;

dcl-s principal packed(9:2) inz(1000000);

dcl-s rate packed(5:2) inz(3.50);

dcl-s years packed(2:0) inz(5);

dcl-s interest packed(11:2);

dcl-s total packed(11:2);

interest = principal * (rate / 100) * years;

total = principal + interest;

dsply ('Total: ' + %char(total));

end-proc;

RPG는 **데이터베이스와 매우 단단하게 결합**되어 있다. SQL을 RPG 안에 인라인으로 박을 수 있는 **embedded SQL**이 표준이다.

JCL (Job Control Language)

z/OS에서 배치 작업을 정의하는 언어. 흔히 "안 좋은 옛날 셸스크립트"라고 불리지만, 메인프레임 운영의 핏줄이다.

//PAYROLL JOB (ACCT1234),'PAYROLL JOB',

// CLASS=A,MSGCLASS=X,REGION=4M

//STEP1 EXEC PGM=PAYCALC

//STEPLIB DD DSN=PROD.LOADLIB,DISP=SHR

//INPUT DD DSN=PROD.PAYROLL.MASTER,DISP=SHR

//OUTPUT DD DSN=PROD.PAYROLL.NEWRUN,DISP=(NEW,CATLG,DELETE),

// SPACE=(CYL,(10,5)),

// DCB=(LRECL=200,BLKSIZE=27800,RECFM=FB)

//SYSPRINT DD SYSOUT=*

JCL의 특징:

- **`//`로 시작하는 컬럼 위치 의존 문법.**

- **JOB → EXEC → DD** 카드 구조 — 작업 → 실행 단계 → 데이터셋.

- **DSN**으로 데이터셋 이름, **DISP**로 처분(SHR/MOD/NEW), **SPACE**로 할당.

- **STEPLIB**로 라이브러리, **SYSPRINT**로 로그 출력.

JCL은 운영 인력의 자산이다. 좋은 JCL은 잘못된 데이터셋 처분 한 줄로 회사를 살린다. 잘못된 JCL은 같은 줄로 회사를 파산시킨다 (`DISP=NEW,DELETE`로 프로덕션 마스터를 날리는 영원한 농담).

CICS (Customer Information Control System)

z/OS의 **트랜잭션 모니터**. 1969년부터 있다. CICS는:

- 단말기(전통적으로 3270)나 웹·모바일에서 들어온 요청을 받아,

- **트랜잭션** 단위로 비즈니스 로직(COBOL/PL/I 등)을 실행하고,

- 결과를 돌려준다.

- 분산 트랜잭션(2PC)을 처리하고, DB2/IMS와 통합된다.

현대 CICS는 **CICS Transaction Server**라는 이름으로 z/OS 위에 돈다. REST/JSON 인터페이스도 지원한다.

DB2 z/OS (= IBM Db2 for z/OS)

z/OS의 표준 관계형 DB. 다른 환경의 Db2 (LUW, for i)와 코드베이스가 다르다. 2026년 기준 **Db2 for z/OS V13** 이후 버전이 운영된다.

DB2 z/OS의 정체성:

- **트랜잭션 처리 + 데이터 웨어하우징**을 한 시스템에서.

- **펜타이드 캐시** + **Telum 칩-온-칩 가속** + Db2 AI Query Optimizer 등 — 메인프레임 하드웨어와 결합된 성능.

- **거대한 누적 데이터** — 페타바이트급 운영이 흔하다.

IMS (Information Management System)

1968년에 아폴로 프로그램을 위해 만들어진 **계층형 DB + 트랜잭션 모니터**. 관계형 DB(DB2)보다 오래됐고, 일부 큰 은행/항공/제조사는 여전히 IMS DB와 IMS TM을 운영한다. "오래됐다 = 안 쓴다"가 아니다 — 오래됐기 때문에 **검증됐고 빠르다**.

PL/I (Programming Language One)

1964년 IBM이 COBOL과 Fortran을 통합한다는 야심으로 만들었다. 결국 두 언어를 대체하진 못했지만, 일부 대형 시스템(특히 유럽 은행, 일부 운영체제 코드)에서 여전히 쓰인다.

TEST: PROC OPTIONS(MAIN);

DCL PRINCIPAL FIXED DEC(9,2) INIT(1000000);

DCL RATE FIXED DEC(5,2) INIT(3.50);

DCL YEARS FIXED BIN(15) INIT(5);

DCL INTEREST FIXED DEC(11,2);

DCL TOTAL FIXED DEC(11,2);

INTEREST = PRINCIPAL * (RATE / 100) * YEARS;

TOTAL = PRINCIPAL + INTEREST;

PUT SKIP LIST('Total: ', TOTAL);

END TEST;

PL/I는 COBOL보다 표현력은 높지만 학습 곡선도 더 가파르다. "있는 곳에는 있고, 새로 시작하진 않는다."

7장 · Fujitsu BS2000 / NEC ACOS / Unisys ClearPath — 비-IBM 메인프레임

"메인프레임 = IBM"이라는 인식이 흔하지만, 그건 정확하지 않다. 일본·유럽·미국 일부에는 IBM이 아닌 메인프레임이 여전히 돌고 있다.

Fujitsu BS2000 (일본/독일)

- 원래는 독일 **Siemens**의 **BS2000** 운영체제. 후에 Fujitsu가 Siemens의 컴퓨터 사업을 흡수.

- 현재는 Fujitsu의 **FUJITSU Server BS2000** 라인. 운영체제는 OSD/BC, BS2000/OSD 등으로 진화.

- 주로 독일·오스트리아·스위스의 정부·은행·보험에서 운영.

- COBOL, ASSEMBLER, C/C++ 지원. SQL DB(SESAM, UDS)도 있다.

- Fujitsu는 일본 내수용 메인프레임도 가지고 있다 (PRIMEFORCE 시리즈 등 — 시대에 따라 라인업이 변경되었으니 최신 명칭은 Fujitsu 공식 자료 확인).

NEC ACOS (일본)

- NEC의 **ACOS-4** 운영체제 위에서 도는 메인프레임. 일본 정부·금융권의 일부 코어가 NEC ACOS로 운영.

- 일본 우정사업본부, 일부 지방은행 등이 운영.

- 자체 COBOL, ADL(ACOS Data Language) 같은 4GL을 가지고 있다.

Unisys ClearPath

- 미국 **Unisys**의 메인프레임 라인. 두 가지 OS 패밀리:

- **MCP (Master Control Program)** — Burroughs B5000(1961)의 후계. 알골(ALGOL) 기반 OS라는 점에서 운영체제 역사의 화석.

- **OS 2200** — Sperry UNIVAC의 후계.

- ClearPath Dorado(2200 계열), ClearPath Libra(MCP 계열) 등으로 라인업이 정리되어 왔다.

- 최근 Unisys는 메인프레임 하드웨어를 일반 x86 서버 위에서 에뮬레이트하는 **ClearPath Forward** 모델로 이동.

- 미국 항공, 정부, 일부 은행에 여전히 운영.

요약 — 비-IBM 메인프레임의 공통점

| 항목 | 공통점 |

| --- | --- |

| 점유율 | IBM 대비 작지만 0이 아님 |

| 운영 | 국가별 거점이 있음 (일본·독일·미국) |

| 마이그레이션 압박 | IBM Z보다 더 큼. 후속 세대 보장이 약하기 때문 |

| 현대화 경로 | 보통 IBM Z로 이전하거나, Linux/클라우드로 |

8장 · AWS Mainframe Modernization

2022년 AWS는 **AWS Mainframe Modernization (AWS MMA)** 서비스를 출시했다. 메인프레임 워크로드를 AWS 위로 옮기는 것을 돕는 매니지드 서비스다.

두 가지 패턴

AWS MMA가 공식적으로 미는 두 가지 마이그레이션 전략:

1. **Replatform (재플랫폼)** — COBOL을 그대로 두고, 메인프레임 환경만 다른 곳(AWS의 컨테이너/EC2)으로 옮긴다. AWS는 **Micro Focus** 런타임(현재 OpenText)을 활용한 옵션을 제공한다.

2. **Refactor (재팩토링)** — COBOL을 Java로 자동 변환한다. AWS는 **Blu Age**를 인수해서 통합했다. Blu Age는 COBOL을 모던 Java/Spring/Angular로 변환해주는 도구.

Replatform이 더 흔하다

대부분의 큰 마이그레이션은 Replatform이다. 이유:

- **코드를 안 건드린다** — 비즈니스 로직 리스크가 없다.

- **메인프레임 운영비를 줄인다** — IBM 라이선스/MIPS 비용을 AWS 컴퓨트 비용으로 대체.

- **현대 도구 통합** — CI/CD, 컨테이너, 옵저버빌리티.

하지만 함정도 있다.

- **데이터 마이그레이션** — DB2 z/OS → Aurora/RDS PostgreSQL. 쉽지 않다. 트리거·저장프로시저·SQL 방언 차이가 모두 나타난다.

- **트랜잭션 모니터** — CICS의 정확한 행동을 모두 재현하는 게 어렵다.

- **MIPS 가격 비교** — "절감"이 항상 진실은 아니다. 동등한 가용성/성능을 맞추면 비슷한 비용이 나오기도 한다.

흐름

[메인프레임] [AWS]

COBOL 소스 ────────▶ COBOL 소스 (또는 Java 변환)

JCL 배치 ────────▶ AWS Batch / EventBridge Scheduler

CICS ────────▶ Mainframe Modernization Runtime

DB2 z/OS ────────▶ Aurora PostgreSQL / DB2 LUW

VSAM ────────▶ DynamoDB / S3 / Aurora

IMS ────────▶ 별도 매핑 (가장 어려움)

AWS는 마이그레이션 평가, 분석, 컷오버까지를 매니지드로 제공한다. 메인프레임 베테랑 + AWS 솔루션 아키텍트의 조합이 필요하다.

9장 · Micro Focus → OpenText (2022) → Visual COBOL

메인프레임 현대화의 중심에 오랫동안 **Micro Focus**가 있었다. 영국에 본사를 둔 회사로, COBOL 컴파일러·런타임의 최대 공급자 중 하나.

2022년 — OpenText 인수

2022년, 캐나다의 정보관리 회사 **OpenText**가 Micro Focus를 약 60억 달러에 인수했다. 인수가 마무리되면서 Micro Focus 브랜드는 점진적으로 OpenText 브랜드로 통합 중이다.

Visual COBOL — 주력 제품

Micro Focus(현 OpenText)의 주력 제품은 **Visual COBOL**이다. 이게 하는 일:

- 메인프레임에서 도는 COBOL을 **윈도우/리눅스/.NET/JVM 위에서도 실행**할 수 있게 한다.

- **Visual Studio / IntelliJ / Eclipse** 통합 — 현대 IDE 안에서 COBOL을 편집·디버그·리팩토링.

- **CICS 흉내** — 동등한 트랜잭션 환경을 제공해 메인프레임 CICS 앱을 그대로 옮겨오게 한다.

- **JCL 변환** — 메인프레임 JCL을 비-메인프레임 환경에서 실행 가능하게.

Enterprise Server / Enterprise Developer

OpenText의 메인프레임 관련 라인은 보통:

- **Enterprise Developer** — 개발자 IDE + 컴파일러.

- **Enterprise Server** — 프로덕션 런타임(CICS-호환, IMS-호환 환경 등).

- **AppMaster Builder, Enterprise Test Server, Modernization Workbench** 등 보조 도구.

AWS Mainframe Modernization의 Replatform 옵션 일부는 이 OpenText 스택 위에서 돈다.

의미

OpenText는 메인프레임을 **죽이지 않는다.** 그들은 메인프레임 코드를 **다른 환경에서 계속 실행**할 수 있게 하는 게 사업이다. 즉 그들의 비즈니스 모델은 "COBOL이 2030년대에도 살아있다"는 명제 위에 있다.

10장 · IBM watsonx Code Assistant for Z (2023.8) — AI COBOL 현대화

2023년 8월, IBM은 **watsonx Code Assistant for Z**를 발표했다. 메인프레임 COBOL을 Java로 변환하는 것을 돕는 AI 도구.

무엇을 하나

- **COBOL → Java 변환** — 자동/반자동. 비즈니스 로직을 모던 Java로 옮긴다.

- **코드 이해 (Code Explanation)** — 1980년대에 쓰인 COBOL 코드를 LLM이 설명해준다. "이 모듈은 무엇을 하는가" 같은 자연어 질의.

- **테스트 생성** — 기존 COBOL에 대한 테스트 케이스 생성.

- **점진적 변환** — 전부 한 번에가 아니라, 모듈 단위·서비스 단위로.

작동 모델

watsonx Code Assistant for Z는 LLM(IBM의 `granite` 코드 모델 패밀리 기반) + 메인프레임 전용 도메인 지식의 조합이다. 즉 그냥 ChatGPT가 아니라, **COBOL/JCL/CICS의 패턴을 학습한 모델**이 백엔드에 있다.

한계와 현실

IBM의 마케팅을 액면 그대로 받아들이면 안 된다. 실제로:

- **자동 변환된 Java는 검토가 필요하다** — LLM이 생성한 코드는 항상 그렇다.

- **비즈니스 로직의 미묘함** — COBOL의 십진수 산술(PIC 9V99), EBCDIC, 표시자(indicator)의 의미 — 이런 게 손실 없이 옮겨지지 않을 수 있다.

- **데이터 마이그레이션은 별 문제** — 코드만 옮긴다고 끝나지 않는다.

그러나 **출발점**으로서는 가치가 있다. 0에서 시작하는 게 아니라, AI가 만든 첫 패스 위에서 사람이 다듬는다.

2024~2025년의 흐름

- IBM은 watsonx Code Assistant 라인을 일반화 — Code Assistant for Java, for Ansible 등도 출시.

- IBM Z용은 점점 더 큰 케이스에 적용 — 한 보험사가 800만 줄 COBOL을 단계적으로 평가.

- 경쟁자: Amazon Q Developer (구 CodeWhisperer)의 메인프레임 지원, GitHub Copilot의 COBOL 지원.

11장 · GitHub Copilot COBOL 지원

**GitHub Copilot**은 2021년 GA되면서 처음에는 자바스크립트·파이썬·타입스크립트를 중심으로 알려졌다. 시간이 지나면서 다양한 언어 지원이 확장되었고, **COBOL 자동완성도 지원**한다.

실제 경험

COBOL에서 Copilot이 어떻게 도와주는가:

- **PIC 절 자동완성** — 변수 이름을 입력하면 `PIC 9(7)V99` 같은 PICTURE 절을 추정.

- **PARAGRAPH 이름 + 흐름 제안** — 다음에 와야 할 PERFORM·MOVE·COMPUTE를 추정.

- **JCL 생성** — 자연어 주석에서 JCL 스니펫.

- **DB2 임베디드 SQL** — `EXEC SQL ... END-EXEC` 블록 자동완성.

한계

- **80-컬럼 포맷 처리** — 전통 컬럼-기반 COBOL은 LLM이 잘 못 다룬다. Free-format에서 더 잘 작동.

- **회사 코딩 표준** — Copilot은 일반 패턴을 안다. 회사 내부 명명규칙·표준은 모른다.

- **테스트 데이터 의존성** — 비즈니스 데이터의 의미를 모른다.

Copilot vs watsonx Code Assistant for Z

- **Copilot** — 범용 코딩 보조. COBOL을 지원하지만, 전문 도구는 아니다.

- **watsonx CA for Z** — 메인프레임 전용. 코드 변환·이해에 특화.

둘은 경쟁자라기보다 **다른 층위**다. 일상 코딩에 Copilot, 큰 변환 프로젝트에 watsonx.

12장 · zCX (z/OS 컨테이너) + Linux on Z + LinuxONE

메인프레임을 클라우드 시대로 끌고 오는 또 다른 흐름은 **컨테이너와 리눅스**다.

zCX (z/OS Container Extensions)

2019년에 도입된 z/OS의 기능. **z/OS 안에서 도커 컨테이너를 실행**한다. z/OS 안에서 Linux on Z 환경을 내장 가상머신처럼 띄우고, 그 안에서 컨테이너를 굴린다.

왜 이게 중요한가:

- 메인프레임의 데이터(Db2 z/OS, VSAM)에 **저지연**으로 접근 가능.

- **Kafka, Elastic, Grafana** 같은 모던 스택을 메인프레임 옆에 둘 수 있다.

- 트랜잭션 백본을 안 건드리고 **모던 인터페이스**를 입힐 수 있다.

Linux on Z

z 하드웨어 위에서 직접 **리눅스를 굴리는** 모드. z/OS와 같이 LPAR로 분할해서 한 메인프레임에 여러 환경을 동시에 운영.

- 주요 배포판: RHEL on Z, SUSE on Z, Ubuntu on Z.

- 메인프레임의 신뢰성을 리눅스 워크로드에 부여.

- 단일 시스템 안에서 수백~수천 개 리눅스 VM/컨테이너를 운영하는 패턴.

IBM LinuxONE

**Linux 전용 메인프레임**. 하드웨어는 IBM Z와 같지만, **z/OS는 안 깐다.** 즉 "메인프레임 신뢰성 + 리눅스 전용". 주로:

- 대규모 결제 처리(블록체인 노드 호스팅 포함).

- 데이터 보호가 중요한 환경(IBM Cloud Hyper Protect와 결합).

- 친환경 데이터센터(같은 워크로드를 x86보다 적은 전력으로).

IBM Cloud Hyper Protect

IBM Cloud의 **Confidential Computing** 라인. 메인프레임 보안 기술(Crypto Express, Secure Service Container)을 클라우드 서비스로 제공. 키 관리, 신뢰 가상 서버, DB 등을 메인프레임-등급 보안으로 호스팅.

13장 · Hercules + GnuCOBOL — 오픈 에뮬레이션

집에서 메인프레임을 만져볼 수 있는가? 그렇다.

Hercules — System/370 / ESA/390 / z/Architecture 에뮬레이터

오픈소스로 공개된 **메인프레임 에뮬레이터**. 일반 PC/맥/리눅스 위에서 z/Architecture를 흉내 낸다. 단:

- **상용 z/OS는 라이선스가 필요** — 따라서 일반인이 z/OS를 합법적으로 돌리기는 어렵다.

- **MVS 3.8j** 같은 옛 IBM OS는 퍼블릭 도메인 — 1970~80년대 메인프레임 체험은 가능.

- **Linux on Z** — 합법적으로 무료. RHEL/SUSE/Ubuntu의 s390x 빌드를 Hercules 위에서 굴릴 수 있다.

GnuCOBOL

오픈소스 COBOL 컴파일러. COBOL을 **C로 트랜스파일**한 뒤 일반 C 컴파일러로 빌드한다.

설치 (예: macOS Homebrew)

brew install gnu-cobol

컴파일

cobc -x -o interest interest.cob

실행

./interest

- **COBOL 85 / 2002 / 2014의 큰 부분 지원.**

- IBM OS 종속 기능(CICS, DB2 z/OS 등)은 지원 안 함.

- 학습용·교육용·소규모 운영용으로 적합.

학습 경로

- COBOL을 처음 배운다면: **GnuCOBOL + VS Code (또는 Eclipse)**로 시작.

- 메인프레임 체험을 원한다면: **Hercules + MVS 3.8j** + IBM **Z Trial** 또는 **IBM Z 학습 프로그램**.

- IBM은 학생/입문자를 위한 **IBM Z Xplore**, **Master the Mainframe** 같은 무료 학습 프로그램을 운영해왔다 (이름과 내용은 시기에 따라 변경됨 — IBM 공식 페이지에서 확인).

14장 · 현대화 패턴 — Strangler Fig / 안티-corruption layer

레거시 시스템을 갈아치우는 패턴은 사실 메인프레임만의 이야기가 아니다. 다음 두 가지가 가장 유명하고 가장 실용적이다.

Strangler Fig 패턴 (Martin Fowler)

이름은 호주의 무화과 나무(strangler fig) — 다른 나무를 감싸며 자라다가 결국 원래 나무를 죽이고 자기가 대체한다. 마틴 파울러가 2004년 글에서 시스템 리뉴얼에 이 비유를 쓴 게 시작이다.

전략:

1. 레거시 시스템 앞에 **프록시/팩사드**를 둔다.

2. 새 요청 중 일부를 **새 시스템**으로 라우팅한다.

3. 점진적으로 더 많은 요청을 새 시스템으로.

4. 어느 날, 레거시는 0% 트래픽이 된다. 그제서야 제거.

[클라이언트] ──▶ [팩사드 / 프록시] ──▶ [레거시 메인프레임]

│

└─────────────▶ [새 마이크로서비스]

(점점 더 많은 라우팅)

장점:

- **빅뱅 마이그레이션 위험 없음** — 한 번에 100% 옮기지 않는다.

- **롤백 가능** — 새 시스템이 망가지면 라우팅을 되돌리면 된다.

- **점진적 학습** — 새 시스템의 운영 노하우를 트래픽을 늘리면서 쌓는다.

단점:

- **수년이 걸린다** — 빠른 답이 아니다.

- **이중 운영 비용** — 둘을 동시에 굴려야 한다.

- **데이터 동기화** — 두 시스템이 같은 데이터를 봐야 하는 동안 동기화 비용이 든다.

Anti-corruption Layer (Eric Evans, DDD)

도메인 주도 설계(DDD)의 패턴 중 하나. 레거시 시스템과 새 시스템 사이에 **번역 계층**을 둔다.

[새 도메인 모델] ──▶ [Anti-corruption Layer] ──▶ [레거시 모델]

(깨끗한 모델) (변환/매핑/캡슐화) (오래된 모델)

목적:

- 레거시의 이상한 개념(예: 60년 된 코드의 비즈니스 가정)이 새 시스템으로 **새지 않게** 한다.

- 새 시스템은 깨끗한 자체 모델을 가진다.

- 변환 비용은 한 곳에 집중.

Strangler와 Anti-corruption은 **같이 쓴다.** Strangler가 라우팅 패턴이라면, Anti-corruption은 라우팅 너머의 도메인 모델 보호 장치다.

실전 — 어디서부터 시작하나

1. **사각형 그리기** — 메인프레임 위에서 도는 모듈을 도메인별로 묶는다.

2. **변경 빈도 + 위험도**로 우선순위 — 자주 바뀌고 위험한 것부터 분리.

3. **읽기부터 분리** — 조회 트래픽을 새 DB(읽기 전용 복제)로 옮기는 게 가장 쉽다.

4. **쓰기를 천천히** — 듀얼 라이트(레거시 + 새 시스템)를 거쳐 마지막에 새 시스템만.

5. **모니터링·관측** — 두 시스템의 응답을 비교(shadow traffic).

6. **롤백 플랜** — 항상.

15장 · 한국 금융권 — KB / 신한 / 우리 / 하나 / 기업 / 농협 메인프레임

한국 금융권의 메인프레임 운영 현황은 일부 공개·일부 추정이다. 2024~2025년 기준 공개된 정보·업계 추정에 의하면 대략 다음과 같다.

(이하 일반에 알려진 흐름의 정리이며, 각 은행의 정확한 시스템 구성은 비공개 부분이 많다. 일부는 추정.)

큰 그림

- **5대 시중은행 + NH농협 + IBK기업은행** — 대부분 IBM Z(혹은 그 전 세대 메인프레임)를 차세대 코어와 함께 운영해왔다.

- **차세대 사업** — 2000년대 후반~2010년대에 큰 차세대 사업이 한 차례 진행되었고, 메인프레임 의존도를 줄이는 흐름과 유지하는 흐름이 공존.

- **2020년대 흐름** — 클라우드 전환 검토, 일부 시스템의 부분 다운사이징, 인공지능 결합 등.

은행별 일반적 흐름 (공개·언론 보도 기반의 일반론)

| 은행 | 흐름 (일반론) |

| --- | --- |

| KB국민 | 메인프레임 + 자체 차세대 시스템. 클라우드 전환 적극 검토. |

| 신한 | 메인프레임 운영. AI 결합 사업 적극. |

| 우리 | 차세대 시스템 사업 진행. |

| 하나 | 자체 차세대 시스템 + 일부 메인프레임. |

| IBK기업 | 메인프레임 운영. |

| NH농협 | IBM Z 운영. 농협의 규모상 가장 큰 메인프레임 사용자 중 하나. |

(주의: 위 표는 일반적으로 알려진 흐름의 정리이며, 각 은행의 정확한 시스템 구성은 비공개 부분이 많다. 추정이 포함된다.)

한국 메인프레임 인력 시장

- 60~70대 베테랑이 핵심 운영을 담당하는 케이스가 많다.

- 신규 인력 진입은 적다 — 대학에서 메인프레임을 가르치는 곳이 거의 없음.

- 그래서 **연봉이 오른다** — COBOL/RPG/JCL을 알고 한국어가 되는 사람은 사실상 부르는 게 값.

- IBM Korea의 **Master the Mainframe** / **Z Xplore** 한국 프로그램이 신규 유입을 도왔다.

한국 비-금융

- **공공·세무** — 일부 시스템에서 메인프레임 운영.

- **항공** — 대한항공/아시아나 등의 일부 시스템.

- **통신** — 일부 백본.

- **제조·유통** — IBM i 운영 사이트가 다수 있는 것으로 알려짐.

16장 · 일본 — 三菱UFJ / SMBC / Mizuho / NTT Data / Fujitsu BS2000

일본은 메인프레임의 또 다른 거점이다. 그리고 한국과 달리, **일본 자체의 메인프레임 산업**이 있다 (Fujitsu, NEC, Hitachi). 이게 일본의 독특한 점이다.

3대 메가뱅크 일반론

(공개 자료·일반적으로 알려진 흐름 기반의 정리이며, 정확한 시스템 구성은 비공개가 많다.)

| 은행 | 일반적 흐름 |

| --- | --- |

| 三菱UFJ (MUFG) | 메인프레임 운영. 2010년대 큰 통합 후 안정 운영. |

| SMBC (三井住友) | 메인프레임 + 자체 차세대. |

| Mizuho (みずほ) | 2002년·2011년·2021년의 시스템 장애로 유명. 그 이후 안정성 확보에 집중. |

NTT Data

일본 SI 시장의 핵심. **공공·금융 코어 시스템의 운영·구축 파트너**. NTT Data는 메인프레임 마이그레이션·운영 위탁을 대규모로 수행한다.

Fujitsu — 자체 메인프레임 보유

- **FUJITSU BS2000** — 독일에서 시작된 메인프레임. 유럽 + 일본의 일부에서 운영.

- 일본 내수용 메인프레임 라인업 (시기에 따라 명칭과 라인업이 변경되어 왔으며, 최신 명칭은 Fujitsu 공식 자료에서 확인).

- Fujitsu는 2020년대에 메인프레임 사업의 일부 정리를 발표 — 신규 메인프레임 개발 중단, x86 기반의 GS / PRIMERGY 라인으로 이전하는 방향성 등이 보도되었다(자세한 일정과 범위는 Fujitsu 공식 발표 기준).

- 이 흐름은 일본 메인프레임 시장에 상당한 영향을 준다.

NEC ACOS

- 일본 정부, 일부 지자체, 일부 은행이 운영.

- NEC도 메인프레임 사업의 점진적 변환을 추진.

Hitachi

- 과거 일본 메인프레임의 한 축이었음. 현재는 메인프레임 자체보다 **시스템 통합·운영 서비스**가 중심.

일본 인력 시장

- 한국과 비슷하게 베테랑 의존 + 신규 유입 부족.

- 일본은 NTT Data·Fujitsu·NEC·Hitachi·IBM Japan 같은 큰 SI 회사가 인력을 흡수하는 구조라, 인력 풀의 회전이 회사 단위로 일어난다.

17장 · 누가 COBOL을 배워야 하나 — 금융 / 보험 / 정부 / 학술

당신이 2026년에 새 언어를 배운다면, COBOL이 1순위는 아닐 것이다. 그러나 **특정한 사람들에게는 1순위가 될 수 있다.** 누가, 왜.

좋은 후보

- **금융권 입사를 고려하는 사람** — 은행 IT, 보험 IT는 메인프레임 운영을 알면 매우 유리하다. 대체 인력이 없다.

- **공공·세무·복지 IT** — 한국·일본·미국 모두 정부 시스템의 일부가 COBOL.

- **정보시스템 컨설팅** — 마이그레이션 프로젝트는 향후 10~20년 시장.

- **학술적 호기심** — 60년 된 언어가 어떻게 살아남는가 자체가 컴퓨터 과학 사례 연구.

- **연봉이 우선** — 단위시간당 단가가 매우 높을 수 있다 (사람이 적기 때문).

별로 후보 아님

- **2026년에 첫 프로그래밍 언어를 정하는 사람** — Python/JavaScript/Go가 낫다.

- **창업가** — 새 제품을 COBOL로 짓지 않는다.

- **AI/ML 엔지니어** — Python 생태계가 그 자리.

실제 학습 경로

1. **GnuCOBOL** 설치 — 로컬에서 COBOL 컴파일·실행.

2. **COBOL 기초** — `IDENTIFICATION / ENVIRONMENT / DATA / PROCEDURE DIVISION`. PIC 절. PERFORM.

3. **파일 처리** — 시퀀셜·인덱스·상대 파일.

4. **DB 통합** — Embedded SQL.

5. **JCL** — 메인프레임 환경에서 작업을 어떻게 돌리는지.

6. **CICS 기초** — 트랜잭션 처리.

7. **메인프레임 환경 체험** — IBM Z Xplore / Master the Mainframe (이름·운영 형태는 시기에 따라 다를 수 있음 — IBM 공식 페이지 확인).

8. **현대화 도구** — Visual COBOL, watsonx Code Assistant for Z 데모/평가판.

시간 투자

- 기초 COBOL — 100~200시간.

- 실전 메인프레임 운영(JCL/CICS/DB2 z/OS) — 1~2년의 현장 경험.

언어 자체는 어렵지 않다. **환경**이 어렵다. 그리고 그게 진입 장벽이고, 동시에 기회다.

에필로그 — 거대한 거인은 천천히, 매우 천천히 움직인다

메인프레임은 죽지 않는다. 적어도 2030년대 중반까지는.

| 시점 | 이벤트 |

| --- | --- |

| 2022.4 | IBM z16 출시 (Telum I, 양자내성 암호) |

| 2023.8 | IBM watsonx Code Assistant for Z 발표 |

| 2022 | OpenText, Micro Focus 인수 (Visual COBOL의 새 주인) |

| 2022 | AWS Mainframe Modernization GA |

| 2025.9 | IBM z17 출시 (Telum II) |

| 2026~ | AI 결합 현대화의 본격 확산 단계 |

큰 그림

- **하드웨어는 진화** — Telum II가 칩-온-칩 AI를 강화. z17은 z16의 자연스러운 후속.

- **소프트웨어는 보존** — 200B 라인 COBOL은 사라지지 않는다. 옮겨질 뿐이다.

- **AI는 가속기** — watsonx, Copilot, Amazon Q가 현대화 일을 사람만 하던 시대보다 빠르게 만든다.

- **클라우드는 옵션** — AWS MMA, IBM Cloud Hyper Protect, Linux on Z, LinuxONE.

- **운영은 여전히 사람** — 좋은 메인프레임 운영자는 회사를 살린다.

다음 글 예고

후보:

- **JCL 실전 — 첫 줄부터 SYSPRINT까지**

- **COBOL → Java 변환 사례 — watsonx Code Assistant for Z 데모 따라 하기**

- **DB2 z/OS와 PostgreSQL의 차이 — 마이그레이션이 어려운 이유**

> "오래된 코드는 어딘가 살아있다. 우리는 그것을 죽이는 게 아니라, 옆에서 천천히 키운 새 코드가 자리를 차지하게 한다." — Strangler Fig를 만든 그 비유처럼.

— 메인프레임 2026, 끝.

참고 / References

- [IBM Z 공식](https://www.ibm.com/z)

- [IBM z17 발표 자료 (IBM Newsroom)](https://newsroom.ibm.com/)

- [IBM z16 — Telum 프로세서](https://www.ibm.com/products/z16)

- [IBM i 공식](https://www.ibm.com/products/ibm-i)

- [IBM Db2 for z/OS](https://www.ibm.com/products/db2/zos)

- [IBM CICS Transaction Server](https://www.ibm.com/products/cics-transaction-server)

- [IBM IMS](https://www.ibm.com/products/ims)

- [IBM Enterprise COBOL for z/OS](https://www.ibm.com/products/enterprise-cobol-zos)

- [IBM watsonx Code Assistant for Z](https://www.ibm.com/products/watsonx-code-assistant-z)

- [IBM LinuxONE](https://www.ibm.com/linuxone)

- [IBM Cloud Hyper Protect](https://www.ibm.com/cloud/hyper-protect-services)

- [Linux on Z (IBM)](https://www.ibm.com/it-infrastructure/z/os/linux)

- [AWS Mainframe Modernization](https://aws.amazon.com/mainframe-modernization/)

- [OpenText (Micro Focus 인수)](https://www.opentext.com/)

- [Visual COBOL — OpenText](https://www.opentext.com/products/visual-cobol)

- [Fujitsu BS2000](https://www.fujitsu.com/global/products/computing/servers/mainframe/bs2000/)

- [NEC ACOS](https://jpn.nec.com/acos/)

- [Unisys ClearPath](https://www.unisys.com/solutions/clearpath-forward/)

- [GitHub Copilot](https://github.com/features/copilot)

- [Hercules emulator](https://www.hercules-390.org/)

- [GnuCOBOL](https://gnucobol.sourceforge.io/)

- [Martin Fowler — StranglerFigApplication](https://martinfowler.com/bliki/StranglerFigApplication.html)

- [Eric Evans — Domain-Driven Design (Anti-corruption Layer)](https://www.domainlanguage.com/ddd/)

- [COBOL 표준 (ISO/IEC 1989)](https://www.iso.org/standard/74527.html)

- [IBM Z Xplore / Master the Mainframe (학습 프로그램)](https://www.ibm.com/community/z/)