안녕 젤리, iOS

구독할 때마다 달라지는 Observable? Cold vs Hot 개념 정리

젤라빈 — Tue, 24 Jun 2025 22:13:24 +0900

RxSwift의 Cold vs Hot 개념 정리

iOS 개발을 하다 보면 비동기 작업을 다룰 일이 많다.
예를 들어, 네트워크 요청을 하거나, 사용자의 버튼 탭 이벤트를 처리하고,
그에 따른 화면 UI를 업데이트하는 작업은 거의 매일 마주치는 일이다.

이럴 때 자주 쓰게 되는 것이 Observable이다.
그런데 개발을 하다 보면 다음과 같은 의문이 생길 때가 있다.

“같은 Observable인데 구독할 때마다 동작이 다르네?”
“subscribe만 했을 뿐인데 왜 두 번 요청이 나가지?”

이런 현상은 대부분 Observable이 Cold인지 Hot인지에 따라 달라지는 동작 때문이다.
이번 글에서는 RxSwift의 Cold Observable과 Hot Observable의 차이를 명확하게 짚어보고,
실제 iOS 프로젝트에서 어떻게 활용하면 좋을지도 함께 정리해보자.

Cold Observable: 구독할 때마다 새롭게 시작된다

Cold Observable은 말 그대로 ‘차가운’, 아직 시작되지 않은 상태를 의미한다.
이 옵저버블은 누군가가 구독하기 전까지는 아무 일도 하지 않는다.
그리고 구독이 발생하면 그때 비로소 동작을 시작한다.

쉽게 말하면, 녹화 방송을 틀어주는 것과 같다.
각 구독자는 자기만의 타이밍으로 방송을 처음부터 보기 시작한다.

예제

let coldObservable = Observable<Int>.create { observer in
    print("  새로운 스트림 시작")
    observer.onNext(Int.random(in: 1...100))
    observer.onCompleted()
    return Disposables.create()
}

coldObservable.subscribe(onNext: { print("  구독자 A: \($0)") })
coldObservable.subscribe(onNext: { print("  구독자 B: \($0)") })

출력 예시

  새로운 스트림 시작
  구독자 A: 42
  새로운 스트림 시작
  구독자 B: 91

subscribe가 발생할 때마다 새로운 데이터 스트림이 만들어진다.
네트워크 요청, 파일 읽기, 데이터베이스 쿼리 등 대부분의 작업은 Cold Observable로 표현된다.

Hot Observable: 이미 방송 중인 상태

Hot Observable은 누군가가 구독하기 전에도 이미 데이터가 흘러가고 있는 상태다.
즉, 실시간 생방송을 생각하면 된다.
방송이 시작된 후에 들어오면, 그 시점 이후의 데이터만 받을 수 있다.

Hot Observable을 직접 만들기 위해서는 보통 Subject를 사용한다.
가장 기본적인 예는 PublishSubject이다.

예제

let subject = PublishSubject<String>()

subject.onNext("  방송 시작 전") // 구독자가 없기 때문에 무시된다

subject.subscribe(onNext: { print("  A: \($0)") })
subject.onNext("  방송 1")

subject.subscribe(onNext: { print("  B: \($0)") })
subject.onNext("  방송 2")

출력 예시

  A:   방송 1
  A:   방송 2
  B:   방송 2

구독자 A는 방송 1부터 받았고,
구독자 B는 방송 2부터 받았다.

이처럼 구독 타이밍에 따라 받는 데이터가 다르다는 것이 Hot Observable의 특징이다.

Cold와 Hot, 언제 어떻게 써야 할까?

iOS 개발에서는 두 가지 타입의 Observable을 모두 자주 만나게 된다.
중요한 건 상황에 맞게 선택하고, 필요하다면 Cold를 Hot으로 변환해서 써야 한다는 점이다.

상황 Cold Observable Hot Observable

네트워크 요청	✅	❌
버튼 탭 이벤트	❌	✅
센서 스트림, NotificationCenter	❌	✅
캐시된 데이터 재사용	✅ (share 필요)	✅

Cold를 Hot처럼 바꾸려면?

RxSwift에서는 share() 또는 multicast() 연산자를 통해
Cold Observable을 Hot처럼 공유할 수 있다.

예를 들어, 타이머처럼 반복되는 이벤트를 여러 구독자가 함께 보려면 아래와 같이 쓴다.

let shared = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance)
    .take(3)
    .share()

shared.subscribe(onNext: { print("  A: \($0)") })

DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
    shared.subscribe(onNext: { print("  B: \($0)") })
}

출력 예시

  A: 0
  A: 1
  A: 2
  B: 2

share() 덕분에 Cold였던 Observable이 Hot처럼 공유되는 것을 확인할 수 있다.

마무리: 지금 내 Observable은 어떤 타입일까?

RxSwift를 쓰다 보면 구독자가 여러 명일 때, 의도치 않게 네트워크 요청이 중복되거나,
이벤트를 놓치는 문제가 발생할 수 있다.

이럴 때 Observable이 Cold인지, Hot인지 구분하고
필요하다면 share()나 Subject로 조정해주는 것이 중요하다.

지금 작성 중인 Observable은 구독할 때마다 새로 실행되고 있는가?
아니면 이미 흘러가는 이벤트를 받아야 하는 상황인가?

이 질문을 기준으로 Cold와 Hot을 구분해보자.
RxSwift의 흐름이 더 명확해지고, 디버깅도 훨씬 쉬워질 것이다.

다음 포스팅에서는 BehaviorSubject, ReplaySubject, 그리고 share(replay:scope:)를 활용해
데이터 캐싱 및 이벤트 공유를 어떻게 구성할 수 있는지도 다뤄볼 예정이다.

비동기 처리의 새로운 패러다임, Combine 가이드

젤라빈 — Tue, 18 Mar 2025 20:00:11 +0900

Combine, 왜 필요한가?

iOS 개발을 하다 보면 비동기 작업을 처리해야 하는 경우가 많다.
예를 들어, 네트워크 요청, UI 이벤트 처리, 데이터 스트림 관리 등이 대표적이다.

기존에는 이를 해결하기 위해 Completion Handler, NotificationCenter, KVO, Delegate 패턴 등을 사용했다.
하지만 이 방식들은 콜백 지옥(Callback Hell)을 유발하거나, 코드가 복잡해지는 문제가 있었다.

Combine은 이런 문제를 해결하고, 데이터 스트림을 선언적으로 관리할 수 있도록 도와주는 프레임워크다.
이번 글에서는 Combine의 개념, 기본 사용법, 활용하는 방법까지 하나씩 알아보자

Combine이란?

Combine은 Apple이 iOS 13부터 도입한 비동기 & 반응형 프로그래밍 프레임워크다.
RxSwift와 같은 리액티브 프로그래밍 방식을 지원하며, 데이터 스트림을 다루는 강력한 기능을 제공한다.

Combine을 활용하면:

✅ 비동기 작업을 선언적으로 처리할 수 있다.
✅ 데이터 스트림을 조합하고 변환하는 것이 쉬워진다.
✅ 콜백 기반 코드의 복잡성을 줄이고, 가독성을 높일 수 있다.

Combine의 핵심 개념

Combine에서 가장 중요한 개념 3가지는 다음과 같다.

1️⃣ Publisher(퍼블리셔) → 데이터를 방출하는 역할
2️⃣ Subscriber(서브스크라이버) → 데이터를 구독하여 처리
3️⃣ Operator(연산자) → 데이터를 변환하거나 필터링

이 개념만 이해하면 Combine을 쉽게 활용할 수 있다!

1. Publisher(퍼블리셔)

Publisher는 데이터 스트림을 생성하는 역할을 한다.
쉽게 말해, 이벤트가 발생할 때마다 데이터를 방출하는 객체다.

Combine에서 제공하는 대표적인 퍼블리셔는 다음과 같다.

✅ Just (단일 값 방출)

import Combine

let publisher = Just("Hello, Combine!")

let subscriber = publisher.sink { value in
    print("  값 수신: \(value)")
}
// 출력:   값 수신: Hello, Combine!

Just는 한 번만 값을 방출하고 끝나는 Publisher다.

✅ Timer (반복적인 값 방출)

import Combine

let timerPublisher = Timer.publish(every: 1.0, on: .main, in: .common)
    .autoconnect()

let subscription = timerPublisher.sink { value in
    print("⏳ 현재 시간: \(value)")
}

Timer를 사용하면 1초마다 새로운 값을 방출할 수 있다.

2. Subscriber(서브스크라이버)

Publisher가 데이터를 방출하면, 이를 받아서 처리하는 역할을 하는 것이 Subscriber다.

Combine에서는 두 가지 방식으로 값을 구독할 수 있다.

✅ sink (간단한 구독)

import Combine

let publisher = Just("Hello, Combine!")

let subscription = publisher.sink { value in
    print("  받은 값: \(value)")
}

sink는 가장 간단한 구독 방법으로, Publisher가 데이터를 방출할 때마다 클로저를 실행한다.

✅ assign (객체 속성에 직접 할당)

import Combine

class ViewModel {
    @Published var message: String = ""
}

let viewModel = ViewModel()
let publisher = Just("Hello, Combine!")

let subscription = publisher.assign(to: &viewModel.$message)

print(viewModel.message) // Hello, Combine!

assign을 사용하면, Publisher의 데이터를 객체의 속성에 직접 연결할 수 있다.

3. Operator(연산자)

Combine의 가장 강력한 기능 중 하나는 Operator(연산자)를 활용해 데이터 스트림을 변형할 수 있다는 것이다.
RxSwift의 map, filter, flatMap과 유사한 개념이다.

✅ map (데이터 변환)

import Combine

let publisher = Just(10)
    .map { $0 * 2 }

let subscription = publisher.sink { value in
    print("  변환된 값: \(value)")
}
// 출력:   변환된 값: 20

map을 사용하면 방출된 데이터를 변환할 수 있다.

✅ filter (조건에 맞는 값만 방출)

import Combine

let numbers = [1, 2, 3, 4, 5].publisher

let subscription = numbers
    .filter { $0 % 2 == 0 }
    .sink { value in
        print("✅ 짝수: \(value)")
    }
// 출력: ✅ 짝수: 2, ✅ 짝수: 4

filter는 조건을 만족하는 데이터만 방출하도록 필터링한다.

✅ combineLatest (두 개의 Publisher 결합)

import Combine

let publisher1 = PassthroughSubject<String, Never>()
let publisher2 = PassthroughSubject<Int, Never>()

let subscription = publisher1.combineLatest(publisher2)
    .sink { value in
        print("  결합된 값: \(value)")
    }

publisher1.send("A")
publisher2.send(1)
publisher1.send("B")
publisher2.send(2)

// 출력:
//   결합된 값: ("A", 1)
//   결합된 값: ("B", 1)
//   결합된 값: ("B", 2)

combineLatest를 사용하면 두 개의 Publisher가 방출하는 최신 값을 결합하여 제공할 수 있다.

Combine 활용하기

Combine은 비동기 네트워크 요청을 처리하는 데 특히 강력하다.
기존 URLSession과 함께 Combine을 사용하면 다음과 같이 구현할 수 있다.

import Combine

struct API {
    static func fetchData() -> AnyPublisher<string, error=""> {
        let url = URL(string: "https://jsonplaceholder.typicode.com/todos/1")!
        
        return URLSession.shared.dataTaskPublisher(for: url)
            .map { String(data: $0.data, encoding: .utf8) ?? "" }
            .receive(on: DispatchQueue.main)
            .eraseToAnyPublisher()
    }
}

let subscription = API.fetchData()
    .sink(receiveCompletion: { completion in
        switch completion {
        case .finished:
            print("✅ 완료")
        case .failure(let error):
            print("❌ 오류 발생: \(error)")
        }
    }, receiveValue: { value in
        print("  받은 데이터: \(value)")
    })
</string,>

✅ URLSession.dataTaskPublisher를 사용하면 네트워크 요청을 Combine으로 간편하게 처리할 수 있다.
✅ map, receive(on:), eraseToAnyPublisher() 등을 사용하여 데이터를 변환하고 최적화할 수 있다.

정리

이번 포스팅에서는 Combine의 기본 개념과 주요 기능을 가볍게 살펴봤다.
Combine은 비동기 작업을 선언적으로 처리할 수 있도록 도와주는 강력한 프레임워크이며,
이를 활용하면 데이터 흐름을 더욱 직관적으로 관리하고, 비동기 코드의 복잡성을 줄일 수 있다.

✅ 오늘 살펴본 핵심 개념 정리

Publisher → 데이터를 방출하는 객체
Subscriber → 데이터를 구독하여 처리하는 객체
Operator → 데이터를 변형하고 필터링하는 기능

하지만, Combine의 진짜 강점은 연산자를 활용한 데이터 조작과, 기존의 UIKit 및 SwiftUI와의 결합에 있다.
이번 글에서는 기본적인 개념과 사용법을 다뤘지만, 다음에는 더 심도 있는 주제들을 다뤄봐야겠다

지금까지 Combine을 사용해 본 적이 없다면, 간단한 프로젝트에서 직접 활용해 보자!

초저지연 실시간 스트리밍, WebRTC(Web Real-Time Communication)

젤라빈 — Mon, 17 Mar 2025 20:00:26 +0900

WebRTC(Web Real-Time Communication)는 브라우저, 모바일 앱 간에 직접 오디오, 비디오, 데이터 전송을 가능하게 하는 실시간 통신 기술이다.
RTMP나 HLS 같은 스트리밍 프로토콜과 달리, 서버를 거치지 않고 P2P(Peer-to-Peer) 방식으로 데이터를 주고받을 수 있다는 것이 가장 큰 특징이다.

현재 WebRTC는 화상 회의, 라이브 스트리밍, 온라인 게임, 원격 제어 등 실시간 상호작용이 필요한 서비스에서 널리 사용되고 있다.
이번 글에서는 WebRTC의 개념, 동작 방식, 그리고 기존 스트리밍 기술과의 차이점까지 자세히 알아보자

WebRTC의 동작 방식

WebRTC는 기본적으로 P2P(피어 투 피어) 방식으로 작동하지만, 네트워크 환경에 따라 중계 서버를 활용하는 방식도 가능하다.
기본적인 흐름은 다음과 같다.

WebRTC의 기본 흐름

1️⃣ 시그널링(Signaling) 과정

WebRTC 자체에는 P2P 연결을 설정하는 기능이 없기 때문에, 먼저 서버를 통해 연결 정보를 교환해야 한다.
이 과정에서 ICE(Interactive Connectivity Establishment) 프로토콜을 사용하여 피어 간 연결을 설정한다.

2️⃣ P2P 연결(Peer-to-Peer Connection) 설정

클라이언트 간에 직접적인 연결(P2P)을 시도한다.
하지만 방화벽, NAT(Network Address Translation) 등의 문제로 직접 연결이 어려운 경우 TURN 서버를 통해 데이터를 중계할 수도 있다.

3️⃣ 미디어 및 데이터 전송(Media & Data Transfer)

연결이 설정되면, 오디오, 비디오, 텍스트 데이터를 서버 없이 직접 주고받을 수 있다.
데이터는 SRTP(Secure Real-time Transport Protocol)을 사용하여 암호화된다.

이 방식 덕분에 초저지연(1초 미만) 실시간 통신이 가능하며, 영상 통화, 라이브 스트리밍, 게임 음성 채팅 같은 서비스에서 강력한 장점을 가진다.

WebRTC의 특징

WebRTC가 RTMP나 HLS보다 실시간 스트리밍에 더 적합한 이유는 다음과 같은 특징 덕분이다.

✅ 초저지연(ultra-low latency) 실시간 통신

HLS는 10~~30초, RTMP는 2~~5초 정도의 딜레이가 발생하지만, WebRTC는 1초 미만의 지연 시간을 제공한다.
실시간 화상 회의, 온라인 게임, 원격 제어 등에 적합하다.

✅ P2P(Peer-to-Peer) 연결

서버를 거치지 않고 브라우저 간 직접 통신이 가능하다.
대역폭을 절약할 수 있으며, 서버 비용이 줄어든다.

✅ 다양한 미디어 형식 지원

오디오, 비디오, 텍스트 데이터를 실시간으로 주고받을 수 있다.
Opus, VP8, VP9, H.264 등의 코덱을 기본 지원한다.

✅ 보안 강화

모든 데이터가 DTLS(SSL 기반의 Datagram Transport Layer Security) 및 SRTP를 사용하여 암호화된다.
E2EE(End-to-End Encryption, 종단 간 암호화) 적용 가능

✅ 브라우저 및 모바일 기본 지원

WebRTC는 HTML5와 연동되어 Chrome, Firefox, Safari 등 대부분의 브라우저에서 네이티브 지원된다.
모바일(iOS, Android)에서도 사용 가능하다.

WebRTC의 장점과 단점

WebRTC는 여러 장점을 가지지만, 몇 가지 단점도 존재한다.

✅ WebRTC의 장점

초저지연 스트리밍 가능

WebRTC는 딜레이가 1초 미만으로, RTMP, HLS보다 훨씬 빠른 실시간 통신이 가능하다.
예: 온라인 수업, 원격 회의, 라이브 채팅, 원격 게임 스트리밍

서버 부하 절감

P2P 기반으로 동작하기 때문에 서버 없이도 스트리밍 가능
트래픽이 많은 경우에도 서버 비용을 절약할 수 있다.

강력한 보안 기능 제공

모든 데이터는 기본적으로 암호화된다.

웹 브라우저에서 기본 지원

별도의 플러그인 없이 HTML5에서 WebRTC를 활용 가능

❌ WebRTC의 단점

⚠️ 네트워크 환경에 따라 품질이 달라짐

P2P 방식이므로 연결된 사용자들의 인터넷 상태에 따라 품질이 달라질 수 있다.
NAT/방화벽 문제로 인해 직접 연결이 안 되는 경우, TURN 서버를 이용해야 하며 추가적인 비용이 발생한다.

⚠️ 대규모 방송에는 부적합

1:1 또는 소규모 그룹 통신에는 최적화되어 있지만, 수천~수백만 명이 보는 방송에는 적합하지 않다.
YouTube, Netflix 같은 대규모 스트리밍 서비스에서는 HLS/CDN 기반 스트리밍을 사용한다.

⚠️ 네트워크 최적화 필요

WebRTC는 네트워크 트래픽을 자동으로 조절하지만, 고품질 영상 전송을 위해서는 추가적인 네트워크 최적화가 필요하다.

WebRTC의 사용 사례

WebRTC는 초저지연 실시간 통신이 필요한 다양한 서비스에서 활용된다.

Google Meet / Zoom / Microsoft Teams

WebRTC를 사용하여 웹 브라우저 기반 화상 회의 제공

Discord / Xbox Live / PlayStation Network

WebRTC를 활용한 실시간 음성 채팅 기능

Facebook Messenger / WhatsApp / FaceTime

모바일 기반 영상 통화에서 WebRTC 사용

온라인 교육 & 원격 제어

실시간 강의, 원격 코딩 인터뷰, 원격 데스크톱 공유

WebRTC vs RTMP vs HLS 비교

특징	WebRTC	RTMP	HLS
지연 시간	0.1~1초 (초저지연)	⏳ 2~5초 (낮음)	10~30초 (높음)
연결 방식	P2P (서버 필요 없음)	지속적인 TCP 연결	HTTP 기반 조각 파일 전송
네트워크 부하	낮음 (직접 연결)	중간 (서버 연결 유지)	높음 (대량의 HTTP 요청 발생)
대규모 방송	❌ 어려움 (TURN 서버 필요)	✅ 가능 (송출용으로 적합)	✅ 매우 적합 (CDN 활용 가능)
어댑티브 스트리밍	❌ 지원 안 함	❌ 지원 안 함	✅ 지원 (Adaptive Bitrate)
보안	✅ DTLS, SRTP 암호화 기본 제공	❌ 기본적으로 암호화 없음	✅ AES-128, DRM 지원
브라우저 지원	✅ 기본 지원 (HTML5)	❌ Flash 기반 (현재 대부분 미지원)	✅ HTML5 기본 지원
플랫폼 지원	✅ 웹, 모바일, 데스크톱	✅ 방송 송출 프로그램 (OBS 등)	✅ 웹, 모바일, 스마트 TV
적용 예시	화상 회의, 게임 음성 채팅, 원격 제어	실시간 방송 송출 (YouTube Live, Twitch)	VOD, 넷플릭스, YouTube 스트리밍

정리:

WebRTC → 화상 채팅, 게임, 초저지연 실시간 커뮤니케이션에 적합
RTMP → 방송 송출(입력) 프로토콜로 여전히 강력한 선택지
HLS → 대규모 스트리밍(출력) 및 다양한 디바이스 지원에 적합

정리

WebRTC는 초저지연 실시간 스트리밍을 가능하게 하는 강력한 기술이다.
서버 없이 P2P로 데이터를 주고받을 수 있으며, 웹 브라우저에서도 기본 지원된다는 점에서 활용성이 높다.

✅ WebRTC가 필요한 경우:

즉각적인 반응이 중요한 서비스 (예: 화상 채팅, 원격 회의, 게임 음성 채팅)
별도의 서버 없이 P2P 기반 실시간 데이터 전송이 필요할 때

현재 RTMP로 송출하고, HLS로 변환하여 제공하는 방식이 가장 일반적이지만,
즉각적인 반응이 중요한 경우 WebRTC를 활용하는 것이 최선이다

WebRTC를 직접 활용하여, 진정한 실시간 커뮤니케이션을 경험해 보자!

현대 스트리밍의 표준, HLS(HTTP Live Streaming)

젤라빈 — Fri, 14 Mar 2025 20:00:35 +0900

HLS란 무엇인가?

HLS(HTTP Live Streaming)는 Apple에서 개발한 HTTP 기반의 미디어 스트리밍 프로토콜이다.
기존의 RTMP가 저지연 스트리밍에 최적화되어 있다면, HLS는 안정성, 보안, 다양한 디바이스 지원을 위해 설계되었다.

현재 YouTube, Netflix, Twitch, Disney+ 등 대부분의 스트리밍 플랫폼에서 HLS를 표준으로 사용하고 있다.
이번 글에서는 HLS의 개념, 동작 방식, 그리고 RTMP와의 차이점까지 자세히 살펴보자!

HLS의 동작 방식

HLS는 RTMP처럼 지속적인 TCP 연결을 유지하는 방식이 아니라, 비디오 데이터를 작은 조각(Chunks)으로 나누어 HTTP를 통해 전송하는 방식이다.

HLS의 기본 흐름

1️⃣ 미디어 파일을 여러 개의 작은 조각(Chunk)으로 분할

예를 들어, 10초 길이의 비디오를 2초 단위로 나눈다.
각각의 조각은 MPEG-TS 포맷으로 저장된다.

2️⃣ 플레이리스트(Manifest) 파일을 생성

.m3u8 파일을 생성하여 비디오 조각들의 목록을 관리한다.
플레이어는 .m3u8 파일을 읽고, 해당 조각을 순차적으로 다운로드하여 재생한다.

3️⃣ 클라이언트가 HTTP 요청을 통해 필요한 조각만 가져와 재생

플레이어는 네트워크 상태에 따라 자동으로 품질을 조절(Adaptive Bitrate Streaming)하여 최적의 영상을 보여준다.

이 방식을 통해 안정적인 스트리밍을 제공할 수 있으며, 다양한 디바이스에서 HLS를 지원할 수 있게 된다.

HLS의 특징

HLS가 현재 가장 널리 사용되는 스트리밍 방식이 된 이유는 다음과 같은 장점 때문이다.

✅ HTTP 기반 전송

일반적인 웹 서버(Nginx, Apache)로 HLS 스트리밍을 제공 가능
별도의 RTMP 서버 없이, CDN(Content Delivery Network)과 쉽게 연동 가능

✅ 적응형 비트레이트 스트리밍 (ABR, Adaptive Bitrate Streaming)

네트워크 상태에 따라 자동으로 고해상도↔저해상도 변경
예를 들어, 1080p → 720p → 480p 해상도로 유동적으로 변경 가능

✅ 다양한 디바이스 지원

iOS, macOS, Android, Windows 등 모든 현대적인 웹 브라우저 및 모바일 기기에서 지원
HTML5 기반 플레이어에서도 네이티브 지원됨

✅ 보안 및 DRM 지원

AES-128 암호화를 지원하여 미디어 콘텐츠 보호 가능
DRM(Digital Rights Management)과 연동 가능 (예: Widevine, FairPlay)

✅ 캐싱 & CDN 최적화

HTTP 기반이기 때문에 CDN(Content Delivery Network)과 쉽게 통합 가능
전 세계 사용자들에게 빠르고 안정적인 미디어 제공 가능

HLS의 장점과 단점

HLS는 여러 장점을 가지지만, 몇 가지 단점도 존재한다.

✅ HLS의 장점

끊김 없는 스트리밍

HTTP 기반으로 서버와 지속적인 연결을 유지할 필요 없음
일시적인 네트워크 문제 발생 시에도 빠르게 복구 가능

어댑티브 스트리밍(Adaptive Bitrate)

네트워크 상태에 따라 자동으로 해상도를 조정하여 끊김 없이 재생 가능

범용적인 지원

iOS, Android, 웹 브라우저, 스마트 TV 등에서 기본 지원

보안 기능 강화

DRM과 암호화를 지원하여 콘텐츠 불법 다운로드 방지 가능

❌ HLS의 단점

⚠️ 높은 지연 시간 (Latency)

HLS는 비디오를 조각 단위로 전송하기 때문에 RTMP보다 지연 시간이 길다.
기본적으로 10~30초의 딜레이가 발생할 수 있음.
하지만 Low Latency HLS(LL-HLS)가 등장하면서 이 문제를 해결하는 중이다.

⚠️ 실시간 인터랙션 어려움

라이브 방송에서 시청자와의 즉각적인 상호작용이 어렵다.
예: 라이브 채팅, 게임 스트리밍, 스포츠 중계

⚠️ 서버에서 미디어 변환 필요

비디오를 조각으로 변환하는 과정이 필요하므로, 인코딩 부담이 크다.
실시간 스트리밍에서는 추가적인 서버 리소스가 필요할 수 있음.

HLS의 사용 사례

현재 대부분의 스트리밍 서비스가 HLS 기반으로 동작하고 있다.

YouTube & Netflix

HLS를 기반으로 다양한 해상도의 영상을 제공
Adaptive Bitrate Streaming 적용

Twitch & Facebook Live

RTMP로 송출된 영상을 HLS로 변환하여 시청자에게 제공
예: 방송자는 RTMP로 송출 → 서버에서 HLS로 변환 → 시청자는 HLS로 재생

iOS & macOS 기본 지원

Apple이 개발한 프로토콜이기 때문에, iOS 및 macOS에서 기본적으로 HLS를 지원

HTML5 기반 웹 스트리밍

별도의 플러그인 없이 웹 브라우저에서 HLS 스트리밍 가능

RTMP vs HLS, 어떤 차이가 있을까?

	RTMP	HLS
지연 시간	2~5초 (낮음)	10~30초 (높음)
연결 방식	지속적인 TCP 연결	HTTP 기반 조각 파일 전송
플레이어 지원	Flash 기반 (현재 대부분 미지원)	대부분의 브라우저에서 지원
적용 예시	실시간 방송 (게임, 스포츠)	VOD, 방송 송출 (YouTube, Netflix)

결론:

RTMP는 송출(입력)에 적합 (낮은 지연 시간)
HLS는 재생(출력)에 적합 (다양한 디바이스 지원, CDN 최적화)

현재 대부분의 서비스는 RTMP로 송출한 후, HLS로 변환하여 재생하는 방식으로 운영되고 있다.

정리

HLS는 현재 가장 널리 사용되는 HTTP 기반의 스트리밍 프로토콜로, 안정성, 적응형 비트레이트, 보안성 측면에서 강력한 장점을 가진다.

하지만 높은 지연 시간(Latency)이 단점으로 작용할 수 있으며, 이를 해결하기 위해 Low Latency HLS(LL-HLS) 같은 최신 기술이 발전하고 있다.

✅ HLS는 언제 사용하면 좋을까?

다양한 해상도로 안정적인 VOD(다시보기), 영화 스트리밍을 제공하고 싶을 때
CDN을 활용하여 대규모 사용자에게 스트리밍을 제공해야 할 때

✅ RTMP vs HLS, 어떻게 선택해야 할까?

실시간 송출(입력)은 RTMP,
재생(출력)은 HLS

HLS가 대세로 자리 잡은 지금, 이 프로토콜을 활용하여 최적의 스트리밍 환경을 구축해보자

iOS에서 RTMP 기반 라이브 스트리밍 구현하기

젤라빈 — Thu, 13 Mar 2025 20:00:01 +0900

라이브 스트리밍, 어떻게 동작할까?

유튜브, 트위치, 인스타그램 라이브 같은 서비스에서 실시간으로 방송을 송출하려면 RTMP(Real-Time Messaging Protocol)가 필요하다.
하지만 iOS 앱에서 직접 RTMP 스트리밍을 구현하려면 미디어 캡처, 인코딩, 전송 등의 과정이 필요하다.

이번 글에서는 iOS에서 RTMP 기반 라이브 스트리밍이 동작하는 과정과 실무 적용 방법을 알아보자!

iOS에서 RTMP 라이브 스트리밍의 기본 흐름

iOS에서 RTMP 스트리밍을 구현하려면 기본적으로 다음 4가지 단계가 필요하다.

1️⃣ 카메라 & 마이크 입력 받기
2️⃣ 비디오 & 오디오 데이터 인코딩
3️⃣ RTMP 서버로 실시간 전송
4️⃣ 뷰어(시청자)에서 재생하기

이제 각 단계별로 자세히 살펴보자!

1️⃣ 카메라 & 마이크 입력 받기

먼저, AVCaptureSession을 사용하여 카메라와 마이크에서 데이터를 가져온다.

import AVFoundation

class LiveStreamManager {
    private let captureSession = AVCaptureSession()
    private var videoOutput = AVCaptureVideoDataOutput()
    private var audioOutput = AVCaptureAudioDataOutput()
    
    func setupCaptureSession() {
        captureSession.sessionPreset = .hd1280x720
        
        //   카메라 입력 설정
        guard let camera = AVCaptureDevice.default(.builtInWideAngleCamera, for: .video, position: .front),
              let videoInput = try? AVCaptureDeviceInput(device: camera) else { return }
        captureSession.addInput(videoInput)
        
        //   마이크 입력 설정
        guard let microphone = AVCaptureDevice.default(for: .audio),
              let audioInput = try? AVCaptureDeviceInput(device: microphone) else { return }
        captureSession.addInput(audioInput)

        //   비디오 & 오디오 출력 추가
        videoOutput.setSampleBufferDelegate(self, queue: DispatchQueue(label: "videoQueue"))
        audioOutput.setSampleBufferDelegate(self, queue: DispatchQueue(label: "audioQueue"))
        captureSession.addOutput(videoOutput)
        captureSession.addOutput(audioOutput)
        
        captureSession.startRunning()
    }
}

설명

AVCaptureSession: 비디오 & 오디오 캡처 관리
AVCaptureDeviceInput: 카메라 및 마이크 입력 설정
AVCaptureVideoDataOutput, AVCaptureAudioDataOutput: 실시간 영상 & 오디오 데이터를 캡처

2️⃣ 비디오 & 오디오 인코딩

RTMP 서버로 데이터를 전송하려면 H.264 (비디오) / AAC (오디오) 코덱으로 압축해야 한다.
이 과정은 VideoToolbox와 AudioToolbox를 활용해 구현할 수 있다.

비디오 인코딩 (H.264)

비디오 프레임을 H.264 포맷으로 변환해야 한다.

import VideoToolbox

extension LiveStreamManager: AVCaptureVideoDataOutputSampleBufferDelegate {
    func captureOutput(_ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection) {
        guard let pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer) else { return }
        
        var encodedData: Data?
        let status = VTCompressionSessionEncodeFrame(
            compressionSession,
            imageBuffer: pixelBuffer,
            presentationTimeStamp: CMTimeMake(value: 0, timescale: 1),
            duration: CMTime.invalid,
            frameProperties: nil,
            infoFlagsOut: nil,
            outputHandler: { status, flags, sampleBuffer in
                if status == noErr, let sampleBuffer = sampleBuffer {
                    encodedData = extractEncodedData(from: sampleBuffer)
                }
            }
        )
        
        if let data = encodedData {
            sendToRTMPServer(data)
        }
    }
}

설명

VTCompressionSessionEncodeFrame(): H.264 인코딩
CMSampleBufferGetImageBuffer(): 프레임을 픽셀 버퍼로 변환
sendToRTMPServer(): 인코딩된 데이터를 RTMP 서버로 전송

오디오 인코딩 (AAC)

오디오 데이터는 AAC (Advanced Audio Codec)로 변환해야 한다.

import AudioToolbox

extension LiveStreamManager: AVCaptureAudioDataOutputSampleBufferDelegate {
    func captureOutput(_ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection) {
        guard let blockBuffer = CMSampleBufferGetDataBuffer(sampleBuffer) else { return }
        
        var audioData = Data()
        CMBlockBufferCopyDataBytes(blockBuffer, atOffset: 0, dataLength: CMBlockBufferGetDataLength(blockBuffer), destination: &audioData)
        
        sendToRTMPServer(audioData)
    }
}

설명

CMSampleBufferGetDataBuffer(): 오디오 데이터 추출
CMBlockBufferCopyDataBytes(): 오디오 데이터를 바이트 배열로 변환

3️⃣ RTMP 서버로 전송하기

이제 인코딩된 데이터를 RTMP 서버로 전송해야 한다.

RTMP는 FLV(Flexible Live Video) 포맷을 사용하여 데이터를 송출한다.
즉, H.264 비디오 + AAC 오디오 데이터를 RTMP 메시지로 패킹하여 서버에 전송해야 한다.

RTMP 스트리밍을 위해서는 라이브러리(LFLiveKit, HaishinKit) 를 사용할 수 있다.

✅ RTMP 연결 설정

import Network

class RTMPSocket {
    private var connection: NWConnection?
    
    func connect(to server: String, port: UInt16) {
        connection = NWConnection(host: NWEndpoint.Host(server), port: NWEndpoint.Port(rawValue: port)!, using: .tcp)
        connection?.stateUpdateHandler = { newState in
            switch newState {
            case .ready:
                print("RTMP 서버 연결 성공")
            case .failed(let error):
                print("연결 실패: \(error)")
            default:
                break
            }
        }
        connection?.start(queue: .global())
    }
    
    func sendData(_ data: Data) {
        connection?.send(content: data, completion: .contentProcessed({ error in
            if let error = error {
                print("데이터 전송 실패: \(error)")
            }
        }))
    }
}

설명

NWConnection을 사용해 RTMP 서버에 연결
sendData(_:) 메서드로 인코딩된 H.264/AAC 데이터를 전송

✅ HaishinKit 라이브러리 활용 (추천)

HaishinKit은 Swift 기반의 RTMP 라이브러리로, 간단하게 RTMP 스트리밍을 구현할 수 있다.

Podfile 추가

pod 'HaishinKit'

RTMP 스트리밍 시작

import HaishinKit

class LiveStreamManager {
    private let rtmpConnection = RTMPConnection()
    private let rtmpStream: RTMPStream
    
    init() {
        rtmpStream = RTMPStream(connection: rtmpConnection)
    }

    func startStreaming() {
        rtmpConnection.connect("rtmp://your-server/live")
        rtmpStream.publish("stream-key")
    }
}

설명

RTMPConnection(): RTMP 서버와 연결
rtmpStream.publish("stream-key"): 스트리밍 시작

4️⃣ 시청자가 스트림을 볼 수 있도록 설정

RTMP 스트림을 송출하면, 클라이언트에서 이를 재생해야 한다.
시청자가 iOS 기기에서 스트림을 볼 수 있도록, AVPlayer를 사용하여 스트림을 재생하자.

import AVKit

class LiveStreamPlayerViewController: UIViewController {
    private var player: AVPlayer?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let streamURL = URL(string: "rtmp://your-server/live/stream-key")!
        let playerItem = AVPlayerItem(url: streamURL)
        player = AVPlayer(playerItem: playerItem)
        
        let playerLayer = AVPlayerLayer(player: player)
        playerLayer.frame = view.bounds
        view.layer.addSublayer(playerLayer)
        
        player?.play()
    }
}

설명

AVPlayer를 사용해 RTMP 스트림을 재생
AVPlayerItem(url:)을 통해 RTMP URL을 입력
playerLayer를 추가하여 스트리밍 영상 출력

정리

iOS에서 RTMP 스트리밍을 직접 구현하려면 여러 단계가 필요하지만, 핵심 흐름은 다음과 같다.

1️⃣ AVCaptureSession을 사용해 카메라 & 마이크 데이터 캡처
2️⃣ VideoToolbox, AudioToolbox를 활용해 H.264 & AAC 인코딩
3️⃣ NWConnection을 사용해 RTMP 서버로 데이터 전송
4️⃣ AVPlayer를 사용해 iOS에서 스트리밍 영상 재생

이제 iOS 앱에서 직접 RTMP 라이브 스트리밍을 구현할 수 있다!
RTMP는 저지연 실시간 스트리밍에 적합하지만, WebRTC나 HLS 같은 대체 기술도 존재한다.
프로젝트에 따라 적절한 스트리밍 방식을 선택하는 것이 중요하며, RTMP는 특히 송출(입력) 용도로 강력한 선택지가 될 수 있다.

지금 바로 RTMP 서버를 설정하고, 직접 데이터를 송출하는 코드를 테스트해 보자
스스로 구축한 스트리밍 시스템을 통해 실시간 방송의 원리를 깊이 이해할 수 있을 것이다.

실시간 스트리밍의 핵심, RTMP(Real-Time Messaging Protocol)

젤라빈 — Wed, 12 Mar 2025 20:00:48 +0900

RTMP란 무엇인가?

라이브 스트리밍을 구현하다 보면 RTMP(Real-Time Messaging Protocol)라는 용어를 한 번쯤 들어봤을 것이다.
RTMP는 저지연(Low Latency) 실시간 스트리밍을 위해 설계된 프로토콜로, 현재도 YouTube Live, Twitch, Facebook Live 같은 플랫폼에서 방송 송출에 사용된다.

이번 글에서는 RTMP가 무엇인지, 어떻게 동작하는지, 그리고 실무에서 어떻게 활용할 수 있는지까지 깊이 있게 알아보자!

RTMP의 동작 방식

RTMP는 클라이언트(방송 송출자)와 서버(스트리밍 플랫폼) 간의 지속적인 TCP 연결을 통해 오디오 및 비디오 데이터를 전송한다.
스트리밍이 시작되면, 다음과 같은 과정이 진행된다.

RTMP의 기본 흐름

1️⃣ 연결 설정 (Handshaking)

클라이언트(송출 프로그램)가 RTMP 서버와 TCP(포트 1935)로 연결을 수립한다.

2️⃣ 데이터 전송 (Data Transmission)

오디오 & 비디오 데이터를 Chunk Stream 방식으로 분할해 실시간 전송한다.
비디오는 H.264, 오디오는 AAC 코덱을 사용한다.

3️⃣ 플레이백 (Playback)

시청자(클라이언트)가 RTMP 데이터를 수신하고, 이를 플레이어에서 재생한다.

이 방식을 통해 라이브 방송이 지연 없이 송출될 수 있다.

RTMP의 특징

RTMP가 실시간 스트리밍에서 많이 사용되는 이유는 다음과 같은 특징 때문이다.

✅ 저지연 스트리밍

네트워크 지연을 최소화하여 빠른 응답성을 제공한다.
특히 인터랙티브한 콘텐츠(게임 스트리밍, 실시간 이벤트)에 적합하다.

✅ 지속적인 연결 유지

TCP 기반으로 안정적인 스트리밍이 가능하다.
비디오, 오디오, 메타데이터를 동기화하여 전송할 수 있다.

✅ 데이터 압축 & 최적화

효율적인 전송을 위해 H.264(비디오), AAC(오디오) 코덱을 사용한다.

✅ 다양한 활용 가능

라이브 방송, 영상 회의, 원격 교육 등 실시간 데이터 전송이 필요한 곳에 적용할 수 있다.

RTMP의 장점과 단점

RTMP를 사용할 때 고려해야 할 장점과 단점도 알아보자.

✅ RTMP의 장점

낮은 지연 시간

라이브 방송에서 즉각적인 반응이 필요한 경우 적합하다.
예: e스포츠 중계, 게임 스트리밍

간단한 설정

오랜 기간 사용되어 왔기 때문에 다양한 플랫폼과 호환된다.

효율적인 전송 방식

Chunk Stream 방식을 사용하여 네트워크 대역폭을 최적화할 수 있다.

❌ RTMP의 단점

⚠️ Flash 기반 플레이어 필요

과거에는 Flash Player를 이용해 RTMP 스트리밍을 재생했지만, 현재 대부분의 브라우저에서 Flash 지원이 중단되었다.

⚠️ 보안 문제

기본적으로 암호화되지 않은 TCP 연결을 사용하기 때문에 보안 취약점이 존재할 수 있다.
RTMPS(RTMP + TLS)를 사용하면 보안성을 강화할 수 있다.

⚠️ HLS 등 최신 프로토콜에 밀려나는 중

RTMP는 실시간 송출에는 강하지만, 재생(Playback)은 현재 HLS(HTTP Live Streaming)로 대체되는 추세이다.

RTMP의 사용 사례

RTMP는 다음과 같은 실시간 스트리밍 서비스에서 활용된다.

유튜브 라이브 (YouTube Live)

RTMP URL과 스트림 키를 사용하여 실시간 방송 송출

트위치 (Twitch)

RTMP 프로토콜을 이용해 게임 방송을 송출

페이스북 라이브 (Facebook Live)

페이스북에서 실시간 스트리밍할 때 사용

OBS Studio / XSplit 등 방송 송출 프로그램

RTMP를 이용해 YouTube, Twitch 등으로 스트림을 전송

이처럼 RTMP는 대부분의 라이브 스트리밍 플랫폼에서 송출(입력) 프로토콜로 사용되고 있다.

RTMP vs HLS, 어떤 차이가 있을까?

현재 RTMP는 송출용으로는 많이 사용되지만, 재생(Playback) 프로토콜은 대부분 HLS로 대체되고 있다.
둘의 차이를 비교해 보자.

	RTMP	HLS
지연 시간	2~5초 (낮음)	10~30초 (높음)
연결 방식	지속적인 TCP 연결	HTTP 기반 조각 파일 전송
플레이어 지원	Flash 기반 (현재 대부분 미지원)	대부분의 브라우저에서 지원
적용 예시	실시간 방송 (게임, 인터뷰, 스포츠 중계)	VOD, 방송 송출 (YouTube, Netflix)

결론:

RTMP는 초저지연이 중요한 실시간 방송(송출)에 적합
HLS는 다양한 디바이스에서 안정적인 재생(Playback)을 위한 최적의 방식

그래서 현재는 송출(입력)은 RTMP, 재생(출력)은 HLS로 변환하여 사용하는 경우가 많다.

정리

RTMP는 오랜 역사를 가진 실시간 스트리밍 프로토콜로, 여전히 라이브 방송 송출(입력) 방식으로 널리 사용되고 있다.
하지만 Flash 지원 중단 및 HLS/WebRTC 같은 최신 기술의 등장으로, 단독으로 사용되기보다는 HLS 등과 조합하여 활용되는 추세다.

✅ RTMP의 강점은?

저지연, 안정적인 TCP 연결, 간편한 설정

✅ RTMP의 한계는?

브라우저에서 재생 지원 부족, 보안 문제

그럼에도 불구하고 RTMP는 실시간 스트리밍에서 여전히 강력한 선택지다.
지금 사용 중인 스트리밍 시스템에서 RTMP가 어떻게 동작하는지 이해하고, 적절한 기술 스택을 조합하여 최적의 스트리밍 환경을 구축해보자!

TCA(The Composable Architecture): iOS 개발의 새로운 패러다임

젤라빈 — Tue, 11 Mar 2025 20:00:14 +0900

iOS 개발에서 상태 관리(state management) 는 언제나 고민해야 할 중요한 부분이다.
특히, SwiftUI와 함께 사용될 때 상태(State)와 데이터 흐름을 어떻게 관리할 것인가? 는 더욱 중요해진다.

이 문제를 해결하는 강력한 아키텍처 패턴 중 하나가 바로 TCA(The Composable Architecture) 이다.
TCA는 Redux 스타일의 단방향 데이터 흐름을 기반으로, 앱의 상태와 로직을 예측 가능하게 관리할 수 있도록 해준다.

이번 포스팅에서는 TCA의 개념, 핵심 구조, 그리고 실무에서의 활용법까지 살펴보자!

1️⃣ TCA란?

TCA(The Composable Architecture) 는 iOS 및 SwiftUI 앱을 위한 아키텍처 패턴으로,
Point-Free 팀이 개발한 오픈소스 프레임워크다.

TCA의 주요 특징
✅ Redux 스타일의 단방향 데이터 흐름을 사용
✅ 애플리케이션 상태(State)를 중앙에서 관리
✅ Side Effect(비동기 작업) 처리가 명확함
✅ Composable(조합 가능한) 구조로, 모듈화가 용이
✅ SwiftUI와 궁합이 좋음

즉, TCA는 앱의 상태와 동작을 예측 가능하게 만들고, 테스트하기 쉬운 환경을 제공하는 아키텍처 패턴이다.

2️⃣ TCA의 핵심 개념

TCA의 구조는 크게 State(상태), Reducer(비즈니스 로직), Action(사용자 입력), Environment(외부 의존성) 로 구성된다.

[ State ]        → 앱의 상태를 저장
[ Action ]       → 사용자 입력 및 이벤트 처리
[ Reducer ]      → 액션을 받아 상태를 변경하는 로직
[ Environment ]  → 외부 서비스(API, Database 등)와의 상호작용
[ Store ]        → 전체적인 데이터 흐름을 관리하는 컨테이너

각 컴포넌트를 자세히 살펴보자.

✅ 1. State (상태)

앱의 상태를 나타내는 구조체이다.

struct CounterState: Equatable {
    var count: Int = 0
}

✅ 2. Action (사용자 입력 및 이벤트)

사용자가 버튼을 누르거나, 네트워크 요청이 완료되었을 때 발생하는 액션을 정의한다.

enum CounterAction {
    case increment
    case decrement
}

✅ 3. Reducer (비즈니스 로직)

Reducer는 Action을 받아서 State를 변경하는 로직을 담당한다.

import ComposableArchitecture

let counterReducer = Reducer<CounterState, CounterAction, Void> { state, action, _ in
    switch action {
    case .increment:
        state.count += 1
        return .none
    case .decrement:
        state.count -= 1
        return .none
    }
}

✅ 4. Store (전체 데이터 흐름 관리)

Store는 앱의 상태와 액션을 관리하는 중앙 컨테이너 역할을 한다.

let store = Store(
    initialState: CounterState(),
    reducer: counterReducer,
    environment: ()
)

✅ 5. View (UI)

SwiftUI와 함께 사용되며, Store에서 상태를 구독하고 액션을 보낸다.

import SwiftUI
import ComposableArchitecture

struct CounterView: View {
    let store: Store<CounterState, CounterAction>

    var body: some View {
        WithViewStore(self.store) { viewStore in
            VStack {
                Text("Count: \(viewStore.count)")
                    .font(.largeTitle)
                HStack {
                    Button("-") { viewStore.send(.decrement) }
                    Button("+") { viewStore.send(.increment) }
                }
            }
        }
    }
}

핵심 정리

Store는 상태를 관리하고, View는 Store의 상태를 구독하며, Reducer는 액션을 받아 상태를 변경한다.
SwiftUI의 WithViewStore 를 사용하면 Store에서 상태를 구독하고 UI를 업데이트할 수 있다.

3️⃣ TCA를 활용하는 방법

TCA를 실제 프로젝트에서 어떻게 활용할 수 있을까?
기본적인 Counter 예제에서 확장하여, 네트워크 요청을 포함한 예제를 만들어보자.

API 호출이 필요한 경우

TCA에서는 비동기 API 호출을 Effect(효과) 를 통해 처리한다.

✅ 1. State 정의

struct UserState: Equatable {
    var user: User?
    var isLoading: Bool = false
}

✅ 2. Action 정의

enum UserAction {
    case fetchUser
    case userResponse(Result<User, APIError>)
}

✅ 3. Reducer에서 API 호출 처리

let userReducer = Reducer<UserState, UserAction, APIClient> { state, action, apiClient in
    switch action {
    case .fetchUser:
        state.isLoading = true
        return apiClient.fetchUser()
            .catchToEffect()
            .map(UserAction.userResponse)

    case .userResponse(.success(let user)):
        state.isLoading = false
        state.user = user
        return .none

    case .userResponse(.failure):
        state.isLoading = false
        return .none
    }
}

✅ 4. View에서 액션 전송

struct UserView: View {
    let store: Store<UserState, UserAction>

    var body: some View {
        WithViewStore(self.store) { viewStore in
            VStack {
                if viewStore.isLoading {
                    ProgressView()
                } else if let user = viewStore.user {
                    Text("User: \(user.name)")
                } else {
                    Button("Load User") {
                        viewStore.send(.fetchUser)
                    }
                }
            }
        }
    }
}

이렇게 하면?

API 요청이 필요할 때 Effect를 사용하여 비동기 작업을 실행할 수 있다.
UI는 상태를 구독하고 자동으로 업데이트된다.

4️⃣ TCA의 장점과 단점

✅ TCA의 장점

✔ 단방향 데이터 흐름으로 인해 예측 가능성이 높다.
✔ 상태와 로직을 중앙에서 관리하여 코드의 일관성을 유지할 수 있다.
✔ SwiftUI와 완벽하게 통합되며, Combine을 활용한 비동기 처리가 용이하다.
✔ 테스트가 쉬운 구조를 제공하여 TDD(Test-Driven Development)에 적합하다.
✔ Composable(조합 가능한) 아키텍처로, 기능을 모듈화하여 재사용성이 높다.

❌ TCA의 단점

초기 학습 비용이 높다 (Redux 스타일의 개념을 이해해야 함).
소규모 프로젝트에는 다소 과할 수 있음 (단순한 앱에서는 불필요하게 복잡해질 가능성).
성능 이슈 (State가 클 경우 업데이트가 많아질 수 있음).

정리

✅ TCA(The Composable Architecture)는 단방향 데이터 흐름을 기반으로 한 강력한 상태 관리 아키텍처
✅ State, Action, Reducer, Store, Environment의 개념을 통해 명확한 구조를 제공
✅ Effect를 사용하여 비동기 API 호출과 같은 Side Effect를 처리할 수 있음
✅ SwiftUI와 함께 사용하면 강력한 조합을 이루며, 테스트가 쉬운 구조를 만들 수 있음

TCA는 처음에는 다소 복잡해 보일 수 있지만, 한 번 익숙해지면 확장성과 유지보수성이 뛰어난 코드를 작성할 수 있다.
지금 진행 중인 프로젝트에서 작은 기능부터 TCA를 도입해보면서, 어떤 이점이 있는지 직접 경험해보자

Clean Architecture - Layer Separation & Dependency Rule

젤라빈 — Mon, 10 Mar 2025 20:00:01 +0900

"코드를 기능별로 잘 나누는 것만으로 정말 좋은 아키텍처가 될까?"

아키텍처 패턴을 고민할 때 가장 중요한 것은 코드를 단순히 레이어별로 나누는 것이 아니라, 각 레이어가 올바르게 역할을 수행하고, 의존성이 잘 정리되어 있는지를 따지는 것이다.

Clean Architecture는 Layer Separation(레이어 분리) 와 Dependency Rule(의존성 규칙) 을 통해 확장성 높은 소프트웨어를 만드는 것을 목표로 한다.

1️⃣ Clean Architecture란?

Clean Architecture는 로버트 C. 마틴(Uncle Bob) 이 제안한 소프트웨어 설계 원칙으로,
애플리케이션을 책임에 따라 계층(Layer)으로 분리하고, 의존성을 내부 도메인 중심으로 흐르게 하는 구조를 말한다.

✅ 핵심 목표:

비즈니스 로직과 UI를 분리하여 유지보수성을 높인다.

의존성을 도메인 중심으로 설계하여, 외부 요소(Database, UI, Frameworks)에 영향을 덜 받도록 한다.

테스트가 용이한 구조를 만들어 단위 테스트(Unit Test)가 쉽도록 한다.

Clean Architecture는 계층 구조와 의존성 규칙(Dependency Rule) 을 기반으로 설계된다.

2️⃣ Clean Architecture의 레이어 구조

Clean Architecture는 아래와 같은 4개의 계층(Layer)으로 나뉜다.

[ UI Layer ]        → View, ViewModel (iOS에서는 SwiftUI, UIKit 등)
[ Interface Layer ] → Use Case (Interactor)
[ Domain Layer ]    → Entities (비즈니스 로직)
[ Data Layer ]      → Repository, Data Sources (DB, API)

레이어별 역할 정리

레이어	역할	예시
UI Layer (프레젠테이션 계층)	사용자 입력을 받고, 화면을 구성	ViewController, SwiftUI View
Interface Layer (Use Case 계층)	UI와 도메인 사이의 연결 역할, 비즈니스 규칙 실행	UseCase, Interactor
Domain Layer (도메인 계층)	애플리케이션의 핵심 로직, 엔티티 정의	UserEntity, ProductEntity
Data Layer (데이터 계층)	데이터 관리 (DB, API, Local Storage)	Repository, NetworkService, Database

3️⃣ Dependency Rule(의존성 규칙)

Clean Architecture에서 가장 중요한 개념은 의존성이 바깥쪽에서 안쪽으로만 흐른다는 점이다.

UI → Interface(Use Case) → Domain(Entity) → Data

✅ 의존성이 내부 도메인 중심으로 흐르는 이유

비즈니스 로직을 UI와 분리하여 UI 변경이 비즈니스 로직에 영향을 주지 않도록 한다.
외부 요소(DB, API, 프레임워크 등)에 대한 의존성을 줄여 확장성을 높인다.
단위 테스트가 용이하도록 구조화하여 유지보수성을 높인다.

즉, 핵심 비즈니스 로직은 어떤 프레임워크나 라이브러리에도 의존하지 않도록 한다!

4️⃣ Clean Architecture를 iOS 프로젝트에 적용하기

이제 Clean Architecture를 iOS 프로젝트에서 어떻게 구현할 수 있는지 살펴보자.

✅ 1. Entity (Domain Layer)

도메인 계층의 핵심 비즈니스 로직을 담당하는 엔티티(Entity)이다.

struct User {
    let id: Int
    let name: String
}

✅ 2. Use Case (Interface Layer)

비즈니스 로직을 실행하는 역할을 한다.
UI와 도메인 사이의 연결고리 역할을 하며, Repository를 사용해 데이터를 가져온다.

protocol FetchUserUseCase {
    func execute(userId: Int) async throws -> User
}

class FetchUserInteractor: FetchUserUseCase {
    private let repository: UserRepository

    init(repository: UserRepository) {
        self.repository = repository
    }

    func execute(userId: Int) async throws -> User {
        return try await repository.getUser(by: userId)
    }
}

✅ 3. Repository (Data Layer)

Repository는 데이터를 가져오는 인터페이스 역할을 한다.

protocol UserRepository {
    func getUser(by id: Int) async throws -> User
}

class UserRepositoryImpl: UserRepository {
    private let apiClient: APIClient

    init(apiClient: APIClient) {
        self.apiClient = apiClient
    }

    func getUser(by id: Int) async throws -> User {
        let response = try await apiClient.request(endpoint: "/users/\(id)")
        return User(id: response["id"] as! Int, name: response["name"] as! String)
    }
}

✅ 4. ViewModel (UI Layer)

ViewModel은 UI에서 데이터를 받아오고 상태를 관리하는 역할을 한다.

class UserViewModel: ObservableObject {
    private let fetchUserUseCase: FetchUserUseCase
    @Published var user: User?

    init(fetchUserUseCase: FetchUserUseCase) {
        self.fetchUserUseCase = fetchUserUseCase
    }

    func loadUser(userId: Int) async {
        do {
            let user = try await fetchUserUseCase.execute(userId: userId)
            DispatchQueue.main.async {
                self.user = user
            }
        } catch {
            print("Error loading user: \(error)")
        }
    }
}

✅ 5. View (UI Layer)

SwiftUI에서 ViewModel을 사용해 UI를 업데이트한다.

struct UserView: View {
    @StateObject private var viewModel = UserViewModel(fetchUserUseCase: FetchUserInteractor(repository: UserRepositoryImpl(apiClient: APIClient())))

    var body: some View {
        VStack {
            if let user = viewModel.user {
                Text(user.name)
            } else {
                ProgressView()
            }
        }
        .onAppear {
            Task {
                await viewModel.loadUser(userId: 1)
            }
        }
    }
}

5️⃣ Clean Architecture 적용 시 고려할 점

✅ 언제 적용하면 좋을까?

대규모 프로젝트에서 코드의 확장성과 유지보수성을 높이고 싶을 때
테스트가 중요한 프로젝트에서 UI와 비즈니스 로직을 분리하고 싶을 때
팀 협업이 필요한 경우 (각 레이어별로 역할이 나뉘므로 개발이 분리됨)

✅ 언제 과할 수 있을까?

작은 프로젝트에서는 계층이 많아져서 오히려 복잡성이 증가할 수도 있다.
모든 프로젝트에서 반드시 Clean Architecture를 적용할 필요는 없으며, 프로젝트의 규모와 요구사항을 고려해야 한다.

정리

✅ Clean Architecture는 비즈니스 로직과 UI를 분리하여 유지보수를 쉽게 만드는 설계 패턴이다.
✅ 핵심 개념은 Layer Separation(레이어 분리)과 Dependency Rule(의존성 규칙) 을 따르는 것!
✅ 도메인 계층이 외부 요소(UI, DB, API 등)에 의존하지 않도록 설계해야 한다.
✅ iOS에서는 Entity, UseCase, Repository, ViewModel, View로 분리하여 적용할 수 있다.
✅ 실무에서 적용할 때는 프로젝트 규모와 필요에 따라 적절히 활용하는 것이 중요하다.

Clean Architecture는 처음에는 조금 복잡해 보일 수 있지만, 한 번 익숙해지면 유지보수성과 확장성이 뛰어난 코드를 작성할 수 있다.
프로젝트에서 직접 적용해보면서 어떤 부분이 도움이 되는지 경험해보는 것이 가장 중요하다.

이제, Clean Architecture를 적용해 더 깔끔한 iOS 앱을 만들어보자!

MVVM(Model-View-ViewModel) 패턴 제대로 이해하기

젤라빈 — Fri, 7 Mar 2025 20:00:14 +0900

iOS 개발을 하다 보면 ViewController가 너무 비대해지는 문제를 자주 마주하게 된다.
네트워크 요청, UI 로직, 데이터 변환 등이 한 곳에 몰리면서 코드가 복잡해지고 유지보수가 어려워지는 문제가 발생한다.

이 문제를 해결하는 방법 중 하나가 바로 MVVM(Model-View-ViewModel) 패턴이다!
MVVM을 활용하면 코드를 더 구조적으로 분리할 수 있고, 테스트가 쉬워지며, UI 로직을 깔끔하게 정리할 수 있다.

이번 포스팅에서는 MVVM 패턴의 개념, 역할별 구조, 그리고 적용 방법까지 정리해보자.

1️⃣ MVVM이란?

✅ MVVM의 기본 개념

MVVM은 Model-View-ViewModel의 약자로, iOS 개발에서 ViewController의 책임을 줄이고 역할을 분리하기 위해 사용되는 패턴이다.

컴포넌트	역할
Model	데이터 및 비즈니스 로직을 담당
View	사용자 인터페이스(UI) 및 이벤트 처리
ViewModel	View와 Model 사이에서 데이터 변환 및 UI 업데이트를 처리

MVVM의 핵심 목표:

ViewController의 역할을 최소화하고, UI 로직을 ViewModel에서 처리
UI(View)와 비즈니스 로직(Model)을 분리하여 코드의 재사용성을 높임
데이터 바인딩(Data Binding) 기술을 활용해 View와 ViewModel을 쉽게 연결

이제 MVVM이 왜 필요한지 예제와 함께 살펴보자!

2️⃣ MVVM이 필요한 이유 (MVC의 문제점)

기존 MVC 패턴의 문제점

전통적인 iOS 개발에서는 MVC(Model-View-Controller) 패턴을 사용한다.

하지만 MVC의 가장 큰 문제는 ViewController가 너무 많은 역할을 담당하게 된다는 점이다.
이를 흔히 "Massive ViewController" 문제라고 한다.

class UserViewController: UIViewController {
    let networkService = NetworkService()
    var users: [User] = []

    override func viewDidLoad() {
        super.viewDidLoad()
        fetchUsers()
    }

    func fetchUsers() {
        networkService.getUsers { [weak self] users in
            self?.users = users
            self?.updateUI()
        }
    }

    func updateUI() {
        // UI 업데이트 코드
    }
}

문제점:

ViewController가 네트워크 요청, 데이터 변환, UI 업데이트까지 모두 담당
테스트가 어렵다 → ViewController를 유닛 테스트하려면 네트워크 로직도 함께 테스트해야 함
재사용성이 낮다 → 다른 화면에서도 유사한 로직이 필요하면 중복 코드가 발생

✅ 이 문제를 해결하는 방법이 바로 MVVM 패턴이다!

3️⃣ MVVM의 역할과 구조

MVVM을 적용하면 코드 구조가 이렇게 변경된다.

1️⃣ Model → 데이터를 나타내는 구조체 또는 클래스로, 네트워크나 데이터베이스에서 가져온 데이터를 저장
2️⃣ ViewModel → Model을 가공하여 View에 전달, UI 로직을 처리
3️⃣ View(ViewController) → ViewModel에서 제공하는 데이터를 UI에 표시

[ViewController] <------> [ViewModel] <------> [Model]

4️⃣ MVVM 적용하기

✅ 1. Model 만들기

Model은 데이터 구조를 정의하고, 네트워크나 데이터베이스에서 가져온 데이터를 저장하는 역할을 한다.

struct User {
    let id: Int
    let name: String
}

✅ 2. ViewModel 만들기

ViewModel은 데이터를 가공하고 UI 로직을 처리하는 역할을 한다.
View에서 직접 Model을 다루지 않고, ViewModel을 통해 필요한 데이터를 전달받도록 한다.

class UserViewModel {
    private let networkService = NetworkService()
    private(set) var users: [User] = []

    var onUsersUpdated: (() -> Void)?

    func fetchUsers() {
        networkService.getUsers { [weak self] users in
            self?.users = users
            self?.onUsersUpdated?()
        }
    }
}

핵심 포인트
✅ ViewModel은 Model을 직접 노출하지 않고, 필요한 데이터를 가공해서 제공
✅ onUsersUpdated 클로저를 통해 데이터가 변경되었을 때 UI를 업데이트하도록 함
✅ 네트워크 로직을 ViewController에서 분리하여 코드가 더 깔끔해짐

✅ 3. View (ViewController)

View는 UI만 담당하고, ViewModel을 통해 데이터를 받아서 UI를 업데이트한다.

class UserViewController: UIViewController {
    private let viewModel = UserViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()

        viewModel.onUsersUpdated = { [weak self] in
            self?.updateUI()
        }

        viewModel.fetchUsers()
    }

    func updateUI() {
        print("UI 업데이트: \(viewModel.users)")
    }
}

핵심 포인트
✅ ViewController는 오직 UI만 담당하며, 데이터 처리는 ViewModel에 위임
✅ ViewModel에서 데이터를 받아 updateUI()를 호출해 화면을 갱신
✅ ViewController는 가볍게 유지되어 유지보수와 테스트가 쉬워짐

5️⃣ MVVM + Combine 활용하기 (데이터 바인딩)

MVVM의 강력한 장점 중 하나는 데이터 바인딩을 활용할 수 있다는 점이다.
Combine을 사용하면 ViewModel에서 변경된 데이터를 자동으로 UI에 반영할 수 있다.

import Combine

class UserViewModel {
    private let networkService = NetworkService()
    @Published private(set) var users: [User] = []

    func fetchUsers() {
        networkService.getUsers { [weak self] users in
            self?.users = users
        }
    }
}

class UserViewController: UIViewController {
    private let viewModel = UserViewModel()
    private var cancellables = Set<AnyCancellable>()

    override func viewDidLoad() {
        super.viewDidLoad()

        viewModel.$users
            .sink { [weak self] _ in
                self?.updateUI()
            }
            .store(in: &cancellables)

        viewModel.fetchUsers()
    }
}

✅ 데이터가 변경될 때마다 UI가 자동으로 업데이트됨!

정리

✅ MVVM은 ViewController의 역할을 줄이고, UI와 비즈니스 로직을 분리하는 패턴
✅ Model → 데이터를 저장하고 관리
✅ ViewModel → 데이터를 가공하고 UI 로직을 처리
✅ View(ViewController) → ViewModel에서 제공하는 데이터를 UI에 표시
✅ MVVM을 사용하면 유지보수가 쉬워지고, 유닛 테스트가 용이해짐
✅ RxSwift, Combine을 활용하면 데이터 바인딩을 통해 UI 업데이트를 자동화할 수 있음

이제 MVVM의 개념은 이해했지만, 진짜 중요한 것은 직접 적용해보는 것이다.
이 패턴을 도입하면 프로젝트 구조가 더 깔끔해지고, 유지보수가 쉬워지는 것을 체감할 수 있다.

다음 단계로, 현재 진행 중인 프로젝트에서 ViewController의 역할이 과도한 부분을 찾아보자.
그리고 해당 로직을 ViewModel로 분리해보는 것부터 시작하면 자연스럽게 MVVM 패턴을 익힐 수 있을 것이다.

MVVM을 적용하면 더 유연하고 테스트하기 쉬운 iOS 앱을 만들 수 있다.
기존 프로젝트에서 실험해보고, 변화를 직접 경험해보는게 가장 좋은것 같다!

iOS 개발에서 의존성 주입(Dependency Injection, DI)이 중요한 이유

젤라빈 — Thu, 6 Mar 2025 20:00:18 +0900

iOS 개발을 하다 보면 ViewController에서 네트워크 요청을 직접 호출하거나, 데이터베이스를 직접 접근하는 코드를 본 적이 있을 것이다.
이렇게 하면 간단한 기능은 빠르게 구현할 수 있지만, 코드가 복잡해질수록 유지보수가 어렵고 테스트하기도 어려워진다.

이 문제를 해결하는 방법이 바로 의존성 주입(Dependency Injection, DI) 이다!
DI를 활용하면 유지보수가 쉬워지고, 유닛 테스트가 편리해지며, 코드의 결합도가 낮아져 더 유연한 아키텍처를 만들 수 있다.

이번 포스팅에서는 DI의 개념과 활용하는 방법을 정리해보겠다.

1️⃣ 의존성이란?

✅ "의존성"이 뭘까?

객체가 다른 객체를 사용할 때, 이를 "의존성(Dependency)" 이라고 한다.
예를 들어, ViewController가 NetworkService를 직접 생성해서 사용한다면, ViewController는 NetworkService에 의존한다고 볼 수 있다.

class ViewController: UIViewController {
    let networkService = NetworkService() // 직접 객체 생성
    
    override func viewDidLoad() {
        super.viewDidLoad()
        networkService.fetchData()
    }
}

이 코드의 문제점은?

ViewController가 NetworkService에 강하게 결합되어 있어서 다른 네트워크 서비스로 교체하기 어려움
유닛 테스트가 어렵다 (NetworkService를 실제로 호출하기 때문에 Mocking이 어려움)

이런 문제를 해결하려면 객체를 직접 생성하는 것이 아니라, 외부에서 주입받아야 한다.
이 개념이 바로 의존성 주입(Dependency Injection, DI) 이다.

2️⃣ 의존성 주입(Dependency Injection)이란?

✅ DI의 개념

의존성 주입(Dependency Injection) 은 객체가 직접 의존성을 생성하는 것이 아니라, 외부에서 주입받도록 하는 설계 패턴이다.

이렇게 하면

코드의 결합도가 낮아지고
다른 구현체로 쉽게 변경할 수 있으며
유닛 테스트도 쉽게 작성할 수 있다

3️⃣ 의존성 주입의 3가지 방법

DI를 적용하는 방법에는 3가지 방법이 있다.

방법	설명 코드	코드 예제
1. 생성자 주입 (Constructor Injection)	객체를 생성할 때, 의존성을 주입	init(service: NetworkService)
2. 프로퍼티 주입 (Property Injection)	객체 생성 후, 외부에서 의존성을 설정	vc.service = NetworkService()
3. 메서드 주입 (Method Injection)	특정 메서드를 호출할 때, 의존성을 주입	vc.setup(service: NetworkService())

이제 각각의 방법을 코드로 살펴보자.

✅ 1. 생성자 주입 (Constructor Injection)

가장 선호되는 방법으로, 객체가 생성될 때 의존성을 주입하는 방식이다.

protocol NetworkService {
    func fetchData()
}

class APIService: NetworkService {
    func fetchData() {
        print("네트워크에서 데이터 가져오기")
    }
}

// ✅ 생성자 주입을 사용하여 의존성 주입
class ViewController {
    let service: NetworkService
    
    init(service: NetworkService) {
        self.service = service
    }
    
    func loadData() {
        service.fetchData()
    }
}

// 사용 예제
let apiService = APIService()
let vc = ViewController(service: apiService) // 의존성을 주입
vc.loadData()

이 방법이 좋은 이유

ViewController가 NetworkService 프로토콜에만 의존 → 의존성 역전 원칙(DIP)를 준수
APIService 대신 MockService를 주입하면 유닛 테스트가 가능

class MockService: NetworkService {
    func fetchData() {
        print("Mock 데이터 가져오기")
    }
}

let mockService = MockService()
let testVC = ViewController(service: mockService) // 테스트에서 Mock 객체 주입
testVC.loadData()

언제 사용하면 좋을까?

불변(immutable) 의존성을 다룰 때 (한 번 주입되면 변경되지 않는 경우)
객체의 생명주기가 길 때 (서비스 레이어, 유틸리티 클래스 등)

✅ 2. 프로퍼티 주입 (Property Injection)

객체를 생성한 후, 외부에서 의존성을 설정하는 방식이다.

class ViewController {
    var service: NetworkService? // 처음에는 nil
    
    func loadData() {
        service?.fetchData()
    }
}

// 사용 예제
let vc = ViewController()
vc.service = APIService() // 외부에서 주입
vc.loadData()

언제 사용하면 좋을까?

의존성이 선택적(optional)일 때
뷰 컨트롤러와 같은 UI 관련 클래스에서 사용 (예: Storyboard 사용 시)

✅ 3. 메서드 주입 (Method Injection)

특정 메서드를 호출할 때 의존성을 주입하는 방식이다.

class ViewController {
    func loadData(service: NetworkService) {
        service.fetchData()
    }
}

// 사용 예제
let vc = ViewController()
vc.loadData(service: APIService()) // 실행할 때마다 다른 서비스 주입 가능

언제 사용하면 좋을까?

매번 다른 의존성을 주입해야 하는 경우 (예: 전략 패턴)
유닛 테스트에서 특정 시점에 의존성을 변경할 필요가 있을 때

4️⃣ 의존성 주입이 실무에서 중요한 이유

테스트가 쉬워진다!
- 실제 NetworkService 대신 MockService를 주입하면, 네트워크 요청 없이 테스트 가능
코드의 유연성이 증가한다!
- 네트워크 서비스 변경 시 APIService 구현체만 교체하면 됨
- DI가 없으면 ViewController를 수정해야 하는데, DI를 적용하면 기존 코드 수정 없이 가능
아키텍처 패턴과의 궁합이 좋다!
- MVVM, Clean Architecture, TCA 등의 패턴에서는 DI가 필수적
- 특히 Dependency Injection Container(예: Swinject)를 활용하면 객체 생성을 더 간편하게 관리 가능

정리

✅ 의존성(Dependency)이란? 한 객체가 다른 객체를 사용할 때의 관계
✅ 의존성 주입(DI)이란? 객체가 직접 의존성을 생성하는 것이 아니라, 외부에서 주입하는 설계 패턴
✅ DI를 적용하면 코드의 유지보수가 쉬워지고, 테스트가 간편해지며, 결합도가 낮아진다

✅ DI의 3가지 방법

생성자 주입: 객체 생성 시 의존성 주입 (가장 선호되는 방식)
프로퍼티 주입: 객체 생성 후 의존성 설정 (UI 관련 클래스에 적합)
메서드 주입: 특정 메서드 실행 시 의존성 전달 (전략 패턴에 유용)

DI를 잘 활용하면 더 유지보수하기 쉬운 iOS 앱을 만들 수 있다.
이제 직접 프로젝트에서 적용해보자!