시스템은 오늘도 정상적으로 돌아갑니다. 문제는 그 시스템이 왜 그렇게 동작하는지 설명할 수 있는 사람이 몇 명 남지 않았다는 점입니다.
수주, 생산, 재고, 출하, 정산 같은 기간계 업무는 20~30년 전에 작성된 프로그램 위에서 지금도 정확하게 처리되고 있습니다. 즉, 품질 자체가 문제인 경우는 드뭅니다. 실제 문제는 변경 속도와 선택지의 폭입니다. 신규 채널을 붙이고 싶다, 외부 API와 연동하고 싶다, 데이터를 모아 AI로 분석하고 싶다 — 이런 논의가 나올 때마다 “기간계를 건드릴 수 있는가”가 첫 번째 관문이 되고, 결국 기획 자체가 축소됩니다.
대부분의 COBOL 마이그레이션 검토는 여기서 시작됩니다. 언어가 오래되어서가 아니라, 시스템을 중심으로 남아 있는 선택지가 계속 줄어들기 때문입니다. 이 글은 레거시 시스템 현대화를 내부적으로 검토하고 있는 CIO, IT 부서 책임자, 아키텍트를 대상으로 마이그레이션과 현대화의 차이, 리플랫폼·리팩터링·리이매진의 선택 기준, AI의 현실적인 역할, 그리고 5단계 전환 프로세스를 정리합니다.
왜 지금 레거시 시스템 현대화가 우선순위가 되는가
COBOL은 사라진 언어가 아닙니다. 금융, 보험, 제조, 유통의 기간계 영역에서 여전히 핵심 거래를 처리하고 있습니다. 다만 “잘 돌아가는 시스템”과 “유지보수할 수 있는 시스템”은 같은 말이 아닙니다. 현대화가 실제 과제로 올라오는 이유는 대체로 다음 여덟 가지입니다.
1. 인력 리스크와 속인화
설계 문서가 갱신되지 않았거나 아예 없는 상태에서, 업무 로직을 정확히 아는 사람은 오래 담당해 온 소수의 엔지니어뿐입니다. 그 인원의 퇴직이나 이동이 곧 시스템 변경의 중단으로 이어집니다. COBOL 인력의 모수 자체가 줄어들고 있어, 외부에서 충원한다는 전제도 해마다 약해지고 있습니다.
2. 운영 비용 증가
하드웨어와 소프트웨어 유지보수 비용은 눈에 보이는 부분입니다. 더 큰 비용은 테스트입니다. 영향 범위를 예측할 수 없으면 모든 변경을 넓게 회귀 테스트해야 하고, 한 줄 수정에 수개월이 걸리는 구조가 굳어집니다.
3. 유지보수성 저하
수십 년간 누적된 수정으로 분기 로직이 늘어난 프로그램은 사실상 블랙박스가 됩니다. 수정하는 시간보다 “수정해도 되는지” 조사하는 시간이 더 길어집니다.
4. 플랫폼·미들웨어 지원 종료
메인프레임과 미들웨어의 생명주기는 기업 사정과 무관하게 진행됩니다. 지원 종료 시점이 정해지면 판단할 수 있는 기간이 줄고, 착수가 늦어질수록 “가장 빠른 방식”만 남게 됩니다.
5. 보안과 감사 대응
지원이 종료된 기반에서는 취약점 대응, 암호화 방식 갱신, 인증 체계 연동이 어려워집니다. 특히 금융권처럼 감독 요건이 지속적으로 강화되는 영역에서는 “구조상 대응이 불가능하다”고 답해야 하는 항목이 늘어납니다.
6. 연계성과 데이터 활용
핵심 데이터가 기간계 내부에 갇혀 있으면 데이터 플랫폼, BI, AI 활용이 모두 절반짜리가 됩니다. 연동이 필요할 때마다 배치 인터페이스를 하나씩 추가하는 방식은 그 자체로 다음 세대의 레거시를 만듭니다.
7. 서비스 출시 속도
프런트엔드를 아무리 애자일하게 바꿔도 기간계의 리드타임이 그대로면 전체 속도는 달라지지 않습니다. 전체 속도는 가장 느린 계층이 결정합니다.
8. 운영 안정성과 업무 연속성
업무 연속성은 “지금까지 멈춘 적이 없다”가 아니라 “복구할 수 있는 사람과 절차가 있는가”입니다. 소수에게 의존하는 기간계는 가동률과 무관하게 연속성 리스크를 안고 있습니다.
마이그레이션과 현대화는 같은 말이 아니다
검토 초기에 가장 자주 혼동되는 지점입니다. 실행 환경을 옮기는 것(마이그레이션)과, 유지보수·확장이 가능한 구조로 다시 만드는 것(현대화)은 투자 판단 자체가 다릅니다. 실무에서는 다음 세 가지 방향을 업무 영역별로 나누어 적용합니다.
| 접근 방식 | 내용 | 적합한 경우 | 해결되지 않는 부분 |
|---|---|---|---|
| 리플랫폼 (기반 이전) | 애플리케이션과 업무 로직 대부분을 유지한 채 오픈 환경이나 클라우드로 이전. | 지원 종료가 임박했고, 우선 인프라 리스크부터 제거해야 하는 경우. 업무 요건이 안정적인 영역. | 유지보수성과 속인화 문제는 그대로 남습니다. 다음 단계를 전제로 계획해야 합니다. |
| 리팩터링 (COBOL Java 전환) | COBOL 자산을 Java/Spring 등 유지보수가 용이한 기술로 전환하고 구조를 재정비. | 앞으로도 개선이 계속되는 핵심 업무. 인력 확보 범위를 넓혀야 하는 영역. | 단순 기계 변환만으로는 “Java로 작성된 COBOL”이 됩니다. 목표 아키텍처를 사전에 정의해야 합니다. |
| 리이매진 (업무 기능 재설계) | API, 마이크로서비스, 이벤트 기반, 클라우드 네이티브 서비스로 업무 기능 자체를 다시 설계. | 경쟁력에 직결되는 영역, 외부 연계와 신규 채널 대응이 필요한 기능. | 비용과 기간이 큽니다. 전 영역에 적용하면 완주하기 어렵습니다. |
대규모 기간계에서는 “어느 방식인가”보다 “어느 영역에 어느 방식인가”가 실질적인 질문입니다. 배치 중심의 안정적인 처리는 리플랫폼으로 기반 리스크만 제거하고, 변경이 잦은 수주·재고 영역은 리팩터링으로 유지보수성을 확보하며, 외부 연계가 필요한 일부 기능만 리이매진하는 식의 배분이 현실적입니다. 이 배분의 정확도가 도구 선택보다 투자 대비 효과에 더 큰 영향을 미칩니다.
AI 활용 현대화: 어디까지 맡기고, 어디부터 맡기지 않는가
AI는 과거 공수의 상당 부분을 차지하던 분석·문서화 단계의 경제성을 바꿔 놓았습니다. 실제로 효과가 확인된 용도는 다음과 같습니다.
- 소스 코드 분류와 자산 정리(사용 중·미사용·중복 판별)
- 애플리케이션 디스커버리와 의존 관계 매핑
- 문서가 없는 자산에 대한 기술 문서 생성
- 업무 로직 추출 및 요약
- 코드 변환 지원
- 테스트 케이스 생성
- 전환 웨이브(분할 단위) 계획 수립 지원
- 테스트 자동화
반면 AI가 프로젝트를 통째로 완결할 수 있다는 전제는 현시점에서 성립하지 않습니다. 레거시 코드에 담겨 있는 것은 로직만이 아니라 예외 처리와 과거의 경위이기 때문입니다. “이 분기는 특정 거래처에만 적용되는 운영 규칙”, “이 반올림 처리는 회계 정책에서 비롯된 것” 같은 판단은 정적 분석만으로는 복원되지 않습니다.
따라서 BAP가 전제로 하는 것은 AI-assisted / expert-led, 즉 사람이 검증 루프에 들어가는 모델입니다. AI가 분석과 생성의 속도를 담당하고, 레거시 영역 전문가, Java·클라우드 엔지니어, QA, 그리고 현업 담당자가 결과를 검증합니다. 특히 현업의 참여는 기능 동등성을 판정하는 최종 근거가 됩니다.
AI는 조사와 생성 공수를 압축하는 수단이지, 업무 판단의 책임 주체가 아닙니다. 이 경계가 모호한 프로젝트는 테스트 단계에서 반드시 문제가 드러납니다.
COBOL 마이그레이션 5단계
1단계 — 애플리케이션 디스커버리와 의존 관계 가시화
프로그램, 잡, 셸 스크립트, 화면, 리포트, 데이터베이스 객체를 정리하고 호출 관계와 데이터 흐름을 가시화합니다. 이 단계에서 가장 큰 효과를 내는 것은 “실제로는 사용되지 않는 자산”을 걸러내는 일입니다. 동시에 현업 인터뷰를 통해 문서화되지 않은 규칙을 끌어냅니다.
2단계 — PoC와 전환 웨이브 계획
전체를 한 번에 착수하지 않습니다. 난이도가 대표성 있는 업무를 하나 선정해 변환 방침, 목표 아키텍처, 테스트 방식을 끝까지 검증합니다. PoC의 목적은 “가능한가”를 확인하는 것이 아니라 본 규모로 확대했을 때의 공수·품질·리스크를 견적할 수 있는 상태를 만드는 것입니다. 그 결과를 바탕으로 업무 단위·데이터 단위로 전환 웨이브를 나누고, 각 웨이브의 전환 방식(병행 가동 필요 여부 포함)을 정합니다.
3단계 — 소스, 화면, 데이터, 기반 전환
코드 변환과 함께 온라인 화면의 웹 전환, 리포트 재구축, 문자 코드와 데이터 타입 차이를 포함한 데이터 이관, 미들웨어와 잡 운영 이전을 병행합니다. 이때 전환 전후의 대응 관계를 추적 가능한 형태로 관리해, “어떤 COBOL 프로그램이 어떤 Java 컴포넌트에 대응하는가”를 언제든 설명할 수 있어야 합니다.
4단계 — 기능 동등성 테스트와 품질 보증
현대화의 품질은 이 단계에서 결정됩니다. 업무 사양을 바꾸지 않는 전환이라면, 동일한 입력에 대해 기존 시스템과 신규 시스템이 동일한 결과를 반환한다는 것을 증적으로 제시할 수 있어야 합니다. 주요 테스트는 다음과 같습니다.
- 단위 테스트
- 컴포넌트 테스트
- 배치 결과 대사(기존·신규 출력 비교)
- 통합 테스트
- 데이터 정합성 검증
- 시스템 테스트
- 성능 테스트(특히 배치 윈도우 내 완료 여부)
- 보안 검증
- 회귀 테스트
- 사용자 인수 테스트(UAT)
5단계 — 컷오버, 안정화, 지속적 개선
전환 계획은 롤백 조건이 함께 문서화되어야 완성됩니다. 전환 직후에는 모니터링과 1차 대응 체제를 두껍게 운영하고, 안정 가동을 확인한 뒤 정상 유지보수로 넘깁니다. 그리고 현대화는 컷오버로 끝나지 않습니다. 유지보수 가능한 구조를 확보한 뒤 API 공개와 클라우드 서비스 활용을 단계적으로 진행하는 지점에서 투자 회수가 본격화됩니다.
기대할 수 있는 비즈니스 성과
- 운영 리스크 저감 — 지원 종료 기반에서 벗어나고, 장애 대응 가능 인원이 늘어납니다.
- 인력 의존 완화 — 채용 모수가 큰 기술로 옮기면 조직 재구성의 여지가 생깁니다.
- 유지보수성 향상 — 구조와 문서가 정비되어 변경 시 조사 공수가 줄어듭니다.
- 릴리스 주기 단축 — 영향 범위를 예측할 수 있으면 테스트 범위를 합리적으로 좁힐 수 있습니다.
- 연계성 확보 — API, 클라우드, 데이터 플랫폼, AI 활용을 위한 접점이 생깁니다.
- 업무 로직 보존 — 오랜 기간 검증된 규칙을 설명 가능한 형태로 다음 기반에 넘길 수 있습니다.
- 사용자 경험 개선 — 화면의 웹 전환으로 단말·브라우저 제약과 조작성 문제를 해소합니다.
- 디지털 전환의 토대 — 이후 과제가 “우선 기간계부터 조사”로 시작되지 않습니다.
절감률이나 투자 회수 기간은 대상 자산의 규모·구조·업무 요건에 따라 크게 달라집니다. 수치 목표는 현황 조사 결과를 근거로 설정해야 하며, 일반론으로 제시할 수 있는 성격이 아닙니다.
BAP 수행 사례: 업무 프로세스를 바꾸지 않고 기간계를 새 기반으로
BAP는 수주 관리, 생산, 재고, 출하 업무를 기존 업무 프로세스를 변경하지 않는다는 전제 아래 기존 시스템에서 신규 플랫폼으로 이전하는 프로젝트에 참여했습니다.
대상 규모는 대략 다음과 같습니다.
- 사용자 화면: 약 90본
- 애플리케이션 프로그램: 약 300본
- 배치 처리·운영용 셸 스크립트: 약 85본
- 데이터베이스 테이블: 약 65본
BAP는 현지에서의 요건 확인과 시스템 분석, 이전 방식 제안, 개발 지원에 더해 컴포넌트 테스트, 시스템 테스트, 사용자 인수 테스트를 수행했습니다.
“업무 프로세스를 바꾸지 않는다”는 제약은, 뒤집어 말하면 기능 동등성 입증이 프로젝트의 중심 과제가 된다는 뜻입니다. 이런 유형의 프로젝트에서는 테스트 설계를 상류 공정부터 포함시키는 진행 방식이 특히 중요합니다.
BAP의 지원 영역
| 영역 | 내용 |
|---|---|
| 현황 조사·분석 | 자산 정리, 의존 관계 가시화, 현업 인터뷰, 전환 방식 비교 검토 |
| PoC | 본격 전개 전 실증 및 공수·품질·리스크 견적 정밀도 향상 |
| 단계적 전환 | 업무 단위·데이터 단위의 전환 웨이브 설계와 실행 |
| 개발 | COBOL Java 전환, Java/Spring 개발, 웹 화면·리포트 재구축 |
| 기반·데이터 | 플랫폼·미들웨어 이전, 데이터 이관 및 정합성 검증 |
| 품질 보증 | 단위부터 UAT까지의 엔드투엔드 테스트, 배치 대사, 성능·보안 검증 |
| 딜리버리 체계 | 오프쇼어·온사이트·하이브리드. 한국어, 영어, 일본어, 베트남어 대응 |
| 전환 후 유지보수 | 안정화 지원, 지속적인 개선 및 기능 추가 |
BAP는 약 500명 규모의 기술 인력을 보유하고 있으며, 베트남(하노이·다낭·호치민·후에)에 개발 거점을, 일본, 한국, 호주, 미국에 사무소를 두고 있습니다. 특히 품질 기준과 문서화 요건이 엄격한 일본 기업 대상 프로젝트 경험이 축적되어 있으며, 기간계 전환에서 요구되는 안정 가동과 기능 동등성 중심의 진행 방식을 그대로 적용합니다.
자주 묻는 질문
COBOL을 Java로 전환하면 현대화가 끝나는 건가요?
아닙니다. COBOL의 제어 구조를 그대로 Java에 옮긴 상태는 “Java로 작성된 COBOL”이며, 변경 시 조사 공수는 거의 달라지지 않습니다. 변환과 함께 패키지 구성, 데이터 액세스, 예외 처리 방침을 재정의해야 유지보수성이 실제로 개선됩니다.
설계 문서가 거의 없습니다. 전환이 가능한가요?
가능합니다. 오히려 문서가 불완전한 상태에서 시작하는 프로젝트가 일반적입니다. 소스 코드, 잡 정의, 실제 데이터의 거동을 대조해 사양을 재구성하고, 현업 인터뷰로 의도를 확인합니다. AI 기반 분석과 문서 생성이 특히 효과를 발휘하는 구간입니다.
일괄 전환과 단계적 전환 중 무엇을 선택해야 하나요?
업무 중단 허용 범위와 자산 규모에 따라 달라집니다. 일괄 전환은 병행 가동 부담이 작지만 롤백 난이도가 올라갑니다. 단계적 전환은 회차별 리스크를 낮추는 대신, 전환 기간 중 신구 데이터 연계라는 설계 과제가 추가됩니다. 원칙이 아니라 PoC 결과를 근거로 판단하는 편이 안전합니다.
전환 후 업무가 달라지지 않는다는 보장은 어떻게 하나요?
기능 동등성 테스트로 담보합니다. 기존 시스템과 신규 시스템의 출력을 대사하고, 차이가 나오면 원인을 특정해 사양인지 결함인지 현업과 함께 확정합니다. 이 과정을 생략할 방법은 없습니다.
지원 종료까지 아직 시간이 있는데, 지금부터 검토해야 하나요?
자산 조사와 방침 결정만으로도 상당한 기간이 필요하고, 이후 전환·테스트·안정화가 이어집니다. 착수가 늦으면 선택지가 리플랫폼으로 좁혀지는 경우가 많습니다. 현황 파악을 먼저 진행해 판단 재료를 확보해 두는 것을 권장합니다.
무엇부터 시작하면 되나요?
자산 정리와 의존 관계 가시화입니다. 규모와 구조가 보여야 리플랫폼·리팩터링·리이매진의 배분을 논의할 수 있습니다. 이 단계에서 큰 투자 판단은 필요하지 않습니다.
COBOL 현대화 상담
BAP는 COBOL 자산을 보유한 기업을 대상으로 다음과 같이 지원하고 있습니다.
- COBOL 현대화 진단 — 현행 자산 정리와 의존 관계 가시화
- 현황 과제 논의 — 인력 체계, 유지보수 부하, 기반 지원 기한을 반영한 쟁점 정리
- 현대화 로드맵 수립 — 업무 영역별 접근 방식 배분과 전환 웨이브 설계
- PoC 수행 — 대규모 투자에 앞서 방식과 견적 정밀도를 검증
사내 방침이 아직 정해지지 않은 단계여도 괜찮습니다. 현행 시스템의 상황을 알려주시면 검토에 필요한 쟁점과 진행 방식을 제안해 드리겠습니다.
