문군의 개발일지

[ReactorKit] Reactor 살펴보기

문군_ — Wed, 4 Feb 2026 17:11:06 +0900

요약

Reactor는 View로부터 Action을 입력받아 Mutation을 생성하고, reduce를 통해 State를 계산하여 View에 제공하는 역할을 한다.
즉, Reactor는 단방향 데이터 흐름(Action -> Mutation -> State)을 강제하는 ViewModel이다.

Reactor의 책임

Reactor는 다음을 책임집니다.

입력(Action)을 정의한다.
- View가 발생시키는 사용자 입력을 Action으로 모델링 합니다.
상태 변경 단위(Mutation)를 정의한다.
- State를 변경하는 "이유/사건"을 Mutation으로 표현합니다.
상태(State)를 정의한다.
- View가 그려야 하는 UI 상태의 단일 진실원천 (SSOT)
비동기 작업을 수행한다.
- 네트워크/DB 등 side effect가 존재하는 작업을 수행합니다.
- mutate() 메서드에서 수행
- 해당 작업을 Mutation으로 변환합니다.
상태를 계산한다.(reduce).
- Mutation + 기존 State -> 새 State 로 전환

Action

Action은 사용자 인터렉션, 즉 View에서 발생한 입력을 의미합니다.

UI 이벤트(버튼 탭, 스크롤, 선택 등)
생명주기 이벤트(viewDidLoad 등)
외부 트리거(갱신 이벤트 등)Example예를 들어 값의 증가와 감소를 카운팅하는 카운터를 만들었다고 해봅시다. 그렇다면 CounterViewReactor는 어떠한 Action을 가질 수 있을까요?

enum Action {
    case increase
    case decrease
}

위처럼 action에는 값의 증가와 감소 두 가지 action을 할 수 있습니다.

Mutation

Mutation은 Action과 State 사이의 연결 다리입니다. 즉, Mutation은 State를 변경하기 위한 이벤트(상태 변경 단위) 입니다.

Mutation은 "State를 어떻게 바꿀지"에 대한 최소 단위
Mutation은 상태 변경 결과 (예: setValue)로 표현하는 편이 테스트에 유리합니다.Example예시의 Counter 앱이 1. 값의 증감 2. 증감 진행중 표시 3. 완료 표시 기능이 필요하다고 해봅시다. 그렇다면 다음과 같은 4가지의 Mutation이 필요할 것입니다.

enum Mutation {
    case increaseValue
    case decraseValue
    case setLoading(Bool)
    case setAlertMessage(String)
}

State

State는 View가 그리는 UI 상태의 단일 진실원천(Single Source Of Truth) 입니다.
View에서는 이 State를 바인딩하여 state의 변화에 따라 UI를 새로 그리는 역할을 수행합니다.

State는 UI 렌더링을 위한 데이터만 가짐
Side effect 객체는 State에 넣지 않음
일회성 이벤트(Alert/Toast)는 @Pulse 사용을 고려ExampleCounter에는 UI에 보여줄 값, 로딩 인디케이터를 위한 로딩 여부의 Bool 값, alertMessage가 필요합니다.

위에서 설명한 일회성 이벤트가 AlertMessage에 해당하므로 @Pulse를 고려할 수 있습니다.

struct State {
    var value: Int
    var isLoading: Bool
    @Pulse var alertMessage: String?
}

데이터 흐름

ReactorKit의 기본 흐름은 다음과 같습니다.

View가 UI 이벤트를 Action으로 변환해 reactor.action에 바인딩
Reactor는 mutate(aciton:)에서 Mutation 스트림을 생성
Reactor는 Mutation을 reduce(state:mutation:)로 누적 계산하여 State 방출
View는 reactor.state를 구독해 UI 갱신

주요 메서드

1. mutate(action:)

Action을 받아 Mutation 스트림을 생성합니다.

    func mutate(action: Action) -> Observable<Mutation> {
        switch action {
        case .increase:
            Observable.concat([
                Observable.just(Mutation.setLoading(true)),
                Observable.just(Mutation.increaseValue).delay(.milliseconds(500), scheduler: MainScheduler.instance),
                Observable.just(Mutation.setLoading(false)),
                Observable.just(Mutation.setAlertMessage("Increased!")),
            ])
        case .decrease:
            Observable.concat([
                Observable.just(Mutation.setLoading(true)),
                Observable.just(Mutation.decraseValue).delay(.milliseconds(500), scheduler: MainScheduler.instance),
                Observable.just(Mutation.setLoading(false)),
                Observable.just(Mutation.setAlertMessage("Decreased!")),
            ])
        }
    }

mutate에서 side effect가 수행되어야 합니다.

2. reduce(state:mutation:)

Mutation을 기반으로 새로운 State를 계산합니다.

func reduce(state: State, mutation: Mutation) -> State {
    var state = state

    switch mutation {
    case .increaseValue:
        state.value += 1
    case .decraseValue:
        state.value -= 1
    case let .setLoading(isLoading):
        state.isLoading = isLoading
    case let .setAlertMessage(message):
        state.alertMessage = message
    }

    return state
}

reduce는 순수 함수(pure funciton) 처럼 유지하는 것이 이상적입니다.
네트워크 요청과 같은 side effect는 reduce에 두지 않습니다.

3. transform

ReactorKit에는 transform이 3종류가 있습니다.

func transform(action: Observable<Action>) -> Observable<Action>
func transform(mutation: Observable<Mutation>) -> Observable<Mutation>
func transform(state: Observable<State>) -> Observable<State>

이것들은 "ReactorKit이 기본으로 만드는 스트림 파이프라인" 중간에 끼워 넣을 수 있는 확장 포인트입니다.

View에서 들어오는 Action 스트림을 가공
mutate에서 만들어진 Mutation 스트림을 조작
최종 State 스트림을 조작/공유할 수 있습니다.

[ReactorKit] ReactorKit 기본 개념 살펴보기

문군_ — Tue, 20 Jan 2026 16:09:34 +0900

ReactorKit 개념

ReactorKit이란?

ReactorKit은 Flux 아키텍처의 단방향 데이터 흐름과 Reactive Programming(RxSwift)의 비동기 스트림 처리를 결합한 iOS 아키텍처 프레임워크 입니다.

ReactorKit은 위에서 서술한 것처럼 Reactive Programming의 개념을 채용했기 때문에 RxSwift와 함께 사용됩니다. 따라서, ReactorKit을 사용하려면 RxSwift에 대한 이해가 전제조건 입니다.

ReactorKit의 핵심 개념은 Reactor 입니다. Reactor는 Rx의 개념인 Observable과 함께 사용되며 비동기적으로 데이터를 처리하고, UI와의 상호작용을 쉽게 관리할 수 있도록 합니다.

이는 MVVM의 뷰 모델(View Model) 의 역할을 한다고 볼 수 있습니다.

다만 ReactorKit의 차이점은 ViewModel을 만들 때 그 안에서의 상태변경 방식을 강제된 규칙 (단방향 데이터 흐름 + 이벤트 모델링) 으로 고정해 둔 것입니다.

다음 그림은 ReactorKit의 작동 방식을 간단하게 표현한 것입니다.

사용자의 Action은 Reactor로, Reactor에서 방출된 State는 View로 Observable 스트림을 통해 전달됩니다. (단방향적 흐름)
View는 Action만 방출하며, Reactor는 State만을 방출합니다.

단방향적 흐름으로 인해 View와 비즈니스 로직을 분리할 수 있으며 모듈 간 결합도를 낮출 수 있습니다.

View와 Reactor

View

View는 데이터를 표시합니다. View Controller와 Cell은 하나의 뷰로 간주됩니다.
View는 사용자의 입력을 Action Stream에 바인딩하고, 뷰 State를 각 UI 컴포넌트에 바인딩 합니다.

뷰 레이어는 비즈니스 로직이 없고, 단순히 액션 스트림과 상태 스트림을 매핑하는 방식을 정의합니다. (Action과 State를 각각의 요소에 바인딩하는 역할만을 수행)

이를 적용하기 위해서는 View 프로토콜을 적용하는 것이 일반적입니다.

View 프로토콜은 다음과 같이 DisposeBag, Reactor, bind(reactor:)가 존재하고 disposeBag과 bind(reactor:) 메서드는 반드시 재정의 해주어야 합니다.

bind 내부에서

UI 이벤트를 Action으로 변환(map)하여 Reactor의 입력(action)에 연결하고
State 변화를 관찰하여 UI에 반영하는 바인딩을 정의합니다.
이를 예시 코드로 살펴보면 다음과 같습니다.

import UIKit

import ReactorKit
import RxCocoa
import RxSwift

final class CounterViewController: UIViewController, View {
    @IBOutlet weak var valueLabel: UILabel!
    @IBOutlet weak var increaseButton: UIButton!
    @IBOutlet weak var decreaseButton: UIButton!
    @IBOutlet weak var activityIndicatorView: UIActivityIndicatorView!

    var disposeBag = DisposeBag()

    override func viewDidLoad() {
        super.viewDidLoad()

        self.reactor = CounterViewReactor()
    }

    func bind(reactor: CounterViewReactor) {
        // Action
        increaseButton.rx.tap
            .throttle(
                .milliseconds(500),
                latest: false,
                scheduler: MainScheduler.instance
            )
            .map { CounterViewReactor.Action.increase }
            .bind(to: reactor.action)
            .disposed(by: disposeBag)

        decreaseButton.rx.tap
            .throttle(
                .milliseconds(500),
                latest: false,
                scheduler: MainScheduler.instance
            )
            .map { CounterViewReactor.Action.decrease }
            .bind(to: reactor.action)
            .disposed(by: disposeBag)

        // State
        reactor.state.map { $0.value }
            .distinctUntilChanged()
            .map { "\($0)" }
            .bind(to: valueLabel.rx.text)
            .disposed(by: disposeBag)
    }
}

Reactor

Reactor는 View 로부터 Action Stream을 전달 받아, 내부에서 mutate()와 reduce() 과정을 거쳐서 State Stream으로 바꾸어 다시 View에 전달합니다.

이를 위해서는 Reactor 프로토콜을 적용해야하고, 해당 프로토콜은 Action, Mutation, State 를 반드시 정의해야 합니다. 또한 State 초기 값 설정을 위한 initialState도 정의해야 합니다.

Action은 사용자 인터렉션을 나타내고, State는 뷰의 상태를 나타냅니다. Mutation은 Action과 State 사이의 브릿지(bridge) 역할을 합니다.

Reactor는 action stream과 state stream을 변환하는 두 단계인 mutate()와 reduce()를 수행합니다.

mutate()

mutate()는 Action 스트림을 Mutation 스트림으로 변환합니다. 변환된 Mutation 스트림은 reduce() 함수로 전달됩니다.

func mutate(action: Action) -> Observable<Mutation>

모든 사이드 이펙트(예: 비동기 작업, API call)은 여기서 수행됩니다.

reduce()

reduce()는 이전 State와 Mutation을 활용하여 새로운 State를 생성합니다.

func reduce(state: State, mutation: Mutation) -> State

View에서 reactor의 state를 바인딩 해둔 상태라면, 새로운 state가 방출될 때마다 바인딩 된 UI가 자동으로 업데이트 됩니다.

Reference

(올리브영 테크 블로그) iOS ReactorKit 톺아보기
ReactorKit

RxSwift - Observable 생성

문군_ — Wed, 14 Jan 2026 17:09:14 +0900

Observable

Observer가 구독하는 대상
Observable이 배출하는 하나 또는 연속된 항목을 Observer가 반응
→ 이러한 패턴 덕분에 동시성 연산이 가능
- Observable이 객체를 배출할 때까지 기다릴 필요 없이, 배출 시점을 관찰하는 관찰자를 두고 관찰자를 통해 배출 알림을 받으면 되기 때문

Observable을 생성하는 방법 (create, just, of, from)

Create

Create 연산자를 사용하면 직접 Observable을 만들 수 있습니다. 이 연산자에는 Observser를 매개변수로 받는 클로저를 전달해야 합니다.

클로저 안에서는 실제 Observable처럼 동작하도록, observer의 onNext, onCompleted, onError 메서드를 적절히 호출해야 합니다.

올바르게 구성된 Observable은 Observer의 onCompleted 또는 onError 중 하나를 정확히 한 번만 호출해야 하며, 그 이후에는 Observer의 어떤 메서드도 더 이상 호출해서는 안 됩니다.

함수의 원형을 살펴보면, “Observer를 매개변수로 받고, Disposable을 반환하는 클로저”를 매개변수로 받음

let observable = Observable<String>.create { observer in
    observer.onNext("first")
    observer.onNext("second")
    observer.onCompleted()

    return Disposables.create()
}

위처럼 create 매서드 다음 Trailing Closure를 이용해서 매개변수로 받은 observer를 통해 언제 onNext를 통해 이벤트를 방출할 것인지, 혹은 언제 onCompleted or onError를 통해 종료할 것인지를 직접 처음부터 끝까지 직접 조절할 수 있습니다.

Just

특정한 아이템(1개)를 방출하는 Observable을 생성하는 메서드

Create 메서드를 통해서도 동일하게 동작하지만, 단지 1개의 아이템만을 방출할 때는 Just를 사용해서 간략화 할 수있음

Just의 경우 단 하나만을 방출하는 것을 전제로 하기 때문에, 따로 onCompleted 를 호출하지 않아도 자동으로 호출된 후 dispose 됩니다.

let observable = Observable.just("first")
// or
let observable = Observable<[String]>.just(["first", "second"])

Of

of 메서드는 가변 매개변수를 입력하여, 매개변수를 각각 방출합니다.

let observable = Observable.of("fisrt", "second", "third")

From

From은 매개변수로 하나의 배열을 받으며, 배열의 요소들을 순서대로 방출하는 Observable Sequence를 생성합니다.

let observable = Observable.from(["frist", "second", "third"])

RxSwift - Observable, RxCocoa, Driver

문군_ — Wed, 14 Jan 2026 17:05:52 +0900

RxSwift는?

비동기로 발생한 데이터를 Completion handler가 아닌 return 값으로 전달해주는 클래스

Observable 생성

Observable<String>.create() { observer in
    observer.onNext("Hello")
    observer.onCompleted()
    return Disposables.create()
}

Observable 이 방출하는 데이터 타입을 가지는 객체를 생성후 .create() 메서드를 통해 Observer를 등록합니다.

Observable의 생명주기

create() 를 통해 생성
subscribe() 를 통해 사용
onNext() 를 통해 데이터 전송
onCompleted() or onError() 를 통해 종료
disposed() : 작업 취소

Observable의 메서드

debug()
observeOn()
subscribe()

Observable의 operators

just()
- 단일 데이터를 전달하는 경우, 정석적인 방법을 다 작성하지 않아도 사용하게 해주는 just가 존재합니다.

func foo() -> Observable<String> { return Observable.just("Hello World") }

from(optional:)
- 여러 데이터를 전달하고 싶을 때는 from 내부에 배열을 만들어서 전송할 수 있습니다.

func foo() -> Observable<String> { return Observable.from(["Hello", "World"]) }

subscribe

Observable 객체의 이벤트를 받을 때 subscribe를 사용합니다.

.subscribe { [weak self] event in
    switch event {
    case let .next(json):
        self?.editView.text = json
        self?.setVisibleWithAnimation(self?.activityIndicator, false)
    case .error(let e):
        print("Error: \(e.localizedDescription)")
        break
    case .completed:
        print("All observable's completed!!")
    }
}

event 전체 (onNext, onError, onCompleted)를 받고자 할 때는 위 방식을 사용하고,
위 이벤트 중 일부만 받고싶다면 subscribe에서 각각의 closure 파라미터만 가져와서 사용할 수 있습니다.
.observeOn(MainScheduler.instance)
- observeOn 은 onNext를 통해 데이터를 받아온 뒤 메인 스레드에서 처리를 해줘야 할 때 DispatchQueue.main.async{} 를 통해 메인 스레드에서 처리를 해주지만, observeOn(MainScheduler.instance) 를 통해서 이를 생략할 수 있습니다.
map , filter

subscribeOn: 시작 메서드를 지정
observeOn: 이후의 스레드를 지정
scan

Disposable

Observable의 create의 리턴 값으로 나오는 Disposable은 평소에는 사용하지 않습니다.

하지만 특정 observable의 이벤트를 종료 or 끝내야 할 상황이라면 .dispose() 메서드를 통해 종료할 수 있습니다.

만약 어떠한 이벤트들이 동작하는 도중, 뷰가 사라진다면 특정 이벤트를 종료해야 할 수 있다. 이 경우에 외부에 disposable을 담는 배열이나 변수를 선언해둔다면, viewDidDisappear 에서 이벤트를 종료할 수 있게됩니다.

var disposableBag: [Disposable] = []
...

override func viewDidDisappear(animated: Bool) {
    super.viewDidDisappear(animated)

    disposableBag.forEach { $0.dispose() }
}
...

func makeObservable() {
    ...
    disposableBag.append(disposable)
}

DisposableBag

위와 같이 Disposable 배열을 선언해도 좋지만 해당 기능을 RxSwift에서는 미리 만들어두었습니다.

DisposeBag 객체를 생성하고, append 대신 insert 를 통해 삽입이 가능합니다.

또한 변수를 할당하지 않고, 생성과 동시에 넣고 싶다면 .disposed(by: disposeBag) 을 통해 생성과 동시에 disposeBag에 넣을 수 있습니다.

var disposeBag = DisposeBag()
Observable.create()...
    .disposed(by: disposeBag)

Observable 단점

Observable은 이벤트를 방출하는 스트림이며, 외부에서 임의로 이벤트를 주입(push)할 수 없습니다.

외부에서 이벤트를 발생시켜야 하는 경우, Observable 역할까지 포함한 Subject 를 사용해 스트림에 값을 push할 수 있습니다.

Subject

Subject에는 총 4가지 종류가 존재합니다.

1. PublishSubject

특징

구독한 이후부터 이벤트를 받음
이전 값은 주지 않음
실시간 이벤트에 적합

2. BehaviorSubject

특징

항상 최신 값 1개를 저장하고 있음
구독하면 즉시 최신 값 1개를 먼저 받고, 이후 이벤트도 받음
반드시 초기값이 필요하거나, 최소 한 번은 onNext가 되어 있어야 함
현재 상태 표현에 적합

3. ReplaySubject

특징

지정한 개수만큼 이전 이벤트를 버퍼에 저장
구독하면 저장된 이벤트들을 재생해서 먼저 보여줌
최근 N개의 이벤트를 새 구독자들도 봐야 할 때 사용

4. AsyncSubject

특징

completed 될 때까지 값을 모음
완료되면 마지막 값 딱 1개만 방출하고 종료
완료되지 않으면 아무것도 나가지 않음
최종 결과만 의미 있는 작업일 때 사용

Observable vs. Subject

Observable은 흐름입니다. Observable이 이벤트를 방출하면 Subscribe 한 구독자들이 받는 구조입니다.
간단하게 비유를 들자면 Observable은 인터넷 방송입니다. 그저 흘러가고있을 뿐입니다. 시청자(Subscriber)들은 구독(Subscribe)해서 시청만을 하고 방송을 보는 것 밖에 하지 못합니다.

Subject는 방송국 콘솔입니다. 시청자처럼 방송을 볼 수도 있고(Observable), PD 처럼 방송을 송출할 수도 있습니다(Observer).
즉 Subject는 두 가지 역할을 동시에 합니다.

Observable (구독할 수 있음)
Observer (onNext로 이벤트를 밀어 넣을 수 있음)

RxCocoa

viewModel.itemsCount
    .map { "\($0)" }
    .observeOn(MainScheduler.instance)
    .subscribe(onNext: { [weak self] in
        self.itemCountLabel.text = $0
    })
    .disposed(by: disposeBag)

위처럼 subscribe를 통해 방출된 이벤트를 처리하는 로직을

viewModel.itemsCount
    .map { "\($0)" }
    .observeOn(MainScheduler.instance)
    .bind(to: itemCountLabel.rx.text)
    .disposed(by: disposeBag)

이처럼 bind와 UIKit의 extension으로 만든 RxCocoa를 통해 .rx 를 통해서 값을 바인딩 할 수 있습니다.

또한 subscribe에서 순환 참조를 방지하기 위한 [weak self] 캡처 리스트를 사용하지 않아도 순환 참조가 발생하지 않습니다.

`catchErrorJustReturn`

RxCocoa의 경우 UI와 관련되어 있기 때문에 항상 메인 스레드에서 동작하도록 해야합니다.

만약 에러가 발생한 경우 해당 스트림은 끊어지게 되는데, UI는 그래서는 안됩니다.

그래서 에러가 발생한 경우 끊어지지 않게 값을 내려보낼 수 있도록 하는 메소드가 존재합니다.

viewModel.itemsCount
    .map { "\($0)" }
    .catchErrorJustReturn("")
    .observeOn(MainScheduler.instance)
    .bind(to: itemCountLabel.rx.text)
    .disposed(by: disposeBag)

위 경우 에러가 발생하면 빈 문자열을 리턴해주도록 합니다.

Driver

Driver 객체는

실패하지 않습니다.
메인스케쥴러에 이벤트를 전달합니다.

UI는 항상 메인스레드에서 동작해야 합니다.

따라서 Observable을 사용해도 항상 observeOn(MainScheduler.instance) 를 해줘야 하는데, 항상 메인 스레드에서 동작하는 Observable을 Drive 라고 합니다.

`asDriver`

위의 catchErrorJustReturn 과 observeOn(MainScheduler.instance) 의 경우 UI 관련된 로직의 경우 필수로 들어가야 합니다.

이를 하나로 축약한 메서드가 존재하는데, 이를 asDriver(onErrorJustReturn:) 이라고 합니다.

viewModel.itemsCount
    .map { "\($0)" }
        .asDriver(onErrorJustReturn: "")
    .drive(itemCountLabel.rx.text)
    .disposed(by: disposeBag)

asDriver의 리턴 값은 Driver 객체입니다.

Relay

UI와 관련된 스트림의 경우 한 번 끊어지면 (UI 스트림이 아니더라도) 다시 연결할 수 없기 때문에, 끊어지지 않는 것이 중요합니다.

이를 지원하는 것이 RxRelay 라이브러리 내부의 Relay 들입니다.

Relay의 경우 onNext 의 역할을 하는 것이 accept 메서드입니다.

→ relay는 onCompleted 나 onError 가 존재하지 않기 때문입니다.

ReactiveX Introduction 번역

문군_ — Wed, 1 Oct 2025 16:59:59 +0900

ReactiveX란?

MS 사에서 만든 observable streams 기반의 비동기 프로그래밍 API

reactivex.io 에서는 ReactiveX를 다음과 같이 설명합니다.

ReactiveX는 옵저버 패턴 , 이터레이터 패턴 그리고 함수형 프로그래밍 의 장점(best ideas)들을 결합한 것입니다.

It extends the observer pattern to support sequences of data and/or events and adds operators that allow you to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O.

ReactiveX는 옵저버 패턴을 확장해 데이터나 이벤트의 연속적인 흐름을 다룰 수 있도록 하고, 여러 시퀀스를 선언적으로 조합할 수 있는 연산자를 제공합니다. 이를 통해 개발자는 스레드 처리, 동기화, 스레드 안전성, 동시성 자료구조, 논블로킹 I/O와 같은 저수준 구현 문제를 직접 다루지 않고도 복잡한 비동기 로직을 표현할 수 있습니다.

Observable은 다양한 아이템들의 비동기 흐름에 접근하는 가장 이상적인 방식으로 그 격차를 메웁니다.

	Single items	multiple items
synchronous	T getData()	Iterable<T> getData()
asynchronous	Future<T> getData()	Observable<T> getData()

이것은 때때로 “함수형 반응형 프로그래밍(functional reactive programming)”이라고 불리기도 하지만, 이는 잘못된 명칭(misnomer)입니다. ReactiveX는 함수형일 수도 있고, 반응형일 수도 있지만, “함수형 반응형 프로그래밍”은 전혀 다른 개념입니다.
주요 차이점 중 하나는, 함수형 반응형 프로그래밍은 시간이 흐름에 따라 연속적으로 변하는 값들을 다루는 반면, ReactiveX는 시간이 지남에 따라 불연속적으로 발생(discrete)하는 값들을 다룬다는 것입니다.

왜 Observable을 사용하나요?

Rx의 Observable 모델은 배열과 같은 데이터 컬렉션을 다룰 때 사용하는 간단하고 조합 가능한 연산자들과 동일한 방식으로 비동기 이벤트 스트림을 다룰 수 있게 해줍니다. 또한 복잡하게 얽힌 콜백 구조에서 벗어나도록 도와주며, 그 결과 코드가 더 읽기 쉬워지고 버그가 발생할 가능성도 줄어듭니다.

Observable은 조합 가능(Composable)합니다.

Java의 Futures 같은 단일 비동기 실행에는 간단히 쓸 수 있지만, 여러 단계로 중첩되면 금방 복잡성이 커집니다.
Futures를 이용해 조건부 비동기 실행 흐름을 최적으로 구성하기는 어렵습니다.
심지어 각 요청의 지연 시간(latency)이 실행 시점마다 달라지므로 사실상 불가능 할 수도 있습니다.
(→ 즉, “만약 이 결과가 true인 경우 다음 요청 실행” 같은 조건부 플로우를 짜기가 힘들고, 요청 지연시간이 불규칙해서 더 어려워짐)
물론 할 수는 있지만, 그렇게 하면 금방 복잡해져서 에러가 생기기 쉽거나, 아니면 Future.get() 을 너무 일찍 호출해서 차라리 동기 실행처럼 되버립니다.
그 결과 비동기의 장점(논블로킹)이 사라져 버립니다.
반대로 ReactiveX의 Observables는 비동기 데이터 흐름과 시퀀스를 조합하기 위해 설계된 것입니다.
(즉, Futures 처럼 단일 작업을 다루는 게 아니라, 여러 비동기 흐름을 조합/연결하는 데 최적화되어 있습니다.

Observable은 유연(Flexible)합니다.

ReactiveX의 Observable은 (Future 가 하는 것처럼) 단일 값하나의 방출만을 지원하는 것이 아니라, 값들의 연속된 시퀀스나 심지어 무한 스트림도 지원합니다. Observable 은 이 모든 경우에 사용할 수 있는 단일한 추상화이며, 이는 Iterable이 가진 유연함과 우아함을 모두 갖추고 있습니다.

Observable은 특정 방식에 얽매이지 않습니다.

ReactiveX는 특정한 동기/비동기 처리 방식에 치우치지 않습니다. Observable은 스레드 풀, 이벤트 루프, 논블로킹 I/O, 엑터 모델(Akka 등) 등, 어떤 방식으로든 구현될 수 있습니다. 즉, 개발자의 필요, 스타일, 전문성에 맞는 방식이면 무엇이든 사용할 수 있습니다. 클라이언트 코드 입장에서는, Observable과 상호작용할 때 항상 비동기적으로 보인다는 것입니다. 실제 내부 구현이 blocking인지 non-blocking인지 무관하게 말입니다.

Observable은 Iterable의 쌍둥이 같은 개념으로, Iterable이 동기적·pull 기반이라면 Observable은 비동기적·push 기반입니다.

event	Iterable (pull)	Observable (push)
retrieve data	T next()	onNext(T)
discover error	throws Exception	onError (Exception)
complete	!hasNext()	onCompleted()

Observable은 어떻게 구현되어 있나요?

public Observable<data> getData();

호출자와 같은 스레드에서 동작하나요?
다른 스레드에서 비동기적으로 동작하나요?
여러 개의 스레드로 일을 나눠서, 순서에 상관없이 데이터를 돌려주나요?
스레드 풀 대신 엑터를 사용하나요?
NIO + 이벤트 루프로 네트워크를 비동기 처리하나요?
이벤트 루프로 작업 스레드와 콜백 스레드를 분리하나요?

관찰자 입장에서는 중요하지 않습니다!

그리고 중요한 점: ReactiveX에서는 나중에 마음이 바뀌어도, Observable의 내부 구현 방식을 과감히 바꾸면서도, 그 Observable을 소비하는 코드(클라이언트)를 깨뜨리지 않을 수 있습니다.

콜백에도 나름의 문제가 있습니다.

콜백은 어떤 것도 블로킹하지 않음으로써 Future.get()에서 발생하는 조기 블로킹 문제를 해결합니다. 콜백은 응답이 준비되었을 때만 실행되므로, 본질적으로 효율적입니다. 하지만 Future와 마찬가지로, 콜백도 단일 레벨의 비동기 실행에는 사용하기 쉽지만, 중첩된 구조로 합성되면 다루기 어렵고 복잡해집니다.

ReactiveX는 다언어(Polyglot) 구현체입니다.

ReactiveX는 여러 프로그래밍 언어에서 구현된 라이브러리로, 각 언어의 문법적 특성과 관용적 스타일을 반영합니다. 또한 현재도 빠른 속도로 더 많은 언어로 확장되고 있습니다.

Reactive Programming

ReactiveX는 Observable을 다룰 수 있는 다양한 연산자(filter, select, transform, combine 등)를 제공합니다. 이를 통해 효율적인 실행과 조합이 가능합니다. Observable 클래스는 Iterable의 “pull” 방식에 대응하는 “push” 방식이라고 생각하면 됩니다. Iterable에서는 소비자(consumer)가 생산자로부터 값을 끌어오며(pull), 값이 준비될 때까지 스레드가 블로킹 됩니다. 반대로, Observable에서는 생산자(producer)가 값이 준비되는 즉시 소비자에게 값을 밀어(push)줍니다. 이 방식은 값이 동기적으로든 비동기적으로든 도착할 수 있기 때문에 더 유연합니다.

Iterable과 Observable 모두에 map, filter 같은 고차함수를 적용할 수 있는데, 그 유사성을 보여주는 예제 코드

Iterable

getDataFromLocalMemory()
  .skip(10)
  .take(5)
  .map({ s -> return s + " transformed" })
  .forEach({ println "next => " + it })

Observable

getDataFromNetwork()
  .skip(10)
  .take(5)
  .map({ s -> return s + " transformed" })
  .subscribe({ println "onNext => " + it })

Observable 타입은 기존 GoF Observable 패턴에 부족했던 두 가지 의미(sementics)를 추가하여, Iterable 타입에서 제공되는 것과 대응되도록 합니다.

생산자가 소비자에게 더 이상 데이터가 없음을 알릴 수 있는 기능
- Iterable 에서는 foreach 루프가 정상적으로 끝나는 것이 데이터 없음 신호
- Observable 에서는 onComplete() 호출
생산자가 소비자에게 에러 발생을 알릴 수있는 기능
- Iterable 에서는 순회중 예외가 발생하면 throw
- Observable 에서는 onError() 호출

이 두 가지가 추가됨으로써, ReactiveX는 Iterable과 Observable 타입을 조화시킵니다. 둘의 유일한 차이는 데이터가 흐르는 방향 입니다. 이것은 매우 중요한데, 이제 Iterable에서 할 수 있는 모든 연산을 Observable에서도 동일하게 할 수 있기 때문입니다.

[Swift] CollectionViewCell에서 이미지 요청을 보낼 때 취소될 수 있는 문제

문군_ — Tue, 8 Apr 2025 17:24:49 +0900

기존 구조에서는 CharacterListViewController에서 supabaseMager.fetchCharacters()를 통해 캐릭터 정보를 받아오고, SwiftUI 셀에서 직접 이미지 요청을 수행하였습니다.

// CharacterListViewController
private func fetchCharacters() {
    Task {
        do {
            let fetchedCharacters: [Character] = try await supabaseManager.fetchCharacter()
            characters = fetchedCharacters
            updateSnapshot()

        } catch {
            NSLog("❌ Error fetching characters: \(error)")
        }
    }
}
...
// MARK: - UICollectionViewDiffableDataSource method
func setupDiffalbeDataSource() {
    dataSource = CharacterDataSource( collectionView: characterListView.characterCollectionView)
    { collectionView, indexPath, itemIdentifier in
        let cell = collectionView.dequeueReusableCell(withReuseIdentifier: CharacterCell.reuseIdentifier, for: indexPath)
        cell.contentConfiguration = UIHostingConfiguration {
            CharacterCell(character: itemIdentifier)
        }
        cell.layer.borderWidth = 0.5
        cell.layer.cornerRadius = 5
        return cell
    }
}

struct CharacterCell: View, ReuseIdentifiable {
    var character: Character
    @State private var image: UIImage? = nil

    var body: some View {
        HStack {
            if let image {
                Image(uiImage: image)
                    .resizable()
                    .frame(width: 80, height: 80)
                    .clipShape(.rect(cornerRadius: 15))
            } else {
                ProgressView()
                    .frame(width: 80, height: 80)
                    .background(Color.gray.opacity(0.3))
                    .clipShape(.rect(cornerRadius: 15))
                    .task {
                        image = await ImageCacheManager.shared.fetch(for: character.imageURL)  // SwiftUI 셀에서 직접 요청을 수행
                    }
            }
            Spacer()
            Text(character.name)
            Spacer()
        }
        .padding()
    }
}

문제

해당 방식을 사용했을 때 이미지를 패치하고 있는 도중에 셀을 스크롤하게 되면 패치 요청이 취소되는 문제가 발생하였습니다.

원인

문제의 원인은 SwiftUI의 .task modifier의 동작 방식에 있었습니다.

task 메서드에 대한 공식 문서에 뷰가 사라지고 난 다음 자동으로 task가 취소된다. 라고 나와있었고, 이를 통해 셀이 화면에 등장할 때마다 실행되며, 셀이 사라지는 경우 해당 작업도 같이 취소된다는 것을 알았습니다.

또한, 이미지 캐싱은 비동기 작업이므로 셀 뷰의 생명주기에 의존하지 않는 위치에서 관리되어야 안정성이 보장되어 다른 방법을 생각해보았습니다.

해결방안

해당 문제를 해결하기 위해서 SwiftUI 셀에서 요청을 보내는 방법 대신, 셀 외부에서 비동기적으로 요청을 보내고, 이미지를 패치하여 변경사항이 생길 때 이를 반영하는 식으로 수정해주고자 하였습니다.

즉, 기존처럼 캐릭터 정보를 먼저 받아온 후, viewModel을 하나 두어 각 캐릭터들에 대한 요청을 ViewModel에서 수행하도록 하였습니다.
이미지 요청은 글로벌 스레드에서 동작하고, UI 업데이트만 메인 스레드에서 처리하도록 하였습니다.

변경 후 구조

// ViewModel
@MainActor
final class CharacterListViewModel: ObservableObject {
    @Published private(set) var characterImages: [Int: UIImage] = [:]

    func loadImage(for character: Character) {
        Task {
            if let image = await ImageCacheManager.shared.fetch(for: character.imageURL) {
                characterImages[character.id] = image
            }
        }
    }

    func image(for character: Character) -> UIImage? {
        return characterImages[character.id]
    }
}

// CharacterListViewController
private func fetchCharacters() {
        Task {
            do {
                let fetchedCharacters: [Character] = try await supabaseManager.fetchCharacter()
                characters = fetchedCharacters
                updateSnapshot()

                for character in characters {
                    characterViewModel.loadImage(for: character)
                }
            } catch {
                NSLog("❌ Error fetching characters: \(error)")
            }
        }
    }

// CharacterCell
struct CharacterCell: View, ReuseIdentifiable {
    var character: Character
    @ObservedObject var viewModel: CharacterListViewModel

    var body: some View {
        HStack(alignment: .center) {
            if let image = viewModel.image(for: character) {
                Image(uiImage: image)
                    .resizable()
                    .scaledToFit()
                    .frame(height: 80)
                    .clipShape(.rect(cornerRadius: 15))
            } else {
                Image("mokujin")
                    .resizable()
                    .scaledToFit()
                    .frame(height: 80)
                    .background(Color.gray.opacity(0.3))
                    .clipShape(.rect(cornerRadius: 15))
            }
            Text(character.name)
                .font(.title2)
                .padding(.leading, 5)
            Spacer()
        }
    }
}

ViewModel을 ObservableObject를 채택하게 만들어, 이미지가 저장되었는지를 관리하는 딕셔너리의 값이 변경하면 셀을 다시 그리게 하는 방식을 채택하였습니다.

[Swift] iOS 앱의 라이프 사이클 관리

문군_ — Tue, 18 Mar 2025 21:24:47 +0900

오늘은 제가 iOS 앱의 라이프 사이클 관리에 대해 공부하기 위해 공식 문서를 참고하면서 정리한 부분을 포스팅하려고 합니다!

앱의 현재 상태란?

앱의 현재 상태에 따라 앱이 언제든지 수행할 수 있는 작업과 수행할 수 없는 작업을 결정

예를 들어, 포그라운드 앱은 사용자의 주의를 끌기 때문에 CPU를 비롯한 시스템 리소스보다 우선순위를 가집니다. 반면에 백그라운드 앱은 화면 밖에 있기 때문에 가능한 한 작업을 적게 수행해야 하며, 가급적 아무것도 수행하지 않는 것이 좋습니다.

앱의 상태가 변경되면 UIKit은 적절한 델리게이트 객체의 메서드를 호출하여 사용자에게 알립니다.

iOS 13 이상: Scene 기반 앱의 생명 주기 이벤트에 응답하기 위해 UISceneDelegate 객체를 사용합니다.
iOS 12 이전: UIApplicationDelegate 객체를 사용하여 생명 주기 이벤트에 응답합니다.

생명주기(Life Cycle)란?

앱의 최초 실행부터 앱이 완전히 종료되기 까지 앱이 가지는 상태와 그 상태들 사이의 전이를 생명주기라고 합니다.

앱의 상태는 앱이 현재 어떠한 것을 할 수 있는가를 결정합니다.

앱의 생명주기(App’s Life Cycle)란?

앱의 실행 / 종료 및 앱이 Foreground / Background에 있을 때, 시스템이 발생시키는 이벤트에 의해 앱의 상태가 전환되는 일련의 과정

앱의 상태(App state)

NotRunning
1. 앱이 아직 실행되지 않았거나, 완전히 종료되어 동작하지 않는 상태
Foreground - Inactive
1. Inactive는 앱이 실행중이지만 사용자로부터 이벤트를 받을 수 없는 상태. 멀티태스킹 윈도우로 진입하거나 앱 실행중 전화, 알림 등에 의해 앱을 사용할 수 없게 되는 경우 이 상태로 진입합니다.
Foreground - Active
1. Active는 앱이 실제 실행중이고 사용자 이벤트를 받아서 상호작용할 수 있는 상태이다. 바로 Active 상태는 될 수 없으며 Inactive 상태를 거쳐 Active 상태가 됩니다.
Background - Running
1. Background는 홈 화면으로 나가거나 다른 앱으로 전환되어 현재 앱이 실질적인 동작을 하지 않는 상태입니다.
2. 예를 들어 뮤직 앱을 닫아도 재생한 음악이 계속 실행되는 경우, 사용자가 앱을 사용하지 않는 동안 서버와 데이터를 동기화 하거나 타이머가 실행되어야 하는 등의 작업을 이 상태에서 할 수 있습니다.
Background -Suspended
1. Suspended는 앱을 다시 실행했을 때 최근 작업을 빠르게 로드하기 위해서 메모리에 관련 데이터만 저장되어 있는 상태입니다.
2. 앱이 Background 상태에 진입했을 때 다른 작업을 하지 않으면 Suspended 상태로 진입하게 됩니다. (보통 2-3초 이내)

앱의 생명주기 관리

Respond to Scene-Based Life Cycle

✔️iOS 13 버전 이상: Scene 사용

앱이 Scene을 지원하는 경우 UIKit은 각각의 Scene에 대해 별도의 생명 주기 이벤트를 제공합니다.

Scene은 기기에서 실행되는 앱 UI의 한 인스턴스를 나타냅니다. 사용자는 각 앱에 대해 여러 개의 Scene을 생성하고 이를 개별적으로 표시하거나 숨길 수 있습니다.

각 Scene은 고유한 생명 주기가 있으므로 각 장면은 서로 다른 실행 상태에 있을 수 있습니다.

예를 들어 한 Scene은 foreground에 있는 반면 다른 Scene은 background에 있거나 일시 중단된 상태(suspended)일 수 있습니다.

Scene의 상태 전환

위 그림은 Scene의 상태 전환을 보여줍니다.

사용자 또는 시스템이 앱에서 새 Scene을 요청하면 UIKit은 이를 생성하고 연결되지 않은 상태(Unattached)로 전환합니다. 사용자가 요청한 Scene은 빠르게 foreground로 이동하여 화면에 표시됩니다.

시스템 요청 Scene은 일반적으로 이벤트를 처리할 수 있도록 background로 이동합니다. 예를 들어, 시스템이 위치 이벤트를 처리하기 위해 background에서 Scene을 실행할 수 있습니다.

사용자가 앱의 UI를 종료하면 UIKit은 관련 Scene을 background 상태로 이동한 다음 일시 중단된(suspended) 상태로 전환합니다.

UIKit은 언제든지 background 또는 일시 중단된(suspended) Scene의 연결을 끊어 리소스를 회수하여 해당 Scene을 연결되지 않은 상태로 되돌릴 수 있습니다.

요약
- 사용자가 새 Scene 요청 → Scene 생성 후 연결되지 않은 상태(unattached)로 전환
  - 사용자가 요청한 Scene은 빠르게 foreground로 이동하여 화면 표시
- 시스템 요청 Scene → 이벤트 처리를 위해 background에서 처리
- 사용자가 UI 종료 → 관련 Scene을 background로 이동 → 일시 중단된 상태 (suspended)로 전환
- 리소스 회수: background 또는 suspended Scene의 연결을 끊어서 리소스 회수 가능

1. 앱 실행

앱이 실행되면 앱을 화면에 보여주기 위해 모든 설정이 끝나고 다음 메서드가 호출됩니다.

application(_:didFinishLaunchingWithOptions:)
앱이 실행되고 앱을 화면에 띄우기 위한 모든 설정이 완료된 뒤, 실제로 화면에 나타나기 직전에 호출

2. Scene 연결

앱이 실행되면 UIKit에 Scene을 연결해야 합니다. Scene이 연결되고 화면에 나타나기까지 과정에서 다음과 같은 순서대로 메서드 들이 호출됩니다.

application(_:configurationForConnecting:options:)여기서 Configuration은 Scene의 delegation 객체를 지정하는 등 Scene을 연결하기 위한 정보가 들어있는 UISceneConfiguration 객체를 의미합니다. 일반적으로 info.plist에 추가된 기본값을 사용해서 생성합니다.
새로운 Scene을 만들고 UIKit과 연결하기 위한 configuration을 지정합니다.
scene(_:willConnectTo:options:)
Scene이 연결될 것임을 delegate에 알려줍니다. 기존에 application(_:didFinishLaunchingWithOptions:) 에서 했던 UIWindow 생성 작업을 이 메서드에서 할 수 있습니다. 스토리보드를 사용한다면 스토리보드에서 entry point를 찾아 내부적으로 UIWindow를 생성합니다.
sceneDidBecomeActive(_:)
앱이 Inactive 상태에서 Active 상태로 전환되었을 때 호출합니다.

3. To Background(offscreen): Active - Inactive - Background ( - Suspend)

앱 실행후 홈으로 나가게 되면 Active → Inactive → Background 상태로 상태가 전환됩니다. 이 때, SceneDelegate는 Scene에 다음 순서로 method를 호출하도록 요청합니다.

sceneWillResignActive(_:)
앱이 Active에서 Inactive 상태로 전환될 때 호출됩니다.
sceneDidEnterBackground(_:)
앱이 Background 상태로 전환되었을 때 호출합니다.

4. To Foreground(onscreen): Background - Inactive - Active

Background 상태에 있는 앱을 다시 실행하면 Background → Inactive → Active 상태로 전환됩니다. 이 때, SceneDelegate는 시스템에 다음 순서로 메서드를 호출하도록 요청합니다.

sceneWillEnterForeground(_:)
앱이 Background에서 Inactive 상태로 전환될 때 호출됩니다.
sceneDidBecomeActive(_:)
앱이 Inactive에서 Active 상태로 전환될 때 호출됩니다.

5. Scene 연결 해제

기존의 App-Based Life Cycle은 멀티태스킹 창에서 swipe up 제스처를 사용하여 앱을 종료시켰습니다. 하지만 Scene을 사용할 때는 multi window를 지원하기 때문에, 앱이 둘 이상의 scene window를 가진다면 swipe up 제스처는 앱을 종료시키지 않고 Scene을 해제시키게 됩니다. 만약 모든 Scene의 연결이 해제된다면 앱이 종료됩니다.

Scene 연결이 해제될 때는 다음과 같은 순서로 메서드가 호출됩니다.

sceneDidDisconnected(_:)
delegate에 UIKit에 연결된 Scene의 연결을 해제할 것을 요청합니다.
application(_:didDiscardSceneSessions:)
사용자가 멀티태스킹 화면(app switcher)에서 한 개 이상의 Scene을 종료시켰을 때 호출됩니다.
applicationWillTerminate(_:)
앱이 사용자에 의해 종료될 때 호출됩니다. 시스템에 의해 예기치 못한 상황에서 종료될 때는 호출되지 않습니다.

Respond to App-Based Life Cycle

iOS 12 이전 또는 Scene을 사용하지 않는다면 모든 Process / UI Life Cycle event는 AppDelegate로 전달됩니다.

1. 앱 실행: Not Running - Inactive - Active

앱이 실행되면 Not Running → Inactive → Active 로 상태가 전환됩니다. 이 때, AppDelegate는 시스템에 다음 메서드를 호출하도록 요청합니다.

application(_:didFinishLaunchingWithOptions:)
앱이 실행되고 앱을 화면에 띄우기 위한 모든 설정이 완료된 뒤, 실제로 화면에 나타나기 직전에 호출됩니다. UIWindow를 생성하는 등의 작업을 할 수 있습니다. Storyboard를 사용한다면 storyboard에서 entry point를 찾아 내부적으로 UIWindow를 생성합니다.
applicationDidBecomeActive(_:)
앱이 Inactive에서 Active 상태로 전환되었을 때 호출

2. To Background(offscreen): Active - Inactive - Background ( - Suspended)

앱 실행후 홈으로 나가게 되면 Active → Inactive → Background 상태로 상태가 전환됩니다. 이 때, AppDelegate는 Scene에 다음 순서로 method를 호출하도록 요청합니다.

applicationWillResignActive(_:)
앱이 Active에서 Inactive 상태로 전환될 때 호출됩니다.

앱이 Active에서 Inactive 상태로 전환될 때 호출됩니다.

applicationDidEnterBackground(_:)
앱이 Background 상태로 전환되었을 때 호출합니다.

3. To Foreground(onscreen): Background - Inactive - Active

Background 상태에 있는 앱을 다시 실행하면 Background → Inactive → Active 상태로 전환됩니다. 이 때, AppDelegate는 시스템에 다음 순서로 메서드를 호출하도록 요청합니다.

applicationWillEnterForeground(_:)
앱이 Background에서 Inactive 상태로 전환될 때 호출됩니다.
applicationDidBecomeActive(_:)
앱이 Inactive에서 Active 상태로 전환될 때 호출됩니다.

4. 앱 종료: (some States) - Background or Suspended - Not Running

사용자가 직접 앱을 종료하는 경우, 앱은 다시 Not Running 상태로 돌아갑니다. 이 때, AppDelegate는 시스템에 다음과 같은 메서드를 호출하도록 요청합니다.

applicationWillTerminate(_:)
앱이 사용자에 의해 종료될 때 호출됩니다. 시스템에 의해 예기치 못한 상황에서 종료될 때는 호출하지 않습니다.

Application vs. Scene

결국 두 방식의 차이점은 UI Life Cycle의 책임이 Scene으로 옮겨감의 차이입니다. AppDelegate의 메서드 이름이 application → scene으로 바뀌었을 뿐 호출 순서는 동일합니다.

Scene의 연결 유무의 차이가 존재하여 앱 실행후 scene 연결, 앱 종료는 scene은 scene 연결 해제를 먼저 해준다는 것의 차이가 존재합니다.

[Supabase] API 요청은 제대로 이루어졌으나, 응답 데이터는 비어있는 문제

문군_ — Tue, 11 Mar 2025 12:54:03 +0900

문제

let client = Supabaseclient(supabaseURL, supabaseKey)
client.from("Character")
.select()
.exectue()

해당 코드를 실행했을 때 응답 코드는 200으로 문제없이 응답은 왔으나, Table의 데이터는 들어오지 않는 문제가 발생하였습니다.

원인과 해결 과정

원인은 몇 가지가 복합적으로 존재했는데요! 문제는 다음과 같았습니다.

칼럼 네임 실수

CodingKeys로 키를 맞춰줄 때 이름을 실수하는 문제가 있었습니다!
RLS (Row Level Security)
데이터베이스에 특정 사용자나 그룹이 특정 행에만 접근할 수 있도록 하는 보안 매커니즘
Supabase의 DB에 접근하기 위해서는 Project URL과 API Key가 필요한데, API Key에는 두 가지 키가 존재합니다.
secret key의 경우 Row Level Security를 우회하여 동작하기에 secret key를 사용하는 경우 문제 없이 데이터를 받아올 수 있지만, 해당 키는 노출되었을 때 DB의 모든 것을 조작할 수 있기 때문에 클라이언트 쪽에서는 사용하지 않는 것이 바람직하다고 합니다.

그래서 해당 문제를 해결하기 위해서 public key를 사용하면서 RLS 정책을 추가하는 방식을 사용하였습니다.

해결 과정

Supabase 관리 페이지에서, Authentication -> Policies 에서 각 테이블에 대한 RLS 설정을 할 수 있습니다!

테이블 별로 두 개의 버튼으로 쿼리문을 직접 작성하지 않아도 테이블 관련 설정을 할 수가 있었는데, Disable RLS를 할 경우 public key로도 값을 잘 받아오게 할 수 있었지만, 이 경우 읽기 뿐 아니라 모든 접근 및 조작을 공개키로도 가능하게 되어 보안상의 문제가 있습니다.

따라서 Create policy 를 눌러서 우측 Template에서 원하는 권한을 추가해주면 RLS를 킨 상태에서 특정 권한만 public key로 접근이 가능하도록 할 수 있었습니다!

[Swift] CoreData를 CloudKit에 연동하기

문군_ — Tue, 18 Feb 2025 17:04:00 +0900

기존 Local CoreData 영구 저장소를 iCloud에 연동 가능하도록 수정함.

이는 기존에 NSPersistentContainer를 NSPersistentCloudKitContainer로 변경해주면 자연스럽게 CloudKit으로 사용이 가능합니다.

NSPersistentCloudKitContainer는 NSPersistentContainer를 상속받기 때문에 교체해도 아무런 문제 없이 사용이 가능합니다.

Local CoreData로 사용하던 것을 iCloud 동기화 sync 기능을 추가

현재까지 알아낸 바로는, 유저가 iCloud 연동을 원하는지 여부를 bool 값으로 저장하고 있다는 가정하에 (UserDefaults에 저장) 이 값을 바탕으로
persistentContainer(type: NSPersistentCloudKitContainer).persistentDescriptions.first로 NSPersistentDescription을 가져옵니다.
해당 description의 .cloudKitContainerOptions를 nil로 초기화 해주면 해당 영구 저장소는 iCloud를 사용하지 않습니다.
그게 아니라면 자동으로 iCloud 연동 기능을 사용하게 됩니다.

remote-notification error

cloudKit에서의 background update를 위해서는 remote notification 기능을 켜줘야 합니다.

Target -> Signing & Capabilities -> + -> Background Mode 추가 한 뒤 remote notification에 체크를 해주면 됩니다.

CloudKit 추가도 마찬가지로 Target -> Signing & Capabilities -> + -> iCloud 추가하면 됩니다.

iCloud 연동할 store 선택

저희 앱은 Default 1개의 Configuration만 사용하기 때문에 해당 Configuration을 선택한 뒤 우측 inspector에서 Used with CloudKit을 선택해주면 동기화하게 됩니다!

만약 Configurations가 없다면 NSPersistentCloudKitContainer는 첫 번째 StoreDescription과 entitlements의 첫 번째 CloudKit Container identifier를 일치시킵니다.

guard let description = persistentContainer.persistentStoreDescriptions.first
    else { throw Error.storeSetUpFailed }
    if !isSync {
        description.cloudKitContainerOptions = nil
    } else {
        description.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.kr.codesquad.boostcamp9.RetsTalk")
    }

CoreData와 CloudKit 연동은 어떻게 자연스레 되는가?

CoreData -> CloudKit

(추측으로는) 앞서

persistentContainer = NSPersistentCloudKitContainer(name: name)

를 만들어 주었고, 이로부터 CoreData는 반드시 생성이 됩니다. (올바른 name이라면)

그래서 CloudKit을 껐다가 켰을 때 container를 재생성하고 cloudKitContaierOptions를 할당해주지만,

description.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.kr.codesquad.boostcamp9.RetsTalk")

기존의 CoreData가 바뀌는 것은 아니기 때문에, 이 경우에는 Background task로 CloudKit에 전달이 되게 됩니다.

CloudKit -> CoreData

위 경우는 CloudKit에서는 사용자의 다른 계정에 주기적으로 Push Notification을 보냅니다. 그 다음 각 장치에서 시스템은 마지막 패치 이후 변경된 모든 레코드를 다운로드하고, NSManagedObject의 인스턴스로 변환하는 백그라운드 작업을 만듭니다.
CoreData는 이러한 managedObject를 local store에 저장합니다.

참고 자료

Syncing a Core Data Store with CloudKit

최소 스패닝(신장) 트리 (Minimum Spanning Tree)

문군_ — Fri, 14 Feb 2025 15:09:10 +0900

Spanning Tree

그래프 내의 모든 정점을 포함하는 트리

최소 신장 트리는 주어진 그래프의 모든 정점들을 연결하는 부분 그래프 중에서 그 가중치의 합이 최소인 트리를 말한다.

특징

사이클이 만들어지지 않아야 한다.
1. 사이클이 만들어진 경우는 불필요한 연결이 존재한다는 뜻이기 때문
전체 노드(n) -1 개의 간선으로 구성된다.
하나의 그래프에 여러 개의 최소 신장 트리가 존재할 수 있다.

최소 신장 트리의 대표적인 알고리즘으로는 크루스칼(Kruskal) 알고리즘과 프림(Prim) 알고리즘이 존재한다.

크루스칼 알고리즘 (Kruskal Algorithm)

동작 원리

선택하지 않은 간선들 중 최소 가중치인 간선을 선택
사이클이 없는 경우에만 트리에 추가
총 v-1 (정점 개수 -1)개의 간선이 선택될 때까지 반복

구성한 스패닝 트리에 사이클 발생 여부를 판단하기 위해, 분리 집합 (Disjoint Set)을 사용한다.

→ Union-Find 알고리즘 사용

→ 어떤 간선을 선택했을 때, 그 간선의 두 정점이 같은 최상위 부모를 가지면 사이클이 발생함을 알 수 있다.