28 · 로케일과 서식

27장이 문자열 그 자체의 표현을 다뤘다면, 이 챕터는 그 문자열을 사람에게 보여주고 사람의 기준으로 비교할 때 생기는 문제를 다룬다.

이 영역의 버그에는 공통된 성질이 하나 있다 — 개발자의 기기에서는 절대 재현되지 않는다. 한국어 환경에서 개발하면 복수형 버그가 눈에 안 보이고, 24시간제를 쓰면 AM/PM 문제가 안 나타나며, 터키어 사용자가 없으면 대소문자 변환 버그를 평생 못 만난다.

그래서 이 챕터의 실험 · 도구 절은 대부분 다른 로케일을 강제로 흉내 내는 방법이다. 재현할 수 없으면 고칠 수도 없다.

Q1. 로케일은 무엇을 결정하는가?

CS 원리

로케일은 매개변수화(parameterization)의 한 사례다. 프로그램의 동작 중 문화권마다 달라지는 부분을 코드에서 분리해 데이터로 빼낸 것이다.

이 데이터의 표준 저장소가 CLDR(Common Locale Data Repository)이다. 정렬 순서, 복수형 규칙, 날짜 필드 순서, 통화 기호 위치 같은 것들이 언어·지역별로 정리돼 있고, Apple·Google·Java 등 대부분의 플랫폼이 이 데이터를 쓴다. 그래서 "iOS가 정한 규칙"이 아니라 "업계가 공유하는 데이터"다.

설계에서 중요한 점은 축이 여러 개이고 서로 독립이라는 것이다.

• 언어 — 어떤 말로 쓰는가. 문자열 선택, 복수형 규칙.
• 지역 — 어디에 있는가. 통화, 도량형, 날짜 순서(월/일 vs 일/월).
• 스크립트 — 어떤 문자 체계인가. 같은 언어라도 다를 수 있다(세르비아어의 키릴/라틴).
• 달력·시간대 — 그레고리력인가 불교력인가, 12시간제인가 24시간제인가.

이 축들이 독립이라는 점이 실무에서 자주 간과된다. "한국어를 쓰는 미국 거주자"(ko_US)는 이상한 조합이 아니라 흔한 조합이다 — 앱은 한국어로 보되 통화는 달러여야 한다.

iOS에서는

iOS 16부터 축이 타입으로 분리됐다. 평평한 문자열을 쪼개 파싱하던 코드가 사라진다.

let loc = Locale(identifier: "ko_US")

// 구조화 접근 (iOS 16+)
loc.language.languageCode?.identifier     // "ko"
loc.language.script?.identifier           // "Kore"   ← 지정 안 해도 추론된다
loc.region?.identifier                    // "US"
loc.currency?.identifier                  // "USD"    ← 지역을 따른다

// 상위 지역은 ISO 국가코드가 아니라 UN M49 숫자 코드다
Locale.Region("KR").containingRegion?.identifier    // "030" (동아시아)
Locale.Region("KR").continent?.identifier           // "142" (아시아)

// 평평한 생성자도 그대로 남아 있다 — 대체가 아니라 추가
Locale(identifier: "ko_US").identifier    // "ko_US"

실무에서 자주 쓰는 조회는 이렇다.

// 사용자가 선호하는 언어 목록 — 첫 번째가 앱이 실제로 쓸 언어와 다를 수 있다
Locale.preferredLanguages           // ["ko-KR", "en-US"]

// 앱이 실제로 고른 언어 (번역이 있는 것 중에서 선택된다)
Bundle.main.preferredLocalizations  // ["ko"]

// 지역 기반 결정 — 언어가 아니라 지역을 봐야 한다
Locale.current.region?.identifier   // "US"
Locale.current.measurementSystem    // .us / .metric / .uk
Locale.current.firstDayOfWeek       // .sunday / .monday

실험 · 도구

다른 로케일을 강제로 흉내 내는 것이 이 챕터 전체의 핵심 기법이다. 스킴 인자로 앱 전체를 바꿀 수 있다.

# Xcode 스킴 › Run › Arguments › Arguments Passed On Launch
-AppleLanguages "(ar)"        # 아랍어 — RTL·복수형 6종
-AppleLocale "ar_SA"
-AppleTextDirection YES       # RTL 강제

# 시뮬레이터를 명령줄로 바꿔도 된다
xcrun simctl spawn booted defaults write -g AppleLanguages -array ar
xcrun simctl spawn booted defaults write -g AppleLocale -string ar_SA
xcrun simctl shutdown booted && xcrun simctl boot booted

코드에서 특정 로케일을 직접 만들어 비교하는 편이 테스트에는 더 낫다 — 기기 설정에 의존하지 않기 때문이다.

let cases = ["ko_KR", "en_US", "ar_SA", "th_TH", "tr_TR"]

for id in cases {
    let l = Locale(identifier: id)
    let price = 1234.5.formatted(.currency(code: l.currency?.identifier ?? "USD").locale(l))
    let date  = Date().formatted(.dateTime.year().month().day().locale(l))
    print(String(format: "%-8@ %-14@ %@", id as NSString, price as NSString, date as NSString))
}
// ko_KR    ₩1,235        2026. 8. 15.
// en_US    $1,234.50     Aug 15, 2026
// ar_SA    ١٬٢٣٤٫٥٠ ر.س.   ١٥‏/٨‏/٢٠٢٦     ← 숫자 자체가 다른 문자다
// th_TH    ฿1,234.50     15 ส.ค. 2569     ← 불교력이라 연도가 다르다

프로젝트 적용

1. "언어"로 판단하던 자리를 "지역"으로 바꾼다. 통화·도량형·주 시작 요일은 언어가 아니라 지역이 결정한다. preferredLanguages.first로 통화를 고르면 ko_US 사용자에게 원화를 보여주게 된다.
2. 로케일 값을 캐시하지 않는다. 사용자가 설정에서 바꾸면 앱이 살아 있는 동안에도 바뀐다. NSLocale.currentLocaleDidChangeNotification을 관찰한다.
3. 서버로 보낼 값과 화면에 보여줄 값을 분리한다. 저장·전송은 로케일 무관 형식(ISO 8601, 통화 코드, 원시 숫자), 표시만 로케일을 따른다(Q7).
4. 불교력·힌두력을 테스트에 넣는다. 태국(th_TH)은 연도가 543년 차이가 난다. 연도를 문자열로 잘라 쓰는 코드가 여기서 깨진다.
5. 지원 언어 목록을 명시적으로 관리한다. Bundle.main.preferredLocalizations로 앱이 실제 고른 언어를 확인한다 — 사용자 선호 1순위와 다를 수 있다.

꼬리 질문

if let url = URL(string: UIApplication.openSettingsURLString) {
    await UIApplication.shared.open(url)
}

// 기본 동작 — 시스템이 preferredLanguages 를 기반으로 채운다
//   Accept-Language: ko-KR;q=1.0, en-US;q=0.9

// 명시하고 싶다면
var req = URLRequest(url: url)
req.setValue(Locale.preferredLanguages.prefix(3)
                .enumerated()
                .map { "\($0.element);q=\(1.0 - Double($0.offset) * 0.1)" }
                .joined(separator: ", "),
             forHTTPHeaderField: "Accept-Language")

// ❌ 테스트가 기기 설정에 좌우된다
func priceText(_ v: Decimal) -> String { v.formatted(.currency(code: "KRW")) }

// ✅ 로케일을 받는다
func priceText(_ v: Decimal, locale: Locale = .current) -> String {
    v.formatted(.currency(code: "KRW").locale(locale))
}

Q2. 문자열 비교와 정렬은 왜 로케일에 따라 달라지는가?

CS 원리

정렬에는 비교자(comparator)가 필요하고, 비교자는 전순서(total order)를 정의해야 한다. 그런데 "문자열의 순서"에는 정답이 없다 — 무엇을 기준으로 삼느냐에 따라 여러 개의 유효한 순서가 존재한다.

코드포인트 순서가 사용자 기대와 어긋나는 이유는 두 가지다.

• 대문자가 소문자보다 앞이다. ASCII에서 Z(90)가 a(97)보다 작다. 그래서 File20이 file1보다 앞에 온다.
• 숫자를 글자로 비교한다. "10"과 "2"를 비교하면 첫 글자 1과 2를 보고 10이 작다고 판정한다.

여기서 중요한 성질이 하나 나온다 — 로케일 인식 비교자는 언어에 따라 결과가 바뀌므로, 그것으로 만든 순서를 저장하거나 캐시하면 안 된다. 사용자가 언어를 바꾸면 순서가 달라진다. 또한 로케일 비교자는 엄격 약순서(strict weak ordering)를 위반하는 경우가 드물게 있어, 정렬 알고리즘이 예측 불가능한 동작을 할 수 있다. 그래서 표시용 정렬과 저장용 순서를 분리하는 것이 원칙이다.

iOS에서는

세 비교를 목적에 맞게 나눠 쓰는 것이 전부다.

let files = ["file10.txt", "File20.txt", "file2.txt", "file1.txt"]

// ❌ 코드포인트 순서 — 사용자 기대와 다르다
files.sorted()
//   ["File20.txt", "file1.txt", "file10.txt", "file2.txt"]

// ✅ Finder 와 같은 순서
files.sorted { $0.localizedStandardCompare($1) == .orderedAscending }
//   ["file1.txt", "file2.txt", "file10.txt", "File20.txt"]

// 옵션을 직접 고르고 싶다면
files.sorted {
    $0.compare($1, options: [.caseInsensitive, .numeric],
               range: nil, locale: .current) == .orderedAscending
}

한글 목록에서도 차이가 난다 — 코드포인트 순서는 영문이 한글보다 항상 앞이지만, 로케일 인식 비교는 언어 설정에 따라 한글을 앞에 둔다.

let names = ["Zoe", "가나", "Alice", "다라"]

names.sorted()
//   ["Alice", "Zoe", "가나", "다라"]      ← 영문이 항상 먼저

names.sorted { $0.localizedStandardCompare($1) == .orderedAscending }
//   ko_KR 에서: ["가나", "다라", "Alice", "Zoe"]   ← 한글이 먼저

검색·필터에는 또 다른 선택이 필요하다. 사용자가 "seoul"로 검색했을 때 "Seoul"과 "Séoul"이 모두 걸려야 한다면 진단 기호 무시 옵션이 필요하다.

extension String {
    /// 검색용 느슨한 포함 판정 — 대소문자·진단기호·폭을 무시한다
    func fuzzyContains(_ needle: String) -> Bool {
        range(of: needle,
              options: [.caseInsensitive, .diacriticInsensitive, .widthInsensitive],
              locale: .current) != nil
    }
}

"Séoul".fuzzyContains("seoul")     // true

실험 · 도구

비교자별 결과를 나란히 찍어 보면 선택 기준이 분명해진다.

let items = ["file10.txt", "File20.txt", "file2.txt", "file1.txt"]

func show(_ label: String, _ sorted: [String]) {
    print(String(format: "%-26@ %@", label as NSString, sorted.joined(separator: "  ") as NSString))
}

show("sorted()", items.sorted())
show("localizedCompare",
     items.sorted { $0.localizedCompare($1) == .orderedAscending })
show("localizedStandardCompare",
     items.sorted { $0.localizedStandardCompare($1) == .orderedAscending })

// sorted()                   File20.txt  file1.txt  file10.txt  file2.txt
// localizedCompare           file1.txt  file10.txt  file2.txt  File20.txt
//     ← 대소문자는 정리됐지만 숫자는 여전히 글자로 비교한다
// localizedStandardCompare   file1.txt  file2.txt  file10.txt  File20.txt
//     ← 숫자를 값으로 읽는다. 이것만 사람 기대와 맞는다

로케일을 바꿔 가며 한글·영문 혼합 정렬이 어떻게 달라지는지도 확인한다.

let names = ["Zoe", "가나", "Alice", "다라", "Ärger"]

for id in ["ko_KR", "en_US", "de_DE", "sv_SE"] {
    let l = Locale(identifier: id)
    let s = names.sorted {
        $0.compare($1, options: [], range: nil, locale: l) == .orderedAscending
    }
    print("\(id): \(s.joined(separator: " "))")
}
//   de_DE 와 sv_SE 에서 "Ärger" 의 위치가 다르다 —
//   독일어는 A 와 함께, 스웨덴어는 Z 뒤에 놓는 관습이다

프로젝트 적용

1. 사용자에게 보이는 모든 목록 정렬을 localizedStandardCompare로 바꾼다. 파일·앨범·연락처·태그 등. 기본 sorted()가 남아 있으면 그게 버그다.
2. 저장·전송하는 순서에는 로케일 비교를 쓰지 않는다. 언어가 바뀌면 순서가 달라지므로 재현되지 않는다. 서버가 정렬하거나 명시적 sortOrder 필드를 쓴다.
3. 키·토큰 비교에는 ==를 쓴다. 로케일 인식 비교는 다른 문자를 같다고 판정할 수 있다(Q3).
4. 검색에는 .diacriticInsensitive를 고려한다. 사용자는 악센트를 입력하지 않는다.
5. 정렬 결과를 스냅샷 테스트로 고정하지 않는다. OS 업데이트로 CLDR 데이터가 바뀌면 대량으로 깨진다. 성질(예: "숫자가 값 순서인가")을 검사한다.

꼬리 질문

// ❌ 매 비교마다 로케일 규칙을 적용한다
items.sorted { $0.name.localizedStandardCompare($1.name) == .orderedAscending }

// ✅ 키를 먼저 만들고 그 키로 정렬 (decorate-sort-undecorate)
let decorated = items.map { (key: $0.name.folding(
        options: [.caseInsensitive, .diacriticInsensitive], locale: .current), item: $0) }
let sorted = decorated
    .sorted { $0.key.localizedStandardCompare($1.key) == .orderedAscending }
    .map(\.item)

// ❌ 동률일 때 순서가 불안정하다
items.sorted { $0.priority > $1.priority }

// ✅ 동률을 깨는 안정적 기준을 붙인다
items.sorted {
    if $0.priority != $1.priority { return $0.priority > $1.priority }
    return $0.id < $1.id                      // 로케일 무관 · 유일한 값
}

Q3. 로케일 불변 매칭은 왜 따로 필요한가?

CS 원리

이 문제의 뿌리는 같은 연산 이름이 두 가지 다른 목적에 쓰인다는 것이다.

• 표시용 변환 — 사람에게 보여줄 텍스트를 그 문화의 관습대로 바꾼다. 로케일을 따라야 한다.
• 식별용 정규화 — 두 값이 같은 것을 가리키는지 판정하기 위해 형태를 통일한다. 어디서 돌려도 같은 결과가 나와야 한다.

두 번째를 로케일 불변(locale-invariant) 연산이라 부른다. 프로토콜·형식·저장소를 다루는 코드는 전부 여기 속한다. HTTP 헤더 이름, 파일 확장자, JSON 키, 열거형 원시값 — 이것들은 사용자의 문화와 무관한 기계 사이의 약속이다.

같은 원리가 숫자 파싱에도 적용된다. "1,234.5"는 영어권에서 천 단위 구분이지만 독일어권에서는 "1.234,5"다. 서버가 준 숫자 문자열을 로케일 인식 파서로 읽으면 기기 설정에 따라 값이 달라진다.

정리하면 경계마다 어느 쪽인지 정해야 한다 — 사람을 향하면 로케일, 기계를 향하면 불변.

iOS에서는

Swift 고유 API는 대체로 안전한 쪽 기본값을 갖는다. 위험은 NSString 계열과 섞일 때 온다.

import Foundation

let s = "ID"

// ✅ Swift 고유 — 로케일 파라미터가 없다. 항상 "id"
s.lowercased()

// ⚠️ NSString 계열 — 로케일을 명시하면 그 규칙을 따른다
(s as NSString).lowercased(with: Locale(identifier: "tr"))   // "ıd"
(s as NSString).lowercased(with: nil)                        // "id" (불변)

// 비교도 마찬가지다
"ID".caseInsensitiveCompare("id")                  // .orderedSame   (불변)
"ID".localizedCaseInsensitiveCompare("id")         // 로케일을 탄다

숫자 파싱에서도 같은 구분이 필요하다.

// ❌ 서버가 준 값을 로케일 인식으로 파싱 — 기기 설정에 좌우된다
let n1 = NumberFormatter().number(from: "1234.5")     // de_DE 에서 1234.5 가 아닐 수 있다

// ✅ 기계용 값은 로케일 무관 파싱
let n2 = Double("1234.5")                             // 항상 1234.5
let n3 = Decimal(string: "1234.5", locale: nil)       // 로케일 무관

// ✅ 사람에게 보여줄 때만 로케일을 적용
n2?.formatted(.number.locale(.current))

실무에서 이 버그가 숨는 자리를 정리하면 이렇다.

• HTTP 헤더 이름 비교 — "Content-Type".lowercased()로 정규화하는 코드.
• 파일 확장자 판정 — url.pathExtension.lowercased() == "jpeg".
• 딕셔너리 키 정규화 — 사용자 입력을 소문자화해 키로 쓰는 경우.
• 열거형 원시값 매칭 — 서버 문자열을 소문자화해 init(rawValue:)에 넘기는 경우.

실험 · 도구

터키어 로케일로 직접 확인하는 것이 가장 빠르다.

let samples = ["ID", "Istanbul", "IMAGE.JPEG"]
let tr = Locale(identifier: "tr_TR")

for s in samples {
    let swiftWay = s.lowercased()
    let nsWay    = (s as NSString).lowercased(with: tr)
    let same     = swiftWay == nsWay ? "동일" : "❌ 다름"
    print(String(format: "%-12@ swift=%-12@ tr=%-12@ %@",
                 s as NSString, swiftWay as NSString, nsWay as NSString, same as NSString))
}
// ID           swift=id           tr=ıd           ❌ 다름
// Istanbul     swift=istanbul     tr=ıstanbul     ❌ 다름
// IMAGE.JPEG   swift=image.jpeg   tr=ımage.jpeg   ❌ 다름

기기 전체를 터키어로 돌려 회귀를 훑을 수도 있다.

# 스킴 인자로 앱만 터키어로 실행
-AppleLanguages "(tr)" -AppleLocale "tr_TR"

# 코드베이스에서 위험한 호출을 찾는다
grep -rn "lowercased(with:\|uppercased(with:\|localizedCaseInsensitive" \
     --include=*.swift Sources/

# 로케일 인식 숫자 파싱이 기계용 값에 쓰이는지 확인
grep -rn "NumberFormatter()" --include=*.swift Sources/ | head -20

프로젝트 적용

1. 기계용 문자열 정규화에는 Swift 고유 API만 쓴다. lowercased()·==·caseInsensitiveCompare. 로케일 인자를 받는 것은 표시용에만.
2. 서버가 준 숫자·날짜 문자열은 로케일 무관으로 파싱한다. Double(_:), ISO 8601 파서, en_US_POSIX(Q7).
3. 가능하면 문자열 비교 자체를 없앤다. 열거형·UTType·전용 타입으로 바꾸면 이 문제군 전체가 사라진다.
4. 대소문자 정규화 지점을 한 곳으로 모은다. 곳곳에 흩어진 lowercased()는 나중에 감사(audit)가 불가능하다.
5. 터키어를 로케일 테스트 매트릭스에 반드시 넣는다. 이 계열 버그는 다른 어떤 로케일로도 재현되지 않는다.

꼬리 질문

extension String {
    /// 저장·중복 판정용 — 로케일 무관, 재현 가능
    var storageKey: String {
        precomposedStringWithCanonicalMapping        // NFC (27장 Q2)
            .lowercased()                            // Swift 고유 — 불변
            .trimmingCharacters(in: .whitespacesAndNewlines)
    }

    /// 검색 매칭용 — 사용자 관대함 우선
    func matchesSearch(_ q: String) -> Bool {
        range(of: q, options: [.caseInsensitive, .diacriticInsensitive,
                               .widthInsensitive], locale: .current) != nil
    }
}

// 최선 — 타입으로 만들면 정규화 위치가 한 곳으로 모인다
struct HeaderName: Hashable {
    let raw: String
    private let normalized: String
    init(_ raw: String) {
        self.raw = raw
        self.normalized = raw.lowercased()      // Swift 고유 — 불변
    }
    static func == (l: Self, r: Self) -> Bool { l.normalized == r.normalized }
    func hash(into h: inout Hasher) { h.combine(normalized) }
}

// 공유 테스트 벡터 — 서버·웹·앱이 같은 결과를 내야 한다
let vectors: [(input: String, expected: String)] = [
    ("  Hello  ", "hello"),
    ("İstanbul", "i̇stanbul"),          // 터키 대문자 I with dot
    ("가\u{0301}", "가\u{0301}"),        // 결합 문자 유지 여부
    ("ＡＢＣ", "abc"),                    // 전각 → 반각
]

Q4. 복수형 규칙은 왜 언어마다 다른가?

CS 원리

복수형 처리의 본질은 수 → 문법 형태로의 사상(mapping)이다. 순진한 구현은 n == 1 ? 단수 : 복수인데, 이건 영어의 규칙을 세계에 강요하는 것이다.

CLDR은 이 사상을 언어별 규칙 데이터로 분리했다. 각 언어는 "어떤 수가 어떤 카테고리에 속하는가"를 규칙으로 선언하고, 앱은 카테고리별 문자열만 제공한다.

여기서 두 가지 원리가 나온다.

• 카테고리는 수가 아니라 규칙이 정한다. "2면 two"가 아니다 — 언어가 two 카테고리를 쓰지 않으면 2도 other다. 그래서 앱이 직접 if n == 2로 분기하면 안 된다.
• 규칙은 정수만의 문제가 아니다. 소수(1.5개)와 유효 자릿수도 카테고리에 영향을 준다. CLDR 규칙은 이를 위해 i·v·f 같은 피연산자를 정의한다.

그리고 복수형이 풀지 못하는 축이 있다는 점이 중요하다. 한국어의 조사 선택은 수가 아니라 앞 글자의 받침 유무를 따른다 — 완전히 다른 차원이다. CLDR 복수 규칙을 아무리 정교하게 채워도 "사과를" / "책을"은 해결되지 않는다.

iOS에서는

String Catalog(.xcstrings)에서 Vary by Plural을 켜면 카테고리별 문자열을 채울 수 있다. 코드는 그냥 값을 넘긴다.

// 코드는 카테고리를 몰라도 된다 — 시스템이 로케일 규칙으로 고른다
let text = String(localized: "item_count",
                  defaultValue: "\(count) items")

// 카탈로그에서 count 에 대해 Vary by Plural 을 켜고
//   one   → "1 item"
//   other → "%lld items"
// 아랍어 번역에는 zero/one/two/few/many/other 여섯 칸이 생긴다

직접 분기하면 안 된다는 점이 핵심이다.

// ❌ 영어 규칙을 하드코딩한 것 — 다른 언어에서 전부 틀린다
let bad = count == 1 ? "1 item" : "\(count) items"

// ❌ 카테고리를 직접 판정하는 것도 틀린다 — 언어가 안 쓰는 카테고리가 있다
if count == 2 { … }        // 한국어·영어에는 two 카테고리가 없다

한국어 조사는 별도 로직이 필요하다. 받침 유무로 갈리므로 유니코드 한글 음절 블록의 산술로 판정할 수 있다.

extension String {
    /// 마지막 글자에 받침(종성)이 있는가
    var hasFinalConsonant: Bool? {
        guard let scalar = unicodeScalars.last?.value else { return nil }
        // 한글 음절 영역: U+AC00 ~ U+D7A3, 종성 인덱스 = (코드 - 0xAC00) % 28
        guard (0xAC00...0xD7A3).contains(scalar) else { return nil }   // 한글이 아니면 판정 불가
        return (scalar - 0xAC00) % 28 != 0
    }

    /// 조사를 붙인다 — 한글이 아니면 앞 형태를 기본으로 쓴다
    func withParticle(_ withJong: String, _ withoutJong: String) -> String {
        guard let has = hasFinalConsonant else { return self + withoutJong }
        return self + (has ? withJong : withoutJong)
    }
}

"사과".withParticle("을", "를")     // "사과를"   (받침 없음)
"책".withParticle("을", "를")       // "책을"     (받침 있음)
"iPhone".withParticle("을", "를")   // "iPhone를"  ← 한글이 아니라 판정 불가

마지막 줄이 이 접근의 한계다. 영문·숫자로 끝나면 발음 기준으로 판정해야 하는데, 이건 규칙이 아니라 발음 사전의 영역이다. 그래서 실무에서는 조사를 피하는 문장 설계가 더 안전하다 — "사과를 삭제했습니다" 대신 "삭제됨: 사과"처럼.

실험 · 도구

어떤 언어가 어떤 카테고리를 쓰는지 직접 확인할 수 있다.

import Foundation

// 특정 수가 로케일에서 어느 카테고리로 떨어지는지 본다
func category(_ n: Int, _ id: String) -> String {
    // 카탈로그 없이 확인하려면 각 카테고리 문자열을 만들어 비교하는 방식이 쓰인다.
    // 여기서는 시스템 포맷터로 결과 문자열만 관찰한다.
    let f = NumberFormatter()
    f.locale = Locale(identifier: id)
    return f.string(from: NSNumber(value: n)) ?? "-"
}

for id in ["ko_KR", "en_US", "ru_RU", "ar_SA"] {
    let row = [0, 1, 2, 11, 21].map { category($0, id) }.joined(separator: " | ")
    print(String(format: "%-8@ %@", id as NSString, row as NSString))
}
// ar_SA 에서는 숫자 자체가 아라비아 인도 숫자로 나온다 — 문자열 길이 가정이 깨진다

복수형 누락은 의사 언어로 훑는 것이 가장 빠르다.

# 아랍어로 실행 — 여섯 카테고리가 전부 필요한 언어라 누락이 바로 드러난다
-AppleLanguages "(ar)" -AppleLocale "ar_SA"

# 카탈로그에서 복수 variation 이 없는 항목 찾기
python3 - <<'PY'
import json, glob
for p in glob.glob("**/*.xcstrings", recursive=True):
    d = json.load(open(p))
    for key, v in d.get("strings", {}).items():
        for lang, loc in v.get("localizations", {}).items():
            if "variations" not in loc and any(c in key for c in ["count", "개", "item"]):
                print(f"{p}  {lang}  {key}   ← 복수 variation 없음")
PY

프로젝트 적용

1. 수가 들어가는 모든 문자열에 복수 variation을 켠다. 한국어만 지원해도 켜 둔다 — 나중에 언어를 추가할 때 문자열을 다시 훑지 않아도 된다.
2. n == 1 분기를 코드에서 없앤다. 이건 영어 규칙의 하드코딩이다.
3. 조사는 복수형과 별개로 처리한다. 가능하면 조사가 필요 없는 문장 구조로 바꾼다.
4. 아랍어를 테스트 매트릭스에 넣는다. 여섯 카테고리를 전부 쓰는 언어라 누락이 즉시 드러난다.
5. 숫자를 문자열로 조립하지 않는다. 아라비아 인도 숫자처럼 숫자 문자 자체가 다른 로케일이 있다. 서식은 시스템에 맡긴다.

꼬리 질문

// ❌ 순서를 하드코딩했다 — 아랍어·일본어에서 어순이 다르다
Text(bold(count)) + Text(" 개 항목이 선택됨")

var s = AttributedString(localized: "\(count) items selected")
// 마크다운으로 강조 범위를 번역자가 지정하게 하는 방법도 있다
//   "**\(count)** items selected"  → 번역자가 위치를 옮길 수 있다
if let r = s.range(of: count.formatted()) {
    s[r].font = .body.bold()
    s[r].foregroundColor = .accentColor
}

// 영문·숫자로 끝나는 경우의 기본값을 명시적으로 정한다
extension String {
    func 을를() -> String { withParticle("을", "를") }
    func 이가() -> String { withParticle("이", "가") }
    func 은는() -> String { withParticle("은", "는") }
}
//   "iPhone" 처럼 한글이 아닌 값은 발음 기준이라 규칙으로 못 푼다.
//   → 이런 값이 들어올 수 있으면 애초에 조사를 피하는 설계가 맞다.

Q5. String Catalog는 무엇을 보장하고 무엇은 못 하는가?

CS 원리

지역화 리소스 관리의 근본 문제는 코드와 데이터의 동기화다. 문자열 키는 코드에 있고 번역은 별도 파일에 있으므로, 둘이 어긋나면 런타임에야 발견된다 — 키가 그대로 화면에 찍히는 형태로.

이 문제를 다루는 접근이 셋 있다.

• 수동 관리 — 개발자가 키를 양쪽에 적는다. 어긋남이 필연적이다.
• 정적 추출 — 도구가 소스를 스캔해 키 목록을 만든다. String Catalog의 방식. 코드가 진실의 원천이 된다.
• 코드 생성 — 리소스에서 타입 안전한 심볼을 생성한다. 오타가 컴파일 단계에서 잡힌다.

정적 추출이 성립하려면 키가 컴파일 타임에 결정돼야 한다. 그래서 String(localized:)의 첫 인자가 StaticString인 것이다 — 런타임에 조립되는 키는 스캐너가 볼 수 없다. 이것은 제약이 아니라 정적 분석이 가능하기 위한 전제다.

동시에 이 방식의 한계도 분명하다. 도구가 검증할 수 있는 것은 구조(키 존재, 포맷 지정자 개수·타입, 복수 카테고리 누락)뿐이고, 의미(번역이 맞는가, 문맥에 적절한가, 잘리지 않는가)는 검증하지 못한다.

iOS에서는

기본 사용은 단순하다. 문자열을 String(localized:)로 감싸면 Xcode가 카탈로그에 자동 추가한다.

// 기본 — 키와 기본값이 같다
let title = String(localized: "Settings")

// 키와 표시값을 분리 (권장) — 나중에 문구가 바뀌어도 키가 유지된다
let msg = String(localized: "cart.empty.message",
                 defaultValue: "장바구니가 비어 있습니다",
                 comment: "장바구니 화면, 항목이 하나도 없을 때")

// SwiftUI 는 Text 가 자동으로 지역화한다
Text("Settings")                       // 자동 조회
Text(verbatim: "Settings")             // 조회하지 않음 (고정 문자열)

보간이 필요할 때가 함정이다. 첫 인자는 StaticString이라 값을 끼워 넣을 수 없다.

// ❌ 컴파일 에러 — 키에 보간을 넣을 수 없다
// String(localized: "greeting_\(userName)")

// ❌ 동작은 하지만 카탈로그가 무한히 늘어난다
// String(localized: "\(count)개 항목")      ← count 마다 새 엔트리

// ✅ 키는 고정하고 defaultValue 에서만 보간한다
let s = String(localized: "cart.item_count",
               defaultValue: "\(count)개 항목",
               comment: "장바구니 항목 수")

// ✅ 값을 나중에 채우려면 LocalizedStringResource
let res = LocalizedStringResource("cart.item_count",
                                  defaultValue: "\(count)개 항목")

포맷 지정자 검증이 이 포맷의 큰 이점이다. 번역에서 %@가 빠지거나 순서가 바뀌면 빌드 경고가 뜬다 — 예전에는 런타임 크래시로만 발견됐다.

// 번역자가 순서를 바꿔야 하는 언어를 위해 위치 지정자를 쓴다
//   "%1$@ 님이 %2$@ 를 공유했습니다"
//   아랍어 번역: "%2$@ تمت مشاركته بواسطة %1$@"
//   ← 순서가 바뀌어도 안전하다. %@ 만 쓰면 순서를 못 바꾼다

실험 · 도구

카탈로그는 JSON이므로 스크립트로 검사할 수 있다. CI에 넣으면 미번역 항목이 릴리스에 새어 나가는 것을 막는다.

# 미번역·검토 필요 항목을 세어 임계로 관리한다
python3 - <<'PY'
import json, glob, collections
stat = collections.Counter()
missing = []
for p in glob.glob("**/*.xcstrings", recursive=True):
    d = json.load(open(p))
    langs = set()
    for key, v in d.get("strings", {}).items():
        for lang, loc in v.get("localizations", {}).items():
            langs.add(lang)
            state = loc.get("stringUnit", {}).get("state", "?")
            stat[(lang, state)] += 1
            if state == "new":
                missing.append((lang, key))
for (lang, state), n in sorted(stat.items()):
    print(f"{lang:6} {state:12} {n}")
print(f"\n미번역 {len(missing)}건")
for lang, key in missing[:10]:
    print(f"  {lang}  {key}")
PY

의미 검증은 도구로 안 되므로 의사 언어로 화면을 훑는다.

# Xcode 스킴 › Run › Options › App Language
#   Double-Length Pseudolanguage   — 모든 문자열을 두 배로 늘려 레이아웃 넘침을 드러낸다
#   Right-to-Left Pseudolanguage   — RTL 레이아웃 문제를 번역 없이 확인
#   Accented Pseudolanguage        — 지역화되지 않은(하드코딩된) 문자열을 찾아낸다

# 명령줄에서도 지정할 수 있다
xcodebuild test -scheme App \
  -testLanguage ar -testRegion SA

Accented Pseudolanguage가 특히 유용하다 — 지역화를 거친 문자열만 악센트가 붙으므로, 악센트 없이 나오는 문자열이 곧 하드코딩된 문자열이다.

프로젝트 적용

1. 키와 표시 문구를 분리한다. 키를 cart.empty.message처럼 두면 문구를 바꿔도 번역이 유지된다. 영어 문장을 키로 쓰면 문구 수정이 곧 번역 초기화다.
2. comment를 반드시 채운다. 번역자는 코드를 보지 않는다. "Save"가 동사인지 명사인지, 버튼인지 제목인지 모른다.
3. 위치 지정자(%1$@)를 기본으로 쓴다. 인자가 둘 이상이면 순서를 바꿔야 하는 언어가 반드시 있다.
4. 미번역 항목 수를 CI 지표로 관리한다. 릴리스 전 임계를 넘으면 실패시킨다 — P1 21장 Q6의 "조용한 실패를 빌드 실패로"와 같은 구조다.
5. Accented Pseudolanguage로 하드코딩 문자열을 정기적으로 훑는다. 새로 추가된 화면에서 가장 잘 빠진다.

꼬리 질문

enum L10n {
    nonisolated(unsafe) static var remote: [String: String] = [:]

    static func t(_ key: String.LocalizationValue, fallback: String) -> String {
        // 원격 우선, 없으면 번들 카탈로그
        if let s = remote[String(describing: key)] { return s }
        return String(localized: key, defaultValue: "\(fallback)")
    }
}

// ❌ 도움이 안 되는 주석
String(localized: "save", defaultValue: "저장", comment: "저장 버튼")

// ✅ 번역자가 판단할 수 있는 주석
String(localized: "editor.save.button",
       defaultValue: "저장",
       comment: "문서 편집 화면 하단 버튼(동사). 최대 6자 권장. 옆에 '취소' 버튼이 나란히 놓임")

String(localized: "share.by_user",
       defaultValue: "\(name) 님이 공유했습니다",
       comment: "알림 목록 한 줄. %1$@ 는 사용자 표시 이름(한글·영문·이모지 가능)")

# SwiftLint 커스텀 규칙 예 — Text/Label 에 리터럴을 직접 넣는 것을 잡는다
custom_rules:
  hardcoded_ui_string:
    name: "지역화되지 않은 UI 문자열"
    regex: 'Text\(\s*"[^"]*[가-힣A-Za-z]{2,}'
    match_kinds: [identifier, string]
    message: "Text(...) 에 리터럴 대신 String(localized:) 또는 LocalizedStringKey 를 쓰세요"
    severity: warning

Q6. FormatStyle은 DateFormatter와 무엇이 다른가?

CS 원리

이 차이는 문자열 기반 설정 vs 타입 기반 설정이라는 오래된 대비의 한 사례다.

문자열 설정은 유연하다 — 어떤 조합이든 표현할 수 있다. 대신 검증이 런타임으로 미뤄진다. 컴파일러는 "yyyy-MM-dd"가 올바른 패턴인지 알 수 없고, "YYYY"(ISO 주 기준 연도)와 "yyyy"(달력 연도)의 차이는 연말 며칠 동안만 드러난다. 12월 31일이 다음 해 첫 주에 속하면 YYYY가 내년을 출력한다.

타입 기반 설정은 표현력을 조금 포기하는 대신 잘못된 상태를 표현 불가능하게 만든다. 필드가 문자가 아니라 열거형 케이스이므로, 존재하지 않는 필드를 쓸 방법이 없다.

두 번째 축은 값 타입 vs 참조 타입이다.

세 번째로 왕복(round-trip) 대칭이 중요하다. DateFormatter의 string(from:)과 date(from:)이 서로 역함수인지는 개발자가 같은 dateFormat을 썼는지에만 달려 있다. FormatStyle은 같은 스타일 값을 ParseStrategy로 재사용하므로 이 대칭이 타입 시스템에 담긴다.

iOS에서는

같은 계열 설계가 날짜뿐 아니라 숫자·통화·기간·측정값에 일관되게 적용된다.

let d = Date()

// 날짜 — 필드를 골라 조립한다
d.formatted(.dateTime.year().month().day())          // 2026. 8. 15.
d.formatted(.dateTime.hour().minute())               // 오후 2:30
d.formatted(.dateTime.weekday(.wide))                // 토요일
d.formatted(.relative(presentation: .named))         // 어제 · 3분 전

// 숫자·통화·퍼센트
1234.5.formatted(.number.precision(.fractionLength(1)))     // 1,234.5
1234.5.formatted(.currency(code: "KRW"))                    // ₩1,235
0.756.formatted(.percent.precision(.fractionLength(1)))     // 75.6%

// 기간·측정값
Duration.seconds(3725).formatted(.time(pattern: .hourMinuteSecond))   // 1:02:05
Measurement(value: 5, unit: UnitLength.kilometers).formatted()        // 5km

파싱 대칭이 실무에서 특히 유용하다. 같은 스타일 값으로 출력하고 다시 읽는다.

let style = Date.ISO8601FormatStyle()

let text = d.formatted(style)                 // "2026-08-15T14:30:00Z"
let back = try Date(text, strategy: style)    // 같은 스타일로 되읽는다
//   DateFormatter 였다면 dateFormat 을 양쪽에 똑같이 적었는지에 달려 있다

스레드 안전성도 달라진다. DateFormatter는 가변 참조 타입이라 여러 스레드가 공유하며 설정을 바꾸면 위험한데, 생성 비용 때문에 공유하고 싶은 유인이 생기는 것이 문제였다.

// ❌ 흔한 패턴 — 캐싱하려다 공유 가변 상태가 된다
final class Legacy {
    static let shared = DateFormatter()        // 여러 스레드가 dateFormat 을 바꾸면 위험
}

// ✅ FormatStyle 은 값 타입이라 그냥 만들어 쓴다
let s = d.formatted(.dateTime.year().month())

성능도 개선됐다. swift-foundation 재작성에서 FormatStyle 기반 날짜 포매팅이 150% 개선(약 2.5배)됐다고 공식 벤치마크가 밝히고 있다. 다만 이는 특정 표준 벤치마크 맥락의 수치라 모든 로케일·필드 조합에 일반화하면 안 된다.

실험 · 도구

YYYY/yyyy 차이를 직접 재현해 보면 왜 타입 기반이 나은지 분명해진다.

import Foundation

var cal = Calendar(identifier: .gregorian)
cal.timeZone = TimeZone(identifier: "Asia/Seoul")!

let wrong = DateFormatter(); wrong.dateFormat = "YYYY-MM-dd"   // ISO 주 기준 연도
let right = DateFormatter(); right.dateFormat = "yyyy-MM-dd"   // 달력 연도
for f in [wrong, right] { f.locale = Locale(identifier: "en_US_POSIX"); f.timeZone = cal.timeZone }

for day in [1, 15, 29, 30, 31] {
    let date = cal.date(from: DateComponents(year: 2026, month: 12, day: day))!
    print("12/\(day):  YYYY→\(wrong.string(from: date))   yyyy→\(right.string(from: date))")
}
// 12/1:   YYYY→2026-12-01   yyyy→2026-12-01
// 12/31:  YYYY→2027-12-31   yyyy→2026-12-31    ← 연도가 다르다
//   해당 날짜가 다음 해 첫 주에 속하면 YYYY 가 내년을 낸다.
//   1년 중 며칠만 틀리므로 테스트를 통과하고 릴리스된다.

기존 코드에서 위험한 패턴을 훑는다.

# 대문자 YYYY 를 쓰는 곳 — 의도적으로 ISO 주 연도를 원한 게 아니면 버그다
grep -rn 'dateFormat.*YYYY' --include=*.swift . | grep -v 'yyyy'

# DateFormatter 를 정적 프로퍼티로 공유하는 곳
grep -rn 'static.*DateFormatter\|static.*NumberFormatter' --include=*.swift .

# 로케일을 지정하지 않은 고정 포맷 (Q7 에서 다룬다)
grep -rn -A3 'dateFormat = ' --include=*.swift . | grep -B1 -v 'locale'

프로젝트 적용

1. 새 코드는 FormatStyle을 기본으로 쓴다. 오타가 컴파일 단계에서 잡히고 스레드 문제가 사라진다.
2. 기존 DateFormatter는 YYYY 검색부터 한다. 이 하나만 잡아도 연말 장애를 막는다.
3. 정적 포매터 캐싱을 걷어낸다. 값 타입으로 옮기면 캐싱 자체가 불필요하다.
4. 출력과 파싱에 같은 스타일 값을 쓴다. 왕복 대칭을 타입에 맡긴다.
5. Measurement.formatted()의 기본 반올림에 주의한다. 기본값은 "정확한 값 보존"보다 "보기 좋은 반올림"을 우선하므로, 정밀도가 필요하면 numberFormatStyle을 명시한다.

꼬리 질문

// 이전 전후 대조 — 실제 값이 같은지 확인한다
let old = legacyFormatter.string(from: date)
let new = date.formatted(.dateTime.year().month().day())
assert(old == new, "출력이 달라졌다: \(old) vs \(new)")

// 필드만 요청하고 배치는 로케일에 맡긴다
let f = DateFormatter()
f.setLocalizedDateFormatFromTemplate("yMMMd")
//   en_US → "Aug 15, 2026"      ko_KR → "2026년 8월 15일"
//   순서·구분자·12/24시간을 로케일이 정한다

struct ShortRelative: FormatStyle {
    func format(_ value: Date) -> String {
        let s = Int(Date.now.timeIntervalSince(value))
        switch s {
        case ..<60:     return "방금"
        case ..<3600:   return "\(s / 60)분"
        default:        return value.formatted(.dateTime.month().day())
        }
    }
}
Date().formatted(ShortRelative())

// 모델은 Date 로만 다룬다 — 문자열을 모델에 담지 않는다
struct Order: Codable {
    let id: String
    let placedAt: Date          // 디코딩 시 ISO 8601 로 파싱
}

// 디코딩·인코딩은 한 곳에서 고정한다
let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601      // 기계용 — 로케일 무관

// 표시는 뷰 계층에서만, 로케일을 따른다
Text(order.placedAt.formatted(.dateTime.year().month().day()))

Q7. en_US_POSIX는 언제 쓰고 언제 쓰면 안 되는가?

CS 원리

이것은 내부 표현과 외부 표현의 분리라는 일반 원칙의 사례다.

시스템은 두 종류의 텍스트를 다룬다.

• 기계 사이의 약속 — 파싱될 것을 전제로 한 형식. 재현 가능해야 하고, 어느 기기에서 만들어도 같아야 한다. 사람이 읽기 편할 필요는 없다.
• 사람을 위한 표현 — 읽기 쉬워야 하고, 그 문화의 관습을 따라야 한다. 재현 가능성은 필요 없다.

두 요구는 정면으로 충돌한다. 재현 가능하려면 고정돼야 하고, 문화를 따르려면 변해야 한다. 그래서 한 형식으로 둘 다 만족시킬 수 없고, 반드시 갈라야 한다.

en_US_POSIX는 첫 번째를 위한 고정점이다. 이름에 en_US가 들어가지만 미국 사용자를 위한 것이 아니라, POSIX/C 표준을 흉내 낸 불변 기준선이다. 실제 미국 로케일(en_US)의 관습이 바뀌어도 이것은 바뀌지 않는다.

여기서 자주 오해되는 지점이 하나 있다. 고정 포맷에서 AM/PM이 섞이는 진짜 원인은 "12시간제가 흔한 나라의 로케일을 골라서"가 아니다. 실측하면 en_US·ko_KR·en_GB 어느 것이든 명시적으로 지정하기만 하면 HH:mm:ss가 24시간제로 지켜진다. 문제가 되는 것은 로케일을 아예 지정하지 않아 기기의 시간 표기 선호(hourCycle)에 위임되는 경우뿐이다.

iOS에서는

고정 포맷에는 로케일·시간대·달력 셋 다 고정하는 것이 안전하다.

// ✅ 기계용 — 세 축을 모두 고정한다
let wire = DateFormatter()
wire.locale = Locale(identifier: "en_US_POSIX")     // 표기 규칙 고정
wire.timeZone = TimeZone(secondsFromGMT: 0)         // UTC 고정
wire.calendar = Calendar(identifier: .gregorian)    // 불교력 등 방지
wire.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZ"

// ✅ 더 나은 방법 — ISO 8601 전용 타입을 쓴다
let iso = ISO8601DateFormatter()
let s = iso.string(from: Date())
// 또는 FormatStyle
let s2 = Date().formatted(.iso8601)

표시용은 정반대다. 형식을 고정하지 않고 필드만 요청한다.

// ❌ 표시용에 고정 포맷 — 모든 사용자에게 미국식을 강요한다
let bad = DateFormatter()
bad.locale = Locale(identifier: "en_US_POSIX")
bad.dateFormat = "MM/dd/yyyy"

// ✅ 필드만 요청하고 배치는 로케일에 맡긴다
let good = DateFormatter()
good.setLocalizedDateFormatFromTemplate("yMMMd")
//   ko_KR → 2026년 8월 15일    en_US → Aug 15, 2026    de_DE → 15. Aug. 2026

// ✅ FormatStyle 이면 더 간단하다
Date().formatted(.dateTime.year().month().day())

불교력 함정도 여기서 나온다. 태국 사용자의 기본 달력은 불교력이라 연도가 543년 차이 난다. 고정 포맷에 달력을 지정하지 않으면 서버로 2569가 나갈 수 있다.

실험 · 도구

로케일 지정 여부가 실제로 무엇을 가르는지 확인해 보자.

import Foundation

let date = Calendar(identifier: .gregorian)
    .date(from: DateComponents(year: 2026, month: 8, day: 15, hour: 14, minute: 30))!

func check(_ label: String, _ configure: (DateFormatter) -> Void) {
    let f = DateFormatter(); f.dateFormat = "HH:mm:ss"; configure(f)
    print(String(format: "%-16@ %@", label as NSString, f.string(from: date) as NSString))
}

check("지정 안 함")     { _ in }                                         // 기기 설정에 위임
check("en_US")        { $0.locale = Locale(identifier: "en_US") }
check("ko_KR")        { $0.locale = Locale(identifier: "ko_KR") }
check("en_US_POSIX")  { $0.locale = Locale(identifier: "en_US_POSIX") }
// 기기를 12시간제로 설정하면 "지정 안 함"만 2:30:00 PM 이 되고
// 나머지 셋은 전부 14:30:00 을 유지한다

불교력 영향도 재현된다.

# 태국 로케일로 실행해 연도가 543 차이 나는지 확인
-AppleLanguages "(th)" -AppleLocale "th_TH"

# 코드베이스에서 달력·시간대를 고정하지 않은 고정 포맷 찾기
grep -rn -B2 -A4 "dateFormat = " --include=*.swift . \
  | grep -L "calendar\|timeZone" | head -20

프로젝트 적용

1. 고정 포맷에는 로케일·시간대·달력 셋을 모두 지정한다. 하나라도 빠지면 기기 설정이 새어 든다.
2. 가능하면 ISO8601DateFormatter나 .iso8601 스타일을 쓴다. 직접 패턴을 적을 일이 없어진다.
3. 표시용에는 절대 en_US_POSIX를 쓰지 않는다. 템플릿 API나 FormatStyle로 필드만 요청한다.
4. 로그·파일명에도 고정 형식을 쓴다. 로그 타임스탬프가 기기 로케일을 타면 파싱·정렬이 깨진다(P1 18장).
5. 태국·아랍 로케일로 회귀 테스트한다. 달력·숫자 문자가 다른 대표 사례다.

꼬리 질문

// 소수 초가 섞여 오는 경우 — 두 파서를 준비해 폴백한다
let withFraction = ISO8601DateFormatter()
withFraction.formatOptions = [.withInternetDateTime, .withFractionalSeconds]

let plain = ISO8601DateFormatter()
plain.formatOptions = [.withInternetDateTime]

func parseISO(_ s: String) -> Date? {
    withFraction.date(from: s) ?? plain.date(from: s)
}

// 저장은 UTC · 고정 형식
let logTime = ISO8601DateFormatter()
logTime.timeZone = TimeZone(secondsFromGMT: 0)
logTime.formatOptions = [.withInternetDateTime, .withFractionalSeconds]

// 표시는 사용자 시간대
Text(entry.timestamp.formatted(.dateTime.hour().minute().second()))

// ❌ 포매터를 정적으로 캐시 — 생성 시점의 로케일에 묶인다
enum Fmt {
    static let display: DateFormatter = {
        let f = DateFormatter()
        f.dateStyle = .long          // 이때의 Locale.current 가 굳어진다
        return f
    }()
}

// ✅ 값 타입이라 캐시할 이유가 없다
Date().formatted(.dateTime.year().month().day())

// ✅ 굳이 캐시한다면 로케일 변경 알림에서 무효화한다
NotificationCenter.default.addObserver(
    forName: NSLocale.currentLocaleDidChangeNotification, object: nil, queue: .main
) { _ in Fmt.invalidate() }

출처 · 참고자료