아기개발자의 성장일기

[Git] Merge Commit > Interactive Rebase (--rebase-merges 옵션)

eungding — Sat, 27 Sep 2025 17:38:31 +0900

[1] Merge Commit 은 왜 기본적으로 Interactive Rebase 가 안될 까 ?

Git의 rebase --interactive (또는 간단히 rebase -i) 는 히스토리를 직선(선형)으로 평탄화하려고 설계되어 있어서,

부모가 2개 이상인 merge commit은 목록에 포함되지 않거나 편집 대상이 아닙니다.

그래서 기본적으로 머지 커밋을 Interactive Rebase (edit, fixup, reword 등) 할 수 없어요.

머지 커밋의 구조

머지 커밋은 브랜치를 합치는 시점에 생기며,
부모가 두 개 이상 → 양쪽 브랜치의 끝을 모두 가리킵니다.

      D --- E   (feature 브랜치)
     /         
A -- B -------- M   (main 브랜치)
                ↑
                머지 커밋 (부모 = B, E)

여기서 M은 부모가 두 개:

하나는 main 브랜치 쪽(B),
하나는 feature 브랜치 쪽(E).

그래서 interactive rebase가 힘든 이유

git rebase -i는 선형 히스토리(부모가 1개인 체인)만 전제로 동작합니다.

머지 커밋은 부모가 2개라 “어떤 선을 따라가야 할지” 모호하기 때문에, 기본 rebase -i 에는 나오지 않아요.

[2] --rebase-merges 옵션

하지만 따로 --rebase-merges 옵션을 쓰면 머지 커밋도 포함한 채로 리베이스할 수 있습니다.

✅ --rebase-merges 옵션이란?
git rebase는 기본적으로 선형 히스토리만 다루기 때문에, 머지 커밋(부모가 2개 이상인 커밋) 은 무시해 버립니다.

--rebase-merges 옵션을 붙이면:
• 머지 커밋 구조를 보존하면서 리베이스할 수 있습니다.
• interactive rebase(-i)와 함께 쓰면 todo 리스트에 merge … 라인이 나타나서, 머지 커밋도 edit, reword, drop 같은 조작이 가능해집니다.

✅ 정리
• rebase -i = 선형 히스토리만
• rebase -i --rebase-merges = 머지 커밋 포함해서 히스토리 재작성 가능

포크에서는 해당 옵션을 지원안하는 것 같고 터미널을 통해 해야하는 것 같아요!

https://github.com/fork-dev/TrackerWin/issues/806

Add option for --rebase-merges when rebasing interactively · Issue #806 · fork-dev/TrackerWin

I'm forced to leave Fork when I want to rewrite the history of a merged branch (--no-ff) as the default rebase puts the rebased commits into a linear branch. Could we have an option when rebasing t...

github.com

[3] --rebase-merges 옵션 써보기

일단 필요한 상황을 가정해볼게요~

1) 추가 커밋 1을 머지 커밋에 합치고 싶을 때

추가 커밋 1
머지 커밋

이런 상황에서는 --rebase-merges 옵션 안쓰고도 충분히 편하게 할 수 있어요!

추가 커밋 1을 soft 혹은 mixed reset 하고 amend (Amend Last Commit) 해서 머지커밋에 흡수시키면 됩니다.

✅ 2) 추가 커밋2 를 머지 커밋에 합치고 싶을 때

추가 커밋 2
추가 커밋 1
머지 커밋

이 상황도 사실 체리픽 + 리셋 으로 쉽게 하면 되는데요,,

추가 커밋 1을 reset 범위에 포함시키지 않고 정석대로 리베이스 하고 싶다는 것을 전제로 해보겠습니다.

전체적은 흐름은 다음과 같고

  # 1. interactive rebase 시작 (에디터가 열림)
  # - 현재 HEAD 에서 3번째 전 커밋까지 rebase 대상으로 삼겠다.
  git rebase -i --rebase-merges HEAD~3

  # 2. 에디터에서 다음과 같이 수정:
  #    - "pick d1d55ad 추가 커밋 2"를 "fixup d1d55ad 추가 커밋 2"로 변경
  #    - 그 줄을 잘라내서 "merge -C 324dcf5 main" 바로 아래로 이동
  #
  # 수정 전:
  # merge -C 324dcf5 main # Merge branch 'main' into feature
  # pick 0f8b2db 추가 커밋 1  
  # pick d1d55ad 추가 커밋 2
  #
  # 수정 후:
  # merge -C 324dcf5 main # Merge branch 'main' into feature
  # fixup d1d55ad 추가 커밋 2
  # pick 0f8b2db 추가 커밋 1

  # 3. 저장하고 에디터 종료하면 rebase가 실행됨

직접 하나씩 해볼게요!

우선 편하게 에디팅하기 위해 원하는 에디터로 열어줍니다.

저는 Sublime Text 로 열었는데

  GIT_EDITOR="subl --wait" git rebase -i --rebase-merges HEAD~3  # Sublime Text

Atom 으로 열고 싶으면 아래 명령어를 사용하시면 됩니다.

  GIT_EDITOR="atom --wait" git rebase -i --rebase-merges HEAD~3   # Atom

그럼 이런 git-rebase-todo 가 나오는데

이렇게 바꾸고

에디터를 저장 후 종료하면 리베이스가 실행됩니다.

참고)

요거 실행 후,

git rebase -i --rebase-merges HEAD~3

에디터로 수정안하고 포크를 열어서 GUI 로 수정할 수 있다고 AI 는 말하는데

포크로 넘어가보면 Interactive Rebase 창이 안열립니다 ;;

--rebase-merges 옵션을 사용하는 경우,

CLI(Command Line Interface) + 포크(GUI툴) 하이브리드로 못쓴다고 파악함.

[Swift] Swift Concurrency > MainActor deinit 헷갈리는 것 정리

eungding — Sat, 27 Sep 2025 15:29:08 +0900

[1] 목표

Swift 에서 deinit 은 항상 nonisolated 입니다.

객체 해제는 즉시 일어나야 하고, Executor 전환으로 지연되면 안되기 때문에

deinit 을 특정 Executor (ex. @MainActor) 에 격리 불가능합니다.

따라서 아래 세가지 상황에서 늘 헷갈리는데 정리해봅시다.

[2.1] 상황 1

현황)

이 상황은 swift 5 에서도 에러 발생합니다.

Strict Concurrency Checking 을 가장 낮은 수준 (Minimal) 로 해도 에러 발생.

원인)

• deinit 안의 코드는 nonisolated 상태로 실행됨.
→ 그런데 effect1.stop()은 @MainActor 격리된 메서드.
→ nonisolated(deinit)에서 actor-isolated(stop()) 호출 → 컴파일러가 막음.

• deinit은 “스레드 안 가리고 지금 당장 파괴해!” 모드.
• 그런데 stop()은 “꼭 메인 액터에서만 불러!”라는 규칙.
• 그래서 두 규칙이 충돌 → 에러.

해결)

// 1) 지역 변수로 뽑아내기
deinit {
    let e = effect1
    Task { @MainActor in
        e.stop()
    }
}

// 2) capture list로 직접 캡처
deinit {
    Task { @MainActor [effect1] in
        effect1.stop()
    }
}

• deinit은 nonisolated → @MainActor 메서드(stop)를 직접 호출 불가.
• 그래서 메인 액터로 hop (전환) 하는 작업만 예약 (Task { @MainActor in ... }) 하고 즉시 deinit을 끝냄
• let e = effect1로 강하게 캡처해 Task가 실행될 때까지 effect1의 수명을 잠시 연장 (사용 후 자동 해제).

+ 두 방법 다 내부적으로 동일한 동작을 하고 스타일 차이일 뿐입니다.

질문1)

만약 self 를 직접 캡쳐한다면 어떻게 되는가 ?

위의 코드에서 컴파일러는 effect1 에 접근하려면 결국 self 를 캡쳐해야한다고 판단하고

swift 5 에서는 워닝, swift 6 에서는 에러를 냅니다. Capture of 'self' in a closure that outlives deinit

deinit 안에서 만든 비동기 클로저(Task)가 self보다 더 오래 살아있을 수 있는데, 그 클로저가 self(를 통해 effect1)를 캡처했다. 그래서 금지!

- deinit { Task { … } }에서 Task 클로저는 탈출(escaping) 하며, deinit 종료 후에도 실행될 수 있음
- effect1.stop()를 부르려면 effect1(= self.effect1)에 접근해야 하므로 self를 캡처함.
- 하지만 deinit 이후 self는 해제되기 때문에, “deinit보다 오래 사는 클로저가 self를 잡는 것”은 안전하지 않아 컴파일러가 막음.

하지만 위의 해결 방안 처럼 하면 클로저는 self 가 아니라 effet1 만 캡쳐해서 괜찮은 것입니다.

// 1) 지역 변수로 뽑아내기
deinit {
    let e = effect1
    Task { @MainActor in
        e.stop()
    }
}

// 2) capture list로 직접 캡처
deinit {
    Task { @MainActor [effect1] in
        effect1.stop()
    }
}

두 경우 모두 self를 직접 캡처하지 않고,
effect1 라는 프로퍼티의 값을 deinit 시점에 지역 변수처럼 캡처합니다.
따라서 클로저는 self가 아니라 effect1 만 들고 있게 되고,
“Capture of ‘self’ in a closure that outlives deinit” 에러가 사라지는 거예요.

질문 2)

strong 이 아니라 weak 하게 캡쳐한다면 ?

• Task가 도는 시점에 effect가 이미 해제됐으면 아무 일도 안 함.
• → 정리 로직이 건너뛰어질 수 있음(누수는 아니더라도 의도한 정리 미실행 가능).

따라서

• 확실히 정리해야 함 → strong 캡처
• 있으면 하고, 없어도 됨 → weak 캡처

stop이 꼭 호출돼야 하는 중요 리소스 정리(타이머 invalidate, 관찰 해제, 파일 핸들 닫기 등) 에서는 strong 권장

[2.2] 상황 2

현황)

Swift 6 + Strict Concurrency Checking 을 가장 높은 수준 (Complete) 로 해도 에러 안남

설명)

1. 프로퍼티 접근이 가능한 이유 = Sendable

• nonisolated 컨텍스트에서 메인 액터 격리 프로퍼티에 접근하려면, 그 값이 실행자 경계를 안전하게 건널 수 있어야(Sendable) 하는데, SomeUIEffect2는 Sendable 이다. → deinit에서 effect2 접근 OK.

2. 메서드 호출이 가능한 이유 = @MainActor 아님
• stop()이 액터 격리(예: @MainActor)가 아니므로, hop(실행자 전환) 없이 동기 호출 가능 → OK.

요약:
• 프로퍼티 접근 측면: Sendable이라 안전.
• 메서드 호출 측면: @MainActor가 아니니 hop 불필요.

[2.3] 상황 3

현황)

swift5 에서는 워닝, swift 6 에서는 에러 발생

원인)

• SomeUI가 @MainActor라서 effect3 자체가 메인 액터에 격리돼 있어요.
• 그런데 deinit은 항상 nonisolated(아무 실행자에도 속하지 않음).

• nonisolated 컨텍스트에서 메인 액터 격리 프로퍼티에 접근하려면, 그 값이 실행자 경계를 안전하게 건널 수 있어야(Sendable) 하는데, SomeUIEffect3는 Sendable이 아니므로 프로퍼티를 읽는 순간 막힙니다.
→ "Cannot access property 'effect3' with a non-Sendable type ... from nonisolated deinit"

해결)

우선 1번과 같은 방식으로 해결할 수 없습니다.

deinit은 nonisolated이고, effect3는 @MainActor에 격리된 프로퍼티라서 그 접근 자체가 크로스-액터 접근이 되는데

non-sendable 이여서 크로스-액터 접근이 불가능하기 때문입니다.

풀어서 이해해보면 다음과 같습니다.

• deinit은 nonisolated라서 어떤 액터에도 속하지 않습니다.
• effect3는 @MainActor 격리된 저장 프로퍼티라 **액터 경계 밖(= nonisolated)**에서 접근하면 크로스-액터 접근이 됩니다.
• 이때 **값을 액터 경계 밖으로 “꺼내도 안전한지”**를 컴파일러가 따지는데, 그 안전성의 기준이 Sendable 입니다.
• SomeUIEffect3가 non-Sendable이므로 경계 밖으로 가져올 수 없어 접근 자체가 거부됩니다 → 에러.

따라서 요런 식으로 약간의 트릭을 써야합니다.

final class DeinitAction {

    let action: () -> Void

    init(_ action: @escaping () -> Void) {
        self.action = action
    }

    deinit {
        action()
    }
}

@MainActor
public final class SomeUI {

    let effect3 = SomeUIEffect3()
    private let onDeinit: DeinitAction

    init() {
        onDeinit = DeinitAction { [effect3] in
            effect3.stop()

            // 만약 stop이 메인에서 실행되어야한다면
            // Task { @MainActor in effect3.stop() }
        }
        effect3.start()
    }

    deinit { /* 비워둬도 됨. onDeinit이 해제되며 action 실행 */ }
}

[3] 정리

final class DeinitAction {

    let action: () -> Void

    init(_ action: @escaping () -> Void) {
        self.action = action
    }

    deinit {
        action()
    }
}

@MainActor
public final class SomeUI {

    let effect1 = SomeUIEffect1()
    let effect2 = SomeUIEffect2()
    let effect3 = SomeUIEffect3()

    private let onDeinit: DeinitAction

    init() {
        onDeinit = DeinitAction { [effect3] in
            effect3.stop()

            // 만약 stop이 메인에서 실행되어야한다면
            // Task { @MainActor in effect3.stop() }
        }

        effect1.start()
        effect2.start()
        effect3.start()
    }

    deinit {
        Task { @MainActor [effect1] in
            effect1.stop()
        }

        effect2.stop()
    }
}

@MainActor
final class SomeUIEffect1 {

    func start() {}
    func stop() {}
}

final class SomeUIEffect2: Sendable {

    func start() {}
    func stop() {}
}

final class SomeUIEffect3 {

    func start() {}
    func stop() {}
}

[iOS] Visual intelligence > pixelBuffer 활용하기

eungding — Mon, 25 Aug 2025 11:54:49 +0900

- 문서: Integrating your app with visual intelligence

- 예제 프로젝트 : Adopting App Intents to support system experiences

[1] 배경

카메라나 스크린샷을 통해 Visual Search 를 하면 아래의 메소드가 타게 되고

SemanticContentDescriptor 를 통해 이미지에 대한 정보를 얻어올 수 있다.

https://developer.apple.com/documentation/visualintelligence/semanticcontentdescriptor

SemanticContentDescriptor 는 labels, pixelBuffer 를 제공하는데 label 을 단독으로 쓸 수 없다.

굉장히 광범위한 label 정보를 주기 때문이다. (예를들어 스콘을 이미지 검색하면 bread 도 아니고 food 라는 label 을 준다.)

label 은 부가적인 정보일 뿐이고 visual intelligence 기능은 pixelBuffer 를 메인으로 사용해야하며

구글처럼 기존에 이미지 검색 기능을 제공하는 서비스가 타겟이라고 한다.

그럼 pixelBuffer 를 통한 이미지 검색을 제공하지 않는 곳은 정확한 label 정보를 얻기 위해

한단계를 더 거쳐야하는데, 어떤 방법이 있을 지 & 성능이 괜찮을 지 알아보자!

[2] 사전 지식 : CVReadOnlyPixelBuffer -> CVPixelBuffer 로 변환하기

CVReadOnlyPixelBuffer (iOS 26+) 를

기존에 쓰던 pixelBuffer 로 변환하려면 withUnsafeBuffer 를 사용하면 된다.

AI 는 자꾸 CVPixelBuffer 로 타입캐스팅 하라고 코드를 짜주는 데 타입캐스팅 실패한다.

이 메소드를 기억하자.

[3] PixelBuffer 로 Label 을 구하는 방법

1) Google MediaPipe의 Object Detector

- 모델을 선택해서 앱에 넣는 방식

ㄴ 테스트해보니 문서에 나온 것처럼 EfficientDet-Lite2 가 EfficientDet-Lite0 에 비해 속도는 느리지만 정확성이 높아서 이 모델로 선택!

- SPM 지원안해서 cocoapod 으로 의존성 설치해야함

2) Core ML + Vision

- 모델을 선택해서 앱에 넣는 방식

ㄴ 과거와 달리 mlmodel 이 아니라 mlpackage 인데 그냥 다운받아서 넣으면 된다.

- 예전에는 Core ML 모델이 보통 .mlmodel 하나의 파일로 배포됐습니다.
- 요즘(특히 Core ML Tools 4+ / iOS 14+)은 모델이 크거나 여러 파일이 필요할 때 **.mlpackage**라는 디렉토리 번들 형식으로 내보내기도 해요.
- Build하면 Xcode가 자동으로 .mlmodelc(컴파일된 Core ML 모델)로 바꿔서 번들 안에 포함시킵니다.
- .mlmodel이든 .mlpackage든 직접 번들에 넣으면 Xcode가 빌드 과정에서 mlmodelc로 변환합니다. 런타임에서는 항상 .mlmodelc를 불러오게 돼요.

ㄴ 테스트해보니 FastViT, DETRResnet50SemanticSegmentationF16 보다 YOLOv3 결과가 더 잘나와서 선택! (근데 FastViT, DETR 이 더 최신 모델이고 정확도가 높다고 한다... 흠)

3) Google Cloud Vision API

- API Request 하는 방식 (과금)

ㄴ 매월 1,000건까지는 무료

- 구글 콘솔 접속 -> 프로젝트 생성 -> Cloud Vision API 를 활성화 -> API 키 생성 하는 과정이 필요하다.

ㄴ API 키로 처음 요청하면 에러에 결제 계좌 등록 링크가 내려오는 데 이것까지 해줘야한다!

[4] 비교

1. SemanticContentDescriptor > labels (confidence 미제공)

2. GoogleObjectDetector with EfficientDet-Lite2 모델

3. CoreMLObjectDetector with YOLOv3 모델

4. GoogleVisionAPIObjectDetector

4가지를 비교해보자 (스샷 후, 물체를 특정해서 검색함)

GoogleVisionAPI 압승이다 압승...




	메론빵도 안다구 ??

[5] 결론

GoogleVisionAPI 를 사용하면 꽤 명확한 label 정보를 얻을 수 있다

(+ food, ingredient, table 관련 label 필터링 하고 쓰면)

(+ 사용자가 정확하게 물체를 선택해서 검색하면)

완벽하진 않지만, Visual Intelligence -> GoogleVisionAPI -> label 정보로 검색결과 제공할 수 있을 듯!

[Swift] Foundation Models

eungding — Fri, 13 Jun 2025 22:43:45 +0900

[1] Foundation Models

Foundation Models 는 온디바이스 LLM 을 제공하는 프레임워크입니다.

https://developer.apple.com/documentation/foundationmodels

Foundation Models | Apple Developer Documentation

Perform tasks with the on-device model that specializes in language understanding, structured output, and tool calling.

developer.apple.com

HIG 에 Generative AI 도 함께 추가되었는데 사용하면서 함께 읽어보면 좋을 것 같아요

[2] 사용법

LanguageModelSession 을 만들고 session 에 prompt 를 넘겨서 response 를 받습니다.

성능이 아쉽지만...... 무료니까...

Session 에는 다음과 같은 이니셜라이저가 제공되는데 문서에 필드 설명이 잘 나와있어요

init(model:guardrails:tools:instructions:)

ㄴ model 중 content tagging 유용해보임

또한 다양한 Request 함수를 제공하고 있습니다. (참고: Generating a request)

[2.1] Structured Ouput

Generable 매크로를 활용해서 LLM이 구조화된(Generable) 응답을 반환할 수 있게 합니다.

Guide 매크로는 필수는 아니지만 함께 활용하면 정확도를 높일 수 있습니다.

(MyTextEditor 는 앱 이름..)

Generable 은 struct 뿐만 아니라 enum 에도 붙일 수 있고 재귀도 가능해서 편하게 쓸 수 있을 것 같고

Guide 도 다양하게 쓸 수 있습니다. (Regex 도 되다니.. )

참고: Generating Swift data structures with guided generation

[2.2] 런타임 동적 스키마

위의 방식이 '컴파일 타임 스키마'라면 (컴파일 시점에 모델이 어떤 출력을 생성해야 할지 미리 알 수 있음)

런타임 동적 스키마를 사용하는 방법도 있습니다.

DynamicGenerationSchema 로 요청을 하고 GeneratedContent 타입을 받아서

value(_:forProperty:) 를 사용하는 방식입니다.

참고: 예제

[3] Tool Calling

Tool Calling 은 모델의 기능을 여러분의 사용 사례에 맞게 확장할 수 있는 수단을 제공합니다.

Tool Calling 을 통해 모델은 여러분이 만든 코드와 상호작용할 수 있으며,
이를 통해 다음과 같은 일을 할 수 있습니다

- 최신 정보를 가져오기 (ex. 외부 API 호출)
- 별도로 제공하는 신뢰가능한 데이터에 기반해서 응답 생성하기 (ex. Contacts 나 HealthKit 같은 다른 프레임워크와 연동, 앱의 데이터베이스에서 항목을 조회하고 이를 응답에 참조하도록 하기)

- 사이드 이펙트 실행하기 (ex. 다크모드 켜기)

[3.1] Tool Calling 사용법

Tool 프로토콜을 채택해서 Tool 을 만든 다음, Session 의 이니셜라이저에 넘기는 방식으로 사용합니다.

예제 1) 날씨 정보 요청

예제 2) 연락처(Contacts) 통합

온디바이스 모델의 강점을 잘 보여주는 예제

개인 정보가 서버로 업로드되지 않기 때문에 프라이버시를 보장하며 이런 기능을 통합할 수 있습니다.

툴이 처음 호출될 때, 사용자에게 접근 권한 요청이 표시된다고 합니다.

[3.2] Tool Calling 작동방식

작동방식은 다음과 같습니다.

- 세션 시작 시 Tool 과 Instruction 를 함께 등록

- 모델이 프롬프트를 분석해서 적절한 툴 판단
- Tool 과 Instruction 기반으로 Tool 에 전달될 Input Arguments 생성
- Tool 의 call() 메서드 호출 → 결과 반환 후 모델이 다음 응답 생성

ex) 캘린더 툴을 통합했을 때

Instruction 에 있는 날짜 정보랑 사용자가 세션에 입력한 프롬프트를 보고

'이벤트' 에 대해 묻는 질문인 것을 파악 후, 캘린더 툴을 호출하는 게 적합하다고 모델이 판단합니다.

Arguments 를 만들어서 캘린더 툴의 call 을 호출한 후, Ouput 을 참고해서 응답을 생성합니다.

주의사항이 있는데,

툴은 하나의 요청에 의해 여러번 호출될 수 있고 call 메서드는 병렬로 실행됩니다.

따라서 툴 내부에서 데이터를 접근하거나 처리할 때는 동시성(concurrency) 를 반드시 고려해야합니다.

참고: Expanding generation with tool calling

[4] Custom Adapter

특수한 사용 사례와 커스텀 데이터셋을 가진 머신러닝 전문가라면,
Apple의 어댑터 학습 툴킷(adapter training toolkit)을 사용해
맞춤형 어댑터를 직접 학습시킬 수도 있습니다.

하지만 유의할 점은,
Apple이 모델을 지속적으로 개선함에 따라
어댑터를 다시 학습시켜야 하는 책임이 따르기 때문에
상당한 관리 부담이 있다는 점입니다.

[5] 기타 유용한 기능

- streamResponse

streaming 기능을 제공합니다. 응답으로 async sequence 를 반환합니다.

이 시퀀스의 각 요소는 부분적으로 생성된 타입의 인스턴스이며,
각 요소는 갱신된 스냅샷(snapshot) 포함하고 있습니다.

스트림 응답을 순회하며 요소들을 저장하면,

UI가 실시간으로 생동감 있게 구성되는 것을 볼 수 있으며 지연(latency)를 감출 수 있습니다.

contentTransition 함께 쓰는 것 좋아보여서 캡쳐

- transcript

session 의 모든 프롬프트와 응답을 포함하고 있습니다.

session 은 stateful 하기 때문에 (상태를 유지) 모든 프롬프트와 응답은 transcript에 기록됩니다.

디버깅 및 UI 표시에 사용할 수 있으며 새로운 세션을 만들 때 transcript 를 넘겨 컨텍스트 유지를 할 수 있습니다.

session 이 최대 컨텍스트 사이즈를 초과했을 때, 새로운 session 을 시작해야하는데

transript 를 넘기면 이전 대화 히스토리를 기억하며 대화흐름을 이어갑니다.

init(model:guardrails:tools:transcript:)

히스토리를 전부 다 넘기는게 아니라 Summarizer 를 두고 transcript 를 요약해서 넘기는 게 좋습니다.

외부 라이브러리를 사용해서 할 수도 있고, Foundation Models 자체를 이용해 Transcript의 일부를 요약하는 것도 가능합니다. (위의 코드 스샷 참고)

[6] 모델 응답 생성 방식 세부 조정

GenerationOptions 을 통해 모델 세부 조정이 가능합니다. 세가지 필드를 세팅할 수 있습니다.

1) sampling : 출력 토큰을 선택하는 방식 설정

이를 통해 출력 결과의 무작위성(randomness) 을 제어가능한데,

아래에서 추가적으로 살펴보겠습니다.

2) temperature : 출력의 다양성 조정 (temperature 가 높을 수록 다른 결과를 생성)

3) maximumResponseTokens: 너무 긴 응답을 방지하기 위한 제한

[6.1] Sampling

모델이 출력을 생성할 때는 한 번에 하나의 토큰씩 생성합니다.
이 과정은 각 토큰에 대한 확률 분포(distribution)를 만든 후, 그 중 하나를 선택하는 방식으로 진행됩니다.

Foundation Models는 기본적으로 일정한 확률 범위 내에서 토큰을 선택합니다.
예를 들어, 첫 번째 토큰으로 어떤 경우엔 “Ah”를, 다른 경우엔 “Well”을 선택할 수 있습니다.
이러한 과정이 모든 토큰 생성마다 반복됩니다.

이러한 토큰 선택 행위를 “샘플링(sampling)“이라고 부르며,
기본 설정은 무작위(random) 샘플링입니다.

다양한 무작위성 출력이 필요한 경우 random 옵션을 기본적으로 사용해도 좋지만,

일관된 출력이 필요한 경우 결정적(deterministic) 출력이 필요합니다.

이를 위해 greedy 옵션을 제공합니다.

샘플링 방식을 greedy로 설정하면 같은 세션 상태에서 같은 프롬프트를 입력시 항상 같은 출력을 얻게 됩니다.
다만 이 보장은 같은 버전의 온디바이스 모델을 사용할 때만 유효합니다. (OS 업데이트로 모델이 바뀌면, 같은 프롬프트와 설정이어도 결과가 달라질 수 있습니다.)

[7] 유의사항

[7.1] Availability

1) Model Availability

Scheme > Option 에서 설정을 바꿔볼 수 있으며

다음과 같이 대응하기를 권장합니다.

2) Language Support

프롬프트에 사용자 입력을 포함할 때는 해당 언어가 지원되지 않을 수 있다는 점도 유의해야 합니다.

이 경우에는 unsupportedLanguageOrLocale라는 전용 오류가 발생하며,
이를 포착하여 처리할 수 있습니다.

이 오류를 활용하면 UI에서 사용자에게 맞춤 안내 메시지를 보여주는 데 유용할 수 있습니다.

또한, 특정 언어가 모델에서 지원되는지를 확인하는 API도 제공됩니다.
예를 들어, 사용자의 현재 언어가 지원되는지 확인하고,
지원되지 않는 경우 주의 문구(disclaimer) 를 표시할 수 있습니다.

[7.2] Guardrails

입력 (instructions, prompt, tool call input) 과 출력 (모델의 응답) 에 모두 작동하는 AI 안전장치 입니다.

Guardrails 은 디폴트 값 하나만 있고 개발자가 커스텀할 수 없는 것 같습니다.

가드레일이 작동하면 에러로 전달되는데

적절한 핸들링이 필요합니다.

[7.3] 온비다이스 모델에 대한 이해

대형 서버 기반 모델은 수백억~수천억 파라미터를 갖고 있고, 그만큼 복잡한 작업을 수행할 수 있지만, 온디바이스 모델은 몇 가지 한계가 있습니다:
- 복잡한 추론 과제는 여러 단계를 나눠 프롬프트로 설계해야 합니다.

- 계산기처럼 수학 계산을 맡기면 안 됩니다. 코드 생성 작업도 피하세요.

- 최신 정보에 대한 지식이 없기 때문에, 정확한 사실에 의존해서는 안 됩니다.

[8] 최적화

1) prewarm

session.respond를 호출하면, 운영체제는 해당 모델이 아직 메모리에 없다면 모델을 로드합니다.
하지만 프리워밍(Prewarming) 을 통해 요청을 보내기 전에 미리 모델을 로드해 세션을 더 빠르게 시작할 수 있습니다.

이 프리워밍은 앱이 비교적 유휴 상태일 때, 그리고 사용자가 세션을 사용할 조짐을 보일 때 수행하는 것이 가장 좋습니다.

예를 들어, 사용자가 프롬프트를 입력하게 될 텍스트 필드에 입력을 시작한 직후가 좋은 타이밍입니다.

예제 앱의 경우, 사용자가 랜드마크를 탭하면 곧 “여행 일정 생성” 버튼을 누를 가능성이 높기 때문에,
그 전에 미리 모델을 로딩할 수 있습니다.사용자가 설명을 다 읽고 버튼을 누를 즈음엔 모델이 이미 준비된 상태가 되어, 빠르게 응답할 수 있게 되는 것입니다.

2) includeSchemaInPrompt

respond(to:generating:includeSchemaInPrompt:options:isolation:) 를 사용하면
프레임워크는 해당 데이터 구조의 생성 스키마(generation schema) 를 자동으로 프롬프트에 삽입합니다.

하지만 이렇게 하면 토큰 수가 증가해, 지연 시간(latency)과 컨텍스트 크기(context size)도 함께 증가하게 됩니다.

그런데 만약 모델이 이미 응답 형식(response format) 을 충분히 이해하고 있는 상황이라면,

연속되는 request 에서는 includeSchemaInPrompt를 false로 설정해 스키마 삽입을 생략하고 성능을 개선할 수 있습니다.

사용가능한 경우는 다음과 같습니다.

첫 번째 경우는
• 동일한 유형의 요청을 여러 번 수행하는 멀티턴 대화에서입니다.
• 첫 번째 요청에서 이미 프롬프트에 스키마가 포함되었기 때문에, 이후 요청들에는 굳이 반복해서 포함할 필요가 없습니다.

두 번째 경우는
• instructions 안에 예시 응답을 포함시킨 경우입니다.
• 구조가 간단하고 옵셔널 속성이 없는 경우, instructions에 포함된 예시만으로 충분합니다. 만약 구조체에 옵셔널 속성(optional properties) 이 있다면, 예시를 줄 때는 해당 속성이 채워진 경우와 nil인 경우 둘 다 제공해야 합니다.

[9] 모델 피드백 하기

- 모델 latency 를 분석할 수 있는 instrument 가 제공됩니다.

- LanguageModelFeedbackAttachment 이라는 인코딩 가능한 피드백 첨부용 데이터 구조가 제공됩니다.

이 구조를 통해 파일형태로 Feedback Assistant 에 첨부할 수 있습니다.

[10] WWDC 영상

- WWDC 25 > Meet the Foundation Models framework

- WWDC 25 > Deep dive into the Foundation Models framework
- WWDC 25 > Explore prompt design & safety for on-device foundation models

- WWDC 25 > Code-along: Bring on-device AI to your app using the Foundation Models framework > 최적화 (prewarm, includeSchemaInPrompt) 관련 내용이 있음

[SwiftUI] TextEditor with AttributedString

eungding — Fri, 13 Jun 2025 19:40:37 +0900

[ TextEditor ]

TextEditor 는 iOS 14+ 인데, iOS 26 부터 쓸 수 있는 이니셜라이저가 추가되었다.

AttributedString 는 iOS 15+ 이고 Text 의 이니셜라이저에서 먼저 사용되고 있었는데 (iOS 15+)

이제 뷰어 뿐만아니라 에디터에서도 사용할 수 있게 된 것이다.

TextEditor 에 AttributedString 을 받는 이니셜라이저를 사용하면

String 을 받는 이니셜라이저와 달리 Format 이라는 메뉴가 뜨고

String

AttributedString

기본으로 제공되는 rich text editing 을 지원할 수 있다.

맥 OS 는 이렇게 나옴

대부분의 attribute, paragraph style 이 지원되는 듯 보인다.

다만 한국어는 아직 불안정한데 ;;;

스페이스바나 엔터치면 이렇게 됨 ;;;; ;;

[ Attributed String ]

NEW (iOS 26+)

(일부만 적음. 전체는 문서 참고)

텍스트 스타일

- AttributedString.TextAlignment

- AttributedString.LineHeight

텍스트 Selection

- AttributedTextSelection

Bidirectional text 를 지원한다고 함

텍스트 변경

- replaceSelection

- transform

[ TextEditor > Custom Control ]

TextEditor 에 Custom Control 을 연결할 수도 있음

Suggestion 해주는 Control 을 추가하는 코드

[ TextEditor > Custom Text Format ]

AttributedTextFormattingDefinition 를 채택해서 커스텀 텍스트 포맷을 미리 정의해두고

TextEditor 에 적용할 수도 있음

AttributedTextValueConstraint 사용해서 특정 attribute 의 value 를 원하는 대로 지정할 수도 있음

아래는 forgregoundColor attribute 에 대한 예제

[ 참고 ]

- WWDC 25 > Code-along: Cook up a rich text experience in SwiftUI with AttributedString

- Building rich SwiftUI text experiences

[Swift] Swift Testing 헷갈리는 것 정리

eungding — Wed, 29 Jan 2025 17:34:39 +0900

- WWDC 24 > Meet Swift Testing

- WWDC 24 > Go further with Swift Testing

- 소개 | 개발 문서

[1] 언제 @Suite 를 직접 붙여야하는가 ?

문서:

A type containing test functions is automatically a test suite and can be optionally annotated with the @Suite attribute.

WWDC 와 문서에서 말하는 것 처럼,

테스트 함수를 포함하는 타입은 자동으로 테스트 스위트가 되기 때문에

@Suite 를 직접 붙일 필요가 없다.

즉 두개는 똑같기 때문에 굳이 @Suite 를 안붙여줘도 됨.

그럼 @Suite 를 언제 붙이면 좋을까 ?

displayName 을 별도로 지정해주고 싶을 때, traits 지정이 필요할 때 사용하면 됨.

예를들어

[ 참고 ]

SuiteTrait 과 TestTrait 은 모두 Trait 을 상속하고 있기 때문에

trait 종류가 거의 동일함.

[2] 모든 trait 은 nested test suite 에도 같이 적용되는가 ?

기본적으로 suite 에 적용한 trait 은 해당 suite 가 포함하는 test 함수 및 nested suite 에 다 적용됨

(가장 쉬운 예로 tag trait 을 생각해보면 됨)

모든 trait 이 상속된다고 어디에 시원하게 나와있지 않지만, 그런 것 같음!

가장 의심이 되는 두가지인 serialized, timeLimit trait 을 아래에서 살펴보자.

우선 serialized trait 은 상속된다고 WWDC 에서 언급됨.

Running tests serially or in parallel 문서에도 다음과 같이 나와있음.

This trait is recursively applied: if it is applied to a suite, any parameterized tests or test suites contained in that suite are also serialized (as are any tests contained in those suites, and so on.)

timeLimit trait 도 테스트해보니 잘 상속되고

Limiting the running time of tests 문서 에도 다음과 같이 나와있음.

When a time limit is applied to a test suite, it’s recursively applied to all test functions and child test suites within that suite.

그리고 여러 timeLimit trait 이 적용될 때, 가장 짧은 시간의 trait 이 사용된다고 함.

⭐️ If multiple time limit traits apply to a test, the shortest time limit is used.

테스트 해보니 정말 가장 가까운 trait 이 아니라 가장 짧은 시간의 trait 이 적용되는 모습 을 확인할 수 있었음.

+ enable, disable 도 함께 확인차 테스트 해봤는데, 예상대로 disabled 가 enabled 보다 더 우선순위로 먹힘.

☑️ 정리

-> 모든 trait 은 재귀적으로 test function, nested suite 에 적용된다고 생각하면 될 듯.

-> 하지만 헷갈리면 안되는 게 serialized 는 살짝 성격이 다름. timeLimit 처럼 각 test function 마다 개별적으로 timeLimit 이 걸리는 게 아니라 suite 단위 임. suite 내의 test 들이 serial 하게 실행되는 것이니까.

문서의 예제코드 + 주석을 읽어보면 바로 이해가능.

@Suite(.serialized) struct FoodTruckTests {
  @Test(arguments: Condiment.allCases) func refill(condiment: Condiment) {
    // This function will be invoked serially, once per condiment, because the
    // containing suite has the .serialized trait.
  }


  @Test func startEngine() async throws {
    // This function will not run while refill(condiment:) is running. One test
    // must end before the other will start.
  }
}

[3] Swift Testing 과 XCTest 가 같이 있을 때, 테스트 옵션 지정한 건 둘다 적용 되는 건가 ?

Swift Testing 은 디폴트가 병렬 실행이고 순차 실행을 원하면 serialized trait 을 붙여준다.

반면 XCTest 는 디폴트가 순차 실행이고 병렬로 실행하기 위해 scheme 에서 테스트 옵션을 바꿔줬다.

Xcode 몇버전 부터 바뀐 건지 기억이 안나는데, Test Plan 전에는 이렇게 세팅해줬고

지금 (Xcode16) 은 이 동선으로 들어가서 TestPlan > Options 로 설정한다.

병렬 옵션에 이렇게 3개가 제공된다.

- Disabled : Swift Testing, XCTest 모두 병렬 X

- Swift Testing Only : Swift Testing 병렬 O, XCTest 병렬 X

- Enabled (If Possible) : Swift Testing, XCTest 모두 병렬 O

Enabled 에 If Possible 이 있는 경우는

XCTest 는 MacOS 랑 simulator 에서만 병렬 실행이 가능하기 때문인 듯.

Enabled (If Possible) 이 디폴트 값이니까 이제는 XCTest 도 디폴트가 병렬임!

참고로

XCTestCase 별로 병렬 옵션을 ON/OFF 할 수 있는 프로퍼티가 혹시 추가되었나 문서를 봤는데 없는 듯 함!

개별 지정은 Swift Testing 만..

[4] XCTest 를 Swift Testing 으로 완전히 Migration 할 수 있는가 ?

대부분은 그렇다.

마이그레이션 문서: Migrating a test from XCTest

문서에 너무 잘 나와있음.

문서에서 주의깊게 볼 것은 XCTFail 이 record 랑 대응된다는 점. (XCTFail 같은 거 없는 줄 알았음 ;;;)

그리고 expectation fullfill -> confirmation 도!

하지만 계속 XCTest 를 써야하는 케이스도 있다.

Continue to use XCTest for User Interface Tests and Performance Tests.

[5] DisplayName 은 언제 쓰면 좋을까 ?

Suite 나 Test 이름을 명확하게 지정해주면 DisplayName 은 필요없어보이는데

언제 쓰면 좋을까 ?

WWDC 에서는 가독성을 위해 띄어쓰기 하는 용도로 dislayname 을 사용했다.

이것도 좋고 parameterized test 에서 파라미터들이 많아서

테스트가 길어질 때 테스트 네임을 짧게 하고 displayName 을 길게 하는 식으로 사용해도 좋을 것 같다.

[6] Tag 를 중첩시키면 어떻게 표시되나 ?

[ 테스트 > 태그 ]

tag 별로 해당하는 테스트함수가 모두 나옴

상위 Tag 로 검색해도 하위 테스트 함수까지 잘 나옴

[ 테스트 리포트 ]

태그 다 붙어서 나옴

검색에 상위 Tag 를 제외해도 하위 테스트 (다른 태그를 달고 있는 테스트) 는 나옴.

[ 테스트 플랜 ]

상위 Tag 를 Exclude 하면 하위 테스트까지 다 exclude 됨.

[iOS] NSCollectionLayoutSupplementaryItem 헷갈리는 것 정리

eungding — Wed, 11 Dec 2024 21:24:18 +0900

[1] NSCollectionLayoutBoundarySupplementaryItem > absoluteOffset

대놓고 이름이 offset 인데, inset 처럼 동작안해서 이상하다고 생각하고 있었다 ;;;;;

위 그림에서 item (파란색) bottom 으로 부터 안쪽 100에 footer (초록색) 이 위치해야하는데, 이상하다 ? 고 생각함 ;;;;;

왜그랬을까 생각해보면... 스유에서 alignment 에 값 주던 형태랑 비슷하니까 안쪽으로 들어간다고 생각했지 않을까 ?

갑자기 떠오르는 SwiftUI 초창기 시절에 들었던 발표,,,

https://tv.kakao.com/channel/3693125/cliplink/414129341

아무리 사고방식이 바뀌었다고 해도 이름이 offset 이다.. 정신차려라.

그리고 주석에도 그림이 적혀있음!

내가 헷갈렸던 footer 2개 들어가는 경우도 전혀 이상하지 않음!

[2] NSCollectionLayoutItem > fractionalOffset

헷갈리면 안되는게 offset 이지만 edges 에서 출발이다 (?)

파리미터 보고 생각하면 되는데,

edges 에 맞게 배치시키고 그 다음에 offset 을 준다고 생각하면 됨.

bottom, leading edges 에 먼저 위치한 다음에 badge 넓이의 반만큼 offset x, y 이동.

이것도 주석에 그림이 잘 적혀있음!

✨ Special Thanks To 동료분들

[Swift] 매크로 (Macro)

eungding — Sat, 7 Dec 2024 23:35:03 +0900

- 문서

- 문서 ⭐️

- WWDC 23 > Write Swift macros

Assisted by GPT

[1] 매크로 템플릿 만들기

Xcode > New > Pacakge > Swift Macro 선택해서 매크로 템플릿을 만들 수 있음.

커맨드라인으로도 가능한데, 아래 명령어를 실행시키면 됨.

swift package init --type macro

만들어보면 기본적으로

ㄴ dependency 로 swift-syntax 가 걸려있음.
ㄴ WWDC 에서 소개하는 stringify 매크로의 선언, 구현, 예제, 테스트 코드 들어가 있음.

[2] 매크로 유형

일단 크게 두가지

1️⃣ Freestanding Macros
• 코드 블록 외부에서 동작.
• 예: 디버깅 정보를 자동으로 추가.
• 사용 예:

#debugLog("Message")

2️⃣ Attached Macros
• 클래스, 구조체, 열거형 등에 속성처럼 부착되어 동작.
• 예: @Codable 매크로로 Codable 구현 자동 생성.
• 사용 예:

@Codable
struct User {
    let name: String
    let age: Int
}

그리고 세부적으로는 freestanding 2개, attached 5개.

위 유형들은 프로토콜과도 매핑됨.

Macro 프로토콜이 있고

이걸 채택하는 FreestandingMacro, AttachedMacro 프로토콜이 있고

Freestanding 의 하위 유형들 (CodeItem 이 하나 더 추가되었나봄)

AttachedMacro 의 하위 유형들 이 있음 (여기도 더 추가되었네..)

[3] Freestanding 매크로 만들어보기

1) ExpressionMacro

이건 기본템플릿에 구현된 예제로 퉁.

# 선언

# 구현

# 사용

let result = #stringify(1 + 2)

2) DeclarationMacro

repeat 함수를 매크로를 통해 선언하는 예제를 작성. (조금 안와닿을 수 있는 예제이지만, 파라미터 두개를 받아보기 위해..)

# 선언

@freestanding(declaration, names: named(printRepeat))
public macro printRepeatFunction(_ value: String, _ count: Int) = #externalMacro(module: "MyMacroMacros", type: "PrintRepeatFunctionMacro")

# 구현

public struct PrintRepeatFunctionMacro: DeclarationMacro {

    public static func expansion(
        of node: some FreestandingMacroExpansionSyntax,
        in context: some MacroExpansionContext
    ) -> [DeclSyntax] {
        guard let value = node.arguments.first?.expression else {
            fatalError("The macro requires a value")
        }

        guard let repeatCount = node.arguments.last?.expression else {
            fatalError("The macro requires a repeat count")
        }

        return [
          """
            func printRepeat() {
                for _ in 0..<\(repeatCount) {
                    print(\(value))
                }
            }
            """
        ]
    }
}

# 사용

struct SomeStruct {
    #printRepeatFunction("HELLO", 3)
}

SomeStruct().printRepeat()

참고로

객체 안에서 매크로로 선언한 function 은 호출가능이지만,

전역 스코프에서 호출하면 에러 발생 (in 템플릿이 제공하는 main 파일)

3) CodeItemMacro (experimental feature)

아직 실험기능이라 써볼 수는 없었음 (swift-syntax 패키지 버전 바꾸면 가능할지도..)

DeclarationMacro 는 class, function 등이 아니라 코드 블럭을 선언하면 에러가 발생하는데,

CodeItemMacro 는 코드블럭을 선언할 수 있는 매크로.

public struct RepeatMacro: CodeItemMacro {

    public static func expansion(
        of node: some FreestandingMacroExpansionSyntax,
        in context: some MacroExpansionContext
    ) -> [CodeBlockItemSyntax] {
        guard let value = node.arguments.first?.expression else {
            fatalError("The macro requires a value")
        }

        guard let repeatCount = node.arguments.last?.expression else {
            fatalError("The macro requires a repeat count")
        }

        return [
          """
            {
               for _ in 0..<\(repeatCount) {
                    print(\(value))
                }
            }
            """
        ]
    }
}

[4] Attached 매크로 만들어보기

1) PeerMacro

PeerMacro 는 적용된 선언과 동등한 수준(peer level)에 새로운 선언을 추가할 때 사용됩니다.
예를 들어, 클래스나 구조체에 @attached(peer) 매크로를 적용하면, 매크로는 해당 클래스나 구조체의 외부에 새로운 선언을 생성합니다.

# 선언

@attached(peer, names: prefixed(Mock))
public macro Mock() = #externalMacro(module: "MyMacroMacros", type: "MockMacro")

[ names ]

• arbitrary는 이름을 고정하지 않겠다는 선언입니다. (매크로 실행 시 동적으로 결정됩니다)
• 이 경우 매크로가 생성한 선언의 이름은 사용자가 명시적으로 지정하지 않는 한, 컴파일러에 의해 기본 이름 또는 충돌 방지 이름으로 설정될 수 있습니다.
• 사용자로부터 이름을 전달받아 동적으로 생성하는 경우 예시: @Mock(name: "CustomMockUserService")

• prefixed(Mock): 생성된 선언의 이름이 Mock 접두사를 포함해야 합니다.

• 예를 들어, 매크로가 UserService에서 호출되면 MockUserService라는 이름으로 확장됩니다.

# 구현

public struct MockMacro: PeerMacro {

    public static func expansion(
        of node: AttributeSyntax,
        providingPeersOf declaration: some DeclSyntaxProtocol,
        in context: some MacroExpansionContext
    ) throws -> [DeclSyntax] {
        // Ensure the macro is applied to a protocol
        guard let protocolDecl = declaration.as(ProtocolDeclSyntax.self) else {
            fatalError("The macro must be applied to a protocol")
        }

        let protocolName = protocolDecl.name.text
        let mockName = "Mock\(protocolName)"

        // 프로퍼티 및 주석에서 기본값 추출
        let members = protocolDecl.memberBlock.members.compactMap { member -> String? in
            if let variable = member.decl.as(VariableDeclSyntax.self) {
                let name = variable.bindings.first?.pattern.description ?? ""
                let type = variable.bindings.first?.typeAnnotation?.type.description ?? "Any"
                let comment = member.leadingTrivia.compactMap { trivia -> String? in
                    if case .lineComment(let text) = trivia {
                        return text.trimmingCharacters(in: .whitespacesAndNewlines)
                    }
                    return nil
                }.first
                let defaultValue = comment?.replacingOccurrences(of: "//", with: "").trimmingCharacters(in: .whitespacesAndNewlines) ?? defaultForType(type)

                return "var \(name): \(type) = \(defaultValue)"
            } else if let function = member.decl.as(FunctionDeclSyntax.self) {
                let name = function.name.text
                let params = function.signature.parameterClause.description
                let returnType = function.signature.returnClause?.type.description ?? "Void"
                return """
                func \(name)\(params) -> \(returnType) {
                    fatalError("Mock implementation for \(name) not provided")
                }
                """
            }
            return nil
        }

        // Mock 클래스 생성
        let mockClass = """
        class \(mockName): \(protocolName) {
            \(members.joined(separator: "\n"))
        }
        """

        // Parse the mock class as DeclSyntax
        return [
            DeclSyntax(stringLiteral: mockClass)
        ]
    }

    /// 기본 타입에 따른 기본값 반환
    private static func defaultForType(_ type: String) -> String {
        switch type {
        case "String": return "\"\""
        case "Int", "Float", "Double": return "0"
        case "Bool": return "false"
        case _ where type.hasSuffix("?"): return "nil" // Optional 타입
        default: return "fatalError(\"No default value for type: \(type)\")"
        }
    }
}

# 사용

@Mock
protocol UserService {
    // "Default Name"
    var name: String { get set }

    // 25
    var age: Int { get set }

    // true
    var isActive: Bool { get set }

    func fetchUser(id: Int) -> String
}

# Expand Macro

2) AccessorMacro

위의 peer 랑 같이 쓰는 예제.

# 선언

@attached(peer, names: arbitrary)
@attached(accessor)
public macro Logged() = #externalMacro(module: "MyMacroMacros", type: "LoggedMacro")

# 구현

public struct LoggedMacro: AccessorMacro, PeerMacro {

    // PeerMacro: 내부 저장 프로퍼티 생성
    public static func expansion(
        of node: AttributeSyntax,
        providingPeersOf declaration: some DeclSyntaxProtocol,
        in context: some MacroExpansionContext
    ) throws -> [DeclSyntax] {
        // 매크로가 변수에 적용되었는지 확인
        guard let variableDecl = declaration.as(VariableDeclSyntax.self) else {
            fatalError("이 매크로는 변수에만 적용할 수 있습니다.")
        }

        // 프로퍼티 이름과 타입 추출
        guard let variableName = variableDecl.bindings.first?.pattern.description else {
            fatalError("변수 이름을 확인할 수 없습니다.")
        }
        guard let type = variableDecl.bindings.first?.typeAnnotation?.type.description else {
            fatalError("변수 타입을 확인할 수 없습니다.")
        }

        // 내부 저장 프로퍼티 생성
        let internalPropertyCode = """
        private var _\(variableName): \(type) = \(variableDecl.bindings.first?.initializer?.value.description ?? "\(type)()")
        """

        // 문자열을 DeclSyntax로 변환
        return [DeclSyntax(stringLiteral: internalPropertyCode)]
    }

    // AccessorMacro: Getter, Setter 추가
    public static func expansion(
        of node: AttributeSyntax,
        providingAccessorsOf declaration: some DeclSyntaxProtocol,
        in context: some MacroExpansionContext
    ) -> [AccessorDeclSyntax] {
        guard let variableDecl = declaration.as(VariableDeclSyntax.self) else {
            fatalError("이 매크로는 변수에만 적용할 수 있습니다.")
        }
        guard let variableName = variableDecl.bindings.first?.pattern.description else {
            fatalError("변수 이름을 확인할 수 없습니다.")
        }

        let getter = """
        get {
            _\(variableName)
        }
        """
        let setter = """
        set {
            let oldValue = _name
            print("Setting \(variableName) from \\(oldValue) to \\(newValue)")
            _\(variableName) = newValue
        }
        """

        return [
            AccessorDeclSyntax(stringLiteral: getter),
            AccessorDeclSyntax(stringLiteral: setter)
        ]
    }
}

# 사용

struct User {
    @Logged
    var name: String
}

var user = User()
user.name = "Bob"   // Setting name from  to Bob
user.name = "Alice" // Setting name from Bob to Alice

# Expand Macro

[Swift] @isolated(any)

eungding — Fri, 15 Nov 2024 21:51:03 +0900

✓ SE-0431 @isolated(any) Function Types

Assisted by GPT

[1] @isolated(any)

@isolated(any) 은 swift 6 에 추가된 attribute 입니다. (function only)

임의의 (하지만 정적으로 알 수 없는) 격리를 가진 함수를 표현할 수 있습니다.

Task 에도 반영됨!

[2] @isolated(any) 도입 배경

Task 이니셜라이저는 () async throws -> () 타입의 불투명 값 (opaque value) 을 받습니다. 그러나 이 값에서 격리를 동적으로 복구할 수 없기 때문에, 이니셜라이저는 해당 작업을 global concurrent executor 에서 시작할 수밖에 없습니다. 만약 이니셜라이저에 전달된 함수가 실제로 특정 액터에 격리되어 있다면, 해당 함수는 진입 시 즉시 그 액터로 전환해야 합니다. 이 과정은 추가적인 동기화를 요구하며, 작업을 다시 일시 중단해야 할 수도 있습니다.

더 중요한 점은, 작업이 실제로 액터에 대기열로 추가되는 순서가 작업이 생성된 순서와 반드시 일치하지 않는다는 것입니다. 이니셜라이저가 처음부터 올바른 executor 에 작업을 바로 추가할 수 있다면, 의미적으로나 성능적으로 훨씬 더 나을 것입니다.

이 문제를 해결하기 위한 간단한 방법은 임의의 (하지만 정적으로 알 수 없는) 격리를 가진 함수를 표현할 수 있는 타입을 추가하는 것입니다.

표준 라이브러리의 모든 task-creation API는 @isolated(any) function 을 받아들이도록 업데이트 되었으며, 새 작업 (task) 를 적절한 executor 에 동기적으로 추가하게 됩니다.

[3] @isolated(any) 사용하기

함수가 임의의 컨텍스트에서 호출될 때, 항상 isolation boundary 를 넘는다고 가정해야 합니다.

그래서 비동기적으로 해당 함수를 호출해야 합니다.

func doSomething(_ operation: @isolated(any) () -> Void) async {
    await operation()
}

[4] isolation property

@isolated(any) 함수 타입의 값은 isolation 이라는 특별한 프로퍼티를 가집니다.

이 프로퍼티는 read-only 전용이며, 타입은 (any Actor)? 입니다.

이 값은 함수 값의 동적 격리 (dynamic isolation) 에 의해 결정됩니다.

func doSomething(_ operation: @isolated(any) () -> Void) async {
    let isolation = operation.isolation
    print(isolation) // ex. Optional(Swift.MainActor)
 }

- 만약 함수가 동적으로 비격리(non-isolated) 상태라면, 격리 값은 nil입니다.
- 만약 함수가 동적으로 글로벌 액터 타입 G에 격리되어 있다면, 격리 값은 G.shared입니다.
- 만약 함수가 동적으로 특정 액터 참조에 격리되어 있다면, 격리 값은 해당 actor reference 입니다.

import Foundation

func doSomething(_ operation: @Sendable @escaping @isolated(any) () -> Void) {
    print(operation.isolation)
    
    Task {
        print(operation.isolation)
        await operation()
    }
}

doSomething {
    // 출력 nil
}

doSomething { @MainActor in
    // 출력 Optional(Swift.MainActor)
}

doSomething { @MyGlobalActor in
    // 출력 Optional(__lldb_expr_631.MyGlobalActor)
}
    
@globalActor
actor MyGlobalActor {
    static let shared = MyGlobalActor()
}

[5] 추후 계획

@isolated(any) 함수 값의 격리는 정적으로 알 수 없기 때문에, 일반적으로 그 함수에 대한 호출은 격리 경계를 넘습니다. 이는 호출이 비동기적으로 처리되어야 한다는 것을 의미하며, 함수가 동기적이라 하더라도 await가 필요하고, 인수와 결과는 격리 경계를 넘는 호출에 대한 일반적인 송수신 가능성(sendability) 제약을 충족해야 합니다.

@isolated(any) 함수에 대한 호출이 격리 경계를 넘지 않도록 처리되려면, 호출자는 함수와 동일한 격리를 가져야 한다고 알려져야 합니다. @isolated(any) 매개변수의 격리는 반드시 불투명 값(opaque value)이기 때문에, 호출자가 함수와 동일한 격리 상태를 가져야 하는데, 이는 호출자가 값별 격리(value-specific isolation)로 선언되어야 함을 의미합니다. 현재로서는 로컬 함수나 클로저가 현재 컨텍스트의 격리 외에 특정 값에 격리될 수 있는 방법은 없습니다.

다음 규칙들은 @isolated(any)가 향후 언어 지원과 어떻게 상호작용할지에 대해 설명합니다. 이 규칙들을 제시하기 위해, 이 제안서는 클로저 격리 제어 구상에서 제안된 구문을 사용합니다. 이 구문에서 캡처 목록의 항목에 isolated를 추가하면 클로저가 그 값에 격리되도록 합니다.

func delay(operation: @isolated(any) () -> ()) {
  let isolation = operation.isolation
  Task { [isolated isolation] in // <-- tentative syntax from the isolated captures pitch
    print("waking")
    operation() // <-- does not cross an isolation barrier and so is synchronous
    print("finished")
  }
}

[참고]

위 proposal 의 Motivation 쪽에 나오는 내용인데, 같이 읽으면 더 개념이 잡힘.

# 함수의 3가지 격리 (isolation) 유형

Swift에서 함수 선언과 클로저는 세 가지 형태의 actor 격리를 지원합니다.

1) 비격리(non-isolated)
함수나 클로저가 특정 actor에 격리되지 않고, 동시성 제약 없이 동작하는 경우를 의미합니다.

2) 글로벌 actor 격리
함수나 클로저가 특정 글로벌 actor(예: @MainActor)에 격리되어 해당 actor의 컨텍스트 내에서만 실행되도록 제한됩니다.

3) 특정 매개변수(parameter) 또는 캡처된 값(captured value)에 격리
함수나 클로저가 전달받은 특정 매개변수 또는 클로저가 캡처한 값(예: self)에 대해 격리되어, 해당 값과의 상호작용이 안전하게 이루어지는 경우를 의미합니다.

3번은 이런 예제를 말함.

함수는 명시적으로 특정 매개변수를 isolated로 선언하여 그 매개변수에 스스로를 격리시킬 수 있습니다. 이런 격리는 actor 메서드에서 self 매개변수에도 암묵적으로 적용됩니다 (다른 격리를 명시적으로 사용하지 않은 경우).

# 한계

function 이 직접 호출 될 때 (called directly) , Swift 의 isolation checker 는 해당 함수의 isolation 을 정확히 분석하고 호출 컨텍스트의 격리와 비교할 수 있습니다. 그러나 호출 표현식이 함수 타입의 불투명 값(opaque value)을 호출하는 경우, Swift는 타입 시스템에서 표현할 수 있는 한계에 제약을 받습니다.

타입시스템으로 표현 가능

- A function type with no isolation specifiers, such as () -> Int, represents a non-isolated function.
- A function type with a global actor attribute, such as @MainActor () -> Int, represents a function that's isolated to that global actor.
- A function type with an isolated parameter, such as (isolated MyActor) - > Int, represents a function that's isolated to that parameter.

타입시스템으로 표현 할 수 없음

- 클로저가 캡처한 값 중 하나에 대해 격리될 수 있다는 것

아래 예제에서 클로저는 캡처한 self 값에 대해 격리됩니다.

actor WorldModelObject {

  ...
  
  func updateLater() {
    Task {
      // This closure doesn't have an explicit isolation
      // specification, and it's being passed to the `Task`
      // initializer, so it will be inferred to have the same
      // isolation as its enclosing context.  The enclosing
      // context is isolated to its `self` parameter, which this
      // closure captures, so this closure will also be isolated
      // that value.
      
      // 이 클로저는 명시적인 격리 지정이 없습니다.
      // 그리고 이 클로저는 `Task`에  전달되고 있으므로,
      // 자신을 둘러싼 컨텍스트와 동일한 격리를 갖는 것으로 추론됩니다.
      // 둘러싼 컨텍스트는 `self` 매개변수에 격리되어 있으며,
      // 이 클로저가 이를 캡처하고 있으므로, 이 클로저 역시
      // 해당 값에 격리됩니다.
      self.update()
    }
  }
}

upcoming closure isolation control proposal 에서는 이 개념이 훨씬 더 중요해질 것으로 예상됩니다.

이 제안에 따르면, 격리된 캡처는 특정 코드 조각의 격리를 제어하는 강력한 일반 도구가 될 것입니다. 하지만 여전히 해당 클로저의 격리를 타입 시스템으로 표현할 방법은 제공되지 않을 것입니다.

[ 추천 ]

- 노션 (위의 proposal 을 쉽게 번역+정리 해주신 링크 발견 ✨)

[Swift] @unchecked, @preconcurrency, @retroactive

eungding — Wed, 6 Nov 2024 01:04:55 +0900

- [Swift] Sendable 을 먼저 읽고 오시길 추천드립니다.

- Swift 6 기반의 글입니다.

[1] @unchecked

GPT 의 설명

Swift에서는 Sendable이라는 프로토콜을 통해 값이 스레드 간 안전하게 공유될 수 있는지를 나타내는데, 기본적으로 Sendable 프로토콜을 구현한 타입은 스레드 안전해야 합니다. 하지만, @unchecked를 사용하면 이 안전성 검사를 생략하고 강제로 Sendable을 준수하는 것으로 표시할 수 있습니다.

예를 들어, @unchecked Sendable을 사용하면 Swift 컴파일러는 이 타입을 Sendable로 인식하지만, 실제로는 스레드 안전하지 않을 수 있음을 경고 없이 허용합니다.

struct SomeType: @unchecked Sendable {
    // 스레드 안전하지 않은 코드가 포함될 수 있음
}

이 속성은 타입이 Sendable 프로토콜을 준수해야 하는 상황에서만 사용됩니다.

강제로 스레드 안전성을 우회하려는 경우에 사용하며, 이로 인해 발생할 수 있는 경쟁 상태나 안전성 문제는 개발자가 책임져야 합니다.

공식 문서

# Sendable

To declare conformance to Sendable without any compiler enforcement, write @unchecked Sendable. You are responsible for the correctness of unchecked sendable types, for example, by protecting all access to its state with a lock or a queue

궁금

Q. enum, struct, class 말고 function이나 closure 에도 적용할 수 있나 ? -> 안된다.

Q. protocol 은 ? -> 안된다

대신 이런 식으로는 에러 해결할 수 있다. (좋은 방법 X)

Q. 암묵적으로 Sendable 을 conform 하고 있는 actor 에도 쓸 수 있나 ? -> 일단 컴파일 에러는 안난다. 근데 이렇게 쓸 일 없으니 안 궁금해도 된다.

[2] @preconcurrency

GPT 의 설명

@preconcurrency는 기존 비동기 코드가 도입된 코드가 새로운 concurrency 시스템과 호환되도록 강제하는 데 사용됩니다. 이 속성은 특히 이전 버전의 코드에서 Sendable이나 다른 concurrency 관련 검사를 피하기 위해 사용되며, 기존 코드가 새로운 concurrency 시스템을 알지 못하고 작성되었음을 나타냅니다.

예를 들어, @preconcurrency는 concurrency 시스템이 없던 Swift 5.5 이전에 작성된 코드에서 사용할 수 있으며, 해당 코드가 concurrency 관련 새로운 규칙을 준수하지 않아도 되도록 허용합니다.

@preconcurrency protocol OldProtocol {
    // concurrency가 없던 시점의 프로토콜 정의
}

공식 문서

# swift-6-concurrency-migration-guide

You can stage in diagnostics caused by adding global actor isolation on a protocol using @preconcurrency. This will preserve source compatibility with clients that have not yet begun adopting concurrency.

@preconcurrency @MainActor
protocol Styler {
    func applyStyle()
}

# SE-0337 Incremental migration to concurrency checking

When applied to a nominal declaration, the @preconcurrency attribute indicates that a declaration existed before the module it belongs to fully adopted concurrency, so the compiler should take steps to avoid these source and ABI breaks. It can be applied to any enum, enum case, struct, class, actor, protocol, var, let, subscript, init or func declaration.

단순히 modern concurrency 준비 안된 외부 모듈 import 할 때만 쓰는 거라고 알고 있었는데,

import 문 외에도 쓸 수 있다는 것을 최근 알았다 ;;;; actor 에도 붙일 수 있다니...

예제 (내부 모듈에서 쓰는)

SomeStruct 를 Sendable 로 만들고 싶지만, 내부 필드가 Sendable 준비가 안된 상태 일 때

@preconcurrency 를 붙여 에러를 워닝으로 전환가능

만약 @unchecked 쓰면 워닝도 안나오게 할 수 있음

이런 혼합도 문법적으로는 가능하고

@preconcurrency 를 뒤로 보내면 워닝을 볼 수 있다.

actor 에 @preconcurrency 붙였을 때도, 위와 동일한 워닝이 발생해야할 것 같아서 테스트해보니

@preconcurrency 위치에 따라 워닝 여부가 다르다 ;;

@unchecked vs @preconcurrency (GPT)

- @unchecked는 타입이 스레드 안전성을 검사하지 않고 Sendable을 준수한다고 선언할 때 사용합니다.

- @preconcurrency는 concurrency 이전에 작성된 코드와 호환성을 유지하면서 concurrency 검사를 피하고자 할 때 사용합니다.

두 속성 모두 concurrency와 관련이 있지만, @unchecked는 주로 스레드 안전성 검사 생략에, @preconcurrency는 기존 코드와의 호환성 유지에 사용된다는 점에서 차이가 있습니다.

헷갈리면 안되는게 '호환'이라고 해서 문제 없이 동작한다는 게 아니라 컴파일 에러가 안생긴다는 것이다.

예를들어 아래 예제에서 CaffeineThresholdDelegate 앞에 @preconcurrency 를 붙여서

'이 메소드도 메인액터에서 격리된다' 고 가정했는데 아니라면 문제가 발생한다.

https://developer.apple.com/videos/play/wwdc2024/10169

[3] @retroactive

공식문서

# Retroactive Sendable Conformance (swift 6 migration guide)

Your dependencies may also expose types that are using manual synchronization. This is usually visible only via documentation. It is possible to add an @unchecked Sendable conformance in this case as well.

extension ColorComponents: @retroactive @unchecked Sendable {
}

# SE-0364 Warning for Retroactive Conformances of External Types

외부 모듈에서 가져온 타입을 extension 해서 쓰는 경우가 있다.

// Not a great implementation, but I suppose it could be useful.
extension Date: Identifiable {
    public var id: TimeInterval { timeIntervalSince1970 }
}

이는 여러 사이드이펙 가능성을 안고 있다. 예를들어 Foundation 이 나중에 id 를 제공하면 빌드가 실패할 것, Foundation 에서 제공하는 id (다른 구현)을 선택했는데, 이미 DB 에 저장된 ID 가 있다면 ID 는 다른 값이 되는 등.. (특히 라이브러리라면 라이브러리 쓰는 모든 클라이언트에 전파될 것이므로 더 치명적)

따라서 이 패턴을 문제로 보고 명시적으로 경고로 표시하는 게 좋다.

부득이한 경우, 클라이언트는 @retroactive attribute 를 프로토콜에 추가하여 이 경고를 무시할 수 있다.

궁금

Q. 내부 모듈 extension 에 쓰면 에러나 워닝 발생하는가 ? -> 에러 발생