금융 앱의 통화 반올림: 안전하게 금액 저장하기

한 푼 버그가 발생하는 이유

한 푼 버그는 사용자가 즉시 알아차리는 실수입니다. 상품 목록에서는 $19.99로 보이던 합계가 결제 단계에서 $20.00이 되거나, $14.38 환불이 $14.37로 처리되기도 합니다. 인보이스의 한 줄에는 “Tax: $1.45”로 나오는데, 총합은 다른 세금 계산으로 더해진 것처럼 보일 수 있습니다.

이런 문제는 보통 쌓이는 작은 반올림 차이에서 시작합니다. 돈은 단순한 "숫자"가 아닙니다. 통화가 사용하는 소수 자릿수, 언제 반올림할지, 라인 항목별로 반올림할지 최종 합계에서만 반올림할지 등의 규칙이 있습니다. 앱의 한 부분이 다른 선택을 하면 한 푼이 생기거나 사라질 수 있습니다.

또한 이런 문제는 가끔만 나타나 디버그가 어렵습니다. 같은 입력이 기기나 로케일 설정, 연산 순서, 값의 타입 변환 방식에 따라 다른 센트를 생성할 수 있습니다.

흔한 촉발 요인으로는 부동소수점으로 계산하고 “마지막에” 반올림하는 것(하지만 “마지막”은 곳마다 다릅니다), 한 화면에서 항목별로 세금을 적용하고 다른 곳에서 소계에 적용하는 것, 통화나 환율을 섞어 일관성 없는 단계에서 반올림하는 것, 또는 표시를 위해 값을 포맷하고 실수로 다시 숫자로 파싱하는 경우 등이 있습니다.

피해는 신뢰가 중요한 곳에서 가장 큽니다: 체크아웃 합계, 환불, 인보이스, 구독, 팁, 지급 및 비용 보고서 등. 한 푼 차이는 결제 실패, 대조 작업의 골칫거리, 그리고 "앱이 돈을 훔쳐간다"는 고객 문의를 초래할 수 있습니다.

목표는 단순합니다: 동일한 입력은 어디서든 동일한 센트를 만들어야 합니다. 같은 상품, 같은 세금, 같은 할인, 같은 반올림 규칙—화면, 기기, 언어, 내보내기에 상관없이요.

예시: 같은 $9.99 상품 2개에 세율 7.25%가 있다면, 세금을 항목별로 반올림할지 소계에서 반올림할지 결정하고 백엔드, 웹 UI, 모바일 앱에서 동일하게 적용하세요. 일관성이 "왜 여기서는 다르지?"라는 상황을 예방합니다.

왜 부동소수점은 돈에 위험한가

대부분 프로그래밍 언어는 float와 double 값을 이진으로 저장합니다. 많은 십진수 가격은 이진으로 정확히 나타낼 수 없어서, 저장한 값이 미세하게 더 크거나 작아지는 경우가 많습니다.

고전적인 예는 0.1 + 0.2입니다. 많은 시스템에서 0.30000000000000004가 됩니다. 겉보기엔 사소해 보이지만, 돈 로직은 보통 연결된 체인입니다: 상품 가격, 할인, 세금, 수수료, 그리고 최종 반올림. 작은 오차가 반올림 결정을 바꿔 한 푼 차이를 만들 수 있습니다.

사람들이 돈 반올림이 잘못됐다고 느낄 때 나타나는 증상들:

• 로그나 API 응답에 9.989999나 19.9000001 같은 값이 보인다.
• 많은 항목을 더한 후 합계가 조금씩 어긋난다.
• 환불 합계가 원래 청구액과 $0.01 차이가 난다.
• 같은 카트 합계가 웹, 모바일, 백엔드에서 다르게 나온다.

포맷팅은 종종 문제를 숨깁니다. 9.989999를 소수 둘째 자리로 출력하면 9.99로 보이므로 모든 것이 맞아 보입니다. 버그는 여러 값을 합하거나, 합계를 비교하거나, 세금 후 반올림할 때 드러납니다. 그래서 팀들이 이 문제를 배포 후 결제 제공자나 회계 내보내기와 대조하면서 발견하곤 합니다.

간단한 규칙: 돈을 부동소수점으로 저장하거나 합산하지 마세요. 통화를 그 통화의 소수 단위(예: 센트)로 셀 수 있는 정수로 취급하거나, 정확한 십진수 연산을 보장하는 decimal 타입을 사용하세요.

백엔드, 웹 앱, 모바일 앱(또는 AppMaster 같은 노코드 플랫폼 포함)을 빌드할 때는 항상 같은 원칙을 지키세요: 정확한 값을 저장하고, 정확한 값으로 계산하며, 표시할 때만 포맷하세요.

실제 통화를 반영하는 머니 모델을 선택하세요

대부분의 머니 버그는 산술 이전에 시작됩니다: 데이터 모델이 통화의 실제 작동 방식을 반영하지 못하는 경우입니다. 모델을 처음에 올바르게 잡으면 반올림은 추측 문제가 아니라 규칙 문제가 됩니다.

가장 안전한 기본은 금액을 통화의 소수 단위 정수로 저장하는 것입니다. USD는 센트, EUR는 유로 센트처럼요. 데이터베이스와 코드는 정확한 정수를 다루고, 사람에게 보여줄 때만 "소수점"을 더합니다.

모든 통화가 소수 둘째 자리(2자리)를 쓰는 것은 아니므로 모델은 통화를 인식해야 합니다. JPY는 소수 단위가 0이고(1엔이 최소 단위), BHD는 보통 3자리(1디나르 = 1000 필스)를 사용합니다. "항상 두 자리"로 하드코딩하면 조용히 과청구하거나 부족 청구할 수 있습니다.

실용적인 머니 레코드는 보통 다음이 필요합니다:

• amount_minor (정수, 예: $19.99면 1999)
• currency_code (USD, EUR, JPY 같은 문자열)
• 시스템에서 조회가 어려우면 선택적 minor_unit 또는 scale(0, 2, 3)

금액마다 통화 코드를 함께 저장하세요(같은 테이블 안이라도). 다중 통화 가격, 환불, 보고서 등을 나중에 추가할 때 실수를 방지합니다.

또한 어디에서 반올림을 허용하고 어디에서 금지할지 결정하세요. 잘 통하는 한 정책은: 내부 합계, 할당, 원장 또는 진행 중인 변환에서는 반올림하지 말고; 세금 단계, 할인 단계, 최종 인보이스 라인처럼 정의된 경계에서만 반올림하라; 그리고 사용한 반올림 모드(half up, half even, 내림 등)를 기록해 결과를 재현 가능하게 하라 입니다.

단계별: 소수 단위 정수로 금액 구현하기

놀랄 만큼 적은 예측 불가능성을 원하면 내부에서 하나의 금액 표현을 선택하고 깨지지 않게 유지하세요: 금액을 통화의 소수 단위(보통 센트) 정수로 저장합니다.

예: $10.99는 1099이고 통화는 USD입니다. 소수 단위가 없는 통화인 JPY는 1500엔이 1500으로 남습니다.

확장 가능한 간단한 구현 경로:

1. 데이터베이스: amount_minor를 64비트 정수로 저장하고 통화 코드를 함께 보관하세요. 컬럼 이름을 명확히 해서 누군가가 소수형으로 착각하지 않게 합니다.
2. API 계약: { amount_minor: 1099, currency: "USD" }처럼 전송하세요. "$10.99" 같은 포맷 문자열이나 JSON 부동소수점은 피하세요.
3. UI 입력: 사용자가 입력하는 것을 숫자 대신 텍스트로 취급하세요. 정규화(공백 제거, 하나의 소수 구분자 허용)한 뒤 통화의 소수 단위 자릿수로 변환하세요.
4. 모든 계산을 정수로: 합계, 라인 합계, 할인, 수수료, 세금은 모두 정수로 연산하세요. 예: “백분율 할인은 계산 후 소수 단위로 반올림한다” 같은 규칙을 정의하고 항상 동일하게 적용하세요.
5. 표시는 마지막에만: 돈을 보여줄 때 amount_minor를 로케일과 통화 규칙으로 문자열로 변환하세요. 자신의 포맷 출력물을 다시 수학에 파싱하지 마세요.

실용적 파싱 예: USD라면 "12.3"을 "12.30"으로 간주한 뒤 1230으로 변환하세요. JPY의 경우 소수 입력을 초기에 거부하세요.

세금, 할인, 수수료 반올림 규칙

대부분의 한 푼 분쟁은 산술 실수 때문이 아닙니다. 정책 차이 때문입니다. 두 시스템이 모두 "정확"할 수 있지만 서로 다른 시점에서 반올림하면 여전히 불일치합니다.

반올림 정책을 문서화하고 모든 곳에서 사용하세요: 계산, 영수증, 내보내기, 환불. 일반적 선택에는 반올림 half-up(0.5 올림)과 half-even(0.5가 가장 가까운 짝수로) 등이 있습니다. 일부 수수료는 항상 올림(ceiling)을 요구해 부족 청구를 방지합니다.

총합은 보통 다음 결정에 따라 달라집니다: 라인별로 반올림할지 인보이스별로 반올림할지, 규칙을 섞지 않았는지(예: 세금은 라인별, 수수료는 인보이스별) 및 가격이 세금 포함인지(순액과 세금을 역산) 또는 세금 제외인지(순액으로부터 세금 계산) 여부.

할인은 또 다른 갈래를 만듭니다. "10% 할인"을 세전으로 적용하면 과세 기준이 감소하고, 세금 후에 적용하면 고객이 내는 금액은 줄지만 신고된 세금은 달라지지 않을 수 있습니다(관할구나 계약에 따라 다름).

작은 예시가 규칙의 중요성을 보여줍니다. $9.99짜리 상품 2개에 7.5% 세율이 있다면, 라인별로 세금을 반올림하면 각 라인 세금은 $0.75(9.99 x 0.075 = 0.74925)로 되어 총 세금은 $1.50가 됩니다. 인보이스 합계에서 세금을 계산해도 여기서는 $1.50이지만, 가격을 조금 바꾸면 1센트 차이가 발생할 수 있습니다.

지원과 재무가 쉽게 설명할 수 있도록 규칙을 평이한 언어로 작성하세요. 그런 다음 동일한 헬퍼를 세금, 수수료, 할인, 환불에 재사용하세요.

총액이 흐려지지 않는 통화 변환

다중 통화 산술은 작은 반올림 선택이 합계를 서서히 바꿀 수 있는 곳입니다. 목표는 단순합니다: 한 번 변환하고 목적을 가지고 반올림하며 원본 사실을 보관하세요.

환율은 명시적 정밀도로 저장하세요. 흔한 패턴은 rate_micro처럼 스케일된 정수로 저장하는 것(예: 1.234567을 1234567로, 스케일 1,000,000)입니다. 또 다른 옵션은 고정 소수 타입이지만, 필드에 스케일을 적어두어 추측할 수 없게 하세요.

보고 및 회계용 기본 통화를 정하세요(보통 회사 통화). 들어오는 금액을 원장과 분석을 위해 기본 통화로 변환하되 원래 통화와 금액도 같이 보관하세요. 그렇게 하면 나중에 모든 숫자를 설명할 수 있습니다.

흐름을 막는 규칙들:

• 회계에서는 한 방향(외화 → 기본화)으로만 변환하고, 왔다갔다 변환하지 마세요.
• 반올림 시점을 결정하세요: 라인별로 반올림해야 라인 합계를 보여줘야 하는 경우가 있고, 총합만 보여주면 끝에서 반올림할 수 있습니다.
• 반올림 모드를 일관되게 사용하고 문서화하세요.
• 원금액, 통화, 거래에 사용된 정확한 환율을 저장하세요.

예: 고객이 19.99 EUR를 결제하면 이를 1999 minor units와 currency=EUR로 저장하고, 체크아웃 당시 사용한 환율(예: EUR→USD를 마이크로 단위로)을 함께 저장합니다. 원장은 변환된 USD 금액(선택한 반올림 규칙으로 반올림)을 저장하지만, 환불은 저장된 원래 EUR 금액과 통화를 사용하지 USD에서 다시 변환하지 않습니다. 이렇게 하면 "왜 19.98 EUR를 돌려받았나요?" 같은 문의를 막을 수 있습니다.

기기 간 포맷팅과 표시

최종 단계는 화면입니다. 저장상으로 값이 맞더라도 포맷팅이 웹과 모바일 간에 다르면 틀리게 보일 수 있습니다.

로케일마다 구두점과 심볼 위치가 다릅니다. 예를 들어 미국 사용자는 $1,234.50을 기대하지만, 유럽 많은 지역에서는 1.234,50 €를 기대합니다(같은 값, 다른 구분자와 심볼 위치). 포맷을 하드코딩하면 사용자를 혼란스럽게 하고 지원 비용을 늘립니다.

한 가지 규칙을 지키세요: 코어에서 포맷하지 말고 경계에서 포맷하세요. 진실의 원천은 (currency code, minor units integer) 여야 합니다. 문자열로 바꿀 때만 포맷하고, 포맷된 문자열을 다시 파싱하지 마세요. 그 과정에서 반올림, 트리밍, 로케일 관련 놀라움이 숨어듭니다.

환불 같은 음수 금액은 일관된 스타일을 선택하세요. 어떤 시스템은 -$12.34로, 다른 시스템은 ($12.34)로 표시합니다. 둘 다 괜찮지만 화면마다 바뀌면 오류처럼 보입니다.

간단한 기기 간 계약:

• 통화는 기호가 아닌 ISO 코드(예: USD, EUR)로 전달하세요.
• 기본적으로 기기 로케일을 사용해 포맷하되 앱 내 오버라이드를 허용하세요.
• 다중 통화 화면에서는 금액 옆에 통화 코드를 표시하세요(예: 12.34 USD).
• 입력 포맷과 표시 포맷을 분리하세요.
• 포맷 전에 규칙에 따라 한 번 반올림하세요.

예: 고객이 모바일에서 10,00 EUR 환불을 보고 데스크탑에서 -€10을 보면 혼동할 수 있습니다. 코드(10,00 EUR)를 같이 보여주고 음수 스타일을 일관되게 쓰면 변경되었는지 궁금해하지 않습니다.

예시: 예측 가능한 체크아웃, 세금, 환불

간단한 카트:

• Item A: $4.99 (499 cents)
• Item B: $2.50 (250 cents)
• Item C: $1.20 (120 cents)

소계 = 869 cents ($8.69). 먼저 10% 할인 적용: 869 x 10% = 86.9 cents → 87 cents로 반올림. 할인된 소계 = 782 cents ($7.82). 이제 세금 8.875%를 적용합니다.

여기서 반올림 규칙이 최종 페니를 바꿀 수 있습니다.

인보이스 총액에 대해 세금을 계산하면: 782 x 8.875% = 69.4025 cents → 69 cents로 반올림.

라인별로(할인 후) 세금을 계산하고 각 라인에서 반올림하면:

• Item A: $4.49 세금 = 39.84875 cents → 40
• Item B: $2.25 세금 = 19.96875 cents → 20
• Item C: $1.08 세금 = 9.585 cents → 10

라인 세금 합계 = 70 cents. 동일한 카트, 동일한 세율이지만 다른 유효한 규칙으로 1센트 차이가 발생합니다.

세금 후에 배송비 399 cents($3.99)를 더하면 총합은 인보이스 레벨 세금일 때 $12.50, 라인 레벨 세금일 때 $12.51가 됩니다. 하나의 규칙을 선택하고 문서화한 뒤 일관되게 유지하세요.

이제 Item B만 환불한다고 합시다. 할인된 가격(225 cents)과 해당 항목에 속한 세금을 환불하세요. 라인 레벨 세금이면 225 + 20 = 245 cents($2.45)입니다. 이렇게 하면 나머지 합계가 정확히 맞아떨어집니다.

나중에 불일치를 설명하려면 각 청구 및 환불에 대해 다음 값을 로깅하세요:

• 라인별 순액 센트, 라인별 세금 센트, 사용한 반올림 모드
• 인보이스 할인 센트와 할당 방식
• 사용된 세율과 과세 기준 센트
• 배송/수수료 센트와 과세 여부
• 최종 합계 센트와 환불 센트

금액 계산을 테스트하는 방법

대부분의 머니 버그는 산술 버그가 아닙니다. 반올림, 순서, 포맷팅 버그로 특정 카트나 날짜에만 드러납니다. 좋은 테스트는 그런 경우들을 평범하게 만듭니다.

골든 테스트로 시작하세요: 고정 입력과 마이너 단위(센트)로 정확한 기대값을 가진 테스트입니다. 주장(assertion)은 엄격하게 하세요. 아이템이 199 cents이고 세금이 15 cents라면, 테스트는 정수 값을 검사해야 하고 포맷 문자열을 검사하면 안 됩니다.

작은 골든 세트로도 많은 경우를 커버할 수 있습니다:

• 세금, 할인, 수수료가 있는 단일 라인 아이템(각 중간 반올림 검사)
• 라인별 반올림 대 소계 반올림(선택한 규칙 검증)
• 환불 및 부분 환불(기호와 반올림 방향 검증)
• 변환 왕복(A→B→A)과 반올림 위치에 대한 정책
• 경계값(1센트 아이템, 대량 수량, 매우 큰 총합)

그다음 속성 기반 검사(property-based checks)나 단순 무작위 테스트를 추가해 놀라운 경우를 잡으세요. 하나의 기대값 대신 불변식을 주장하세요: 총합은 라인 합계의 합과 같다, 분수 소수 단위는 절대 나타나지 않는다, "총합 = 소계 + 세금 + 수수료 - 할인"이 항상 성립한다 등.

크로스 플랫폼 테스트도 중요합니다. 결과는 백엔드와 클라이언트 사이에서 달라질 수 있습니다. Go 백엔드, Vue 웹 앱, Kotlin/SwiftUI 모바일이 있다면 각 계층에서 동일한 테스트 벡터를 실행하고 UI 문자열이 아니라 정수 출력값을 비교하세요.

마지막으로 시간에 따른 케이스를 테스트하세요. 인보이스에 사용된 세율을 저장하고 세율 변경 후에도 이전 인보이스가 같은 결과를 재계산하는지 검증하세요. 여기에서 "이전에는 일치했는데 이제 다르다"는 버그가 생깁니다.

피해야 할 흔한 함정

대부분의 한 푼 버그는 산술 실수가 아니라 정책의 문제입니다: 코드가 정확히 시킨 대로 동작하는데 재무가 기대한 방식과 다릅니다.

주의할 함정들:

• 너무 일찍 반올림하기: 각 라인 항목을 반올림한 다음 소계를 반올림하고 다시 세금을 반올림하면 합계가 흐트러집니다. 규칙(예: 라인별 세금 vs 인보이스 합계)을 정하고 정책이 허용하는 곳에서만 반올림하세요.
• 한 필드에 여러 통화 섞기: 동일한 "총합" 필드에 USD와 EUR를 더하는 것은 환불, 보고, 대조에서 문제를 일으킵니다. 금액에 통화를 태그하고 교차 통화 합계를 내기 전에 합의된 환율로 변환하세요.
• 사용자 입력 파싱 오류: 사용자가 "1,000.50", "1 000,50", "10.0" 등을 입력합니다. 파서가 한 형식만 가정하면 100050으로 잘못 청구하거나 끝자리 0을 떼어버릴 수 있습니다. 입력을 정규화, 검증하고 소수 단위로 저장하세요.
• 포맷된 문자열을 API나 DB에 사용하기: "$1,234.56"은 표시용입니다. API가 이를 수락하면 다른 시스템이 다르게 파싱할 수 있습니다. 정수(소수 단위)와 통화 코드를 전달하고 각 클라이언트에서 로컬로 포맷하게 하세요.
• 세율이나 환율 테이블 버전 관리 누락: 세율, 면제, 반올림 규칙은 바뀝니다. 옛날 비율을 덮어쓰면 과거 인보이스를 재현할 수 없습니다. 계산마다 버전이나 유효 날짜를 저장하세요.

간단한 현실 점검: 월요일에 생성된 체크아웃은 지난달 세율을 사용했고, 금요일에 환불했을 때 세율이 바뀌었다면 원본 세율과 반올림 정책을 저장하지 않았다면 환불이 원본 영수증과 맞지 않을 것입니다.

빠른 체크리스트 및 다음 단계

놀랄 일을 줄이려면 돈을 작은 시스템으로 취급하세요: 명확한 입력, 규칙, 출력이 있는 시스템입니다. 대부분의 한 푼 버그는 반올림 허용 위치를 문서화하지 않았기 때문에 살아남습니다.

출시 전 체크리스트:

• 데이터베이스, 비즈니스 로직, API 어디에서나 금액을 소수 단위 정수(센트 등)로 저장하세요.
• 모든 수학을 정수로 하고 표시 포맷은 마지막에만 수행하세요.
• 계산(세금, 할인, 수수료, 환율)마다 하나의 반올림 지점을 선택하고 한 곳에서 강제하세요.
• 웹과 모바일에서 통화 규칙(소수 자릿수, 구분자, 음수 표현)을 일관되게 포맷하세요.
• 0.01, 변환에서 반복되는 소수, 환불, 부분 캡처, 큰 장바구니 같은 경계 케이스 테스트를 추가하세요.

계산 유형별로 반올림 정책을 한 줄로 적어두세요. 예: "할인은 라인 항목별로 반올림하여 가장 가까운 센트로 한다; 세금은 인보이스 합계에서 반올림한다; 환불은 원래의 반올림 경로를 반복한다." 이러한 정책을 코드 근처와 팀 문서에 두어 흐트러지지 않게 하세요.

중요 단계마다 가벼운 로그를 추가하세요. 입력 값, 선택한 정책 이름, 마이너 단위 출력값을 캡처하세요. 고객이 "한 푼 더 청구되었다"고 신고하면, 한 줄의 로그로 이유를 바로 설명할 수 있어야 합니다.

프로덕션에서 로직을 바꾸기 전에 작은 감사를 계획하세요. 실제 과거 주문 샘플에서 새 로직으로 다시 계산하고 옛 결과와 비교해 불일치 건수를 세세요. 몇 건을 수동으로 검토해 새 정책과 일치하는지 확인하세요.

만약 같은 규칙을 세 번 다시 쓰지 않고 엔드투엔드 흐름을 만들고 싶다면 AppMaster (appmaster.io)은 공유 백엔드 로직을 가진 완전한 앱에 적합하도록 설계되었습니다. PostgreSQL의 Data Designer에서 amount_minor를 마이너 유닛 정수로 모델링하고, Business Process에 반올림 및 세금 단계를 한 번 구현한 뒤 웹과 네이티브 모바일 UI에서 동일한 로직을 재사용할 수 있습니다.