금융 시스템 아키텍처/데이터 파이프라인 정리

금융 시스템 아키텍처/데이터 파이프라인 정리

1) 금융 시스템이 복잡하게 설계될 수밖에 없는 이유

1.1 금융 = 규제 산업 → 데이터/업무가 “법”에 종속

• 금융 업무는 업무별 기준·준칙이 존재하고, 법률적 제약을 준수해야 하는 영역
• 업무 데이터를 단일 DB/단일 모델로 과도하게 “유기적으로” 엮어버리면 발생하는 문제
  • 규제/내규 변경 발생 시 즉시 반영 난이도 상승
  • 영향 범위(impact) 폭증 → 장애 리스크 확대
  • 운영/감사 대응 난이도 증가
• 결과적으로 선택되는 설계 방향
  • 업무 간 느슨한 결합(loose coupling)
  • 경우에 따라 보수적 단일 DB 중심 아키텍처
  • “보수적이지만 안정적인 선택”이 비용 대비 최적이 되는 구조

---

2) 테이블 설계 원리: 분리할 건 분리, 합칠 건 합치기

핵심 원리: 공통분모는 통합, 성격이 다른 건 분리

2.1 분리 예시: 대출 vs 카드 ‘심사’는 통합하면 손해

• 대출 심사와 카드 심사는 평가 항목이 구조적으로 다름
• 심사내역을 하나로 통합 시
  • 칼럼/규칙의 폭발적 증가
  • 예외 처리와 정책 변경 비용 증가
  • 운영/감사 관점의 설명 복잡도 증가
• 결론: 심사 도메인은 분리 설계가 합리적

2.2 통합 예시: 연체 이후 프로세스는 공통분모가 큼

• 연체 이후는 대출/카드 공통 항목이 큼
  • 연체금액, 연체일, 상환이력, 회수이력 등
• 이후 절차는 고객 단위 데이터 성격이 강함
  • 경매/소송, 회생/파산, 신용회복 등
• 결론: 연체 이후 구간은 통합 설계가 유리해지는 맥락

2.3 “잘 관리되는 테이블”의 방향성 = 공통분모 중심 설계

• 고객정보는 고객 단위로 통합 관리되는 편이 개인정보 관리/정합성 측면에서 효율적
• 단, “무조건 통합”이 아니라
  • 데이터량
  • 트랜잭션 유형
  • 변경 빈도
  • 규제 영향 범위
    를 함께 고려하는 설계가 필요

---

3) 전통적 금융 아키텍처의 큰 덩어리

3.1 Core + 채널/단말 + DW + 상품 팩토리

• 채널/단말: 영업망, 인터넷뱅킹, 모바일, ATM, 콜센터 등
• CORE(코어뱅킹): 예금/대출/외환/신탁 등 본업 처리
• DW(Data Warehouse): 분석/리포팅 목적의 통합 저장소
• 상품 Factory: 상품/금리/수수료 등 규칙·정책의 표준화/중앙관리
• 코드/메타 시스템: 공통코드 및 업무별 코드(여신/수신/카드/회계 등) 표준 체계

요약: 업무 안정성을 우선하는 코어 중심 구조 위에 채널이 붙고, DW가 별도로 존재하며, 상품/코드는 팩토리/메타로 표준화되는 형태

---

4) DW로 데이터를 가져오는 방법: CDC와 SCD

4.1 원천→DW 적재 파이프라인(전형)

• 원천 DB(대표적으로 Oracle)에서 CDC를 위한 로그 설정 활성화
• 초기 구간: Full Load(통째 적재)
• 이후 구간: CDC로 변경분 증분 반영(GoldenGate/LogMiner 등)
• DW 내부 레이어 분리
  • Stage: 원천 데이터를 “그대로” 담는 구간
  • Integration: 의미/정합성/표준을 맞추는 구간
  • Mart: 분석/서비스 목적에 맞게 최적화한 구간

---

4.2 Oracle CDC를 위한 전제: ARCHIVELOG + Supplemental Logging

(1) Redo Log의 의미

• Oracle은 INSERT/UPDATE/DELETE 같은 변경 작업을 Redo Log에 기록
• 장애 복구 시 Redo Log를 재적용(redo)하여 상태 복원

(2) NOARCHIVELOG vs ARCHIVELOG

구분	NOARCHIVELOG	ARCHIVELOG
Redo Log	재사용(덮어쓰기)	보관(Archive)
과거 변경 추적	불가	가능
시점 복구(Point-in-time recovery)	불가	가능
CDC 가능성	불가	가능
금융권 운영 적합성	부적합	사실상 필수

• NOARCHIVELOG
  • Redo Log가 가득 차면 덮어씀
  • 과거 변경 이력 소실
  • 개발/테스트 성격
• ARCHIVELOG
  • Redo Log가 차면 Archive Log로 복사 후 보관
  • 변경 이력을 시간 순으로 유지
  • “DB 변경 블랙박스 기록” 성격

(3) Supplemental Logging의 의미(핵심만)

• 로그 기반 CDC가 “변경분을 정확히 재현”하려면
  • UPDATE/DELETE에서 어떤 행이 바뀌었는지 식별 가능한 키 정보가 로그에 필요
• Supplemental Logging은 CDC가 필요한 키/식별 정보를 로그에 추가로 남기는 설정 범주

---

4.3 CDC(Change Data Capture) 방식 4종 비교

1) 로그 기반(Log-based CDC): GoldenGate, Debezium, LogMiner

• DB redo/transaction log를 읽어서 변경 이벤트 추출
• 장점: 원본 부하 낮음, 트랜잭션 경계 유지, 신뢰성 높음
• 단점: 초기 설정 필요, 로그 포맷/권한 의존

2) 트리거 기반(Trigger-based CDC)

• 테이블 트리거로 변경을 별도 테이블/큐에 기록
• 장점: 구현 단순(소규모), 세밀한 제어
• 단점: 원본 DB 부하 증가, 지연/관리 복잡

3) 타임스탬프/쿼리 기반(Polling)

• last_update_ts 같은 컬럼을 주기 조회
• 장점: 로그 접근 불필요, 구현 단순
• 단점: 동시성/정확성 이슈, 지연 발생

4) 덤프/배치(Full Extract + diff)

• 주기적으로 전체 덤프 후 diff 또는 truncate+reload
• 장점: 단순, 일관성 확보 상대적으로 쉬움
• 단점: 비용/시간 큼, 실시간 불가

---

4.4 SCD(Slowly Changing Dimension)란

• DW 차원 테이블(고객/상품 등)의 변경 이력을 어떻게 보존할지에 대한 설계 패턴

관계 정리:

• CDC: “무엇이 언제 바뀌었나?”를 잡아내는 수집 문제
• SCD: 잡아낸 변경을 DW 테이블에 어떻게 기록/표현할지의 저장 문제

구분	CDC	SCD
풀네임	Change Data Capture	Slowly Changing Dimension
관점	파이프라인/수집	모델링/저장
질문	무엇이 언제 바뀌었나	변경을 어떻게 남길까
결과물	INSERT/UPDATE/DELETE 이벤트	이력형 차원 테이블
목적	누락 방지, 증분 적재	시점 분석, 이력 보존

---

5) “근본 개선 포인트” = 모델링보다 먼저 해야 할 일

• 모델 성능 개선 전에 데이터 생산 구조/규제 절차/원천 접근성부터 정리 필요
• 도메인 전문가(업무/규제)와의 협업이 필수인 이유
  • 데이터 산출 과정 자체가 규제·내규·업무 절차의 결과물인 경우가 많음
• 원천 데이터 확보의 중요성
  • 정제된 결과물만 있으면 정합성/누락/정의 변경을 검증하기 어려움
• 원천 기반으로 가능한 작업
  • 정합성 체크
  • 규제 변경 영향 범위 점검
  • 변경을 “하나의 창구”에서 관리 가능한 구조로 개선

---

6) 금융 트랜잭션 흐름의 정석: 채널 → 연계 → 코어 → 대외기관

6.1 레이어 관점

• 채널: 인터넷/모바일/ATM/콜센터 등 다채널
• MCI: Multi Channel Integration(채널 통합 계층)
• Core Banking: 본업 트랜잭션 처리
• FEP: Front End Processor(대외기관 연동 전면 처리 계층)
• EAI: Enterprise Application Integration(단위 업무 시스템 연계)

핵심 메시지: 코어는 최대한 안정적으로 두고, 바깥(채널/대외연동/단위업무)은 연계 계층으로 흡수하는 구조

---

7) Legacy → New System: 왜 ‘데이터/모델 인프라’를 분리하는가

7.1 레거시의 한계

• 레거시는 “업무 처리”가 최우선인 세계
• 무거운 연산/실험/실패/재시도에 취약
• 모델 학습/피처 생성 같은 작업이 레거시 위에서 직접 수행되면
  • 성능 예측 불가능
  • 장애 위험 증가
  • 운영 안정성 훼손

7.2 뉴 시스템의 방향

• Data Transform + 모델 트레이닝이 가능한 전용 환경을 분리 구축
• Kubernetes 기반 오케스트레이션으로 작업/자원/실패를 통제

구조 예시:

기존 시스템(EDW/Core)  ──(Batch/지연)──▶  ML 전용 환경
                                      ├─ Feature Engineering
                                      ├─ Training/Experiment
                                      └─ Batch/Job 실행(Kubernetes 관리)

---

8) Legacy ↔ New System 연결: “데이터는 배치, 모델은 실시간”이 기본이 되는 이유

8.1 데이터 사이클은 배치 중심

• 레거시 DB를 실시간으로 모델이 직접 때리면 발생하는 문제
  • 트래픽 급증
  • 쿼리 폭증/락 경합
  • 예측 불가 부하
  • 모델 배포 실수 → 은행 전체 장애로 전파
• 그래서 선택되는 방식
  • Delayed Batch(T+1, T+1h, T+5m 등)
  • Scheduling Batch(비피크 시간대 스케줄)

핵심 전제: 데이터 최신성 < 시스템 안정성

8.2 모델 사이클은 실시간 중심

• 모델이 사용되는 순간은 “지금 판단”이 필요한 순간
  • 결제 승인
  • 로그인
  • 이상거래 탐지
  • 추천 노출
• 배치 추론이면 타이밍 상실 → 실시간 API/이벤트 기반 추론 필요

8.3 진짜 이유: 책임 분리

영역	책임
Data(Legacy)	무결성, 안정성
Model(New)	반응성, 정확성

• 한 쪽 실패가 다른 쪽으로 전파되지 않게 하는 설계가 핵심

8.4 반드시 필요한 인터페이스 설계

• Dependency Injection: 모델이 레거시 DB를 직접 참조하지 않게 함(API/파일/이벤트)
• Input Data Generation: 피처 스키마/타입/결측 규칙을 계약처럼 고정
• Output 전송: 스코어/플래그/코드 형태로 업무 시스템이 해석 가능하게 전달
  • 특히 AML 등에서는 최종 결정은 사람/업무 시스템, 모델은 판단 보조

---

9) 제약 인프라에서 모델 운영 시 체크리스트(운영 포인트)

9.1 운영 관점 유의사항(공통 주제)

• “성능”이 아니라 자원과 시간의 예측 가능성을 숫자로 관리하는 영역
  • 메모리/지연/트래픽/GPU 부족이 장애로 직결

1) Model Size 관리

• 운영에서의 “모델 사이즈” 의미
  • 파일 크기(가중치 저장 크기)
  • 로딩 후 메모리 상주 크기(RAM/VRAM)
  • 추론 시 추가 메모리(activation/cache/batch 등)
• 관리 지표 예
  • peak VRAM usage
  • p50/p95 latency
  • throughput(req/s)
• 대표 대응
  • Quantization(FP16/INT8)
  • Distillation
  • Pruning
  • Batch size 조정

2) Task별 모델 프로세스 관리 → Inference Time 추정

• Task별로 입력/모델/후처리가 달라 지연이 달라짐
• 한 Task 폭주가 다른 Task를 죽이지 않게
  • 프로세스/Pod 단위 격리
  • 스케일링 독립
• SLA 관점에서 추론 시간(p95/p99) 기반 용량 산정 필요

3) Legacy Data Size 확인 + 네트워크 트래픽 추정

• Legacy → New 전송 순간의 변수들이 비용/장애 위험이 됨
  • 파일 크기, 컬럼 수, 전송 주기, 압축 여부
• 운영 관점 계산 프레임(개념)
  • GB/day, run/day, GB/run, 대역폭(MB/s), 전송 시간 ≈ 크기/대역폭
• 원활한 인터페이스를 위한 실무 선택
  • 스키마 계약(컬럼/타입 고정)
  • 압축(parquet + snappy)
  • 증분 전달(전체 대신 변경분)
  • 큐/버퍼(Kafka/S3 staging)

4) GPU 부족 대응

• 기존 weights load 재학습
  • 처음부터 학습 대신 체크포인트 로드 후 짧은 fine-tune
  • 비용/시간 절감
• epoch restore 등 재개 가능 구현
  • epoch마다 checkpoint 저장
  • optimizer/scheduler state 저장
  • random seed/state 저장(재현성)
  • 중단/eviction/spot 종료에도 이어서 학습 가능

---

10) 모델 압축(실용화를 위한 대표 전략)

• Pruning(가중치/헤드/레이어 제거)
• Weight Factorization(저랭크 근사)
• Knowledge Distillation(teacher→student)
• Weight Sharing(ALBERT류)
• Quantization(저비트 표현)
• Pre-train vs Downstream: task-specific/agnostic 모두 존재

---

11) 추천 시스템 파트: 전략 → 문제(콜드 스타트) → 아키텍처 개선

11.1 추천 전략/데이터 타입

• Content-based / Collaborative Filtering
• Explicit feedback(평점 등) vs Implicit feedback(클릭/구매/탐색 등)

11.2 협업 필터링의 한계: 콜드 스타트

• 행동 데이터가 쌓이지 않으면 계산 불가
• 신규 아이템/신규 유저에서 추천 품질 급락
• Content-based 등으로 보완 필요

11.3 추천 아키텍처에서 자주 발생하는 문제

• 상품 정보가 “데이터 생성 시점”에만 가용한 구조
• 결과
  • 점진적 개선 어려움
  • 모델 재활용 어려움
  • 정책 변경(필터/부스팅)이 느림

11.4 개선 원칙 3가지

1. 추천 모델과 서비스를 분리
2. 상품/유저 정보를 서빙 타임에 접근 가능하게 구성
3. 필터/부스팅 변경이 쉽고 빠르게 가능해야 함

랭킹 단계 결합 피처 예

• 검색 관련도
• 추천 모델 스코어
• 연관성 피처(이미지/카테고리 등)
• 상품 자체 피처(가격/리뷰/카테고리 등)

---

한 장 요약

• 금융 아키텍처는 “기술”보다 규제/안정성/운영이 우선이라 계층 분리와 느슨한 결합이 강함
• 테이블 설계는 성격 다른 업무는 분리, 공통분모 큰 구간은 통합이 원칙
• 레거시(코어/EDW)와 모델 인프라(뉴 시스템)는 목적이 달라 분리되고, 연결은 보통 데이터=배치 / 모델=실시간
• DW 적재는 CDC(수집)와 SCD(이력 저장)의 조합이 핵심
• 모델 운영은 성능보다 자원·지연·트래픽·복구 가능성을 관리하는 문제
• 추천 시스템은 모델 성능뿐 아니라 서빙 시점 데이터 접근성, 모델/서비스 분리, 정책 변경 용이성이 아키텍처 핵심