Skip to content
Published on

메인프레임 & 레거시 시스템 2026 — IBM z17 (2025.9) / IBM i / COBOL / RPG / JCL / CICS / watsonx Code Assistant for Z 심층 가이드

Authors

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

"메인프레임은 죽었다"라는 헤드라인은 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 ITelum 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 (일본/독일)

  • 원래는 독일 SiemensBS2000 운영체제. 후에 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 임베디드 SQLEXEC 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.4IBM z16 출시 (Telum I, 양자내성 암호)
2023.8IBM watsonx Code Assistant for Z 발표
2022OpenText, Micro Focus 인수 (Visual COBOL의 새 주인)
2022AWS Mainframe Modernization GA
2025.9IBM 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