02 · Swift의 특징

30초 답변 🔥 먼저 이 문장

L1개념 — 타입 안정성이 코드에서 드러나는 네 장면

// ① 암묵적 형변환 없음 — 의도치 않은 정밀도 손실이 컴파일 에러
let a: Int = 3, b: Double = 1.5
// let c = a + b            // ❌ 컴파일 에러
let c = Double(a) + b       // ✅ 변환을 코드에 남긴다

// ② nil이 타입에 드러난다
func find(_ id: Int) -> User? { /* ... */ }
// let name = find(1).name  // ❌ nil 처리를 건너뛸 수 없다

// ③ exhaustive switch — 케이스를 추가하면 처리 누락이 전부 컴파일 에러
enum Payment { case card, bank, point }   // 여기에 .voucher 를 추가하면
switch payment {                          // 이 switch 들이 전부 에러가 난다
case .card: break
case .bank: break
case .point: break
}

// ④ 제네릭 제약 — 런타임 캐스팅 없이 다형성
func maxOf<T: Comparable>(_ xs: [T]) -> T? { xs.max() }
// as! 도, Any 도 필요 없다

L2언어 설계 — 안전을 얻는 네 개의 축

축 1 · 메모리 안전과 ARC

축 2 · 배타적 접근 (SE-0176)

func swapValues(_ x: inout Int, _ y: inout Int) { /* ... */ }

var n = 1
// swapValues(&n, &n)   // ❌ overlapping accesses to 'n'

// C에서는 이런 앨리어싱이 조용히 통과해 정의되지 않은 동작이 된다.
// Swift는 "겹치는 접근"을 금지해서, 컴파일러가 앨리어싱 없음을 가정하고
// 더 공격적으로 최적화할 수 있게 만든다 — 안전과 성능을 동시에 얻는 지점.

축 3 · 에러는 예외가 아니라 제어 흐름

Swift의 throws는 다른 언어의 예외와 다릅니다. 스택 되감기(unwinding)를 하지 않고 사실상 Result 반환에 가깝게 구현되므로 성능이 예측 가능합니다.

enum NetworkError: Error { case timeout, offline }

func fetch() throws(NetworkError) -> Data { /* ... */ }

do {
    let data = try fetch()
} catch {
    // error 타입이 NetworkError 로 확정 → exhaustive switch 가능
    switch error {
    case .timeout: retry()
    case .offline: showOfflineBanner()
    }
}

축 4 · 동시성

Swift 6.2에서는 방향이 한 번 조정됐습니다. 초기 모델이 "안전하지만 배우기 어렵다"는 피드백을 받았고, 접근하기 쉬운 동시성이라는 이름으로 다음이 들어왔습니다.

• 기본 격리를 MainActor로 (SE-0466) — 모듈 단위로 "표시 없는 코드는 메인 액터"로 둘 수 있다. 대부분의 앱 코드가 실제로 메인에서 도는 현실에 맞춘 것.
• nonisolated(nonsending) (SE-0461) — nonisolated async 함수가 호출자의 액터에서 실행되게 해서 불필요한 액터 이동(hop)과 Sendable 요구를 줄인다.

L3구현 — SIL이라는 중간 언어

Swift 컴파일러가 특이한 점은 LLVM IR로 바로 내리지 않고 SIL(Swift Intermediate Language)이라는 자체 중간 언어를 거친다는 것입니다. 이유는 명확합니다 — Swift 고유의 최적화는 LLVM이 모르기 때문입니다.

• ARC 최적화 — retain 직후 release처럼 상쇄되는 쌍을 제거. LLVM은 참조 카운팅 의미를 모르므로 이걸 못 합니다.
• 제네릭 특수화 — f<T>를 f<Int> 전용 사본으로 복제해 witness table 조회를 없앱니다.
• devirtualization — 오버라이드가 없음을 증명해 vtable 호출을 직접 호출로.
• 배타적 접근 검사 — 정적으로 판정되면 런타임 검사를 아예 빼 버립니다.

ABI 안정성이 실제로 고정한 것

Swift 5의 ABI 안정성은 "버전이 올라가도 된다"는 선언이 아니라, 바이너리 수준 규약을 못 박은 것입니다.

• 호출 규약 — 인자를 어느 레지스터에 싣고 소유권을 누가 갖는가
• 메모리 레이아웃 — 타입의 크기·정렬·필드 순서
• 이름 맹글링 — 제네릭·오버로드를 유일한 심볼 이름으로 인코딩하는 규칙
• 메타데이터 형식 — 런타임이 타입을 조회하는 자료구조

결과: 표준 라이브러리가 OS에 내장되어 앱 바이너리에서 빠졌고, 다른 버전의 컴파일러로 빌드한 바이너리끼리 링크가 가능해졌습니다. 대가로 라이브러리 진화(library evolution) 모드에서는 구조체 레이아웃을 마음대로 바꿀 수 없어 간접 접근이 늘어납니다 — 디스패치가 다시 동적으로 되돌아가는 지점입니다.

L4CS 근본 — 타입 시스템은 무엇을 증명하고, 무엇을 못 하나

① 타입 시스템의 정의: 실행 전에 오류 부류의 부재를 증명하는 장치

타입 이론에서 "타입 시스템이 건전(sound)하다"는 것은 두 정리로 정의됩니다.

• Progress — 타입이 붙은 프로그램은 값이거나, 아니면 한 걸음 더 실행할 수 있다. 중간에 "막히지" 않는다.
• Preservation — 한 걸음 실행해도 타입이 유지된다.

둘을 합치면 "타입이 맞는 프로그램은 타입 오류로 멈추지 않는다"가 증명됩니다. 흔히 말하는 "well-typed programs don't go wrong"이 이겁니다. Swift가 "안전하다"고 할 때의 정확한 의미도 "모든 버그가 없다"가 아니라 "이 부류의 오류가 없음이 보장된다"입니다.

② 대수적 데이터 타입 — 타입의 크기를 계산할 수 있다

Swift의 struct와 enum은 각각 곱 타입(product type)과 합 타입(sum type)입니다. 이름이 대수적인 이유는 실제로 표현 가능한 값의 개수가 곱셈과 덧셈이기 때문입니다.

|Bool| = 2
|Void| = 1

// 곱 타입 (struct / tuple) — 각 필드 개수의 곱
struct S { var a: Bool; var b: Bool }      // |S| = 2 × 2 = 4

// 합 타입 (enum) — 각 케이스 개수의 합
enum E { case x(Bool); case y }            // |E| = 2 + 1 = 3

// Optional 은 "+1" 이다
// Optional<T> = T + 1     →  |Bool?| = 2 + 1 = 3   (true, false, nil)

// ─────────── 그래서 이런 판단이 계산이 된다 ───────────
// ❌ Bool 3개  →  2 × 2 × 2 = 8가지, 그중 유효한 건 4가지
struct BadState { var isLoading: Bool; var hasError: Bool; var isEmpty: Bool }

// ✅ enum 하나 →  정확히 4가지, 무효 상태가 존재하지 않음
enum GoodState { case idle, loading, loaded([Item]), failed(Error) }

"make illegal states unrepresentable"이라는 격언은 감성적 조언이 아니라 상태 공간의 크기를 8에서 4로 줄이는 산술입니다. 줄어든 4개가 바로 테스트해야 했지만 아무도 안 하던 케이스입니다.

③ Swift의 타입 추론은 Hindley-Milner가 아니다

함수형 언어(ML, Haskell)는 Hindley-Milner 추론을 씁니다 — 거의 항상 최적 타입을 효율적으로 찾아 줍니다. Swift는 쓸 수가 없습니다. 오버로딩, 서브타이핑, 리터럴 프로토콜(ExpressibleByIntegerLiteral 등), 암묵적 변환이 있으면 HM의 전제가 깨집니다.

그래서 Swift는 제약 기반(constraint-based) 추론을 씁니다 — 식에서 제약을 모으고, 가능한 오버로드 조합을 탐색해서 해를 찾습니다. 그리고 여기서 실무에서 다들 겪는 그 에러가 나옵니다.

// 이 한 줄이 컴파일러를 몇 분씩 잡아먹거나 아예 포기하게 만든다
let x = a + b * c - d / e + f * g

// 왜? + - * / 각각이 Int, Double, Float, CGFloat... 여러 오버로드를 갖는다.
// 연산자가 n개면 조합이 지수적으로 늘어난다 (조합 폭발).
// 컴파일러는 시간 제한에 걸리면 "too complex"로 포기한다.

// ✅ 해법도 원리에서 나온다 — 탐색 공간을 쪼개거나 못 박는다
let t1: Double = b * c
let t2: Double = d / e
let x = a + t1 - t2 + f * g       // 타입을 명시하면 탐색이 확정된다

이 답을 할 수 있으면 "컴파일 느려요"라는 불평이 원리 설명으로 바뀝니다. 실무 경험과 CS가 만나는 가장 좋은 지점 중 하나입니다.

④ Rice의 정리 — 컴파일러가 원리적으로 못 잡는 것

Rice의 정리: 프로그램의 비자명한 의미적 성질은 일반적으로 결정 불가능하다. "이 코드에 데이터 경합이 있는가?", "이 참조는 절대 nil이 아닌가?", "이 클로저는 함수를 탈출하는가?" — 전부 정확히 판정할 수 없습니다.

그럼 컴파일러는 어떻게 하나? 보수적 근사(conservative approximation)를 합니다. 확신할 수 없으면 안전한 쪽으로 거부합니다.

그래서 Swift에는 반드시 탈출구가 존재합니다. 그리고 탈출구의 이름이 전부 "이건 네가 책임져"라고 말하고 있습니다.

CS 정본으로 더 내려가기

이 페이지의 L4는 면접 답변에 필요한 깊이까지만 팝니다. 같은 주제를 CS 원리 → iOS 매핑 → 재현·측정 순서로 끝까지 파는 것은 허브의 iOS 개발자 CS 로드맵이고, 대응 챕터는 아래입니다.

경험으로 말하기

꼬리 질문 대비

쉽게 이해하기

프로그래밍 언어를 공장의 안전 규정이라고 생각해 봅시다.

옛날 언어(C, Objective-C)는 "조심하세요"라고 써 붙인 공장입니다. 숙련공은 빠르게 일하지만 실수하면 다칩니다. 게다가 다치는 순간과 실수한 순간이 다릅니다 — 어제 잘못 놓은 부품 때문에 오늘 사고가 나요. 이게 nil 크래시와 데이터 경합의 정체입니다.

Swift는 애초에 잘못 조립되지 않는 부품을 쓰는 공장입니다. 안 맞는 부품은 끼워지지가 않습니다(컴파일 에러). "조심"에 의존하지 않죠.

그런데 여기서 중요한 사실이 하나 있습니다. 검사기는 애매하면 무조건 반려합니다. 사실은 멀쩡한 부품인데도요. 왜냐하면 "이 부품이 정말 안전한가"를 완벽하게 판정하는 기계는 만들 수 없다는 게 수학적으로 증명돼 있거든요(Rice의 정리). 그래서 공장에는 "제가 책임지겠습니다" 도장이 반드시 있습니다 — @unchecked Sendable, !, unowned가 그 도장입니다.

이걸 알면 태도가 바뀝니다. 컴파일러가 반려할 때 "왜 안 되지, 짜증나네"가 아니라 "아, 얘가 증명을 못 하는구나. 내가 증명할 수 있나?"로 묻게 됩니다. 증명할 수 있으면 도장을 찍고 근거를 주석으로 남기고, 못 하면 설계를 바꿉니다.

설계 근거 · 1차 자료

이 페이지의 "왜 그렇게 설계했나" 주장은 아래에서 나왔습니다. 면접에서 근거를 물으면 이 이름들을 대면 됩니다.