코어뱅킹 시스템 현대화 2026 심층 분석 — Temenos·Mambu·Thought Machine·FIS·NCR·Finacle·BaNCS, 그리고 한·일 메가뱅크 차세대 IT

프롤로그 — 은행의 심장을 바꾼다는 것

코어뱅킹 시스템은 은행에서 가장 보수적인 영역이다. 모바일 앱은 6개월마다 갈아엎어도, 원장(ledger)을 관리하는 코어는 30년 된 COBOL 코드가 그대로 돌고 있는 경우가 흔하다. 이유는 단순하다 — 틀리면 안 된다. 잔액이 1원이라도 어긋나면 그날 저녁 뉴스에 나온다.

그래서 2026년의 화두는 "어떻게 멈추지 않고 심장을 바꾸느냐"다. 영국 Lloyds Banking Group은 2024년 Thought Machine Vault로 마이그레이션을 시작했고, 독일 N26은 Mambu 위에 처음부터 클라우드 네이티브로 지었으며, 한국 KB국민은행은 5년에 걸친 차세대 IT 프로젝트(ACE-Bank)를 진행 중이다. 일본은? 1973년 가동된 全銀시스템이 60년째 돌고 있다 — 하지만 그 뒤에서 NTT Data·NEC가 BeSTA·OperaMaster로 클라우드 전환을 그리고 있다.

이 글은 코어뱅킹 11개 벤더의 지도를 그리고, 한국·일본의 차세대 IT 프로젝트를 짚고, 메인프레임에서 클라우드로 가는 길을 설명한다.

1장 · 코어뱅킹이란 무엇인가 — 원장이 곧 은행이다

코어뱅킹(core banking) 시스템의 정의부터 정확히 잡자. 은행이 처리하는 일은 결국 **계좌(account)·원장(ledger)·여신(loan)·수신(deposit)**의 네 가지 모듈로 환원된다. 이 네 가지를 모두 한 시스템에서 관리하는 게 코어뱅킹이다.

코어뱅킹이 처리하는 일을 펼치면 이렇다.

계좌 관리: 신규 개설·해지·잔액 조회·거래 내역
원장 관리: 모든 거래의 차변/대변(debit/credit) 기록, 일계표·월계표 생성
여신: 대출 신청·심사·상환 스케줄·연체 관리
수신: 정기예금·적금·이자 계산
결제 정산: 타행 이체·국제 송금·카드 결제 후처리
회계 마감: 일일 마감(EOD, end-of-day), 월말·연말 마감

코어뱅킹 외의 시스템들 — 모바일 앱·인터넷뱅킹·ATM·콜센터 — 은 모두 코어를 호출하는 **채널(channel)**이다. 채널은 갈아엎어도 코어가 멀쩡하면 은행은 돌아간다. 반대는 성립하지 않는다.

2장 · 메인프레임 시대 — IBM z/OS와 COBOL의 60년

코어뱅킹의 역사는 곧 메인프레임의 역사다. 1960년대 IBM System/360, 1970년대 System/370, 2000년대 zSeries로 이어진 IBM의 메인프레임 라인업은 지금도 글로벌 100대 은행 중 90개 이상이 사용한다. 운영체제는 z/OS, 언어는 대부분 COBOL, 트랜잭션 모니터는 CICS, 데이터베이스는 DB2 또는 IMS다.

왜 아직도 메인프레임인가? 세 가지 이유다.

신뢰성: z/OS는 한 해 다운타임이 분 단위가 아니라 초 단위다. 99.999% 가용성(연 5분 다운).
처리량: 단일 머신에서 초당 100,000건 이상의 트랜잭션을 처리한다.
이미 돌아간다: 30년간 검증된 코드를 굳이 바꿔야 하나?

문제는 비용과 인력이다. IBM 메인프레임의 MIPS(million instructions per second) 라이선스 비용은 분기에 수십억 원이 들고, COBOL을 다룰 수 있는 엔지니어는 점점 사라진다. 평균 연령이 55세 이상이고, 대학에서는 더 이상 가르치지 않는다. 그래서 "탈메인프레임"이 2010년대부터 화두였다.

차원	메인프레임(legacy)	클라우드 네이티브(modern)
하드웨어	IBM z16, 단일 머신 수십억 원	x86 클라우드, on-demand
OS	z/OS	Linux 컨테이너
언어	COBOL, PL/I	Java, Kotlin, Python, TypeScript
DB	DB2, IMS	PostgreSQL, Cassandra, DynamoDB
처리	배치 중심(EOD)	실시간 이벤트 스트리밍
배포	분기 단위	일 단위 또는 더 자주
인력 풀	줄어듦	풍부함
확장	수직(스케일업)	수평(스케일아웃)

3장 · Temenos T24/Transact — 글로벌 시장 점유율 1위

스위스 본사의 Temenos는 코어뱅킹 시장의 1위 벤더다. 주력 제품인 T24(Transaction 24)는 1993년 출시되어 30년이 넘었지만, 2020년 클라우드 네이티브로 재설계된 Transact 라인이 현재의 주력이다.

Temenos가 강한 이유는 글로벌 표준화다. 150개국 950개 은행이 쓰고 있고, 다국가 지원(다통화·다언어·다법규)이 처음부터 들어가 있다. HSBC·Standard Chartered 같은 다국적 은행이 선호하는 이유다.

기술 스택은 Java 기반에 jBASE라는 자체 DB를 쓴다. 최근에는 Oracle·PostgreSQL도 지원한다. 클라우드 배포는 AWS·Azure·GCP 모두 지원하며, 컨테이너 기반의 Transact Cloud를 밀고 있다.

# Temenos Transact 컨테이너 배포 예시 (Kubernetes)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: transact-core
  namespace: banking
spec:
  replicas: 3
  selector:
    matchLabels:
      app: transact-core
  template:
    metadata:
      labels:
        app: transact-core
    spec:
      containers:
        - name: transact
          image: temenos/transact:R24.AMR.0
          env:
            - name: DB_HOST
              value: postgres-primary.banking.svc.cluster.local
            - name: COMPANY
              value: 'BNK01'
          resources:
            requests:
              memory: '4Gi'
              cpu: '2'
            limits:
              memory: '8Gi'
              cpu: '4'
          ports:
            - containerPort: 2020
              name: tafj

Temenos의 약점은 가격과 복잡성이다. 라이선스 비용이 비싸고, 커스터마이즈에 전문 컨설턴트가 필수다. 한 은행이 도입하는 데 평균 18~~36개월, $50M~~$300M 정도가 든다.

4장 · Mambu — 클라우드 네이티브, API-first의 원조

베를린 본사의 Mambu는 2011년 설립된 SaaS형 코어뱅킹이다. 메인프레임 시대를 건너뛰고 처음부터 AWS 위에서 멀티테넌트로 설계됐다. 2025년 기준 65개국 11,000,000명 이상의 최종 사용자를 서비스한다.

Mambu의 핵심 가치는 세 가지다.

API-first: 모든 기능이 REST API로 노출. 모바일 앱·웹·POS 같은 채널은 API만 호출하면 된다.
클라우드 네이티브: AWS·Azure·GCP에서 멀티테넌트로 운영. 인프라 운영을 은행이 직접 안 해도 된다.
컴포저블 뱅킹(composable banking): Mambu는 코어만 제공하고, 결제·KYC·신용평가는 다른 핀테크 SaaS와 API로 조합. 은행이 "최고의 부품"을 골라 쓰는 모델.

대표 고객은 독일 N26, 영국 ABN AMRO, 호주 86 400, 인도네시아 BTPN. 특히 N26은 Mambu 위에서 유럽 전역에 시장 진입했다.

{
  "comment": "Mambu Loan Account 생성 API 예시",
  "endpoint": "POST /loans",
  "request": {
    "loanName": "Personal Loan - 2026-05-25",
    "loanAmount": "10000.00",
    "interestRate": "8.5",
    "productTypeKey": "8a8e8d2f-personal-loan-product",
    "accountHolderKey": "8a8e8d2f-customer-uuid",
    "accountHolderType": "CLIENT",
    "scheduleSettings": {
      "gracePeriod": 0,
      "repaymentInstallments": 36,
      "repaymentPeriodCount": 1,
      "repaymentPeriodUnit": "MONTHS"
    },
    "disbursementDetails": {
      "expectedDisbursementDate": "2026-06-01T00:00:00+09:00"
    }
  },
  "response": {
    "encodedKey": "8a8e8d2f-loan-account-uuid",
    "accountState": "PENDING_APPROVAL",
    "loanAmount": "10000.00"
  }
}

Mambu의 약점은 복잡한 상품을 만들기 어렵다는 점이다. 표준화된 상품(예금·대출·카드)은 빠르게 출시하지만, 한국·일본처럼 정기예금·적금·청약·우대금리 같은 변형이 많은 시장에는 추가 개발 비용이 크다.

5장 · Thought Machine Vault — 스마트 컨트랙트로 상품을 코드화

런던 본사의 Thought Machine은 2014년 전직 Google 엔지니어들이 설립했다. 핵심 제품 Vault는 코어뱅킹 시장에서 가장 혁신적인 접근으로 평가받는다 — 금융 상품을 코드(스마트 컨트랙트)로 정의한다는 것.

전통적인 코어뱅킹에서 새로운 상품(예: 청년 적금 우대금리)을 만들려면 벤더에 요청해서 패치를 받거나, 컨설턴트가 와서 6개월간 커스터마이즈해야 한다. Vault는 다르다. Contract Language라는 Python-like DSL로 상품 로직을 작성하고, 은행 내부 엔지니어가 배포한다.

# Thought Machine Contract Language 예시 (단순화)
# 정기예금 상품: 1년 만기, 연 4.5%, 중도해지 시 0.5%
api = '4.0.0'
display_name = '1-Year Term Deposit'
parameters = [
    Parameter(name='deposit_amount', shape=NumberShape(min_value=1000)),
    Parameter(name='interest_rate', shape=NumberShape(default_value=Decimal('0.045'))),
    Parameter(name='penalty_rate', shape=NumberShape(default_value=Decimal('0.005'))),
    Parameter(name='term_months', shape=NumberShape(default_value=12)),
]

@requires(parameters=True, balances='latest')
def execution_schedules():
    return [('ACCRUE_INTEREST', {'hour': '0', 'minute': '0'})]

@requires(parameters=True, balances='latest')
def scheduled_code(effective_date, event_type):
    if event_type == 'ACCRUE_INTEREST':
        balance = vault.get_balance_timeseries().at(timestamp=effective_date).net()
        rate = vault.get_parameter_timeseries(name='interest_rate').latest()
        daily_interest = balance * rate / 365
        posting_ins = vault.make_internal_transfer_instructions(
            amount=daily_interest,
            denomination='KRW',
            from_account_id='BANK_INTEREST_EXPENSE',
            to_account_id=vault.account_id,
        )
        vault.instruct_posting_batch(posting_instructions=posting_ins)

이 모델의 장점은 상품 출시 속도다. 전통 코어에서 6개월 걸리는 상품을 Vault에서는 2주에 만들 수 있다. 그리고 모든 상품 로직이 코드 리뷰·테스트·버전 관리되므로 감사성도 좋다.

2024년 영국 Lloyds Banking Group이 Vault로 마이그레이션을 시작했고, 호주 ANZ Plus, 일본 SMBC도 도입했다. 한국에서는 아직 도입 사례가 없지만, 검토 중인 시중은행이 여럿이다.

약점은 새로운 기술 스택을 학습해야 한다는 점이다. Contract Language는 강력하지만, 은행 내부에 이를 다룰 엔지니어가 필요하다. 외주 의존도가 높은 한국·일본 은행에는 진입 장벽이 있다.

6장 · FIS Modern Banking Platform — 미국 시장의 강자

미국 본사의 FIS(Fidelity National Information Services)는 시가총액 수백억 달러의 금융 인프라 거인이다. 2015년 SunGard 인수, 2019년 Worldpay 인수로 결제·트레이딩·자산관리까지 아우른다. 코어뱅킹 라인은 IBS·Profile·HORIZON 등 여러 인수 제품을 통합해 **Modern Banking Platform(MBP)**을 만들었다.

MBP는 미국·캐나다 중소형 은행과 신용조합(credit union)에서 강세다. 특징은 다음과 같다.

모듈식 구조: 원장·여신·수신·카드를 독립 모듈로 배포
클라우드/온프렘 혼합: 보수적인 은행을 위한 온프렘 옵션 유지
레거시와의 호환: 기존 FIS 제품에서 점진적 마이그레이션 경로

      *> FIS HORIZON 코어의 일일 마감 배치 (단순화)
       IDENTIFICATION DIVISION.
       PROGRAM-ID. EOD-INTEREST-ACCRUAL.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-ACCOUNT-RECORD.
           05  WS-ACCT-NO        PIC X(12).
           05  WS-BALANCE        PIC S9(13)V99 COMP-3.
           05  WS-RATE           PIC S9(3)V9(5) COMP-3.
           05  WS-ACCRUED        PIC S9(13)V99 COMP-3.

       PROCEDURE DIVISION.
       MAIN-LOGIC.
           OPEN INPUT  ACCT-MASTER-FILE
                OUTPUT JOURNAL-FILE.
           PERFORM READ-AND-ACCRUE UNTIL EOF-ACCT.
           CLOSE ACCT-MASTER-FILE JOURNAL-FILE.
           STOP RUN.

       READ-AND-ACCRUE.
           READ ACCT-MASTER-FILE INTO WS-ACCOUNT-RECORD
              AT END MOVE 'Y' TO EOF-FLAG.
           COMPUTE WS-ACCRUED ROUNDED =
              WS-BALANCE * WS-RATE / 365.
           WRITE JOURNAL-RECORD FROM WS-ACCOUNT-RECORD.

MBP의 강점은 검증된 안정성이다. 미국 FDIC 규제 환경에 최적화되어 있고, 신용조합 같은 보수적 고객이 30년 이상 쓰고 있다. 약점은 글로벌 확장성이 떨어진다는 점.

7장 · NCR Voyix·Finastra Fusion — 결제·중견 시장 전문

NCR Voyix(구 NCR Corporation에서 2023년 분사)는 ATM·POS 단말 시장의 거인이지만, 코어뱅킹 영역에서는 미국 커뮤니티 뱅크와 신용조합에 특화된 NCR Voyix Digital Banking을 제공한다. 자체 코어보다는 다른 코어와 통합하는 디지털 채널 + 미들웨어 성격이 강하다.

Finastra는 영국·미국 합병으로 탄생한 거인이다. Fusion Banking은 코어뱅킹 라인으로 Fusion Essence(중소형), Fusion Phoenix(미국 신용조합), Fusion Equation(글로벌 대형) 등 시장별 제품군을 가진다. 특히 **무역금융(trade finance)**과 신디케이트 대출(syndicated loans) 영역에서 강세다.

벤더	주요 타깃	강점	약점
Temenos Transact	글로벌 대형/중형	다국가 표준화	비싸고 복잡
Mambu	네오뱅크·핀테크	클라우드/API-first	복잡 상품 어려움
Thought Machine Vault	디지털 뱅크·MZ	스마트 컨트랙트	학습 곡선
FIS MBP	미국 중소형/신협	안정성·미국 규제	글로벌 약함
NCR Voyix	커뮤니티 뱅크	디지털 채널·ATM	코어 자체는 약함
Finastra Fusion	무역금융·신디 대출	도메인 전문성	UI/UX 구식

8장 · Infosys Finacle·TCS BaNCS — 인도가 만든 글로벌 코어

인도 IT 서비스 거인 두 곳이 만든 코어뱅킹 제품이 글로벌 시장의 한 축을 차지한다.

Infosys Finacle은 1995년 출시되어 100개국 1억 명 이상의 고객 계좌를 처리한다. 인도 국영은행(SBI), 영국 RBS, 호주 ANZ 같은 대형 은행이 쓴다. Java/Oracle 기반에서 시작해 최근 Finacle 11J로 클라우드 네이티브화를 진행 중이다. 특히 인도네시아·필리핀·아프리카 같은 신흥 시장에서 점유율이 높다.

TCS BaNCS는 Tata Consultancy Services의 제품으로, 코어뱅킹뿐 아니라 자본시장·보험·연금까지 아우르는 종합 금융 플랫폼이다. State Bank of India, 일본 SBI, 캐나다 Bank of Montreal 같은 큰 고객을 가진다. 일본 시장에서 BaNCS는 SMBC·SBI 등이 도입한 사례가 있어 한국에서도 검토 대상으로 자주 거론된다.

# Finacle 인터넷뱅킹 컴포넌트 헬스 체크 (예시)
curl -s https://finacle-api.bank.example.com/v1/health | jq .
# 응답
# {
#   "status": "UP",
#   "components": {
#     "coreEngine": "UP",
#     "ledger": "UP",
#     "paymentGateway": "UP",
#     "loanModule": "UP"
#   },
#   "version": "11J.1.0"
# }

인도제 코어의 강점은 가격 경쟁력과 신흥 시장 적합성이다. 가격은 Temenos의 절반 이하이고, 외주 인력 풀이 풍부하다(인도 IT 서비스 회사 직원 수십만 명). 약점은 UI/UX의 세련됨이 부족하고, 선진국 시장에서는 Temenos·Mambu에 밀린다.

9장 · Avaloq·SAP for Banking·Oracle Banking — 유럽과 ERP 거인

Avaloq는 스위스 본사로 프라이빗 뱅킹·자산관리(wealth management) 영역에 특화된 코어다. UBS·Credit Suisse·Julius Baer 같은 스위스 프라이빗 뱅크가 주 고객. 일반 리테일 뱅킹이 아니라, 자산 1억 달러 이상의 초고액자산가(HNWI) 관리에 최적화되어 있다. 2020년 NEC에 인수되어 일본 시장 진입도 가속 중이다.

SAP for Banking은 ERP 거인 SAP의 코어뱅킹 라인이다. SAP의 강점은 회계·재무 모듈과의 통합으로, 은행을 하나의 기업으로 본다면 ERP+코어를 동시에 해결한다는 가치다. 다만 출시 후 시장 침투가 더뎌, 2020년대 들어 후순위로 밀렸다.

Oracle Banking(구 i-flex/Flexcube)은 Oracle DB의 강점 위에 만든 코어다. Oracle DB를 이미 쓰는 은행에는 자연스러운 선택. Flexcube는 인도·중동·동남아에서 강세이며, 한국에서는 외국계 은행 지점이 주로 쓴다.

벤더	본사	차별 영역	한국 채택
Avaloq	스위스	프라이빗 뱅킹·WM	외국계 PB 일부
SAP for Banking	독일	ERP 통합	일부 대기업 캡티브
Oracle Banking	미국	Oracle DB 통합	외국계 지점

10장 · 한국 차세대 IT — KB ACE-Bank·신한 SOL·우리·하나

한국 은행 IT는 특이한 생태계다. 벤더 코어를 그대로 쓰지 않고, SI 회사(삼성SDS·LG CNS·SK C&C·KB데이타시스템 등)가 거의 처음부터 만든다. 그래서 같은 한국 5대 은행도 코어 아키텍처가 다 다르다.

은행	차세대 프로젝트	핵심 SI	시기	규모
KB국민은행	ACE-Bank	KB데이타시스템·LG CNS	2021~2026	`$500M+`
신한은행	The New 신한 / SOL	삼성SDS	2019~2024	`$400M+`
우리은행	WIN	우리FIS	2020~2025	`$300M+`
하나은행	New System	하나금융티아이	2022~2027	`$400M+`
농협은행	NH차세대	삼성SDS	2021~2026	`$350M+`

KB ACE-Bank는 한국에서 가장 큰 차세대 IT 프로젝트로, 메인프레임(IBM z/OS)에서 x86 분산 시스템(Linux + Java + Oracle/Tibero)으로 전환한다. 마이크로서비스로 분해하고, Kafka 기반 이벤트 스트리밍을 도입한다. 2026년 가동 목표.

신한 SOL은 모바일 앱 브랜드이자 차세대 시스템 이름이기도 하다. 신한은행은 2021년 차세대를 가동했고, 그 위에 SOL이라는 슈퍼앱을 올렸다. 한국 은행 앱 중 사용성·트래픽 모두 1위권.

한국 은행 IT의 특징:

자체 개발 비중이 높다 — Temenos·Mambu 같은 상용 코어를 그대로 쓰지 않음
금융결제원(KFTC) 의존도가 크다 — 타행 이체·실시간 송금이 KFTC 망을 통과
금융감독원 보안 규제가 엄격하다 — 망분리·인증 등 한국 특유 규제

11장 · 삼성SDS Nexledger·Brity 그리고 한국 금융 블록체인

한국 금융 IT에서 빼놓을 수 없는 것이 삼성SDS의 Nexledger(블록체인 플랫폼)와 Brity 시리즈(AI/자동화)다.

Nexledger는 삼성SDS가 자체 개발한 엔터프라이즈 블록체인 플랫폼으로, 신한은행·하나은행 등의 디지털 자산·서류 인증·KYC 영역에 도입됐다. 코어뱅킹은 아니지만, 코어와 연결되는 부수 인프라로서 한국 금융 IT 지도에 한 축을 형성한다.

Brity Works·Brity Assistant 같은 자동화 도구는 은행 콜센터·내부 업무 자동화에 쓰인다. 차세대 IT 프로젝트들이 이런 자동화 도구를 코어와 통합하는 방향으로 가고 있다.

# 한국 차세대 IT의 전형적 아키텍처 (단순화)
core_ledger:
  language: Java
  framework: Spring Boot
  database: Oracle / Tibero
  message_queue: IBM MQ → Kafka (전환 중)
  deployment: Linux on x86 (메인프레임 탈피)

channels:
  mobile: React Native / Flutter
  internet_banking: React + Spring
  atm: 자체 단말 (Diebold Nixdorf / Wincor)

external_integration:
  kftc: 금융결제원 망 (타행 이체)
  bok_wire: 한국은행 BOK-Wire+ (대고객 결제)
  cls: CLS Bank (외환)
  swift: SWIFT (국제 송금)

security:
  network_segregation: 망분리 (인터넷망 ↔ 업무망)
  authentication: 공동인증서 / 금융인증서 / 생체인증
  encryption: AES-256, HSM (Hardware Security Module)

12장 · 일본 全銀시스템 — 60년 된 결제 인프라

일본의 코어뱅킹은 한국과 또 다른 특이한 생태계다. **全銀시스템(전국은행데이터통신시스템)**은 1973년 가동되어 60년째 운영되는 일본 은행 간 결제 인프라다. 전국은행협회(全国銀行協会)가 운영하고, NTT Data가 시스템을 담당한다. 하루 1,300만 건 이상의 거래를 처리한다.

全銀시스템의 핵심은 **BANCS(Banking Application Network for Communication Services)**라는 NTT Data의 플랫폼이다. 메인프레임 기반이며, 2020년대 후반 8세대 시스템으로 전환을 진행 중이다.

# 全銀시스템 데이터 흐름 (단순화)
은행 A (송금 의뢰)
   ↓ 全銀 프로토콜 (전용선)
全銀시스템 센터 (NTT Data 운영, 도쿄/오사카 이중화)
   ↓ 차액 결제 (BOJ 일본은행 당좌예금)
은행 B (수신)
처리 시간: 평일 영업시간 내 실시간 / 영업시간 외 익영업일

일본 메가뱅크 3사(三菱UFJ·三井住友·みずほ)도 각자 다른 코어를 쓴다.

은행	코어 시스템	핵심 SI	특징
三菱UFJ	MUFG 코어	IBM·NTT Data	메인프레임 중심
三井住友(SMBC)	NEXT-S	NTT Data·NEC	합병 후 통합 진행
みずほ(Mizuho)	MINORI	富士通·日立·IBM	2002·2011·2021 대형 장애 이력

특히 みずほ MINORI는 2018년 가동 후 2021년 2~3월에 ATM 대량 장애가 발생해 사회 문제가 됐다. 합병 은행 3사의 코어 시스템 통합이 너무 복잡했던 결과로 분석된다. 일본 금융청(FSA)이 직접 개입한 사례.

13장 · 일본 코어뱅킹 벤더 — NEC OperaMaster·NTT BeSTA

일본 시장은 글로벌 벤더보다 일본제 코어가 우세하다.

NEC OperaMaster는 일본 지역은행·신용금고용 코어로, 100개 이상의 일본 금융기관이 도입했다. 일본 회계·세무·금융청 보고에 최적화되어 있다.

NTT Data BeSTA(Best-fit Standard banking Application)는 일본 지방은행 80% 이상이 쓰는 사실상 표준이다. 메인프레임 기반에서 클라우드 전환을 진행 중이고, 2024년 출시된 OpenCanvas BeSTA Cloud가 그 결과물이다.

# NTT Data BeSTA Cloud 아키텍처 (공개 자료 기반)
프레젠테이션 계층
  - 모바일/웹 채널 → API Gateway
서비스 계층
  - 계좌 서비스, 대출 서비스, 수신 서비스 (마이크로서비스화)
도메인 계층
  - 원장(ledger) 코어 (메인프레임에서 점진적 이행)
인프라 계층
  - NTT Data 자체 클라우드 (OpenCanvas)
  - Kubernetes + PostgreSQL + Kafka

일본 코어뱅킹의 특징:

합의제 의사결정으로 변경이 느리다 — 한 기능 추가에 1~2년
장애에 극도로 보수적 — みずほ 사태의 영향
외주 의존도가 매우 높다 — 은행 내 IT 인력 적음, NTT Data·NEC·富士通·日立 4대 SI 의존
클라우드 전환이 한국보다 느리다 — 금융청 가이드라인이 보수적

14장 · 마이크로서비스 분해 — 모놀리스 코어를 어떻게 쪼개나

전통 코어뱅킹은 거대한 모놀리스다. 한 줄을 바꾸려면 전체를 다시 컴파일·테스트해야 한다. 클라우드 네이티브 코어는 이걸 마이크로서비스로 쪼갠다 — 하지만 어떻게?

도메인 주도 설계(DDD) 관점에서 코어뱅킹의 자연스러운 경계는 이렇다.

고객(Customer): KYC·계좌 주체 관리
계좌(Account): 계좌 개설·해지·기본 정보
원장(Ledger): 모든 거래의 차변/대변 기록 (단일 진실 원천)
여신(Loan): 대출 상품·심사·상환
수신(Deposit): 예금 상품·이자
결제(Payment): 송금·이체·청구
카드(Card): 체크·신용카드 발급·승인
외환(FX): 환전·국제 송금

각 도메인이 독립 서비스가 되고, REST/gRPC로 통신한다. 핵심 원칙은 각 서비스가 자기 DB를 가진다(Database per Service).

# 마이크로서비스 분해된 코어뱅킹 (단순화 토폴로지)
services:
  customer-service:
    db: PostgreSQL (customers, kyc_records)
    api: gRPC / REST
  account-service:
    db: PostgreSQL (accounts, account_balances)
    publishes: account.opened, account.closed
  ledger-service:
    db: Event Store (append-only) + PostgreSQL (snapshots)
    publishes: posting.created
  loan-service:
    db: PostgreSQL (loans, repayment_schedules)
  payment-service:
    db: PostgreSQL (payments) + Redis (idempotency)
    publishes: payment.initiated, payment.completed
  card-service:
    db: PostgreSQL (cards, authorizations)

infrastructure:
  message_broker: Apache Kafka
  service_mesh: Istio
  observability: OpenTelemetry → Datadog

어려운 점은 분산 트랜잭션이다. 송금 한 건이 출금(account-service) + 원장 기록(ledger-service) + 수신처 입금(account-service)을 동반하는데, 어느 한 단계가 실패하면? 전통 코어는 2PC(2-phase commit)으로 해결했지만, 마이크로서비스에서는 Saga 패턴이 표준이다 — 각 단계를 보상 가능한 단위로 쪼개고, 실패 시 보상 트랜잭션을 발행.

15장 · 이벤트 소싱과 CQRS — 원장의 새로운 패러다임

원장(ledger)은 코어뱅킹의 심장이다. "지금 잔액이 얼마인가"가 아니라, **"이 계좌에 일어난 모든 사건의 역사"**가 본질이다. 이 관점에서 가장 잘 맞는 패턴이 **이벤트 소싱(Event Sourcing)**이다.

전통 코어는 잔액을 한 행에 저장한다.

-- 전통적 잔액 테이블
account_balances (account_id, balance, updated_at)
1001  100000  2026-05-25 09:00:00
-- 송금 후
1001   90000  2026-05-25 10:30:00  -- 이전 잔액은 사라짐

이벤트 소싱은 모든 사건을 저장한다.

-- 이벤트 스토어
events (event_id, account_id, event_type, amount, timestamp)
e001  1001  AccountOpened  100000  2026-05-25 09:00:00
e002  1001  Withdrew        10000  2026-05-25 10:30:00
-- 현재 잔액 = 모든 이벤트의 합 = 90000

장점:

감사 추적이 자동 — 모든 변경이 영원히 보존
버그 복구가 가능 — 잘못된 거래를 보상 이벤트로 정정
CQRS와 자연스럽게 결합 — 읽기 모델을 여러 개 만들 수 있음

CQRS(Command Query Responsibility Segregation)는 쓰기와 읽기를 분리한다. 쓰기는 이벤트를 추가하고, 읽기는 이벤트로부터 만든 다양한 뷰(잔액·거래 내역·세무 보고용 등)를 본다.

# 이벤트 소싱 + CQRS 흐름
1. Command: Withdraw $10000 from account 1001
2. Event Store: 이벤트 추가 (Withdrew, 10000, 2026-05-25T10:30)
3. Event Bus: 이벤트 발행
4. Read Model 1 (Balance View): 잔액 -10000 갱신
5. Read Model 2 (Transaction History): 거래 내역 추가
6. Read Model 3 (Tax Report): 세무 집계 갱신

Thought Machine Vault가 이 패턴의 모범 사례다. 모든 거래가 Posting이라는 이벤트로 영구 기록되고, 잔액은 파생된 읽기 모델이다.

16장 · 실시간 vs 배치 — RTGS와 EOD의 공존

코어뱅킹의 처리 모델은 **실시간(real-time)**과 **배치(batch)**의 두 축이 있다.

배치(EOD, end-of-day): 영업시간이 끝난 후 그날 거래를 집계해서 마감. 이자 계산·세무 집계·일계표 생성이 여기 들어간다. 메인프레임 시대의 표준 모델이고, 지금도 회계상 일일 마감은 필요하다.

실시간(RTGS, Real-Time Gross Settlement): 거래가 발생한 즉시 양 계좌가 갱신되고 결제 망에 반영. 24/7로 운영. 카카오뱅크·N26 같은 디지털 뱅크가 처음부터 채택한 모델.

차원	배치(EOD)	실시간(RTGS)
처리 단위	하루치 모아서 한 번	거래마다 즉시
결과 가시화	다음 날 아침	수 초 이내
인프라	메인프레임 + DB2	Kafka + 마이크로서비스
장애 영향	마감 지연	즉시 사용자 영향
운영 시간	영업시간	24/7

한국은 이미 2001년부터 실시간 이체를 표준화했다(금융결제원 망). 이 점에서 한국은 전 세계에서 가장 앞선 결제 인프라 중 하나다. 일본은 全銀시스템이 실시간이지만 영업시간 외에는 익영업일 처리로 보수적이다. 유럽은 SEPA Instant Credit Transfer가 표준화됐고, 미국은 FedNow가 2023년에야 가동되어 후발주자다.

17장 · 한국 결제 인프라 — 금융결제원·BOK-Wire+·오픈뱅킹

한국 결제 망의 구조를 짚자.

금융결제원(KFTC): 은행 간 소액 결제 망. 타행 이체·실시간 송금이 여기 통과. 1986년 설립.
BOK-Wire+: 한국은행이 운영하는 거액 결제 망. RTGS 방식. 일반 사용자는 직접 접하지 않지만, 1,000,000,000 원 이상의 거액은 여기로 간다.
오픈뱅킹(2019~): 핀테크가 모든 은행 계좌에 API로 접근 가능. 토스·카카오페이 같은 핀테크 폭발의 인프라.
마이데이터(2022~): 금융 정보 통합 조회. 본인의 모든 금융 데이터를 한 곳에 모음.

# 한국 오픈뱅킹 데이터 흐름 (단순화)
사용자 → 핀테크 앱(토스 등)
   ↓ 인증/동의
핀테크 → 금융결제원 오픈뱅킹 API
   ↓ 각 은행 코어 호출
은행 (KB·신한·우리 등) → 잔액·거래내역 응답
   ↓
사용자에게 통합 화면 제공

이 인프라 덕에 한국은 세계에서 가장 핀테크 친화적인 시장 중 하나가 됐다. 토스·카카오뱅크·네이버페이가 짧은 시간에 시장을 장악한 배경.

18장 · 일본 결제 인프라 — Zengin·BOJ-NET·코드 결제 후발

일본 결제 망은 두 축이다.

全銀시스템(Zengin): 은행 간 소액 결제. 1973년 가동.
BOJ-NET: 일본은행 거액 결제 망. 한국 BOK-Wire+와 유사.

코드 결제(QR·바코드 결제)는 PayPay·LINE Pay·楽天Pay 등이 있지만 한국·중국에 비해 보급이 늦었다. 일본은 현금 사용 비중이 여전히 높다(2024년 기준 약 35%로 OECD 평균보다 높음).

2023년 全銀시스템 대형 장애가 있었다 — 시스템 갱신 작업 중 8월 며칠간 타행 이체가 멈춰서 일본 사회 전체에 영향. 60년 된 인프라의 한계가 드러난 사건. 이후 NTT Data가 클라우드 전환 가속을 발표했다.

19장 · 네오뱅크의 코어 선택 — Chime·Monzo·N26·Revolut

네오뱅크(neobank)는 점포 없이 모바일로만 운영하는 디지털 은행이다. 이들이 어떤 코어를 골랐는지 보면 코어뱅킹 시장의 트렌드를 읽을 수 있다.

네오뱅크	본사	코어	사용자 수(2025)
Chime	미국	Galileo (Stripe 자회사) + 자체	30M+
Monzo	영국	자체 개발(Go·Kubernetes)	11M+
Revolut	영국	자체 개발	50M+
N26	독일	Mambu	8M+
Nubank	브라질	자체 + Clojure 기반	100M+
카카오뱅크	한국	자체 + LG CNS	25M+
토스뱅크	한국	자체	10M+

흥미로운 점: 대부분의 네오뱅크는 자체 코어를 만들었다. Mambu 같은 SaaS를 쓴 경우는 N26·86 400처럼 빠르게 시장 진입한 케이스. 규모가 커지면 결국 자체 개발로 전환하거나, 깊은 커스터마이즈를 한다.

이유는 차별화다. 표준 코어를 쓰면 표준 상품만 만들 수 있고, 표준 상품으로는 경쟁사와 차별화가 어렵다. 그래서 규모가 큰 디지털 뱅크일수록 자체 개발 비중이 높다.

한국 카카오뱅크는 LG CNS가 코어를 만들었지만, 그 위의 모든 상품 로직과 채널은 카카오뱅크 자체 엔지니어가 짰다. 토스뱅크는 처음부터 자체 코어로 시작.

20장 · 코어 마이그레이션 전략 — Strangler Fig 패턴

레거시 코어를 클라우드 네이티브로 옮기는 일은 수년에 걸친 프로젝트다. "어느 날 밤 갈아끼우기"는 불가능. 그래서 Strangler Fig 패턴(Martin Fowler 명명)이 표준이다.

핵심은 레거시를 죽이지 않고, 새 시스템이 점진적으로 기능을 흡수하는 것이다. 마치 나무 줄기를 천천히 감싸 죽이는 무화과나무처럼.

# Strangler Fig 마이그레이션 단계
Phase 1 (1~2년):
  - 새 시스템에 facade(라우터) 배치
  - 모든 요청이 facade를 거침
  - facade가 100% 레거시로 라우팅
  - 기존 시스템 동작 변화 없음

Phase 2 (2~3년):
  - 비핵심 모듈부터 새 시스템으로 이관 (예: 보고서·통계)
  - facade가 일부는 신, 일부는 구로 라우팅
  - 데이터는 양방향 동기화

Phase 3 (3~5년):
  - 핵심 모듈 이관 (계좌·원장)
  - 듀얼 라이트(dual write) → 비교 검증
  - 점차 신시스템 비중 확대

Phase 4 (5년+):
  - 레거시 단계적 폐기
  - facade 제거 또는 단순화
  - 메인프레임 종료

이 과정에서 핵심은 데이터 일관성이다. 두 시스템을 동시에 운영하면 잔액이 어긋날 위험이 있다. 대부분의 은행이 일정 기간 양쪽에 쓰고 매일 reconciliation(대조)을 돌린다.

한국 KB ACE-Bank가 정확히 이 패턴을 따른다. 2021년 시작해서 단계적으로 모듈 이관 중이며, 2026년 전체 가동 목표.

21장 · 규제와 컴플라이언스 — 코어가 짊어진 짐

코어뱅킹은 기술 이상의 영역이다. 규제 준수가 절반이다.

글로벌 주요 규제:

Basel III/IV: 자본 적정성·유동성 비율
AML/CFT: 자금세탁방지·테러자금조달방지
KYC: 고객 신원 확인
GDPR: 개인정보보호 (유럽)
PCI DSS: 카드 정보 보호

한국 특화:

금융감독원(FSS) 전자금융감독규정
개인정보보호법(PIPA): GDPR 유사
신용정보법: 신용정보 처리 제한
망분리: 인터넷망과 업무망 물리 분리

일본 특화:

금융청(FSA) 종합 감독 지침
個人情報保護法(APPI): 개인정보보호법
マイナンバー(My Number) 처리 규제

코어뱅킹 벤더를 선택할 때 이 규제 대응이 얼마나 잘 되어 있는가가 핵심 평가 항목이다. Mambu·Thought Machine 같은 신생 클라우드 벤더는 신흥 시장 진입은 빠르지만, 한국·일본 같은 보수적 규제 시장은 검증에 시간이 걸린다.

22장 · 비용 모델 — 라이선스, SaaS, 자체 개발

코어뱅킹 도입 비용은 크게 세 모델이다.

1. 영구 라이선스(perpetual license): 전통 모델. 라이선스 1회 구입 + 연 유지보수(20~~25%). Temenos·FIS·Finastra가 이 모델. 초기 비용 $10M~~$300M, 매년 유지보수 $2M~$50M. 클라우드 SaaS로 이동 중.

2. SaaS/구독: Mambu·Thought Machine. 사용자 수·트랜잭션 수 기반 월/연 과금. 초기 진입 비용 낮음, 운영 비용은 트래픽 비례.

3. 자체 개발: 한국·중국 대형 은행·네오뱅크. 초기 투자 $100M~~$500M, 인력 수백~~수천 명. 장기적으로는 유연성 최고지만 리스크도 큼.

모델	초기 비용	운영 비용	유연성	리스크
영구 라이선스	매우 높음	중	중	벤더 종속
SaaS	낮음	변동	중하	가격 인상
자체 개발	매우 높음	인건비	최고	실패 시 큰 손실

23장 · 코어뱅킹의 미래 — AI·블록체인·CBDC

2026년의 코어뱅킹이 향하는 방향.

1. AI 통합: LLM을 활용한 고객 응대·이상거래 탐지·신용 평가. 코어 위에 AI 레이어가 올라가는 형태. 한국 KB·신한이 적극적.

2. 블록체인/DLT 통합: 분산 원장이 전통 원장을 보완. SWIFT를 대체하는 국경 간 결제(JP Morgan Onyx·Partior)에서 시작. 한국 삼성SDS Nexledger가 같은 흐름.

3. 중앙은행 디지털화폐(CBDC): 각국 중앙은행이 디지털 화폐 시범 운영. 중국 e-CNY가 가장 앞섰고, 한국은행도 2024년부터 파일럿 진행. CBDC가 가동되면 코어뱅킹은 중앙은행 시스템과의 직접 연결이 필요해진다.

4. 임베디드 뱅킹(embedded banking): 코어뱅킹 API가 비은행 앱(택시·커머스·SaaS)에 직접 통합. BaaS(Banking-as-a-Service)의 본격화. Mambu·Solaris·Treasury Prime이 이 시장.

5. 양자내성 암호: 2030년대 양자컴퓨터가 RSA를 깰 수 있다는 우려. 코어뱅킹의 암호 인프라가 PQC(post-quantum cryptography)로 전환 시작.

24장 · 정리 — 이 글 다음에 무엇을 볼까

코어뱅킹 시스템은 은행의 심장이다. 1970년대 IBM 메인프레임 위의 COBOL이 2026년에는 Kubernetes 위의 Java/Kotlin/Python으로 재탄생한다. Temenos·Mambu·Thought Machine·FIS·NCR·Finastra·Finacle·BaNCS·Avaloq·SAP·Oracle — 11개 글로벌 벤더 각각이 다른 시장과 다른 가치를 가진다. 한국은 SI 회사가 만드는 자체 코어가 강하고, 일본은 NTT Data·NEC가 만든 일본제 코어가 우세하다.

핵심은 **"무엇을 살 것인가"가 아니라 "왜 바꾸는가"**다. 메인프레임은 신뢰성이 검증된 자산이고, 클라우드는 속도와 비용 효율의 기회다. 결국 답은 하이브리드이며, 5~10년에 걸친 점진적 마이그레이션이 현실이다.

다음 단계로 볼 만한 주제:

결제 시스템 전반(SWIFT·SEPA·FedNow·全銀)
BaaS(Banking-as-a-Service) 시장
CBDC와 디지털 자산
한국 핀테크 생태계(토스·카카오뱅크·네이버페이)
일본 메가뱅크 IT 거버넌스

References

Temenos Transact Documentation — https://docs.temenos.com/
Mambu Developer Portal — https://api.mambu.com/
Thought Machine Vault Contract Language Docs — https://docs.thoughtmachine.net/vault/
FIS Modern Banking Platform — https://www.fisglobal.com/en/banking/modern-banking-platform
NCR Voyix Digital Banking — https://www.ncrvoyix.com/financial-services
Finastra Fusion Banking — https://www.finastra.com/solutions/banking
Infosys Finacle — https://www.edgeverve.com/finacle/
TCS BaNCS — https://www.tcs.com/what-we-do/products-platforms/tcs-bancs
Avaloq — https://www.avaloq.com/
SAP for Banking — https://www.sap.com/industries/banking.html
Oracle Banking — https://www.oracle.com/industries/financial-services/banking/
KB국민은행 ACE-Bank 차세대 IT 보도자료 — https://www.kbstar.com/
신한은행 The New 신한 — https://www.shinhan.com/
삼성SDS Nexledger — https://www.samsungsds.com/kr/blockchain/nexledger.html
금융결제원(KFTC) 오픈뱅킹 — https://www.kftc.or.kr/
한국은행 BOK-Wire+ — https://www.bok.or.kr/
NTT Data BeSTA / BANCS — https://www.nttdata.com/jp/ja/services/besta/
NEC OperaMaster — https://jpn.nec.com/financial/
全国銀行協会全銀시스템 — https://www.zenginkyo.or.jp/
日本銀行 BOJ-NET — https://www.boj.or.jp/paym/bojnet/index.htm/
Martin Fowler — Strangler Fig Application — https://martinfowler.com/bliki/StranglerFigApplication.html
Domain-Driven Design (Eric Evans, 2003) — Addison-Wesley
Building Event-Driven Microservices (Adam Bellemare, 2020) — O'Reilly
BIS — Real-Time Gross Settlement Systems — https://www.bis.org/cpmi/publ/d22.htm
Basel Committee on Banking Supervision — https://www.bis.org/bcbs/
Mambu — The State of Cloud Banking Report — https://www.mambu.com/insights/reports
Thought Machine — Lloyds Banking Group Migration Announcement (2024) — Thought Machine press release
IBM z/OS and Mainframe Modernization — https://www.ibm.com/z