핀테크 시스템을 설계할 때 반드시 지켜야 할 기본 원칙 정리

 

이 글은 핀테크 시스템에서 ‘돈’을 어떻게 다뤄야 하는지에 대한 핵심 원칙과 실무적인 설계 기준을 정리한 글입니다.
일반적인 CRUD 중심의 시스템과 달리, 돈을 다루는 소프트웨어는 정확성, 불변성, 추적 가능성, 검증 가능성이 무엇보다 중요합니다.

핀테크에 처음 합류한 개발자, 이미 금융 시스템을 만들고 있지만 왜 이렇게 복잡한 설계가 필요한지 다시 정리하고 싶은 분, 혹은 일반 시스템과 돈 시스템의 차이를 이해하고 싶은 분을 위해, 돈 중심 시스템의 설계 철학과 주요 기술 개념을 체계적으로 풀어봅니다.

반응형

---

핀테크 시스템의 세 가지 핵심 원칙

돈을 핵심 상태로 다루는 모든 시스템은 아래 세 가지 원칙 위에서 설계되어야 합니다.

1. No Invented Data

돈은 없던 곳에서 새로 생길 수 없습니다.
중복 처리, 임의 잔액 수정, 자동 보정 같은 로직은 시스템이 돈을 “만들어내는” 결과로 이어질 수 있습니다.

2. No Lost Data

돈에 발생한 모든 변화는 기록되어야 합니다.
삭제되거나 덮어쓰이는 데이터는 감사와 재구성을 불가능하게 만듭니다.

3. No Trust

외부 결제사, 내부 컴포넌트, 심지어 운영자까지도 신뢰하지 않고 검증해야 합니다.
모든 입력과 결과는 확인 가능해야 합니다.

이 세 가지 원칙은 이후 소개하는 모든 패턴과 설계의 출발점입니다.

---

돈을 표현하는 방식의 중요성

float와 double을 피해야 하는 이유

금액 표현은 금융 시스템에서 가장 중요한 결정 중 하나입니다.
float나 double은 빠르고 메모리 효율적이지만, 예측 불가능한 정밀도 손실을 만들어냅니다. 이는 곧 금액 불일치로 이어집니다.

안전한 금액 표현 방식

• BigDecimal
  • 반올림 위치와 정밀도를 명시적으로 제어 가능
  • FX 계산, 수수료, 중간 연산에 적합
• 최소 단위 정수 저장
  • 대부분의 법정화폐는 고정 정밀도를 가짐
  • 예: €12.34 → 1234
  • ISO 4217 기준 자릿수를 따라야 하며 통화마다 다름
• 유리수(Rational)
  • 정밀도 손실이 절대 허용되지 않는 경우 가장 강력
  • 성능 부담과 구현 복잡도가 큼

중요한 점은 저장 방식과 계산 방식은 분리해서 결정할 수 있다는 것입니다.
정수로 저장하고, 계산은 BigDecimal로 수행하는 구조도 충분히 가능합니다.

---

반올림과 통화 처리의 원칙

반올림은 피할 수 없는 문제입니다.
나눗셈, 수수료, 이자, 환율 변환 등 모든 과정에서 발생합니다.

반올림은 반드시 명시적으로

• 반올림 전략은 기술이 아니라 비즈니스 결정
• half-up, half-even 등 전략에 따라 법적·세무적 영향 발생
• 가능한 한 늦게, 경계 지점에서만 반올림

돈은 항상 통화와 함께

• 금액과 통화를 하나의 타입으로 묶어야 오류를 줄일 수 있음
• 서로 다른 통화 간 덧셈은 금지
• 통화 변환은 통제된 환율로 명시적으로 수행
• 암호화폐는 단순 코드가 아닌 (network, contract address) 같은 식별이 필요

---

FX 환율을 다룰 때 놓치기 쉬운 점

• 환율은 항상 방향성을 가짐
  EUR/USD는 USD/EUR의 단순 역수가 아님
• 환율의 시점이 결과를 바꿈
  • 현재 환율: 보유 자산 평가
  • value-date 환율: 세무·회계 기준
• 두 가지 환율 구분
  • Transactional rate: 실제 거래 환율
  • Reference rate: 평가 목적 환율

환율과 함께 출처와 시점을 저장해야 나중에 검증이 가능합니다.

---

장부와 복식부기의 기본 개념

돈의 이동은 반드시 감사 가능해야 하며, 수년 뒤에도 재구성 가능해야 합니다.

복식부기의 핵심

• 모든 거래는 (debit, credit, amount) 쌍으로 기록
• 한 계정에서 빠진 돈은 반드시 다른 계정으로 이동
• 장부는 항상 균형을 이룸

잔액은 저장하지 않는다

잔액은 결과값일 뿐이며, 돈의 이동 기록에서 파생되어야 합니다.

계정 타입

• asset, liability, equity
• 확장식:
  assets = liabilities + equity + revenue - expenses

---

시간 모델: value, booking, settlement

금융 거래에는 하나 이상의 시간이 존재합니다.

• Value time: 거래가 실제 발생한 시점
• Booking time: 시스템에 기록된 시점
• Settlement time: 실제 돈이 이동한 시점

이 세 가지를 하나의 created_at으로 합치면,
나중에 절대 복구할 수 없는 정보 손실이 발생합니다.

---

감사 추적과 불변성

핀테크 시스템은 규제 감사 대상이 될 수 있습니다.
따라서 “현재 상태”뿐 아니라 그 상태가 만들어진 전체 과정이 필요합니다.

감사 추적에 포함돼야 할 것

• 무엇이, 언제, 누가, 왜 발생했는지
• 돈 이동뿐 아니라 설정 변경, 권한 변경, 수동 개입

Append-only 원칙

• 기록은 수정·삭제 불가
• 정정은 새로운 레코드로 상쇄
• 해시 체인, 체크섬으로 위·변조 감지 가능

---

취소와 정정 처리 방식

• Reversal: 원본을 완전히 상쇄
• Correction: 잘못된 값과 올바른 값의 차이를 조정

중요한 점은 원본 기록은 절대 사라지지 않는다는 것입니다.

---

돈 흐름 실행과 자금 예약

외부 시스템과 연동되는 거래에서는 race condition을 반드시 고려해야 합니다.

Funds Reservation 패턴

• 거래 전 자금을 예약
• 성공 시 settle, 실패 시 release
• total balance와 available balance 분리

이 방식은 중복 지출 위험을 크게 줄여줍니다.

---

멱등성과 재시작 가능한 흐름

분산 시스템에서는 동일 요청이 여러 번 전달될 수 있습니다.

멱등성의 핵심

• 같은 요청이 여러 번 와도 결과는 한 번만
• 명시적인 idempotency key 사용 권장

재시작 가능한 설계

• 모든 진행 상태는 영속 저장
• 상태 머신 기반 설계
• 각 단계는 다시 실행 가능해야 함

---

외부 API와 웹훅 처리 원칙

외부 시스템은 절대 신뢰할 수 없습니다.

• 스키마 변경, 누락, 오류는 일상적
• 웹훅은 “진실”이 아니라 힌트
• raw payload 그대로 저장
• 빠른 2xx 응답 후 비동기 처리
• 멱등성 필수

---

Outbox, CDC, 그리고 Reconciliation

신뢰 가능한 알림

• Outbox 패턴
• Change Data Capture(CDC)
• at-least-once 전송을 전제로 설계

Reconciliation의 역할

• 내부 장부와 외부 시스템 간 불일치 탐지
• overwrite가 아닌 원인 분석과 정정이 목적

---

접근 제어와 변경 추적

돈 시스템에서 권한과 변경 이력은 데이터만큼 중요합니다.

• Four-eyes, maker-checker
• 최소 권한 원칙
• 코드 변경, 배포 이력까지 감사 대상

---

728x90

핀테크 시스템은 단순히 “금액을 저장하고 계산하는 프로그램”이 아닙니다.
돈을 다룬다는 것은 신뢰, 법적 책임, 수년 뒤의 재현 가능성까지 함께 설계하는 일입니다.

이 글에서 정리한 원칙들은 구현 기술이 아니라 사고 방식에 가깝습니다.
이 원칙을 기반으로 설계한다면, 시스템이 커지고 복잡해져도
돈을 잃지 않고, 만들지 않으며, 설명 가능한 상태를 유지할 수 있습니다.

핀테크 시스템을 설계하거나 운영하는 모든 엔지니어에게
이 기본 원칙들이 탄탄한 기준점이 되기를 기대합니다.

300x250

https://w.pitula.me/fintech-engineering-handbook/

Fintech Engineering Handbook