27 · 문자열과 유니코드

P2의 첫 챕터다. P1이 사용자 기기에서 도는 앱을 관측·판독하는 법이었다면, P2는 크래시 없이 조용히 틀리는 것들과 언어·런타임이 보장하는 것의 경계를 다룬다.

문자열이 그 첫 자리인 이유는 단순하다. 문자열은 모든 앱이 쓰는데 아무도 그 내부 표현을 생각하지 않는 타입이고, 그래서 버그가 테스트를 통과한 뒤 특정 사용자에게서만 터진다. 이모지를 쓰는 사용자, 한글 파일명을 올리는 사용자, 이름에 결합 문자가 들어가는 사용자에게서만.

이 챕터의 모든 문항은 "겉보기와 실제가 어긋나는 지점"을 다룬다. 길이가 하나가 아니고, 같아 보이는 문자열의 바이트가 다르고, 인덱스가 정수가 아니고, 가벼워 보이는 슬라이스가 480MB를 붙잡는다.

Q1. 문자열의 "길이"는 왜 하나가 아닌가?

CS 원리

이 계층 구조는 유니코드가 두 가지 요구를 동시에 만족시키려다 생긴 것이다. 하나는 "세상의 모든 문자를 표현한다", 다른 하나는 "기존 바이트 기반 시스템과 호환된다".

• 코드포인트(스칼라) — 유니코드가 문자에 붙인 번호다. U+0041(A), U+AC00(가). 약 110만 개의 자리가 있다.
• 인코딩(UTF-8 / UTF-16) — 그 번호를 실제 바이트로 적는 방식이다. UTF-8은 1~4바이트 가변, UTF-16은 2 또는 4바이트. 같은 코드포인트라도 인코딩마다 길이가 다르다.
• 그래프임 클러스터 — 여러 코드포인트가 결합해 사람이 한 글자로 인식하는 단위다. 유니코드 부속 문서 UAX #29가 경계 규칙을 정의한다.

맨 위 계층이 필요한 이유는 결합 문자 때문이다. 한 글자가 여러 코드포인트로 만들어질 수 있다 — 기본 문자 + 발음 구별 기호, 이모지 + 스킨톤 수정자, 여러 이모지 + ZWJ(zero-width joiner). 사용자에게 "글자 하나"인 것을 프로그램도 하나로 세려면 이 결합 규칙을 알아야 한다.

여기서 비용이 나온다. 결합 규칙은 본질적으로 순차적이다 — 앞의 스칼라를 보지 않고는 다음 경계가 어디인지 알 수 없다. 그래서 그래프임 개수는 처음부터 훑어야만 알 수 있고 O(n)이다. 반면 바이트 수는 버퍼 길이라 O(1)이다.

iOS에서는

Swift의 Character는 확장 그래프임 클러스터다. 이 선택이 Swift 문자열 API 전체의 성격을 결정한다.

let family = "👨‍👩‍👧‍👦"

family.count                 // 1   ← Character(확장 그래프임 클러스터)
family.unicodeScalars.count  // 7   ← Man, ZWJ, Woman, ZWJ, Girl, ZWJ, Boy
family.utf16.count           // 11  ← 서로게이트 쌍 4쌍 + ZWJ 3개
family.utf8.count            // 25  ← 실제 바이트 수

// 국기와 스킨톤도 같은 패턴이다 — 스칼라 여러 개가 Character 하나로 묶인다
"🇰🇷".count                   // 1 (regional indicator 스칼라 2개)
"👍🏽".count                   // 1 (thumbs up + 스킨톤 수정자)

복잡도 차이가 실무에 그대로 드러난다. count는 캐시되지 않는다 — 값 안에 캐시되는 것은 _countAndFlagsBits에 담긴 UTF-8 바이트 수뿐이다. 같은 문자열에서 .count를 세 번 불러도 매번 같은 시간이 걸린다.

// ❌ 루프 조건에서 count를 반복 호출 — 매번 O(n)
for i in 0..<text.count { … }          // 전체가 O(n²)가 된다

// ✅ 한 번만 세거나, 애초에 인덱스로 순회한다
let n = text.count
for ch in text { … }                    // 순회 자체는 O(n)

// ✅ 비어 있는지 확인은 count를 쓰지 않는다
if text.isEmpty { … }                   // O(1)
if text.count == 0 { … }                // ❌ O(n)

실험 · 도구

네 계층이 실제로 다르게 세어지는 것을 직접 확인해 보자.

import Foundation

func inspect(_ s: String, _ label: String) {
    print(String(format: "%-14@ count=%2d scalars=%2d utf16=%2d utf8=%2d",
                 label as NSString, s.count, s.unicodeScalars.count,
                 s.utf16.count, s.utf8.count))
}

inspect("A",        "ASCII")        // count= 1 scalars= 1 utf16= 1 utf8= 1
inspect("가",       "한글 완성형")   // count= 1 scalars= 1 utf16= 1 utf8= 3
inspect("👍",       "이모지")        // count= 1 scalars= 1 utf16= 2 utf8= 4
inspect("👍🏽",      "스킨톤")        // count= 1 scalars= 2 utf16= 4 utf8= 8
inspect("🇰🇷",       "국기")          // count= 1 scalars= 2 utf16= 4 utf8= 8
inspect("👨‍👩‍👧‍👦", "가족")          // count= 1 scalars= 7 utf16=11 utf8=25

복잡도 차이도 재 볼 수 있다. 긴 문자열에서 두 값을 반복 계산해 비교한다.

let long = String(repeating: "가나다👨‍👩‍👧‍👦", count: 20_000)

var clock = ContinuousClock()
let t1 = clock.measure { for _ in 0..<3 { _ = long.count } }
let t2 = clock.measure { for _ in 0..<3 { _ = long.utf8.count } }
print("count      \(t1)")     // 밀리초 단위 — 3회 모두 같은 비용
print("utf8.count \(t2)")     // 사실상 0 — 캐시된 값 읽기

프로젝트 적용

1. "길이"를 요구하는 명세를 만나면 계층부터 확인한다. 서버가 "닉네임 20자 이하"라고 할 때 그 20이 바이트인지 글자인지를 정하지 않으면 클라이언트와 서버의 판정이 갈린다.
2. 바이트 제한 검사에는 utf8.count를 쓴다. 이모지 20개는 count로 20이지만 실제로는 500바이트일 수 있다. DB 컬럼이 VARCHAR(255)라면 바이트 기준이다.
3. 사용자에게 보여줄 "남은 글자 수"에는 count를 쓴다. 사용자는 그래프임을 센다.
4. 뜨거운 경로에서 count를 반복 호출하지 않는다. 특히 루프 조건과 count == 0 비교.
5. 자르기(truncate)는 그래프임 단위로 한다. 바이트나 스칼라 단위로 자르면 이모지가 깨진다.

꼬리 질문

extension String {
    /// UTF-8 기준 maxBytes 이하가 되도록 자르되, Character 경계를 지킨다
    func truncatedToUTF8Bytes(_ maxBytes: Int) -> String {
        var out = ""
        var used = 0
        for ch in self {
            let n = String(ch).utf8.count
            if used + n > maxBytes { break }
            out.append(ch)
            used += n
        }
        return out
    }
}

"안녕하세요👨‍👩‍👧‍👦".truncatedToUTF8Bytes(20)   // "안녕하세요" (15바이트)
//   가족 이모지는 25바이트라 통째로 빠진다 — 조각으로 깨지지 않는다

// ❌ 스칼라 단위 — 이모지가 조각난다
text.unicodeScalars.removeLast()

// ✅ Character 단위 — 보이는 글자 하나가 사라진다
text.removeLast()

// 커서 이동도 마찬가지
let next = text.index(after: cursor)      // ✅ 그래프임 경계로 이동
let prev = text.index(before: cursor)

Q2. 겉보기에 같은 문자열이 왜 바이트가 다른가?

CS 원리

정준 등가는 유니코드가 기존 문자 집합과의 왕복 변환을 보장하려다 생긴 부채다. 라틴-1 같은 기존 인코딩에 이미 é가 한 글자로 들어 있었으므로 유니코드도 그 자리를 만들어야 했고, 동시에 결합 문자로 임의의 조합을 만드는 일반 메커니즘도 필요했다. 결과적으로 같은 것에 두 개의 표현이 생겼다.

이를 다루기 위해 유니코드는 정규화 형식을 정의한다(UAX #15).

여기서 원리 하나가 나온다 — 동등성 판정은 계층마다 다르다. 바이트 동등, 코드포인트 동등, 정준 동등, 호환 동등, 대소문자 무시 동등, 로케일 인식 동등이 전부 다른 관계다. 어느 동등성을 쓸지 정하지 않으면 시스템 경계에서 어긋난다.

iOS에서는

Swift의 ==는 정준 동등성 비교이고, 이 판단은 Hashable 계약에 따라 hashValue에도 적용된다. 조합형으로 Set에 넣고 분해형으로 조회해도 찾아진다.

let composed   = "\u{AC00}"                 // 가  (NFC)
let decomposed = "\u{1100}\u{1161}"         // ᄀ+ᅡ (NFD)

composed == decomposed          // true  ← 정준 등가
composed.count                  // 1
decomposed.count                // 1      ← 둘 다 Character 1개

composed.utf8.count             // 3
decomposed.utf8.count           // 6      ← 바이트는 두 배

var set: Set<String> = [composed]
set.contains(decomposed)        // true   ← hashValue도 정준 등가를 따른다

// 바이트 그대로 비교하려면 명시해야 한다
composed.compare(decomposed, options: .literal) == .orderedSame   // false

문제가 드러나는 자리는 Swift의 ==를 거치지 않는 경로다.

• 해시·서명 — 파일명이나 문자열을 SHA로 해싱해 무결성을 검증하면 NFC/NFD가 다른 해시를 낸다.
• DB 기본 키·유니크 제약 — 데이터베이스의 대조(collation) 규칙에 따라 다르게 판정된다.
• 파일 시스템 — macOS는 파일명을 NFD로 정규화해 저장하는 경향이 있어, 서버가 준 NFC 이름으로 파일을 찾으면 없다고 나올 수 있다.
• URL 경로 — 퍼센트 인코딩되는 바이트가 달라진다(Q6).

대응은 경계에서 한 형식으로 고정하는 것이다.

import Foundation

extension String {
    /// 네트워크·저장 경계에서 NFC로 통일한다
    var nfc: String { precomposedStringWithCanonicalMapping }
    /// 파일 시스템과 대조할 때 NFD가 필요하면
    var nfd: String { decomposedStringWithCanonicalMapping }
}

// 업로드 직전 파일명을 NFC로 고정
let safeName = localFileName.nfc
// 서버가 준 이름으로 로컬 파일을 찾을 때도 같은 형식으로 맞춘다
let match = contents.first { $0.nfc == serverName.nfc }

실험 · 도구

정규화 차이는 눈으로 안 보이므로 바이트를 직접 찍어봐야 한다.

func dump(_ s: String, _ label: String) {
    let bytes = s.utf8.map { String(format: "%02X", $0) }.joined(separator: " ")
    let scalars = s.unicodeScalars.map { String(format: "U+%04X", $0.value) }.joined(separator: " ")
    print("\(label): count=\(s.count) utf8=\(s.utf8.count)\n   scalars: \(scalars)\n   bytes:   \(bytes)")
}

dump("가".precomposedStringWithCanonicalMapping, "NFC")
//   count=1 utf8=3  scalars: U+AC00   bytes: EA B0 80
dump("가".decomposedStringWithCanonicalMapping, "NFD")
//   count=1 utf8=6  scalars: U+1100 U+1161   bytes: E1 84 80 E1 85 A1

파일 시스템이 실제로 어떻게 저장하는지도 확인할 수 있다.

# 한글 이름 파일을 만들고 실제 저장된 바이트를 본다
cd "$(mktemp -d)"
touch "가.txt"
ls | xxd | head -2
#   APFS 는 NFD 로 정규화해 저장하는 경우가 많다 →
#   E1 84 80 E1 85 A1 (6바이트) 로 보이면 NFD,
#   EA B0 80 (3바이트) 면 NFC 다.

# 서버에서 받은 이름(NFC)으로 찾으면 못 찾는 상황을 재현
python3 -c "import unicodedata,os; \
print(os.listdir('.')[0] == unicodedata.normalize('NFC','가.txt'))"
#   False 가 나오면 정규화 불일치다

프로젝트 적용

1. 경계에서 정규화 형식을 고정한다. 네트워크로 나가고 들어오는 문자열, 저장소에 쓰는 키는 NFC로 통일하는 것이 무난하다. 웹과 대부분의 서버가 NFC를 기대한다.
2. 해시·서명·중복 판정 전에는 반드시 정규화한다. 정규화하지 않은 해시는 같은 파일이 다른 해시를 갖게 만든다.
3. 파일 시스템과 대조할 때는 양쪽을 같은 형식으로 맞춘다. 저장된 이름을 그대로 믿지 않는다.
4. 사용자 입력을 그대로 키로 쓰지 않는다. 닉네임 중복 검사, 태그 비교 등은 정규화 후 비교한다.
5. NFKC는 신중하게 쓴다. 검색 색인에는 유용하지만 ①과 1을 같게 만드는 등 의미를 바꾼다. 표시용 원본은 따로 보관한다.

꼬리 질문

extension String {
    /// 중복 판정·검색용 정규 형태 — 표시용 원본과 별도로 보관한다
    var canonicalKey: String {
        precomposedStringWithCanonicalMapping
            .trimmingCharacters(in: .whitespacesAndNewlines)
            .lowercased()
            .filter { !$0.unicodeScalars.contains { s in
                s.properties.isDefaultIgnorableCodePoint      // 제로폭 등
            } }
    }
}

Q3. String.Index는 왜 정수가 아니며 언제 무효화되는가?

CS 원리

가변 길이 인코딩에서 "n번째 위치"는 정의되지 않은 개념이다. 무엇의 n번째인지를 말해야 의미가 생긴다.

고정 길이 배열이라면 base + n × size로 위치를 계산할 수 있다. 그런데 UTF-8은 문자마다 1~4바이트라, "5번째 글자"의 바이트 오프셋은 앞의 네 글자를 실제로 읽어봐야 안다. 이것이 문자열 인덱스가 정수일 수 없는 근본 이유다.

설계 선택지는 둘이었다.

• 뷰마다 다른 인덱스 타입 — 타입 안전하지만 뷰를 옮길 때마다 변환 코드가 폭증한다.
• 하나의 불투명 인덱스를 공유 — Swift의 선택. 인덱스는 "이 문자열의 이 지점"이라는 불투명한 표식이고, 뷰는 그것을 각자 해석한다.

두 번째 선택의 대가가 수명 문제다. 인덱스가 버퍼 안의 위치를 담고 있으므로, 버퍼가 바뀌면 그 표식의 의미도 바뀐다. 이는 C++ 이터레이터 무효화나 데이터베이스 커서 무효화와 정확히 같은 구조의 문제다 — 컨테이너를 수정하면 그 안을 가리키던 참조가 못 쓰게 된다.

iOS에서는

정수 산술이 정의돼 있지 않아 컴파일 단계에서 막힌다. 이동은 전용 메서드로만 한다.

let s = "가👍🏽나"

// ❌ 컴파일 에러 — String.Index 에는 + 가 없다
// let bad = s.startIndex + 1

// ✅ 이동은 index(after:) / index(_:offsetBy:)
let i1 = s.index(after: s.startIndex)
let i2 = s.index(s.startIndex, offsetBy: 2)
s[i2]                                  // "나"

// 뷰 간 변환은 실패 가능하다 — 경계가 맞지 않으면 nil
let u8 = s.utf8.index(s.utf8.startIndex, offsetBy: 3)
let asChar = u8.samePosition(in: s)    // Optional<String.Index>

무효화 규칙은 "인덱스가 가리키던 위치보다 앞쪽이 바뀌었는가"로 갈린다.

var text = "abcdef"
let idx = text.index(text.startIndex, offsetBy: 5)   // "f" 위치

// (1) 뒤에만 덧붙이면 — 앞쪽이 그대로라 인덱스가 살아 있다
text.append("gh")
text[idx]                    // "f"  ← 유효

// (2) 앞쪽을 건드리면 — 의미가 달라진다
text.insert("Z", at: text.startIndex)
text[idx]                    // "e"  ← 조용히 밀렸다. 트랩도 안 난다

// (3) 재할당으로 범위를 넘으면 — 트랩
text = "ab"
// text[idx]                 // Fatal error: String index is out of bounds

// (4) 다른 문자열에 재사용 — 범위 안이면 트랩 없이 틀린 값
let other = "ZYXWVUT"
other[idx]                   // "U"  ← 의미 없는 결과

(2)와 (4)가 위험하다. 크래시가 나지 않아 잘못된 값이 그대로 흘러간다.

실험 · 도구

무효화 네 가지 경우를 직접 재현해 보면 규칙이 몸에 남는다.

func probe(_ label: String, _ body: () -> String?) {
    print("\(label): \(body().map { "\"\($0)\"" } ?? "nil")")
}

var t = "abcdef"
let idx = t.index(t.startIndex, offsetBy: 5)

t.append("gh");                probe("append 후",  { String(t[idx]) })   // "f"
t.insert("Z", at: t.startIndex); probe("앞에 삽입", { String(t[idx]) })  // "e" ← 밀림
t = "ab"
//   여기서 t[idx] 를 부르면 트랩 — 방어하려면 범위를 먼저 확인한다
probe("재할당 후", { idx < t.endIndex ? String(t[idx]) : nil })          // nil

안전하게 쓰려면 인덱스를 오래 보관하지 않는 것이 원칙이고, 보관해야 한다면 오프셋으로 바꿔 둔다.

// 인덱스 대신 "시작에서 몇 번째"를 보관하면 재계산할 수 있다
let offset = s.distance(from: s.startIndex, to: i2)   // Int
// 나중에 복원
let restored = s.index(s.startIndex, offsetBy: offset)

프로젝트 적용

1. 인덱스를 프로퍼티나 컬렉션에 저장하지 않는다. 계산해서 바로 쓰고 버린다. 저장이 필요하면 distance(from:to:)로 오프셋을 보관한다.
2. 문자열을 수정한 뒤에는 인덱스를 다시 계산한다. 특히 insert·removeSubrange 뒤.
3. 다른 문자열에서 얻은 인덱스를 재사용하지 않는다. 값이 맞아 보여도 의미가 없다.
4. NSRange와 섞을 때는 반드시 변환 API를 쓴다. Range(nsRange, in: string). UTF-16 좌표를 Character 감각으로 다루면 어긋난다(Q7).
5. 범위 검사를 습관화한다. 외부에서 받은 인덱스는 idx < endIndex를 먼저 확인한다.

꼬리 질문

// 저장
let utf16Offset = text.distance(from: text.startIndex, to: cursor)   // Character 기준
// 또는 UIKit 좌표계로
let nsOffset = text.utf16.distance(from: text.utf16.startIndex,
                                   to: cursor.samePosition(in: text.utf16)!)

// 복원 — 반드시 범위를 확인한다
let safe = min(savedOffset, text.count)
let restored = text.index(text.startIndex, offsetBy: safe)

// ❌ 매 반복이 처음부터 센다 — 전체가 O(n²)
for i in 0..<text.count {
    let idx = text.index(text.startIndex, offsetBy: i)
    process(text[idx])
}

// ✅ 인덱스를 이어서 전진시킨다 — O(n)
var idx = text.startIndex
while idx < text.endIndex {
    process(text[idx])
    idx = text.index(after: idx)
}

// ✅ 더 낫게 — 그냥 순회한다
for ch in text { process(ch) }

// 서버가 UTF-8 바이트 오프셋을 준다는 계약이라면
guard let u8 = text.utf8.index(text.utf8.startIndex,
                               offsetBy: serverUTF8Offset,
                               limitedBy: text.utf8.endIndex),
      let idx = u8.samePosition(in: text) else {
    // 경계가 아니거나 범위를 벗어남 — 서버 계약 위반으로 처리
    return
}

Q4. 문자열은 메모리에 어떻게 담기는가?

CS 원리

이것은 소형 객체 최적화(small object optimization)의 문자열 판본이다. 아이디어는 단순하다 — 포인터를 담을 자리에 값을 직접 담는다.

힙 할당은 비싸다. 할당자 호출, 캐시 미스, 그리고 해제 시점 관리(참조 카운팅)까지 붙는다. 그런데 실제 프로그램에서 다루는 문자열의 상당수는 아주 짧다 — 키 이름, 식별자, 짧은 레이블. 이 경우 포인터 8바이트를 저장하려고 힙을 쓰느니, 그 8바이트 자리에 문자를 직접 넣는 편이 낫다.

대가는 분기다. 모든 접근이 "지금 인라인인가 힙인가"를 판별해야 한다. 그래서 값 안에 판별 비트를 둔다. Swift는 _countAndFlagsBits와 포인터 워드의 여분 비트를 이 용도로 쓴다 — P0 05장 Q6에서 본 extra inhabitant를 태그로 재활용하는 것과 같은 기법이다.

여기서 불연속적 성능 절벽이 생긴다. 대부분의 자료구조는 크기가 커질수록 비용이 매끄럽게 늘지만, 이 최적화는 경계에서 한 번에 튄다. 14바이트와 15바이트는 거의 같고, 15바이트와 16바이트는 몇 배 차이가 난다.

iOS에서는

Swift 5부터 네이티브 String은 검증된 UTF-8 바이트를 단일 연속 버퍼에 담는다. 예전에는 UTF-16 기반이었고, 이 전환이 상당한 성능 변화를 만들었다.

MemoryLayout<String>.size          // 16  ← 값 자체는 항상 16바이트

// 인라인 여부를 직접 볼 수는 없지만 성능으로 드러난다
let short = "abcdefghijklmno"      // 15바이트 — 인라인
let long  = "abcdefghijklmnop"     // 16바이트 — 힙

// 한글은 글자당 3바이트라 경계가 훨씬 이르다
"가나다라마".utf8.count             // 15  ← 인라인 경계 정확히
"가나다라마바".utf8.count           // 18  ← 이미 힙

실무에 미치는 영향은 비용의 성격이 달라진다는 점이다.

• 인라인 문자열의 복사는 값 복사다. 참조 카운트 증가가 없다.
• 힙 문자열의 복사는 참조 카운트 증가이고, 수정하면 CoW로 실제 복사가 일어난다(P0 05장 Q3).

그래서 짧은 키를 대량으로 다루는 코드에서 차이가 난다 — 딕셔너리 키, 열거형 원시값, 로그 카테고리 같은 것들.

// 짧은 키는 인라인이라 사전 조회에서 ARC 트래픽이 없다
var counts: [String: Int] = [:]
for event in events { counts[event.name, default: 0] += 1 }
//   event.name 이 15바이트 이하면 힙 접근 없이 비교·해싱된다

// 긴 키는 매 조회마다 힙 버퍼를 따라간다
//   → 키를 짧게 유지하거나, 열거형·정수 ID로 바꾸는 것이 유리할 수 있다

실험 · 도구

경계를 직접 재 보면 절벽이 그대로 보인다.

import Foundation

func bench(_ label: String, _ seed: String, iterations: Int = 2_000_000) {
    let clock = ContinuousClock()
    let elapsed = clock.measure {
        for _ in 0..<iterations {
            var s = seed
            s.append("!")            // 수정 → 인라인이면 값 조작, 힙이면 CoW 확인
            _ = s
        }
    }
    print("\(label) (\(seed.utf8.count)바이트): \(elapsed)")
}

bench("14바이트", String(repeating: "a", count: 14))
bench("15바이트", String(repeating: "a", count: 15))   // 여기까지 인라인
bench("16바이트", String(repeating: "a", count: 16))   // 여기서 튄다
bench("한글 5자", "가나다라마")                          // 15바이트 — 인라인
bench("한글 6자", "가나다라마바")                        // 18바이트 — 힙

힙 할당 자체를 세고 싶다면 Instruments의 Allocations 계측기로 malloc 호출 수를 비교한다(P0 15장 Q6). 인라인 구간에서는 문자열당 할당이 0이다.

# 커맨드라인에서 대략 확인 — 힙 할당 수를 세어 비교한다
# (macOS 실행 파일 기준. iOS 는 Instruments Allocations 를 쓴다)
MallocStackLogging=1 ./bench-short   # 15바이트 버전
MallocStackLogging=1 ./bench-long    # 16바이트 버전
#   leaks --outputGraph 로 스냅숏을 떠 할당 건수를 비교하면 차이가 드러난다

프로젝트 적용

1. 뜨거운 경로의 키를 짧게 유지한다. 15바이트(한글 5자) 이하면 힙 할당이 사라진다. 로그 카테고리·이벤트 이름처럼 초당 수천 번 만들어지는 문자열에 특히 효과가 있다.
2. 다만 가독성을 희생하지 않는다. 이름을 줄여 얻는 이득은 측정 가능한 뜨거운 경로에서만 의미가 있다. 대부분의 코드에서는 무시할 만하다.
3. 식별자에는 문자열 대신 열거형을 고려한다. 인라인 여부를 신경 쓸 필요가 아예 없어지고, 오타도 컴파일 단계에서 잡힌다.
4. "짧으면 공짜"라고 가정하지 않는다. 멀티바이트 문자가 섞이면 경계가 훨씬 이르다.
5. 벤치마크는 릴리스 빌드로 한다. 디버그 빌드에서는 최적화가 없어 이 차이가 묻힌다(P0 12장 Q4).

꼬리 질문

// ❌ 이득이 없다 — 결국 String 키
enum Key: String { case userName, sessionID }
dict[Key.userName.rawValue] = v

// ✅ 열거형 자체를 키로 — Hashable 자동 합성, 태그 해싱
enum Key: Hashable { case userName, sessionID }
var dict: [Key: String] = [:]
dict[.userName] = v

// 반복 루프 안에서 브리징하지 않는다
let ns = text as NSString                 // ✅ 한 번만 변환
for m in matches {
    let piece = ns.substring(with: m.range)   // 같은 NSString 재사용
}

// ❌ 매 반복 브리징
for m in matches {
    let piece = (text as NSString).substring(with: m.range)
}

Q5. Substring을 오래 들고 있으면 왜 메모리가 안 줄어드는가?

CS 원리

슬라이스 설계는 복사 회피라는 명확한 목적에서 나온다. 문자열을 파싱할 때 토큰마다 새 문자열을 할당하면 비용이 크므로, 원본을 그대로 두고 범위만 가리키는 값을 만든다. 이것 자체는 훌륭한 설계다.

대가는 수명이 전염된다는 것이다. 슬라이스는 원본 버퍼를 강하게 참조하므로, 슬라이스의 수명이 곧 원본 버퍼의 수명이 된다. 여기서 비대칭이 생긴다.

두 번째 행이 사고가 나는 자리다. 그리고 이 문제는 도구로 잡기 어렵다 — 메모리 누수 탐지기(Leaks)는 "도달할 수 없는데 해제되지 않은" 메모리를 찾는데, 여기서 원본 버퍼는 슬라이스를 통해 정당하게 도달 가능하다. 누수가 아니라 방치(abandoned)다.

두 번째 함정은 인덱스 기준점이다. 슬라이스의 인덱스는 0부터 시작한다는 보장이 없고, 원본에서의 오프셋을 그대로 물려받는다. array[2...4]의 startIndex는 2다.

iOS에서는

Swift는 이 위험을 타입으로 알려준다. 슬라이스 타입이 원본과 다르다는 사실 자체가 "이건 오래 들고 있지 말라"는 신호다.

let huge = String(repeating: "x", count: 50_000_000)   // 약 50MB

// ❌ Substring 을 그대로 보관 — 원본 50MB 가 계속 살아 있다
struct Cache { var token: Substring }
let cache = Cache(token: huge.prefix(3))
//   huge 가 스코프를 벗어나도 50MB 가 해제되지 않는다

// ✅ 명시 변환으로 원본에서 떼어낸다
struct Cache2 { var token: String }
let cache2 = Cache2(token: String(huge.prefix(3)))
//   3바이트만 남고 원본은 해제된다

인덱스 기준점 문제도 실무에서 자주 터진다.

let arr = [10, 20, 30, 40, 50, 60]
let slice = arr[2...4]

slice.startIndex        // 2   ← 0 이 아니다
slice.count             // 3
// slice[0]             // ❌ Fatal error: Index out of bounds

slice[slice.startIndex] // 30  ✅
slice.first             // 30  ✅ (Optional)
Array(slice)[0]         // 30  ✅ (복사 후에는 0 부터)

이 함정은 함수 경계에서 특히 위험하다. [Int]를 받는 함수에 ArraySlice를 Array(...)로 감싸 넘기면 안전하지만, 제네릭으로 Collection을 받으면 인덱스가 0부터라고 가정한 코드가 조용히 깨진다.

실험 · 도구

슬라이스가 원본을 붙잡는 것을 메모리로 직접 확인해 보자.

import Foundation

func rssMB() -> Double {
    var info = mach_task_basic_info()
    var count = mach_msg_type_number_t(MemoryLayout<mach_task_basic_info>.size) / 4
    let kr = withUnsafeMutablePointer(to: &info) {
        $0.withMemoryRebound(to: integer_t.self, capacity: Int(count)) {
            task_info(mach_task_self_, task_flavor_t(MACH_TASK_BASIC_INFO), $0, &count)
        }
    }
    return kr == KERN_SUCCESS ? Double(info.resident_size) / 1_048_576 : -1
}

print("시작:      \(rssMB()) MB")

var kept: ArraySlice<Int>? = nil
do {
    let big = Array(0..<60_000_000)        // 약 480MB
    print("할당 후:   \(rssMB()) MB")
    kept = big[0..<1]                      // 1개짜리 슬라이스만 남긴다
}                                          // big 이 스코프를 벗어난다
print("스코프 밖: \(rssMB()) MB")           // ← 여전히 480MB 대

kept = Array(kept!)[0..<1]                 // 복사로 떼어낸다
print("복사 후:   \(rssMB()) MB")           // ← 크게 떨어진다

Instruments로는 Allocations에서 "Persistent Bytes"를 본다. Leaks에는 안 잡힌다 — 도달 가능한 메모리이기 때문이다. 이것이 "누수"와 "방치"를 구분해야 하는 이유다.

프로젝트 적용

1. 슬라이스를 저장 프로퍼티로 두지 않는다. 함수 안에서 잠깐 쓰고 버리는 용도로만 쓴다.
2. 반환 타입을 Substring으로 노출하지 않는다. 호출자가 오래 보관할 수 있으므로, 공개 API는 String으로 변환해 돌려준다.
3. 파싱 결과를 모델에 담을 때 반드시 변환한다. 큰 응답 본문을 파싱해 작은 필드만 모델에 넣는 경우가 정확히 이 패턴이다 — 응답 전체가 살아남는다.
4. 슬라이스 인덱스를 정수 리터럴로 접근하지 않는다. slice.first·slice[slice.startIndex]를 쓴다.
5. 메모리가 안 줄어드는 현상을 만나면 Leaks가 아니라 Allocations를 본다. 누수 탐지기에는 안 잡히는 종류다.

꼬리 질문

// ❌ 응답 전체가 항목마다 붙잡힌다
struct Item { let name: Substring }
let items = body.split(separator: "\n").map { Item(name: $0.prefix(20)) }

// ✅ 명시 변환
struct Item2 { let name: String }
let items2 = body.split(separator: "\n").map { Item2(name: String($0.prefix(20))) }

// 안에서는 슬라이스로 싸게, 나갈 때 변환
func extractToken(from line: String) -> String {
    let piece = line.drop(while: { $0 != "=" }).dropFirst()   // Substring
    return String(piece)                                      // 경계에서 복사
}

Q6. URL·쿼리에서 문자열은 어디서 깨지는가?

CS 원리

이 문제의 본질은 같은 문자가 계층마다 다른 의미를 갖는다는 것이다.

URL은 여러 층으로 이루어진 문법이다. 스킴, 호스트, 경로, 쿼리, 프래그먼트가 : / ? #로 구분되고, 쿼리 안은 다시 &와 =로 나뉜다. 그래서 "구분자로 쓰이는 문자"와 "데이터인 문자"를 구별해야 하는데, 둘의 생김새가 같다.

해결 방식이 이스케이프다. 데이터 안에 구분자와 같은 문자가 있으면 다른 형태로 바꿔 적는다. 이 구조는 SQL 인젝션, 셸 인젝션, HTML 인젝션과 정확히 같은 문제다 — 데이터와 코드가 같은 채널을 지나는 것.

여기서 계층 규칙이 나온다.

• 인코딩은 가장 안쪽 값에 먼저, 조립은 바깥에서. 값을 인코딩한 뒤 &로 이어 붙여야 한다. 이어 붙인 뒤 통째로 인코딩하면 구분자까지 인코딩된다.
• 한 번만 인코딩한다. 이미 인코딩된 문자열을 다시 인코딩하면 %가 %25가 되어 이중 인코딩이 된다.
• 계층마다 허용 집합이 다르다. 경로에서 허용되는 문자와 쿼리 값에서 허용되는 문자가 다르다.

iOS에서는

URLComponents가 조립을 대신해 주므로, 직접 문자열을 이어 붙이지 않는 것이 첫 번째 원칙이다.

// ✅ 값을 그대로 넣으면 URLComponents 가 계층에 맞게 인코딩한다
var c = URLComponents(string: "https://api.example.com/search")!
c.queryItems = [
    URLQueryItem(name: "q",    value: "A&B=C"),
    URLQueryItem(name: "page", value: "2"),
]
c.url?.absoluteString
//   https://api.example.com/search?q=A%26B%3DC&page=2

// ❌ 직접 조립 + urlQueryAllowed — 값 안의 & 와 = 가 살아남는다
let bad = "A&B=C".addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)!
//   "A&B=C"  ← 아무것도 인코딩되지 않았다

+ 문제는 별도로 다뤄야 한다. RFC 3986상 +는 sub-delims라 구조적으로 유효해서 인코딩되지 않는다. 그런데 폼 인코딩 관례에서는 +가 공백이므로, 서버가 리터럴 +를 공백으로 오독할 수 있다.

extension CharacterSet {
    /// 쿼리 "값 하나"에 안전한 집합 — 구분자와 + 를 제외한다
    static let urlQueryValueAllowed: CharacterSet = {
        var s = CharacterSet.urlQueryAllowed
        s.remove(charactersIn: "+&=?")
        return s
    }()
}

"C++ 강좌".addingPercentEncoding(withAllowedCharacters: .urlQueryValueAllowed)!
//   "C%2B%2B%20%EA%B0%95%EC%A2%8C"  ← + 가 %2B 로 보존된다

그리고 최근 SDK의 동작 변화를 알아야 한다. URL(string:)은 공백·한글 같은 무효 문자를 만나면 예전처럼 nil을 돌려주는 대신 자동으로 퍼센트 인코딩한다(RFC 3986 파서로 통일, iOS 17 전후). 관대해진 것처럼 보이지만 부작용이 있다.

// 이미 인코딩된 %3A 와 무효 문자 [ 가 섞이면
URL(string: "https://x.com/a%3Ab[c]")?.absoluteString
//   %3A 의 % 까지 다시 인코딩되어 %253A 가 되는 이중 인코딩이 실측으로 재현된다
//   (2026-03 시점에도 추적 중인 미해결 이슈)

// ✅ 외부 입력은 엄격 검증으로 받는다
URL(string: rawInput, encodingInvalidCharacters: false)   // 무효하면 nil

실험 · 도구

어떤 집합이 무엇을 통과시키는지 직접 찍어 보면 감이 잡힌다.

let sample = "A&B=C+D 한글/?#"

for (name, set) in [("urlQueryAllowed", CharacterSet.urlQueryAllowed),
                    ("urlPathAllowed",  .urlPathAllowed),
                    ("urlHostAllowed",  .urlHostAllowed),
                    ("alphanumerics",   .alphanumerics)] {
    let enc = sample.addingPercentEncoding(withAllowedCharacters: set) ?? "-"
    print(String(format: "%-18@ %@", name as NSString, enc as NSString))
}
// urlQueryAllowed    A&B=C+D%20%ED%95%9C%EA%B8%80/?%23
//   ← & = + / ? 가 전부 통과했다. 값 하나에 쓰면 안 되는 이유다
// alphanumerics      A%26B%3DC%2BD%20%ED%95%9C%EA%B8%80%2F%3F%23
//   ← 가장 안전하지만 - . _ ~ 까지 인코딩해 URL 이 길어진다

서버가 무엇을 받았는지 확인하는 것이 최종 검증이다.

# 실제로 나가는 요청을 그대로 본다
curl -v -G "https://httpbin.org/get" \
     --data-urlencode "q=A&B=C+D" 2>&1 | grep -E "^> GET"
#   > GET /get?q=A%26B%3DC%2BD HTTP/2   ← 값이 통째로 인코딩됐는지 확인

# 이중 인코딩 여부는 %25 를 찾으면 된다
echo "https://x.com/a%253Ab" | grep -o '%25'
#   %25 가 보이면 이미 인코딩된 문자열을 또 인코딩한 것이다

프로젝트 적용

1. URL을 문자열 보간으로 만들지 않는다. "\(base)?q=\(query)"는 거의 항상 버그다. URLComponents로 조립한다.
2. 완성된 URL을 다시 파싱하지 않는다. 재파싱은 이중 인코딩의 주된 원인이다. 필요하면 URLComponents를 계속 들고 다니며 수정한다.
3. 외부 입력은 encodingInvalidCharacters: false로 엄격 검증한다. 자동 인코딩에 기대면 무엇이 들어왔는지 모른 채 통과시킨다.
4. 서버의 폼 인코딩 관례를 확인한다. +를 공백으로 읽는 서버라면 값에서 +를 반드시 %2B로 보낸다.
5. URL을 로그에 남길 때는 쿼리를 스크러빙한다. 검색어·토큰이 그대로 남는다(P1 23장 Q1).

꼬리 질문

let nfc = "가".precomposedStringWithCanonicalMapping
let nfd = "가".decomposedStringWithCanonicalMapping

nfc.addingPercentEncoding(withAllowedCharacters: .alphanumerics)!
//   %EA%B0%80              (3바이트)
nfd.addingPercentEncoding(withAllowedCharacters: .alphanumerics)!
//   %E1%84%80%E1%85%A1     (6바이트)  ← 완전히 다른 URL 이 된다

URLQueryItem(name: "q", value: rawQuery.precomposedStringWithCanonicalMapping)

// 딥링크 처리 — 화이트리스트로 받는다
guard let c = URLComponents(url: incoming, resolvingAgainstBaseURL: false),
      let id = c.queryItems?.first(where: { $0.name == "itemID" })?.value,
      id.allSatisfy(\.isHexDigit), id.count == 32 else {
    return    // 형식이 맞지 않으면 버린다
}
// ← 값을 "해석"하지 말고 "검증"한다

var c = URLComponents(string: "https://api.example.com")!
c.path = "/files/report 2026/Q3.pdf"
c.url?.absoluteString
//   /files/report%202026/Q3.pdf   ← 공백은 인코딩됐지만 / 는 그대로다
//   경로 구분자로 해석되어 서버가 다른 자원을 찾는다

let segment = "report 2026/Q3.pdf"
    .addingPercentEncoding(withAllowedCharacters: .alphanumerics.union(CharacterSet(charactersIn: "-._~")))!
c.percentEncodedPath = "/files/" + segment
//   /files/report%202026%2FQ3.pdf   ← 세그먼트 하나로 전달된다

Q7. 정규식은 유니코드를 어떻게 다루는가?

CS 원리

정규식 엔진은 기호의 열(sequence of symbols) 위에서 오토마톤을 돌린다. 그래서 "기호가 무엇인가"를 먼저 정해야 하고, 이 선택이 엔진의 의미론 전체를 결정한다.

맨 아래를 고르면 사용자 직관과 일치하지만, 다른 시스템과 좌표를 주고받을 때 변환이 필요하다. 위쪽을 고르면 좌표가 단순하지만 문자를 쪼갤 위험이 생긴다.

실무에서 이 차이가 드러나는 전형이 "세 글자 이상" 같은 수량 검사다. .{3,}이 그래프임 기준이면 이모지 3개가 통과하고, UTF-16 기준이면 이모지 2개만으로도 통과한다(하나당 2코드유닛).

iOS에서는

Swift Regex는 String의 Character 인덱스 위에서 동작하므로, 결과 범위가 그대로 String에 쓸 수 있는 인덱스다. 변환이 없다.

let text = "가족👨‍👩‍👧‍👦 이모지"

text.count                    // 7
(text as NSString).length     // 17   ← UTF-16 코드 유닛

// Swift Regex — 결과가 String.Index 범위다
if let m = text.firstMatch(of: /이모지/) {
    text[m.range]             // "이모지"   ← 바로 쓸 수 있다
}

// NSRegularExpression — NSRange 를 반드시 변환한다
let re = try NSRegularExpression(pattern: "이모지")
let ns = text as NSString
if let m = re.firstMatch(in: text, range: NSRange(location: 0, length: ns.length)) {
    // ❌ 위치 숫자를 그대로 쓰면 안 된다
    // ✅ 변환
    if let r = Range(m.range, in: text) { text[r] }   // "이모지"
}

타입 있는 캡처가 Swift Regex의 또 다른 이점이다.

let line = "2026-08-15 ERROR payment_failed"
let pattern = /(?<date>\d{4}-\d{2}-\d{2}) (?<level>\w+) (?<code>\w+)/

if let m = line.firstMatch(of: pattern) {
    m.date    // Substring — 이름으로 접근, 컴파일 타임 검사
    m.level
    m.code
}
//   NSRegularExpression 이라면 range(at: 1) 처럼 번호로 접근하고
//   번호가 틀려도 컴파일 단계에서 잡히지 않는다

다만 성능 기대는 신중해야 한다. Swift Regex의 이득은 주로 인덱스 변환 비용 제거와 타입 안전이지, 매칭 엔진 자체가 항상 더 빠른 것은 아니다.

실험 · 도구

두 좌표계의 차이를 직접 확인해 보자.

import Foundation

let samples = ["hello", "가족👨‍👩‍👧‍👦 이모지", "🇰🇷🇰🇷🇰🇷"]

for s in samples {
    let ns = s as NSString
    print(String(format: "%-20@ count=%2d  utf16=%2d  차이=%2d",
                 s as NSString, s.count, ns.length, ns.length - s.count))
}
// hello                count= 5  utf16= 5  차이= 0
// 가족👨‍👩‍👧‍👦 이모지        count= 7  utf16=17  차이=10
// 🇰🇷🇰🇷🇰🇷                 count= 3  utf16=12  차이= 9

"세 글자 이상" 검사가 엔진마다 다르게 판정되는 것도 재현된다.

let three = "🇰🇷🇰🇷"        // 사람이 보기엔 2글자

// Swift Regex — 그래프임 기준이라 통과하지 않는다
three.wholeMatch(of: /.{3,}/) != nil        // false  ✅ 의도대로

// NSRegularExpression — UTF-16 기준이라 8코드유닛이므로 통과한다
let re = try NSRegularExpression(pattern: "^.{3,}$")
let ns = three as NSString
re.firstMatch(in: three, range: NSRange(location: 0, length: ns.length)) != nil
//   true  ← 2글자인데 "세 글자 이상"을 통과했다

기존 코드가 어느 쪽을 쓰는지 훑어보려면 다음으로 찾는다.

# NSRange 를 직접 다루는 곳 — 변환 없이 쓰고 있으면 위험하다
grep -rn "NSRange(location:" --include=*.swift Sources/ | head -20

# 변환 API 를 쓰는지 확인
grep -rn "Range(.*, in:" --include=*.swift Sources/ | wc -l

# NSString 캐스팅 — 브리징이 루프 안에 있으면 비용이다 (Q4 꼬리질문)
grep -rn "as NSString" --include=*.swift Sources/

프로젝트 적용

1. 새 코드는 Swift Regex를 기본으로 쓴다. 좌표 변환이 없어 실수할 자리가 사라지고, 캡처가 타입으로 잡힌다.
2. NSRange를 만나면 즉시 변환한다. Range(nsRange, in: string). 위치 숫자를 직접 계산하지 않는다.
3. 수량 검사의 단위를 명시한다. "3자 이상"이 그래프임인지 코드 유닛인지 정하고, 서버와도 맞춘다(Q1).
4. 사용자 입력 검증에 정규식을 쓸 때는 이모지·결합 문자를 테스트에 넣는다. ASCII만으로 테스트하면 이 계층 차이가 절대 드러나지 않는다.
5. 성능을 이유로 무조건 바꾸지 않는다. 이득은 주로 변환 비용과 타입 안전이다. 매칭이 병목이면 정규식을 쓰지 않는 방법부터 검토한다.

꼬리 질문

func sanitized(_ raw: String) -> String {
    raw.precomposedStringWithCanonicalMapping                     // NFC 통일
       .trimmingCharacters(in: .whitespacesAndNewlines)
       .filter { !$0.unicodeScalars.contains { $0.properties.isDefaultIgnorableCodePoint } }
}

출처 · 참고자료