또 만드는 한톨

onChange는 사실 조금 이상하다

thinkyside — Thu, 29 Jan 2026 12:38:07 +0900

'특정 View가 화면에 노출되는 시점'을 감지하기 위해 커스텀 ViewModifier를 구현하던 중 요상한 문제에 부딪혔습니다. 특정 값이 변화할 때를 감지하기 위해 SwiftUI에서 흔히 사용하는 `onChange` ViewModifier를 이용해 함수를 실행하는 코드였는데, 값이 분명 변화해`onChange`가 실행되었음에도 예상하는 값과 다르게 사용되는 문제였습니다.

문제의 코드는 이랬습니다!

상위 View에서 전달받은 Environment 값(containerFrame)을 받아오고
onChange에서 이 Environment 값의 변화를 감지하면,
checkVisible 함수에서 Environment 값을 이용해 화면에 노출되었는지를 검사합니다.

struct OnVisibilityViewModifier: ViewModifier {

    @Environment(\.containerFrame) private var containerFrame
    
    func body(content: Content) -> some View {
        content
            .onChange(of: containerFrame) { _ in
                checkVisible()
            }
    }
    
    private func checkVisible() {
        containerFrame... // containerFrame을 가지고 계산 어쩌구저쩌구...
    }
}

직관적으로 containerFrame 값이 `.zero`에서 `CGRect(x: 100, y: 100, width: 100, height: 100)`로 값이 변화했을 때, 우리는 checkVisible 함수에서 새로 업데이트된 값으로 계산되기를 바랄 것입니다. 하지만 전-혀 직관적이지 않게도 전혀 다른 결과를 마주하게 됩니다.

// 1. TestView
struct TestView: View {

    @State private var frame: CGRect = .zero

    var body: some View {
        VStack {
            Button("frame 업데이트") {
                frame = .init(x: 100, y: 100, width: 100, height: 100)
            }
            // 여기서 containerFrame 값 받아와서 사용할 것
            .modifier(OnVisibilityViewModifier())
        }
        // containerFrame 값 environment로 주입
        .environment(\.containerFrame, frame)
    }
}

// 2. ViewModifier
struct OnVisibilityViewModifier: ViewModifier {

    @Environment(\.containerFrame) private var containerFrame

    func body(content: Content) -> some View {
        content
            .onAppear {
                print("onAppear 클로저에서 실행한 containerFrame: \(containerFrame)")
            }
            .onChange(of: containerFrame) { _ in
                print("onChange 클로저에서 실행한 containerFrame: \(containerFrame)")
                checkVisible()
            }
    }

    private func checkVisible() {
        print("checkVisible 함수에서 실행한 containerFrame: \(containerFrame)")
    }
}

???

onChange 클로저가 호출되었다는 뜻은, 실제로 containerFrame 값이 변화했다는 의미입니다.(그래서 print가 찍히고 있구요!) 하지만 클로저 내부에서도, checkVisible 함수에서도 containerFrame 값은 여전히 기본값을 출력하고 있습니다. 대체 여기서 찍히고 있는 저 값은 어떻게 해석해야 할까요?

일단 해결해보기

위 문제를 해결하는 가장 간단한 방법은,,, 클로저에 전달된 인자를 사용하는 것입니다! 같은 값일 거라고 생각하고 당연~하게도 Environment 값에 접근해 사용하던 것을 요렇게 바꿔주면 우리가 원하는 값을 찾을 수 있게 됩니다.

struct OnVisibilityViewModifier: ViewModifier {

    @Environment(\.containerFrame) private var containerFrame

    func body(content: Content) -> some View {
        content
            .onChange(of: containerFrame) { value in
                print("onChange 클로저에서 전달 받은 containerFrame: \(value)")
                checkVisible(value) // ⭐️ 전달 받은 값을 넣어주기
            }
    }

    private func checkVisible(_ value: CGRect) {
        print("checkVisible 함수에서 전달받은 containerFrame: \(value)")
    }
}

클로저로 전달된 value와 Environment가 같은 값이 아니라니,,, 뭔가 이상합니다!

onChange는 사실 조금 이상하다?

여기서 우리가 유추할 수 있는 것은 onChange를 사용할 때 대상이 되는 참조 값(여기서는 EnvironmentValue로 주입된 containerFrame)은 변경 전 상태를, 클로저의 인자로 전달되는 값(value)은 변경 후 상태를 나타낸다는 것입니다.

애플이 작성해 둔 onChange 공식 예제에서도 아래와 같이 사용하는 것을 확인할 수 있습니다.

struct MyScene: Scene {
    @Environment(\.scenePhase) private var scenePhase
    @StateObject private var cache = DataCache()

    var body: some Scene {
        WindowGroup {
            MyRootView()
        }
        .onChange(of: scenePhase) { newScenePhase in
            if newScenePhase == .background {
                cache.empty()
            }
        }
    }
}

하지만 조금 생각해 보면 무척이나 이상하긴 구조이긴 합니다. onChange의 의미는,,, 이름에서부터 '특정 값이 변화한 시점'에 실행되어야 하는 것으로 인식되기 쉽고, 그 맥락에 따라 직관적으로 그 대상이 되는 참조 값 또한 '변화 후의 값'을 떠올리게 됩니다.

왜 이미 참조할 수 있는 값(scenePhase)이 있음에도 불구하고 굳이 굳이 클로저의 인자를 사용해야 '최신 값'에 접근할 수 있는 걸까요? 아래와 같이 작성했을 때 이상해 보이지 않는 이유도 이 때문일 것입니다.

.onChange(of: scenePhase) { _ in
    if scenePhase == .background {
        cache.empty()
    }
}

그래서 등장한 새로운 onChange

애플도 이런 문제를 인지한 것인지 iOS 17.0에서 새로운 onChange를 내놓게 됩니다! 이에 따라 기존 onChange는 Deprecated 되었고, 위에서 함께 살펴본 문제에 대해 언급하며 이유를 설명해줍니다.

Deprecated
Use onChange(of:initial:_:) or onChange(of:initial:_:) instead. The trailing closure in each case takes either zero or two input parameters, compared to this method which takes one.Be aware that the replacements have slightly different behavior. This modifier’s closure captures values that represent the state before the change. The new modifiers capture values that correspond to the new state. The new behavior makes it easier to perform updates that rely on values other than the one that caused the modifier’s closure to run.

onChange(of:initial:_:) 또는 onChange(of:initial:_:)를 사용하세요. 각 메서드의 후행 클로저는 입력 매개변수를 0개 또는 2개 받는 반면, 이 메서드는 1개만 받습니다. 대체 메서드는 동작 방식이 약간 다릅니다. 기존 modifier의 클로저는 변경 전 상태를 나타내는 값을 캡처하는 반면, 새로운 modifier는 변경 후 상태에 해당하는 값을 캡처합니다. 이러한 새로운 동작 덕분에 modifier의 클로저를 실행시킨 값이 아닌 다른 값에 의존하는 업데이트를 더 쉽게 수행할 수 있습니다.

새롭게 만들어진 onChange는 우리가 직관적으로 해석하기 쉬운 형태인 '변경 후' 상태에 해당하는 값을 캡처한다고 하는 것이 핵심입니다! 바로 테스트 해볼까요?

struct OnVisibilityViewModifier: ViewModifier {

    @Environment(\.containerFrame) private var containerFrame

    func body(content: Content) -> some View {
        content
            .onAppear {
                print("onAppear 클로저에서 실행한 containerFrame: \(containerFrame)")
            }
            .onChange(of: containerFrame) { // ⭐️ 새로운 onChange 사용
                print("onChange 클로저에서 전달 받은 containerFrame: \(containerFrame)")
                checkVisible()
            }
    }

    private func checkVisible() {
        print("checkVisible 함수에서 전달받은 containerFrame: \(containerFrame)")
    }
}

이제야 처음 의도했던 것처럼 사용이 가능해졌습니다! 클로저의 인자를 받아 사용하지 않더라도 최신 값을 잘 받아오고 있네요.

만약 변경되기 이전의 값을 받아오고 싶다면 아래와 같이 사용도 가능합니다!(레거시 onChange가 '변경 전' 값을 캡처하도록 만들어진 이유도 '변경 전' 값을 사용하는 상황을 고려해서,,, 였을까요?)

.onChange(of: containerFrame) { oldValue, newValue in
    print("변경 전: \(oldValue)")
    print("변경 후: \(newValue)")
}

iOS 16 이하에서는 여전히 주의가 필요함!

사실 최소 지원 버전이 iOS 17 이상인 프로젝트였다면 아래와 같은 노란색 에러를 없애기 위해서라도(?) 자연스럽게 문제를 해결할 수도 있었을 것입니다.

하지만,,, 제가 진행 중인 프로젝트는 iOS 16이 최소지원 버전이었고 이를 위해 레거시 onChange를 사용해야 했기 때문에 문제를 발견하기 더 어려웠지 않았나 싶습니다.(물론 근본적인 동작 방식을 알고 있었다면 == 공식 문서를 잘 읽었다면 이런 일은 일어나지 않았겠지만 말이에요)

아무튼 이번 기회에 왜 굳이 잘 동작하는(~~그렇지 않았지만~~) onChange를 다시 만들었을까? 하는 작은 의문점이 있었는데 이것도 해결하고 동작 원리도 이해하는 좋은 기회가 되었던 것 같습니다!

번외: State-Binding 값은 어떻게 동작할까?

문득 Environment 값이 아닌 State-Binding으로 이어줘도 레거시 onChange는 '변경 전' 값을 캡처할까? 라는 호기심이 생겼습니다.

struct TestView: View {

    @State private var frame: CGRect = .zero

    var body: some View {
        VStack {
            Button("frame 업데이트") {
                frame = .init(x: 100, y: 100, width: 100, height: 100)
            }
            .modifier(OnVisibilityViewModifier(containerFrame: $frame))
        }
    }
}

struct OnVisibilityViewModifier: ViewModifier {

    @Binding var containerFrame: CGRect

    func body(content: Content) -> some View {
        content
            .onAppear {
                print("onAppear 클로저에서 실행한 containerFrame: \(containerFrame)")
            }
            .onChange(of: containerFrame) { _ in
                print("onChange 클로저에서 전달 받은 containerFrame: \(containerFrame)")
                checkVisible()
            }
    }

    private func checkVisible() {
        print("checkVisible 함수에서 전달받은 containerFrame: \(containerFrame)")
    }
}

결과는,,,?

아니!!! 변경 전 값을 캡처한다면서요??! << 라고 생각할 수 있지만,,, 이것은 Environment와 State-Binding의 근본적인 동작 차이 때문일 것으로 추측하고 있습니다.

기본적으로 State-Binding은 항상 원본 값에 대한 참조, 즉 Source of Truth 원칙을 지키기 때문에 onChange에서 캡처한 시점은 '변경 전'일지 몰라도, 실제로 가져온 것은 'Source of Truth에 대한 메모리 주소 값'이기 때문에 항상 최신 값을 나타낼 수 밖에 없게 됩니다.

반면 Environment는 스냅샷 방식으로 동작하기 때문에 '변경 전 값을 복사'하게 됩니다. 이는 포스팅 본문에서 살펴본 것과 같이 애플의 의도(?)일 것 같기도 하네요,,,(변경 전 값을 사용해야 하는 상황이 있을 수 있음을 고려한 것일까요,,,)

아무튼 다시 정리하자면 iOS 16 이하 버전 + Environment 값을 사용할 때는 항상 주의, 또 주의할 것!

사이드 이펙트

thinkyside — Sun, 11 Jan 2026 18:50:21 +0900

Point-Free의 첫 번째 에피스드인 Function 편 이후 이어지는 Side Effects 편 스크립트를 기반으로 내용을 정리해봤습니다. 이번 에피소드도 감탄의 연속,,, 어떤 사고 과정을 통해 이런 방향성을 자신있게 제시할 수 있는지, 이를 근거 있게 전달할 수 있는 흐름 등의 내용이 무척 인상깊었습니다.

Introduction

지금까지 함수들이 어떻게 합성(compose)되는지 강조하며 에피소드를 진행했음.
그러나 함수의 시그니처(선언부)만으로는 포착되지 않는 수많은 동작이 존재함 → Side Effects
Side Effects는 코드 복잡성의 주된 원인 중 하나임.
- 테스트가 어려움.
- 합성이 잘 되지 않음.
Side Effects의 이러한 복잡성은 함수 합성을 적극적으로 활용하는데 있어 걸림돌이 됨.
이번 에피소드에서는 몇 가지 Side Effects의 유형을 다루고, 이것들이 왜 걸림돌이 되는지 보고, 문제를 깔끔히 해결해 볼 것임.
먼저 Side Effects가 없는 함수를 살펴보겠음.

func compute(_ x: Int) -> Int {
  return x * x + 1
}

위 함수를 호출하면 결과가 반환됨.

compute(2)  // 5

Side Effects가 없는 함수의 가장 좋은 속성은, 동일한 입력으로 몇 번을 호출하든 동일한 출력을 얻는다는 것임.

compute(2)  // 5
compute(2)  // 5
compute(2)  // 5

이러한 예측 가능성 덕분에 테스트 작성 또한 매우 간단함.

assertEqual(5, compute(2))  // ✅

만약 잘못된 예상값을 입력으로 넣으면 항상 실패할 것임.

assertEqual(4, compute(2)) // ❌
assertEqual(5, compute(3)) // ❌

이제 함수에 Side Effect를 넣어보겠음.

func computeWithEffect(_ x: Int) -> Int {
  let computation = x * x + 1
  print("Computed \(computation)")
  return computation
}

중간에 print 문을 넣었음.
이전과 동일한 입력으로 위 함수를 호출하면 동일한 출력을 얻음.

computeWithEffect(2)  // 5

하지만 콘솔을 살펴보면 여기에 추가 출력이 발생한 것을 확인할 수 있음.

Computed 5

함수 시그니처를 비교하면 computeWithEffect 는 compute 함수와 정확히 동일하지만 시그니처만으로는 설명할 수 없는 작업이 수행되고 있음.
print 기능은 외부 어딘가로 나아가 어떤 ‘변화’를 일으키고 있고, 이 경우 콘솔에 출력하는 일임.
Side Effects는 함수 본문 내부에 숨어있다는 것을 알아야 한다는 것임.
이제 이 함수에 대해 테스트를 작성해보겠음.

assertEqual(5, computeWithEffect(2))  // ✅

이 테스트 코드는 통과하지만 또 새로운 줄이 콘솔에 출력됐을 것임.

Computed 5
Computed 5

이 동작은 우리가 테스트할 수 없는 동작임.
이 상황에서는 콘솔에 print 하는 것이 별 문제가 아닌 것처럼 보일 수 있음.
하지만 디스크에 쓰기, API 요청, Analysis 트래킹과 같은 다른 Side Effects가 발생하게 되면 이야기가 달라짐.
Side Effects는 우리의 구성적 직관성(compositional intuitions)을 깨트릴 수 있음.
이전 에피소드(함수)에서 두 개의 함수가 포함된 배열에 대한 mapping이 어떻게 기존 방식과 동일할 수 있을지 논의했었음.

[2, 10].map(compute).map(compute)  // [26, 10202] 두 개의 함수를 체이닝(기존)
[2, 10].map(compute >>> compute)   // [26, 10202] 두 개의 함수를 합성(새로운 방식)

이제 이 방식처럼 computeWithEffect 함수를 사용해보겠음.

[2, 10].map(computeWithEffect).map(computeWithEffect) // [26, 10202]
[2, 10].map(computeWithEffect >>> computeWithEffect) // [26, 10202]

반환 값은 동일하지만 콘솔을 보면 출력이 동일하지 않는 것임!

Computed 5
Computed 101
Computed 26
Computed 10202
--
Computed 5
Computed 26
Computed 101
Computed 10202

Side Effects를 고려하지 않고서는 더 이상 함수 합성을 활용하기 어려울 것임.
이런 종류의 리팩토링은 실질적인 성능 최적화 수단임.
- 배열을 2번 순회하는 대신 함수 합성으로 1번만 순회하게 하는 것.
그러나 함수에 Side Effects가 있다면 실행 순서가 동일하게 유지되지 않음.
결국 Side Effects가 있는 환경에서는 성능 최적화를 진행하는 것은 코드를 오동작하게 만들 위험이 있음.

Hidden Outputs

이제 Side Effects를 제어할 수 있는 가장 간단한 방법을 알아볼 것임.
함수 본문 안에서 Side Effects를 직접 수행하는 대신, 무엇을 출력해야하는지 설명하는 값을 추가로 반환하는 것임.
함수는 여러 반환값을 가질 수 있으므로, 이를 표현하기 위해 [String] 을 모델로 사용해보겠음.

func computeAndPrint(_ x: Int) -> (Int, [String]) {
  let computation = x * x + 1
  return (computation, ["Computed \(computation)"])
}

computeAndPrint(2)  // (5, ["Computed 5"])

이제 계산 결과 뿐 아니라 print하려는 로그가 담긴 배열도 반환받게 됨.

assertEqual(
 (5, ["Computed 5"]),
  computeAndPrint(2)
) // ✅

이제 우리는 계산 결과 뿐 아니라 수행하려는 효과(Effect)에 대해서도 다룰 수 있게 됨!
이제 Side Effects가 예상치 못한 포맷이라면 테스트가 실패함.

assertEqual(
 (5, ["Computed 5"]),
  computeAndPrint(3)
) // ❌

이 함수에서 데이터는 매우 간단하지만 실제 프로덕트에서는 API 요청이나 이벤트 분석과 같은 것들을 설명하는 중요한 데이터일 수 있음을 기억해야 함.
이 방식을 활용하면 우리가 의도한 대로 Side Effects들이 준비되고 있는지 검증하는 테스트 코드를 작성할 수 있게 될 것임.
이런 관점에서 보면 외부 세계에 변화를 주는 Side Effects는 사실 함수의 감춰진(암묵적) 출력값이나 다름 없음.
프로그래밍 세계에서 무언가 ‘암묵적’이라는 것은 대개 좋은 징조가 아님.
이제 우리는 궁금해질 것임. → 그럼 Side Effects는 누가 실행하는가?
우리는 Effect를 명시적 반환 타입으로 끌어올림으로써, Effect를 실행할 책임을 함수 내부가 아닌 함수를 호출하는 주체에게 넘긴 것임.

// 1. Effect를 명시적 반환 타입으로 받고
let (computation, logs) = computeAndPrint(2)

// 2. 함수를 호출하는 주체가 특정 Action을 취할 수 있게 함.
logs.forEach { print($0) }

우리는 함수를 호출하는 주체 역시도 Side Effects를 직접 처리하고 싶지 않을 수도 있음.
그럼 그 함수를 호출한 또 다른 상위로 Side Effects를 넘기고, 넘기고, 넘길 것임.
이에 대한 해결책을 알아보기 전에, 이 문제가 정확히 어떤 것인지 구체적으로 이해할 필요가 있음.
Side Effects 문제를 드디어 해결한 것처럼 보일 수 있지만, 안타깝게도 이 과정에서 우리는 함수의 가장 중요한 특징 중 하나인 합성(Composition)을 망가뜨리고 말았음.
compute 함수는 자체적으로 forward-compose를 하기 때문에 적절함.

compute >>> compute  // (Int) -> Int

computeAndPrint 함수 또한 자체적으로 forward-compose 하기 때문에 실제로 꽤 괜찮아보임.

computeWithEffect >>> computeWithEffect  // (Int) -> Int

둘 모두 값을 파이프(|>)로 연결해 결과를 얻을 수도 있을 것.

2 |> compute >>> compute  // 26
2 |> computeWithEffect >>> computeWithEffect  // 26

물론 콘솔에 print가 찍히겠지만 말임.

Computed 5
Computed 26

하지만 사실 computeAndPrint 함수는 합성되지 않음.

❌ Cannot convert value of type '(Int) -> (Int, [String])' to expected argument type '((Int, [String])) -> (Int, [String])'

computeAndPrint 함수의 출력은 (Int, [String])이라는 튜플 형태인 반면, 입력은 그저 Int일 뿐입니다.

앞으로 우리는 이런 상황을 반복해서 마주치게 될 것.
Side Effects를 수행해야 하는 함수가 있을 때마다 그 Effect를 묘사하기 위해 반환 타입을 확장할 것이고, 그 때마다 함수 합성은 깨질 것.
우리는 이런 형태의 함수들도 다시 잘 합성될 수 있도록 새로운 방식을 고민해야함.
튜플을 반환하는 함수의 경우 이 문제를 우아하게 해결할 수 있음.

func compose<A, B, C>(
  _ f: @escaping (A) -> (B, [String]),
_ g: @escaping (B) -> (C, [String])
  ) -> (A) -> (C, [String]) {
  …
}

이 구조는 이전에 만들었던 >>> 함수와 시그니처가 매우 비슷함.
(A) -> B, (B) -> C, 그리고 (A) -> C라는 흐름은 같지만, 옆에 약간의 추가 정보(Side Effects)가 곁들여져 있을 뿐임.
우리가 가진 함수들의 타입과 사용 가능한 값들이 무엇인지 하나씩 살펴보다 보면 이 함수를 어떻게 구현해야 할지 알 수 있음.

func compose<A, B, C>(
  _ f: @escaping (A) -> (B, [String]),
  _ g: @escaping (B) -> (C, [String])
) -> (A) -> (C, [String]) {

  return { a in
    let (b, logs) = f(a)
    let (c, moreLogs) = g(b)
    return (c, logs + moreLogs)
  }
}

우리가 새로운 함수를 반환해야 한다는 사실을 알고 있으니, 우선 함수를 정의하고 입력값 a를 받아오는 것부터 시작해보겠음.
우리에게는 a를 인자로 받는 함수 f가 있으니, f에 a를 전달한 뒤 그 결과값인 b와 발생한 logs(Side Effects)들을 추출.
이제 함수 g에 들어갈 b가 생겼으니 g에 b를 넣으면 c와 logs(Side Effects)가 돌아올 것.
이제 이를 f에서 받은 logs와 함께 반환하면 될 것임.

compose(computeAndPrint, computeAndPrint)
// (Int) -> (Int, [String])

이제 우리는 computeAndPrint 함수를 두 번 호출하는 완전히 새로운 함수를 만들어냈음.
여기에 데이터를 넣으면 최종 계산 결과 뿐 아니라 각각의 실행 단계마다 누적된 모든 log(Side Effects) 기록 까지 한 번에 확인할 수 있음.

2 |> compose(computeAndPrint, computeAndPrint)
// (26, ["Computed 5", "Computed 26"])

Introducing >=>

합성 기능을 복구하고 문제를 완전히 해결한 것처럼 보이지만 2개 이상의 함수를 합성하면 꽤나 지저분해지기 시작함.

2 |> compose(
  compose(computeAndPrint, computeAndPrint),
  computeAndPrint
)

더 나쁜 점은 동일한 합성 기능을 만드는데 2가지 다른 방법이 있다는 것.

2 |> compose(
  compose(computeAndPrint, computeAndPrint),
  computeAndPrint
)
2 |> compose(
  computeAndPrint,
  compose(computeAndPrint, computeAndPrint)
)

괄호는 언제나 함수 합성의 적이었음.
그렇다면 괄호의 천적은 무엇일까? → 바로 중위 연산자(infix operator)임.

precedencegroup EffectfulComposition {
  associativity: left
  higherThan: ForwardApplication
}

이제 우리는 친숙해보이는 형태로 중위 연산자를 하나 정의해볼 수 있을 것임.

infix operator >=>: EffectfulComposition

이 연산자는 >>> 와 매우 닮았지만, 가운데 화살표를 튜브 모양의 =으로 바꿨음.
이 연산자의 이름은 피쉬(Fish)로 불리기도 함.
이제 이전에 만든 compose 함수의 이름을 이 연산자로 바꿀 수 있음.
이제 괄호를 어떻게 배치해야 할지 고민해야 하는 번거로움 없이도 Side Effects가 있는 함수들을 매끄럽게 이어붙일 수 있을 것.

func >=> <A, B, C>(
  _ f: @escaping (A) -> (B, [String]),
  _ g: @escaping (B) -> (C, [String])
) -> (A) -> (C, [String]) {

  return { a in
    let (b, logs) = f(a)
    let (c, moreLogs) = g(b)
    return (c, logs + moreLogs)
  }
}

computeAndPrint >=> computeAndPrint >=> computeAndPrint
// (Int) -> (Int, [String])

이제 값들을 여러 줄에 걸쳐 코드를 작성함으로써 물 흐르듯 자연스럽게 파이프라인을 만들 수 있음.

2
  |> computeAndPrint
  >=> computeAndPrint
  >=> computeAndPrint

함수 합성의 또다른 장점은 기존에 쓰던 연산자들과도 아주 훌륭하게 조화를 이룬다는 점.

2
  |> computeAndPrint
  >=> (incr >>> computeAndPrint)
  >=> (square >>> computeAndPrint)

이제 우리는 합성을 통해 Side Effects가 있는 함수의 결과값을 → Side Effects가 없는 순수 함수에 전달하며 자유롭게 활용할 수 있게 되었음.
비록 새로운 괄호 문제가 생기긴 했지만 이 또한 해결이 가능함.
괄호가 나타나는 위치와 그 사이의 입력 / 출력 타입을 살펴보면 순수 함수의 합성이 언제나 더 높은 우선순위를 가져야 한다는 결론에 도달하게 됨.
따라서 앞에서 만든 EffectfulComposition 우선순위 그룹을 업데이트 할 필요가 있음.

precedencegroup EffectfulComposition {
  associativity: left
  higherThan: ForwardApplication
  lowerThan: ForwardComposition
}

이제 우리는 더 이상 괄호가 필요하지 않음!

2
  |> computeAndPrint
  >=> incr
  >>> computeAndPrint
  >=> square
  >>> computeAndPrint

이제 코드의 모든 줄은 그 의미를 명확히 해주는 연산자와 함께함.
>>> 로 시작하는 줄은 Side Effects가 없는 순수 함수의 결과물을 다루고 있음을 알리고,
>=> 로 시작하는 줄은 Side Effects가 있는 연산 결과를 다루고 있음을 보여줌.
새로운 연산자를 도입했으니 우리 코드에 이 연산자를 추가할 명분을 증명할 차례임.

이 연산자가 이미 Swift에 존재하는 혹은 의미를 가지고 있는가? → X
기존에 널리 쓰이던 선례가 있고 모양이 직관적인가? → O / Haskell 이나 PureScript에서 기본으로 제공되는 연산자이며, 수많은 함수형 프로그래밍 커뮤니티에서 라이브러리로 채택하고 있음.
범용적인 연산자인가? → O / 현재는 튜플을 처리하도록 정의되어 있지만 이 연산자가 묘사하는 구조는 프로그래밍 전반에서 나타날 것.

func >=> <A, B, C>(
  _ f: @escaping (A) -> B?,
  _ g: @escaping (B) -> C?
) -> ((A) -> C?) {

  return { a in
    fatalError()  // an exercise for the viewer
  }
}

이제 튜플 대신 옵셔널을 사용해보겠음.
위 형태는 옵셔널을 반환하는 함수들을 합성할 때 유용한 연산자를 하나 얻을 수 있게 됨.
이 연산자를 활용하면 실패할 가능성이 있는 initializer 들을 매끄럽게 하나로 연결할 수 있음.

String.init(utf8String:) >=> URL.init(string:)
// (UnsafePointer<Int8>) -> URL?

덕분에 우리는 아무런 노력 없이도 실패 가능성이 있는 완전히 새로운 생성자를 얻게 되었음.
이 연산자를 활용하면 배열을 반환하는 함수들 사이의 합성 능력도 한층 더 강화할 수 있음.

func >=> <A, B, C>(
  _ f: @escaping (A) -> [B],
  _ g: @escaping (B) -> [C]
) -> ((A) -> [C]) {

  return { a in
    fatalError()  // an exercise for the viewer
  }
}

만약 Promise나 Future 타입을 사용하고 있다면 이 연산자를 활용해 프로미스를 반환하는 함수들도 아주 쉽게 합성할 수 있음.

func >=> <A, B, C>(
  _ f: @escaping (A) -> Promise<B>,
  _ g: @escaping (B) -> Promise<C>
) -> ((A) -> Promise<C>) {

  return { a in
    fatalError()  // an exercise for the viewer
  }
}

매우 강력한 타입 시스템을 가진 몇몇 언언에서는 이 연산자를 단 한번만 정의하면 모든 구현체를 즉시 얻을 수 있기도 함. → 아직 Swift에는 그런 기능이 없어서 새로운 타입이 생길 때 마다 직접 정의해 주어야 함.
하지만 덕분에 우리는 이러한 구조에 대한 직관을 기를 수 있고, 수많은 타입에 걸쳐 공유할 수 있게 되었음.
이제 >=> 연산자를 볼 때마다 우리는 이것이 어떤 종류의 Side Effects 속으로 로직을 연쇄적으로 이어주고 있다는 것을 바로 알 수 있을 것임.

Hidden Inputs

지금까지 우리는 암묵적 출력을 만들어내는 Side Effects를 살펴보고, 그 출력을 함수의 명시적 출력으로 바꿈으로써 합성 가능성을 유지한 채 Side Effects를 제어하는 방법을 알아봤음.
그런데 이것보다 조금 더 까다로운 또 다른 종류의 Side Effects가 있음.
사용자를 위한 인사말을 생성하는 아주 간단한 함수를 예시로 들어보겠음.

func greetWithEffect(_ name: String) -> String {
  let seconds = Int(Date().timeIntervalSince1970) % 60
  return "Hello \(name)! It's \(seconds) seconds past the minute."
}

greetWithEffect("Blob")
// "Hello Blob! It's 14 seconds past the minute."

이 코드를 다시 실행하면 이전과는 다른 결과값이 나올 가능성이 높음.
이는 우리가 앞서 보았던 compute 함수가 가졌던 ‘예측 가능성’과는 정반대 되는 상황임.
이런 상태에서 테스트 코드를 작성한다면 그 테스트는 거의 매번 실패하고 말 것임.

assertEqual(
  "Hello Blob! It's 32 seconds past the minute.",
  greetWithEffect("Blob")
) // ❌

이것은 특히나 골치아픈 Side Effects임.
이전 사례(암묵적 출력)에서는 적어도 출력값에 대해 테스트라도 할 수 있었지만, 이번에는 출력값이 계속 변하기 때문에 테스트 코드를 작성하는 것조차 불가능함.
print는 입력은 받지만 반환값이 없는 함수였음. 반면 이번 사례인 Date는 입력은 없지만 반환값이 있는 함수임.
이번에도 비슷한 해결책을 적용해 볼 것임.
앞서 print의 Effect를 compute 함수의 반환값으로 명시했던 것처럼, D**ate의 Effect를 함수의 인자로 명시해보는 것임.**

func greet(at date: Date, name: String) -> String {
  let seconds = Int(date.timeIntervalSince1970) % 60
  return "Hello \(name)! It's \(seconds) seconds past the minute."
}

greet(at: Date(), name: "Blob")

이 함수는 이전과 동일하게 동작하지만 한 가지 결정적인 차이점이 있음.
이제 우리가 Date를 완벽하게 통제할 수 있게 되었고, 덕분에 언제 실행하더라도 항상 통과하는 테스트 코드를 작성할 수 있게됨.

assertEqual(
  "Hello Blob! It's 39 seconds past the minute.",
  greetWithEffect(at: Date(timeIntervalSince1970: 39), name: "Blob")
) // ✅

약간의 보일러플레이트를 감수하고 테스트 가능성을 되찾아 왔음.
하지만 이제 함수를 호출할 때마다 Date를 명시적으로 넘겨줘야 하는데, 테스트 상황이 아닐 때는 이게 불필요하게 느껴질 수도 있음.
그래서 우리는 구현 세부 사항을 감추고, 호출부의 코드를 깔끔하게 유지하기 위해 기본 인자를 지정해 현재 날짜라는 의존성을 함수에 주입하고 싶은 유혹을 느낄지도 모름.

func greet(at date: Date = Date(), name: String) -> String {
  let s = Int(date.timeIntervalSince1970) % 60
  return "Hello \(name)! It's \(s) seconds past the minute."
}

greet(name: "Blob")

코드가 조금 더 깔끔해지긴 했지만 더 큰 문제가 생겼음. → 또 다시 함수 합성이 깨져버린 것.
이전의 greetWithEffect 함수는 (String) → String 이라는 깔끔한 모양 덕분에 문자열을 반환하거나 문자열을 입력으로 받는 다른 함수들과 자유롭게 결합할 수 있었음.

func uppercased(_ string: String) -> String {
  return string.uppercased()
}

위 함수는 greetWithEffect 함수와 멋지게 합성될 수 있음.

uppercased >>> greetWithEffect
greetWithEffect >>> uppercased

또한 파이프로 연결해 각 합성에 대해 서로 다른 동작을 얻을 수도 있음.

"Blob" |> uppercased >>> greetWithEffect
// "Hello BLOB! It's 56 seconds past the minute."
"Blob" |> greetWithEffect >>> uppercased
// "HELLO BLOB! IT'S 56 SECONDS PAST THE MINUTE."

그러나 greet 함수의 경우 합성이 불가능함.

"Blob" |> uppercased >>> greet
"Blob" |> greet >>> uppercased
// Cannot convert value of type '(Date, String) -> String' to expected argument type '(_) -> _'

함수가 2개의 입력을 받게 되면서 다른 함수의 출력값을 이 함수로 직접 연결할 방법이 사라졌음.
하지만 Date의 입력을 잠시 제쳐두고 보면, 여전히 그 내부에는 (String) → String 이라는 모양이 숨어있음을 알 수 있음.
사실 시그니처에서 Date를 분리해낼 수 있는 묘수가 있는데, greet 함수가 Date를 먼저 입력받되, 그 결과로 실제 인사말 로직을 처리하는 새로운 (String) → String 함수를 반환하도록 구조를 바꾸는 것.

func greet(at date: Date) -> (String) -> String {
  return { name in
    let s = Int(date.timeIntervalSince1970) % 60
    return "Hello \(name)! It's \(s) seconds past the minute."
  }
}

이제 Date와 함께 greeting 함수를 호출해 완전히 새로운 (String) → String 함수를 얻을 수 있음.

greet(at: Date())  // (String) -> String

이 함수는 합성이 가능함!

uppercased >>> greet(at: Date())  // (String) -> String
greet(at: Date()) >>> uppercased  // (String) -> String

이제 파이프를 이용해 값을 얻을 수도 있음!

"Blob" |> uppercased >>> greet(at: Date())
// "Hello BLOB! It's 37 seconds past the minute."
"Blob" |> greet(at: Date()) >>> uppercased
// "HELLO BLOB! IT'S 37 SECONDS PAST THE MINUTE."

우리는 합성과 테스트 가능성을 모두 복구할 수 있게 되었음.

assertEqual(
  "Hello Blob! It's 37 seconds past the minute.",
  "Blob" |> greet(at: Date(timeIntervalSince1970: 37))
) // ✅

드디어 우리는 테스트가 불가능했던 그 context를 함수의 입력값으로 옮김으로써 Side Effects를 제어하는데 성공했음.
이것은 우리가 앞서 보았던 Side Effects 사례와 정확히 대칭을 이루는 방식임.
이전 Side Effects는 외부 세계에 영향을 주어 변화를 일으키는 ‘암묵적 출력’
이번 Side Effects는 외부 세계의 상태에 의존하는 ‘암묵적 입력’
모든 Side Effects는 결국 이 2가지 형태 중 하나로 나타나게 됨.

Mutation

이제 상태 변경(Mutation)이라는 아주 특수한 형태의 Side Effects를 자세히 분석해보겠음.
우리 모두 코드를 작성하며 상태 변경을 다뤄왔지만, 이는 종종 코드를 매우 복잡하게 만듦.
다행히 Swift는 상태 변경이 언제, 어디서 발생하는지 제어하고 명확히 기록할 수 있도록 돕는 타입 수준의 기능들을 제공함.
상태 변경이 얼마나 지저분해질 수 있는지 보여주는 예시를 가져왔음.

let formatter = NumberFormatter()

func decimalStyle(_ format: NumberFormatter) {
  format.numberStyle = .decimal
  format.maximumFractionDigits = 2
}

func currencyStyle(_ format: NumberFormatter) {
  format.numberStyle = .currency
  format.roundingMode = .down
}

func wholeStyle(_ format: NumberFormatter) {
  format.maximumFractionDigits = 0
}

여기 Foundation 프레임워크에서 제공하는 NumberFormatter와 이 Formatter에 특정 스타일을 입혀주는 여러 함수가 있음.
이 스타일링 함수들을 사용하려면 우리가 만든 Formatter 인스턴스에 직접 적용하기만 하면 됨.

decimalStyle(formatter)
wholeStyle(formatter)
formatter.string(for: 1234.6)  // "1,235"

currencyStyle(formatter)
formatter.string(for: 1234.6)  // "$1,234"

그런데 여기서 아까 사용했던 첫 번째 Formatter 설정들을 다시 적용하려고 하면 문제가 생김. → 이전 함수들이 남긴 설정값이 객체에 그대로 남아 있기 때문

decimalStyle(formatter)
wholeStyle(formatter)
formatter.string(for: 1234.6)  // "1,234"

출력값이 “1,235” 에서 “1,234” 로 바뀌어 버렸음. → 바로 상태 변경 때문.
currencyStyle 함수가 저지른 변경 사항이 Formatter의 다른 용도에까지 스며들게 된 것.
이런 버그는 규모가 큰 프로젝트에서 정말 추적하기 힘든 골칫덩이가 됨.
이것이 바로 상태 변경이 까다로운 이유.
이전의 모든 코드가 무슨 짓을 했는지 일일히 추적해 보지 않고서는 지금 내 눈앞의 코드 한 줄이 정확히 어떤 동작을 할지 알 방법이 없기 때문.
사실 상태 변경은 우리가 앞서 만났던 2가지 Side Effects가 합쳐진 형태임.
함수 사이에 주고 받는 ‘변경 가능한 데이터’는 그 자체로 암묵적 입력이자, 동시에 암묵적 출력이 되는 것!
우리가 이런 문제를 겪는 이유는 NumberFormatter가 참조(Reference) 타입이기 때문.
Swift에서 class는 참조 타입임.
참조 타입의 인스턴스는 단 하나의 객체이고, 이 객체의 상태가 바뀌면 참조를 가진 코드 베이스의 모든 곳이 영향을 받게 됨.
어떤 코드들이 동일한 참조를 공유하고 있는지 추적할 쉬운 방법이 없기에, 상태 변경이 개입되는 순간 혼란이 가중되는 것.
만약 이 예제 코드가 실제 앱에 쓰였고 새로운 기능을 개발하면서 이 Formatter에 의존했다면 완전히 엉뚱한 곳에서 미묘한 버그들이 기어 나오기 시작했을 것.
이제 이 코드를 값(Value) 타입을 사용하는 방식으로 리팩토링 해볼 것.
먼저 NumberFormatter에서 수행하던 설정 작업들을 감싸줄 수 있는 struct를 만드는 것부터 시작해보겠음.

struct NumberFormatterConfig {
  var numberStyle: NumberFormatter.Style = .none
  var roundingMode: NumberFormatter.RoundingMode = .up
  var maximumFractionDigits: Int = 0

  var formatter: NumberFormatter {
    let result = NumberFormatter()
    result.numberStyle = self.numberStyle
    result.roundingMode = self.roundingMode
    result.maximumFractionDigits = self.maximumFractionDigits
    return result
  }
}

이 struct는 적절한 기본값을 가지고 있으며, 새롭고 ‘정직한’(honest) NumberFormatter를 뽑아낼 수 있는 계산 속성인 formatter를 제공함.
이제 기존의 스타일링 함수들을 NumberFormatterConfig 를 사용해 업데이트하면 어떤 모습이 될까?

func decimalStyle(
  _ format: NumberFormatterConfig
) -> NumberFormatterConfig {
  var format = format
  format.numberStyle = .decimal
  format.maximumFractionDigits = 2
  return format
}

func currencyStyle(
  _ format: NumberFormatterConfig
) -> NumberFormatterConfig {
  var format = format
  format.numberStyle = .currency
  format.roundingMode = .down
  return format
}

func wholeStyle(
  _ format: NumberFormatterConfig
) -> NumberFormatterConfig {
  var format = format
  format.maximumFractionDigits = 0
  return format
}

각 스타일링 함수는 NumberFormatterConfig 를 인자로 받은 뒤 var 키워드를 사용해 이를 복사함.
그리고 지역 복사본(local copy)의 값을 변경한 뒤 호출자에게 다시 반환하는 방식임.
이 방식을 실제로 사용하는 모습은 이전과 조금 달라진 것.

let config = NumberFormatterConfig()

wholeStyle(decimalStyle(config))
  .formatter
  .string(for: 1234.6)
// "1,235"

currencyStyle(config)
  .formatter
  .string(for: 1234.6)
// "$1,234"

wholeStyle(decimalStyle(config))
  .formatter
  .string(for: 1234.6)
// "1,235"

이번에는 config를 스타일링 함수에 전달할 때마다 새로운 복사본을 받게 되어 아까 버그를 고칠 수 있게 될 것임.
사실 참조 타입에서도 이와 비슷하게 처리할 방법이 있긴함. → NSCopying 프로토콜을 구현한 class들에서 copy 메서드를 호출해 복사본을 만들고 이를 명시적으로 반환해주는 것.

func decimalStyle(_ format: NumberFormatter) -> NumberFormatter {
  let format = format.copy() as! NumberFormatter
  format.numberStyle = .decimal
  format.maximumFractionDigits = 2
  return format
}

하지만 안타깝게도 참조 타입을 복사하는 위 방식은, 원본 Formatter를 변경하지 않았다는 것을 컴파일러가 보장해 주지 않음.
또한 호출자가 복사본을 받았다고 생각하고 마음껏 상태를 변경하기 시작하면 복잡성은 더 커질 수도 있을 것임.
하지만 참조 타입은 매번 복사할 필요가 없기 때문에 분명 성능적 이점이 있음.
다행히도 Swift는 값 타입을 사용하면서도 성능을 챙길 수 있게 방법을 만들어뒀음 → inout 키워드임.

func inoutDecimalStyle(_ format: inout NumberFormatterConfig) {
  format.numberStyle = .decimal
  format.maximumFractionDigits = 2
}

func inoutCurrencyStyle(_ format: inout NumberFormatterConfig) {
  format.numberStyle = .currency
  format.roundingMode = .down
}

func inoutWholeStyle(_ format: inout NumberFormatterConfig) {
  format.maximumFractionDigits = 0
}

이 방식은 NumberFormatter의 상태를 직접 변경하던 원래 방식과 매우 비슷해보임.
값을 일일이 복사하거나 다시 반환할 걱정 없이 그 자리에서 즉시 상태를 바꿀 수 있음.

let config = NumberFormatterConfig()

inoutDecimalStyle(config)
inoutWholeStyle(config)
config.formatter.string(from: 1234.6)

하지만 컴파일 에러가 발생했음!

Cannot pass immutable value as inout argument: 'config' is a 'let' constant

Swift가 var로 바꾸라고 제안해주는 것.

var config = NumberFormatterConfig()

inoutDecimalStyle(config)
inoutWholeStyle(config)
config.formatter.string(from: 1234.6)

하지만 충분하지 않음. 또 컴파일 에러가 발생함.

Passing value of type 'NumberFormatterConfig' to an inout parameter requires explicit '&'

Swift가 데이터를 변경하는 것에 동의하는 것에 대한 표시를 하도록 하는 것.

inoutDecimalStyle(&config)
inoutWholeStyle(&config)
config.formatter.string(from: 1234.6)  // "1,235"

다른 스타일링 함수에도 이와 같이 적용할 수 있음.

inoutCurrencyStyle(&config)
config.formatter.string(from: 1234.6)  // "$1,234"

inoutDecimalStyle(&config)
inoutWholeStyle(&config)
config.formatter.string(from: 1234.6)  // "1,234"

다시 버그가 나타났음. → 그러나 이번에는 상황이 좀 다름! → 지금 우리 코드에는 상태 변경에 대한 수많은 문법적 장치들이 깔려 있기 때문.
덕분에 이런 종류의 버그를 추적하기 훨씬 쉬워졌을 것.
상태 변경이 일어나는 위치와 그 영향 범위를 제어할 수 있도록 Swift가 타입 수준의 기능을 제공한다는 점은 정말 훌륭함.
하지만 이 기능을 제대로 활용하려면 여전히 해결해야 하는 문제가 있음. → 이전에 우리가 사용했던 매번 새로운 복사본을 반환하던 스타일링 함수들은 아주 깔끔한 형태를 가지고 있었음.

(NumberFormatterConfig) -> NumberFormatterConfig

위 함수들은 입력과 출력의 타입이 서로 같음.
즉, 이들끼리 자유롭게 합쳐질 수 있을 뿐 아니라 NumberFormatterConfig를 반환하거나 입력으로 받는 그 어떤 함수들과도 완벽하게 결합될 수 있다는 뜻!

decimalStyle >>> currencyStyle
// (NumberFormatterConfig) -> NumberFormatterConfig

이제 우리는 작은 조각들을 합쳐서 만든 완전히 새로운 스타일링 함수를 갖게 되었음.
반면 아까 살펴본 inout 함수들은 이런 모양을 갖추고 있지 않음.
입력과 출력의 타입이 맞지 않아서 일반적인 함수들과는 합성이 되지 않음.
하지만 두 방식 모두 담고 있는 로직은 동일하기 때문에 분명 연결할 방법이 있을 것.
입력과 출력 타입이 같은 일반 함수를 inout 함수로 변환해주는 toInout 이라는 함수를 정의해 볼 것.

func toInout<A>(
  _ f: @escaping (A) -> A
) -> ((inout A) -> Void) {

  return { a in
    a = f(a)
  }
}

또한 역변환을 수행하는 fromInout 함수를 정의할 수 있음.

func fromInout<A>(
  _ f: @escaping (inout A) -> Void
) -> ((A) -> A) {

  return { a in
    var copy = a
    f(&copy)
    return copy
  }
}

여기서 우리가 알 수 있는 점은 (A) → A 형태의 함수와 (inout A) → Void 형태의 함수 사이에는 아주 자연스러운 대응 관계가 존재한다는 점임.
(A) → A 함수들은 매우 우아하게 합성되는 특징이 있는데, 이런 대응 관계를 잘 활용한다면 (inout A) → Void 함수들 역시 그 강력한 합성 능력을 공유할 수 있을 것임.

Introducing <>

비록 (A) → A 형태의 함수들이 >>> 연산자로 합성되는 것을 확인했지만, 이 연산자를 그대로 재사용하지는 않을 것.
>>>는 허용하는 범위가 너무 넓기 때문.
우리는 그보다 훨씬 더 제약이 명확한, 즉 ‘단일 타입’(Single Type) 간의 합성에 집중하려고 함.
자 그럼 새로운 연산자를 정의해보겠음.

precedencegroup SingleTypeComposition {
  associativity: left
  higherThan: ForwardApplication
}

infix operator <>: SingleTypeComposition

이 연산자에 붙여진 재밌는 이름은 바로 ‘다이아몬드’ 연산자임.
이 연산자를 (A) → A 함수들에 대해 정의하는 방법은 꽤나 간단함.

func <> <A>(
  f: @escaping (A) -> A,
  g: @escaping (A) -> A
) -> ((A) -> A) {

  return f >>> g
}

기존 연산자를 또 다른 연산자로 한 번 더 감싸는 것이 이상해보일 수 있음.
하지만 우리는 이를 통해 연산자의 사용 범위를 제한하고 명확한 의미를 부여했음.
즉, 이 연산자를 보는 순간 “아, 지금은 단일 타입을 다루고 있구나”라고 바로 알 수 있게 된 것!
이제 inout 함수들을 위한 <> 연산자도 정의해보겠음.

func <> <A>(
  f: @escaping (inout A) -> Void,
  g: @escaping (inout A) -> Void
) -> ((inout A) -> Void) {

  return { a in
    f(&a)
    g(&a)
  }
}

이제 이전에 작성했던 함수들이 잘 합성됨!

decimalStyle <> currencyStyle

더 좋은 방법은 inout 함수를 직접 합성하는 것.

inoutDecimalStyle <> inoutCurrencyStyle

값을 파이프해 함수 합성을 하면 어떤 일이 일어날까요?

config |> decimalStyle <> currencyStyle
config |> inoutDecimalStyle <> inoutCurrencyStyle

우리의 버전에서는 에러가 발생할 것입니다.

Cannot convert value of type '(inout Int) -> ()' to expected argument type '(_) -> _'

이건 우리가 만든 |> 연산자가 아직 inout 세계에서는 동작하지 않기 때문.
하지만 우리는 함수 오버로딩을 통해 이를 추가로 정의할 수 있음.

func |> <A>(a: inout A, f: (inout A) -> Void) -> Void {
  f(&a)
}

이젠 우리는 드디어 자유롭게 값을 파이프할 수 있게 되었음!

config |> inoutDecimalStyle <> inoutCurrencyStyle

정말 멋진 결과임! Swift의 훌륭한 기능들을 활용하면서도 함수형 프로그래밍의 핵심인 합성 가능성(Composability)을 전혀 희생할 필요가 없었음.
물론 또 하나의 연산자를 추가하는 비용을 치렀으니, 다시 한번 자격을 체크할 차례임.

이 연산자가 Swift에 이미 존재하는가? → X / 따라서 기존 기능과 혼동될 여지가 전혀 없음.
참고할 만한 사례가 있는가? → O / Haskell, PureScript 등 함수형 커뮤니티가 탄탄한 언어들에서 이미 널리 채택되어 사용 중임. 양방향을 가리키는 이 기호 모양은 무언가를 하나로 ‘결합’한다는 의미를 아주 잘 전달함.
이것은 범용적인 연산자인가? → O / 지금까지는 (A) → A 와 (inout A) → Void 함수를 위해서만 정의했지만 사실 <>는 같은 타입의 두 요소를 하나로 합치는 모든 상황에서 훨씬 범용적으로 사용됨. → 이것은 계산의 가장 근본적인 단위라고도 할 수 있음.

What’s the point?

이제 스스로에게 물어볼 시간임. → 이 모든 것의 목적이 무엇인가?
우리는 코드에 복잡성을 더하고 테스트를 어렵게 만드는 수많은 Side Effects를 마주했음.
이를 해결하기 위해 입력과 출력이라는 타입 시스템 안에 Side Effects를 명시하는 약간의 사전 작업을 감수했음.
하지만 그 과정에서 함수 합성이 깨졌고, 이를 복구하기 위한 Side Effects 전용 합성 연산자들을 도입해야 했음.
과연 그럴 가치가 있었는가? → Point-Free의 대답은 당연히 그렇다!! 임.
격리된 상태에서는 테스트도 불가능하고 추론하기도 힘들었던 Side Effects 덩어리의 코드들을 명시적으로 드러나게 끌어올렸기 때문.
이제 우리는 이전 줄의 코드가 무슨 일을 했는지 일일히 파악하지 않고도 단 한 줄의 코드만으로 그 동작을 완벽히 이해하고 테스트할 수 있음.
이 모든 것은 ‘함수 합성’이라는 강력한 무기를 잃지 않고 해낸 것. → 이것은 정말 강력한 힘임!
비록 초기에 약간의 수고가 더 들었지만 이는 복잡하게 얽힌 상태 변경을 디버깅하거나,
코드 여기저기에 뿌려진 Side Effects 때문에 발생하는 버그를 잡는데 들어갈 엄청난 시간을 절약해 줄 것.
또한 테스트를 위해 억지로 코드를 끼워 맞추는 고통에서도 해방될 것.
Side Effects는 정말 방대한 주제이며, 우리는 이제 겨우 그 겉면을 봤을 뿐임.
앞으로 우리는 Side Effects를 제어하는 훨씬 더 흥미로운 방법들을 탐험하게 될 것!

SwiftUI TextEditor 줄바꿈 스크롤 점핑 현상 해결하기

thinkyside — Sun, 4 Jan 2026 12:22:57 +0900

문제 정의

objc + 스토리보드로 구현되어 있는 메모 화면을 리팩토링하기 위해 SwiftUI의 TextEditor는 여러 줄의 텍스트를 입력 받을 때 사용할 수 있는 공식 API를 사용했다.

struct ContentView: View {

    @State var text: String = ""

    var body: some View {
        VStack(spacing: 0) {
            NavigationBar()
            TextEditor(text: $text)
                .lineSpacing(4)
        }
    }
}

하지만 왜인지(?) 화면 너머까지 텍스트를 입력하고 줄바꿈할 때 스크롤이 점핑(튀는)하는 현상을 발견해 이를 해결하고자 여러 가지를 시도해봤다.

++ 아래 링크에서 같은 문제를 겪은 사람이 있다,,, iOS 16 TextEditor long text jumping (SwiftUI)

https://developer.apple.com/forums/thread/724330

iOS 16 TextEditor long text jumpin… | Apple Developer Forums

Text jumping (I don't know how else to name that weird behavior) to the top(?) every time user enters a new character. I can reproduce the issue only on iPad OS 16. It affects the user who attempts to write long (several paragraphs) text in the TextEditor.

developer.apple.com

삽질 기록

1. UIRepresentable을 이용한 UITextView 사용해보기

struct ContentView: View {

    @State var text: String = ""

    var body: some View {
        VStack(spacing: 0) {
            NavigationBar()
            TextViewWrapper(text: $text)
        }
    }
}

struct TextViewWrapper: UIViewRepresentable {
    @Binding var text: String

    func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()
        textView.delegate = context.coordinator
        return textView
    }

    func updateUIView(_ uiView: UITextView, context: Context) {
        let selectedRange = uiView.selectedRange
        uiView.text = text
        uiView.selectedRange = selectedRange
    }

    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }

    class Coordinator: NSObject, UITextViewDelegate {
        var parent: TextViewWrapper

        init(_ parent: TextViewWrapper) {
            self.parent = parent
        }

        func textViewDidChange(_ textView: UITextView) {
            parent.text = textView.text
        }
    }
}

스크롤 점핑 현상이 완화(같은 줄 안에서는 점핑이 없어졌지만, 줄바꿈 시 발생)되긴 했지만 여전히 발생하긴 함.

2. SwiftUI의 TextField 사용

struct ContentView: View {

    @State var text: String = ""

    var body: some View {
        VStack(spacing: 0) {
            NavigationBar()
            TextField(text: $text, axis: .vertical) {}
                .lineSpacing(4)
        }
    }
}

스크롤 점핑 현상 해결(정상 동작)
하지만 TextEditor에 있던 Scroll Indicator가 보여지지 않음.
Focus 됐을 때와 안됐을 때의 라인이 달라보일 때가 있음.(Focus 되면 갑자기 줄이 늘어나는 것처럼 보임,,?)
Line 수가 적을 때 height 값도 작아지기 때문에(TextEditor는 기본적으로 가능한 가장 큰 크기를 차지) FocusField가 활성화 시킬 수 있는 영역에 대한 추가 구현이 필요.

3. ScrollView + TextField 사용

struct ContentView: View {

    @State var text: String = ""

    var body: some View {
        VStack(spacing: 0) {
            NavigationBar()
            ScrollView {
                TextField(text: $text, axis: .vertical) {}
                    .lineSpacing(4)
            }
        }
    }
}

위 방식에서 ScrollView만 추가해본 방식.
스크롤은 정상 동작하고 Scroll Indicator도 표시되지만, 줄바꿈 시 자동으로 스크롤되는 기능이 누락됨.

4. UITextView + NSAttributedString 사용

struct ContentView: View {

    @State var text: String = "asdasd"

    var body: some View {
        VStack(spacing: 0) {
            NavigationBar()
            TextViewRepresentable(
                text: $text,
                font: .systemFont(ofSize: 20),
                textColor: .red,
                tintColor: .blue,
                lineSpacing: 8,
                contentInset: UIEdgeInsets(top: 0, left: 16, bottom: 0, right: 16)
            )
        }
    }

    @ViewBuilder
    private func NavigationBar() -> some View {
        Rectangle()
            .frame(height: 40)
            .foregroundStyle(.black)
    }
}

struct TextViewRepresentable: UIViewRepresentable {

    @Binding var text: String

    let font: UIFont
    let textColor: UIColor
    let tintColor: UIColor
    let lineSpacing: CGFloat
    let contentInset: UIEdgeInsets

    init(
        text: Binding<String>,
        font: UIFont,
        textColor: UIColor,
        tintColor: UIColor,
        lineSpacing: CGFloat = 4,
        contentInset: UIEdgeInsets = .zero
    ) {
        self._text = text
        self.font = font
        self.textColor = textColor
        self.tintColor = tintColor
        self.lineSpacing = lineSpacing
        self.contentInset = contentInset
    }

    func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()

        // 1. Delegate 설정
        textView.delegate = context.coordinator

        // 2. ContentInset 설정
        textView.textContainerInset = contentInset

        // 3. TintColor 설정
        textView.tintColor = tintColor

        // 4. paragraphStyle 설정
        let paragraphStyle = NSMutableParagraphStyle()
        paragraphStyle.lineSpacing = lineSpacing

        // 5. NSAttributedString 속성 세트 생성
        let attributes: [NSAttributedString.Key: Any] = [
            .font: font,
            .foregroundColor: textColor,
            .paragraphStyle: paragraphStyle
        ]

        // 6. 기본 텍스트 속성 설정
        textView.attributedText = NSAttributedString(
            string: text,
            attributes: attributes
        )

        // 7. 타이핑 속성 설정
        textView.typingAttributes = attributes
        return textView
    }

    func updateUIView(_ uiView: UITextView, context: Context) { }

    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }

    final class Coordinator: NSObject, UITextViewDelegate {

        @Binding var text: String

        var parent: TextViewRepresentable

        init(_ parent: TextViewRepresentable, _ text: Binding<String>) {
            self.parent = parent
        }

        func textViewDidChange(_ textView: UITextView) {
            parent.text = textView.text
        }
    }
}

RichTextKit 라이브러리를 참고해 `NSAttributedString` 사용에서 힌트를 얻음.
스크롤 점핑 현상 해결 + Scroll Indicator 정상적으로 보임.

문제 해결

결국 이것저것 시도해보다 `NSAttributedString`에서 답을 얻을 수 있었다,,! 애플이 TextEditor를 고쳐준다면야 가장 좋겠지만 마냥 기다릴 순 없으니 아래와 같이 컴포넌트로 만들어두고 잘 돌려써먹어볼 예정이다.

import SwiftUI

/// SwiftUI `TextEditor`의 스크롤 점핑 문제를 해결하기 위해 구현된 커스텀 텍스트 에디터.
///
/// - Note: `UITextView`와 `NSAttributedString`을 활용해 스크롤 점핑 문제를 해결했습니다.
public struct StableTextEditor: UIViewRepresentable {

    @Binding var isFocused: Bool
    @Binding var text: String

    let font: UIFont
    let textColor: UIColor
    let tintColor: UIColor
    let backgroundColor: UIColor
    let lineSpacing: CGFloat
    let contentInset: UIEdgeInsets

    public init(
        isFocused: Binding<Bool>,
        text: Binding<String>,
        font: UIFont,
        textColor: Color,
        tintColor: Color,
        backgroundColor: Color,
        lineSpacing: CGFloat,
        contentInset: UIEdgeInsets = .zero
    ) {
        self._isFocused = isFocused
        self._text = text
        self.font = font
        self.textColor = UIColor(textColor)
        self.tintColor = UIColor(tintColor)
        self.backgroundColor = UIColor(backgroundColor)
        self.lineSpacing = lineSpacing
        self.contentInset = contentInset
    }

    public func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()
        textView.delegate = context.coordinator
        textView.tintColor = tintColor
        textView.backgroundColor = backgroundColor
        textView.textContainerInset = contentInset
        textView.attributedText = NSAttributedString(string: text, attributes: attributes)
        textView.typingAttributes = attributes
        return textView
    }

    public func updateUIView(_ uiView: UITextView, context: Context) {
        if uiView.text != text {
            uiView.attributedText = NSAttributedString(string: text, attributes: attributes)
            uiView.typingAttributes = attributes
        }

        if isFocused {
            uiView.becomeFirstResponder()
        } else {
            uiView.resignFirstResponder()
        }
    }

    public func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }
}

// MARK: - Helper
extension StableTextEditor {

    /// NSAttributedString 속성 Dictionary를 반환합니다.
    private var attributes: [NSAttributedString.Key: Any] {
        let paragraphStyle = NSMutableParagraphStyle()
        paragraphStyle.lineSpacing = lineSpacing
        return [
            .font: font,
            .foregroundColor: textColor,
            .paragraphStyle: paragraphStyle
        ]
    }
}

// MARK: - Coordinator
extension StableTextEditor {

    public final class Coordinator: NSObject, UITextViewDelegate {

        var parent: StableTextEditor

        public init(_ parent: StableTextEditor) {
            self.parent = parent
        }

        public func textViewDidChange(_ textView: UITextView) {
            parent.text = textView.text
        }

        public func textViewDidBeginEditing(_ textView: UITextView) {
            parent.isFocused = true
        }

        public func textViewDidEndEditing(_ textView: UITextView) {
            parent.isFocused = false
        }
    }
}

영원회귀

thinkyside — Thu, 25 Dec 2025 17:21:12 +0900

유난히 길게 느껴졌던 여름이 지나고 여전히 길게 느껴질 겨울이 왔다. 나 자신을 이해하기 위해 그 어느 때보다 시간을 쏟고 있는 까닭일까 이번 겨울은 더 춥고 짙다. 달라진 것이 있다면 후회와 자기반성이 아닌 있는 그대로와 사유를 위한 시간을 보낼 것이라는 점이다. 다시 돌아가도 다시 똑같은 선택을 할 것이라는 자기 확신, 허무주의에서 벗어나 매 순간이 의미 있었음을 느끼며 한 글자씩 소중하고 다정히 밀어 본다.

1. 일

푸르른 여름 내내 나를 몰아세웠던 것은 낙엽이 지기도 전에 색이 바래 나를 차분하게 만들었다. 늘 그랬듯 자기 세계에서 큰 사건이라 여겨졌던 것들은 조금만 시간이 지나도 닳고 무뎌져 평범한 사건이 되어버렸다. 적성에 맞지 않아서, 인간관계에 힘이 들어서, 생각한 것이 아니어서 그런 게 아니다. 그것은 '일'에 대한 불확실한 정의에서 오는 태도일 것이라 생각한다.

내게 '일'이란 무엇인가? 경제적 자립, 사회 구성원으로서의 기능뿐이었다면 헷갈리지도 않았을 것이다. 막연히 내뱉는 자아실현과 같은 개념도 너무나 추상적이다. 어쩌면 '이때쯤 해야만 하는 것' 정도로 생각하지 않았는가. 나는 그저 일이 재미있고 마음에 드는 요즘, 그 이유를 알고 안주하지 않았으면 할 뿐이다.

2. 나는 얼마나 나를 위해 살고 있는가

하루 24시간 중 8시간은 잠을, 9시간은 일을, 3시간은 지하철에서 보내고 나면 내게 남는 시간은 4시간이다. 그중 식사와 씻는 시간 등 인생의 공과금을 지불하고 나면 온전히 쓸 수 있는 시간은 3시간 남짓이다. 턱없이 부족하다 느껴지는 시간이다. 그렇다면 3시간은 나를 위해 쓰고 있는가? 단언할 수 없다. 세상의 온갖 무질서하고 무의미 해 보이는 것들은 겉으로는 봐야만 할 것 같은, 행복을 줄 것 같이 생겨먹었기 때문이다. 현대 사회에서 이를 완전히 무시하기란 불가능에 가까워 보일 정도이다.

나의 3시간은 둘 중 하나다. 첫 째는 카페에서 작업을 하는 것이다. 무언가 만들어내는 과정은 언제나 즐겁다. 회사 일로서 만드는 일 또한 비슷한 맥락에서 즐거움을 주지만 주체적으로 상상하던 것을 실현해 내는 만듦은 그 밀도가 다를 수밖에 없다. 하루를 생산적으로 살고 싶어 시작한 '데이블럭' 프로젝트를 최근 다시 재개했다. 꾸준히 올라오던 사용자들의 목소리에 부응하고 싶기도, 요즘 내게 다시 필요해졌다 느꼈기 때문이기도 하다. 좋아하는 것 무엇이든 만들어나가는 꿈을 위해 노력하는 일은 내 하루를 뜨겁게 열정으로 만든다.

둘 째는 영화를 보는 것이다. 최근 인문학, 철학 등에 관심이 많아지며 자연스레 책과 영화에 시선이 가게 되었고 나와 다른 하루를 살아가는 이들의 이야기는 한정된 세계를 넓혀주었다. 이전에는 오락의 역할 뿐이었다면, 이제는 경험의 역할로서 다양한 생각과 삶의 태도를 비유적으로 건네주고 있다. 푹신한 침대 위에서 매일 다른 곳을 여행하는 기분을 느낀다. 평소 보고 싶었던, 누군가 추천해 준 좋은 영화를 감상하는 일은 내 하루를 차갑게 진정시켜 준다.

3. 순응하는 삶, 투쟁하는 삶

적지 않은 시간을 출퇴근 지하철에서 보내다 보면 자연스레 무기력해지곤 한다. 저마다의 피곤함 속에서 모두가 한 손을 들고 작은 화면 안을 들여다보는 모습이 나를 더욱 무기력하게 만든다. 나 또한 피곤함에 굴복해 아무 생각 없이 손가락을 휘적거리다 보면 지하철 안이 닭장과 같다는 느낌을 지울 수 없게 된다. 나는 피곤함에, 편안함에 순응하고 싶지 않았다. 내가 통제할 수 없는 세계에 의존하고 싶지 않았다.

나의 투쟁은 독서였다. 빠르게 지나가 형체조차 흐릿한 것들에서 벗어나 느리지만 선명한 글자를 좇으며 삶의 의존성을 역전시키고자 했다. 독서는 어려웠다. 굳이 무거운 책을 들고 다녀야 하고, 지하철만큼이나 집중력도 흔들렸으며, 무엇보다 답답했다. 이처럼 작다고 생각한 투쟁조차 어려웠다. 그러나 시간이 지나 익숙해지고, 익숙해진 것은 습관이 되어 조금이나마 내 것이 되었다 느꼈을 때의 효용감은 절대 작지 않았다. 나는 이제야 내 세계를 만들어나가는 방법을, 좋음에 맞서는 방법을 경험한 것이다.

4. 불확실한 사람에 관하여

누군가를 좋아하는 감정은 언제 생길까? 정확히는 언제 그런 마음이었다 자기 확신할 수 있을까? 관계의 크기나 시간에 비례해야 하는 것이라면 나는 확신할 수 없을 것이다. 확신할 수 없다는 것은 다음 단계로 발전하기 위한 행동으로 이어질 수 없다는 말이기도 하다. 그렇게 솔직함과는 반대로 넘실대는 파도에 떠밀려오다 보니 내 섬엔 응어리만 쌓여갔다. 상처 입을 상황을, 상처 입힐 사람이 될 용기를 내지 못한 대가는 언제나 씁쓸하고 조용히 찾아온다.

그래서 나는 불확실한 사람이 이야기한 그 불확실한 감정에 솔직해지기로 했다. 누군가를 좋아한다는 감정은 그 자체로 아름다운 것이다. 내 안에서 외면하고 짓누를 것이 아닌 향유하고 꺼내놓아야 할 형태인 것이다. 타인은 절대 이해할 수도 대신해 줄 수도 없는 나의 소중한 감정인 것이다. 이 모든 감정을 받아들일 때 비로소 불확실함에서 오는 외로움보단 즐거움을, 사랑을 통해 더 나은 사람이 될 수 있을 것이다.

아직 일어나지 않은 불확실한 사람, 사랑, 마음에 관하여 나는 다시 돌아가도 같은 선택을 할 것이다. 그럼에도 불구하고, 그 모든 일이 있었음에도 여전히 당신이기 때문이다.

외계인 자서전 - 지극히 특별하고 평범한 외로움

thinkyside — Sun, 30 Nov 2025 19:12:45 +0900

올해 가장 많이 떠오르고, 늘 옆에 있었고, 차츰 익숙해져가는 건 외로움이었다. 작년에 과분한 사랑을 받아서 그랬을까, 분명 그 때도 채워지지 않는 공허함 같은 게 있었는데 지금은 더욱 그렇다. 아디나가 뉴욕에서 그랬던 것처럼 내 인생에서 사람들을 스쳐가고, 대화하고, 함께 일할 기회가 어느 때보다 커져가는데 도대체 왜 외로움이 커지는 걸까? 역설적이라는 생각에 괜스레 억울한 감정이 몰려오기도 한다. 화가 나서 눈물이 날 때도 있다.

외계인 자서전은 외로움을 위로해주지 않는다. 아디나의 고독함이 묻어져나오는 문장들에는 솔직함에서 오는 측은함, 상실감, 공허함이 있다. 그러나 오히려 그것이 내게 편안함을 줬다. 그럴 수 있음을, 그럼에도 불구하고 인간이라는 불완전한 존재가 살아가는 그 방식을 느낄 수 있었다. 그리고 그것은 언제나 극적인 사건에서 오는게 아닌, 일상 속 작은 다정함이었다. 사랑하는 사람과 헤어지고, 작은 존재가 멀리 떠나가고, 톱니바퀴 처럼 똑같은 일상이 반복되는 삶을 살아갈 수 있게 만드는 것은, '당신은 혼자가 아니에요'라는 보편적 언어 표현이 아닌 시시콜콜한 농담 한마디 아무도 신경 쓰지 않던 오리 동상에 옷을 입혀주는 것들이었다.

나는 앞으로도 여전히 외로울 것이다. 여전히 생각이 많을 것이다. 늘 그렇듯 이해하지 못할 것이다. 그러나 전혀 이상하지 않다. 우리는 저마다의 우주에서 온 외계인이니까. 보이저 호에 담긴 쓸데 없고 공간만 차지하는 골든 레코드가 우리를 이어주리라 소망하며.

Let'Swift 2025 짤막한 후기

thinkyside — Mon, 24 Nov 2025 23:15:18 +0900

올해는 못 갈 줄만 알았던 iOS 행사를 회사 팀원 분의 좋은 기회를 받아 다녀올 수 있었습니다.(오거나이저 만세!)

오랜만에 아카데미 분들도 봐서 좋았고, 무엇보다 다시금 iOS에 대한 열정의 기억을 되살릴 수 있었습니다. 사이드 프로젝트도, 디자인도, 완전히 다른 것도 재밌는게 많지만 제겐 역시 iOS 개발이 제일 재밌는 것 중에 하나이니까요.

작년에 비해 스스로 넣는 인풋량은 많이 부족하지만(그만큼 다른걸 많이 채우고 있다 생각하지만) 외적으로 주입되는 인풋량은 더 많아짐을 느끼곤 합니다. 처음 들었던 컨퍼런스에선 거의 모든 내용을 이해할 수 없었지만 지금은 고개를 끄덕거릴 정도는 되었습니다 ㅎㅎ

열심히 준비해 좋은 기회 주신 회사 동료 분께 다시 한번 감사 인사 드립니다 (다들 너무 고생 많으심,,, 늘 응원합니닷)

컨퍼런스 내용 간단 정리

AI 친화적 코드베이스: 중대규모 코드베이스에서 AI 에이전트 활용도 높이기

Claude 코드 기반 설명.
관련 없는 맥락이 인풋으로 들어가면 답변의 질이 떨어짐 → 컨텍스트 부패
Why? 1 → 문자열 리터럴 충돌 → 동일 함수/클래스명으로 인한 혼란
Why? 2 → Claude의 Read 방법 → 필요한 부분을 동적으로 로드하기 때문에 전체 파일 읽어야 함
해결 시도 1 → Claude의 Read 방법을 바꿔주는 Claude Context MCP 사용 → 토큰 사용량 및 호출 횟수 최적화
해결 시도 2 → Smart Compact 기법 사용 → 각 단계별 요약 문서(project.md 등) 생성 → 관련 없는 코드베이스 탐색 및 요약을 줄여줌
하지만 2가지 방식 모두 완전히 컨텍스트 부패를 막을 수는 없었음,,, → 이를 위해 코드베이스에서의 수정이 필요하다 느낌
코드베이스 수정 1 → Layer Based 폴더링이 아닌, Feature Based 폴더링 채택 → Claude의 파일 탐색을 더 정확하고 빠르게 해줌.(회사 프로젝트도 폴더링 개선이 필요해 보임 인간에게나 AI에게나 필요해보임)
코드베이스 수정 2 → 단일 책임 File 구조(SuperFile 지양) → 전체 파일을 읽으려 하기 때문에 이를 막아줌 → 프로토콜 및 구현체의 파일을 적절히 분리할 수 있음.

CGAffineTransform으로 화면 렌더링 이해도 올리기

안타깝게도 transform(x: 0, y: -1) 하면 뒤집어 진다,,, 까지 이해했음(?)
CGAffineTransform이 어떻게 이런 단순한 값으로 좌표를 표현하는지에 대한 수학적 설명이 주된 내용이었음.(벡터, 행렬 등)

SwiftUI로 디자인시스템 약간 오버 엔지니어링 설계하기(feat: OOP)

디자인 시스템을 설계하기 위해 각 컴포넌트 내 공통되는 디자인 요소, variation 등을 분석하는 과정이 선행됨.
이후에는 protocol을 이용해 각 요소를 적절히 추상화하고 UIComponent(View)에 적용.
연사자 분이 왜 오버 엔지니어링이라고 제목을 붙이셨는지 공감이 감,,,(개인적으로는 만들어진 컴포넌트에서 수정이나 추가가 거의 적을 것이라 판단해 하나의 View에 다양한 속성을 받을 수 있게 생성자를 만들고 기본값을 부여해 적당한 리소스로 관리 가능한 컴포넌트를 구현했을 것 같음)
마지막에 연사자 분도 프로젝트의 맥락과 필요에 따라 선택이 필요하다고 언급해주셨음.
특히 디자이너 분들과의 적극적인 소통이 필요하다는 말이 가장 인상 깊었음.(진짜 제일 중요한듯!!!)

모놀로식에서 모듈화로, 그 중간 어딘가

모듈화는 왜 하는가? → 생산성 및 효율 증가 / 도메인 분리 / 의존성 및 재사용성 관리 / 빌드 시간 최적화 / 데모 앱
연사자 분 팀의 모듈화에서의 목표 → 한번에 큰 변화가 아닌, 점진적인 개선으로 모듈화 진행하기(모듈화 진행 중에도 안정적인 서비스를 유지하고, 영향 범위를 크게 만들지 않아 팀원의 부담을 줄이는 방향성)
How? → 모듈 분리 부터 하려 하지 말고 메인 앱의 적절한 의존성 분리부터 선행(그래야 모듈화가 더 수월해짐)
점진적 방법 1 → 저수준 레이어(Core) 부터 의존성 분리하기 → 이후 다른 객체, 레이어와의 의존성 분리의 토대가 될 것.
점진적 방법 2 → DI Container를 이용해 간접적으로 의존성 분리(최종 목표는 DI Container도 걷어낼 수 있어야 함, 점진적인 개선을 위한 방편) → 순환 의존성을 간접적으로 느슨하게 만들어줄 수 있음
어느 정도 메인 앱의 의존성 분리가 됐을 때 Component(UI) 모듈을 만들었음. → 최종적으로 각 Feature 모듈을 여러 개 만들어 데모 앱을 만드는 게 목표인데, 이를 위핸 토대가 Component 이기 때문.
Component 모듈을 만들어서 스토리북(모든 팀원들이 보고 참고할 수 있는 UI 컴포넌트의 집합 데모 앱 같은 느낌)으로 QA 영향 범위를 파악하고, 컴포넌트 재사용률을 높일 수 있음.
이 때 활용할 수 있는 좋은 툴이 Uber에서 만든 snapshot-test-case 라이브러리.
연사자 분 팀에서는 PR의 diff를 토대로 PR의 스냅샷, develop 브랜치의 스냅샷을 만들고 이를 비교해 다른 점이 발생했을 때의 차이를 스크린샷으로 정리해주는 액션을 만들어 영향 범위를 효과적으로 파악할 수 있게 만들었음.
회사 프로젝트에서도 모듈화를 조금씩 진행 중인데 지금처럼 새롭고 작은 기능은 모듈로 나눠가면서도, 메인 앱의 코드 의존성을 점진적으로 개선해나갈 수 있는 액션 아이템을 만들 수 있으면 좋겠다고 생각했음.
tmi) 카카오 스타일스의 '지그재그' 팀의 이야기였음!

Modern Network와 WebSocket

iOS 26에서는 WebSocket을 더 Modern하게 사용할 수 있도록 새로운 API가 이것저것 추가되었음.
특히 SwiftUI의 ResultBuilder 패턴 처럼 WebSocket을 쉽고 직관적으로 생성할 수 있는 방법도 추가됨!
개인적으로 Networking, WebSocket 등에 대한 기본 지식이 부족하다 느껴 이 부분은 추후 탄탄히 쌓아보도록 공부가 필요함.(조만간 찜해둔 Network 기본기 인프런 강의 완강하기)

Swift 개발자를 위한 온디바이스 AI LLM

Apple Intelligence → 온디바이스 LLM → OS 내장이기 때문에 앱 용량 증가 X
Apple Intelligence의 장점: 요약 / 정보 추출 / 텍스트 분류 / 간단한 QA / 작은 Context에서의 작업
Apple Intelligence의 약점: ChatGPT, Gemini 등 대비 지식 부족, 복잡한 추론 능력 부족, 아직은 부족한 한글 능력,,
모델 사용 전 필수 체크! 기기가 Intelligence를 지원하는가?(iPhone 15 Pro 이상) / 사용자가 기기에서 '온디바이스 Siri 및 탐색' 기능을 활성화 했는가? / 모델이 다운로드 되었는가?
LanguageModelSession? AFM(Apple Foundation Model)의 핵심 객체 → Swift 코드에서 요 객체로 다양한 동작 가능
핵심 꿀팁 1 → 모델 사용 전 사전 예열로 성능 최적화(session.prewarm) → 첫 응답 지연 감소 / 최적 호출 시점
핵심 꿀팁 2 → Playground 매크로로 AFM 테스트(#Playground) → SwiftUI Preview와 비슷하게 여러가지 LLM 요청 결과 확인
사용법 1 → AFM 기본 응답 생성하기 → session.responde(to:) → 여기서 파라미터로 들어가는 GenerationOption 값에 따라 응답 전략(창의적 결과, 일관성, 조정 등), 표현의 다양성(신뢰도, 창의성 등)을 바꿔줄 수 있음
AFM 응답 생성 시 오류 발생 케이스 → 유해, 민감 콘텐츠 / 예측 불가능한 출력 / 의도된 역할 이탈 / 구조화된 출력 위반 / 지원되지 않는 언어 등 → 이에 대한 에러 처리 적극 권장!
사용법 2 → session.streamResponse()를 통해 비동기 스트리밍 작업 시작 → 각 출력 값을 바인딩 된 변수에 누적해줄 수 있음.
사용법 3 → Guided Generation(유도 생성) → 개발자가 정의한 Swift 타입(구조체, 열거형)에 맞춰 모델이 엄격한 형식의 출력을 생성하도록 유도 → 별도의 파싱 없이 Type-Safe한 Swift 객체를 즉시 얻을 수 있음 → @Generable, @Guide 매크로 활용
사용법 4 → Tools(모델의 손발) → 모델이 스스로 외부 코드(Swift 함수)를 호출해 정보를 얻거나 특정 행동을 수행하게 만드는 기능 → Tool Calling 또는 Function Calling이라고도 함. → RAG(검색 증강 생성) 구현, 앱의 액션(DB에 새 정보를 쓰거나, 외부 API를 호출하는 등)을 호출하는데도 활용 가능.
요걸 활용해볼 다양한 아이디어? 게임 NPC 랜덤 대사 생성 / 사용자 입력 기반 여행 일정 자동 생성 / 온디바이스 개인 맞춤형 비서 등
복잡한 작업이 어렵고 한국어에 약해 맛있게 써먹기는 어렵겠지만 분명 온디바이스의 장점을 살려 여러가지 시도를 해볼만 할 것 같다고 느꼈다.(회사 프로젝트든, 개인 프로젝트든 어쨌든 무료로 다양한걸 해볼 수 있다는데 해볼만 하지 않을까?)

Firebase Remote Config로 배포 없이 값 "딸깍" 바꿔주기

thinkyside — Sun, 23 Nov 2025 12:28:42 +0900

앱에 새로 출시할 기능이 상당히 실험적이고 도전적이라 '어떤 비즈니스 이펙트를 가져올지 예상할 수 없을 때' 어떤 선택을 할 수 있을까요? 여기서 전제는 '앱 배포'이기 때문에 되돌리거나 새로운 변경사항으로 바꾸고 싶으면 기존 방식으로는 길고 긴 심사를 다시 거쳐야한다는 것입니다.

점진 배포하기
Server-Driven 방식으로 분기처리 하기
그냥 다시 배포하고 기도하기(?)

3가지 방식 모두 장단점이 있지만, 오늘은 그 중에서도 가장 적은 리소스로 가장 빠르게 프론트에서 적용할 수 있는 방식인 Firebase Remote Config 방식에 대해 정리해보겠습니다.

Firebase Remote Config?

이름에서도 알 수 있듯 원격 제어 설정을 도와주는 친구입니다.(Firebase,,, 대체 얼마나 해주는거야!!) 공식 개발자 문서에 따르면 아래와 같은 기능을 도입할 수 있다고 해요.

앱 사용자 층에 변경사항을 빠르게 출시: 파라미터 값을 원격으로 바꿔 앱 내 변화.
사용자층의 특정 세그먼트에 앱 맞춤설정: GA 세그먼트를 기준으로 다양한 사용자 환경 제공 가능.
타겟팅 및 점진 배포, 커스텀 이벤트 측정, A/B 테스트 설정 등등...

원격으로 값을 바꿔줄 수 있기 때문에 Server-Driven 방식처럼 분기 처리로 배포와 상관 없이 앱 내 변화를 줄 수 있게 됩니다. 이렇게 좋은 기능이 있었는데,,, 왜 작년엔 서버 없다고 3번 방식(~~기도 메타~~)만 사용했는지 모르겠네요.

일단 한번 해보기(빠른 시작 가이드)

기본적으로 프로젝트 내 Firebase 세팅이 되어있다는 걸 기준으로 정리해보겠습니다.(안했다면 요 공식 문서를!) 또 Remote Config 사용을 위해선 Google Analytics 사용 설정도 필수이기 때문에 이 친구 또한 되어 있어야 합니다.(안했다면 요 공식 문서를!)

자 우선 어떤 값을 원격으로 사용하고 제어하고 싶은지 명시해야겠죠? Firebase Console에서 쉽게 설정할 수 있습니다.

실행 > Remote Config

Remote Config를 처음 설정하게 되면 아래 화면으로 진입하게 됩니다. 첫 구성을 만들기 위해 '구성 만들기' 버튼을 클릭합니다.

'구성 만들기' 버튼 클릭

이제 매개변수를 만들면 됩니다! 필드도 몇개 없고 직관적이라 어떤 값들이 들어가야 할지 쉽게 파악이 가능합니다. 저는 제 강아지 이름을 원격으로 제어하고자 `puppy_name`의 Key와 '민톨'이라는 Value를 문자열 타입으로 설정해주었습니다.

++ 중요! Remote Config 파라미터 Key 또는 Value에는 민감한 데이터를 저장하지 말 것을 권장합니다.

이렇게 첫 번째 매개변수를 만들고 나면 앞으로 계속 보게될 매개변수 리스트 화면을 볼 수 있게 됩니다. 여기서 중요한 점은, 값을 만들면 바로 반영되는 것이 아닌 '변경 사항 게시' 버튼을 눌러줘야 실제 값이 반영된다는 것입니다! 잊지말고 꼭 눌러주세요.

Firebase Console에서의 설정은 끝났습니다. 이제 프로젝트에도 Remote Config를 가져오기 위한 기본 세팅을 진행해줍니다. 먼저 제가 기존에 사용하던 `FirebaseManager`에 이를 위한 함수를 하나 생성해주었습니다.

++ `import FirebaseRemoteConfig` 부분에서 컴파일 에러가 난다면, 프로젝트 타겟에 `FirebaseRemoteConfig`가 추가되었는지 확인해보세요!(없다면 추가 고고)

import FirebaseCore
import FirebaseRemoteConfig // ⭐️ 추가

enum FirebaseManager {
    
    /// Firebase를 초기화합니다.
    static func initialize() {
        FirebaseApp.configure()
    }
    
    /// ⭐️ Remote Config를 설정합니다.
    static func setupRemoteConfig() {
        let remoteConfig = RemoteConfig.remoteConfig() // ⭐️ 싱글톤
        let settings = RemoteConfigSettings() // ⭐️ 설정 객체
        settings.minimumFetchInterval = 0 // ⭐️ 얼마나 자주 값을 가져올지(0 == 최대한 자주)
        remoteConfig.configSettings = settings // ⭐️ 싱글톤에 설정 객체 넘기기
    }
}

이후 앱 초기화 시점에 Firebase 초기화와 함께 RemoteConfig 설정도 진행해주었습니다.

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // ...
        FirebaseManager.initialize()
        FirebaseManager.setupRemoteConfig() // ⭐️ 앱 초기화 시 Remote Config 설정
        // ...
    }
}

자 이제 대망의 값을 가져와보겠습니다! Firebase Console에서 작성했던 Key와 타입을 이용해 아래와 같이 작성하면 우리가 설정했던 '민톨' 값을 정상적으로 가져오는 것을 확인할 수 있습니다.

// ⭐️ 당연한 이야기지만 비동기로 가져오지 않으면 기본값(타입 기본값 or 내가 지정한 기본값)으로 설정됨
Task {
    let remoteConfig = RemoteConfig.remoteConfig()
    try await remoteConfig.fetch()
    try await remoteConfig.activate()
    let puppyName = remoteConfig["puppy_name"].stringValue
    print("제 강아지 이름은 \(puppyName)이에요.")
}

다양한 타입 설정도 가능해요

Remote Config는 총 4개의 데이터 타입을 지원합니다. 위에서 예시로 포함한 문자열(`String`)과 숫자(`Int`), 부울(`Bool`), `JSON`을 이용해 다양한 데이터를 표현할 수 있죠. 각각 사용은 아래와 같이 가능합니다. JSON을 지원하기 때문에 사실상 대부분의 데이터는 모두 표현이 가능하다 봐도 무방합니다 ㅎㅎ

Task {
    let remoteConfig = RemoteConfig.remoteConfig()
    try await remoteConfig.fetch()
    try await remoteConfig.activate()
    let puppyName = remoteConfig["puppy_name"].stringValue
    let puppyAge = remoteConfig["puppy_age"].numberValue
    let isCute = remoteConfig["isCute"].boolValue
    let character = try remoteConfig["character"].decoded(asType: Character.self)
    print("제 강아지 이름은 \(puppyName)이고 \(puppyAge)살이고 \(isCute ? "귀여워요" : "별로에요").")
    dump(character)
}

인앱 기본값 설정도 가능해요

지금가지는 Firebase Console에서 기본값을 설정해주었지만 각각의 앱 별로 별도의 기본값을 사용해줘야 할 일이 생기기도 합니다.(ex: iOS, Android에 따른 기본값 분기 처리 등)

인앱 기본값을 설정하기 위해 Firebase Console에서 기본값 파일을 다운로드 받은 후, 앱 내 적용해 이를 구현할 수 있습니다.

원격 구성 기본값을 다운로드 받으면 `remote_config_defaults.plist` 파일이 다운로드 됩니다. 해당 파일을 프로젝트에 적용 후, 설정하고 싶은 기본값을 구성합니다.

static func setupRemoteConfig() {
    let remoteConfig = RemoteConfig.remoteConfig()
    let settings = RemoteConfigSettings()
    settings.minimumFetchInterval = 0
    remoteConfig.configSettings = settings
    remoteConfig.setDefaults(fromPlist: "remote_config_defaults") // ⭐️ 기본값 설정
}

그럼 이렇게 안귀여운(?) 한톨을 출력할 수 있게 됩니다.

실시간 업데이트도 가능해요

지금까지 RemoteConfig를 받아오는 방식은 매번 명시적으로 불러오는 것이었습니다.(ex: viewDidLoad, onAppear 시점에 RemoteConfig 값 호출)

하지만 Rx나 Combine, AsyncStream처럼 비동기 스트림 형태, 즉 실시간으로 값을 받을 수 있는 방법도 있습니다!

// ⭐️ Remote Config 리스너 추가
remoteConfig.addOnConfigUpdateListener { configUpdate, error in

    // ⭐️ 에러 처리
    if let error {
        print("에러 발생: \(error.localizedDescription)")
        return
    }
    
    // ⭐️ 업데이트가 있을 시 로직 호출
    if let _ = configUpdate {
        Task {
            let remoteConfig = RemoteConfig.remoteConfig()
            try await remoteConfig.fetch()
            try await remoteConfig.activate()
            let puppyName = remoteConfig["puppy_name"].stringValue
            print("실시간 민톨 이름 업데이트: \(puppyName)")
        }
    }
}

민톨이는 100세까지 살자

SwiftUI용 프로퍼티 래퍼도 있어요

일반 함수 안에서는 위와 같이 리스너를 추가해 실시간 값을 받아올 수 있지만, SwiftUI View 용으로만 사용한다면 전용 프로퍼티 래퍼 `@RemoteConfigProperty` 사용을 고려해봐도 좋습니다. 아래와 같이 추가하면 정말 쉽게 실시간 View 업데이트를 사용할 수 있게 됩니다!

struct ContentView: View {
  @RemoteConfigProperty(key: "puppy_name", fallback: "기본 민톨") var puppyName

  var body: some View {
    VStack {
      Text(puppyName)
    }
    .onAppear {
      RemoteConfig.remoteConfig().fetchAndActivate()
    }
  }
}

역시 좋은 기능은 잘 찾아오면 이미 있다,,, ㅎㅎ

최근 회사 프로젝트에서 광고 SDK 관련 민감한 로직의 분기 처리를 빠르게 적용하기 위해 Sever-Driven 대신 Firebase Remote Config를 사용했었습니다. 이미 여기저기 사용 중이었기 때문에 이미 있던 값들을 가져다 쓰기만 했었는데, 역시 이렇게 직접 구현해보니 더 제 것이 되는 것 같습니다.

예전 캐플 프로젝트 때도 Remote Config를 적극적으로 활용했으면 서버 분들께 부담 드리지 않고 다양한 이벤트를 진행해 볼 수 있었을 것 같다는 아쉬움도 남네요 ㅜ

팩트풀니스 - 그럼에도 불구하고 세계는 생각보다 괜찮다

thinkyside — Sat, 8 Nov 2025 17:41:57 +0900

오랜만에 책을 직접 사서 읽었다. 밀리의 서재 등을 이용해 읽는 방식도 한 때 시도해 봤지만 역시 종이책의 감성과 질감을 포기하기란 쉽지 않다. 책을 마음껏 사용하고 싶은 마음도 있었다. 도서관에서 빌려온 책들이 아무렇게나 접혀있거나 세월의 흔적들을 보는 게 즐겁긴 하지만 내 생각을 펼치기엔 아무래도 모두가 읽을 책이라는 점에서 양심에 걸리니 말이다. 직접 사서 읽는 경험이 꽤나 좋았기 때문에 앞으로도 읽고 싶은 책이 있을 때 자주 서점을 들락 나락 해볼 생각이다.

팩트풀니스를 읽으며 세계를, 인생을 바라보는 관점이 바뀌어감을 느꼈다. 최근 우리나라 모든 세대를 흥분하게 만든 정치적 갈등, 공포와 좌절감을 안겨주는 수많은 부정적인 뉴스들, 스스로 앞으로 나아가고 있는 것인지에 대한 확신이 없을 때 등 나는 그저 오래된 직관만을 사용해 상황을 인식하고 그것이 사실이라 믿었다. 주변 사람들도 비슷하게 생각하고 있었고, 의견을 나누다 보면 의심조차 하지 않을 수밖에 없었다. 이런 상황은 어쩔 수 없는 것이라 생각했다.

하지만 이 모든 건 내가 생각하는 것만큼 나쁘지 않고, 그렇게 흘러가지도 않는다. 느려 보여도, 당장은 나쁜 상태라 해도 긍정적인 변화도 양립하는 상황일 수 있음을, 부정적인 뉴스가 들끓어도 그럴 수밖에 없는 시스템에서 비롯됐음을, 악의적인 의도가 없었을 거라는, 무지에서 발생했기에 주의해서 봐야 함을 알 수 있었다.

이렇게 느낄 수 있었던 것은 책 제목에서도 드러나있듯 '팩트풀니스', 즉 '사실충실성'에 기반한 객관적 수치와 자료를 바탕으로 한 내용들이었기 때문이다. 세계는 객관적으로 긍정적인 방향으로 발전해가고 있고, 우리가 이를 정확히 판단하지 못하는 이유는 오랜 세월 축적되어 온 인간의 본능 때문이다. 어렵겠지만 이제는 정확한 판단과 진단, 그리고 실천 가능한 해결 방안을 위해 '사실충실성'에 기인해 현상을 바라보도록 노력해야 할 것이다.

책에서는 세계에 대해서 이야기했지만, 나는 개인의 인생에 있어서도 '사실충실성'이 필요하다 느낀다. 10가지 본능은 스스로의 인생에 대해서도 과도하고 부정적으로 인식하게 만든다. 늘 뒤쳐저있는 것 같고, 잘하고 있는지 확신이 들지 않고, 어떻게 하면 더 잘할 수 있을까 궁리하며 스트레스를 받는다. 하지만 중요한 건 나는 조금씩 성장하고 있다는 것이다. 스스로 만족하지 못하고 나쁜 상태라고 생각이 들어도, 긍정적인 변화를 축적하고 있다. 그 사실은 변함이 없고, 앞으로도 그러기 위해 노력할 것이다. 그러니 불필요한 공포감은 내려놓자. 나는 낙관주의자가 되려는 것이 아닌 실천주의자가 되려는 것이다.

딥링크, URL 스킴, 유니버셜 링크, 다이나믹 링크 뭐가 뭔데?

thinkyside — Sun, 26 Oct 2025 21:45:44 +0900

어떤 버튼을 눌렀을 때 특정 앱이 열리는 기능은 우리에게 익숙합니다. 그런데 도대체 이 기능을 뭐라고 불러야 할까요? 어디서는 딥링크, 어디서는 URL 스킴, 유니버셜 링크, 다이내믹 링크 등 다양한 용어가 들려오는데 이름만 다른 걸까요? 혹은 정말 다른 기능들일까요?

오늘은 iOS 앱 개발 관점에서 알쏭달쏭 헷갈리는 용어들에 대해 확실하게 이해해 보는 시간을 가져보겠습니다!

사실은 모두 딥링크

이것저것 단어가 많지만 사실은 모두 '딥링크'라고 할 수 있습니다. URL 스킴, 유니버셜 링크, 다이나믹 링크 등 "앱 내 특정 페이지로 바로 연결되는 모든 기술"은 딥링크라는 큰 기술 카테고리에 묶인다고 이해하면 됩니다.

딥링크 == 일반적인 용어(대 카테고리)

가장 전통적인 방법, URL Scheme

URL Scheme은 딥링크의 가장 전통적인 방식입니다. 앱이 고유하게 등록한 URL 형식을 사용해 앱을 실행하는 방식으로 `myphotoapp:albumname?name="albumname"`과 같은 구조로 사용됩니다.

다른 앱의 실행을 요청하거나 간단한 데이터 전달 가능.
앱이 설치되어 있을 때만 작동.
iOS 9.0 이전까지의 표준 딥링크 방식.
앱에 잠재적인 공격 경로를 제공할 수 있기 때문에, 매개변수의 유효성을 검사하고 잘못된 URL은 삭제해야 함.(특히 개인정보를 포함하는 것은 위험!)
앱스토어에서 Scheme의 고유성을 보장해주지 않기 때문에 다른 곳에서 무단 사용할 수 있음.(이 때문에 애플은 아래에서 후술 할 유니버설 링크 사용을 권장함.)

애플에서 제공하는 URL Scheme 공식 문서, Defining a custom URL scheme for your app를 참고해 직접 URL Scheme을 가지고 놀아보겠습니다.

1. 내 앱으로 이동할 수 있는 URL Scheme 추가해 보기

Xcode의 Targets - Info - URL Types에 새로운 URL Scheme을 추가해 보겠습니다.

가장 첫 번째 필드인 Identifier에는 다른 앱과 내 앱을 구분하는 데 사용될 식별자를 지정합니다. 애플 공식문서에서는 고유성을 보장하기 위해 회사 도메인(저의 경우 개발자 이름!)과 앱 이름을 포함하는 역방향 DNS 문자열 지정을 권장합니다.(하지만 근본적으로 다른 앱과 동일한 Scheme 등록을 막을 수는 없다고 합니다 )

두 번째 필드인 URL Schemes에는 딥링크 URL 앞에 들어갈 접두사를 지정합니다. 저의 경우 앱 이름인 'poporazzi'를 지정해 주었으며, 앞으로 `poporazzi://`의 형태로 앱이 열릴 수 있게 만들어 줄 수 있을 겁니다!

여기서 한 가지 더 주의해야 할 점은, 일부 URL Scheme은 애플 시스템 전용으로 예약되어 있습니다. 기본 메일, 전화, 지도, 음악 앱 등이 이에 포함되어 있으며 자세한 내용은 App URL Scheme Reference 페이지에서 확인할 수 있습니다.(한 마디로 애플이 미리 등록해 놓은 URL Scheme은 사용 못 한다~ 얘기입니닷)

(요 아래부터는 거의 사용하지 않으나 어떤 건지 알아보는 목적으로 쓱 훑으면 좋지 않을까 싶습니다.)

세 번째 필드인 Icon은 URL Scheme과 연결된 문서 아이콘을 지정합니다. 딥링크로 열 수 있는 파일이나 문서 등을 표시할 때 사용된다고 하는데, 일반적인 경우엔 사용하지 않는다고 합니다.

네 번째 필드인 Role은 앱이 URL을 어떻게 처리하는지 정의합니다. 지정할 수 있는 옵션은 Viewer(읽기 전용), Editor(읽기/쓰기), None(역할 정의 X) 3가지로 나뉘는데 식별을 위한 요소일 뿐이지 기능적인 영향은 없다고 합니다.

그 아래 Additional url type properties에는 커스텀 속성을 정의할 수 있습니다. URL Scheme의 버전 정보나 설명 등을 추가할 수 있다고 하는데 이 또한 기능적인 영향은 없어 대부분의 딥링크 구현에선 비워도 무방합니다.

2. URL Scheme으로 내 앱 열어보기

요렇게 만들어본 URL Scheme으로 제 앱을 열어봐야겠죠? 위에서도 언급했듯, URL Scheme은 앱이 설치되어 있을 때만 동작하기 때문에 꼭 새로 빌드 후 테스트 해보는 걸 잊지 않으며, Safari에 URL Scheme을 입력해 보면 아주 잘 열리는 것을 확인할 수 있습니다!

위에서 지정한 접두사로 딥링크 입력

++ 만약 앱이 설치되어 있지 않다면, URL Scheme을 찾을 수 없기 때문에 Safari에서 유효하지 않은 주소라고 알려주게 됩니다.

3. URL Scheme으로 들어온 이벤트 핸들링하기

URL Scheme으로 들어온 이벤트에 대해 특정 행동을 하거나, URL 매개변수를 파싱해 특정 화면으로 이동시키고 싶은 경우엔 `SceneDelegate`의 LifeCycle에서 이벤트를 핸들링할 수 있습니다.

// 1. 앱이 실행되지 않은 상태에서 URL Scheme이 실행될 때
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    if let url = connectionOptions.urlContexts.first?.url {
        // 여기서 핸들링!
    }
}

// 2. 앱이 이미 실행 중일 때 딥링크가 열릴 때
func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    if let url = URLContexts.first?.url {
        // 여기서 핸들링!
    }
}

여기서 옵셔널 바인딩 되는 `URL` 타입을 가지고 host, path, query 등을 추출해 다양한 URL Scheme에 따라 분기 처리를 하면 되겠죠? 주의해야 할 점은, 앱의 실행 여부에 따라 실행되는 SceneDelegate 내 메서드가 다르기 때문에 목적에 따라 구현해야 함을 유념해야 합니다.

4. 내 앱에서 다른 앱의 URL Scheme 열기

`UIApplication`에서 제공하는 `open` 함수를 사용해 다른 앱의 URL Scheme을 열 수 있습니다.

if let url = URL(string: "poporazzi://") {
    UIApplication.shared.open(url) { result in
        if result {
           // URL Scheme 실행 결과 handler
        }
    }
}

현재 표준이 된 유니버셜 링크 Universal Link

유니버셜 링크는 Apple의 공식 딥링크 기술입니다.(안드로이드의 App Link와 대응) 위에서 소개한 URL Scheme의 한계점인 앱 설치의 필요성, 고유성 보장, 보안 등의 문제를 해결해 줄 수 있어 현재 가장 보편적으로 사용되고 있습니다.

https://myphotoapp.com/name/albumname 형식으로 사용.(일반 HTTPS 형식을 따름)
앱 미설치 시 웹사이트로 이동할 수 있게 처리 가능.
iOS 9.0 이후 표준 딥링크 방식.
앱의 Bundle Id를 미리 특정 도메인의 웹사이트에 등록하는 방식으로, 고유성을 보장할 수 있음.
일반 웹 URL이기 때문에 SEO 최적화.
Apple이 서버 인증서(AASA)로 검증해 보안 향상.

이렇게 보면 URL Scheme을 사용하지 않을 이유가 없어 보이지만, 도메인과 서버 설정이 필수적이기 때문에 구현과 테스트가 어렵다는 단점도 존재합니다. 그래서 작은 앱을 만들 때는 URL Scheme을 사용하는 것이 효율적일 수도 있겠습니다!

클라이언트 입장에서 유니버셜 링크를 테스트해보고 싶기 때문에 간단하게 Vercel을 사용해 진행해 보겠습니다.(이 과정에서 서버 관련 지식이 한참 부족하다 보니 좀 헤매버렸습니다,,)

1. 서버 - AASA(apple-app-site-association) 파일 추가

유니버셜 링크를 사용하기 위해 필수적인 것이 도메인과 서버 설정입니다. 이 때 도메인 정보가 포함된 JSON 파일인 AASA(apple-app-site-association) 파일을 서버에 업로드 해야 해당 파일을 확인 후 앱을 실행시켜주는 프로세스입니다.

AASA 파일 구성 시 중요한 부분은 appID와 components(path)입니다. app ID에는 {Team-ID}.{Bundle-ID} 로 구성된 값을 넣어주고, components에는 이동할 경로를 명시합니다.

{
  "applinks": {
    // 유니버셜 링크에서는 사용하지 않지만 빈 배열로 명시 필요
    "apps": [],
    // 웹사이트에서 이동 가능한 앱 목록.
    "details": [
      {
        // {Team-ID}.{Bundle-ID}
        "appIDs": ["9XG4S4XZWN.com.thinkyside.poporazzi"],
        // 웹사이트 경로
        "components": [
          {
            "/": "*"
          }
        ]
      }
    ]
  }
}

서버 구성 시 확인해야 할 점은 HTTPS와 SSL 지원 여부입니다. 애플의 보안 정책 때문인지 기본적으로 챙길 수 있는 것들은 체크가 필요할 듯 합니다! 또한 AASA 파일은 웹사이트 내 표준화된 메타데이터나 설정 파일을 저장하는 디렉토리인 `.well-known`에 추가되어야 합니다.

2. 클라이언트 - Associated Domains(Capabilities) 설정

클라이언트(iOS 개발자)는 Xcode를 이용해 Associated Domains Capabilities를 설정해 주어야 합니다. Targets - Signing & Capabilites 탭에서 + Capability 버튼을 클릭합니다.

Targets - Signing & Capabilites 탭에서 + Capability 버튼 클릭

이후 유니버셜 링크를 설정해 줄 수 있는 Capability인 Associated Domains를 클릭해 추가해줍니다.

Associated Domains 검색 후 추가

요렇게 추가된 Associated Domains 아래 Domains Row에 우리의 도메인을 추가하면 완료입니다. 아래 추가할 도메인은 `applinks:{YOUR_DOMAIN}` 형식으로 작성되어야 합니다. 저는 vercel에서 내려준 도메인을 입력해주었습니다.

applinks:{YOUR_DOMAIN} 추가

이제 테스트 해보면! 딥링크가 아주 잘 동작하는 것을 확인할 수 있습니다.(만약 딥링크가 동작을 안한다면 10~20분 정도 기다려본 후 다시 시도해보는게 도움이 될 수 있습니다! Apple CDN이 캐시를 업데이트 하는 시간이 필요하다고 하네요,,, >> 이것 때문에 다른 곳에서 삽질 엄청함)

3. 유니버셜 링크로 들어온 이벤트 핸들링하기

유니버셜 링크 또한 `SceneDelegate`에서 이벤트를 핸들링할 수 있는데 `URLContext`를 이용했던 URL Scheme과 달리, `NSUserActivity`를 이용해야 합니다.

NSUserActivity는 특정 시점의 앱 상태를 나타내는 객체로, 사용자가 수행한 작업에 대한 정보를 캡처합니다. 보통 그 아래 속성인 `webPageURL`을 이용해 URL 타입을 반환 받고 path, query에 따라 분기 처리를 진행하면 됩니다.

// 1. 앱이 실행되지 않은 상태에서 URL Scheme이 실행될 때
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    if let url = connectionOptions.userActivities.first?.webpageURL {
        // 여기서 핸들링!
    }
}

// 2. 앱이 이미 실행 중일 때 딥링크가 열릴 때
func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
    if let url = userActivity.webpageURL {
        // 여기서 핸들링!
    }
}

앱이 실행되지 않을 때는 URL Scheme과 마찬가지로 `willConnectTo` Delegate 메서드를 이용하면 되지만, 앱이 이미 실행 중일 때는 `continueUserActivity` Delegate 메서드를 사용해야 한다는 점을 체크해주세요!

다른 앱의 유니버셜 링크를 여는 방법은 URL Scheme과 동일합니다~!

if let url = URL(string: "https://poporazzi.vercel.app/home") {
    UIApplication.shared.open(url)
}

하나의 링크로 여러 플랫폼을 관리하는 똑똑한 다이나믹 링크 Dynamic Link

마지막은 다이나믹 링크입니다. 보통 앱 개발 시 iOS와 안드로이드 OS를 지원하게 되는데, 유니버셜 링크의 경우 애플의 독자적인 딥링크 기술이기 때문에 안드로이드에서의 딥링크는 앱 링크(App Link)로 별도 구현이 필요합니다.

이는 딥링크가 새로 추가될 때마다 작업량도 두배, 수정될 때도 체크해야 할 포인트가 두배가 되기 때문에 유지보수성이 떨어질 수 밖에 없게 됩니다. 이를 해결해줄 수 있도록 하나의 링크로 모든 OS에 대한 딥링크를 연결해주는 AppsFlyer, Branch.io 등이 제공하는 것이 다이나믹 링크입니다.

다이나믹 링크를 지원하는 서비스에 따라 조금씩 다르지만, 크게 아래와 같은 기능들을 제공합니다.

하나의 링크로 iOS/Android 멀티 플랫폼 딥링크 지원.(각각의 기술로 컨버팅)
Deferred Deep Link 기술 지원.(앱 미설치 사용자에게도 딥링크 정보를 전달할 수 있는 기술, 이건 별도 포스팅 해보면 좋을듯!)
링크 단축 기능 제공.
링크 클릭 수, 앱 설치 전환율, 플랫폼별 통계 등 데이터 제공.
A/B 테스팅 지원.

다이나믹 링크의 핵심은, 비즈니스 차원에서 유지보수 비용도 줄이고 다양한 데이터들을 볼 목적으로 사용하는 서비스 차원의 개념이라는 것입니다. 또한 iOS의 경우 다이나믹 링크도 실제 동작은 결국 유니버셜 링크를 사용하기 때문에, 구현 방법은 위에서 서술한 방식과 동일합니다!

최종 정리

기능	URL Scheme	Universal Link	Dynamic Link
형식	myapp://	https://myapp.com	https://myapp.page.link
iOS 버전	iOS 9.0 미만	iOS 9.0 이상	iOS 9.0 이상
앱 미설치 시 동작	❌ 경고 발생	✅ 웹페이지 이동	✅ 스토어→ 설치→ 딥링크(Deferred)
도메인 필요 여부	❌ 불필요	✅ 필수	✅ 필수(서비스가 제공해줌)
서버 설정	❌ 불필요	✅ 필수(AASA 파일 추가)	❌ 서비스가 관리
고유성 보장	❌ 보장하지 않음	✅ 도메인으로 보장	✅ 서비스가 보장
보안	⚠️ 낮음	✅ 높음(Apple 검증)	✅ 높음
크로스플랫폼	❌ OS별 구현	❌ OS별 구현	✅ 하나로 관리 가능
추천 용도	앱 간 통신, 간단한 앱	표준 딥링크, 비즈니스 레벨의 앱	유지보수, 마케팅이 필요한 앱

Firebase App Distribution + Fastlane으로 초간단 QA 빌드 뽑아보기

thinkyside — Sun, 19 Oct 2025 23:00:34 +0900

아카데미에서 개발을 하지 않는 팀원분들께 중간중간 만들어진 앱을 공유, 즉 QA를 위해 사용했던 방법은 이랬습니다. 아이폰을 맥북에 연결해 직접 빌드하기, 혹은 TestFlight를 이용해 내부 테스터로 초대하기 등이었죠.(그냥 제 아이폰을 주는 방법도 있었답니다) 그리고 생각보다 아이폰을 직접 연결해 빌드한다는 단순무식(?)한 방법을 자주 사용하곤 했는데, TestFlight라는 좋은 Tool을 놔두고 왜 그랬을까요?

기존 배포의 불편한 점

TestFlight는 애플이 제공하는 공식 베타 테스트 플랫폼입니다. TestFlight에 초대되었다면 누구든 베타 버전을 쉽게 받아볼 수 있죠. 하지만 TestFlight의 배포 프로세스는 생각보다 오래 걸립니다.

Xcode 빌드 및 Archive
애플 서버에 업로드
애플 서버 내에서 유효성 검사 및 처리(이 과정은 수분에서 수십 분 이상 소요)

이 과정은 앱 크기나 환경에 따라 달라질 수 있겠지만 제 경험 상 약 20분 이상 소요됩니다. 아카이브 빌드가 되길 기다리고,,, App Store Connect 설정을 마치고,,, 업로드가 되더라도 언제 완료될지 모르는 유효성 검사를 기다려야 합니다.(이 과정이 생각보다 김,,,) 한마디로 귀찮고 비효율적인 작업이죠.

TestFlight의 배포 프로세스가 이렇게 귀찮고 꽤나 오래걸리다보니, 급한 상황에선 가장 빠르고 확실한 디바이스 연결을 통한 직접 빌드 방식을 많이 선택하게 되었습니다. 물론 이 방법은 서로 오프라인 내 같은 공간에 있어야 하다 보니 절대 좋은 방법이라고 이야기할 수는 없었습니다.(팀원과의 돈독함이 올라가는 긍정적인 효과는 있었지만 말이죠)

나노 바나나가 나름 적절한 짤을 뽑아줬다

처음 맛본 배포 자동화

그렇게 입사 후 얼마 안 됐을 때쯤, 회사에서 QA 빌드를 뽑아야 한다 들었을 때 자연스럽게 TestFlight를 통한 배포를 생각했습니다. 하지만 그것보다 훨씬 빠르고 효과적인 방법을 사용하고 있었습니다! 터미널에 `fastlane ios dev`라고 명령하면 자동으로 배포 프로세스가 돌고 약 10분 이후 Firebase App Distribution에서 QA 빌드를 설치할 수 있다는 메일을 확인할 수 있었습니다.

사실상 제가 할 일은 터미널에 명령어만 작성하면 되는 것이었고, 시간도 TestFlight 대비 훨씬 빠르게 배포할 수 있었습니다. 그래서 오늘은 제가 맛본 자동화를 도와줄 Firebase App Distribution + Fastlane을 직접 적용해 보며 정리해 보겠습니다!

Firebase App Distribution을 통한 빠른 배포

Firebase App Distribution은 Google Firebase에서 제공하는 모바일 앱 배포 플랫폼으로 아래 주요 기능을 제공합니다.

크로스 플랫폼 지원(iOS 및 Android 플랫폼 관리)
빠른 배포(SDK를 설치할 필요 없이 신속한 온보딩, 인스턴트 앱 배포)
CI 통합 기능 제공(fastlane 등)
테스터 관리
Crashlytics 연동

이것저것 장점이 많지만 가장 중요한 기능은 아무래도 빠른 배포와 CI 통합 기능 제공입니다. 직접 사용해 보며 어떤 프로세스로 흘러가는지 살펴보 겠습니다.

1. 테스터 기기 등록

우선 테스터들이 다운로드 받을 기기를 등록합니다. UUID를 통한 등록이며, 등록에 따른 시간도 소요되기 때문에 가장 먼저 추가하는 것을 권장합니다!

Devices + 클릭

Device Name, UUID 입력 후 Continue 클릭

이렇게 테스터들의 기기 등록을 마친 후 수정된 프로비저닝 파일을 기반으로 아래 프로세스를 진행해야 정상적으로 테스터들이 앱을 다운로드 받을 수 있게 됩니다.

2. Xcode 아카이빙 및 IPA 파일 export

Firebase App Distribution에 빌드를 업로드하려면 IPA(iOS App tore Package) 파일이 필요합니다. 이를 위해 Xcode를 통해 Archive하고 IPA 파일을 export합니다.

{Version}({BuildNumber}) 형식으로 네이밍 되니 이 점을 참고해 아카이빙 전 체크하면 좋습니다!
ex) 1.5.4(1)

Product > Archive

Distribute App

Custom

Debugging

Export

여기까지 진행 후 Export 하면 필요했던 IPA 파일을 확인할 수 있습니다.

3. IPA 파일 업로드

이제 export 한 IPA 파일을 Firebase App Distribution에 업로드해야 합니다. Firebase Console로 이동 후, 왼쪽 탭에서 App Distribution으로 이동합니다. 이후 IPA 파일을 드래그 앤 드롭 해 업로드합니다.

IPA 파일 드래그 앤 드롭

업로드 중...

완료!

4. 테스터 추가 및 배포

이제 기본 세팅은 끝났습니다. 해당 배포를 다운 받을 테스터를 추가하고, 배포하면 개발자가 할 일은 끗!

테스터 추가(그룹에 미리 등록해두면 편하겠죠?)

optional) 출시 노트 추가

배포 완료!

5. 테스터 다운로드

배포가 완료되면 테스터들에게 초대 메일이 발송됩니다.

Get started 버튼 클릭

첫 초대 수락 시, 약관 동의 및 Firebase 프로필 다운로드가 필요합니다.

약관 동의 및 초대 수락

수락된 링크 이동 시, 배포된 앱 확인 가능. 다운로드하려면 기기 등록(프로필 설치) 필요

설정 앱 > 일반 > VPN 및 기기 관리 > Firebase App Distribution 설치

약관 동의 및 기기 등록까지 마무리 후 App Distribution 페이지에서 다운로드가 가능합니다. 이렇게 한번 등록해둔 테스터들은 이후 빌드부턴 바로 다운로드 할 수 있게 됩니다.

Fastlane을 통한 간단한 배포

기기 및 테스터 등록을 미리 해두었다면, 개발자가 할 일은 아카이빙 > IPA 파일 추출 > IPA 파일 업로드 순일 것입니다. 이 방식은 TestFlight 보다 빠르게 배포할 수 있지만(애플 서버를 통한 유효성 검증 과정이 생략되기 때문) 여전히 너무 귀찮은 작업이긴 합니다. 이를 해결할 수 있도록 Firebase는 Fastlane을 통한 CI 기능을 제공합니다.

Fastlane은 앱 배포 프로세스를 단순화하고 일관된 워크플로우로 통합할 수 있도록 돕는 오픈 소스 플랫폼입니다. Fastlane의 기능은 뒤에 설명할 베타 배포 자동화 이외에도 코드 서명 및 인증서 관리, 테스트 코드 실행 등 유용한 기능이 많지만 이 부분은 추후 별도의 포스팅에서 다뤄보는 것으로 하고, 오늘은 Firebase App Distribution과의 통합을 중점적으로 다뤄보겠습니다.

1. Fastlane 설치

homebrew를 통해 Fastlane을 설치합니다.

brew install fastlane

2. Fastlane 프로젝트 생성

작업 중인 디렉토리에서 아래 명령어를 실행 후, Fastlane 프로젝트를 생성합니다. 중간중간 어떤 용도로 사용할거냐는 내용들이 나오는데, 나중에 얼마든지 수정이 가능하니 적당한걸로 선택하면 됩니다!

fastlane init

3. Fastlane 플러그인 설치

이제 Firebase App Distribution 연결을 위한 플러그인을 설치합니다. 우선 Pluginfile을 만들어 어떤 플러그인을 사용할 것인지 정의해 주고,

gem 'fastlane-plugin-firebase_app_distribution'

Gemfile에서 해당 파일을 사용할 수 있도록 다음과 같이 수정합니다.

source "https://rubygems.org"

gem "fastlane"

plugins_path = File.join(File.dirname(__FILE__), 'fastlane', 'Pluginfile')
eval_gemfile(plugins_path) if File.exist?(plugins_path)

4. Firebase 로그인

이후 Firebase를 사용하기 위해 Firebase CLI를 설치 후 로그인 합니다.

# Firebase CLI 설치
brew install firebase-cli

# Firebase 로그인
firebase login

5. 환경 변수 파일 생성

각종 환경 변수를 관리하기 위해 `.env` 파일을 생성 후, Firebase App ID를 등록해주었습니다. Firebase에 프로젝트를 등록할 때 추가했던 `GoogleService-Info.plist` 파일의 `GOOGLE_APP_ID`를 참고해 추가할 수 있습니다.

FIREBASE_APP_ID={GOOGLE_APP_ID}

6. Fastfile 설정

이것저것 준비 과정이 길었는데 이제 본격적인 배포 커스텀입니다. 저는 아래와 같이 구현했습니다.

`fastlane qa notes:"어쩌구저쩌구 출시노트"` 로 실행
날짜/시간 기반 빌드 번호 생성 ex) 1.5.4 (2510192247)
internal 테스트 그룹에 배포

* 사내 Fastfile에선 QA 빌드 뿐만이 아닌 자동으로 버전, 커밋을 기준으로 출시노트를 작성해주는 Production 빌드 등도 사용하고 있었답니다. 각자 목적에 맞게 여러가지로 커스텀 해두면 생산성이 정말 많이 올라갈 것 같아요!

default_platform(:ios)

platform :ios do
  desc "QA 빌드를 배포합니다."
  lane :qa do |options|
    _set_build_number_with_timestamp
    _build
    release_notes = _prepare_release_notes(options)
    _upload_to_firebase_app_distribution(release_notes: release_notes)
  end

  # 날짜/시간 기반 빌드 번호 생성 (YYMMDDHHMM)
  private_lane :_set_build_number_with_timestamp do
    new_build_number = Time.now.strftime("%y%m%d%H%M")
    increment_build_number(
      xcodeproj: "poporazzi.xcodeproj",
      build_number: new_build_number
    )
  end

  # 앱 빌드
  private_lane :_build do
    build_app(
      scheme: "poporazzi",
      export_method: "development"
    )
  end

  # 출시 노트 준비
  private_lane :_prepare_release_notes do |options|
    options[:notes] || "QA 빌드"
  end

  # Firebase App Distribution에 업로드
  private_lane :_upload_to_firebase_app_distribution do |options|
    firebase_app_distribution(
      app: ENV["FIREBASE_APP_ID"], # .env 파일에서 관리
      groups: "internal", # 테스트 그룹명
      release_notes: options[:release_notes], # 출시 노트
      firebase_cli_path: "/usr/local/bin/firebase"
    )
  end
end

7. 실행해보기

이후 만들어둔 fastlane 커맨드를 이용해 요렇게 입력해주고 기다리다보면,,,

에러가 발생하지 않는다면 아래와 같은 요약과 함께 배포가 완료된 것을 확인할 수 있습니다.

이후 테스터들은 QA 빌드를 다운받을 수 있는 메일을 출시노트와 함께 받을 수 있고, 빠른 배포 프로세스가 완성된 것을 확인할 수 있습니다!

적용 후기

이렇게 한번 적용해두니 이전 방식으로 되돌아갈 수 없을 정도로 편리하다는 생각이 들었습니다. 처음 설정 과정도 공식 문서 등을 통해 쉽게 따라할 수 있으며, Fastfile 작성 또한 생소한 Ruby 언어이나 문법이 어렵지 않아 금방 익힐 수 있고 또는 AI에게 요구사항을 부탁하면 아주 잘 써주는 것을 확인할 수 있었습니다.

팀 프로젝트에선 오늘과 같이 QA 빌드 lane을 만들어두면 제일 잘 써먹을 수 있을 것 같고, 개인 프로젝트에선 Production 빌드 lane을 만들어 하루에도 여러번 배포할 수 있는 환경을 구성해보면 어떨까 합니다.(다음 개인 프로젝트에선 꼭 써먹어 보는 걸루 )