SwiftUI로 앱을 만들다 보면, body에서 뷰를 반환할 때 종종 some View라는 표현을 보게 됩니다. some 은 도대체 뭘까요?
그리고 any, AnyView, @ViewBuilder는 언제 써야 할까요? 이에 대해 파헤쳐보았습니다!

Opaque Type이란

Opaque Type: 불투명 타입

한국말로는 불투명 타입이라고 하는데요, SwiftUI에서 some 키워드를 붙인 타입을 Opaque Type이라고 합니다!

struct BasicView: View {
    var body: some View {
        Text("Hello, World!")
            .bold()
            .background(.yellow)
            .foregroundStyle(.red)
            .padding()
            .background(.blue)
            .jack()
    }
}

• 보통 뷰를 만들면 기본적으로 body 프로퍼티의 타입이 some View 로 되어있는 걸 볼 수 있습니다.

위 코드를 보시면 Text에 여러 View Modifier가 체이닝 되어있는 걸 볼 수 있는데 어차피 body 연산 구문 내에 Text밖에 없는 거 some View 대신 Text 를 쓰면 안되는 걸까요? 왜 굳이 some 키워드를 붙여서 Opaque Type이라는 것을 사용하는 걸까요?

print(Mirror(reflecting: self).subjectType)

• 이걸 사용하면 런타임 시점에 어떤 타입인지 알 수 있습니다. 이걸로 Text의 타입을 확인해보면..

ModifiedContent<ModifiedContent<ModifiedContent<ModifiedContent<Text, _BackgroundStyleModifier<Color>>, _ForegroundStyleModifier<Color>>, _PaddingLayout>, _BackgroundStyleModifier<Color>>

결과는 이렇게 나옵니다.. View Modifier을 붙이면 붙이는 대로 죄다 타입명이 되고 제네릭의 제네릭의 제네릭이 되어.. 아주 길고 복잡하게 나옵니다..!

이걸 타입명으로 쓸 수는 있지만 그렇게 하기엔 너무 복잡하기 때문에 이런 복잡한 타입명을 숨기고자 사용하는 것이 some View (Opaque Type) 입니다!

Opaque Type의 성능 이점

Opaque Type은 타입을 숨긴다고 했는데 그건 개발자 눈에만 숨기고, 컴파일러에게는 아주 투명하게 잘 보입니다.

그래서 컴파일 시점에 타입이 확정되어 이는 정적 디스패치(static dispatch)로 동작할 수 있게 하기 때문에 최적화가 가능해집니다!

private func textButton() -> some View {
    VStack {
        Image(systemName: "star")
        Text("버튼")
    }
}

구현부에서 some View 를 반환하지만 이건 구체 타입을 반환하기 때문에 컴파일러가 그 타입을 정확히 알 수 있습니다.

제네릭과 달리 구현부에 구체적 타입이 들어가고 호출부를 추상화시키기 때문에 역제네릭이라고도 부릅니다.

Opaque Type (some)과 Existential Type (any)의 차이점

Swift에서는 some과 any 둘 다 프로토콜 타입을 표현할 때 사용되지만, 역할과 동작 방식이 완전히 다릅니다.

func getRandomView() -> any View {
    if Bool.random() {
        return Text("Hello")
    } else {
        return Button("Click me") {}
    }
}

any View는 Swift 5.7부터 도입된 존재 타입(existential type)을 명시적으로 표현하는 방식입니다. 이전에는 그냥 View라고 단순히 프로토콜 형태로 썼다면, 이제는 any View로 표현합니다.

이렇게 하면 컴파일러가 해당 타입이 동적 디스패치를 사용하는 존재 타입이라는 것을 명확하게 인식할 수 있게 됩니다!

존재 타입(existential type)

"해당 프로토콜을 준수하는 타입이 존재한다"라는 의미

Swift에서 프로토콜을 타입으로 사용할 때 생기는 개념으로, 반환 값이 특정 프로토콜을 준수한다는 사실만 보장하고 구체적인 타입은 숨기는 방식입니다.

실제 사용되는 구체 타입에 대해서는 런타임에 알 수 있어서 성능적으로 불리한 점이 있을 수 있습니다.

some - Opaque Type

• 반환 타입이 명확하고 고정된 단일 타입이라는 것을 컴파일러가 알고 있음.
• 정적 디스패치를 통해 성능이 향상됨.
• 뷰 구성 시 타입 안정성을 확보할 수 있음.

any - Existential Type

• 런타임까지 어떤 타입인지 정해지지 않음.
• 다양한 타입을 한 곳에서 다뤄야 할 때 사용하지만, 비용이 큼.
• 내부 구현은 동적 디스패치, 즉 런타임 타입 체크를 수반.

any를 도입하게 된 이유

아까 해당 타입이 동적 디스패치를 사용하는 존재 타입이라는 것을 명확하게 인식할 수 있기 때문이라고 했는데요, 좀 더 자세히 살펴보자면

1. Existential 타입의 명확한 표현

var view: View // Swift 5.6 이전
var view: any View

위 코드에서 view는 내부적으로 existential container로 처리되었습니다. 즉, 다양한 View 타입을 담을 수 있는 일종의 래퍼 타입인데, 컴파일 타임에는 구체 타입을 알 수 없습니다.

이러한 existential 타입 사용이 런타임 비용을 유발할 수 있다는 점, 그리고 일반적인 제네릭 타입과 구분되지 않는다는 점이 혼란을 일으켰습니다.

그래서 any 를 붙임으로써 구체 타입이 아닌 프로토콜을 타입으로 쓴다는 의미를 명확히 전달할 수 있습니다.

2. Generic vs Existential 혼란 방지

// Generic: 구체 타입은 컴파일 타임에 결정됨
func render<V: View>(_ view: V) { ... }

// Existential: 어떤 View든 담을 수 있음 (컴파일러는 내부 타입을 모름)
func render(_ view: any View) { ... }

과거에는 View만 써도 existential이었기 때문에 이 둘이 비슷해 보였지만, 실제로는 퍼포먼스와 타입 시스템에서 다르게 작동했습니다.

any 키워드는 이 차이를 명확히 보여주는 역할을 합니다.

3. 제약이 있는 프로토콜 사용에 대한 제한 인식

associatedtype이나 Self를 포함하는 프로토콜은 여전히 any를 붙여도 존재 타입으로 사용할 수 없습니다.

이런 프로토콜은 내부적으로 구체적인 타입이 결정되어야 하기 때문에, 컴파일러가 해당 타입을 추론할 수 없는 상황에서는 타입으로 사용할 수 없는 것이죠.

예를 들어 다음과 같은 프로토콜은 any를 붙여도 에러가 발생합니다:

protocol IdentifiableItem {
    associatedtype ID
    var id: ID { get }
}

let item: any IdentifiableItem // 컴파일 에러

Swift 5.7 이전에는 이런 제약으로 인해 헷갈리거나, 명확하지 않은 에러 메시지가 출력되는 경우도 있었습니다.

하지만 any 도입 이후에는 “이 프로토콜은 존재 타입으로 사용할 수 없다"는 걸 컴파일 타임에 확실하게 알려줍니다.

덕분에 개발자는 어떤 프로토콜이 제네릭으로만 사용 가능한지, 어떤 프로토콜이 존재 타입으로 쓸 수 있는지를 훨씬 직관적으로 구분할 수 있습니다.

any View vs AnyView

any View는 Swift 5.7 이후 등장한 새로운 타입 선언 방식이라면,
AnyView는 SwiftUI가 제공하는 타입 지우기(type-erasing) 구조체입니다.

// Swift 5.6 이전 방식 (타입 지우기)
var body: some View {
    AnyView(condition ? Text("A") : Image(systemName: "star"))
}

// Swift 5.7 이후 방식
func someFunc() -> any View {
    // ...
}

AnyView는 타입 정체성을 지우며, 다양한 구체적 타입들을 단일 타입으로 래핑합니다. AnyView 역시 런타임에 동작하여 성능이 떨어질 수 있습니다.

SwiftUI 코드 최적화하기

@ViewBuilder 활용

any View나 AnyView는 동적 View를 처리할 때 유용하지만, 성능 비용이 큽니다. 대신 @ViewBuilder 를 사용하면 타입 안정성과 성능을 유지할 수 있습니다.

@ViewBuilder
func conditionalView(_ condition: Bool) -> some View {
    if condition {
        Text("A")
    } else {
        Image(systemName: "star")
    }
}

@ViewBuilder는 컴파일러가 View 계층을 단일 some View로 통합하며, 정적 디스패치를 보장합니다.

struct ColorHStack<Content>: View where Content: View {
    
    let content: () -> Content
    let color: Color
    
    init(color: Color = .clear,
         @ViewBuilder content: @escaping () -> Content) {
        self.color = color
        self.content = content
    }

    var body: some View {
        HStack {
            content()
        }
        .background(color)
    }
}

struct ContentView: View {
                
    var body: some View {
        ColorHStack(color: .purple) {
            Text("Zedd")
            Text("Zedd")
        }
    }
}

이런식으로도 활용할 수 있습니다.

마무리

지금까지 SwiftUI의 Opaque Type 부터 some, any, AnyView, @ViewBuilder까지 알아보았는데요,

정리하자면 SwiftUI의 Opaque Type은 Swift의 정적 타입 시스템과 컴파일러 최적화의 핵심입니다.

some View는 컴파일 타임에 타입을 추론하여 성능과 안정성을 확보하고 개발자는 선언적 UI를 간결히 작성할 수 있게 합니다!

앞으로는 any 키워드로 존재 타입임을 명시하고 any, AnyView보단 @ViewBuilder로 최적화 하는 것을 추천드립니다.

읽어주셔서 감사합니다!