04 · Struct vs Class

30초 답변 🔥 먼저 이 문장

L1개념 — 차이의 전체 지도

struct Internal { var x: Int }                 // ✅ 자동으로 Sendable
public struct Public { public var x: Int }     // ❌ 자동 아님
public struct Public2: Sendable { public var x: Int }  // ✅ 명시해야 한다

L2언어 설계 — 선택 기준과 CoW

먼저: 왜 Swift는 값 타입을 1급으로 올렸나

"기본은 struct"라는 권고는 취향이 아니라 Objective-C 시절의 특정 버그 유형에 대한 대응입니다. 여기를 설명할 수 있으면 설계 의도를 안다는 게 드러납니다.

// ── Objective-C: 참조가 기본이라 "넘긴 뒤"를 통제할 수 없다 ──
- (void)configureWith:(NSMutableArray *)items {
    self.items = items;          // 💥 호출자가 나중에 items를 바꾸면 내 상태도 바뀐다
}
// 그래서 Cocoa 전반에 이 관행이 생겼다:
- (void)configureWith:(NSArray *)items {
    self.items = [items copy];   // 방어적 복사 — "혹시 모르니 일단 복사"
}
// @property (copy) NSString *name;  ← copy 어트리뷰트가 흔한 이유가 이것

// 문제점
//   ① 개발자가 매번 기억해야 한다 (잊으면 조용히 버그)
//   ② 필요 없을 때도 복사한다 (항상 비용을 낸다)
//   ③ 얕은 복사라서 중첩 구조는 여전히 샌다

// ── Swift: 복사를 기본값으로 바꿔 이 셋을 한 번에 없앤다 ──
func configure(with items: [Item]) {
    self.items = items           // ✅ 이미 값이다. 방어적 복사가 불필요하다
}

그런데 "복사가 기본"은 곧바로 성능 반론에 부딪힙니다. 원소 10만 개 배열을 함수에 넘길 때마다 복사하면 쓸 수 없는 언어가 되죠. Swift의 판단은 "의미론은 값으로 고정하고, 비용은 표준 라이브러리가 흡수한다"였습니다 — 그 흡수 장치가 바로 다음에 볼 CoW입니다.

Apple의 공식 선택 기준

1. 기본은 struct.
2. ObjC 상호운용이 필요하면 class.
3. identity 제어가 필요하면 class — 공유되는 하나의 인스턴스여야 할 때.
4. 상속이 필요하면 class — 단, 프로토콜 + 컴포지션을 먼저 검토.

Copy-on-Write — "struct인데 왜 안 느린가"

Array·String·Dictionary·Set은 struct지만 내부에 힙 버퍼 참조를 들고 있습니다. 복사 시점엔 참조만 복사하고(O(1)), 쓰기 시점에 유일 소유자가 아니면 그때 실제로 복사합니다.

final class Storage {
    var data: [Int]
    init(_ d: [Int]) { data = d }
    func copy() -> Storage { Storage(data) }
}

struct Box {
    private var storage: Storage
    init(_ d: [Int]) { storage = Storage(d) }

    var values: [Int] { storage.data }        // 읽기는 그냥 통과

    mutating func append(_ v: Int) {
        if !isKnownUniquelyReferenced(&storage) {
            storage = storage.copy()          // 나만 쓰는 게 아니면 그때 복사
        }
        storage.data.append(v)
    }
}

L3구현 — 메모리에서 실제로 무엇이 다른가

MemoryLayout — size / stride / alignment

struct A { var flag: Bool; var num: Int64; var flag2: Bool }
struct B { var flag: Bool; var flag2: Bool; var num: Int64 }

MemoryLayout<A>.size       // 17  — Bool(1) + 패딩7 + Int64(8) + Bool(1)
MemoryLayout<A>.alignment  // 8   — 가장 엄격한 멤버(Int64)를 따른다
MemoryLayout<A>.stride     // 24  — 17을 8의 배수로 올림 (배열에서 다음 원소까지)

MemoryLayout<B>.size       // 16  — Bool(1) + Bool(1) + 패딩6 + Int64(8)
MemoryLayout<B>.stride     // 16  — 이미 8의 배수라 꼬리 패딩이 없다

// ★ size와 stride의 차이가 여기서 드러난다
//   size   : 마지막 유효 바이트까지 — 꼬리 패딩을 포함하지 않는다 (A = 17)
//   stride : size를 alignment의 배수로 올림한 값 — 꼬리 패딩 포함 (A = 24)
//   배열의 원소 간격을 정하는 건 size가 아니라 stride다.
//
// 선언 순서만 바꿔서 stride가 24 → 16 으로 줄었다.
// 원소 100만 개 배열이면 8MB 차이다.

L4CS 근본 — 진짜 성능 차이는 캐시에서 난다

"class는 힙 할당이라 느리다"는 흔한 설명인데, 절반만 맞습니다. 할당 비용도 있지만, 실무에서 훨씬 크게 작용하는 건 메모리 계층입니다.

① 메모리 계층 — 숫자를 알면 판단이 바뀐다

② 캐시 라인과 공간 지역성

CPU는 메모리를 바이트가 아니라 캐시 라인 단위로 가져옵니다. 라인 크기는 아키텍처마다 다른데, x86은 보통 64바이트, Apple Silicon은 128바이트입니다. 즉 Int 하나(8바이트)를 읽어도 그 주변 120바이트가 함께 캐시에 올라옵니다.

여기서 struct 배열과 class 배열의 결정적 차이가 나옵니다.

struct PointS { var x: Double; var y: Double }
final class PointC { var x = 0.0; var y = 0.0 }

let structs = (0..<1_000_000).map { _ in PointS(x: 1, y: 2) }
let classes = (0..<1_000_000).map { _ in PointC() }

// 순회 — 여기가 진짜 차이가 나는 곳
var sum = 0.0
for p in structs { sum += p.x }   // 연속 메모리 → 캐시 라인마다 여러 개 처리
for p in classes { sum += p.x }   // 포인터 → 힙 임의 위치 → 미스 + ARC까지

// 주의: 실제 수치는 요소 크기·접근 패턴·최적화 수준에 따라 크게 달라진다.
// 면접에서는 배수를 말하지 말고 "왜 차이가 나는가"를 말하는 게 안전하다.

③ 참조 카운팅이 멀티코어에서 비싼 진짜 이유

retain/release는 원자적 증감입니다. 그런데 원자적 연산의 비용은 명령어 몇 개가 아니라 캐시 일관성 트래픽에서 나옵니다.

• 여러 코어가 같은 객체를 retain/release 하면, 그 refCount가 든 캐시 라인의 소유권이 코어 사이를 왕복합니다.
• 이걸 MESI 같은 캐시 일관성 프로토콜이 처리하는데, 소유권 이동마다 코어 간 통신이 발생합니다.
• 결과적으로 공유 객체를 여러 스레드가 만지면 refCount 자체가 병목이 될 수 있습니다.

여기서 "값 타입을 기본으로"라는 조언이 성능 조언이자 동시성 조언으로 합쳐집니다. 값 타입은 공유되지 않으니 refCount 경쟁이 없고, 그래서 Sendable도 자동으로 얻습니다 — 07번 Thread Safety와 만나는 지점입니다.

④ CoW는 OS가 먼저 쓰던 기법이다

Copy-on-Write는 Swift의 발명이 아니라 운영체제의 고전 기법입니다. fork()로 프로세스를 복제할 때 메모리 전체를 복사하지 않고, 페이지를 공유한 뒤 읽기 전용으로 표시합니다. 누군가 쓰려고 하면 그때 페이지 폴트를 일으켜 그 페이지만 복사하죠.

실무 선택 프레임

CS 정본으로 더 내려가기

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

경험으로 말하기

꼬리 질문 대비

final class Box { var value = 0 }
struct Wrapper { var box = Box() }      // struct 안에 참조 타입

var a = Wrapper()
var b = a                // struct 복사 — 하지만 box 는 "포인터가" 복사된다
b.box.value = 99
print(a.box.value)       // 99 ⚠️ a도 바뀌었다!

쉽게 이해하기

struct는 복사해서 나눠 주는 종이입니다. 내가 내 종이에 낙서해도 네 종이는 멀쩡해요. class는 화이트보드 위치를 알려 주는 것입니다. 우리 둘 다 같은 보드를 보니까, 내가 지우면 너한테도 지워집니다.

그런데 "종이는 복사하니까 느리겠네?"라고 생각하기 쉬운데, Swift는 여기서 꾀를 부립니다. 일단 "복사했다고 말만 해 두고" 실제로는 같은 종이를 봅니다. 그러다 누군가 연필을 드는 순간에만 진짜로 복사합니다. 이게 CoW예요. 대부분은 읽기만 하니까, 진짜 복사는 생각보다 훨씬 적게 일어납니다.

그리고 여기가 CS로 이어지는 지점입니다. 컴퓨터가 느려지는 진짜 이유는 계산이 많아서가 아니라 데이터를 가지러 멀리 가야 해서인 경우가 많습니다. CPU 바로 옆 서랍(캐시)에 있으면 순식간이고, 창고(메인 메모리)까지 가야 하면 50배 넘게 걸립니다.

종이 100장이 한 뭉치로 묶여 있으면(struct 배열) 한 번에 서랍으로 가져올 수 있습니다. 그런데 "창고 A-3칸, B-7칸, C-1칸..." 위치 목록만 들고 있으면(class 배열) 100번 창고를 왕복해야 해요. 이게 struct 배열이 빠른 진짜 이유입니다 — 할당을 안 해서가 아니라, 가지러 갈 거리가 짧아서.

설계 근거 · 1차 자료

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