하나의 숨겨진 REDEFINES 링크가 강조된, 의존성 지도로 변환되는 COBOL 코드.

Artificial IntelligenceFintechTechnology

완벽하게 컴파일된 COBOL 마이그레이션이 그래도 원장을 무너뜨린 이유

Ashutosh Singhal 2026년 5월 7일13 min

코드는 완벽했다. 그게 바로 문제의 전부였다.

한 전신 송금 프로그램이 COBOL에서 Java로 번역되어 있었다. 컴파일도 됐다. 단위 테스트도 통과했다. 우리가 실수를 잡으려고 세워둔 모든 관문을 통과했다. 그런데 사용자 인수 테스트(UAT)에서, 맨 첫 거래가 데이터베이스의 정합성 검사에 걸렸고 전체가 무너져 내렸다.

부검은 필요 이상으로 오래 걸렸다. Java 코드에서 겉보기에 잘못돼 보이는 것이 전혀 없었기 때문이다. 문제의 원인은 TRN-LIMIT이라는 변수였다. 번역 도구는 이를 평범한 숫자로 읽고 표준 정수 타입을 부여했다. 하지만 TRN-LIMIT은 도구가 들여다보던 곳에서는 정의된 적이 없었다. 그것은 카피북 — 공유 헤더 파일 — 에 선언되어 있었는데, 그 카피북은 실행 체인상 수천 줄 앞에서 끌어들여진 것이었고, 그 카피북에는 REDEFINES 절(clause)이 들어 있었다. 이는 완전히 다른 곳에서 설정된 플래그에 따라 같은 메모리 슬롯을 두 개의 전혀 다른 데이터 타입으로 읽을 수 있게 해주는 COBOL 구문이다. 메인프레임에서 그 주소에는 packed decimal이 담겨 있었다. 새 Java 코드는 손상된 이진 데이터를 데이터베이스 컬럼에 써넣었고, 원장의 참조 무결성이 무너졌다.

코드는 문법적으로 흠잡을 데 없었다. 실패는 맥락에서 비롯됐다. 도구는 자신의 시야 밖에 존재하는 의존성을 놓쳤다 — 그리고 레거시 COBOL 현대화에서 돈이 사라지는 방식은 거의 항상 이것이다.

현대화 프로젝트는 보통 눈에 보이는 코드 때문에 죽지 않는다. 도구가 볼 수 없었던 코드 때문에 죽는다.

이것은 더 나은 번역이 해답이라고 믿기를 멈춘 이유와, 그 대신 우리가 Veriprajna에서 만든 것에 대한 이야기다.

"COBOL을 붙여넣으면 Java가 나온다"는 왜 항상 시연은 잘될까?

지난 2년 동안 메인프레임 현대화 회의에 한 번이라도 앉아본 적이 있다면, 이런 제안을 들어봤을 것이다: COBOL을 붙여넣으면 Java를 돌려받는다. 이것이 솔깃한 이유는 시연이 항상 잘되기 때문이다. 누군가 깔끔한 200줄짜리 프로그램을 집어넣으면, 모델이 깨끗하고 관용적인 Java를 반환하고, 회의실에 있는 모두가 안도의 한숨을 내쉰다. 드디어.

나도 한동안은 그렇게 믿었다. 우리 팀이 처음 이 문제에 달려들었을 때, 우리는 당연한 일을 했다 — 번역을 더 낫게 만들려고 했다. 모델에 더 많은 맥락을 넣어주고, COBOL의 특이점에 맞게 튜닝하고, 출력 품질을 벤치마킹했다. 심지어 이 목적을 위해 특별히 만들어진 XMainframe이라는 파인튜닝된 오픈 모델도 있는데, COBOL 작업에서 범용 코드 모델보다 약 30% 높은 점수를 낸다. 번역은 더 깨끗해졌다. Java는 더 읽기 쉬워졌다.

그런데도 UAT에서 여전히 깨졌다. 그 전신 송금 프로그램을 가라앉혔던 바로 그런 종류의 숨은 의존성에서, 몇 번이고 되풀이해서. 그달에 나는 우리가 엉뚱한 것을 다듬고 있었음을 깨달았다. 번역의 품질은 애초에 병목이 아니었다. 컴파일되는 코드는 쉬운 부분이다. 어려운 부분은 도구가 볼 수 없는 코드다.

이를 둘러싼 숫자는 잔혹하고 일관적이다: 메인프레임 현대화 프로젝트의 70~80%가 목표 달성에 실패한다. 70%가 지연되는 게 아니라 — 70%가 실패한다. 흔한 진단은 과소평가된 테스트나 지저분한 데이터 마이그레이션을 탓하는데, 그것들도 실제 원인이다. 하지만 거의 모든 경우의 밑바닥에는 내가 방금 실시간으로 지켜본 것과 똑같은 근본 원인이 있다: 도구들은 코드베이스를 변환해야 할 텍스트로 취급하지만, 실제로 그것은 이해해야 할 위상(topology)이다.

"COBOL을 붙여넣으면 Java가 나온다"가 볼 수 없는 것

번역기가 놓치는 카피북 체인, packed-decimal 연산, JCL 작업 네트워크를 보여주는 세 개의 패널.

맥락적 실명(失明)을 찾기 시작하면, 그것이 어디에나 있다는 걸 보게 된다. 세 가지 패턴이 우리를 가장 자주 무너뜨렸고, 그중 어느 것도 번역기가 응시하는 소스 파일에서는 보이지 않는다.

이미 설명한 카피북 문제부터 보자. 하나의 COBOL 프로그램이 마흔 개가 넘는 카피북을 참조할 수 있고, 그 카피북들은 또 다른 카피북을 포함하므로, 변수의 실제 정의가 포함 체인의 여러 단계 깊은 곳에 자리할 수 있다. 텍스트 기반 도구는 눈앞의 문장을 읽고 타입을 추론한다. packed-decimal 필드에서 그 추론이 조용히 틀렸다는 것을 알아챌 방법이 없다.

그다음은 산술 연산이다. COBOL의 COMP-3 packed decimal은 Java에 네이티브 대응물이 없다. double을 쓰면 돈을 움직이는 시스템에 방금 부동소수점 반올림을 끌어들인 것이 된다. 심지어 BigDecimal조차도, 올바른 도구임에도, 기본적으로는 COBOL과 일치하지 않는다 — 반올림 모드를 명시적으로 HALF_EVEN으로 고정해야 COBOL의 ROUNDED 절(clause)을 반영할 수 있다. 잘못하면 거래당 1페니씩 어긋난다. 그 1페니가 수백만 건의 거래에 걸쳐 누적되어, 몇 주 뒤 대사(reconciliation) 보고서가 아무도 설명할 수 없는 차이를 짚어내게 된다.

거의 모두가 잊어버리는 패턴이 실제로 프로덕션을 무너뜨리는 그것이다: 당신의 COBOL은 혼자 돌아가지 않는다. 스케줄러 — CA-7 또는 TWS — 가 2천에서 5천 개 사이의 배치 작업을, 그 사이로 엮인 의존성 체인과 함께 조율한다. 작업 A가 새벽 1시에 데이터셋을 쓰고 작업 B가 새벽 2시에 그것을 읽는다. COBOL의 모든 줄을 완벽하게 마이그레이션하고도 자정에 은행을 멈춰 세울 수 있다. 아무도 작업 네트워크를 매핑하지 않았기 때문이다. 프로덕션 그래프는 애초에 소스 코드에 없었다. 그것은 JCL 안에 있었다.

새벽 2시에 프로덕션을 무너뜨리는 작업은 결코 당신이 들여다보던 그 작업이 아니다.

이것이 내가 말하는 위상(topology)이다. 실제로 당신의 사업을 돌아가게 하는 산출물은 관계의 그물망이다 — 프로그램, 카피북, 데이터셋, 예약된 작업, DB2 테이블, CICS 트랜잭션 — 그리고 COBOL 소스는 그중 한 가닥일 뿐이다.

내가 번역기를 신뢰하기를 멈추고 지도를 그리기 시작한 이유

UAT에서 실패하는 번역 우선 방식 대 성공하는 지도 우선 의존성 그래프 방식.

우리에게 전환점은 지도가 곧 제품이라고 결정한 것이었다.

우리는 단 한 줄을 번역하기 전에, 코드베이스 전체의 지식 그래프를 구축한다 — 모든 프로그램, 모든 카피북 엣지, 모든 JCL 의존성, 모든 데이터셋 인계, 모든 DB2 접점 — 그리고 소스 파일이 숨기는 이행적(transitive) 관계를 풀어낸다. 한 프로그램이 카피북 엣지를 마흔 개 넘게 갖고 있고 그중 하나가 REDEFINES를 두 모듈 떨어진 곳에 담고 있음을 볼 수 있으면, TRN-LIMIT 재앙은 그저 일어나지 않는다. Java를 한 글자라도 입력하기 전에 그 필드가 packed decimal이라는 것을 알았기 때문이다.

이것이 나머지 업계가 파는 것과 왜 다른지 정확히 짚고 넘어가고 싶다. 이 분야는 붐비고, 그중 대부분은 자기가 해결하는 부분에 대해서는 진짜로 훌륭하기 때문이다.

IBM의 watsonx Code Assistant for Z는 가장 진지한 기존 강자다 — 오케스트레이션, 아키텍처, 코드 에이전트를 갖춘 에이전트형 시스템으로, COBOL-투-Java는 물론 PL/I와 IMS까지 처리하고, CPU 소비를 카피북 안쪽까지 파고들어 분석한다. 그것은 또한 z/OS 위에서 돌아가고 IBM의 ADDI 도구에 기대는 200만 달러 이상짜리 약속인데, 이 도구가 당신을 조용히 메인프레임에 묶어둔다 당신을 그로부터 해방시키려는 마이그레이션을 하는 동안에. 그것은 행위 동등성 테스트를 하지 않고, 당신의 JCL 작업 네트워크를 매핑하지 않는다.

그다음, 시장 전체를 뒤바꾼 순간이 있다. 2026년 2월, Anthropic은 Claude Code를 위한 COBOL 현대화 플레이북을 발표했다; IBM의 주가는 발표 당일 13.2% 하락했고, 3월에는 1억 달러 규모의 파트너 네트워크가 뒤따랐다. Claude Code는 발견, 문서화, 낯선 코드 읽기에 탁월하다 — 초기 단계에서 진정으로 유용하다. 하지만 그것은 범용 도구다. 이행적 의존성을 풀어내기 위한 내장 지식 그래프가 없고, JCL 스케줄링이나 행위 동등성, 규제받는 은행이 만들어내야 하는 감사 추적을 해결하는 척하지 않는다.

Microsoft의 Azure 마이그레이션 팩토리는 Java Quarkus를 겨냥하고 당신의 타깃 플랫폼을 Azure에 묶는다. 대형 시스템 통합업체들 — 특허받은 변환 엔진을 가진 DXC, MasterCraft를 가진 TCS, Cobalt를 가진 Infosys, Accenture — 은 50만 달러에서 500만 달러 이상 규모의 계약을 진행하며 당신의 시스템에 대한 지능을 구축하기보다 벤더 도구를 구현한다; Accenture는 대략 7억 4,990만 달러가 들고 5년이 걸린 호주 커먼웰스 은행의 코어 마이그레이션을 주도했다. 그리고 흔히 출발점으로 제시되는 Micro Focus의 Visual COBOL은 현대화가 전혀 아니다 — 그것은 재호스팅이다. 당신의 COBOL은 그저 새 런타임 위에서 계속 COBOL로 남는다. 기술 부채와 인력 문제는 정확히 당신이 두고 온 그 자리에 그대로 있다.

이들 각각은 실제로 무언가를 해낸다. 이들 중 어느 것도 하지 않는 것은 완전한 의존성 위상 — JCL, CICS, DB2, 카피북, 그 모든 것 — 을 먼저, 어떤 타깃 플랫폼과도 독립적으로 구축하고, 그 지도를 다른 모든 것이 그 위에 서는 토대로 삼는 일이다.

대부분의 벤더는 당신에게 더 나은 번역기를 판다. 번역은 애초에 실패한 부분이 아니었다.

아무도 멈출 수 없는 시계

이것을 엔지니어링 문제에서 비상사태로 바꿔놓는 부분이 여기 있다.

이 시스템들을 이해하는 사람들이 떠나고 있다. 미국의 평균 COBOL 개발자는 약 55세다. 그 인력의 대략 10%가 매년 은퇴하고, 대학의 85%가 1990년대에 이미 COBOL을 교과과정에서 뺐기 때문에 그들을 대체할 사람이 거의 없다. 이제 조직의 60%가 숙련된 COBOL 개발자를 찾는 것이 자신들의 가장 큰 단일 현대화 과제라고 말하고 — 여전히 이 스택을 아는 개발자의 58%가 그것 때문에 그만두는 것을 고려하고 있다고 말한다.

나는 나를 괴롭히는 이 상황의 한 버전 앞에 서본 적이 있다: 배치 윈도를 실제로 이해하는 유일한 사람의 은퇴 파티. 모두가 웃고 있고, 케이크가 있고, 내 머릿속 어딘가에서 목소리가 이렇게 말하고 있다 저 지식이 방금 문밖으로 걸어나갔고 그것은 어디에도 적혀 있지 않다. 지식 그래프는, 무엇보다도, 그 파티가 있기 전에 그 사람 머릿속에 있는 것을 담아두는 방법이다 — 의존성 지도가 그것을 외우고 있던 사람들보다 오래 살아남게 하는 방법.

그리고 그 판돈은 작지도 추상적이지도 않다. 약 2,200억 줄의 COBOL이 여전히 활발히 프로덕션에서 돌아가고 있다. 그것은 ATM 거래의 95%를 돌리고 하루에 대략 3조 달러를 청산한다. 은행 시스템의 43%가 그 위에 지어져 있다. 미국의 기술 부채는 추정 1조 5,200억 달러에 이르고, 평균적인 기업은 레거시 비효율에 매년 약 3억 7천만 달러를 태우며, 금융 서비스 기업들은 IT 예산의 70~75%를 낡은 시스템의 숨만 붙여두는 데 쓴다. 마이그레이션을 제대로 해낸 팀들은 114~225%의 수익률과 연간 약 2,500만 달러의 절감을 보고한다 — 하지만 그 이득은 실패하지 않은 마이그레이션의 저편에서만 존재한다. 이것은 아무것도 하지 않는 것이 비싼 선택인 드문 현대화다.

새로운 AI 도구들이 그냥 이걸 해결하지 않을까?

이것은 내가 가장 많이 받는 질문이고, 특히 Anthropic 발표가 마치 문제가 방금 해결됐다고 선언된 것처럼 보이게 한 뒤로는 타당한 질문이다.

내 솔직한 대답: 새 도구들은 발견 단계를 극적으로 빠르게 만들었고, 그것은 진짜 진전이다 — 나도 그것들을 쓴다. 하지만 에이전트형 AI가 COBOL을 잘 읽게 된다고 해서 실제로 프로젝트를 죽이는 것이 바뀌지는 않는다. Gartner는 2026년까지 엔터프라이즈 앱의 40%가 작업별 AI 에이전트를 포함할 것으로 예상한다; 코드를 더 빨리 번역하는 에이전트가 더 많아져도 그들이 모두 같은 JCL 의존성에 눈멀어 있다면 도움이 되지 않는다. 엉뚱한 문제에서의 속도는 그저 UAT에 더 빨리 도달해 거기서 실패하는 방법일 뿐이다.

내가 받는 또 다른 질문은 규제에 관한 것이고, 중견 은행들이 과소평가하는 바로 그것이다. EU의 디지털 운영 복원력법(Digital Operational Resilience Act) — DORA — 은 2025년 1월에 발효됐고, 레거시 시스템이 애초에 통과하도록 설계된 적이 없는 운영 복원력 및 위협 기반 침투 테스트를 요구한다. FFIEC와 OCC의 미국 감독관들은 노후 인프라를 살아 있는 컴플라이언스 격차로 취급하며, 10년이 넘은 시스템은 대략 세 배의 침해 확률을 안고 있다. 새 시스템이 옛 시스템과 동일하게 동작함을 입증하는 감사 추적을 만들어낼 수 없는 마이그레이션은 현대화가 아니다 — 그것은 더 나은 문법을 가진 새로운 책임(liability)이다.

그래서 행위 동등성 테스트가 지도만큼이나 중요하다. 이 기법은 설명하기는 간단하지만 잘 해내기는 어렵다: 레거시 시스템에서 실제 입력과 출력을 포착하고 — 골든 데이터셋 — 이를 새 시스템에 대해 재생(replay)하여, 예외 케이스 하나하나까지 동작이 일치할 때까지 맞춰본다. 수십 년에 걸쳐 축적된 그 예외 케이스들은, 흔히 규제 로직을 담고 있으며, 그것은 다른 어디에도 존재하지 않는다 — 사양서에도, 누군가의 머릿속에도 없고, 오직 실행 중인 코드 안에만 있다. 나는 이것이 은행보다 보험사를 더 세게 무는 것을 지켜본 적이 있다: 1998년 증권 특약에서만 발동되는 요율 규칙, 살아 있는 누구도 그 반올림을 설명할 수 없지만 모든 감사가 의존하는 손해준비금 계산. 그것들을 조용히 잃어버리면, 규제 당국이 묻는 날 어느 것이 중요했는지 알게 될 것이다.

어느 벽돌을 먼저 빼낼 것인가?

지도를 갖게 되면, 그것은 어떤 번역기도 알려줄 수 없는 것을 알려준다: 어디서 시작하는 것이 안전한가.

이제 지배적인 전략은 — 그럴 만한 이유로 — 교살자 무화과(strangler fig)다: 빅뱅 방식의 재작성 대신, 한 번에 하나의 기능을 뽑아내고, 옛것과 새것을 나란히 돌리며, 새 조각이 신뢰를 얻을 때까지 레거시 시스템을 살아 있는 대체 수단으로 유지한다. 하지만 교살자 무화과를 권하는 모든 벤더는 가장 어려운 질문을 빼놓는다 — 어느 모듈을 먼저 목 조를 것인가? 긴밀하게 결합된 것을 고르면 빅뱅 리스크를 여러 단계만 더해 재현한 꼴이 된다.

지식 그래프는 그것에 직접 답한다. 그것은 가장 결합도가 낮은 모듈 — 유입 의존성이 가장 적은 것들 — 을 드러내주어, 위험한 핵심을 건드리기 전에 시스템의 진짜 한 조각을 뽑아내고, 접근법을 입증하고, 조직의 자신감을 쌓을 수 있게 한다. 지도는 단지 TRN-LIMIT 실패에 대한 보험만이 아니다. 그것은 순서 계획이다.

우리는 이 모든 것 — 의존성 지식 그래프, 교살자 무화과 방식의 순서 결정, 행위 동등성 하네스를, 어떤 타깃 플랫폼과도 의도적으로 독립적으로 — 을 Veriprajna의 레거시 COBOL 현대화 실무에 담아냈다. 이는 200만 달러 하한선의 기존 강자들과 7자리 규모의 SI들이 신경 쓰기엔 너무 작다고 여기는 중견 은행과 보험사를 정면으로 겨냥한 것이다.

내가 솔직하게 인정하는 것

나는 기술이 모든 것을 해결한다고 가장하지 않겠다. 내가 본 가장 값비싼 실패들은 전혀 기술적인 것이 아니었기 때문이다.

어떤 도구도 — 우리 것을 포함해 — 조직의 동의를 만들어내거나, 수년간의 나쁜 데이터를 정리하거나, 이백 명의 개발자에게 일하는 방식을 바꾸도록 설득하는 정치적 싸움에서 이겨주지는 못한다. 시장은 2026년 약 90억 달러에서 10년 말까지 그 두 배를 향해 성장할 것으로 전망되는데, 바로 지출의 상당 부분이 컴파일러가 아니라 인간적·조직적 계층으로 가기 때문이다. 그리고 오픈소스든 상용이든 지구상 어떤 파서도 IBM Enterprise COBOL의 모든 구문을 완벽하게 다루지 못한다 — 1985년 이전의 ALTER 문(statement), 가장 깊은 곳의 REDEFINES. 그렇지 않다고 말하는 사람은 그 틈새를 당신에게 팔고 있는 것이다. 기술은 필수적이다. 하지만 그것만으로 충분했던 적은 없다.

하지만 기술이 소유할 수 있는 부분은, 반드시 완전히 소유해야 한다. 마이그레이션이 수백만 달러를 태우고도 아무것도 내놓지 못하는 이유가 누군가 형편없는 Java를 짜서인 경우는 드물다. 실제로 매핑한 적 없는 시스템을 번역했기 때문이다 — 웹 자체가 찢어지는 밤까지 보이지 않는 채로, 웹의 가닥들만 변환한 것이다.

지도를 먼저 그려라. 그것을 쓴 사람들보다 오래 살아남은 시스템은 놓친 의존성 하나를 용서하지 않으며, 무엇이 무엇에 연결되는지 볼 수 있게 되기 전에 안전한 버전의 이 작업이란 없다. 우리는 아무도 거기 있는 줄 몰랐던 단 하나의 packed-decimal 필드에 의해 무너진 원장에서 그것을 배웠다. 그 필드들이 당신을 찾아내기 전에 당신이 그것들을 찾아내라.