Publisher 깊게 보기
Publisher의 종류 한눈에 보기
Combine에서 쓰는 Publisher는 크게 세 부류로 나뉨.
분류 예시 특징
| 기본 제공 Publisher | Just, Empty, Fail, Future, Deferred | 한 번 정의되면 값이 정해져 있음 |
| 외부 이벤트 Publisher | URLSession.dataTaskPublisher, NotificationCenter.Publisher, Timer.publish | 시스템 이벤트에서 값이 흘러나옴 |
| 수동 발행 Publisher | PassthroughSubject, CurrentValueSubject, @Published | 코드에서 send()로 값을 직접 주입 |
Apple이 기본 제공하는 Publisher들
Just — 값 하나 내보내고 끝
let publisher = Just("Hello")
// Output: String, Failure: Never
publisher.sink { print($0) } // "Hello"
테스트 코드나 기본값 제공할 때 자주 씀. 절대 실패하지 않는다(Failure: Never) 는 점이 핵심.
Empty — 아무 값도 안 내보내고 완료
let publisher = Empty<String, Never>()
publisher.sink(
receiveCompletion: { _ in print("완료") },
receiveValue: { _ in print("값 없음") }
)
// "완료"
조건에 따라 "아무것도 안 하기" 분기를 만들 때 유용함. 예를 들어 flatMap 안에서 특정 조건일 때 빈 스트림으로 처리.
Fail — 에러를 내보내고 종료
enum MyError: Error { case somethingWrong }
let publisher = Fail<String, MyError>(error: .somethingWrong)
publisher.sink(
receiveCompletion: { completion in
if case .failure(let error) = completion {
print("에러: \\(error)")
}
},
receiveValue: { _ in }
)
// "에러: somethingWrong"
분기 처리에서 "이 경우엔 에러로 처리" 라고 명시할 때 사용.
Future — 비동기 작업 한 번 → 값 하나
func loadUser(id: String) -> Future<User, Error> {
Future { promise in
API.fetchUser(id: id) { result in
switch result {
case .success(let user):
promise(.success(user))
case .failure(let error):
promise(.failure(error))
}
}
}
}
기존 Completion Handler 기반 API를 Combine으로 감싸는 가장 흔한 방법.
주의 : Future는 생성되는 순간 즉시 실행됨. 구독 전에 이미 작업이 시작됨. 이게 의도와 다르면 Deferred로 감싸야 함.
// Future를 감싸서 구독 시점에 실행되도록
Deferred {
Future<User, Error> { promise in
// 구독될 때마다 실행됨
}
}
URLSession.dataTaskPublisher — 네트워크 요청
URLSession.shared.dataTaskPublisher(for: url)
.map(\\.data)
.decode(type: User.self, decoder: JSONDecoder())
.receive(on: DispatchQueue.main)
.sink(
receiveCompletion: { _ in },
receiveValue: { user in print(user) }
)
.store(in: &cancellables)
URLSession 기반 네트워크 요청을 그대로 Publisher로 받을 수 있음. map → decode → receive(on:) → sink 가 표준 패턴.
Timer.publish — 주기적 이벤트
Timer.publish(every: 1.0, on: .main, in: .common)
.autoconnect() // 구독 시 자동 시작
.sink { date in print(date) }
.store(in: &cancellables)
autoconnect()를 빼먹으면 타이머가 시작되지 않음. 이거 빼먹어서 시간 날리는 경우가 정말 많음.
Subject — 외부에서 값을 주입할 수 있는 Publisher
기본 Publisher들은 "정해진 값을 내보냄". 반대로 내가 원할 때 값을 넣고 싶다면 Subject를 씀.
Subject는 두 종류임.
PassthroughSubject — 초기값 없음, 구독 이후 값만 받음
let subject = PassthroughSubject<String, Never>()
subject.sink { print("받음: \\($0)") }
.store(in: &cancellables)
subject.send("A") // "받음: A"
subject.send("B") // "받음: B"
CurrentValueSubject — 초기값 있음, 구독 시 현재 값을 받음
let subject = CurrentValueSubject<String, Never>("초기값")
subject.sink { print("받음: \\($0)") }
.store(in: &cancellables)
// "받음: 초기값" ← 구독 즉시 현재 값을 받음
subject.send("새 값") // "받음: 새 값"
print(subject.value) // "새 값" ← 현재 값에 직접 접근 가능
상태(state)를 다룰 때 적합함. ViewModel의 데이터 상태를 표현하는 데 가장 자주 씀. .value로 현재 값을 동기적으로 꺼낼 수 있는 것도 큰 장점.
언제 뭘 쓰는지 헷갈리면:
- "지금 상태가 뭐야?" → CurrentValueSubject (예: 로그인 여부, 현재 선택된 탭)
- "방금 무슨 일 있었어?" → PassthroughSubject (예: 버튼 탭, API 호출 트리거)
@Published — 프로퍼티를 Publisher로
@Published는 프로퍼티 래퍼로, 일반 프로퍼티를 자동으로 Publisher로 만들어줌.
class SearchViewModel {
@Published var query: String = ""
@Published var results: [Item] = []
}
let viewModel = SearchViewModel()
viewModel.$query // Published<String>.Publisher
.debounce(for: .milliseconds(300), scheduler: DispatchQueue.main)
.removeDuplicates()
.sink { print("검색어: \\($0)") }
.store(in: &cancellables)
viewModel.query = "Combine" // 0.3초 후 "검색어: Combine"
내부적으로는 CurrentValueSubject와 거의 동일하게 동작함. 다만 클래스 안에서 프로퍼티 형태로 쓸 때 훨씬 자연스러움.
주의 : @Published는 willSet 시점에 값을 내보냄. 즉, sink에서 받는 값은 곧 바뀔 값임. 이미 바뀐 값이 아님.
class ViewModel {
@Published var count = 0
}
let vm = ViewModel()
vm.$count.sink { newValue in
print("publisher: \\(newValue), property: \\(vm.count)")
}.store(in: &cancellables)
vm.count = 5
// 출력: "publisher: 5, property: 0"
// publisher가 먼저 발행되고, 그 다음에 실제 프로퍼티가 갱신됨
이 동작 때문에 디버깅하다 헷갈리는 경우가 있으니 알아두면 좋음.
Cold vs Hot
Cold Publisher — 구독해야 값을 내보냄
대부분의 Combine Publisher는 Cold임. 구독자가 생기기 전까지는 아무 일도 일어나지 않음.
let publisher = URLSession.shared.dataTaskPublisher(for: url)
// 이 시점엔 네트워크 요청 안 일어남
publisher.sink { _ in }.store(in: &cancellables) // 이제 요청 시작
publisher.sink { _ in }.store(in: &cancellables) // 두 번째 구독 → 또 요청
같은 Publisher를 두 번 구독하면 네트워크 요청도 두 번 발생함. 이게 의도한 동작이 아니라면 문제가 됨.
Hot Publisher — 구독 여부와 무관하게 값을 내보냄
Subject나 NotificationCenter.Publisher는 Hot임. 구독자가 없어도 값은 흘러감.
let subject = PassthroughSubject<Int, Never>()
subject.send(1) // 아무도 안 받음, 그냥 사라짐
subject.sink { print($0) }.store(in: &cancellables)
subject.send(2) // 2
Cold를 Hot처럼 쓰고 싶을 때
예를 들어, 네트워크 요청 결과를 여러 곳에서 공유하고 싶다고 하자. Cold 그대로 두면 구독할 때마다 요청이 날아감. 이때 쓰는 게 share() 또는 multicast().
let shared = URLSession.shared.dataTaskPublisher(for: url)
.map(\\.data)
.share() // 여러 구독자가 결과를 공유
shared.sink { _ in }.store(in: &cancellables) // 요청 발생
shared.sink { _ in }.store(in: &cancellables) // 요청 안 발생, 결과만 공유
커스텀 Publisher 만들기
직접 만들 일은 거의 없지만 한 번 만들어보면 Publisher 구조가 머리에 박힘.
struct CountdownPublisher: Publisher {
typealias Output = Int
typealias Failure = Never
let from: Int
func receive<S: Subscriber>(subscriber: S)
where S.Input == Output, S.Failure == Failure {
let subscription = CountdownSubscription(subscriber: subscriber, from: from)
subscriber.receive(subscription: subscription)
}
}
final class CountdownSubscription<S: Subscriber>: Subscription
where S.Input == Int, S.Failure == Never {
private var subscriber: S?
private var current: Int
init(subscriber: S, from: Int) {
self.subscriber = subscriber
self.current = from
}
func request(_ demand: Subscribers.Demand) {
while current >= 0 {
_ = subscriber?.receive(current)
current -= 1
}
subscriber?.receive(completion: .finished)
}
func cancel() {
subscriber = nil
}
}
// 사용
CountdownPublisher(from: 3)
.sink { print($0) }
.store(in: &cancellables)
// 출력: 3, 2, 1, 0`
쓸 일은 별로 없음. 대부분의 경우 Subject나 Future로 충분히 해결됨. 이런 구조로 동작한다 정도만 알면 됨.
꿀팁
1. 네트워크는 거의 항상 dataTaskPublisher + share
func fetchUser(id: String) -> AnyPublisher<User, Error> {
URLSession.shared.dataTaskPublisher(for: url)
.map(\\.data)
.decode(type: User.self, decoder: JSONDecoder())
.mapError { $0 as Error }
.share() // 같은 요청 여러 곳에서 구독해도 한 번만 발생
.eraseToAnyPublisher()
}
.eraseToAnyPublisher()로 타입을 감추는 게 거의 표준. 내부 구현(map, decode 등)이 호출하는 쪽에 노출되지 않음.
2. ViewModel 상태는 CurrentValueSubject 또는 @Published
final class HomeViewModel {
// UIKit 베이스
let isLoading = CurrentValueSubject<Bool, Never>(false)
let items = CurrentValueSubject<[Item], Never>([])
// SwiftUI 베이스 또는 ObservableObject 쓸 때
@Published var isLoading2 = false
@Published var items2: [Item] = []
}
UIKit + Combine 조합에서는 CurrentValueSubject, SwiftUI나 ObservableObject 패턴에서는 @Published가 자연스러움.
3. 이벤트성 입력은 PassthroughSubject
final class HomeViewModel {
// 입력 (View → ViewModel)
let viewDidLoad = PassthroughSubject<Void, Never>()
let didTapRefresh = PassthroughSubject<Void, Never>()
let didSelectItem = PassthroughSubject<Item, Never>()
}
Input/Output 패턴으로 ViewModel을 설계할 때 거의 표준 형태.
4. Future는 한 번만 실행됨 → 결과 캐싱 필요한가 체크
Future는 한 번 실행되고 결과를 내부에 저장함. 같은 Future를 두 번 구독하면 두 번째는 캐시된 결과를 받음.
이게 원하는 동작이면 OK, 매번 새 요청을 보내고 싶다면 Deferred { Future { ... } }로 감싸야 함.
5. @Published의 willSet 동작 기억하기
@Published 프로퍼티를 변경한 직후 그 값에 접근하면, 구독자가 받은 값과 실제 값이 한 사이클 어긋날 수 있음. 디버깅하다 시간 낭비하지 않으려면 외워두기.
정리
Publisher의 종류는 크게 셋. 기본 제공(Just, Empty, Fail, Future), 시스템 이벤트(URLSession, NotificationCenter, Timer), 수동 발행(Subject, @Published).
- 네트워크 → URLSession.dataTaskPublisher + share + eraseToAnyPublisher
- 상태 → CurrentValueSubject 또는 @Published
- 이벤트 → PassthroughSubject
- Completion Handler 감싸기 → Future (필요 시 Deferred)
그리고 가장 헷갈리는 Cold vs Hot. 대부분의 Publisher는 Cold이고, 구독할 때마다 재실행됨. 공유가 필요하면 share().