---
title: "금융 정산 마이그레이션에서 소수점 정밀도를 보장하는 법: 6종 데이터베이스 실증 가이드"
date: 2026-06-02 00:00:00 +0000
description: "Oracle에서 BigQuery로 대출 이자 정산 쿼리를 이행할 때 발생하는 1원 소수점 오차의 원인을 분석하고, 후순위 나눗셈(Division Deferral) 기법으로 BigQuery·Spanner·PostgreSQL·MySQL·Presto·Trino 6종 데이터베이스 전체에서 100.0000% 정합성을 달성한 실증 가이드"
categories: data
tags: [BigQuery, Oracle, Spanner, PostgreSQL, MySQL, Presto, Trino, 소수점 정밀도, 마이그레이션, 금융 정산]
---

## 1. 도입

## 2. 마이그레이션 개요

## 3. 대출 이자 수식 및 스키마 이행

## 4. 문제 발견: AS-IS 쿼리의 1원 오차

## 5. 원인 분석: 데이터베이스별 수치 연산 아키텍처

### 5.1 플랫폼별 정밀도 처리 방식 비교

### 5.2 David Goldberg 논문과의 간극

### 5.3 UNION ALL과 묵시적 타입 격하

## 6. 해결: 후순위 나눗셈(Division Deferral)

## 7. 6종 데이터베이스 교차 검증 결과

## 8. 프로덕션 방어 수칙

## 9. 결론

정산 시스템에서 1원은 단순한 반올림 오차가 아닙니다.

금융기관의 대출 이자 정산 환경에서 1원의 편차는 감사 불일치, 규제 보고 오류, 고객 신뢰 훼손으로 직결됩니다. 허용 오차는 정확히 0입니다.

Oracle에서 수년간 완벽하게 동작하던 대출 이자 산출 쿼리가 있습니다. 이 쿼리를 BigQuery로 그대로 이식하면 어떻게 될까요? 10만 건 중 1건에서 계산 결과가 1원 낮게 나옵니다. 그리고 정수 경계에 걸리는 특수 케이스만 모아 테스트하면 **47.43%**에서 오차가 발생합니다.

본 가이드는 이 오차의 수학적 원인을 분석하고, **후순위 나눗셈(Division Deferral)** 기법으로 BigQuery·Cloud Spanner·PostgreSQL·MySQL·Presto·Trino 6종 데이터베이스 전체에서 100.0000% 정합성을 달성한 실증 과정을 기록합니다.

- **원천 환경**: Oracle Database 21c (대출 이자 산출 쿼리, 100,000건 데이터)
- **검증 대상**: Google Cloud BigQuery, Cloud Spanner, PostgreSQL, MySQL, Presto, Trino 총 6종
- **검증 목표**: Oracle 결과와 1원도 다르지 않음을 보장

### 종합 검증 결과 요약

아래 표는 각 플랫폼에서 동일 수식을 실행했을 때의 AS-IS 정합성과, 후순위 나눗셈 적용 이후의 최종 정합성을 비교합니다.

| 데이터베이스 | 수치 타입 | 중간 연산 정밀도 처리 | AS-IS 일치율 (10만 건) | 후순위 나눗셈 적용 후 |
| :--- | :--- | :--- | :--- | :--- |
| **Oracle** | `NUMBER` | Base-100 소프트웨어 가상 레지스터 (~80자리) | **100.0000%** (0건 차이) | **100.0000%** |
| **BigQuery** | `BIGNUMERIC` | scale=38 고정 소수점, 연산 단계별 정규화 | **99.9990%** (1건 차이) | **100.0000%** |
| **Cloud Spanner** | `NUMERIC` | scale=9 고정 소수점, ROUND_HALF_UP | **99.9840%** (16건 차이) | **100.0000%** |
| **PostgreSQL** | `NUMERIC` | 임의 정밀도(Arbitrary Precision) | **100.0000%** (0건 차이) | **100.0000%** |
| **MySQL** | `DECIMAL` | `div_precision_increment` 한계 | **99.9980%** (2건 차이) | **100.0000%** |
| **Trino** | `DECIMAL` | 38자리 고정, 초과 시 스케일 축소 | **81.7680%** (18,232건 차이) | **100.0000%** |
| **Presto** | `DECIMAL` | `max(s1,s2)` 엄격 적용, 조기 스케일 축소 | **4.5840%** (95,416건 차이) | **100.0000%** |

### 검증 절차 요약

```mermaid
graph TD
    A[Oracle 데이터 추출 및 CSV 다운로드] --> B[BigQuery 테이블 스키마 정의 및 로드]
    B --> C[1차 AS-IS SQL 실행]
    C --> D[정합성 검증 및 1원 오차 검출]
    D --> E[BIGNUMERIC 나눗셈 연산 사양 분석]
    E --> F[대수적 통분 및 후순위 나눗셈 수식 설계]
    F --> G[2차 최적화 SQL 실행]
    G --> H[6종 DB 전수 검증 및 결과 기록]

### 3.1 스키마 매핑 분석

수치 정밀도 손실을 방지하기 위해 Oracle `NUMBER` 타입에 BigQuery `BIGNUMERIC` 타입을 대응시켰습니다.

| 컬럼명 | Oracle 타입 | BigQuery 타입 | 설명 |
| :--- | :--- | :--- | :--- |
| `기준년월` | `VARCHAR2(6)` | `STRING` | 정산 기준년월 |
| `고객관리번호` | `NUMBER(15)` | `BIGNUMERIC(15)` | 고객 식별 번호 |
| `대출관리번호` | `VARCHAR2(20)` | `STRING` | 대출 건 식별 번호 |
| `대출잔액` | `NUMBER(15)` | `BIGNUMERIC(15)` | 이자 계산 기준 잔액 |
| `약정금리` | `NUMBER(5,2)` | `BIGNUMERIC(5,2)` | 연 이자율 (%) |
| `대출실행일자` | `DATE` | `DATE` | 이자 기산 시작일 |
| `이자계산기준일` | `DATE` | `DATE` | 이자 정산 기준일 |

**BigQuery 스키마 정의 (`schema.json`)**:

```json
[
  {"name": "기준년월",       "type": "STRING",     "mode": "REQUIRED"},
  {"name": "고객관리번호",   "type": "BIGNUMERIC", "mode": "REQUIRED"},
  {"name": "대출관리번호",   "type": "STRING",     "mode": "REQUIRED"},
  {"name": "대출잔액",       "type": "BIGNUMERIC", "mode": "REQUIRED"},
  {"name": "약정금리",       "type": "BIGNUMERIC", "mode": "REQUIRED"},
  {"name": "대출실행일자",   "type": "DATE",       "mode": "REQUIRED"},
  {"name": "이자계산기준일", "type": "DATE",       "mode": "REQUIRED"}
]

Oracle 원천 SQL을 BigQuery 문법으로 직접 번역하여 실행했습니다.

**AS-IS BigQuery SQL (1차 번역)**:

```sql
-- AS-IS: 나눗셈을 수식 중간에 배치 (오차 발생 구간)
SELECT 대출관리번호
     , TRUNC(
         (CAST(대출잔액 AS BIGNUMERIC) * (CAST(약정금리 AS BIGNUMERIC) / CAST(100 AS BIGNUMERIC)))
         * ((CAST(DATE_DIFF(이자계산기준일, 대출실행일자, DAY) AS BIGNUMERIC) / CAST(365 AS BIGNUMERIC))
            + CAST(30 AS BIGNUMERIC) / CAST(365 AS BIGNUMERIC))
       , 0) AS 이자금액
  FROM `DM.월별대출이자산출`
 ORDER BY 대출관리번호

대출 이자 수식의 핵심은 `30 / 365` 나눗셈입니다. 이 값은 무한 순환소수입니다:

$$
\frac{30}{365} = 0.08219178082191780821\ldots \quad \text{(무한 순환소수)}
$$

각 데이터베이스는 이 무한소수를 처리하는 방식이 다릅니다.

#### Oracle NUMBER: 80자리 임시 소프트웨어 연산 버퍼

Oracle `NUMBER` 타입은 디스크 저장(최대 22바이트, 100진수 20자리)과 메모리 연산 영역을 분리합니다.

```c
/* Oracle OCI Number Type (oci.h) */
struct OCINumber {
    ub1 OCINumberData[22];
};

> Goldberg, D. (1991). *What Every Computer Scientist Should Know About Floating-Point Arithmetic*. ACM Computing Surveys, 23(1), 5–48. [DOI: 10.1145/103162.103163](https://dl.acm.org/doi/10.1145/103162.103163) / [전문 보기](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)

Goldberg의 1991년 논문은 IEEE 754 이진 부동소수점 연산의 수학적 토대를 제시합니다. 반올림 오차(Rounding Error), 가드 디지트(Guard Digits), 유효자리 소실(Catastrophic Cancellation)을 단일 코어 직렬 FPU 환경에서 정밀하게 증명했습니다.

그러나 현대 분산 정산 플랫폼은 Goldberg가 상정한 환경과 구조적으로 다릅니다:

1. **고정소수점 라이브러리**: BigQuery `BIGNUMERIC`, Spanner `NUMERIC` 등은 이진 부동소수점 대신 소프트웨어 에뮬레이션 십진 고정소수점 라이브러리를 사용합니다.
2. **조기 정규화(Premature Normalization)**: 분산 환경의 데이터 일관성을 위해 이항 연산 단계마다 결과를 고정 스케일(BigQuery scale=38, Spanner scale=9)로 강제 조정합니다.
3. **MPP 비결정론적 셔플**: 부동소수점 덧셈은 교환법칙이 성립하나 결합법칙이 성립하지 않습니다 — $(A + B) + C \neq A + (B + C)$. 분산 집계 순서가 매 실행마다 달라지면 결과도 달라집니다.
4. **CBO 대수적 변환**: 비용 기반 옵티마이저가 $A \times B + A \times C$를 $A \times (B + C)$로 내부 치환할 때, 유한 정밀도 환경에서는 수치 경로가 달라집니다.

따라서 Goldberg 이론만으로는 현대 분산 DWH의 고정소수점 정규화 오차를 완전히 설명하지 못합니다.

`UNION ALL`로 `BIGNUMERIC`과 `FLOAT64`를 병합하면 BigQuery는 표현 범위가 넓은 `FLOAT64`를 공통 상위 타입으로 결정합니다. 이 규칙은 BigQuery만의 문제가 아닙니다.

**테스트 데이터**: `123456789012345.6789012345678901234567` (소수부 22자리)와 `1.0`을 `UNION ALL`로 병합.

| 데이터베이스 | 판별 함수 | 최종 타입 | 출력값 | 정합성 |
| :--- | :--- | :--- | :--- | :--- |
| **Oracle 21c** | 내장 타입 검사 | `NUMBER(38,22)` | `123456789012345.6789012345678901234567` | **100% 보존** |
| **BigQuery** | `bq show` 스키마 | `FLOAT64` | `1.2345678901234567E14` | **20자리 유실** |
| **PostgreSQL** | `pg_typeof()` | `double precision` | `123456789012345.67` | **20자리 유실** |
| **MySQL 8.0** | `DESCRIBE` 임시 테이블 | `double` | `123456789012345.67` | **20자리 유실** |
| **Presto** | `typeof()` | `double` | `1.2345678901234567E14` | **20자리 유실** |
| **Trino** | `typeof()` | `double` | `1.2345678901234567E14` | **20자리 유실** |

**해결**: 모든 `UNION ALL` 브랜치에 동일한 고정소수점 타입을 명시적으로 캐스팅합니다.

```sql
-- BigQuery: 모든 브랜치를 BIGNUMERIC으로 통일
SELECT CAST('123456789012345.6789012345678901234567' AS BIGNUMERIC) AS val
UNION ALL
SELECT CAST(1.0 AS BIGNUMERIC) AS val;
-- 결과: 123456789012345.6789012345678901234567 (100% 보존)

**핵심 아이디어**: 수식 내 모든 중간 나눗셈을 곱셈으로 통합하고, 단 1회의 나눗셈을 `TRUNC` 직전 마지막 단계로 후순위 배치합니다. 이는 기존 수식과 수학적으로 동치이면서, 플랫폼 고유의 조기 스케일 정규화에 의한 수치 유실을 원천 배제합니다.

### 6.1 수학적 동치 증명

AS-IS 수식:

$$
\text{이자}_{\text{AS-IS}} = \text{TRUNC}\!\left(\text{잔액} \times \frac{\text{금리}}{100} \times \left(\frac{D}{365} + \frac{30}{365}\right),\ 0\right)
$$

대수적 통분 — 나눗셈을 마지막으로 후순위 배치:

$$
= \text{TRUNC}\!\left(\text{잔액} \times \frac{\text{금리}}{100} \times \frac{D + 30}{365},\ 0\right)
$$

$$
= \text{TRUNC}\!\left(\frac{\text{잔액} \times \text{금리} \times (D + 30)}{36{,}500},\ 0\right)
$$

$$
\therefore\quad \text{이자}_{\text{TO-BE}} = \text{TRUNC}\!\left(\frac{\text{잔액} \times \text{금리} \times (D + 30)}{36{,}500},\ 0\right) \quad \blacksquare
$$

### 6.2 BigQuery TO-BE SQL

```sql
-- TO-BE: 후순위 나눗셈 — 나눗셈 1회, TRUNC 직전 최종 단계에서만
SELECT 대출관리번호
     , TRUNC(
         (CAST(대출잔액 AS BIGNUMERIC)
          * CAST(약정금리 AS BIGNUMERIC)
          * (CAST(DATE_DIFF(이자계산기준일, 대출실행일자, DAY) AS BIGNUMERIC)
             + BIGNUMERIC '30'))
         / BIGNUMERIC '36500'
       , 0) AS 이자금액
  FROM `DM.월별대출이자산출`
 ORDER BY 대출관리번호

### 7.1 검증 자동화 스크립트

**Oracle vs. BigQuery 대조 (`compare_results.py`)**:

```python
import csv, subprocess, json, os

def run_bq_query(query):
    temp_file = "temp_query.sql"
    with open(temp_file, "w", encoding="utf-8") as f:
        f.write(query)
    cmd = f"bq query --use_legacy_sql=false --max_rows=150000 --format=json < {temp_file}"
    res = subprocess.run(cmd, shell=True, capture_output=True, text=True)
    os.remove(temp_file)
    if res.returncode != 0:
        print("Query failed:", res.stderr)
        return []
    return json.loads(res.stdout)

def main():
    oracle_rows = {}
    with open("oracle_data.csv", "r", encoding="utf-8") as fin:
        reader = csv.DictReader(fin)
        for row in reader:
            oracle_rows[row['대출관리번호']] = {
                'oracle_fee': int(row['oracle_이자금액'])
            }

    query_asis = """
    SELECT 대출관리번호,
           TRUNC(
             (CAST(대출잔액 AS BIGNUMERIC) * (CAST(약정금리 AS BIGNUMERIC) / CAST(100 AS BIGNUMERIC)))
             * ((CAST(DATE_DIFF(이자계산기준일, 대출실행일자, DAY) AS BIGNUMERIC) / CAST(365 AS BIGNUMERIC))
                + CAST(30 AS BIGNUMERIC) / CAST(365 AS BIGNUMERIC))
           , 0) AS 이자금액_asis
      FROM `DM.월별대출이자산출`
     ORDER BY 대출관리번호
    """

    query_optimized = """
    SELECT 대출관리번호,
           TRUNC(
             (CAST(대출잔액 AS BIGNUMERIC)
              * CAST(약정금리 AS BIGNUMERIC)
              * (CAST(DATE_DIFF(이자계산기준일, 대출실행일자, DAY) AS BIGNUMERIC) + BIGNUMERIC '30'))
             / BIGNUMERIC '36500'
           , 0) AS 이자금액_optimized
      FROM `DM.월별대출이자산출`
     ORDER BY 대출관리번호
    """

    print("Running AS-IS query...")
    res_asis = {r['대출관리번호']: int(float(r['이자금액_asis'])) for r in run_bq_query(query_asis)}
    print("Running Optimized query...")
    res_opt = {r['대출관리번호']: int(float(r['이자금액_optimized'])) for r in run_bq_query(query_optimized)}

    diff_asis = diff_opt = 0
    for lid, data in oracle_rows.items():
        if data['oracle_fee'] != res_asis.get(lid, -1): diff_asis += 1
        if data['oracle_fee'] != res_opt.get(lid, -1):  diff_opt += 1

    n = len(oracle_rows)
    print(f"\nTotal: {n:,}")
    print(f"AS-IS  불일치: {diff_asis:,} / {n:,} ({diff_asis/n*100:.4f}%)")
    print(f"TO-BE  불일치: {diff_opt:,}  / {n:,} ({diff_opt/n*100:.4f}%)")

if __name__ == "__main__":
    main()

Oracle에서 이식한 정산 쿼리를 분산 데이터베이스 환경에서 안전하게 운영하기 위한 필수 체크리스트입니다.

**수식 설계**
- [ ] 나눗셈은 항상 마지막 단계로 — **후순위 나눗셈(Division Deferral)** 적용
- [ ] 중간 나눗셈이 불가피한 경우: 분자·분모를 먼저 곱셈으로 통합 후 단일 나눗셈으로 대체

**타입 관리**
- [ ] 모든 수치 컬럼에 명시적 `CAST(col AS BIGNUMERIC)` 선언
- [ ] 소수 리터럴은 `BIGNUMERIC '30'` 프리픽스 또는 `CAST(30 AS BIGNUMERIC)` 형태로 기입
- [ ] `FLOAT64` / `DOUBLE` 타입과의 혼합 연산 금지

**UNION ALL**
- [ ] 모든 브랜치의 수치 컬럼 타입을 동일한 고정소수점 타입으로 명시적 통일 (Tier 1)
- [ ] 상수 리터럴 브랜치도 예외 없이 타입 프리픽스 적용 (Tier 2)
- [ ] 수식 내 피연산자 사전 업캐스팅 (Tier 3)
- [ ] 마이그레이션 린터로 빌드 타임 사전 검증 (Tier 4)

**검증 파이프라인**
- [ ] `bq CLI` 대량 쿼리 시 `--max_rows=150000` 명시 (기본값 100건 제한 우회)
- [ ] 정수 경계 케이스 전용 시뮬레이션(`verify.py`) 마이그레이션 전 실행
- [ ] Oracle 원천 결과와 1:1 전수 대조 (`compare_results.py`) 실행

후순위 나눗셈 하나로 6종 데이터베이스 전체에서 100.0000% 정합성을 달성했습니다.

핵심 교훈은 명확합니다:

> **수학적으로 동치인 수식이라도, 연산 순서가 정밀도를 결정한다.**

Oracle에서 오차가 발생하지 않았던 이유는 운이 아닙니다. 80자리 임시 소프트웨어 연산 버퍼 아키텍처가 중간 나눗셈의 소수점 손실을 원천 차단했기 때문입니다. 반면 BigQuery, Spanner, MySQL, Presto, Trino는 연산 단계마다 고정 스케일 정규화를 강제 적용하므로, 중간 나눗셈이 있는 수식은 필연적으로 정수 경계 케이스에서 오차를 유발합니다.

플랫폼 마이그레이션 시 수식의 정합성 재검토는 선택이 아닌 필수입니다. 특히 `/ 365`, `/ 12`, `/ 100`처럼 무한 순환소수를 만드는 나눗셈이 수식 중간에 존재한다면, 후순위 나눗셈 적용 여부를 반드시 검토하십시오.