Swift의 some과 any 차이점

Swift의 some과 any는 둘 다 프로토콜을 다루는 키워드지만, 사용 목적과 동작 방식이 완전히 다릅니다.

some (Opaque Type)

"구체적인 타입은 숨기되, 컴파일러는 정확히 어떤 타입인지 알고 있다"

func makeView() -> some View {
    Text("Hello")  // 컴파일러는 이게 Text라는 걸 정확히 안다
}

특징

• 반환 타입이 항상 동일한 구체적 타입이어야 함
• 컴파일 타임에 타입이 결정됨 (성능 우수)
• SwiftUI에서 주로 사용 (some View)

제약 사항

// ❌ 에러: 반환 타입이 일관되지 않음
func makeView(condition: Bool) -> some View {
    if condition {
        return Text("Yes")     // Text 타입
    } else {
        return Image("photo")  // Image 타입 - 다른 타입!
    }
}

---

any (Existential Type)

"어떤 프로토콜을 따르는 타입이면 뭐든 OK, 런타임에 결정"

func makeView(condition: Bool) -> any View {
    if condition {
        return Text("Yes")     // ✅ OK
    } else {
        return Image("photo")  // ✅ OK - 둘 다 View 프로토콜 준수
    }
}

특징

• 다양한 구체적 타입을 담을 수 있음
• 런타임에 타입이 결정됨 (성능 오버헤드 있음)
• 유연성이 필요할 때 사용

활용 예시

let views: [any View] = [
    Text("Title"),
    Image(systemName: "star"),
    Button("Tap") { }
]  // ✅ 서로 다른 타입들을 배열에 담을 수 있음

---

핵심 차이점 비교

특성	some	any
타입 결정 시점	컴파일 타임	런타임
반환 타입 일관성	항상 동일해야 함	매번 달라도 됨
성능	빠름 (Static Dispatch)	약간 느림 (Dynamic Dispatch)
주요 사용처	단일 타입 반환	다형성 필요시
타입 정보	컴파일러가 정확히 앎	런타임에만 확인 가능

---

실전 예제

some 사용 - SwiftUI body

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Title")
            Image("logo")
        }
        // body는 항상 같은 뷰 구조를 반환
    }
}

any 사용 - 다양한 타입의 컬렉션

// 여러 종류의 애니메이션을 배열로 관리
let animations: [any Animation] = [
    .easeIn,
    .spring(response: 0.3),
    .linear(duration: 1.0)
]

// 다양한 Shape를 담는 배열
let shapes: [any Shape] = [
    Circle(),
    Rectangle(),
    RoundedRectangle(cornerRadius: 10)
]

---

언제 무엇을 사용할까?

some을 사용하는 경우

• SwiftUI의 body 프로퍼티
• 함수가 항상 같은 타입을 반환할 때
• 성능이 중요한 경우
• 타입 추론의 이점을 활용하고 싶을 때

any를 사용하는 경우

• 여러 다른 타입을 하나의 컬렉션에 담아야 할 때
• 조건에 따라 다른 타입을 반환해야 할 때
• 런타임에 타입이 결정되어야 하는 경우
• 유연성이 성능보다 중요한 경우

---

결론

some은 "성능과 타입 안정성"이 중요할 때, any는 "유연성"이 필요할 때 사용합니다.

• SwiftUI는 대부분 some View를 사용
• 컬렉션에 여러 타입을 담아야 할 때만 any를 고려
• 성능이 중요한 앱에서는 가능한 some 사용을 우선

Swift 5.7부터 any 키워드가 명시적으로 필요하게 되어, 코드의 의도가 더 명확해졌습니다.