Skip to content
Published on

코어뱅킹 현대화 전략 — 메인프레임에서 클라우드 네이티브까지

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며

"코어뱅킹을 바꾼다"는 말은 은행 IT에서 가장 무거운 문장입니다. 심장 이식 수술을 환자가 마라톤을 뛰는 도중에 하는 것에 비유되곤 합니다. 그런데도 전 세계 은행들이 이 수술대에 오르는 이유는 분명합니다. 레거시 코어를 유지하는 비용과 리스크가, 바꾸는 비용과 리스크를 넘어서는 시점이 오기 때문입니다.

이 글에서는 코어뱅킹 현대화의 동인과 접근법들을 비교하고, 코어 분해 전략, 클라우드 네이티브 코어의 흐름, 한국 특유의 규제 환경, 데이터 마이그레이션과 컷오버 리스크 관리, 조직 전환, 그리고 반복되는 실패 패턴까지 정리합니다. 특정 벤더나 솔루션의 추천이 아니며 투자·법률 자문도 아닙니다. 규제 관련 내용은 시점에 따라 변하므로 반드시 최신 원문을 확인하시기 바랍니다.

레거시 코어뱅킹의 현실

COBOL과 메인프레임이라는 유산

전 세계 대형 은행의 상당수는 여전히 메인프레임 위의 COBOL 코어를 운영합니다. 1970에서 80년대에 구축된 시스템이 거듭된 증축을 거치며 수천만 라인의 코드베이스가 된 경우가 흔합니다. 이 시스템들은 "낡았지만 무너지지 않는" 역설적 존재입니다. 수십 년의 운영으로 검증된 안정성과 트랜잭션 처리 능력은 실재하지만, 다음과 같은 구조적 부담이 누적됩니다.

  • 인력 절벽: COBOL과 해당 기관 고유 프레임워크를 아는 인력이 은퇴하고, 신규 유입은 거의 없습니다. "코드는 있는데 이유를 아는 사람이 없는" 화석화가 진행됩니다.
  • 변경 비용: 단순한 상품 조건 추가에도 영향 분석에 수 주가 걸리고, 릴리스는 분기 단위로 묶입니다.
  • 통합의 벽: 실시간 API, 이벤트 스트리밍 같은 현대적 통합 방식과의 임피던스가 커서, 미들웨어 계층이 겹겹이 쌓입니다.

레거시 코어의 전형적 구조

현대화 대상을 정확히 알기 위해, 전형적인 레거시 코어의 모습을 그려보면 다음과 같습니다.

 +--------------------------------------------------------------+
 |                     모놀리식 코어 (메인프레임/유닉스)              |
 |                                                              |
 |  [온라인 영역]                       [배치 영역]                |
 |   거래 제어 모니터(TP모니터)            JCL/스케줄러 기반          |
 |   수신/여신/외환 트랜잭션 모듈           일마감/월마감 잡 수천 개     |
 |   (상품 로직 + 원장 갱신 + 분개가        (이자, 결산, 보고서,       |
 |    하나의 프로그램에 혼재)               대사, 추출이 혼재)         |
 |                                                              |
 |  [공유 데이터]                                                 |
 |   계층형/관계형 DB + VSAM류 파일 + 코드 테이블 수천 개              |
 |   모듈 간 통신: 공유 메모리, 파일 인터페이스, 포인트투포인트 전문      |
 +--------------------------------------------------------------+

이 구조의 문제는 성능이 아닙니다(성능은 대체로 훌륭합니다). 문제는 결합도입니다. 상품 로직, 계산, 원장 기록, 회계가 한 덩어리라서 어느 하나만 바꿀 수 없고, 수천 개의 배치 잡이 파일 인터페이스로 얽혀 있어 영향 범위 분석 자체가 고고학이 됩니다.

한국의 차세대 프로젝트 역사

한국 은행권은 독특한 길을 걸었습니다. 2000년대 초중반부터 "차세대"라는 이름으로 메인프레임을 유닉스 기반(이후 리눅스·x86)으로 전환하는 빅뱅 재구축을 반복해 온 것입니다. 1세대 차세대(2000년대), 2세대(2010년대), 그리고 일부 은행의 3세대 프로젝트까지, 통상 3에서 5년의 기간과 수천억 원 규모의 예산이 투입되는 초대형 프로젝트였습니다. 그 결과 한국 시중은행 코어는 글로벌 평균 대비 탈메인프레임이 많이 진행된 편이지만, "수년 주기의 빅뱅 재구축"이라는 모델 자체의 피로감(비용, 조직 소모, 빅뱅 컷오버 리스크)에 대한 문제의식도 함께 쌓였습니다. 최근의 화두가 빅뱅이 아닌 점진적 현대화와 클라우드 활용으로 이동한 배경입니다.

현대화의 동인 — 왜 지금인가

동인구체적 내용
비용 구조메인프레임 라이선스·유지보수 비용, 변경 단가의 지속 상승
인력 리스크레거시 기술 인력의 은퇴, 채용 시장에서의 비매력
민첩성상품 출시 주기 단축 요구(월 단위에서 주·일 단위로)
경쟁 압력인터넷전문은행의 등장 — 낮은 IT 원가와 빠른 실험 속도
채널 변화모바일 퍼스트, 오픈뱅킹, 임베디드 금융으로 인한 트래픽 패턴 변화
규제 변화클라우드 이용 규제의 단계적 완화, 망분리 규제의 합리화 흐름
데이터 활용실시간 데이터 기반 개인화·리스크 관리 요구

특히 한국에서는 인터넷전문은행의 충격이 컸습니다. 처음부터 리눅스·오픈소스 기반으로 구축된 신생 은행이 기존 은행 대비 훨씬 적은 인력과 비용으로 코어를 운영하며 빠르게 상품을 실험하는 모습은, "코어뱅킹은 원래 무겁고 느린 것"이라는 통념을 흔들었습니다.

동인을 정리할 때 주의할 점이 하나 있습니다. "낡았으니 바꾼다"는 동인이 될 수 없다는 것입니다. 경영진을 설득하고 다년간의 투자를 정당화하려면, 각 동인을 측정 가능한 목표(상품 출시 리드타임 N일 단축, 운영 비용 N퍼센트 절감, 특정 인력 리스크의 해소 시한)로 번역해야 하고, 그 목표가 이후 모든 단계의 우선순위 판단 기준이 됩니다.

접근법 비교 — 네 가지 길

코어 현대화의 접근법은 크게 네 갈래로 정리할 수 있습니다.

접근법개요장점단점/리스크적합한 경우
빅뱅 차세대전면 재구축 후 일괄 전환일관된 아키텍처, 이행 후 단순한 운영컷오버 리스크 극대, 수년간 가치 동결, 예산 초과 단골레거시가 한계이고 조직이 대형 PJT 경험 보유
점진적 스트랭글러기능 단위로 신규 시스템이 레거시를 잠식리스크 분산, 조기 가치 전달, 학습 반영신구 공존 기간의 복잡도, 장기화 위험도메인 경계가 분리 가능하고 장기 로드맵 유지 가능
할로우 더 코어코어는 얇은 원장으로 축소, 주변 기능을 밖으로 추출코어 변경 최소화로 리스크 통제코어 자체의 수명 연장에 불과할 수 있음코어가 안정적이고 주변 민첩성이 급한 경우
신규 뱅크 병행(그린필드)별도의 신규 뱅크/브랜드를 새 코어로 구축 후 고객 이전레거시 제약 없는 설계, 신속한 검증이중 운영 비용, 기존 고객 이전의 난제신사업·신규 세그먼트 공략과 병행할 때

실제 프로젝트는 이들의 혼합입니다. 예컨대 "신규 수신 상품은 새 코어에서 출시(그린필드) + 기존 상품은 만기 도래분부터 새 코어로 이관(스트랭글러) + 레거시는 원장 기능만 남기고 동결(할로우)"같은 조합이 현실적인 로드맵으로 자주 등장합니다.

스트랭글러 패턴의 구조

                     +---------------------+
        채널/대외계 ->|   라우팅 파사드        |
                     | (상품/계좌 기준 분기)   |
                     +----+-----------+----+
                          |           |
            구계좌/구상품   |           |  신계좌/신상품
                +---------v--+     +--v-----------+
                |  레거시 코어  |     |   신규 코어    |
                | (동결, 축소) |     | (성장, 확장)   |
                +---------+--+     +--+-----------+
                          |           |
                +---------v-----------v----------+
                |    통합 원장 뷰 / 정보계 동기화     |
                |    (양쪽 잔액·거래의 단일 뷰)       |
                +--------------------------------+

스트랭글러의 성패는 라우팅 파사드의 설계에 달려 있습니다. 어떤 계좌가 어느 코어에 있는지를 채널이 몰라도 되게 만드는 것, 그리고 양쪽에 걸친 거래(구계좌에서 신계좌로 이체 등)의 정합성을 보장하는 것이 핵심 난제입니다.

코어 분해 전략 — 무엇을 어떻게 쪼개나

상품 팩토리의 분리

레거시 코어가 비대해진 주범은 상품 로직이 원장 처리 코드에 박혀 있기 때문입니다. 현대적 코어 설계는 상품 정의(금리 체계, 수수료, 조건, 한도)를 데이터·설정으로 외부화한 상품 팩토리를 둡니다. 신상품 출시가 "코드 배포"가 아니라 "상품 메타데이터 등록"이 되는 것이 목표입니다. 앞 글에서 다룬 우대금리 룰 엔진도 상품 팩토리의 일부로 볼 수 있습니다.

원장의 분리와 얇은 코어

 [전통 모놀리식 코어]               [분해된 코어]
 +--------------------+        +------------------+
 |  채널 처리           |        |  상품 팩토리       |  <- 상품 정의/룰
 |  상품 로직           |        +------------------+
 |  이자/수수료 계산     |        +------------------+
 |  원장 기록           |   =>   |  가격/이자 엔진    |  <- 계산 전담
 |  고객 정보           |        +------------------+
 |  회계 분개           |        +------------------+
 |  보고서             |        |  얇은 원장(코어)    |  <- 잔액/거래 기록만
 +--------------------+        +------------------+
                               +------------------+
                               |  고객 마스터(별도)  |
                               +------------------+
                               +------------------+
                               |  회계 허브(별도)    |
                               +------------------+

분해의 원칙은 "원장은 마지막까지 작고 단단하게"입니다. 잔액과 거래 기록이라는 본질만 남기고, 계산(이자·수수료), 판단(한도·조건), 표현(보고서·조회)을 모두 바깥으로 빼는 방향입니다. 원장이 작을수록 검증이 쉽고, 검증이 쉬울수록 이행이 안전해집니다.

이벤트 기반 통합

분해된 컴포넌트들은 이벤트로 묶는 것이 현재의 정석입니다. 원장에서 확정된 거래를 이벤트(예: 입금 완료, 계좌 해지)로 발행하면, 정보계 적재·알림·회계 허브·리스크 시스템이 각자 구독합니다.

  [원장 코어] --발행--> [이벤트 스트림 (Kafka 등)] --구독--> [정보계 적재]
                                            +--구독--> [알림/푸시]
                                            +--구독--> [회계 허브]
                                            +--구독--> [FDS/리스크]

단, 금융 도메인에서 이벤트 기반 통합을 할 때는 일반 웹 서비스보다 엄격한 규율이 필요합니다.

  • 원장 커밋과 이벤트 발행의 원자성: 아웃박스 패턴(원장 트랜잭션 안에서 이벤트를 테이블에 기록 후 별도 릴레이가 발행)이 사실상 표준입니다.
  • 순서와 멱등: 같은 계좌의 이벤트는 순서가 보존되어야 하고(계좌 키 기반 파티셔닝), 구독자는 중복 수신을 전제로 멱등하게 설계합니다.
  • 재처리 가능성: 구독 시스템 장애 시 특정 시점부터 재소비할 수 있어야 하며, 이벤트 스키마의 하위 호환을 관리합니다.

분해 순서의 결정 기준

무엇부터 떼어낼지는 다음 두 축으로 평가하는 것이 실용적입니다.

평가 축질문예시
분리 용이성원장 트랜잭션과의 결합이 약한가보고서/조회(쉬움) vs 출금 검증(어려움)
변경 빈도비즈니스 요구로 자주 바뀌는가상품 조건/우대금리(높음) vs 분개 규칙(낮음)

변경 빈도가 높고 분리가 쉬운 것(조회 API, 상품 룰, 알림)부터 시작해 조기 성과를 만들고, 분리가 어렵고 변경이 적은 원장 본체는 마지막에 다루는 것이 정석입니다. 반대로 가장 어려운 원장부터 손대는 프로젝트는 가치 전달 없이 리스크만 쌓다가 동력을 잃기 쉽습니다.

클라우드 네이티브 코어뱅킹의 흐름

2010년대 후반부터 "코어뱅킹을 SaaS/클라우드 네이티브로"라는 흐름이 본격화됐습니다. 대표적으로 거론되는 플레이어들의 특징을 아는 범위에서 정리하면 다음과 같습니다(특정 솔루션 추천이 아니며, 기능과 전략은 계속 변하므로 공식 자료 확인이 필요합니다).

  • Thought Machine (Vault Core): 클라우드 네이티브 설계와 스마트 컨트랙트라 불리는 상품 정의 방식(상품 로직을 코드 계약으로 기술)을 내세우는 신생 코어. 대형 은행들의 차세대 코어 실험 사례로 자주 언급됩니다.
  • Mambu: SaaS형 코어뱅킹의 대표 주자로, 컴포저블 뱅킹(필요한 기능을 조합)을 표방합니다. 네오뱅크·핀테크의 빠른 출시 사례가 많습니다.
  • Temenos, FIS, Finastra 등 전통 강자들도 클라우드 전환 버전을 내놓으며 대응하고 있습니다.

클라우드 네이티브 코어의 공통 패턴은 다음과 같습니다.

  1. 상품 정의의 코드화/설정화: 상품을 코어 바깥의 선언적 정의로 다뤄 출시 주기를 단축합니다.
  2. API 퍼스트: 모든 기능이 API로 노출되어 채널·파트너 통합이 수월합니다.
  3. 수평 확장: 계좌 단위 파티셔닝으로 처리량을 노드 추가로 확장합니다.
  4. 실시간 원장: 일배치 중심 설계를 줄이고, 이자 계상 등도 실시간·준실시간으로 이동하는 경향이 있습니다.

다만 냉정하게 봐야 할 지점도 있습니다. 대형 기존 은행이 전체 원장을 신생 SaaS 코어로 옮긴 완결 사례는 아직 많지 않고, 부분 도입(특정 상품군, 신규 브랜드)으로 검증 중인 단계가 일반적입니다. "클라우드 네이티브 코어 = 즉시 도입 가능한 완성품"이 아니라 "유망하지만 검증 비용이 큰 선택지"로 보는 것이 실무 감각에 맞습니다.

한국의 특수성 — 규제 환경이라는 변수

한국에서 코어 현대화를 설계할 때는 규제 환경을 빼놓을 수 없습니다. 큰 흐름만 짚으면 다음과 같습니다(세부 요건은 개정이 잦으므로 반드시 금융위원회·금융감독원의 최신 원문과 유권해석을 확인해야 합니다).

  • 전자금융감독규정: 금융회사 IT의 안전성 기준을 정하는 핵심 규정입니다. 인력·조직, 시설, 정보처리시스템, 재해복구(핵심 업무의 복구 목표 시간 등)에 대한 요구사항이 있어 아키텍처 설계의 제약 조건이 됩니다.
  • 망분리: 내부 업무망과 인터넷의 분리를 요구해 온 규제로, 개발 생산성(오픈소스 활용, SaaS 개발 도구)에 큰 영향을 줬습니다. 최근 수년간 규제 샌드박스와 단계적 개선을 통해 클라우드 개발 환경, 생성형 AI 활용 등에 대한 예외와 합리화가 진행되어 왔습니다.
  • 클라우드 이용 규제: 과거에는 중요 시스템의 클라우드 이용이 사실상 어려웠으나, 규정 개정을 거치며 중요도 평가와 사전 보고 체계를 기반으로 클라우드 활용 범위가 단계적으로 넓어져 왔습니다. 다만 계정계급 핵심 시스템의 퍼블릭 클라우드 전면 이전은 여전히 보수적으로 접근하는 것이 업계의 일반적인 모습입니다.

전략적 함의는 명확합니다. 한국에서의 현실적인 경로는 "주변계(채널, 정보계, 신사업)부터 클라우드로, 계정계는 분해와 표준화를 먼저"가 되는 경우가 많고, 규제 변화의 속도가 로드맵의 주요 변수라는 점을 처음부터 계획에 반영해야 합니다.

데이터 마이그레이션 전략 — 원장을 옮기는 기술

코어 현대화의 최대 난관은 코드가 아니라 데이터입니다. 수천만 계좌, 수십억 건의 거래 이력, 그리고 "지금 이 순간에도 변하는" 잔액을 옮겨야 합니다.

이중 기재 (Dual Write / Parallel Run)

  단계 1: 레거시가 마스터, 신규 코어는 그림자
  [거래] --> [레거시 원장 (확정)] --복제/재생--> [신규 원장 (그림자)]
                                                  |
                            [일일 전수 대사: 잔액/이자/수수료 비교 리포트]

  단계 2: 신뢰 확보 후 역할 전환 (상품군/고객군 단위)
  [거래] --> [신규 원장 (확정)] --복제--> [레거시 원장 (그림자, 비상용)]

  단계 3: 레거시 동결, 조회 전용 보존 후 폐기

핵심 규율은 다음과 같습니다.

  1. 병행 검증은 전수로: 표본 검증은 함정입니다. 이자 계산처럼 조건 조합이 많은 영역은 전 계좌 비교가 원칙이고, 차이 건은 분류 코드를 붙여 수렴 추이를 관리합니다("차이 제로의 N일 연속 유지" 같은 기준으로 컷오버 게이트를 정의).
  2. 재생(replay) 가능한 이행: 초기 적재 + 변경분 동기화(CDC) + 컷오버 직전 최종 동기화의 3단 구조로 만들고, 어느 단계든 실패 시 처음부터 재실행 가능해야 합니다.
  3. 의미 변환의 명세화: 레거시의 상태 코드, 일수 관행, 절사 정책이 신규 코어와 1:1이 아닐 수 있습니다. 매핑 규칙을 명세서로 만들고, 변환 손실(예: 레거시에만 있는 특수 상태)의 처리 방침을 업무 부서와 합의해 둡니다.
  4. 이력의 처리: 전체 거래 이력을 신규 코어로 옮길지, 조회 전용 아카이브에 두고 신규 코어는 기산 잔액부터 시작할지는 비용·규제 보존 의무·고객 경험을 함께 따져 결정합니다.

병행 대사 쿼리의 모습

전수 대사의 실체는 의외로 소박한 SQL입니다. 신구 원장을 일 단위로 비교하는 골격 예시는 다음과 같습니다.

-- 일일 잔액 전수 대사: 레거시 스냅샷 vs 신규 코어 스냅샷
SELECT COALESCE(l.account_no, n.account_no)      AS account_no,
       l.balance                                  AS legacy_balance,
       n.balance                                  AS new_balance,
       COALESCE(l.balance, 0) - COALESCE(n.balance, 0) AS diff,
       CASE
         WHEN l.account_no IS NULL THEN 'NEW_ONLY'    -- 신규에만 존재
         WHEN n.account_no IS NULL THEN 'LEGACY_ONLY' -- 레거시에만 존재
         WHEN l.balance <> n.balance THEN 'MISMATCH'
         ELSE 'OK'
       END AS recon_status
  FROM legacy_balance_snapshot l
  FULL OUTER JOIN new_core_balance_snapshot n
       ON l.account_no = n.account_no
      AND l.snapshot_date = n.snapshot_date
 WHERE l.snapshot_date = DATE '2026-06-12'
   AND (l.balance IS DISTINCT FROM n.balance
        OR l.account_no IS NULL OR n.account_no IS NULL);

-- 차이 건의 분류 집계: 수렴 추이 관리용
SELECT recon_status, diff_reason_code, COUNT(*) AS cnt,
       SUM(ABS(diff)) AS abs_diff_sum
  FROM daily_recon_result
 WHERE snapshot_date = DATE '2026-06-12'
 GROUP BY recon_status, diff_reason_code
 ORDER BY cnt DESC;

포인트는 차이 사유 코드입니다. "절사 정책 차이", "레거시 특수 상태", "타이밍 차이(미결 거래)"처럼 차이를 분류해 두면, 어떤 차이가 설계상 허용(문서화된 차이 목록)이고 어떤 차이가 결함인지 추적할 수 있습니다. 차이 리포트가 매일 자동으로 나오고 추이 그래프가 우하향하는 것, 이것이 병행 검증이 살아 있다는 증거입니다.

컷오버 설계

컷오버 방식내용리스크 프로파일
일괄(빅뱅)주말 등에 전체 전환단기간 고강도, 롤백 창이 좁음
상품군 단위예: 신규 적금부터 전환신구 공존 복잡도, 리스크 분산
고객군 단위예: 신규 고객부터동일 고객 다계좌의 분리 문제
만기 롤오버만기 도래 시 신규 코어로 재계약가장 느리지만 가장 안전한 축

어떤 방식이든 롤백 계획은 컷오버 계획과 동급의 산출물이어야 합니다. "어느 시점까지, 어떤 조건이 깨지면, 어떤 절차로 되돌리는가"를 리허설로 검증하지 않은 롤백 계획은 문서일 뿐입니다. 대형 이행에서는 통상 전환 리허설을 수차례(데이터 전수 이행 리허설 포함) 수행하고, 리허설마다 소요 시간을 측정해 컷오버 타임라인의 여유를 확인합니다.

컷오버 주간의 타임라인 예시

빅뱅형 요소가 포함된 전환의 마지막 주말은 보통 다음과 같은 시간표로 움직입니다.

 금요일 영업 마감
   T+0h   : 레거시 일마감 정상 완료 확인 (선행 게이트)
   T+1h   : 신규 거래 차단(서비스 공지), 채널을 점검 모드로
   T+2h   : 최종 변경분 동기화(CDC 드레인), 양 원장 정지점 확정
   T+3h   : 전수 대사 실행 (잔액/미지급이자/한도/상태)
   T+6h   : 대사 결과 판정 회의 -> GO / NO-GO 결정
   [GO]   : 라우팅 전환, 신규 코어로 거래 개시(내부 검증 거래 우선)
   T+8h   : 채널 단계적 오픈(직원 -> 일부 고객군 -> 전체)
   T+24h  : 첫 영업일 모니터링 체계(워룸) 가동
   T+72h  : 안정화 판정, 워룸 해제 또는 롤백 판단 시한
 [NO-GO] : 사전 정의된 롤백 절차 가동, 레거시로 복귀 후 원인 분석

이 시간표에서 가장 중요한 줄은 GO/NO-GO 판정 회의입니다. 판정 기준(대사 차이 허용치, 필수 시나리오 통과율)이 사전에 문서로 합의되어 있어야, 새벽 4시의 피로한 회의실에서 즉흥적인 결정이 내려지는 것을 막을 수 있습니다.

리스크 관리 — 단계별 게이트

현대화 프로그램은 단계별 게이트(go/no-go)로 통제합니다.

 [게이트 예시]
  G1 설계 검증   : 핵심 거래 시나리오의 신규 코어 처리 검증(PoC), 성능 목표 합의
  G2 병행 개시   : 그림자 모드 가동, 전수 대사 체계 가동
  G3 부분 컷오버 : 저위험 상품군 전환, 운영 체계(모니터링/장애 대응) 검증
  G4 본 컷오버   : 핵심 상품군 전환, 롤백 리허설 완료가 전제 조건
  G5 레거시 동결 : 신규 거래 차단, 조회 전용 전환, 보존 계획 확정

각 게이트의 판정 기준을 정량화하는 것이 중요합니다. "병행 대사 차이 0건 N일 연속", "신규 코어 P99 응답시간 목표 충족", "장애 모의훈련 통과" 같은 기준이 없으면 게이트는 일정 압박에 뚫립니다.

조직과 인력의 전환

기술 이행보다 어려운 것이 조직 이행입니다.

  • 듀얼 스킬 기간의 설계: 신구 시스템이 공존하는 수년간, 레거시를 아는 인력과 신기술 인력이 모두 필요합니다. 레거시 인력을 "이행의 도메인 전문가"로 재배치하는 경로(도메인 지식의 문서화, 신규 코어의 업무 검증 담당)를 만들지 못하면, 이행 후반에 레거시 지식이 증발하는 사고가 납니다.
  • 운영 모델의 전환: 분해된 코어는 운영 방식도 바꿉니다. 중앙 운영팀의 일괄 배치 관제에서, 서비스 단위 온콜과 SRE 관행으로의 전환이 따라와야 합니다.
  • 업무 부서와의 공동 소유: 상품 팩토리는 "IT가 만들고 현업이 쓰는" 도구입니다. 상품 정의의 책임을 현업으로 이전하는 프로세스(검증 환경, 승인 워크플로, 교육)까지가 프로젝트 범위입니다.
  • 외주 의존도의 관리: 한국 차세대 프로젝트는 전통적으로 대형 SI 중심으로 수행되어 왔습니다. 점진적 현대화는 수년간 지속되는 내재화 역량을 요구하므로, "프로젝트가 끝나면 떠나는 인력" 구조로는 운영 단계가 버티지 못합니다. 핵심 컴포넌트(원장, 상품 팩토리)의 설계·운영 역량은 내재화하고, 외주는 명확한 경계의 모듈에 한정하는 소싱 전략이 필요합니다.

조직 전환의 진척은 기술 진척보다 측정하기 어렵지만, 최소한 "신규 코어 장애를 내부 인력만으로 진단·복구할 수 있는가"라는 질문에는 단계마다 답할 수 있어야 합니다.

실패 패턴 — 반복되는 함정들

  1. 기능 동등성의 저주: "현행과 100 퍼센트 동일하게"를 목표로 잡으면, 레거시의 우연한 동작(버그성 사양 포함)까지 복제하느라 비용이 폭증하고 현대화의 의미가 사라집니다. 차이 허용 목록을 만들고 업무 부서와 합의하는 작업이 필수입니다.
  2. 빅뱅 일정의 정치화: 컷오버 일자가 경영 발표로 먼저 고정되고 품질이 일정에 종속되는 패턴입니다. 게이트 기준의 정량화와 "일정보다 기준" 원칙의 거버넌스 합의가 백신입니다.
  3. 병행 검증 생략: 일정 압박으로 그림자 운영 기간을 줄이면, 컷오버 후 이자 결산·월마감 같은 저빈도 이벤트에서 잠복 결함이 터집니다. 최소 한 번의 분기 결산을 병행 기간에 포함하는 것이 안전합니다.
  4. 데이터 품질 과소평가: 레거시 데이터의 정합성 문제(고아 레코드, 코드 불일치)는 이행 도구가 아니라 업무 판단을 요구합니다. 데이터 클렌징을 프로젝트 초기에 별도 트랙으로 시작하지 않으면 막판 병목이 됩니다.
  5. 신기술 만능론: 이벤트 소싱, MSA 같은 패턴을 "그 자체가 목적"으로 도입하면 분산 시스템의 복잡도가 원장 정합성 리스크로 직결됩니다. 코어의 본질(돈이 맞아야 한다)에 기여하는지가 모든 기술 선택의 기준이어야 합니다.
  6. 벤더 종속의 재생산: 메인프레임 종속을 벗어나려다 특정 클라우드·특정 SaaS 코어에 더 깊이 종속되는 경우입니다. 탈출 비용(데이터 반출, 상품 정의의 이식성)을 계약 단계에서 평가해야 합니다.
  7. 비기능 요구의 후순위화: 성능·재해복구·보안 요건을 "나중에 맞추면 된다"고 미루면, 막판 성능 테스트에서 아키텍처 수준의 재작업이 발생합니다. 초기 PoC 단계부터 피크 부하와 장애 시나리오를 포함해야 합니다.
  8. 이행 조직의 이원화 갈등: 신규 코어 개발팀과 레거시 운영팀이 별도 보고 라인으로 분리되어 정보가 끊기는 패턴입니다. 대사 차이의 원인 분석은 양쪽 지식이 모두 필요하므로, 공동 목표(차이 수렴 지표)를 가진 혼성 조직이 효과적입니다.

로드맵 예시 — 가상의 중형 은행 5개년

가상의 시나리오로 전체 그림을 그려보면 다음과 같습니다.

 1차년도: 기반 구축
   - 코어 도메인 분석, 원장/상품/계산 경계 정의
   - API 게이트웨이·이벤트 스트림 구축, 레거시에 어댑터 부착
   - 데이터 클렌징 트랙 시작, 클라우드 거버넌스(규제 대응) 체계화

 2차년도: 주변부터 전환
   - 정보계·채널의 클라우드 전환, 레거시 부하 경감
   - 상품 팩토리 1차 구축, 신규 수신 상품 1종을 신규 코어에서 파일럿

 3차년도: 그림자 병행
   - 신규 코어 그림자 모드 가동, 전수 대사 체계 운영
   - 분기 결산 1회 이상을 병행 검증으로 통과

 4차년도: 단계 컷오버
   - 저위험 상품군부터 순차 전환, 만기 롤오버 병행
   - 롤백 리허설, 재해복구 전환 훈련 통과를 게이트로 운영

 5차년도: 레거시 동결과 정리
   - 잔여 상품 전환 완료, 레거시 조회 전용 보존
   - 운영 모델 전환 완료(SRE 체계), 회고와 표준화

물론 현실의 일정은 규제 변화, 조직 역량, 우선순위에 따라 크게 달라집니다. 요점은 기간이 아니라 구조입니다. 가치가 조기에 나오는 순서(주변 → 신상품 → 병행 → 단계 전환)와, 각 단계의 정량 게이트가 로드맵의 골격이 되어야 한다는 것입니다.

또 하나 덧붙이면, 로드맵은 한 번 그리고 끝나는 산출물이 아닙니다. 규제 완화의 속도, 신규 코어의 검증 결과, 시장 상황(금리 환경, 경쟁사 동향)에 따라 매년 재평가하는 살아 있는 문서로 운영해야 합니다. 다만 재평가가 잦더라도 게이트 기준 자체를 완화하는 방향의 수정은 경계해야 합니다. 일정은 움직여도 품질 기준은 움직이지 않는다는 원칙이 프로그램의 신뢰를 지킵니다.

진행을 측정하는 지표

다년간의 프로그램은 "느낌"이 아니라 지표로 관리해야 합니다. 실무에서 유용한 지표 세트는 다음과 같습니다.

범주지표보는 이유
가치 전달신규 코어에서 출시된 상품 수, 상품 출시 리드타임현대화가 비즈니스에 닿고 있는지
잠식 진척신규 코어 처리 거래 비중(건수/금액), 이관 계좌 비율스트랭글러의 실제 진도
품질병행 대사 차이 건수 추이, 차이 사유별 분포컷오버 준비도
안정성신규 코어 가용성, P99 응답시간, 장애 건수운영 신뢰 형성
레거시 축소레거시 변경 요청 건수, 배치 잡 수, 라이선스 비용동결이 실제로 일어나는지
조직신규 스택 보유 인력 비율, 레거시 도메인 지식 문서화율인력 절벽 대응

특히 "레거시 변경 요청 건수"는 숨은 명지표입니다. 현대화가 진행 중인데 레거시 변경이 줄지 않는다면, 신규 기능이 여전히 레거시에 들어가고 있다는 뜻이고, 이는 잠식이 아니라 이중 투자가 일어나고 있다는 경고입니다. "레거시 신규 기능 동결" 선언과 예외 승인 절차가 이 지표를 살립니다.

용어집

용어영문의미
차세대Next-generation project코어 전면 재구축형 대형 프로젝트의 한국식 통칭
빅뱅 컷오버Big-bang cutover일시점 전체 전환 방식
스트랭글러Strangler fig pattern신규가 레거시를 점진 잠식하는 전환 패턴
상품 팩토리Product factory상품 정의를 데이터/설정으로 외부화한 구성요소
얇은 원장Thin ledger잔액·거래 기록 본질만 남긴 최소 코어
이중 기재Dual write / parallel run신구 원장에 동시 기록하며 검증하는 기간
전수 대사Full reconciliation표본이 아닌 전체 건 비교 검증
컷오버 게이트Cutover gate단계 진행의 정량 판정 기준
그림자 모드Shadow mode신규 코어가 확정 권한 없이 병행 계산만 수행
만기 롤오버 이행Rollover migration만기 도래 계약부터 신규 코어로 이전
망분리Network separation업무망과 인터넷망의 분리 규제
워룸War room전환 직후 집중 모니터링·의사결정 체제

마치며

코어뱅킹 현대화는 기술 프로젝트라기보다 리스크 관리 프로그램입니다. 빅뱅이냐 점진이냐는 종교 논쟁이 아니라, 조직의 리스크 수용 능력과 도메인 분리 가능성에 대한 공학적 판단의 문제입니다. 분명한 것은 방향입니다. 원장은 작고 단단하게, 상품은 데이터로, 통합은 이벤트로, 이행은 병행 검증으로. 그리고 어떤 화려한 아키텍처를 그리더라도 마지막 질문은 앞의 두 글과 같습니다. "이 전환 과정에서 돈이 틀릴 수 있는 경로는 어디인가?" 그 질문에 단계마다 답할 수 있는 프로그램만이 심장 이식을 완주합니다.

이 시리즈의 앞 두 편(수신 시스템 아키텍처, 이자 계산 엔진)에서 다룬 원장 설계와 검증 규율은, 결국 이 현대화 여정에서 신구 시스템을 비교 가능하게 만드는 공통 언어이기도 합니다. 코어를 바꾸려는 조직이라면, 먼저 현재의 코어를 그 언어로 설명할 수 있는지부터 점검해 보시기를 권합니다.

참고 자료

Discuss on Twitter • View on GitHub