SwiftUI로 앱을 만들다 보면, 리스트에서 아이템을 선택하면 상세 화면이 뜨는 패턴을 자주 구현하게 된다. 이번에는 FrameworkGridView, FrameworkGridViewModel, FrameworkDetailView 세 가지를 기준으로 .sheet가 어떻게 동작하는지 하나씩 뜯어보자.

1. 전체 구조 다시 보기

FrameworkGridView

@StateObject var viewModel = FrameworkGridViewModel()

var body: some View {
    NavigationView {
        ScrollView {
            LazyVGrid(columns: columns) {
                ForEach(MockData.frameworks, id: \.id) { framework in
                    FrameworkTitleView(framework: framework)
                        .onTapGesture {
                            viewModel.selectedFramework = framework
                        }
                }
            }
        }
        .navigationTitle("🍎 Frameworks")
        .sheet(isPresented: $viewModel.isShowingDetailView) {
            FrameworkDetailView(
                frameWork: viewModel.selectedFramework!,
                isShowingDetailView: $viewModel.isShowingDetailView
            )
        }
    }
}

FrameworkGridViewModel

final class FrameworkGridViewModel: ObservableObject {
    var selectedFramework: Framework? {
        didSet {
            isShowingDetailView = true
        }
    }

    @Published var isShowingDetailView = false
}

FrameworkDetailView

struct FrameworkDetailView: View {
    var frameWork: Framework
    @Binding var isShowingDetailView: Bool

    var body: some View {
        VStack {
            HStack {
                Spacer()
                Button {
                    isShowingDetailView = false
                } label: {
                    Image(systemName: "xmark")
                        .foregroundColor(Color(.label))
                        .imageScale(.large)
                        .frame(width: 44, height: 44)
                }
            }
            .padding()

            Spacer()
            FrameworkTitleView(framework: frameWork)
            Text(frameWork.description)
                .font(.body)
                .padding()
            Spacer()
            Button {
                // 더 알아보기 로직
            } label: {
                AFButton(title: "더 알아보기")
            }
        }
    }
}

2. 동작 흐름 정의

1) onTapGesture로 selectedFramework 주입

FrameworkGridView에서 사용자가 특정 아이템을 탭하면 viewModel.selectedFramework에 선택한 framework가 할당된다.

.onTapGesture {
    viewModel.selectedFramework = framework
}

즉, FrameworkGridView는 이미 생성된 ViewModel 인스턴스를 사용하며, 선택한 데이터를 ViewModel에 넘겨주는 역할만 한다.

2) didSet을 통한 isShowingDetailView 변경

FrameworkGridViewModel의 핵심 로직은 selectedFramework의 didSet이다.

var selectedFramework: Framework? {
    didSet {
        isShowingDetailView = true
    }
}

• 선택된 데이터가 할당되면
• 자동으로 isShowingDetailView가 true로 바뀐다.

즉, 선택과 동시에 상세 화면을 띄우라는 신호를 보내는 구조다.

3) @Published와 .sheet의 반응

isShowingDetailView는 @Published이기 때문에, 값이 변경되면 이 값을 감시하고 있는 View가 즉시 반응한다.

.sheet(isPresented: $viewModel.isShowingDetailView) {
    FrameworkDetailView(
        frameWork: viewModel.selectedFramework!,
        isShowingDetailView: $viewModel.isShowingDetailView
    )
}

즉,

• isShowingDetailView = true → .sheet가 뜬다
• isShowingDetailView = false → .sheet가 닫힌다

FrameworkDetailView 내부에서 xmark 버튼을 눌러 isShowingDetailView = false로 바꾸면, 자동으로 시트가 사라지는 이유도 여기에 있다.

4) 선택된 데이터의 전달

.sheet가 실행될 때, selectedFramework에 저장된 데이터가 그대로 전달된다.

FrameworkDetailView(
    frameWork: viewModel.selectedFramework!,
    isShowingDetailView: $viewModel.isShowingDetailView
)

즉, FrameworkDetailView가 보여줄 데이터는 onTapGesture에서 선택된 그 데이터 그대로다.

3. 흐름 요약

1. 탭 이벤트 발생 → selectedFramework에 선택된 데이터가 주입된다.
2. didSet 실행 → isShowingDetailView가 true로 변경된다.
3. @Published 반응 → .sheet가 자동으로 뜬다.
4. 데이터 전달 → selectedFramework가 FrameworkDetailView에 전달되어 View에 표시된다.
5. 닫기 버튼 동작 → isShowingDetailView = false로 변경되어 .sheet가 닫힌다.

4. 한 줄 정리

즉, View → ViewModel → View의 단방향 흐름으로 동작하며, 상태 변경은 ViewModel이 책임지고, View는 그 상태를 구독하며 UI를 업데이트한다.

마무리로 정리한 내용

SwiftUI로 UI를 작성하다 보면 여러 개의 뷰를 나열하는 상황이 많다. 하지만 SwiftUI의 함수나 body는 단 하나의 View만 반환해야 한다. 그럼에도 여러 개의 뷰를 쌓을 수 있는 이유가 뭘까? 바로 @ViewBuilder 덕분이다.

1. @ViewBuilder란?

@ViewBuilder는 여러 개의 뷰를 하나의 View로 조합해주는 Function Builder이다.

쉽게 말해, 여러 View를 선언적으로 나열하면 Swift가 알아서 하나의 View 트리로 합쳐준다. 이 덕분에 body나 커스텀 컴포넌트에서 뷰를 자연스럽게 쌓을 수 있다.

2. 왜 필요한가?

SwiftUI에서 함수나 프로퍼티는 some View → 단일 View만 반환 가능하다.

func myView() -> some View {
    Text("Hello")
    Text("World")   // 오류 발생
}

그럼 이렇게 여러 View를 어떻게 쌓을 수 있을까? @ViewBuilder가 이 문제를 해결해준다.

@ViewBuilder
func myView() -> some View {
    Text("Hello")
    Text("World")   // 자동으로 TupleView로 묶임
}

Swift는 내부적으로 이 코드를 TupleView<(Text, Text)> 형태로 변환해준다.

@ViewBuilder를 쓰다보면 계속해서 아래와 같은 식으로 꼬리에 꼬리를 물면서 하나로 생성이 된다.

ModifiedContent<ModifiedContent<ModifiedContent<ModifiedContent<ModifiedContent<Text, _FrameLayout>, _BackgroundStyleModifier<AnyGradient>>, _EnvironmentKeyWritingModifier<Optional<Color>>>, _EnvironmentKeyWritingModifier<Optional<Font>>>, _ClipEffect<RoundedRectangle>>

3. 내부 원리

@ViewBuilder는 Swift의 Function Builder 기능을 사용한다. 컴파일러가 빌더 안의 여러 반환값을 하나로 합쳐주는 문법적 도우미다.

덕분에 다음과 같은 일이 가능해진다.

• if/else, switch, ForEach 같은 제어문 사용
• 여러 View를 선언적으로 조합

즉, SwiftUI의 선언적 UI 패러다임을 가능하게 하는 핵심 문법이다.

4. 활용 예시

4-1. 기본적인 사용

@ViewBuilder
func myView() -> some View {
    Text("Hello")
    Text("World")
}

자동으로 하나의 View로 합쳐지기 때문에 별도의 컨테이너를 명시하지 않아도 된다.

4-2. if/else 활용

@ViewBuilder
func greetingView(isMorning: Bool) -> some View {
    if isMorning {
        Text("Good Morning")
    } else {
        Text("Good Evening")
    }
}

빌더 내부에서 조건문을 자유롭게 쓸 수 있다.

4-3. ForEach 활용

@ViewBuilder
func listView(items: [String]) -> some View {
    ForEach(items, id: \.self) { item in
        Text(item)
    }
}

여러 개의 뷰를 동적으로 생성할 때도 유용하다.

4-4. 커스텀 뷰에서의 사용

@ViewBuilder는 클로저 형태로 View를 받아야 하는 커스텀 컴포넌트에서 특히 중요하다.

struct MyCard<Content: View>: View {
    let title: String
    let content: Content

    init(title: String, @ViewBuilder content: () -> Content) {
        self.title = title
        self.content = content()
    }

    var body: some View {
        VStack {
            Text(title)
                .font(.headline)
            content
        }
    }
}

struct ContentView: View {
    var body: some View {
        MyCard(title: "SwiftUI") {
            Text("ViewBuilder Example")
            Text("Hello World")
        }
    }
}

5. body는 왜 여러 View를 쌓을 수 있을까?

하나 의문이 생긴다. body에는 @ViewBuilder를 명시하지 않았는데 왜 여러 View를 쌓을 수 있을까? 정답은, SwiftUI가 body 프로퍼티에 암묵적으로 @ViewBuilder를 적용하기 때문이다.

즉, 다음 두 코드는 동일하게 작동한다.

// SwiftUI 내부에서 암묵적으로 이렇게 처리됨
@ViewBuilder
var body: some View {
    Text("Hello")
    Text("World")
}

7. 정리 — 한 줄 요약

SwiftUI로 앱을 만들다 보면 뷰가 화면에 나타나는 시점에 특정 작업을 실행해야 할 때가 있다. 이럴 때 사용하는 게 바로 .onAppear이다.

1. .onAppear란?

먼저 정의부터 짚고 가보자.

.onAppear는 SwiftUI에서 뷰가 화면에 나타날 때(렌더링될 때) 실행되는 클로저를 지정하는 뷰 수명주기(Lifecycle) 이벤트이다.

• 화면에 그려지는 순간 딱 한 번 실행된다.
• UIKit의 viewDidAppear와 유사한 역할을 한다.
• 뷰가 사라졌다가 다시 나타나면 다시 실행된다.

그럼 하나 의문이 생긴다. "UI가 다시 그려질 때도 실행될까?" 답은 No다. 단순히 데이터가 바뀌어 UI가 다시 렌더링될 때는 실행되지 않는다.

2. 특징

언제 실행되나?

• SwiftUI가 뷰를 실제로 렌더링해서 사용자에게 보이는 순간
• 예: NavigationLink로 새로운 화면을 열 때 새 화면의 onAppear가 호출됨

언제 다시 실행되나?

• 뷰가 완전히 사라졌다가 다시 나타날 때 (예: 다른 화면으로 갔다가 다시 돌아오면 실행)

반대 개념 – .onDisappear

• 뷰가 화면에서 사라질 때 실행된다.
• 주로 정리 작업(타이머 중지, 상태 초기화) 등에 사용된다.

3. 문법

.onAppear {
    // 뷰가 나타날 때 실행할 코드
}

.onDisappear {
    // 뷰가 사라질 때 실행할 코드
}

4. 예시

기본 사용 예시

struct OnAppearExample: View {
    @State private var message = "로딩 중..."

    var body: some View {
        Text(message)
            .onAppear {
                print("뷰가 화면에 나타났습니다!")
                message = "화면에 나타났습니다."
            }
            .onDisappear {
                print("뷰가 사라졌습니다!")
            }
    }
}

실행 흐름

1. 화면에 나타나는 순간 → "뷰가 화면에 나타났습니다!" 출력 + message 변경
2. 화면에서 벗어날 때 → "뷰가 사라졌습니다!" 출력

API 데이터 불러올 때 자주 사용

struct UserProfileView: View {
    @State private var username = "불러오는 중..."

    var body: some View {
        Text(username)
            .onAppear {
                loadUserData()
            }
    }

    func loadUserData() {
        // 실제 앱에서는 네트워크 요청 사용
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            username = "홍길동"
        }
    }
}

뷰가 로드되자마자 자동으로 네트워크 요청이나 초기 데이터 세팅을 할 때 많이 사용된다.

5. 한 줄 정리

한 줄 요약: .onAppear는 뷰가 보이는 순간 작업을 시작하고, .onDisappear는 사라질 때 정리하는 데 쓰인다.

@State, @Binding, @StateObject, @ObservedObject, @EnvironmentObject

SwiftUI로 앱을 만들다 보면 “상태 관리”가 정말 중요하다는 걸 느끼게 된다. 값이 바뀔 때마다 UI가 자동으로 업데이트되니 편리하지만, 상태의 소유권과 생명주기를 제대로 이해하지 않으면 예상치 못한 버그를 맞이할 수 있다.

그럼 하나씩 정리해보자.

1. @State — 로컬 상태

정의

@State는 뷰 내부에서만 관리되는 로컬 상태다. 값 타입(Int, String, struct)에 적합하며, 값이 바뀌면 뷰가 자동으로 다시 그려진다.

의문

“이걸 어디에 써야 하지?” → 뷰 내부에서만 쓰는 값일 때 사용하면 된다. 외부와 공유할 필요가 없을 때 가장 적합하다.

예시 코드

struct CounterView: View {
    @State private var count = 0  // 로컬 상태

    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("증가") {
                count += 1  // 값 변경 → UI 자동 업데이트
            }
        }
    }
}

2. @Binding — 상위 상태를 하위에서 수정

정의

@Binding은 상위 뷰의 @State 값을 하위 뷰에서 읽고 수정할 수 있게 연결해 준다.

의문

“하위 뷰가 상태를 직접 소유하면 안 되나?” → 하위에서 소유하면 상위와 값이 따로 놀게 된다. 상위 상태를 공유해야 한다면 Binding이 정답이다.

예시 코드

struct ParentView: View {
    @State private var name = "홍길동"

    var body: some View {
        VStack {
            Text("이름: \(name)")
            ChildView(name: $name)  // Binding으로 전달
        }
    }
}

struct ChildView: View {
    @Binding var name: String  // 상위의 상태에 직접 연결

    var body: some View {
        TextField("이름 입력", text: $name)
            .textFieldStyle(.roundedBorder)
    }
}

하위에서 이름을 바꾸면 부모 뷰의 name도 즉시 바뀐다.

3. @StateObject — 참조 타입 상태의 소유자

정의

@StateObject는 뷰가 직접 ObservableObject를 소유하고 관리할 때 사용한다. SwiftUI가 객체의 생명주기를 관리하며, 값이 바뀌면 뷰가 다시 그려진다.

의문

“왜 그냥 @State로 클래스 타입을 쓰면 안 돼?” → @State는 값 타입 전용이다. 클래스 같은 참조 타입은 @StateObject를 써야 한다.

예시 코드

class UserSettings: ObservableObject {
    @Published var score = 0
}

struct StateObjectExample: View {
    @StateObject private var settings = UserSettings()  // 뷰가 소유

    var body: some View {
        VStack {
            Text("점수: \(settings.score)")
            Button("점수 증가") {
                settings.score += 1
            }
        }
    }
}

@StateObject는 뷰가 새로 그려져도 기존 객체를 유지한다.

4. @ObservedObject — 다른 뷰에서 만든 객체 관찰

정의

@ObservedObject는 상위에서 이미 만든 ObservableObject를 관찰만 할 때 사용한다. 뷰는 이 객체를 소유하지 않는다.

의문

“그럼 @StateObject랑 뭐가 다른데?” → 소유권의 차이다.

• @StateObject: 내가 소유 → 내가 생성
• @ObservedObject: 남이 소유 → 나는 관찰만

예시 코드

struct ParentView: View {
    @StateObject private var settings = UserSettings()  // 부모가 소유

    var body: some View {
        VStack {
            Text("부모 점수: \(settings.score)")
            ChildView(settings: settings)
        }
    }
}

struct ChildView: View {
    @ObservedObject var settings: UserSettings  // 단순 관찰

    var body: some View {
        VStack {
            Text("자식 점수: \(settings.score)")
            Button("점수 증가") {
                settings.score += 1
            }
        }
    }
}

부모와 자식이 같은 객체를 공유하며, 값이 바뀌면 둘 다 업데이트된다.

5. @EnvironmentObject — 전역 상태 공유

정의

@EnvironmentObject는 앱 전역에서 공유하는 상태를 주입받을 때 사용한다. 상위에서 .environmentObject(_:)로 한 번만 넣어주면 하위 뷰 어디서든 접근 가능하다.

의문

“그냥 파라미터로 넘기면 되지 않나?” → 뷰 계층이 깊어질수록 파라미터로 계속 넘기는 게 귀찮아진다. @EnvironmentObject를 쓰면 이 문제를 깔끔하게 해결할 수 있다.

예시 코드

class AppSettings: ObservableObject {
    @Published var themeColor: Color = .blue
}

@main
struct MyApp: App {
    @StateObject private var settings = AppSettings()

    var body: some Scene {
        WindowGroup {
            RootView()
                .environmentObject(settings)  // 전역 주입
        }
    }
}

struct RootView: View {
    var body: some View {
        ChildView()  // 별도 파라미터 필요 없음
    }
}

struct ChildView: View {
    @EnvironmentObject var settings: AppSettings

    var body: some View {
        VStack {
            Text("테마 색상")
                .foregroundColor(settings.themeColor)
            Button("색상 변경") {
                settings.themeColor = .red
            }
        }
    }
}

단, 주입하지 않으면 런타임 에러가 난다.

한눈에 비교

결론 — 한 줄 요약

• 소유권이 핵심이다.
• 내가 만든 값 → @State / @StateObject
• 남이 준 값 → @Binding / @ObservedObject
• 전역 공유 → @EnvironmentObject

Swift로 비동기 작업을 하다 보면 async/await는 자연스럽게 접하게 되는데, 조금만 깊게 들어가 보면 @Sendable 같은 개념도 함께 따라온다.

async와 await란?

먼저 정의부터 짚고 가보자.

async는 비동기 함수임을 나타내는 키워드고, await는 비동기 함수의 결과를 기다리기 위한 키워드다.

즉, async는 약속, await는 그 약속을 기다리는 역할이라고 보면 된다.

func fetchName() async -> String {
    return "Swift User"
}

Task {
    let name = await fetchName()
    print(name)  // Swift User
}

Swift 5.5부터 도입된 이 문법은 비동기 코드도 동기처럼 읽기 쉽게 만들어주는 강력한 도구다.

async await 선언방법

비동기 함수 정의

func getUserInfo() async -> String {
    try? await Task.sleep(for: .seconds(1))
    return "User Info"
}

호출 예시

Task {
    let info = await getUserInfo()
    print(info)
}

await는 반드시 비동기 컨텍스트에서만 사용 가능하다. 즉, Task {} 같은 비동기 환경 안에서만 쓸 수 있다.

Task {}는 새로운 비동기 실행 컨텍스트를 열어주는 문이다.

@Sendable은 뭐가 다른 걸까?

@Sendable은 뭔가 생소한 느낌이 있는데, 이것도 사실 async와 함께 쓰이다 보면 자주 마주치게 된다.

정의부터 정리해보자

@Sendable은 클로저가 스레드 안전하게 실행될 수 있음을 컴파일러에 보장해주는 키워드다.

다시 말해, 비동기 환경에서 다른 스레드로 넘어갈 수 있는 클로저인지 아닌지를 판단하는 기준인 셈.

의문점이 생긴다

“왜 꼭 @Sendable을 붙이라고 할까?”

이유는 명확하다. Swift의 동시성 모델은 스레드 안전성(thread safety)을 기본으로 하기 때문이다.

예를 들어 이런 코드가 있다고 해보자:

var name = "Foo"

Task {
    await getFullName(delay: .seconds(1)) {
        print(name) // ❌ 외부 변수 캡처 → 컴파일 에러 가능성
        return "Result"
    }
}

이 코드는 name이라는 외부 변수를 참조하고 있어서 동시성 환경에서는 데이터 충돌이나 레이스 컨디션이 생길 수 있다.

그래서 Swift는 컴파일 타임에 미리 알려준다. “이 클로저는 @Sendable이 아닌데, 스레드 안전하지 않을 수 있어!”

@Sendable을 비유로 쉽게 이해해보자

이 개념이 어렵게 느껴진다면, 이렇게 비유해보자.

• 클로저는 "메모지에 적힌 일"
• Task는 "그 메모를 친구에게 넘겨서 대신 처리해달라는 상황"

근데 메모에 이렇게 써 있다면?

“내 방 책상 위에 있는 파일을 꺼내서 정리해줘!”

친구는 내 방에 들어올 수 없는데…? 결국 그 일은 실패하고 만다. ⚠️

Swift에서도 똑같은 상황이 벌어진다.

• 클로저가 외부 값을 참조하고 있다면
• 다른 스레드에서는 그 값에 접근할 수 없거나 위험할 수 있다.

그래서 Swift는 명시적으로 @Sendable을 붙이라고 요구하는 것이다. 해당 클로저가 사용하는 동안은 다른 스레드에서는 사용할 수 없도록 제한을 해버리는 것이다.

정리하며 한 줄 요약

Swift에서는 기본 제공되는 연산자뿐만 아니라 연산자를 직접 정의하거나 옵셔널 타입에도 오버로딩을 통해 다양한 동작을 지정할 수 있다. 오늘은 아래와 같은 내용을 중심으로 Swift의 연산자 활용법을 정리해본다

• 옵셔널 문자열을 더하는 + 연산자
• 사용자 정의 전위/후위 연산자
• 커스텀 타입(Person, Family) 간의 연산자 정의

옵셔널 문자열에 대한 + 연산자 오버로딩

func + (
    lhs: String?,
    rhs: String?
) -> String? {
    switch(lhs, rhs) {
    case(.none, .none):
        return nil
    case let (.some(value), .none),
         let (.none, .some(value)):
        return value
    case let (.some(lhs), .some(rhs)):
        return lhs + rhs
    }
}

개념 설명

• 옵셔널 String 타입도 + 연산을 사용할 수 있도록 오버로딩 함.
• 두 값 모두 nil이면 결과도 nil.
• 한 쪽이 nil이면, 다른 쪽 값을 반환.
• 둘 다 값이 있으면 일반 문자열처럼 이어붙임.

let firstName: String? = "Foo"
let lastName: String? = " Bar"
let fullName = firstName + lastName  // "Foo Bar"

사용자 정의 연산자

전위 연산자 (prefix)

prefix operator ^
prefix func ^ (value: String) -> String {
    value.uppercased()
}

let lowercaseName = "Foo Bar"
let uppercaseName = ^lowercaseName  // "FOO BAR"

• ^"hello" → "HELLO"
• 문자열을 전부 대문자로 바꾸는 사용자 정의 연산자

후위 연산자 (postfix)

postfix operator *
postfix func * (value: String) -> String {
    "*** \(value) ***"
}

let widthStars = lowercaseName*  // "*** Foo Bar ***"

• "hello"* → "*** hello ***"
• 문자열 양옆에 별표를 붙이는 연산자

커스텀 타입 간의 연산자 정의

struct Person {
    let name: String
}
struct Family {
    let members: [Person]
}

🔹 Person + Person → Family

func + (lhs: Person, rhs: Person) -> Family {
    Family(members: [lhs, rhs])
}

🔹 Family + Person → Family

func + (lhs: Family, rhs: Person) -> Family {
    var members = lhs.members
    members.append(rhs)
    return Family(members: members)
}

🔹 Family + [Person] → Family

func + (lhs: Family, rhs: [Person]) -> Family {
    var members = lhs.members
    members.append(contentsOf: rhs)
    return Family(members: members)
}

사용 예

let mom = Person(name: "Mom")
let dad = Person(name: "Dad")
let son = Person(name: "Son")
let daughter1 = Person(name: "Daughter1")
let daughter2 = Person(name: "Daughter2")

let family = mom + dad                         // Family with mom and dad
let familyWithChildren = family + son         // Family with mom, dad, son
let familyWithDaughters = familyWithChildren + [daughter1, daughter2]

• 연산자 오버로딩을 통해 자연어처럼 family + son 또는 mom + dad 형태로 코드를 구성할 수 있어 가독성이 높아짐.

오늘의 핵심 요약

마무리

Swift에서는 연산자 오버로딩과 사용자 정의 연산자 기능을 통해 표현력 있는 코드, 안전한 로직 처리, 가독성 좋은 DSL 형태의 인터페이스를 만들 수 있다. 단, 과한 오버로딩은 오히려 가독성을 해칠 수 있으므로 적절한 수준에서 명확한 의미를 갖도록 정의하는 것이 중요하다.

hashValue는 어떤 객체를 빠르게 식별할 수 있도록 만들어주는 고유한 정수값이다. 객체가 Hashable을 채택하면 자동으로 사용할 수 있게 된다.

예를 들어서:

struct Person: Hashable {
    let name: String
    let age: Int
}

let foo = Person(name: "Foo", age: 30)
print(foo.hashValue)  // 고유한 정수값 출력

이 값은 주로 Set이나 Dictionary처럼 해시 기반 컬렉션에서 빠른 검색을 위해 쓰인다.

정리하자면: hashValue는 객체를 빠르게 찾기 위한 식별 번호다.

hashValue가 같으면 같은 객체인가?

아니다.

두 객체의 hashValue가 같아도 == 비교 결과는 다를 수 있다. 하지만 중요한 규칙이 하나 있다.

==가 true라면, 반드시 hashValue도 같아야 한다.

이건 Hashable을 제대로 구현하기 위한 필수 조건이다.

그럼 실제로 예를 하나 보자

struct House: Hashable {
    let number: Int
    let numberOfBedrooms: Int
}

let house1 = House(number: 123, numberOfBedrooms: 2)
let house2 = House(number: 123, numberOfBedrooms: 2)

print(house1 == house2)       // true
print(house1.hashValue == house2.hashValue)  // true

왜 같을까? Swift는 struct가 Hashable을 채택하면, 내부 속성 기준으로 ==와 hashValue를 자동으로 만들어준다. 즉, number와 numberOfBedrooms가 같으니까 둘 다 true가 되는 것.

그럼 수동으로 구현하면?

이번엔 우리가 hash(into:)와 ==을 직접 정의해보자.

struct NumberedHouse: Hashable {
    let number: Int
    let numberOfBedrooms: Int

    func hash(into hasher: inout Hasher) {
        hasher.combine(number)
    }

    static func == (lhs: Self, rhs: Self) -> Bool {
        lhs.number == rhs.number
    }
}

이렇게 되면 오직 number만을 기준으로 동등성과 해시가 판단된다.

let h1 = NumberedHouse(number: 123, numberOfBedrooms: 2)
let h2 = NumberedHouse(number: 123, numberOfBedrooms: 100)

let set = Set([h1, h2])
print(set.count)  // 1

침실 수가 달라도 번호가 같으면 같은 객체로 취급된다. Set은 중복을 허용하지 않으니까 하나만 들어가는 것.

그럼 Set에 넣을 때 내부적으로 어떤 일이 일어날까?

Swift는 Set, Dictionary 등에 값을 넣을 때 자동으로 다음을 수행한다.

1. hash(into:)를 호출해서 해시값 계산
2. 해시값이 같으면 ==로 진짜 같은지 비교

즉, 우리는 함수만 정의하면 되고 언제 호출할지는 Swift가 알아서 처리해준다.

정리하면

한 줄 정리

hashValue는 빠른 탐색용 정수값, ==는 논리적 동등성 비교. 둘은 짝궁처럼 같이 작동해야 한다.

추가 팁

• Swift 4.2부터는 hashValue보다 hash(into:) 구현이 권장된다.
• ==가 true면 반드시 해시도 같아야 한다 (반대는 아님).
• Set, Dictionary에서 Hashable을 잘못 구현하면 중복 탐지 실패나 검색 오류 같은 버그가 생길 수 있다.
• 자동 합성도 편하지만, 커스텀 기준이 필요할 땐 직접 구현하자.

throws는 뭘까?

Swift에서 throws는 에러를 던질 수 있는 함수를 의미한다. 즉, 이 함수는 문제가 생기면 직접 에러를 호출한 쪽으로 "던질 수 있다".

func someFunc() throws -> String

바로 try를 붙여서 호출해야 한다.

do {
    let result = try someFunc()
} catch {
    print("에러 발생: \(error)")
}

또는 try?를 쓰면 실패 시 nil을 반환하고, try!는 실패 시 런타임 에러를 낸다.

rethrows란?

rethrows는 이렇게 정의할 수 있다.

자신은 에러를 던지지 않지만, 전달받은 클로저가 에러를 던지면 그걸 대신 던질 수 있게 해주는 키워드다.

예를 들어 다음과 같은 함수가 있다고 하자

func fullName(
    firstName: String?, 
    lastName: String?,
    calculator: (String?, String?) throws -> String?
) rethrows -> String? {
    try calculator(firstName, lastName)
}

fullName 함수는 직접 에러를 만들지는 않지만, calculator라는 클로저가 에러를 던질 수 있다면, 그 에러를 호출한 쪽으로 다시 던질 수 있다.

그럼 실제로 어떻게 동작하는지 예제를 보자.

💡 예제: 에러를 던지는 클로저를 넘기기

먼저, 에러 타입부터 정의해보자.

enum NameErrors: Error {
    case firstNameIsInvalid
    case lastNameIsInvalid
}

이제 +라는 함수(클로저로 넘길 수 있는 형태)를 만들어보자. 이 함수는 에러를 던질 수 있다.

func + (
    firstName: String?,
    lastName: String?
) throws -> String? {
    guard let firstName, !firstName.isEmpty else {
        throw NameErrors.firstNameIsInvalid
    }
    guard let lastName, !lastName.isEmpty else {
        throw NameErrors.lastNameIsInvalid
    }
    return "\(firstName) \(lastName)"
}

그리고 이 + 함수를 fullName 함수에 넘겨서 사용해보자.

do {
    let fooBar = try fullName(firstName: "foo", lastName: nil, calculator: +)
    print(fooBar ?? "")
} catch NameErrors.firstNameIsInvalid {
    print("First name is invalid")
} catch NameErrors.lastNameIsInvalid {
    print("Last name is invalid")
} catch {
    print("Something went wrong")
}

그러면 여기서 생기는 의문 하나

fullName 함수는 에러를 직접 던지지 않는데, 왜 do-catch로 감싸야 하지?

바로 이 지점이 rethrows의 핵심이다.

• fullName은 에러를 직접 던지지 않는다.
• 하지만 전달받은 클로저(+ 함수)가 throws 함수이기 때문에,
• 해당 클로저에서 에러가 발생하면, fullName은 그 에러를 "다시 던질 수" 있다.

🧠 한 줄 요약

rethrows는 "나는 에러를 만들진 않지만, 받은 클로저가 던진다면 그걸 대신 던질게"라는 선언이다.

Swift는 이렇게 정적 타입과 명시적 에러 처리를 중요하게 여기는 언어다. 그래서 throws와 rethrows의 쓰임새를 구분해서 설계하게 만든다. 이런 부분이 처음엔 번거롭지만, 점점 더 코드가 안정적으로 느껴지는 이유이기도 하다.

에러 처리와 옵셔널, 어떤 차이가 있을까?

이건 정말 자주 헷갈렸다. throw와 Optional은 모두 실패 상황을 표현할 수 있는데, 어떤 차이점이 있을까?

• throws는 예외 상황을 에러 타입으로 전달한다.
• Optional은 값이 없을 수도 있는 정상적인 흐름을 표현한다.

func getName() throws -> String?

이렇게 쓰면, "에러"와 "값 없음(nil)"을 명확히 구분할 수 있어서 더 유용한 경우가 많다.

compactMap은 그냥 map이랑 뭐가 다를까?

compactMap은 map의 기능 + nil 제거 기능이 붙어 있다. 즉, 변환을 하고 나서 nil은 제거하는 기능까지 포함이다.

let numbers = [1, 2, 3, 4]
let evenStrings = numbers.compactMap {
    $0 % 2 == 0 ? String($0) : nil
}
// 결과: ["2", "4"]

단순히 map만 쓰면 Optional이 남는데, compactMap은 그런 거 없이 깔끔하게 나온다.

AnyHashable은 언제 쓰는 걸까?

다양한 타입이 하나의 컬렉션(Set, Dictionary 등)에 있어야 할 때 사용한다. 단, 이 타입들은 전부 Hashable이어야 한다.

let items: Set<AnyHashable> = [1, "hi", true]

각 아이템의 원래 타입은 내부적으로 유지되지만, 외부에서는 AnyHashable로 동작한다.

Hashable, hash(into:), 그리고 ==

해시 기반 컬렉션(Set, Dictionary 등)을 쓰려면, 타입이 Hashable을 따라야 한다. 그럼 두 가지 필수 메서드가 생긴다.

hash(into:)

• 이건 해시값을 계산하는 메서드다.
• 보통 id 같은 고유값을 이용해서 구현한다.

==

• 두 객체가 같은지 비교할 때 기준이 되는 연산자다.

struct Person: Hashable {
    let id: UUID
    let name: String
    let age: Int

    func hash(into hasher: inout Hasher) {
        hasher.combine(id)
    }

    static func == (lhs: Person, rhs: Person) -> Bool {
        lhs.id == rhs.id
    }
}

switch에서 let을 꼭 써야 하는 이유

예를 들어 이런 코드가 있다고 하자.

switch result {
case .success(let value):
    print(value)
case .failure(let error):
    print(error)
}

여기서 let은 뭐냐면, case 패턴에서 값을 꺼내서 변수에 바인딩하는 역할이다. Swift는 명시적인 언어라서, 바인딩 여부도 확실하게 표시해줘야 한다.

그래서 case let .success(value)처럼 써도 된다. 같은 의미다.

[String: Any] 왜 이렇게 캐스팅할까?

딕셔너리에 여러 타입의 값이 섞여 있으면, Swift는 타입을 제대로 추론하지 못한다. 그래서 강제로 [String: Any]로 명시해주는 것이다.

let userInfo = [
    "name": "Foo",
    "age": 20,
    "address": [
        "line": "Dongjak",
        "postCode": "123"
    ]
] as [String: Any]

안 그러면 에러가 난다.

as? [String: String]은 어떤 상황에서 쓰지?

위에서 본 userInfo["address"]는 타입이 Any다. 근데 실제론 [String: String]이니까, 그걸 다시 안전하게 다운캐스팅해서 꺼내야 한다.

if let address = userInfo["address"] as? [String: String] {
    print(address["line"] ?? "")
}

안전하게 타입을 확인하고 꺼내는 데 필요한 문법이다.

핵심 한 줄 요약

간단하게 말해서 이거다.

Optional은 값이 있을 수도, 없을 수도 있는 타입이다.

Swift는 타입 안정성을 굉장히 중요하게 생각한다. 그래서 nil이라는 개념을 아무 변수에나 막 쓸 수 없다.

var name: String = nil       // 에러
var name: String? = nil      // 에러 안남

즉, nil을 쓸 수 있으려면 명시적으로 ?를 붙여서 옵셔널 타입이라고 선언해줘야 한다.

다른 언어에서는 어떻게 처리할까?

여기서 궁금한 게 하나 생긴다. 다른 언어들도 이런 옵셔널 개념이 있을까?

한번 비교해보자.

옵셔널이 아니면 nil을 절대 못 넣는다.

옵셔널 비교연산

var age: Int? = nil

if age == nil {
    print("age는 nil입니다")
}

물론 가능하다. == nil을 직접 비교하는 것도 된다. 하지만 Swift에서는 더 깔끔하고 안전한 방식인 **if let이나 guard let**을 권장한다.

if let vs guard let

옵셔널을 안전하게 꺼내 쓰는 대표적인 방식이 이 두 가지다.

if let

if let value = optional {
    // value 사용 가능
    print(value)
}
print(value) // 에러발생

조건이 true일 때만 실행된다. 하지만 블록 내부에서만 value를 쓸 수 있다는 단점이 있다.

guard let

guard let value = optional 
else {
    print(value)
    return
}
print(value)
// 여기부터는 value가 nil이 아닐경우  구분을 타게 되어이음

이건 다르다. 조건이 false일 때 탈출하기 때문에 이후 코드에서는 언래핑된 value를 계속 쓸 수 있다. 중첩 코드 없이 플랫하게 유지할 수 있어서 훨씬 가독성이 좋다.

옵셔널 체이닝

foo.address?.firstLine

옵셔널 체이닝은 중간의 어떤 값이 nil이라도 에러가 나지 않고, 전체가 nil이 되도록 안전하게 처리하는 방식이다.

예를 들어 아래와 같은 중첩된 구조를 생각해보자.

if let address = foo.address {
    if let line = address.firstLine {
        print(line)
    }
}

이걸 한 줄로 줄이면 다음과 같은 코드로 정리 할 수 있다.

if let line = foo.address?.firstLine {
    print(line)
}

엄청 깔끔해진다.

여러 개를 한 번에 바인딩하려면?

옵셔널 바인딩은 하나씩만 하는 게 아니다.

if let address = foo.address,            // 중간 값 바인딩
   let firstLine = address.firstLine {    // 최종 값 바인딩
    print(firstLine)    // 최종 값 사용가능
    print(address)        // 중간 값 사용가능
}

이렇게 ,로 이어서 순차적으로 바인딩할 수 있다. 중간 값을 쓰고 싶다면 이 방식이 유용하다. 옵셔널 체이닝은 결과만 얻을 수 있지만, 바인딩은 중간 값까지 활용 가능하다.

옵셔널의 내부 구조?

사실 옵셔널은 enum이다.

// optional 내부 구조
enum Optional<Wrapped> {
    case none           // == nil
    case some(Wrapped)  // 값이 있을 때
}

그래서 이런 코드도 완전히 가능하다.

switch age {
case .none:
    print("Age is nil")
case let .some(value):
    print("Age is \(value)")
}

즉, 옵셔널도 그냥 열거형일 뿐이다. 다만 Swift가 너무 잘 숨겨줘서 그런 줄 몰랐던 거다.

옵셔널을 선언할 때, 자료형 뒤에 ?를 붙여주는데 이건 optional자료형으로 wrapping하는 거라고 보면 된다.

guard lastName == nil else { ... }는 무슨 의미?

여기서 궁금한 게 또 하나 생긴다. 조건에 부정을 넣는 것도 가능할까?

guard lastName == nil else {
    // lastName이 nil일 경우 실행
    return
}
// nil이 아니면 실행

이건 lastName이 nil이 아니면 return, 즉 nil일 경우에만 계속 진행하겠다는 의미다.

guard는 결국 false일 때 탈출하는 거니까 조건을 부정으로 써도 전혀 문제없다.

한 줄 정리

옵셔널은 값이 있을 수도 없을 수도 있는 Swift만의 안전한 타입 시스템이며, 옵셔널 바인딩(if let, guard let), 체이닝, nil 병합(??) 등 다양한 방식으로 다룰 수 있다.

마무리하며....

옵셔널..... 자주 쓰이는 방식이니 잘 알아둬야겠다.

Swift에서 프로토콜, 제네릭, 그리고 확장(extension)이 섞인 코드를 보다 보면 뭔가 어려운 듯하면서도, 익숙한 듯하면서도… 이상하게 머리에 잘 안 들어온다. 나도 그랬다. 특히 associatedtype이 처음 등장했을 때는 대체 얘는 왜 필요한 건지부터가 궁금했다.

그럼, 처음부터 차근차근 짚어보자.

제네릭이란?

제네릭(Generic)은 “타입을 고정하지 않고, 나중에 사용할 때 결정하도록 만드는 프로그래밍 기법”이다. 예를 들어 Array<T>는 어떤 타입이든 저장할 수 있다. Array<Int>, Array<String>처럼.

Swift에서 제네릭은 다음과 같은 곳에 쓰인다.

func swapValues<T>(_ a: inout T, _ b: inout T) {
    let temp = a
    a = b
    b = temp
}

같은 로직을 여러 타입에 대해 재사용할 수 있게 해주니, 유연하고 타입 안정적인 코드를 만들 수 있다.

다음 코드를 봐보자. 역시 아무것도 모르는게 당연하다. 이 코드가 예제가 되어줄거다. (주석으로 달은건 무시해도 된다. 강의를 보면서 대충 이해한대로 적은 것이니....)

rotocol View {
    func addSubView(_ view: View)
}

extension View {
    func addSubView(_ view: View) {
    }
}

struct Button: View {}

protocol PresentableAsView {
    associatedtype ViewType: View // generic 역할
    func produceView() -> ViewType // ViewType을 지정해줄 애
    func configure(superView: View, thisView: ViewType)
    func present(view: ViewType, on superView: View)
}

extension PresentableAsView {
    func present(view: ViewType, on superView: View) {
        superView.addSubView(view) // 이건 잘 모르겠음
    }
}

struct MyButton: PresentableAsView { // MyButton 구조체를 만들어 줌
    func produceView() -> Button { Button() }   // 구현체로부터 받은 produceView를 Button()으로 초기화 여기서 ViewType 자동추론이 이루어진다.
    func configure(superView: View, thisView: Button) {} // 의미 없음
}

extension PresentableAsView where ViewType == Button { // Veiw타입이 Button하고 같으면 아래 함수를 실행
    func doSomethingWithButton() {
        "This is a button"
    }
}

let button = MyButton()
button.doSomethingWithButton()

그럼 여기서 궁금한 게 하나 생긴다.

Swift 프로토콜에서는 왜 직접 제네릭을 못 쓰고 associatedtype을 써야 할까?

associatedtype이란?

Swift에서는 프로토콜에 직접 <T> 같은 제네릭을 붙일 수 없다. 대신 associatedtype을 이용해서 추상적인 타입을 정의한다.

protocol PresentableAsView {
    associatedtype ViewType: View
}

이건 “이 프로토콜을 따르는 애는 ViewType이라는 타입을 나중에 정하게 될 건데, 그 타입은 최소한 View를 따라야 해”라는 뜻이다.

즉, 프로토콜은 타입을 알 수 없으니 대충 틀만 잡고, 실제 타입은 나중에 이 프로토콜을 채택하는 쪽에서 정해줘야 한다는 거다.

그럼 또 하나.

아래처럼 쓴 present(view: Button, ...)는 과연 프로토콜 요구사항을 만족할까?

extension PresentableAsView {
    func present(view: Button, on superView: View) {
        superView.addSubView(view)
    }
}

아니다 ❌ 이건 프로토콜에 정의된 func present(view: ViewType, on:)와는 다른 함수다. ViewType과 Button은 같은 타입이 아니기 때문이다. 이름만 같아 보여도, Swift는 타입까지 엄격하게 본다.

따라서 정확하게 구현하려면 이렇게 써야 한다:

extension PresentableAsView {
    func present(view: ViewType, on superView: View) {
        superView.addSubView(view)
    }
}

그럼 where ViewType == Button 조건은 언제 만족할까?

extension PresentableAsView where ViewType == Button {
    func doSomethingWithButton() {
        print("This is a button")
    }
}

이건 조건부 확장이다. 말 그대로, ViewType이 Button일 때만 저 확장이 붙는다.

그럼 ViewType은 언제 Button으로 정해질까?

struct MyButton: PresentableAsView {
    func produceView() -> Button { Button() } // 여기서 정해진다.
    func configure(superView: View, thisView: Button) {} // produceView()가 없었다면 여기서 정해졌을것이다.
}

여기서 Swift는 추론한다:

• produceView()의 반환값이 Button이니까 → ViewType = Button
• configure()도 thisView: Button이니까 → 역시 ViewType = Button

즉, 컴파일러는 "아 너 ViewType = Button이구나" 하고 알아서 추론해준다. 그래서 아래 같은 코드도 실행된다:

let my = MyButton()
my.doSomethingWithButton()

마지막 퍼즐 – produceView, configure, present는 왜 필요한가?

지금 당장 보기엔 아무 일도 안 하는 함수처럼 보일 수 있다. 하지만 이들은 설계상의 인터페이스 역할을 한다.

• produceView() → 뷰를 만들고
• configure() → 뷰를 설정하고
• present() → 부모 뷰에 뷰를 추가한다

이렇게 만들면 어떤 뷰 타입이 오든 같은 흐름으로 처리할 수 있다. → 매우 확장성과 재사용성이 높은 구조다.

요약 정리

마무리하며....

이 코드는 Swift 제네릭 프로그래밍, 프로토콜 중심 설계, 타입 추론, 조건부 확장의 정수가 다 들어 있는 예제다. 처음엔 헷갈릴 수밖에 없다. 하지만 흐름을 알고 나면, Swift가 왜 이렇게 설계되었는지 조금씩 이해가 간다.

그리고 이제 나도 이렇게 말할 수 있다: associatedtype은 프로토콜 속 제네릭이다.

프로토콜(Protocol)이란?

먼저 정의부터 확실하게 짚고 가자.

Protocol은 어떤 속성이나 메서드가 필요하다는 ‘규약’을 정리해놓은 것이다. 쉽게 말하면 "이걸 따르는 타입은 이 기능을 반드시 구현해야 해!" 라는 일종의 계약서 같은 느낌이다. 자바로 치면 인터페이스 역할을 하는 친구라고 보면된다.

protocol Greetable {
    var name: String { get }
    func greet()
}

이걸 보면, name이라는 속성이 있어야 하고, greet()라는 메서드도 구현해야 한다.

프로토콜로 인스턴스를 만들 수 있을까?

let someone = Greetable() // 응 안됨.

에러가 난다. 왜냐하면 프로토콜은 구현체가 아니라 설계도이기 때문이다. 직접 쓸 수 없고, 반드시 해당 프로토콜을 "채택한" 타입(예: struct, class)을 통해서 사용해야 한다.

struct Human: Greetable {
    var name: String
    func greet() {
        print("Hello, \(name)")
    }
}

let tom = Human(name: "Tom")
tom.greet() // Hello, Tom

extension?

Swift에서는 기존 타입에 기능을 붙일 수 있다. 이게 바로 extension(확장)이다.

extension Int {
    func squared() -> Int {
        return self * self
    }
}

이제 5.squared() => 25가 출력된다.

프로토콜에도 extension을 쓸 수 있다.

protocol CanJump {
    func jump()
}
extension CanJump {
    func jump() {
        print("Jumping...")
    }
}

만약 어떤 타입이 CanJump만 채택하고 jump()를 직접 구현하지 않으면? → extension에 있는 기본 구현이 자동으로 사용된다.

struct Cat: CanJump {}
Cat().jump() // Jumping...

프로토콜 속성에 { get }, { get set }이 붙는 이유는?

이건 처음 보면 문법이 헷갈릴 수 있다.

protocol HasName {
    var name: String { get }
    var age: Int { get set }
}

• { get }: 읽기만 가능 (let이나 var 모두 OK)
• { get set }: 읽기 + 쓰기 (→ 반드시 var만 가능)

예를 들어서 이렇게 구현할 수 있다.

struct Person: HasName {
    let name: String   // 읽기 전용
    var age: Int       // 읽고 쓸 수 있음
}

자바에서 생각하면 getter와 setter를 생각하면 쉬울듯하다...

그럼 private(set)과 뭐가 다를까?

또 헷갈릴 수 있는 게 private(set)이다.

struct User {
    private(set) var name: String
}

이건 외부에서는 읽기만 가능하지만 내부에서는 수정 가능하다.

결국 목적은 비슷하지만, 프로토콜은 ‘요구 조건’, 구조체는 ‘접근 제어’ 관점인 거다.

Any, is, as?는 언제 써야 할까?

여기서 타입 캐스팅 개념으로 넘어가 보자.

func describe(obj: Any) {
    if obj is Vehicle {
        print("obj conforms to Vehicle")
    } else {
        print("nope")
    }
}

• Any: 모든 타입을 받을 수 있다. (Int, String, Struct, Class 기타 등등...., 자바에서 Object클래스와 비슷한 개념)
• is: 런타임에 타입이 맞는지 체크 (java에서 instance of 와 비슷한 개념)

그럼 as?는 뭘까?

if let vehicle = obj as? Vehicle {
    vehicle.increaseSpeed(by: 10)
}

여기서 as?는 조건부 타입 캐스팅이다.

🧠 그런데 구조체에서 as? 썼더니 왜 값이 안 바뀔까?

struct Car: Vehicle {
    var speed = 0
    mutating func increaseSpeed(by amount: Int) {
        speed += amount
    }
}

let car = Car()
increaseSpeedIfVehicle(obj: car)

print(car.speed) // 0

헷갈릴 수 있다. 분명 increaseSpeed 했는데 왜 0이지?

→ Swift의 struct는 값 타입이다. 즉, obj as? Vehicle에서 복사본이 넘어가기 때문에, 원래 car는 그대로인 것이다.

• 해결하려면 class를 쓰거나
• inout 매개변수로 직접 전달해야 한다.

정리

Swift는 한 번 이해하면 정말 강력한 문법들이 많은 언어다. 궁금한 게 생기면 또 정리해서 기록해봐야겠다.

class란?

Swift에서 class는 참조 타입(reference type)이다. 같은 인스턴스를 여러 변수가 공유할 수 있고, 값이 바뀌면 모든 참조가 영향을 받는다.

class Person {
    var name: String
    var age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }

    func sayHello() {
        print("Hello, my name is \(name)")
    }
}

그럼 여기서 궁금한 게 하나 생긴다. 값을 비교하고 싶을 때는 어떻게 해야 할까? 클래스는 참조 타입인데, ==만 써도 되는 걸까?

== vs === (값 비교와 참조 비교)

• ==는 값을 비교하는 연산자다. Equatable 프로토콜을 따르지 않으면 쓸 수 없다.
• ===는 클래스 인스턴스가 동일한 객체인지 비교한다. 즉, 주소값 비교한다.

class Dog {
    var name: String
    init(name: String) { self.name = name }
}

let a = Dog(name: "Buddy")
let b = Dog(name: "Buddy")
let c = a

print(a === b) // false
print(a === c) // true

쉽게 말하자면, ==는 값이 같냐를 보는 것이고, ===는 같은 물건이냐를 보는 것이다.

private(set)은 왜 쓸까?

Swift에서는 변수에 private(set)을 붙일 수 있다. 읽을 수는 있지만, 바깥에서는 수정할 수 없다.

class Person {
    private(set) var age: Int

    init(age: Int) {
        self.age = age
    }

    func growOlder() {
        age += 1
    }
}

그럼 왜 이렇게 만들까? 캡슐화 때문이다. 외부에서는 값이 어떻게 바뀌는지 알 필요 없고, 내부에서만 규칙적으로 바뀌게 하고 싶을 때 사용한다.

convenience init이란?

보통 클래스에 여러 종류의 초기화 방법이 필요할 때가 있다. 이럴 때 보조 생성자 역할을 하는 게 convenience init이다.

class Car {
    var manufacturer: String = "Tesla"
    var model: String
    var year: Int

    init(model: String, year: Int) {
        self.model = model
        self.year = year
    }

    convenience init(model: String) {
        self.init(model: model, year: 2025)
    }

    func startEngine() {
        print("start Engine.")
    }

    func drive() {
        print("I'm driving.")
    }
}

근데 여기서 또 질문이 생긴다. 그냥 init 여러 개 만들면 되는 거 아닌가?

init 오버로딩 vs convenience init

물론 Swift도 init 오버로딩이 가능하다. 그치만 중복 코드가 생긴다.

init(model: String) {
    self.model = model
    self.year = 2025
    startEngine()
    drive()
}

init(model: String, year: Int) {
    self.model = model
    self.year = year
    startEngine()
    drive()

}
// startEngine과 drive의 함수의 중복코드 발생!

반면 convenience init을 쓰면 중복 없이 기존 init을 재활용할 수 있다.

convenience init(model: String) {
    self.init(model: model, year: 2025)
    startEngine()
    drive()
}

결국, 편리하고 중복 없는 초기화를 위해 convenience init이 존재하는 것이다.

그럼 자식 클래스에서 super.init()은 어떻게 써야 할까?

아래 코드는 에러가 난다.

class TeslaY: Car {
    override init() {
        super.init(model: "Y") // 에러
    }
}

왜냐면 부모의 convenience init은 자식에서 super.init로 호출할 수 없다.

해결하려면 반드시 지정 생성자를 호출해야 한다.

override init() {
    super.init(model: "Y", year: 2025) // OK!
}

Swift는 상속 구조에서 초기화를 명확하게 통제한다. super.init()은 꼭 지정 생성자만 호출할 수 있다. 보조 생성자는 내부에서 self.init()로만 호출 가능하다.

deinit은 언제 호출될까?

deinit은 클래스 인스턴스가 메모리에서 해제될 때 자동으로 호출된다.

class MyClass {
    init() {
        print("Initialized")
    }

    func doSomething() {}

    deinit {
        print("Deinitialized")
    }
}

예를 들어 이런 코드가 있다면?

let myClosure = {
    let obj = MyClass()
    obj.doSomething()
}
myClosure()

// 출력:
// Initialized
// Deinitialized

클로저 블록이 끝나면서 obj의 참조 카운트가 0이 되고, 그 순간 deinit이 호출된다.

이게 바로 ARC (Automatic Reference Counting)의 힘이다. Swift는 메모리를 자동으로 관리해준다. 단, 순환 참조는 주의해야한다.

마무리 한 줄 요약

Swift에서 class를 제대로 이해하려면 참조 타입의 특성과 ARC를 잘 알아야 한다. 그리고 생성자와 소멸자의 규칙도 깔끔하게 정리해두면 실전에서 훨씬 유연하게 대응할 수 있다.

필요하면 다음 포스팅에서 required init, weak/unowned, 순환 참조 방지도 다뤄보자!

enum은 한정된 값의 집합을 표현하는 타입이다. 예를 들어, 동물의 종류처럼 "정해진 선택지"를 다룰 때 쓰기 좋다.

enum Animals {
    case cat
    case dog
    case rabbit
}

이렇게 Animals.cat처럼 쓰면, 이것 자체가 enum 타입의 값이 된다. 출력하면 "cat"처럼 보일 수도 있지만, 실제로는 문자열이 아니다.

그럼 여기서 궁금한 게 하나 생긴다.

문자열처럼 출력하고 싶으면 어떻게 하지?

그럴 땐 RawRepresentable을 활용하면 된다. 뒤에 붙는거는 프로토콜인데 이건 스웨덴 형님이 나중에 알려주신다고 참고만 하시란다. (지금은 클로저 후유증이 좀 남아있으니 더 안파고 넘어가보겠다.)

enum Animals: String {
    case cat, dog, rabbit
}

print(Animals.cat.rawValue)  // "cat"

2. enum을 언제 쓸까?

정해진 상태나 선택지를 표현하고 싶을 때 enum이 제격이다.

예를 들어:

• 로그인 상태: .loggedIn, .loggedOut
• 네트워크 상태: .loading, .success(data), .failure(error)
• 방향: .left, .right

왜 좋냐면 switch문과 찰떡*이고, 연관 값을 붙여서 다양한 상태를 *안전하게 표현할 수 있기 때문이다.

3. enum에서 == 비교가 안 되는 이유는?

enum Shortcut {
    case fileOrFolder(path: URL, name: String)
    case wwwUrl(path: URL)
}

let a = Shortcut.wwwUrl(path: URL(string: "https://apple.com")!)

if a == Shortcut.wwwUrl(path: URL(string: "https://apple.com")!) {
    // Error 발생
}

왜 안 될까?

바로, 연관 값이 있는 enum은 자동으로 Equatable을 채택하지 않기 때문이다.

해결 방법:

enum Shortcut: Equatable {
    case fileOrFolder(path: URL, name: String)
    case wwwUrl(path: URL)
}

4. 그럼 switch는 왜 잘 작동할까?

switch a {
case .wwwUrl(let path):
    print(path)
default:
    break
}

switch는 패턴 매칭 기반이라, Equatable이 없어도 내부 case 구조를 직접 분해해서 비교한다. 즉, == 연산이 아니라 구조 자체를 비교하는 방식이다. ==는 값을 비교하는거라고 한다면 switch같은 경우에는, 값이 특정 구조, 모양, 조건을 만족하는지 검사하는 방식

5. if case let 문법

if case let .wwwUrl(path) = a {
    print(path)
}

// 이거랑 똑같다고 보면 된다
switch a {
    case let .wwwUrl(path):
        print(path)
        break
    defualt:
        "somthing else..."
}

이건 switch를 줄여 쓴 문법이다. 특정 케이스만 확인하고, 연관 값도 꺼내고 싶을 때 아주 편리하다.

비슷하게 guard case, for case, while case도 쓸 수 있다.

6. 재귀 enum이란? indirect?

이게 조금 난이도 있는 부분이다.

indirect enum IntOperation {
    case add(Int, Int)
    case subtract(Int, Int)
    case freeHand(IntOperation)
}

여기서 freeHand는 다시 IntOperation을 포함하고 있다. 이건 재귀 구조인데, Swift의 enum은 값 타입이라 스스로를 가질 수 없다. 그래서 indirect 키워드를 써서 힙에 저장되도록 한다.

7. 재귀 enum을 이용한 계산 예제

indirect enum IntOperation {
    case add(Int, Int)
    case subtract(Int, Int)
    case freeHand(IntOperation)

    func calculateResult(
        of operation: IntOperation? = nil
    ) -> Int {
        switch operation ?? self {
        case let .add(lhs, rhs):
            return lhs + rhs
        case let .subtract(lhs, rhs):
            return lhs + rhs
        case let .freeHand(operation):
            return calculateResult(of: operation)
        }
    }
}

여기서 핵심은 operation ?? self다. 함수 호출 시 매개변수가 없으면 self를 쓰는 구조다. 즉, 이런 식으로도 가능하다:

let freeHand = IntOperation.freeHand(.add(20, 30))
freeHand.calculateResult()  // 50

8. 그럼 struct와의 차이는 뭐야?

한 줄 정리

enum은 상태를 표현하고, struct는 데이터를 담는다.

그래서 오늘은 Swift의 구조체에 대해 차근차근 정리해보려 한다.

구조체?

struct Person {
    let name: String
    let age: Int
}

let foo = Person(name: "Foo", age: 20)

Swift의 구조체는 내부에 저장된 속성들을 기준으로 자동으로 생성자(init)를 만들어준다. 이런 걸 멤버와이즈 이니셜라이저라고 부른다.

즉, 따로 init 안 만들어도 이렇게 Person(name:age:)처럼 바로 만들 수 있다는 얘기다.

그럼 언제 사용자 정의 init이 필요할까?

struct CommodoreComputer {
    let name: String
    let manufacturer: String

    init(name: String) {
        self.name = name
        self.manufacturer = "Commodore"
    }
}

여기서 궁금한 게 하나 생긴다. "기본 생성자도 있는데 굳이 init을 왜 만들지?"

그 이유는 manufacturer처럼 내부에서 고정 값을 넣고 싶을 때! 외부에서 굳이 넣을 필요 없는 값을 내부에서 세팅해줄 수 있어서다.

기본값을 활용하면 더 간단해진다

struct CommodoreComputer2 {
    let name: String
    let manufacturer = "Commodore"
}

이렇게 속성에 기본값을 주면? Swift는 알아서 생성자를 만들어준다. 그래서 CommodoreComputer2(name:)만 있어도 된다.

fullName을 계산해주는 두 가지 방식

struct Person2 {
    let firstName: String
    let lastName: String
    let fullName: String

    init(firstName: String, lastName: String) {
        self.firstName = firstName
        self.lastName = lastName
        self.fullName = "\(firstName) \(lastName)"
    }
}

이렇게 init에서 fullName을 지정해줄 수도 있지만, 사실 더 Swift스러운 방법은 따로 있다.

struct Person22 {
    let firstName: String
    let lastName: String

    var fullName: String {
        "\(firstName) \(lastName)"
    }
}

왜 이게 더 좋을까?

• fullName은 실제로 저장된 값이 아니라 계산 가능한 값이다.
• 이렇게 하면 속성이 바뀌더라도 항상 최신 상태를 유지할 수 있다.

구조체 내부 값을 바꾸고 싶다면? → mutating

struct Car {
    var currentSpeed: Int

    mutating func drive(speed: Int) {
        currentSpeed = speed
    }
}

여기서 궁금한 점. "왜 굳이 mutating이라는 키워드가 필요한 걸까?"

그 이유는 구조체는 값 타입이라 내부에서 값을 바꾸려면 스스로를 다시 바꿔야 하기 때문. 그래서 명시적으로 mutating을 붙여줘야 한다.

// currentSpeed가 let이면 당연히 안바뀜.
var car = Car(currentSpeed: 100)
car.drive(speed: 300)

구조체는 복사된다 (값 타입 특징)

let copy = car
car.drive(speed: 500)
print(copy.currentSpeed)  // 300

이 예제를 보면 명확하다. copy는 car를 복사한 값이라, 이후 car가 바뀌어도 copy는 그대로다.

구조체는 상속이 안 된다

struct LivingThing {
    init() {
        print("I'm living thing")
    }
}

// 에러 발생: 구조체는 상속이 안 된다
// struct Animal: LivingThing { }

이쯤에서 이런 의문이 생긴다. "왜 struct는 상속이 안 되는 거지?"

Swift는 컴포지션(구성)을 더 중요하게 본다. 클래스처럼 복잡하게 상속보단, 작은 구조체들을 조립해서 쓰는 걸 더 선호한다. 그래서 swiftUI 잠깐 배웠을 때, 데이터는 struct. 데이터를 제어하는건 class를 사용한다고 들었던거같다.

copy 메서드 패턴으로 새 인스턴스 만들기

struct Bike {
    let manufacturer: String
    let currentSpeed: Int

    func copy(currentSpeed: Int) -> Bike {
        Bike(manufacturer: self.manufacturer, currentSpeed: currentSpeed)
    }
}

값 타입에서 가장 많이 쓰이는 패턴 중 하나가 바로 이거다.

기존 값을 유지하면서 일부 속성만 바꾼 새로운 인스턴스를 만들고 싶을 때 유용하다.

let bike1 = Bike(manufacturer: "HD", currentSpeed: 20)
let bike2 = bike1.copy(currentSpeed: 30)

다른 방법도 있다.

struct Bike {
    let manufacturer: String
    let currentSpeed: int

    mutating func moveToOrigin() {
        // 이런식으로 작성하면 self 전체를 다른 값으로 통째로 바꾸는 것도 가능.
        self = Point(manufacturer: "YD", currentSpeed: 30)
    }
}

정리하자면

• 구조체는 값 타입이고 상속 불가
• 생성자는 자동으로 만들어지지만, 필요에 따라 init 정의 가능
• 계산 속성(computed property) 활용은 코드 간결성과 최신 상태 유지에 좋다
• 내부 값 수정은 mutating 키워드로 명시
• 복사(copy) 패턴은 상태 변경을 안전하게 다룰 수 있는 방법

한 줄 요약

Swift의 struct는 값 기반 프로그래밍을 위한 핵심 도구다.

불변성, 복사, 컴포지션을 잘 이해하고 쓰면, Swift가 훨씬 더 명확하고 안전한 언어로 다가온다.

클로저란?

클로저는 이름 없는 함수이다. 그리고 이 함수는 변수처럼 저장하거나, 함수의 인자로 전달하거나, 함수에서 리턴할 수도 있다.

Swift에서는 아래처럼 쓴다:

let greet = {
    print("안녕하세요")
}
greet()  // 출력: 안녕하세요

그럼 여기서 궁금한 게 하나 생긴다. "굳이 이렇게까지 해야 돼? 그냥 함수 쓰면 되는 거 아니야?"

클로저를 왜 써야 할까?

클로저는 실전에서 정말 많이 쓰인다. 그 이유는 이렇다.

• 콜백 전달
  • 네트워크 요청 끝났을 때, 애니메이션 완료 시 등등
• 상태 유지
  • 외부 변수 캡처해서 값 기억 가능 (→ 클로저 캡처)
• 코드 간결
  • 짧고 일회성 로직에 딱 좋음
• 지연 실행
  • 필요할 때만 실행되도록 할 수 있음

예를 들어 이런 함수가 있다고 하자.

func makeCounter() -> () -> Int {
    var count = 0
    return {
        count += 1
        return count
    }
}

이건 count라는 값을 내부에서 유지하면서 점점 늘려주는 클로저를 리턴한다.

let counter = makeCounter()
counter()  // 1
counter()  // 2

이처럼 클로저는 함수 이상의 역할을 할 수 있다. ‘기억하는 함수’라고 생각하면 된다.

클로저를 어떻게 쓸까?

Swift에서 클로저는 여러 방식으로 정의할 수 있다. (예시를 쭉 보면 감이 올지도.......?)

예를 들어 이런 식으로도 쓸 수 있다:

func perform(action: () -> Void) {
    action()
}

perform {
    print("실행됨!")
}

→ 이런 방식은 trailing closure 문법이라고 부른다. 가독성이 훨씬 좋다.

클로저 예제 모음

함수에서 클로저 반환

func makeAdder(_ x: Int) -> (Int) -> Int {
    return { y in x + y }
}

let add5 = makeAdder(5)
add5(3)  // 결과: 8

고차 함수 사용

let nums = [1, 2, 3]
let squared = nums.map { $0 * $0 }  // [1, 4, 9]

@escaping 사용 예시

func asyncTask(completion: @escaping () -> Void) {
    DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
        completion()
    }
}

→ 비동기에서 나중에 클로저를 실행해야 하니 @escaping을 붙여줘야 한다.

정리 한 줄 요약

클로저는 이름 없는 함수로, 콜백 전달이나 상태 유지, 코드 축약 등에 매우 유용하다. Swift에서는 클로저 문법이 매우 강력하고 다양하기 때문에 map, filter, sorted 같은 고차 함수에서도 자주 활용된다.

• JS의 () => {}, Python의 lambda, Java의 () -> {}와 개념적으로 비슷하다.
• 하지만 Swift는 타입 안정성과 캡처 기능이 더 강력하다.
• 단, 클로저가 변수/상수를 캡처하다가 메모리 누수(참조 순환)가 생길 수 있으니 [weak self] 같은 문법도 꼭 알아두자.

그래서 오늘은 함수 관련해서 헷갈릴만한 포인트를 쫙 정리해봤다. 나중에 블로그 다시 보면서 기억도 되살릴 겸 써놓는 기록이다.

리턴이 있는 함수

Swift에서 리턴이 없으면 그냥 Void다. 정확히 말하면 Void == () 빈 튜플이다.

func sayHello(name: String) {
    print("Hello, \(name)!")
}

이 함수는 아무것도 안 돌려준다. 그냥 출력만 하고 끝. 그럼 여기서 궁금한 게 하나 생긴다.

리턴이 있어야 좋은 함수일까?

결론은 그때마다 다르다. 값을 밖으로 전달할 필요가 있으면 -> 타입을 명시하고 return을 써주면 된다.

func plusTwo(value: Int) -> Int {
    return value + 2
}

이건 명확히 Int를 돌려주는 함수. 이렇게 어떤 타입을 리턴받는지 확인하기 좋다.

리턴이 없는 함수 (생략이 가능함)

Swift에서는 한 줄짜리 계산식이면 return을 생략할 수 있다.

func plus(_ a: Int, _ b: Int) -> Int {
    a + b
}

이런 식으로 간단한 함수는 깔끔하게 쓸 수 있다. 그런데 여러 줄이 된다면 무조건 return을 명시해야 한다.

func plus(_ a: Int, _ b: Int) -> Int {
    let result = a + b
    return result
}

한 줄이면 생략, 두 줄 이상이면 return 꼭 써줘야 된다.
그런데.... 이런 식으로 리턴은 했는데 타입을 안 썼다?

func wrongReturn(value: Int) {
    return value + 2 // ❌ 오류
}

에러가 난다. 왜냐면 Void 함수는 값을 돌려줄 수 없기 때문. 리턴할 거면 타입도 꼭 같이 써야 한다.

리턴값 안 써도 되게 해주는 어노테이션

@discardableResult라는 게 있다. 이건 뭐냐면, 리턴값을 무시해도 경고 안 뜨게 해주는 키워드다. 쉽게 말해서 리턴값이 있지만, 쓰이지 않았다는 경고를 무시하기 위한 어노테이션이라고 보면된다.

@discardableResult
func logAction(_ message: String) -> Bool {
    print("LOG: \(message)")
    return true
}

Swift에서는 안정성과 명확성을 중요시하기 때문에 리턴을 무시할 때도 명시적으로 작성해줘야 된단다...

파라미터 앞에 _

func add(_ a: Int, _ b: Int) -> Int {
    a + b
}

이런 식으로 _를 붙이면 호출할 때 외부 파라미터 이름을 생략할 수 있다.

add(3, 5) // 깔끔하게 호출 가능

반면, 이건 좀 다르다

func addNumbers(a: Int, b: Int) -> Int {
    a + b
}

addNumbers(a: 3, b: 5) // 외부 이름 붙여야 함

즉, _는 외부 이름 생략하겠다는 선언이다.

함수 안에 함수

Swift는 중첩 함수(nested function)도 가능하다.

func complicatedStuff(with value: Int) -> Int {
    func subLogic(value: Int) -> Int {
        value + 2
    }
    return subLogic(value: value + 3)
}

여기서 subLogic은 complicatedStuff 안에서만 쓸 수 있다. 이걸 잘 쓰면 복잡한 로직을 깔끔하게 나눌 수 있다. 설명해줄 때 클로저랑 비슷하다는데.... 클로저는 다음 시간에 가르쳐준단다. 기다려보자.

with, by, from은 왜 붙이는 거지?

func fetchUserData(
    with id: Int,
    by your: String, 
    from me: String) { ... }

이런식으로 쓰는 것은 js, pyhon, java에서는 못보던 형태일 것이다. with, by, from 등은 그냥 외부 파라미터 이름일 뿐이다. 반대로 id, your, me는 내부 파라미터 이름이다.

코드 외부에서 파라미터 넣을 때는 with, by, from를 사용해 주지만,

fetchUserData(with: 123) // 외부에서 파라미터 넣을 경우

내부에서 사용할 때는 id, your, me를 사용해준다.

func fetchUserData(
    with id: Int,
    by your: String, 
    from me: String) -> Int {
        retrun "\(your)" + "\(me)" // 내부에서 파라미터를 사용할 경우
    }

생략하고 싶으면 _를 쓰면 된다.

Swift를 쓰다 보면 NSArray나 NSMutableArray 같은 Objective-C 기반 클래스를 만날 때가 있다. 특히 다른 프레임워크나 레거시 코드랑 연동할 때 자주 보이는데…

func changeTheArray(_ array: NSArray) {
    let copy = array as! NSMutableArray
}

이런 코드 보면 한 가지 궁금증이 생긴다.

NSArray 타입인데 왜 NSMutableArray로 바꿀 수 있는 걸까?

사실 Swift에서 NSArray는 "불변" 배열이고, NSMutableArray는 "가변" 배열이다.

근데 이 둘은 클래스 계층상 관계가 있다. NSMutableArray는 NSArray의 하위 클래스다.

즉, NSMutableArray는 자동으로 NSArray로 업캐스팅되고, 필요하면 다시 as!나 as?를 써서 다운캐스팅할 수 있는 거다.

그럼 실제로 동작은 어떻게 될까?

이 코드를 보자.

let someNames = NSMutableArray(array: ["Foo", "Bar"])

func changeTheArray(_ array: NSArray) {
    let copy = array as! NSMutableArray
    copy.add("Baz")
}

changeTheArray(someNames)
print(someNames) // ["Foo", "Bar", "Baz"]

여기서 핵심은 이거다: 함수 인자는 NSArray지만 실제 객체는 NSMutableArray이기 때문에 캐스팅이 가능하다.

그리고 중요한 사실 하나! NSMutableArray는 참조 타입이라, 함수 내부에서 추가한 값이 밖에서도 반영된다.

추가로 강의 가르쳐준 스웨덴 유튜버는 이렇게 타입을 강제로 바꿔서 쓰는 것은 매우 위험하다고한다.

마지막으로 정리하면 이렇게 된다.

1. NSArray는 불변 배열이고, NSMutableArray는 그 하위 클래스인 가변 배열이다.
2. 함수에서 NSArray로 받아도, 실제로는 NSMutableArray일 수 있으니 as!로 다운캐스팅이 가능하다.
3. NSMutableArray는 참조 타입이라 내부 값을 바꾸면 원본도 바뀐다.
4. let으로 선언해도 인스턴스 내부 수정은 막지 않는다.

한 줄 요약

NSMutableArray는 NSArray로 업캐스팅되었다가 다운캐스팅으로 다시 가변 배열처럼 쓸 수 있다. 하지만 항상 타입 확인을 하고 안전하게 써야 한다.

let (data, _) = try! await URLSession.shared.data(from: url!)

이 한 줄에 !가 두 개나 들어간다. 근데 try! 이렇게 쓰는 방식은 권장은 안한다고 한다.

try! await URLSession.shared.data(from:) 이 한 줄이 뭘 의미할까?

이 코드의 동작을 찬찬히 뜯어보자.

• URLSession.shared.data(from:): 네트워크 요청을 보낸다.
• await: 네트워크 응답이 올 때까지 기다린다.
• try!: 오류가 나더라도 무시하고 실행한다.
• (data, _): 받은 응답 중 data만 쓰고, 메타정보는 무시한다.

그럼 여기서 궁금한 게 하나 생긴다. 왜 !를 이렇게 두 번이나 쓰는 걸까....

Swift에서 !는 두 가지 상황에서 자주 등장한다.

1. url!: 옵셔널 강제 해제

let url = URL(string: "https://example.com")!

URL(string:)은 옵셔널을 반환한다. 왜냐면 문자열이 진짜 URL일지 아닐지 알 수 없기 때문. 그래서 저렇게 !를 붙이면 "무조건 URL이 맞을 거야!" 하고 강제로 열어버린다.

근데 만약 문자열이 잘못돼서 nil이면 앱크래시 문구가 뜬다.

2. try!: 에러 강제 무시

let (data, _) = try! await URLSession.shared.data(from: url!)

이 함수는 실패할 수도 있다. 예를 들어 인터넷이 안 된다든가, URL이 잘못됐다든가.

그럴 때 보통은 try?나 do-catch를 써야 하는데, try!를 사용하게 되면 앱크래시가 발생하게 된다.

그럼 어떻게 처리하는 게 좋은 걸까?

테스트할 때는 try!, url!을 써도 괜찮다. 데이터가 무조건 있다는 걸 알고 있고, 빠르게 확인하고 싶을 때.

하지만 실서비스 앱이라면,

✅ guard let으로 URL 안전하게 열고 ✅ do-catch로 네트워크 요청 에러도 잡아줘야 한다. - gpt 피셜 -

Codable, Decodable, Encodable은 차이점?

네트워크 응답으로 JSON을 받았다면 그걸 모델 객체로 바꾸는 작업이 필요하다. 그때 사용하는 게 바로 이 세 가지 프로토콜이다.

예를 들어 이런 모델이 있다

struct Drama: Codable {
    let title: String
    let year: Int
}

근데 JSON 키가 year가 아니라 releaseYear라면?

enum CodingKeys: String, CodingKey {
    case title
    case year = "releaseYear"
}

이렇게 키 매핑을 해주면 된다. Swift에서는 구조체의 프로퍼티 이름과 JSON 키가 다르면 반드시 CodingKeys를 지정해줘야 제대로 파싱된다.

"주니어 iOS개발자로 취업을 하려면 어떤 기술과 역량이 필요할까?"

아주 중요한 질문입니다. iOS 개발자로 취업을 목표로 한다면, 단순히 "앱을 만들 수 있다" 수준을 넘어서서 개발 실력 + 협업 능력 + 실무 경험의 간접 증명이 중요합니다.

다음은 iOS 주니어 개발자가 취업을 위해 반드시 알아야 할 기술/지식을 실무 기준으로 정리한 것입니다.

✅ iOS 취업을 위한 필수 역량 정리

1. 기본 개발 역량

2. 실전 앱 구현 능력

3. 협업과 소통 역량

4. 기초 CS 및 면접 준비

5. 기타 (경쟁력 있는 항목)

🧠 정리: “취업용 iOS 개발 역량 3대 포인트”

1. UIKit 기반 앱 하나 이상 구현 + MVVM 구조화 가능
2. Swift 기반 문법과 메모리/비동기/구조화에 대한 기본 이해
3. 협업/문서화/형상관리/Git 경험 + Firebase 같은 외부 연동 경험

필요하시면 다음도 드릴 수 있어요:

• 주니어용 이력서/포트폴리오 구성 팁
• 실제 면접 질문 리스트
• 위 항목들을 기준으로 한 체크리스트 PDF

어떤 게 필요하신가요? 또는 지금 어느 정도까지 준비되셨는지도 알려주시면 맞춤형으로 안내드리겠습니다.

취미로만 하는것도 나쁘지 않을지도....ㅎ

SwiftData를 처음 써보면 정말 놀라는 포인트가 하나 있다. modelContext.save()를 호출하지 않았는데도 데이터가 저장되는 현상을 밝견했다.

문제를 발견한 코드는 다음과 같다.

struct TodoDetail: View {

    @Binding var todo: TodoList

    @Environment(\.modelContext) private var modelContext

        ...생략

        .padding()
        .navigationTitle("할 일을 작성하세요.")
        .toolbar{
            ToolbarItem{
                Button("저장") {
                    do {
                       // 주석처리 했음에도 불구하고, 저장이 된다.
                      // try modelContext.save()
                    }
                    catch {
                        print("Error Context Save: \(error)")
                    }

                }
            }
        }
    }
}
... 생략

SwiftData는 과연 언제, 어떤 조건에서 데이터를 자동 저장하는 걸까?

SwiftData는 자동 저장 기능을 갖고 있다.

SwiftData는 Core Data 위에 만들어진 새로운 추상화 계층이다. 그리고 SwiftUI와 찰떡같이 맞춰주기 위해 자동 저장 기능이 추가됐다. 그러니까 핵심은 이거다:

SwiftData는 특정 시점에 자동으로 데이터를 저장한다.

그럼 여기서 궁금한 게 하나 생긴다. 그 특정 시점이 언제냐는 거다.

언제 자동 저장이 될까?

SwiftData에서 자동 저장은 다음 조건에서 '발생할 수 있다'고 한다. 여기서 중요한 건 "항상 발생한다"가 아니라 "발생할 수 있다"라는 점이다.

딱 정리하자면, 자동 저장은 "뷰가 사라질 때" 가장 확실하게 일어난다. 그 외의 경우는 절대적으로 믿으면 안 된다. 앱이 종료되거나 메모리가 부족해지면 데이터가 날아갈 수도 있다.

그러면 왜 저장이 된 걸까?

내가 작성한 코드에서 modelContext.save()는 없었다. 근데 TextField와 TextEditor에 @Binding var todo: TodoList가 직접 연결돼 있었고, 이 상태에서 값을 입력하면 SwiftData의 ModelContext는 자동으로 변화(hasChanges)를 감지한다.

그리고 이 뷰가 pop되거나 dismiss되는 순간, SwiftData는 알아서 context.save()를 호출한다.

결국 이 말은, 자동 저장은 내가 뷰를 닫는 그 타이밍에 발생한 것이다.

자동 저장을 막고 수동 저장만 하고 싶다면?

이럴 땐 이렇게 하면 된다:

@State private var tempTitle: String = ""
@State private var tempDesc: String = ""

.onAppear {
    tempTitle = todo.title
    tempDesc = todo.todoDesc
}

Button("저장") {
    todo.title = tempTitle
    todo.todoDesc = tempDesc
    try? modelContext.save()
}

@Binding 대신 @State에 임시 값을 담아두고, 사용자가 직접 저장 버튼을 눌렀을 때만 모델을 수정하는 방식이다.

이러면 자동 저장을 피하고 내가 원하는 타이밍에만 저장할 수 있다. SwiftData를 제어하려면 이런 식으로 한 번 더 래핑해주는 게 좋다.

정리하자면

한 줄 요약: SwiftData는 뷰가 사라질 때 자동 저장이 일어난다. 하지만 그 외 상황은 보장되지 않으므로 수동 저장 흐름이 필요할 수 있다.

SwiftData가 정말 매력적인 이유는 SwiftUI와 자연스럽게 동작하기 때문이다. 하지만 반대로, 자동으로 너무 많은 걸 처리해줘서 개발자가 직접 제어하고 싶을 땐 조금 까다로워질 수도 있다.

필요하면 이 글을 기반으로 추가적인 실험 결과나 예제를 더 작성해도 좋겠다. 다음엔 @Model, @Query, 그리고 관계 설정 쪽도 정리해볼 예정이다.