30 · 수치 정확도

29장에서 Date가 Double이라 기준점에서 멀수록 눈금이 성겨진다는 것을 봤다. 이 챕터는 그 Double 자체를 파고든다.

부동소수점 버그의 성질은 이 티어의 다른 주제들과 같다 — 크래시가 나지 않는다. 계산은 정상적으로 끝나고 값도 그럴듯하다. 다만 1원이 안 맞고, 합계가 항목 합과 다르고, 같은 데이터를 다른 순서로 더하면 다른 답이 나온다.

P1 19장에서 정수 오버플로가 Swift 런타임 트랩으로 잡힌다는 것을 봤다. 부동소수점은 정반대다 — 트랩이 없다. 오버플로는 infinity가 되고, 정의되지 않은 연산은 nan이 되어 조용히 전파된다.

Q1. IEEE 754는 왜 0.1 + 0.2 ≠ 0.3인가?

CS 원리

부동소수점은 고정된 비트 수로 넓은 범위의 실수를 근사하려는 설계다. 배정밀도(Double)는 64비트를 이렇게 나눈다.

• 부호 1비트
• 지수 11비트 — 소수점의 위치를 정한다. 범위를 담당한다.
• 가수(mantissa) 52비트 — 유효 숫자를 담는다. 정밀도를 담당한다.

핵심은 가수가 이진수라는 것이다. 표현 가능한 값은 2의 거듭제곱의 유한 합뿐이다. 0.5(2⁻¹), 0.25(2⁻²), 0.75(2⁻¹+2⁻²)는 정확하지만, 0.1은 그런 합으로 만들어지지 않는다.

이는 진법의 문제다. 10진법에서 유한 소수인 분수는 분모가 2와 5로만 이루어진 것뿐이고, 2진법에서는 분모가 2의 거듭제곱인 것뿐이다. 0.1 = 1/10 = 1/(2×5)인데 분모에 5가 있어 2진법에서 무한 순환한다.

여기서 두 번째 성질이 나온다 — 정밀도는 값의 크기에 상대적이다. 가수 비트 수가 고정이므로, 값이 커지면 표현 가능한 값 사이의 간격(ULP)도 커진다. 그래서 2⁵³ + 1은 Double로 표현되지 않고 2⁵³과 같은 값이 된다.

iOS에서는

Swift에서 이를 직접 확인할 수 있다. Double의 description은 원래 값으로 되돌아가는 가장 짧은 표기를 보여주므로, 실제 저장값을 보려면 다른 수단이 필요하다.

0.1 + 0.2                    // 0.30000000000000004
0.1 + 0.2 == 0.3             // false

// 실제 저장값을 보려면 자릿수를 늘려 출력한다
String(format: "%.55f", 0.1)
//   0.1000000000000000055511151231257827021181583404541015625

// 비트 구성 확인
let bits = 0.1.bitPattern
String(bits, radix: 2)       // 부호 1 + 지수 11 + 가수 52 비트
0.1.exponent                 // -4
0.1.significandBitPattern    // 가수의 실제 비트

정확히 표현되는 값도 있다. 2의 거듭제곱과 그 합은 오차가 없다.

0.5 + 0.25 == 0.75           // true   — 둘 다 2의 거듭제곱
1.0 + 2.0 == 3.0             // true   — 작은 정수는 정확하다
0.1 + 0.1 == 0.2             // true   — 같은 오차가 상쇄되는 우연

// 정수도 한계가 있다 — 2^53 을 넘으면 인접한 정수가 표현되지 않는다
Double(9_007_199_254_740_992)      // 2^53
Double(9_007_199_254_740_993)      // 2^53 + 1 인데 결과는 2^53 과 같다
Double(2 << 52) == Double((2 << 52) + 1)   // true

이 마지막이 실무에서 ID를 Double로 다룰 때 사고를 낸다. 64비트 정수 ID를 JSON에서 Double로 파싱하면 큰 값에서 조용히 뭉개진다(31장에서 다시 다룬다).

// ❌ JSON 숫자를 Double 로 받으면 큰 ID 가 손상된다
struct Bad: Codable { let id: Double }

// ✅ 정수는 정수로, 아주 크면 문자열로 받는다
struct Good: Codable { let id: Int64 }
struct Safer: Codable { let id: String }

실험 · 도구

표현 한계를 직접 재현해 보자.

import Foundation

// 어떤 10진 소수가 정확히 표현되는지 확인한다
for v in [0.5, 0.25, 0.75, 0.1, 0.2, 0.3, 0.125, 1.0 / 3.0] {
    let exact = Decimal(v)                      // Double 의 실제 값을 10진으로 펼친다
    let isExact = "\(v)" == "\(exact)"
    print(String(format: "%-8@ %@ %@", "\(v)" as NSString,
                 isExact ? "정확" : "근사", "\(exact)" as NSString))
}
// 0.5      정확
// 0.1      근사  0.1000000000000000055511151231257827
// 0.3      근사  0.299999999999999988897769753748434595

ULP가 값의 크기에 따라 어떻게 변하는지도 볼 수 있다.

for v in [1.0, 1_000.0, 1e9, 787_234_200.0, 1e15, 1e16] {
    print(String(format: "%16.1f  ulp = %.3e", v, v.ulp))
}
//              1.0  ulp = 2.220e-16
//           1000.0  ulp = 1.137e-13
//     1000000000.0  ulp = 1.192e-07     ← 29장 Date 의 정밀도가 이 값이다
//   1000000000000000.0  ulp = 1.250e-01  ← 1보다 커졌다
//  10000000000000000.0  ulp = 2.000e+00  ← 정수도 건너뛴다

커맨드라인에서 빠르게 확인할 수도 있다.

# 특정 값의 실제 저장값을 10진으로 펼쳐 본다
python3 -c "from decimal import Decimal; print(Decimal(0.1))"
#   0.1000000000000000055511151231257827021181583404541015625

# 비트 패턴 확인
python3 -c "
import struct
for v in [0.1, 0.5, 0.3]:
    b = format(struct.unpack('<Q', struct.pack('<d', v))[0], '064b')
    print(f'{v}: 부호 {b[0]} 지수 {b[1:12]} 가수 {b[12:]}')
"

프로젝트 적용

1. 부동소수점을 ==로 비교하지 않는다. 허용 오차를 정해 비교하거나(Q5), 애초에 정확한 타입을 쓴다(Q2).
2. 돈·수량처럼 정확해야 하는 값에 Double을 쓰지 않는다. Q2에서 다룬다.
3. 큰 정수 ID를 Double로 통과시키지 않는다. 2⁵³을 넘으면 조용히 뭉개진다. JSON 파싱 경로를 특히 확인한다.
4. "소수점 두 자리니까 안전하다"는 가정을 버린다. 0.01도 이진으로 정확하지 않다.
5. 표시와 계산을 분리한다. 화면에 0.30000000000000004가 보이는 것은 서식 문제이지만, 그 값으로 판정하는 것은 정확도 문제다.

꼬리 질문

let v = 0.1 + 0.2

// 표시 — 반올림해서 보여준다
v.formatted(.number.precision(.fractionLength(2)))   // "0.3"
String(format: "%.2f", v)                            // "0.30"

// 값 — 여전히 0.30000000000000004 다
v == 0.3                                             // false
if v > 0.3 { … }                                     // true 로 들어간다

Float(16_777_216) == Float(16_777_217)   // true  ← 2^24 를 넘으면 인접 정수가 뭉개진다
Double(16_777_217)                        // 정확하다

let x = 1.0 / 0.0            // inf   — 크래시하지 않는다
let y = 0.0 / 0.0            // nan
let z = y + 100              // nan   — 한 번 오염되면 계속 번진다

// NaN 은 자기 자신과도 같지 않다 — IEEE 754 규정이다
Double.nan == Double.nan     // false
Double.nan != Double.nan     // true

// 그래서 == 로는 검출할 수 없다
if z.isNaN { … }             // ✅
if z == .nan { … }           // ❌ 절대 참이 되지 않는다

// 경계에서 검증해 오염을 차단한다
extension Double {
    var finiteOrNil: Double? { isFinite ? self : nil }
}

guard let ratio = (a / b).finiteOrNil else {
    logger.error("비정상 값: a=\(a) b=\(b)")
    return .zero
}

Q2. 통화 계산에 Double을 쓰면 언제 터지는가?

CS 원리

돈 계산이 부동소수점과 맞지 않는 이유는 요구되는 불변식이 다르기 때문이다.

선택지는 둘이다.

• 정수 최소 단위 — 원 단위 정수, 센트 단위 정수로 다룬다. 가장 빠르고 정확하며 오버플로만 조심하면 된다. 다만 나눗셈(할인율·이자)에서 스스로 반올림 규칙을 정해야 한다.
• 10진 타입 — Decimal. 소수점 이하를 자연스럽게 다루고 반올림 규칙을 지정할 수 있다. 정수보다 느리지만 표현력이 높다.

여기서 중요한 원리 하나 — 정확한 타입을 쓰더라도 경계에서 오염될 수 있다. Decimal은 정확하지만, 이미 오차가 낀 Double을 감싸면 그 오차를 정확하게 보존할 뿐이다. 그래서 값이 Double을 한 번도 거치지 않게 경로 전체를 지켜야 한다.

iOS에서는

Decimal의 성질과 함정을 같이 봐야 한다.

import Foundation

// 정확하다 — 0.1 을 열 번 더해도 정확히 1
var sum = Decimal(0)
for _ in 0..<10 { sum += Decimal(string: "0.1")! }
sum == Decimal(1)                    // true

// Double 이었다면
var d = 0.0
for _ in 0..<10 { d += 0.1 }
d == 1.0                             // false — 0.9999999999999999

// ⚠️ 널리 퍼진 단순화는 정확하지 않다
Decimal(0.1) == Decimal(string: "0.1")!      // 이 툴체인에서는 true
//   리터럴 0.1 의 Double 표현이 "가장 짧게 반올림한 표현"과 우연히 일치한다

// ✅ 진짜 함정은 이쪽이다
Decimal(0.1 + 0.2) == Decimal(string: "0.3")!   // false
Decimal(0.1 + 0.2)                              // 0.3000000000000000512
//   이미 Double 로 연산을 거친 값을 감싸면 오차가 그대로 옮겨붙는다
//   NSDecimalNumber(value:) 도 동일하게 오염된다

그래서 디코딩부터 Decimal이어야 한다. Double 프로퍼티를 한 번이라도 거치면 그 순간 반올림 손실이 확정된다.

// ❌ Double 로 받았다가 나중에 변환 — 이미 늦었다
struct BadItem: Codable { let price: Double }

// ✅ 처음부터 Decimal 로 디코딩한다
struct Item: Codable {
    let price: Decimal          // JSONDecoder 가 직접 Decimal 로 파싱한다
    let quantity: Int
    var total: Decimal { price * Decimal(quantity) }
}

// 표시는 통화 서식으로 (28장 Q6)
item.total.formatted(.currency(code: "KRW"))

정수 최소 단위 방식도 유효하다. 원 단위 앱이라면 오히려 이쪽이 단순하다.

// 원 단위 정수 — 나눗셈이 없으면 가장 안전하고 빠르다
struct Money: Codable, Hashable {
    let won: Int64
    static func + (l: Self, r: Self) -> Self { Money(won: l.won + r.won) }
    var text: String { won.formatted(.currency(code: "KRW")) }
}
//   할인율·이자처럼 나눗셈이 필요해지면 반올림 규칙을 정해야 한다 (Q3)

실험 · 도구

오염 경로를 직접 재현해 보면 규칙이 분명해진다.

import Foundation

func show(_ label: String, _ d: Decimal) {
    print(String(format: "%-34@ %@", label as NSString, "\(d)" as NSString))
}

show("Decimal(string: \"0.3\")", Decimal(string: "0.3")!)      // 0.3
show("Decimal(0.3)",             Decimal(0.3))                 // 0.3
show("Decimal(0.1 + 0.2)",       Decimal(0.1 + 0.2))           // 0.3000000000000000512
show("Decimal(0.1) + Decimal(0.2)", Decimal(0.1) + Decimal(0.2))  // 0.3

// 합계 비교 — 항목 합과 총합이 맞는지 본다
let prices = ["19900", "29900", "9900", "0.1", "0.2"]
let dec = prices.compactMap { Decimal(string: $0) }.reduce(0, +)
let dbl = prices.compactMap { Double($0) }.reduce(0, +)
print("Decimal 합: \(dec)")     // 59700.3
print("Double  합: \(dbl)")     // 59700.30000000001

기존 코드에서 위험한 경로를 훑는다.

# 금액 성격 필드가 Double 인 곳
grep -rnE "(price|amount|total|balance|fee|tax|discount).*: *(Double|Float)" \
     --include=*.swift .

# Double 을 Decimal 로 감싸는 곳 — 이미 오염됐을 수 있다
grep -rn "Decimal(" --include=*.swift . | grep -v "Decimal(string:" | grep -v "Decimal(sign:"

# JSON 디코딩에서 금액이 Double 로 들어오는지 확인
grep -rn -B3 -A3 "price\|amount" --include=*.swift . | grep -i "double"

프로젝트 적용

1. 금액 타입을 하나 정해 전 계층에서 쓴다. Decimal이든 정수 Money든, 섞지 않는 것이 핵심이다.
2. 디코딩 단계부터 정확한 타입으로 받는다. Double을 한 번 거치면 그 시점에 손실이 확정된다.
3. Decimal(리터럴) 대신 Decimal(string:)을 쓰는 습관을 들인다. 지금 툴체인에서 우연히 맞더라도, 의도가 드러나는 쪽이 안전하다.
4. 금액에 Double이 등장하면 린트로 막는다. 새로 들어오는 것을 차단하는 것이 이미 있는 것을 찾는 것보다 싸다.
5. 서버와 금액 표현을 합의한다. JSON 숫자는 파서에 따라 Double로 해석될 수 있어, 문자열로 주고받는 방식이 안전한 경우가 많다(31장).

꼬리 질문

// 항목별 반올림 vs 합계 반올림 — 결과가 다르다
let items = [Decimal(string: "333")!, Decimal(string: "333")!, Decimal(string: "333")!]
let rate  = Decimal(string: "0.1")!

// (A) 항목별로 반올림한 뒤 합산
let a = items.map { round2($0 * rate) }.reduce(0, +)     // 33.3 → 33 씩 → 99

// (B) 합산한 뒤 반올림
let b = round2(items.reduce(0, +) * rate)                // 999 × 0.1 = 99.9 → 100

func round2(_ d: Decimal) -> Decimal {
    var input = d, result = Decimal()
    NSDecimalRound(&result, &input, 0, .plain)
    return result
}

// 대량 집계는 정수로
let totalWon = transactions.reduce(Int64(0)) { $0 + $1.amountWon }
//   Int64 덧셈이라 빠르고 정확하다. 오버플로만 주의한다.

// 오버플로 방어 — P1 19장에서 본 트랩이 여기서 도움이 된다
let safe = transactions.reduce(Int64(0)) { acc, t in
    let (v, overflow) = acc.addingReportingOverflow(t.amountWon)
    precondition(!overflow, "금액 합계 오버플로")
    return v
}

struct Money: Hashable, Codable {
    let amount: Decimal
    let currency: String        // ISO 4217 — "KRW", "USD"

    static func + (l: Money, r: Money) throws -> Money {
        guard l.currency == r.currency else { throw MoneyError.currencyMismatch(l.currency, r.currency) }
        return Money(amount: l.amount + r.amount, currency: l.currency)
    }
}
//   서로 다른 통화를 더하려 하면 컴파일이 아니라 런타임에 막힌다.
//   제네릭 파라미터로 통화를 표현하면 컴파일 타임에 막을 수도 있다.

Q3. 반올림 규칙은 몇 가지이며 무엇을 골라야 하는가?

CS 원리

반올림은 표현 가능한 값 집합으로의 사상이다. 대부분의 값은 가장 가까운 값이 하나뿐이라 논란이 없지만, 정확히 중간인 값에서 규칙이 갈린다.

여기서 편향(bias)이라는 개념이 나온다. 학교에서 배운 "5는 올림"은 중간값을 항상 위로 보내므로, 값이 많아지면 합계가 계통적으로 커진다. 개별 오차는 작아도 같은 방향으로 쌓이면 무시할 수 없다.

은행가 반올림(.toNearestOrEven)은 중간값을 짝수 쪽으로 보낸다. 0.5→0, 1.5→2, 2.5→2, 3.5→4. 위아래로 번갈아 가므로 편향이 상쇄된다. IEEE 754가 이것을 기본 반올림 모드로 정한 이유다.

두 번째로 음수에서의 방향이 헷갈린다. 두 가지 축이 있다.

• 수직선 기준 — .up은 항상 큰 쪽(오른쪽), .down은 항상 작은 쪽(왼쪽). −2.5는 .down으로 −3이 된다.
• 0 기준 — .towardZero는 절댓값이 작아지는 쪽, .awayFromZero는 커지는 쪽. −2.5는 .towardZero로 −2가 된다.

양수에서는 .down과 .towardZero가 같지만 음수에서는 다르다. 환불·차감처럼 음수가 등장하는 계산에서 이 차이가 드러난다.

iOS에서는

부동소수점은 rounded(_:), Decimal은 NSDecimalRound를 쓴다. 규칙 이름이 다르므로 대응을 알아둬야 한다.

// Double — FloatingPointRoundingRule
(2.5).rounded()                              // 3   (.toNearestOrAwayFromZero 기본)
(2.5).rounded(.toNearestOrEven)              // 2   은행가 반올림
(2.5).rounded(.up)                           // 3
(-2.5).rounded(.down)                        // -3  수직선 기준
(-2.5).rounded(.towardZero)                  // -2  0 기준 — .down 과 다르다

// 자릿수 반올림은 직접 스케일링해야 한다 — 여기서 오차가 낀다
func round2(_ v: Double) -> Double { (v * 100).rounded() / 100 }
round2(1.005)                                // 1.0  ← 1.005 가 이미 근삿값이라 기대와 다르다

자릿수 반올림에서 Double이 특히 위험하다. 1.005는 이진으로 1.00499999…이므로 100을 곱해도 100.49999…가 되어 내림된다. 이런 경우가 Decimal을 써야 하는 이유다.

import Foundation

func rounded(_ d: Decimal, scale: Int, mode: NSDecimalNumber.RoundingMode) -> Decimal {
    var input = d, result = Decimal()
    NSDecimalRound(&result, &input, scale, mode)
    return result
}

let v = Decimal(string: "1.005")!
rounded(v, scale: 2, mode: .plain)      // 1.01  ← 기대대로
rounded(v, scale: 2, mode: .bankers)    // 1.00  ← 짝수 쪽
rounded(v, scale: 2, mode: .down)       // 1.00
rounded(v, scale: 2, mode: .up)         // 1.01

규칙 대응은 이렇다.

Decimal의 .down·.up은 0 기준이라 Double의 .down(수직선 기준)과 이름이 같지만 음수에서 동작이 다르다. 이 대응표를 팀 문서에 박아 두는 편이 안전하다.

실험 · 도구

여섯 규칙의 결과를 나란히 찍어 보면 차이가 분명해진다.

import Foundation

let rules: [(String, FloatingPointRoundingRule)] = [
    ("toNearestOrAwayFromZero", .toNearestOrAwayFromZero),
    ("toNearestOrEven",         .toNearestOrEven),
    ("up",                      .up),
    ("down",                    .down),
    ("towardZero",              .towardZero),
    ("awayFromZero",            .awayFromZero),
]
let inputs = [0.5, 1.5, 2.5, -0.5, -2.5, -2.4]

print("규칙".padding(toLength: 24, withPad: " ", startingAt: 0)
      + inputs.map { String(format: "%6.1f", $0) }.joined())
for (name, rule) in rules {
    let row = inputs.map { String(format: "%6.0f", $0.rounded(rule)) }.joined()
    print(name.padding(toLength: 24, withPad: " ", startingAt: 0) + row)
}

편향이 실제로 쌓이는지도 측정할 수 있다.

// 0.5 단위 값 1000개를 두 규칙으로 반올림해 합계를 비교한다
let values = (0..<1000).map { Double($0) + 0.5 }
let exact  = values.reduce(0, +)
let away   = values.map { $0.rounded(.toNearestOrAwayFromZero) }.reduce(0, +)
let even   = values.map { $0.rounded(.toNearestOrEven) }.reduce(0, +)

print("정확한 합:      \(exact)")
print("항상 올림 합:   \(away)   차이 \(away - exact)")   // 계통적으로 크다
print("짝수 반올림 합: \(even)   차이 \(even - exact)")   // 거의 0 에 수렴

프로젝트 적용

1. 반올림 규칙을 코드가 아니라 명세로 정한다. 회계·세무 요구가 규칙을 정하고, 코드는 그것을 반영할 뿐이다. 주석에 근거를 남긴다.
2. 기본값에 기대지 않는다. rounded()는 학교식이고 IEEE 754 기본은 은행가식이다 — 둘이 다르다는 사실을 알고 명시적으로 고른다.
3. 음수가 등장하는 계산에서 .down과 .towardZero를 구분한다. 환불·차감·조정 로직이 해당한다.
4. 자릿수 반올림은 Decimal로 한다. Double에 100을 곱해 반올림하는 방식은 1.005에서 이미 어긋난다.
5. 반올림 지점을 한 곳에 모은다. 계산 중간마다 반올림하면 오차가 누적된다. 마지막에 한 번만 하는 것이 원칙이다.

꼬리 질문

let items = [Decimal(string: "0.335")!, Decimal(string: "0.335")!, Decimal(string: "0.335")!]

// (A) 매 단계 반올림 — 정보를 세 번 버린다
let a = items.map { rounded($0, scale: 2, mode: .plain) }.reduce(0, +)   // 0.34 × 3 = 1.02

// (B) 마지막에 한 번만 — 정보를 한 번만 버린다
let b = rounded(items.reduce(0, +), scale: 2, mode: .plain)              // 1.005 → 1.01

// 실제 합은 1.005 다. (B) 가 더 가깝다.

/// 비율을 정수 백분율로 배분하되 합이 정확히 total 이 되게 한다
func allocate(_ values: [Decimal], total: Int) -> [Int] {
    let sum = values.reduce(0, +)
    guard sum > 0 else { return Array(repeating: 0, count: values.count) }

    // 1) 내림으로 기본 배분
    let exact = values.map { $0 / sum * Decimal(total) }
    var base  = exact.map { (v: Decimal) -> Int in
        var input = v, out = Decimal()
        NSDecimalRound(&out, &input, 0, .down)
        return (out as NSDecimalNumber).intValue
    }

    // 2) 남은 몫을 나머지가 큰 순서로 하나씩 준다
    var remaining = total - base.reduce(0, +)
    let order = exact.indices.sorted {
        (exact[$0] - Decimal(base[$0])) > (exact[$1] - Decimal(base[$1]))
    }
    for i in order where remaining > 0 { base[i] += 1; remaining -= 1 }
    return base
}

allocate([Decimal(1), Decimal(1), Decimal(1)], total: 100)   // [34, 33, 33] — 합 100

Q4. 누적 오차는 어디서 커지는가?

CS 원리

덧셈에서 오차가 생기는 메커니즘은 지수 맞추기다. 두 부동소수점을 더하려면 지수를 같게 만든 뒤 가수를 더해야 하는데, 지수 차이가 크면 작은 값의 가수가 오른쪽으로 밀려나 잘린다.

가수가 52비트이므로, 두 값의 크기 차이가 2⁵³배를 넘으면 작은 값은 완전히 사라진다. 이것이 1e16 + 1 == 1e16인 이유다.

여기서 대수적 성질이 깨진다. 29장 Q2에서 달력 산술의 결합법칙이 깨지는 것을 봤는데, 부동소수점도 같은 문제를 갖는다.

• 결합법칙 (a+b)+c ≠ a+(b+c) — 실측으로 확인된다.
• 분배법칙도 성립하지 않을 수 있다.
• 덧셈 순서가 결과를 바꾸므로, 병렬 합산은 실행마다 다른 답을 낼 수 있다.

마지막이 실무에서 곤란하다. 여러 스레드로 나눠 합산하면 결합 순서가 비결정적이라 실행마다 미세하게 다른 결과가 나온다. 이는 버그가 아니라 부동소수점의 성질이지만, "같은 입력이면 같은 출력"을 기대하는 테스트를 깨뜨린다.

대응 원리는 큰 값과 작은 값이 만나는 횟수를 줄이는 것이다. 작은 값부터 더하면 비슷한 크기끼리 합쳐지므로 손실이 줄고, 보정 합산은 잘려나간 부분을 따로 기억했다가 다음 덧셈에 되돌린다.

iOS에서는

순서에 따른 차이를 직접 확인할 수 있다.

// 결합법칙이 깨진다
(1e16 + 1) - 1e16        // 0.0
(1e16 - 1e16) + 1        // 1.0

// 큰 값 하나에 작은 값을 많이 더하면 전부 삼켜진다
var s = 1e16
for _ in 0..<1000 { s += 1 }
s == 1e16                // true — 1000 번 더했는데 그대로다

// 작은 값부터 더하면 살아남는다
var t = 0.0
for _ in 0..<1000 { t += 1 }
t += 1e16
t - 1e16                 // 1000.0

보정 합산(Kahan summation)은 잘려나간 부분을 별도 변수에 기억해 다음 덧셈에 되돌린다.

/// 잘려나간 하위 비트를 보정하며 합산한다
func kahanSum(_ values: [Double]) -> Double {
    var sum = 0.0
    var c = 0.0                      // 아직 반영되지 못한 보정분
    for v in values {
        let y = v - c                // 이전에 잘린 만큼을 먼저 되돌린다
        let t = sum + y
        c = (t - sum) - y            // 이번에 잘린 양을 다시 기억한다
        sum = t
    }
    return sum
}

let vals = Array(repeating: 0.1, count: 10)
vals.reduce(0, +)        // 0.9999999999999999
kahanSum(vals)           // 1.0

다만 돈 계산에는 이것도 답이 아니다. 보정 합산은 오차를 줄일 뿐 정확하게 만들지는 않는다. 정확성이 요구되면 Decimal이나 정수로 가야 한다(Q2).

// 통계·그래픽처럼 근사가 허용되는 곳 → Kahan 또는 정렬 후 합산
// 금액·수량처럼 정확해야 하는 곳    → Decimal / 정수

// 정렬 후 합산 — 작은 값부터 더해 손실을 줄인다
let safer = values.sorted { abs($0) < abs($1) }.reduce(0, +)

실험 · 도구

순서가 결과를 바꾸는 것을 측정해 보자.

import Foundation

// 큰 값 하나 + 작은 값 다수
var values = Array(repeating: 1.0, count: 100_000)
values.append(1e16)

let forward  = values.reduce(0, +)                              // 큰 값이 앞쪽에 오는 경우
let sorted   = values.sorted { abs($0) < abs($1) }.reduce(0, +) // 작은 값부터
let kahan    = kahanSum(values)

print("정확한 합:   \(1e16 + 100_000)")
print("순서대로:    \(forward)")
print("정렬 후:     \(sorted)")
print("Kahan:      \(kahan)")
//   순서대로 더하면 작은 값들이 삼켜져 1e16 에 가깝게 나온다

병렬 합산의 비결정성도 확인할 수 있다.

// 같은 배열을 여러 번 병렬 합산하면 결과가 미세하게 흔들릴 수 있다
func parallelSum(_ v: [Double]) async -> Double {
    await withTaskGroup(of: Double.self) { group in
        let chunk = v.count / 4
        for i in 0..<4 {
            let slice = Array(v[(i * chunk)..<min((i + 1) * chunk, v.count)])
            group.addTask { slice.reduce(0, +) }
        }
        var total = 0.0
        for await partial in group { total += partial }   // 도착 순서가 비결정적이다
        return total
    }
}
//   부분합의 결합 순서가 매번 다를 수 있어 하위 비트가 흔들린다.
//   결정성이 필요하면 부분합을 인덱스 순으로 모아 더한다.

기존 코드에서 위험한 합산을 찾는다.

# 부동소수점 누적 합산 — 값의 크기 분포를 확인할 후보
grep -rn "reduce(0" --include=*.swift . | grep -iE "double|float|sum|total"

# 병렬 합산 — 결정성이 필요한 곳인지 검토
grep -rn -A5 "withTaskGroup" --include=*.swift . | grep -iE "\+=|reduce"

프로젝트 적용

1. 합산 결과를 ==로 비교하지 않는다. 순서가 조금만 달라도 하위 비트가 다르다(Q5).
2. 값의 크기 분포를 본다. 크기가 고르면 순서가 큰 문제가 안 되지만, 큰 값 하나에 작은 값 다수가 전형적인 위험 패턴이다.
3. 정확성이 필요하면 보정 합산이 아니라 정확한 타입으로 간다. Kahan은 줄일 뿐 없애지 못한다.
4. 병렬 합산에 결정성이 필요하면 결합 순서를 고정한다. 부분합을 인덱스 순으로 모은다.
5. 스냅샷 테스트에 부동소수점 합계를 그대로 넣지 않는다. 플랫폼·최적화 수준에 따라 하위 비트가 달라질 수 있다.

꼬리 질문

// ❌ 순진한 분산 — 값이 크면 음수 분산이 나오기도 한다
func naiveVariance(_ v: [Double]) -> Double {
    let n = Double(v.count)
    let sumSq = v.reduce(0) { $0 + $1 * $1 }
    let mean = v.reduce(0, +) / n
    return sumSq / n - mean * mean          // 큰 값끼리 빼기 — 위험
}

// ✅ Welford 온라인 알고리즘 — 수치적으로 안정적이다
func welfordVariance(_ v: [Double]) -> Double {
    var n = 0.0, mean = 0.0, m2 = 0.0
    for x in v {
        n += 1
        let delta = x - mean
        mean += delta / n
        m2 += delta * (x - mean)
    }
    return n > 1 ? m2 / n : 0
}

let big = (0..<1000).map { 1e9 + Double($0) }
naiveVariance(big)      // 음수나 0 이 나올 수 있다
welfordVariance(big)    // 안정적인 값

import Accelerate

let v = Array(repeating: 0.1, count: 1000)
let scalar = v.reduce(0, +)
var vector = 0.0
vDSP_sveD(v, 1, &vector, vDSP_Length(v.count))
scalar == vector            // 반드시 같지는 않다 — 부분합 결합 순서가 다르다

Q5. 수치 결과를 어떻게 테스트하는가?

CS 원리

부동소수점 비교의 어려움은 "같다"의 정의가 맥락에 달렸다는 데 있다.

절대 오차만 쓰면 큰 값에서 지나치게 엄격해진다 — 1e9 근처는 ULP가 이미 1.19e-7이라(Q1) ε = 1e-9로는 절대 통과하지 못한다. 반대로 상대 오차만 쓰면 0 근처에서 지나치게 관대해진다 — 0에 가까운 두 값은 상대 오차가 쉽게 커진다.

그래서 실무에서는 둘을 결합한다. 작은 값에는 절대 오차, 큰 값에는 상대 오차를 적용하는 형태다.

더 중요한 원칙이 하나 있다 — 근사 비교는 근사가 허용되는 값에만 쓴다. 금액을 Decimal로 정확히 계산해 놓고 테스트에서 accuracy: 0.01로 비교하면, 1원 오차를 통과시키는 테스트가 된다. 정확한 타입에는 엄격한 ==가 맞다.

iOS에서는

Swift Testing에는 정확도 비교 등가물이 없으므로 직접 정하거나 라이브러리를 쓴다.

import Testing
import Numerics        // swift-numerics

@Test func 평균이_기대값에_가깝다() {
    let result = average(of: samples)

    // ✅ swift-numerics — 절대·상대 오차를 함께 다룬다
    #expect(result.isApproximatelyEqual(to: 42.0, relativeTolerance: 1e-9))

    // ✅ 직접 정할 수도 있다
    #expect(abs(result - 42.0) <= 1e-9 * max(abs(result), 42.0))
}

// XCTest 에는 정확도 인자가 있다
XCTAssertEqual(result, 42.0, accuracy: 1e-9)

정확한 타입은 엄격하게 비교한다.

@Test func 금액_합계가_정확하다() {
    let total = cart.items.reduce(Decimal(0)) { $0 + $1.price }

    // ✅ Decimal 은 정확하므로 == 로 본다
    #expect(total == Decimal(string: "59700.30")!)

    // ❌ 근사 비교를 쓰면 1원 오차를 통과시킨다
    // #expect(abs(total - expected) < 0.01)
}

속성 기반 검사가 수치 코드에 특히 잘 맞는다. 개별 값이 아니라 불변식을 검사한다.

@Test(arguments: [
    [0.1, 0.2, 0.3], [1e16, 1.0, 1.0], [-5.0, 5.0], Array(repeating: 0.1, count: 100)
])
func 합산은_순서와_무관해야_한다_근사적으로(_ values: [Double]) {
    let a = values.reduce(0, +)
    let b = values.reversed().reduce(0, +)
    // 정확히 같지는 않지만 상대 오차 범위 안이어야 한다
    #expect(a.isApproximatelyEqual(to: b, relativeTolerance: 1e-12)
            || (a.isFinite && b.isFinite))
}

@Test func 반올림은_원본과_반올림단위_이내여야_한다() {
    for v in stride(from: -100.0, through: 100.0, by: 0.37) {
        #expect(abs(v.rounded() - v) <= 0.5)
    }
}

실험 · 도구

허용 오차를 잘못 잡으면 어떻게 되는지 확인해 보자.

import Foundation

func compare(_ a: Double, _ b: Double, absEps: Double, relEps: Double) -> String {
    let absOK = abs(a - b) <= absEps
    let relOK = abs(a - b) <= relEps * Swift.max(abs(a), abs(b))
    return "절대 \(absOK ? "통과" : "실패")  상대 \(relOK ? "통과" : "실패")"
}

// 작은 값 — 절대 오차가 적합
print(compare(0.1 + 0.2, 0.3, absEps: 1e-9, relEps: 1e-9))     // 둘 다 통과

// 큰 값 — 절대 오차는 실패한다
let big = 1e9
print(compare(big + 0.1, big, absEps: 1e-9, relEps: 1e-9))     // 절대 실패, 상대 통과

// 0 근처 — 상대 오차가 지나치게 엄격해진다
print(compare(1e-20, 2e-20, absEps: 1e-9, relEps: 1e-9))       // 절대 통과, 상대 실패

테스트에서 위험한 패턴을 찾는다.

# 부동소수점을 == 로 단언하는 테스트 — 플랫폼에 따라 깨진다
grep -rnE "#expect\(.*(Double|Float).*==" --include=*Tests*.swift .

# Decimal 을 근사 비교하는 테스트 — 정확성 회귀를 놓친다
grep -rn -B2 "accuracy:" --include=*Tests*.swift . | grep -i decimal

# 스냅샷에 부동소수점 값이 그대로 박혀 있는지
grep -rnE "[0-9]+\.[0-9]{10,}" --include=*.json __Snapshots__/ 2>/dev/null | head

프로젝트 적용

1. 타입에 따라 비교 방식을 정한다. Double·Float는 근사, Decimal·정수는 엄격. 이 규칙을 팀 컨벤션으로 박아 둔다.
2. 허용 오차를 상수로 정의하고 근거를 남긴다. 1e-9가 어디서 나왔는지 아무도 모르는 상황을 피한다.
3. 절대·상대를 결합한 헬퍼를 하나 만들어 쓴다. 매 테스트에서 다시 고민하지 않게 한다.
4. 불변식을 검사한다. "합이 100이다", "순서를 바꿔도 근사적으로 같다", "반올림 오차가 반올림 단위 이내다" 같은 성질은 개별 값보다 강한 검증이다.
5. 경계값을 테스트에 고정한다. 0, 음수, 2⁵³, 1e16, nan, infinity, 아주 작은 값. 이 목록이 이 챕터의 요약이기도 하다.

꼬리 질문

// 1000 개를 합산한다면
let epsilon = Double.ulpOfOne          // 2.22e-16
let tolerance = Double(values.count) * epsilon    // 약 2.2e-13
#expect(result.isApproximatelyEqual(to: expected, relativeTolerance: tolerance))

/// 1000회 누적 합산의 이론적 오차 상한 (n × ulpOfOne) 에 10배 여유
private let sumTolerance = 2.2e-12

// ❌ 하위 비트까지 고정 — 환경이 바뀌면 깨진다
#expect("\(result)" == "0.30000000000000004")

// ✅ 성질을 검사한다
#expect(result.isApproximatelyEqual(to: 0.3, relativeTolerance: 1e-12))
#expect(result > 0.29 && result < 0.31)

func validate(_ invoice: Invoice) {
    let itemSum = invoice.items.reduce(Decimal(0)) { $0 + $1.total }
    if itemSum != invoice.total {
        logger.error("합계 불일치: 항목합 \(itemSum) vs 총액 \(invoice.total)")
        metrics.increment("invoice.sum_mismatch")     // 지표로 추세를 본다
    }
}

출처 · 참고자료