“시스템은 오늘도 정확하게 돌아간다. 그런데 왜 그렇게 동작하는지 설명할 수 있는 사람은 거의 없다.” COBOL 기간계 시스템을 운영하는 많은 기업이 바로 이런 상황에 놓여 있습니다.
문제는 품질이 아니라 변경 속도와 좁아지는 선택지입니다. 새로운 판매 채널 추가, SaaS와의 데이터 연계, AI 수요 예측 등 새로운 시도를 할 때마다 “기존 시스템을 건드릴 수 있는가”가 첫 관문이 되고, 결국 기획 자체가 축소됩니다. 이것이 기업이 레거시 현대화를 검토하는 진짜 이유입니다.
이 글에서 알 수 있는 내용 (IT 부서장·CIO·CTO 대상)
- COBOL 현대화가 우선 과제가 되는 8가지 이유
- 마이그레이션과 현대화의 차이, 리플랫폼·리팩토링·리이매진의 선택 기준
- AI에 맡길 수 있는 것과 사람이 판단해야 하는 것
- 5단계 현대화 프로세스와 BAP의 프로젝트 사례
왜 지금 레거시 시스템 현대화가 우선순위가 되는가
COBOL은 사라진 언어가 아닙니다. 금융, 보험, 제조, 유통의 기간계 영역에서 여전히 핵심 거래를 처리하고 있습니다. 다만 “잘 돌아가는 시스템”과 “유지보수할 수 있는 시스템”은 다릅니다. 중요한 것은 기술이 얼마나 오래됐는가가 아니라 비즈니스 변화에 대응할 수 있는가입니다. 현대화가 현실적인 과제가 되는 이유는 대체로 다음 8가지입니다.
| 압력 | 무슨 일이 일어나는가 |
|---|---|
| 1. 인력 리스크 | 업무 로직을 이해하는 사람은 일부 장기 담당자뿐. 이들의 퇴사·이동이 곧 변경 중단으로 이어지고, COBOL 인력의 외부 조달도 해마다 어려워짐 |
| 2. 운영 비용 상승 | 유지보수비에 더해 영향 범위를 알 수 없어 테스트 공수가 커짐. “한 줄 고치는 데 3개월 테스트”가 의사결정 속도를 떨어뜨림 |
| 3. 유지보수성 저하 | 오랜 개수로 분기가 늘어 블랙박스화. 수정 자체보다 “수정해도 되는지” 조사에 더 많은 시간이 듦 |
| 4. 플랫폼 지원 종료 | 하드웨어·미들웨어의 수명 주기는 기업이 아닌 벤더 일정에 따름. 늦게 시작할수록 올바른 방식이 아닌 가장 빠른 방식을 강요받기 쉬움 |
| 5. 보안·감사 대응 | 지원이 끝난 플랫폼은 최신 패치나 암호화 방식을 적용하기 어려워 “구조상 불가능”이라고 답해야 하는 영역이 늘어남 |
| 6. 연계성 한계 | 데이터가 기간계 안에 갇혀 BI·데이터 플랫폼·AI 활용이 모두 어중간해짐. 개별 배치 연계 추가가 또 다른 레거시를 만듦 |
| 7. 개발 속도 | 프런트엔드를 아무리 애자일화해도 기간계의 리드타임이 그대로면 전체 속도는 빨라지지 않음 |
| 8. 업무 연속성(BCP) | “돌아가니까 안전하다”가 아님. 복구할 사람과 절차가 없다면 속인화된 기간계 자체가 연속성 리스크 |
마이그레이션과 현대화는 같은 말이 아니다
검토 초기에 가장 많이 오해하는 부분입니다. 운영 환경만 옮기는 마이그레이션과 유지보수·확장하기 쉬운 구조로 재구성하는 현대화는 전혀 다른 투자 판단입니다. 실무에서는 다음 3가지 접근 방식을 업무 영역별로 조합합니다.
| 접근 방식 | 내용 | 적합한 경우 | 유의점 |
|---|---|---|---|
| 리플랫폼 (탈호스트·플랫폼 이전) | 업무 로직은 대부분 유지한 채 플랫폼을 오픈 시스템이나 클라우드로 이전 | 지원 종료가 임박해 플랫폼 리스크부터 해소해야 하는, 요건이 안정된 영역 | 플랫폼 리스크는 해소되지만 유지보수성·속인화 문제는 남음. 다음 단계를 전제로 계획 |
| 리팩토링 (COBOL→Java 등) | Java/Spring 등 유지보수하기 쉬운 기술로 변환하고 구조를 정리 | 앞으로도 개수가 계속되는 핵심 업무, 인력 확보 폭을 넓히고 싶은 영역 | 단순 기계 변환은 “Java로 쓴 COBOL”이 되기 쉬움. 설계 방침을 먼저 정의해야 함 |
| 리이매진 (업무 기능 재설계) | API·마이크로서비스·클라우드 네이티브로 업무 기능 자체를 재설계 | 경쟁력과 직결되거나 외부 연계·신규 채널이 필요한 영역 | 비용과 기간이 큼. 대상을 좁히는 것이 전제 |
현실적인 답은 “조합”
AI 활용 현대화: 어디까지 맡기고, 어디부터 맡기지 않을까
현대화 영역에서도 AI 활용이 빠르게 늘고 있습니다. 다만 AI가 프로젝트 전체를 자동으로 끝낼 수 있는 단계는 아닙니다.
AI가 효과를 내는 영역
- 소스 코드 분류·목록화(사용 중/미사용/중복)
- 애플리케이션 디스커버리와 의존 관계 매핑
- 설계서가 없는 자산의 문서 생성
- 업무 로직 추출·요약, 코드 변환 지원
- 테스트 케이스 생성, 테스트 자동화, 이관 웨이브 계획 지원
사람이 판단해야 하는 영역
- “이 분기는 특정 거래처용 운영 규칙” 같은 업무상 예외 처리
- “이 반올림 처리는 회계 방침에서 유래” 같은 과거 경위
- 신·구 출력 차이가 사양인지 결함인지 판정
- 기능 등가성의 최종 확인(업무 부서 참여 필수)
BAP의 접근법: AI-assisted, expert-led
COBOL 현대화 진행 방법: 5단계
애플리케이션 디스커버리와 의존 관계 시각화
프로그램·잡·셸·장표·DB를 목록화하고 호출 관계와 데이터 흐름을 시각화합니다. “실제로 쓰이지 않는 자산”을 걸러낼 수 있는지가 이후 규모를 크게 좌우합니다. 업무 부서 인터뷰로 문서화되지 않은 규칙도 끌어냅니다.
PoC와 이관 웨이브 계획
대표적인 난이도의 업무 하나를 골라 변환 방침·아키텍처·테스트 방법을 실증합니다. 목적은 “가능한가”의 확인이 아니라 실제 규모의 공수·품질·리스크를 산정할 수 있는 상태를 만드는 것입니다. 그 결과로 이관 웨이브와 전환 방식(병행 가동 여부 포함)을 정합니다.
소스 코드·화면·데이터·플랫폼 변환
코드 변환과 함께 화면 웹화, 장표 재구축, 문자 코드·데이터 타입 차이를 포함한 데이터 이관, 미들웨어·잡 운영 이관을 병행합니다. “어떤 COBOL 프로그램이 어떤 Java 클래스에 대응하는지”를 항상 추적할 수 있게 관리합니다.
기능 등가성 테스트와 품질 보증
현대화의 품질은 이 단계에서 결정됩니다. 구 시스템과 신 시스템이 같은 입력에 같은 결과를 낸다는 것을 증적으로 보여 줘야 합니다.
단위 테스트 컴포넌트 테스트 배치 결과 대사 통합 테스트 데이터 정합성 검증 시스템 테스트 성능 테스트(배치 윈도우) 보안 검증 회귀 테스트 사용자 인수 테스트(UAT)
컷오버, 안정화, 지속적 개선
절차서와 롤백 조건을 함께 준비하고, 전환 직후에는 모니터링 체계를 강화합니다. 현대화는 컷오버로 끝나지 않습니다. 유지보수하기 쉬운 구조 위에서 API화와 클라우드 활용을 단계적으로 진행할 때 비로소 투자가 회수됩니다.
현대화로 얻는 비즈니스 가치
| 가치 | 내용 |
|---|---|
| 운영 리스크 감소 | 지원 종료 플랫폼에서 벗어나고, 장애 대응 가능 인력이 늘어남 |
| 인력 의존도 완화 | Java 등 인력 풀이 큰 기술로 전환해 체계를 재구축하기 쉬워짐 |
| 유지보수성 향상 | 구조와 문서가 정비되어 수정 시 조사 공수가 줄어듦 |
| 릴리스 주기 단축 | 영향 범위를 파악할 수 있어 테스트 범위를 합리적으로 좁힐 수 있음 |
| 연계성 확보 | API·클라우드·데이터 플랫폼·AI와의 연결 지점이 생김 |
| 업무 로직 보존 | 오랜 기간 검증된 업무 규칙을 설명 가능한 형태로 이어받음 |
| 사용자 경험 개선 | 화면 웹화로 단말·브라우저 제약과 조작성 문제를 해소 |
※비용 절감률과 투자 회수 기간은 대상 자산의 규모·구조·업무 요건에 따라 크게 달라집니다. 수치 목표는 현행 자산 조사 결과를 바탕으로 설정해야 합니다.
BAP 사례: 업무 프로세스를 바꾸지 않고 기간 업무를 새 플랫폼으로
BAP는 수주 관리·생산·재고·출하 등 기간 업무를 기존 업무 프로세스를 변경하지 않는다는 전제로 구 시스템에서 새 플랫폼으로 이관하는 프로젝트에 참여했습니다.
약 90개
사용자 화면
약 300개
애플리케이션 프로그램
약 85개
배치·운영 셸 스크립트
약 65개
DB 테이블
BAP는 현지 요건 확인과 시스템 분석, 이관 방식 제안, 개발 지원은 물론 컴포넌트 테스트부터 사용자 인수 테스트까지 담당했습니다. “업무 프로세스를 바꾸지 않는다”는 제약은 곧 기능 등가성 입증이 프로젝트의 핵심 과제가 된다는 뜻입니다. 테스트를 상류 설계 단계부터 반영하는 방식이 특히 중요합니다.
BAP의 지원 영역
| 영역 | 내용 |
|---|---|
| 현황 조사·분석 | 자산 목록화, 의존 관계 시각화, 업무 인터뷰, 이관 방식 비교 |
| PoC | 본격 전개 전 실증, 공수·품질·리스크 산정 정확도 향상 |
| 단계적 이관 | 업무·데이터 단위 이관 웨이브 설계와 실행 |
| 개발 | COBOL→Java 변환, Java/Spring 개발, 웹 화면·장표 재구축 |
| 플랫폼·데이터 | 플랫폼/미들웨어 이관, 데이터 이관 및 정합성 검증 |
| 품질 보증 | 단위부터 UAT까지의 엔드투엔드 테스트, 배치 대사, 성능·보안 검증 |
| 딜리버리 체계 | 오프쇼어·온사이트·하이브리드. 한국어·영어·일본어·베트남어 대응 |
| 전환 후 유지보수 | 안정화 지원, 지속적인 개선 및 기능 추가 |
BAP는 약 500명 규모의 기술 인력을 보유하고 있으며, 베트남(하노이·다낭·호찌민·후에), 일본, 한국, 호주, 미국에 거점을 둔 개발 회사입니다.
자주 묻는 질문
Q. COBOL을 Java로 변환하면 현대화가 끝나나요?
A. 아닙니다. COBOL의 제어 구조를 그대로 옮기면 “Java로 쓴 COBOL”이 될 뿐, 수정 시 조사 공수는 거의 줄지 않습니다. 변환과 함께 패키지 구성·데이터 접근·예외 처리 방침을 재정의해야 합니다.
Q. 설계서가 전혀 남아 있지 않아도 이관할 수 있나요?
A. 가능하며, 흔한 경우입니다. 소스 코드, 잡 정의, 실제 데이터의 동작을 대조해 사양을 재구성하고 업무 부서 인터뷰로 의도를 확인합니다. 이 과정에서 AI 기반 분석·문서 생성이 특히 효과적입니다.
Q. 일괄 이관과 단계적 이관 중 무엇을 선택해야 하나요?
A. 업무 중단 허용도와 자산 규모에 따라 다릅니다. 일괄 전환은 병행 가동 부담이 적지만 롤백이 어렵고, 단계적 이관은 회차별 리스크를 줄이는 대신 신·구 데이터 연계 설계가 필요합니다. PoC 결과를 바탕으로 판단하는 것이 안전합니다.
Q. 이관 후 업무가 바뀌지는 않나요?
A. 기능 등가성 테스트로 보장합니다. 신·구 출력을 대조하고 차이가 나면 원인을 밝혀 사양인지 결함인지 업무 부서와 확인하는 것, 이 축적이 유일한 방법입니다.
Q. 지원 종료까지 시간이 남았는데 지금부터 검토해야 하나요?
A. 네. 자산 조사와 방침 결정에만 상당한 기간이 걸리고, 이후 이관·테스트·안정화가 이어집니다. 기한 직전에 시작하면 선택지가 리플랫폼으로 좁아지기 쉽습니다. 자산 목록화와 의존 관계 시각화부터 시작하시길 권합니다.
COBOL 현대화 상담
- 진단: 현행 자산 목록화와 의존 관계 시각화
- 과제 정리: 인력 체계·유지보수 부담·플랫폼 지원 기한을 고려한 논점 정리
- 로드맵 수립: 업무 영역별 접근 방식 배분과 이관 웨이브 설계
- PoC: 대규모 투자 전 방식과 견적 정확도 검증
“아직 사내 방침이 정해지지 않았다”는 단계라도 괜찮습니다. 현행 시스템 상황을 알려 주시면 검토에 필요한 논점과 진행 방법을 제안해 드립니다.
