[Study27] 금융권 IT시스템 알아보기

https://12bme.tistory.com/237, https://m.blog.naver.com/agapeuni/222975289239

[시스템용어] 금융권 IT시스템에 대한 이해

블로그를 읽고 정리했습니다.거의 그대로 배껴와따고보면되고, 만약 제 글을 보실 분들이면 위 글을 보시는 걸 추천합니다.

 

금융권....딱봐도 뭔가 엄청난 백업  ,  관리분리 등이 있을 것 같죠

단순한 서버 집합이 아니라, 돈의 흐름을 안전하게 처리하기 위한 초대형 미션 크리티컬 시스템입니다.

시스템은 크게 5개로 구분되어요.

 

1. 계정계

2. 정보계

3. 대외계

4. 운영계

5. 기업 업무 시스템

 

1. 계정계

모든 돈의 흐름을 처리해요.

담당 업무로써는 ( 수신 , 여신, 외환, 카드, 신탁, 보험, 공통업무 )를 맡습니다.

 

특징은 계좌, 거래 데이터 수십억~수백억 건이 있습니다. 그래서 장애 발생 시 즉시 금전 손실이 일어납니다. 그걸방지하기위해 이중, 삼중 백업을하고 강력한 트랜잭션관리를 해요. 완전 정형화된 원장(ledger) 중심 구조인거지요.

 

기술적 특성으로는, 전통적으로는 MainFrame에서 Unix로 들어가고,

Cobal에서 C ㅇ에서 java로 도입되어요.

극단적 안정성을 우선합니다. 미들웨어 중심 트랜잭션 처리합니다.

핵심키워드가 ACID 트랜잭션, 원장 시스템, 보수적 운영, 고가용성(HA)입니다.

 

2. 정보계

데이터를 처리하는 곳이 아니라, 분석하는 곳입니다.

담당업무는 ( 성과분석, 고객 관계 관리, 위험관리, 수익성 분석, 전략 수립 )입니다.

특징은 데이터 웨어하우스(DW)기반이고, 대량 Join , 배치처리등을 처리합니다. 통계 집계 중심이어요.

핵심 키워드는 DW, ETL, 배치, 분석, BI입니다

 

3. 대외계

은행 밖과 연결되는 모든 창구에요.

담당 업무는 (인터넷뱅킹,모바일뱅킹, ATM,텔레뱅킹, 펌뱅킹,금융공동망)입ㄴ니다.

대부분 대용량보단 정확성, 무결성을 중시해요. 트랜잭션 허브형태인거죠.

핵심키워드는 Gateway, 전문 처리, 인터페이스, 연계 허브입니다.

 

4.운영계

시스템을 운영하는 시스템이어요.

담당 업무는( 통합관제, 장애 모니터링, 네트워크 관리, 서버자원관리)입니다.

 

5.기업 업무 시스템은

은행이라는 회사가 돌아가기 위한 시스템입니다.

담당 업무는 (회계,인사,세무,총무)등과 같은 업무입니다. 

 

 

그래서 은행 IT시스템의 공통 특징은

1. 안정성>속도>편의성

2. 데이터 중심 구조

3. 기존 시스템을 쉽게 폐기하지 않음

4. 복잡한 N-Tier구조

5. 주야간 분리패턴

 

입니다.

 

 

차세대 시스템은?

2000년대 초반부터 은행 전반의 구조를 통째로 고도화하는 초대형 프로젝트입니다.

노후 시스템의 교체 / 채널 통합 / 표준 아키텍처 도입 / 확장성 확보를 합니다.

 

기간계, 레거시 시스템은?

기간계는 새로운 시스템 도입 시점에 기존에 사용하던 시스템을 말합니다.

업계에서는 레거시 시스템이라고 편하게 불러요.

 

 

 

용어는 이정도면 됐고 

현재 은행 시스템에 대한 소개를 해볼게요.

https://toss.tech/article/slash23-corebanking를 그대로 따왔습니다 ㅎㅎ

 

현재 은행 시스템

0)전체 그림 : 채널계 MSA + 코어뱅킹 모놀리식의 충돌

전통 은행 아키텍처를 단순화하면

채널계-> 웹,앱,ATM등 고객 요청을 받아서 코어뱅킹에 전달

코어뱅킹 (계정계) -> 잔액,원장,거래내역,회계처리 등 핵심 비지니스 로직을 짭니다.

 

토스뱅크에선 채널계는 이미 MSA였지만, 코어뱅킹은 MCI/FEP/EAI 같은 연계 컴포넌트까지 강결합된 거대한 모놀리식이었다고 설명합니다( 예시를들면, 고객 접점은 민첩한데, 돈이 오가는 핵심은 덩치 큰 단일 서버 )라는 구조적 불균형이 있던 상황이죠.

 

* 모놀리식이 뭐야?

-> 하나의 애플리케이션 안에 모든 기능이 통합되어있는 구조.하나의 프로젝트는 하나의 빌드 결과물이나오고, 하나의 서버 프로세스를 구성하기에 모든 기능이 한 코드 베이스에 있습니다.

비교로 마이크로서비스 아키텍처. 즉 MSA가 나오는데, 기능별로 서비스를 분리합니다. 서비스마다 독립적으로 배포하는거죠.

예를들어, 인증서비스는 DB1과 연결하고, 유저 서비스는 DB2와 연결하고...이런식으로 분리하는거죠.

한줄로 요약하자면

모놀리식은 모든 기능을 하나로 묶은 구조

MSA는 기능을 쪼개어 여러 서비스로 나눈 구조입니다.

 

1) 왜 코어 뱅킹이 모놀리식인가?

기술 블로그의 요지는, 역사적으로 다양한 채널 요청을 한 곳에서 처리하는 방향으로 발전하면서 모놀리식이 굳어졌습니다.

 

- 코어뱅킹은 원장/잔액/회계가 얽혀 있어 “한 번에 같이 커밋되는 트랜잭션”이 매우 중요합니다.

==>그래서 “한 DB 트랜잭션으로 ACID 보장”이 쉬운 모놀리식이 오래 버텼습니다.

 

그러나 모놀리식 코어뱅킹에는장점도 있지만, 치명적인 한계가 있습니다.

장점은

1. 로컬 DB트랜잭션으로 여러 하위 도메인 데이터를 ACID하게 변경 가능합니다.

2. 단일 코드 베이스라 개발이 단순합니다.

3. 인력 수급,운영이 보편적입니다.

단점은

1. 부분 스케일 아웃이 불가능합니다. 특정업무(카드이벤트)만 트래픽이 폭증해도 코어 전체를 키워야하고

2. 영향도 격리가 실패합니다. 하나의 컴포넌트가 장애가 일어나면 전 업무 마비로 이어집니다.

 

특히 토스뱅크에서는 이벤트를 엄청 많이하는데...이벤트가 몰리고 다른 실험도 있으면 고객에게 영향이 갈 수 있다는겁니다.

 

* ACID와 DB트랜잭션이 뭐야?

-> 트랜잭션은, 데이터베이스에서 수행되는 작업들의 하나의단위입니다.

계좌이체를 예시로 들면, A계좌에서 -1000원이면, 다른계좌에선 +1000원이 되어야해요.이 두작업을 하나의 트랜잭션이라고 부릅니다.

 

ACID는 트랜잭션이 반드시 지켜야 할 4가지 특성입니다.

글자의미한 줄 설명

 

A	Atomicity (원자성)	전부 성공 or 전부 실패(출금 성공, 입금실패시 전부 실패)
C	Consistency (일관성)	규칙을 항상 만족(잔액은 음수가 되면안됨,주문금액 = 상품가격 *수량
I	Isolation (격리성)	동시에 실행돼도 서로 간섭 X( 동시에 여러 트랜잭션이 실행돼도, 각자 혼자 실행되는 것처럼보임)
D	Durability (지속성)	성공한 결과는 영구 저장(트랜잭션이 커밋되면, 서버가 꺼져도 데이터유지)

2) 왜 하필 지금 이자 받기부터 분리했느가?

기술 블로그에선, 트래픽이 가장 많고 대표 서비스라서 , 지금 이자받기를 먼저 분리해서 MSA로 전환했습니다.

 

• 트래픽/비용/병목이 명확해서 개선 효과가 크게 측정됨
• 서비스 단위 경계가 비교적 선명(이자 지급이라는 bounded context)
• 장애 격리 효과가 큼(코어 전체 장애와 분리해 생존 가능)

 

 

 

3) 새 코어 뱅킹 MSA의 기술 스택 선택

채널 서버에서 쓰던 것과 동일한 생태계를 채택합니다.

쿠버네티스 / 스프링부트 / 코틀린 / JPA / Kafka / Redis죠.

핵심 포인트는 기술 그자체보다 운영 관성/표준을 맞춰요.

 

코어뱅킹은 규제·감사·장애 책임이 커서 신규 기술 도입 시 “운영 표준화”가 더 중요합니다. 그래서 채널계에서이미 검증된 체계를 코어로 확장하는 전략을 합니다.

* 채널계가 뭐야?

-> 고객이 직접 사용하는 모든 접점 서비스입니다.

모바일 뱅킹 앱, 인터넷 뱅킹 웹 , ATM , 오픈뱅킹 API등과 같은거죠

사용자 요청을 받아서 코어뱅킹에게 전달하는 앞단 시스템입니다.

코어뱅킹에게 요청접수/화면제공/API제공등을 하고, 코어뱅킹이 실제 금융 처리를 해요.

 

 

5) “도메인 분리”를 어디까지 할 것인가 (MSA 설계의 핵심 고민)

테크 블로그에선, 지금 이자 받기’에 필요한 도메인이 고객/상품(금리)/회계라서,

이것을 한 서비스에 다 넣으면 MSA 장점을 못 살린다고 보고 도메인 단위로 나누기로 결정합니다.

 

여기서 중요한 설계 결론은:

• “하나의 큰 트랜잭션으로 묶어야 하는 것”과
• “API 호출로 느슨하게 엮어도 되는 것”을 구분했다는 점입니다.

실전 관점으로 풀면:

(1) 트랜잭션 경계

‘지금 이자 받기’에는 보통 아래 단계가 있습니다.

1. 고객/계좌 상태 확인
2. 적용 금리 조회
3. 이자 계산
4. 이자 지급(잔액 갱신 + 거래내역)
5. 회계 분개/전표
6. 세금 처리

이 중 잔액/거래내역/원장 무결성은 강한 일관성이 필요합니다.
반면 “세금/통계/일부 회계 후처리”는 “지연되어도 즉시 사고가 나지 않는 영역”이 섞여 있습니다. (토스는 이 지점을 기준으로 비동기 분리를 합니다. )

(2) 분리 방식

• 트랜잭션으로 엮이지 않아도 되는 도메인은 별도 마이크로서비스화
• 서비스 간 의존성은 API 호출로 느슨화

즉, “전부 분리”가 아니라 “돈의 원장 무결성이 깨지는 지점은 강하게, 나머지는 느슨하게”라는 보수적 MSA입니다.

 

 

 

6) 동시성 제어: 은행에서 가장 위험한 구간

원문은 동시성 문제를 아주 직관적으로 설명합니다.

0.01초 사이에

• Tx1: 지금 이자 받기(잔액 +100)
• Tx2: 타행 입금(잔액 +300)  가 동시에 들어오면,

서로의 변경을 모른 채 “100 기준으로 각각 갱신”해 잘못된 최종 잔액이 생길 수 있습니다.

 

은행에서는 이 “동시 갱신 채널”이 앱뿐 아니라 타행/ATM/자동이체 등 매우 많아서, 단순한 애플리케이션 락으로는 부족하다는 맥락도 명시합니다.

토스의 해결: Redis Global Lock + DB Row Lock(JPA @Lock)

기술블로그에선,  Redis Global Lock에 더해 DB Layer에서 JPA의 @Lock으로 동시성을 제어

실무적으로 정리하면:

• Redis Lock: “동시에 몰리는 요청을 1차로 정리”하는 분산 락(빠른 문지기)
• DB Row Lock: 최종 진실(원장/잔액)은 DB가 강제하는 락으로 직렬화 (정합성의 마지막 방어선)

또한 중요한 운영 포인트를 직접 언급합니다.

• 락을 잡아야 할 데이터를 명확히 식별
• 갱신 데이터에만 락을 획득해야 데드락/성능저하 예방
• ‘지금 이자 받기’는 계좌 단위 현재 잔액 Row에만 락이 걸리도록 설계
• 락 대기를 사용자에게 티 나지 않게 재시도/타임아웃 적용

즉, “전역 락으로 통째로 잠그는” 방식이 아니라, 계좌 단위로 최소 잠금 범위를 줄여 은행 트래픽을 감당 가능하게 만든 설계입니다.

 

 

왜 Redis 락 “만”으로는 부족한가?

Redis 분산 락은 흔히 이렇게 씁니다:

• 키: lock:account:{accountId}
• 락 획득 성공한 요청만 진행
• 실패하면 대기/재시도

근데 은행급 환경에서는 Redis 락만으로는 구멍이 생길 수 있습니다.

 

(A) 락이 “DB의 진실”을 강제하지 못함

Redis 락이 잡혀 있어도 DB에서는 여전히 동시 UPDATE가 가능한 구조입니다.
즉, 어떤 이유로 락을 우회하거나(버그), 락이 풀리거나(만료), 락을 안 거는 경로가 생기면 DB는 그대로 뚫립니다.

 

(B) 락 만료/네트워크 분리/프로세스 장애 같은 운영 이슈

 

- 락 TTL이 너무 짧으면: 트랜잭션이 끝나기 전에 락이 풀려 동시에 두 요청이 들어갈 수 있음

- TTL이 너무 길면: 장애 시 락이 오래 살아서 계좌 거래가 “멈춘 것처럼” 보임

- Redis 지연/장애: 락 획득 자체가 병목 또는 단일 장애점(SPOF)이 될 수 있음 . 은행은 “락이 깨졌을 때도 최종 정합성”을 보장해야 하니, 마지막 방어선은 DB가 해야 합니다

 

3) DB Row Lock이 “마지막 방어선”인 이유

DB Row Lock은 말 그대로:

특정 계좌의 “현재 잔액 row”를 DB가 잠그고,
다른 트랜잭션은 그 row에 대해 갱신/잠금 시도를 하면 “대기”하도록 강제

즉, DB가 물리적으로 직렬화(serialization) 를 보장합니다.
그래서 락을 안 걸거나 Redis에 문제가 있어도, DB에서 최종적으로 “한 번에 한 트랜잭션만” 잔액 row를 바꾸게 만들 수 있어요

 

 

 

7) 성능 개선: Kafka로 “트랜잭션에서 빼도 되는 것”을 빼기

원문에서 성능 병목은 매우 구체적입니다.

• 이자 1회 지급에
  • 20개 테이블
  • 80번의 UPDATE/INSERT
• 평균 응답 300ms, 코어뱅킹 중 느린 편

토스는 “정규화/인덱스로는 한계”라고 보고, 트랜잭션에서 분리 가능한 DML을 Kafka로 분리합니다.

 

분리 기준(이게 핵심)

잔액/통장 관점에서 DB 쓰기 지연이 생겨도 실시간 문제가 발생하느냐?

• 반드시 트랜잭션이 보장되어야 하는 데이터: 동기 트랜잭션 유지
• 즉시성이 덜한 데이터(예: 세금 처리): 비동기로 분리

구현 패턴

• 이자 지급 트랜잭션 종료 시점에 “세금 토픽”에 Produce
• 비동기 서버가 Consume → 세금 DB 반영
• 실패 대비: **DLQ(Dead Letter Queue)**로 안정성 확보
• 재처리 대비: 멱등성(idempotency) 있는 API/처리 설계

효과

• DML 80회 → 50회로 감소

여기서 얻을 수 있는 “은행형 MSA 교훈”은:

• 코어뱅킹에서 비동기화를 하려면 “아무거나 이벤트로 빼는 게 아니라”
• 정합성이 필요한 원장 축과 지연 허용 가능한 주변 업무를 엄격히 구분해야 합니다.

 

8) Redis 캐싱: “하루 1번”이라는 비즈니스 제약을 성능으로 바꾸기

기술블로그에선, 이자 계산은 원래 “일자별 거래내역 DB를 조회해서 연산”하는 구조라서 느림
그런데 고객은 “하루에 1번만 이자를 받을 수 있음” → 캐시로 DB I/O를 하루 1번으로 줄일 수 있다

캐싱 전략의 정석 포인트

• “계좌 상세탭 접근” 시 매번 DB 계산하던 것을,
• 하루 중 첫 접근만 DB, 결과를 Redis에 캐시
• 이후 접근은 Redis 값 반환
• TTL을 하루로 둬서 자정 이후 자동 갱신되게 함(정합성까지 확보)

이 설계가 좋은 이유는:

• 캐시 키의 일관성이 명확(계좌 + 날짜)
• TTL 정책이 비즈니스 룰(일 단위)과 정확히 일치
• “캐시 무효화 지옥”이 상대적으로 덜함

 

9) 가장 어려운 파트: 기존 코어를 멈추지 않고 ‘검증하면서’ 전환하기

토스는 전환을 단순히 “라우팅 바꾸고 끝”이 아니라, 검증-정합성-점진적 전환 3단계로 밀어붙입니다.

9-1) 온라인 실시간(Shadow) 검증

• 고객이 이자 조회를 요청하면,
  • 기존 코어뱅킹 호출(MCI 통해)
  • 동시에 신규 이자 마이크로서비스 호출
• 두 응답(이자값) 비교
• 불일치 시 내부 모니터링 채널로 알림 → 원인 분석 → 로직 수정 반복

이 방식의 장점:

• 실제 트래픽/실제 데이터로 검증(현실 반영)
• 신규 서비스가 고객 응답을 “대체”하지 않아 리스크가 낮음(관찰만)

9-2) 배치 기반 대량 검증(스테이징)

• 스테이징(운영과 동일 구성)에서
• 매일 대량 대상 추출 → 코어/신규 둘 다 호출 → 불일치 알림

이 방식의 장점:

• 엣지 케이스가 대량으로 빨리 드러남
• 운영 부하 없이 비교 가능

9-3) “지금 이자 받기(실제 지급)”의 정합성 검증은 더 빡세다

조회는 “값만 비교”지만, 지급은

• 잔액 갱신
• 거래내역 적재
• 회계 처리
  등이 실제 원장에 반영되어야 하므로, 도메인 기반 E2E 시나리오로 검증합니다.

원문 예시:

• 잔액 구간별 차등 이자 계산 검증
• 고객 상태(명의도용/해킹 피해/사망 등) 검증
• 계좌 상태(출금/입금 정지 등) 검증

즉, “기술 테스트”가 아니라 은행 업무 규칙 테스트가 전환의 핵심입니다.

---

10) 최종 전환: 순차 배포(점진적 트래픽 스위칭)

기술 블로그에선, 내부(개발팀→임직원) → 일부 고객 → 점진 확대 방식으로 전환
그리고 “코어를 바라보는 호출량 vs 신규를 바라보는 호출량”을 조절해 신규 트래픽을 서서히 올렸다고 합니다.

이건 실무에서 흔히 말하는:

• canary release(카나리)
• progressive delivery(점진적 전달)
• traffic shifting(트래픽 이동)
  전략입니다.

핵심 이점:

• “돌아갈 길(rollback)”이 항상 남아 있음
• 특정 구간에서만 문제 나면 즉시 멈추고 원복 가능

흠 어렵당...

원장?

- 모든 거래 내역을 시간 순서대로 빠짐없이 기록해두는 공식 장부!

돈의 이동을 누가, 언제, 얼마를, 왜 어떤 계좌에서 어떤 계좌로 이동했는지를 영구적으로 기록하는 기준데이터.

만약 잔액테이블과 원장테이블을 나누어보면,

잔액테이블은 현재 얼마나 남아잇는지 저장하고, 조회는 빠르지만 근거가없어요.

원장 테이블은 모든 거래 이력을 저장하고, 느리지만 근거가있습니다.