감자주먹밥

HealthKit 수영 데이터 Fetch 해오기

JustHm — Thu, 23 Oct 2025 14:00:38 +0900

취미로 하는 수영을 가지고 앱을 만들어보자 라는 다짐으로 혼자 프로젝트를 시작했습니다.

앱 기능 중 피트니스 앱 처럼 수영 데이터를 보여주는 기능을 만들기 위해 HealthKit을 사용하게 됐습니다.

공식문서나 다른 글을 봐도 HealthKit steps 정도만 사용하는 경우가 많아서 이번 기회에 삽질한 내용을 정리합니다.

기본 설정

먼저 프로젝트 생성 후

HealthKit Capability

먼저 App Target으로 이동해서 HealthKit Capability를 추가해줍니다.

두 개의 체크박스는 그냥 데이터를 fetch하는데는 필요가 없기 때문에 그냥 넘어가도 됩니다.

그래도 간략하게 정리하자면.. 질병 정보 읽기 권한 체크, 레코드 갱신시 백그라운드에서도 동작하게 허용하는 체크입니다.

info.plist

plist에도 권한 체크를 위한 메시지를 설정해야 합니다!

share, read 중 하나만 사용한다고 해도 둘 다 설정해야 제대로 뜨는걸 삽질하다보니 알아냈습니다 ㅠㅠ

이제부터는 구현으로 넘어갑니다.

HealthKit 구현

import HealthKit

final class HealthKitRecordRepositoryImpl: HealthKitRecordRepository {
    private let store: HKHealthStore = HKHealthStore()
    private let read: Set<HKObjectType>

    init(read: Set<HKQuantityType>? = nil) {
        if let read = read {
            self.read = read
        }
        else {
            self.read = Set(
                HealthKitType.allCases.compactMap{HKObjectType.quantityType(forIdentifier: $0.quantityTypeIdentifier)} +
                [HKObjectType.workoutType(), HKSeriesType.workoutRoute()]
            )
        }
    }
...
}

HealthKit에 접근할 수 있는 HKHealthStore, fetch 해올 타입을 저장할 HKObjectType의 집합을 하나 만들어 놓습니다.

여기서 HKObjectType은 특별한 상황이 아니면 사용하는것만 사용할테니 enum으로 정의 해둔것 사용하게 했습니다.

추가로 HKObjectType.workoutType(), HKObjectType.workoutRoute()는 각각 운동 세션 오버뷰, 운동 경로를 접근할 수 있는 타입입니다.

HKObjectType.workoutRoute()는 꼭 하지 않아도 됩니다. (추후 OpenWater 운동 데이터 경로를 뽑기위해 넣어둠)

권한 요청

func requestAuthorization() async throws -> Bool {
    guard HKHealthStore.isHealthDataAvailable() else { return false }
    try await store.requestAuthorization(toShare: [], read: read)
    // 요청 후 한 번 더 물어볼 필요가 없는지 확인
    return try await hasReadAuthorization()
}

isHealthDataAvailable() 메서드를 사용해 기기가 HealthKit을 사용할 수 있는지 먼저 확인합니다.

그리고 store.requestAuthorization 메서드에 읽어올 타입 집합을 넣고 실행시키면, 실제 앱에서 권한체크를 할 수 있습니다.

마지막 return문 에서는 따로 권한체크를 위한 함수를 구현해뒀습니다.

여기까지 Fetch 하기위한 작업이었고 진짜 Fetch를 시작합니다.

HealthKit Fetch Quries

데이터를 읽어올 때 사용하는 쿼리는 여러 종류가 있습니다.

이전에는 Swift Concurrency를 지원하지 않은것으로 공부했는데, 이번 프로젝트를 진행하며 보니 Swift Concurrency를 지원하는 쿼리들로 업데이트 되었습니다!

그래서 여기서는 업데이트 된 쿼리 몇 가지를 비교해보고 사용법을 정리하겠습니다.

HKSampleQueryDescriptor	단순히 데이터만 가져옴
HKStatisticsQueryDescriptor	합계, 평균, 최댓값 등의 통계를 가져옴 (요약용)
HKStatisticsCollectionQueryDescriptor	일정 단위로 나눠 통계를 시계열 데이터로 가져옴 (차트에 유용)

그 외 증분쿼리, 변경 감지용 이벤트 쿼리 등 여러가지가 있지만, 통계용 화면을 만들기 위한 3가지만 알아보겠습니다.

HKSampleQuery

func fetchDataByDateRange(type: HealthKitType, start: Date, end: Date) async throws -> [HKQuantitySample] {
    try await hasReadAuthorization()

    let swimType = HKQuantityType(type.quantityTypeIdentifier)
    let rangeOfDate = HKQuery.predicateForSamples(withStart: start, end: end, options:
.strictStartDate)

    let descriptor = HKSampleQueryDescriptor(predicates:[.quantitySample(type: swimType,
predicate: rangeOfDate)], sortDescriptors: [.init(\.startDate, order: .forward)])

    return try await descriptor.result(for: store)
}

수영과 관련된 타입 .distanceSwimming, .swimmingStrokeCount을 fetch 하는 코드입니다.

.distanceSwimming은 측정된 기록 시간 범위에 수행한 거리가 반환됩니다.
.swimmingStrokeCount는 측정된 기록 시간 범위에 스트로크 카운트와 영법 유형이 반환됩니다.

타입 결정 후 fetch 할 범위를 predicate로 지정합니다.

마지막으로 HKSampleQueryDescriptor 에 지정한 타입, 조건을 넣어 fetch를 해주면 됩니다.

데이터를 가져오는 방식은 간단하지만 사용할 데이터를 추출하는게 어려웠습니다..

.distanceSwimming 데이터 추출하기

이 부분은 간단했습니다.

여기서 사용할 데이터는 시간 범위와 측정된 수행 거리만 추출하면 됐습니다.

let distanceResult = try await repository.fetchDataByDateRange(type: .distanceSwimming, start: startDate, end: endDate)

let startDate = distanceResult.first?.startDate
let endDate = distanceResult.first?.endDate
let distance = distanceResult.first?.quantity.doubleValue(for: .meter())

간략하게 정리용으로 작성한 코드입니다.

Fetch를 하면 구간 데이터가 배열로 넘어오게 되고 여기서 구간별 거리 및 시간범위를 추출할 수 있습니다.

.swimmingStrokeCount 데이터 추출하기

여기서 영법을 추출하는 방법에 대해 엄청나게 검색을 했습니다..

도저히 내부 메서드로는 추출할 수 없는것 같아 공식문서 포함 이곳저곳 검색해보니 metadata에 Key 값으로 접근해야 데이터를 받을 수 있다는 것을 알게 되었습니다.

let strokeResult = try await repository.fetchDataByDateRange(type: .swimmingStrokeCount, start: startDate, end: endDate)

let sourceRevision = strokeResult.first?.sourceRevision.source.name ?? "Unknown device"
let startDate = strokeResult.first?.startDate
let endDate = strokeResult.first?.endDate
let strokeStyle = strokeResult.first?.metadata?[HKMetadataKeySwimmingStrokeStyle] as? Int

여기서 혹시 metadata[HKMetadataKeySwimmingStrokeStyle]를 distanceResult 에서도 뽑을 수 있지 않을까? 했지만, 테스트 해 본 결과 .swimmingStrokeCount에서만 기록되는 데이터 였습니다.

HKMetadataKeySwimmingStrokeStyle 는 어떤 값이 들어올까? 라는게 가장 큰 관건이었는데, 값을 하나하나 피트니스앱과 비교하기 귀찮았기에..

검색을 해보니 아래와 같은 데이터를 얻을 수 있었습니다.

/**
 @enum          HKSwimmingStrokeStyle
 @abstract      Represents a style of stroke used during a swimming workout.
 */

@available(iOS 10.0, *)
public enum HKSwimmingStrokeStyle : Int, @unchecked Sendable {
    case unknown = 0
    case mixed = 1
    case freestyle = 2
    case backstroke = 3
    case breaststroke = 4
    case butterfly = 5

    @available(iOS 16.0, *)
    case kickboard = 6

}

Enum이 이미 존재하기 때문에 하나하나 구분할 필요는 없습니다!

AppleWatch SE 기준
kickboard 케이스가 매칭되지 않음! (최신 애플워치가 없어서 다른 테스트는 못해봤습니다 ㅠㅠ)

distanceSwimming 타입에서는 측정 범위와 거리가 존재하지만,
swimStrokeCount 타입에서는 kickboard 사용했을때의 측정데이터가 존재하지 않음
stroke 가 없어서 인 것 같지만, 그래도 이부분 참고

이렇게 데이터 추출까지 확인해봤습니다.

HKStatisticsQuery

func fetchStatisticsQuery(
    type: HealthKitType,
    unit: HKUnit,
    start: Date,
    end: Date,
    options: HKStatisticsOptions
) async throws -> Double {
    let quantityType = HKQuantityType(type.quantityTypeIdentifier)
    let predicate = HKQuery.predicateForSamples(withStart: start, end: end, options: [])
    let descriptor = HKStatisticsQueryDescriptor(
        predicate: .quantitySample(type: quantityType, predicate: predicate),
        options: options
    )
    let stats = try await descriptor.result(for: store)
    // 데이터 추출 후 옵션에 따른 데이터 뽑는 방식
    ... // 아래에서 따로 설명
}
// usage
result.totalActivityBurn = try await repository.fetchStatisticsQuery(type: .activeEnergyBurned, unit: .kilocalorie(), start: start, end: end, options: .cumulativeSum)

result.heartRateMax = try await repository.fetchStatisticsQuery(type: .heartRate, unit: bpmUnit, start: start, end: end, options: .discreteMax)

result.heartRateAvg = try await repository.fetchStatisticsQuery(type: .heartRate, unit: bpmUnit, start: start, end: end, options: .discreteAverage)

Fetch 하는법은 비슷하기때문에 설명은 스킵하고,
HKStatisticsQueryDescriptor에서 반환되는 값을 원하는 방식으로 추출하는 방법을 알아보겠습니다.

코드를 보면 options에 따라 데이터 뽑는 법이 다른것을 알 수 있습니다.

switch options {
    case .cumulativeSum: // 누적합계
        return stats?.sumQuantity()?.doubleValue(for: unit) ?? 0
    case .discreteAverage: // 샘플들의 평균값
        return stats?.averageQuantity()?.doubleValue(for: unit) ?? 0
    case .discreteMin: // 최솟값
        return stats?.minimumQuantity()?.doubleValue(for: unit) ?? 0
    case .discreteMax: // 최댓값
        return stats?.maximumQuantity()?.doubleValue(for: unit) ?? 0
    case .mostRecent: // 최근 기록된 값
        return stats?.mostRecentQuantity()?.doubleValue(for: unit) ?? 0
    default:
        return 0
    }

모든 옵션이 사용되진 않지만, 알아보기 위해서 전부 올려두었습니다.

합계, 평균값 등에 따라 Fetch 후 사용할 수 있는 내장 메서드가 정의되어 있기때문에 쉽게 사용이 가능합니다.

HKUnit 은 어떤 포멧으로 값을 추출할지를 설정할 수 있습니다.

HKStatisticsCollectionQuery

func fetchStatisticsCollectionQuery(
    type: HealthKitType,
    start: Date,
    end: Date,
    options: HKStatisticsOptions,
    interval: DateComponents = DateComponents(minute: 1)
) async throws -> HKStatisticsCollection {

    let predicate = HKQuery.predicateForSamples(withStart: start, end: end, options: .strictStartDate)
    let quantityType = HKQuantityType(type.quantityTypeIdentifier)
    let sameplePredicate = HKSamplePredicate.quantitySample(type: quantityType, predicate: predicate)

    let descriptor = HKStatisticsCollectionQueryDescriptor(predicate: sameplePredicate, options: options, anchorDate: start, intervalComponents: interval)
    return try await descriptor.result(for: store)
}

마지막으로 차트에서 사용하기 유용한 CollectionQuery 입니다.

다른 Query와 마찬가지로 데이터타입, 가져올 날짜 범위를 설정해주면 됩니다.

여기서 다른점은 interval 옵션이 있는것입니다.
interval을 설정하면 특정 범위의 데이터를 interval로 분할하여 가져오게 됩니다.

예시를 들면

let interval = DateComponents(second: 60)

이렇게 옵션을 설정하면 데이터가 60초 단위로 통계 데이터가 쌓여 반환됩니다.

위 방법들로 데이터를 활용하면 수영기록에 대한 Overview를 쉽게 만들 수 있습니다!

[프로그래머스] Lv2 귤 고르기

JustHm — Wed, 22 Oct 2025 12:00:05 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/138476

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

문제 풀이

먼저 특정 크기의 귤의 갯수를 구하는게 먼저라 생각해 이것을 먼저 사전 처리하고,

서로 다른 종류의 수를 최소화 해야하니 가장 많은 갯수의 귤부터 먼저 다 넣어가면서 차례대로 처리한다면 쉽게 풀 수 있겠다 생각이 들었다.

해결 방법

func solution(_ k:Int, _ tangerine:[Int]) -> Int {
    var k = k
    var answer = 0
    var dict = [Int:Int]()
    for item in tangerine { // 크기별 귤 갯수 카운트
        dict[item, default: 0] += 1 
    }

	// 귤 갯수를 내림차순으로 정렬 후 박스에 넣기
    for item in dict.sorted{$0.value > $1.value} {
        k -= item.value
        answer += 1       
        if k <= 0 { break }
    }
    
    return answer
}

귤 갯수가 많은 것 부터 넣어야지만 종류를 최소화 할 수 있다.

이 문제는 쉽게 해결했다.

[프로그래머스] Lv2 점프와 순간이동

JustHm — Wed, 22 Oct 2025 11:54:38 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/12980#

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

문제 풀이

1 부터 12 까지 직접 계산한 결과 규칙이 있는것을 확인했다.

2로 나눠지면 나눈값에 해당하는 인덱스의 값을 사용
나머지가 있으면 바로 이전 인덱스의 값에 +1

해당 규칙을 찾고서 DP 문제라고 생각해 코드를 작성했다.

실패한 DP 방식

결론부터 말하자면 DP 방식은 효율성 점수 0점.

다른 방식을 사용해야한다.

func solution(_ n:Int) -> Int {
    var arr = [0, 1, 1]
    guard n > 2 else { return arr[n] }

    for i in 3...n {
        if i % 2 == 0 {
            arr.append(arr[i / 2])
        }
        else {
            arr.append(arr[i-1] + 1)
        }
    }

    return arr[n]
}

아무래도 10억 이하의 자연수를 범위로 잡고 있기에, 높은 숫자를 다 체크하면서 제한시간을 초과하는것 같다.

그래서 다른 방식을 고민해봤다.

통과한 방식 (그리디? 비트 카운팅?)

func solution(_ n:Int) -> Int {
    var n = n
    var ans = 1
    while n > 1 {
        if n % 2 == 0 {
            n /= 2
        }
        else {
            n -= 1
            ans += 1
        }
    }
    return ans
}

처음부터 계산하는게 아닌 N부터 0으로 가는 스텝을 계산한 방식이다.

나머지가 있으면 한 걸음, 없으면 텔레포트 하는 방식

위 방식으로 효율성 점수까지 통과했다.

나누기를 최대한 활용하니까 스킵하는 스텝수가 많아져 효율성을 통과할 수 있었다.

그런데, 풀이를 보고나니 살짝 이상했다. 이거 비트 카운팅 할때랑 비슷한데?

그래서 몇 개 테스트케이스의 값을 이진수로 바꿔 비트가 1인 갯수만 세어보니 결과와 똑같았다..

간단한 다른 해결 방법

func solution(_ n:Int) -> Int {
    return n.nonzeroBitCount
}

결국 스위프트 내장 메서드인 nonzeroBitCount 를 써서 해결 할 수도 있었다.

SwiftData 도입기 비동기로 사용해보기

JustHm — Fri, 1 Aug 2025 21:29:04 +0900

GitHub - EST-iOS-TEAM2/Dietto: ESTSoft Final 팀프로젝트

ESTSoft Final 팀프로젝트. Contribute to EST-iOS-TEAM2/Dietto development by creating an account on GitHub.

github.com

이전 프로젝트에서 내부 DB가 필요할 때 CoreData를 주로 사용했는데

SwiftData도 알아두면 추후에 마이그레이션 하기 좋을 거 같아 iOS 17 부터 사용할 수 있는 SwiftData를 이번 기회에 도입해보기로 결정했다.

CoreData보다 쉽게 모델을 정의하고, 비슷하게 CRUD를 할 수 있는점 덕분에 SwiftData 도입에 어려운것은 없었다!

난관에 봉착한 때는 CoreData처럼 BackgroundContext를 이용해 비동기로 CRUD 작업을 해보기 위한 도전부터 시작됐다..

SwiftData Repository 생성

SwiftData를 처음 도입할때 CoreData를 도입했을때와 비슷하게 작성하였다.

final class StorageRepositoryImpl<T: PersistentModel>: StorageRepository {

    private let context: ModelContext

    init(modelContainer: ModelContainer) {
        self.context = ModelContext(modelContainer)
    }

...

    func updateData(predicate: Predicate<T>, updateBlock: @escaping (T) -> Void) throws {
        let descriptor = FetchDescriptor<T>(predicate: predicate)
        if let result = try context.fetch(descriptor).first {
            updateBlock(result)
            try context.save()
        }
    }
}

사용할 modelContext를 선언해두고 함수에서 CRUD를 구현하는 방식을 사용했다.

데이터 타입을 Generic으로 한 이유는 여러 모델에 대응하는 하나의 Repository만 두고싶어 사용하게 됐다.

Generic으로 Repository를 만들면 사용할때는 StorageRepositoryImpl<InterestsDTO>()와 같이 주입해주면 된다!

하지만 이렇게 했을땐 CRUD가 동기적으로 실행된다.

데이터가 적을때는 Main Thread에서 블락이 일어날 일이 없겠지만, 데이터가 많으면 블락이 생길 수 밖에 없다

그래서 이번에는 어떻게 하면 비동기로 Thread-safe하게 CRUD 할 수 있을지를 알아봤다.

먼저 CoreData는 NSPersistentContainer에서 newBackgroundContext()메서드를 통해 비동기 작업을 할 수 있었다.

하지만 SwiftData에는 ModelContainer에 위와 같은 메서드를 제공하지 않는다.

그렇다면 이런 방법은 어떨까?

Task.detached {
    let object = ...
    await modelContext.insert(object)
}

문제가 없을거 같았지만 아래와 같은 경고 문구가 떴다.

Non-sendable type ‘ModelContext’ in implicitly asynchronous access to main actor-isolated property ‘modelContext’ cannot cross actor boundary
ModelContext는 non-sendable타입인데 암묵적으로 비동기로 접근되었다. 이 속성은 Main Actor에 속해있어 actor 경계를 넘을 수 없다.

코드에서 사용된 modelContext는 MainActor의 리소스기 때문에 반드시 MainActor 내에서만 호출해야 안전하다는 경고다.
그래서 위 코드로는 비동기 CRUD를 구현해도 충돌은 안나지만 문제가 생길 수 있기에 더 좋은 방법을 찾아봤다.

ModelActor 매크로 사용하기

먼저 놓치고 있던 부분! 비동기 작업에 안전성을 보장해야한다.

일반 class로 생성했을때는 동시성 제어를 자동으로 해주지 않는다.

ModelContext는 그냥 사용하면 Thread-safe 하지 않기 때문에 동시 접근시 Race Condition이 발생할 수 있다.

@ModelActor는 이름에도 있듯이 SwiftData를 위한 Actor라고 생각하면 된다.

기본적으로 actor 기반으로 동작하며 ModelContext의 접근을 직렬화해준다.

이런 특징 덕분에 Thread-safe한 비동기 작업이 가능해진다.

@ModelActor
actor AnotherStorageRepositoryImpl<T: PersistentModel>: AnotherStorageRepository {

    init() {
        let configure = ModelConfiguration("\(T.self)") // 이름 지정
        do {
            let modelContainer = try ModelContainer(for: T.self, configurations: configure)
            self.init(modelContainer: modelContainer)
        } catch {
            fatalError(error.localizedDescription)
        }
    }

    func insertData(data: T) async throws {
        modelContext.insert(data)
        try modelContext.save()
    }

    func updateData(predicate: Predicate<T>, updateBlock: @escaping (T) -> Void) async throws {
        let descriptor = FetchDescriptor<T>(predicate: predicate)
        guard let result = try modelContext.fetch(descriptor).first else { throw StorageError.updateError }
        updateBlock(result)
        try modelContext.save()
    }

    func fetchData(where predicate: Predicate<T>? = nil, sort: [SortDescriptor<T>] = []) async throws -> [T] {
        let descriptor = FetchDescriptor<T>(predicate: predicate, sortBy: sort)
        return try modelContext.fetch(descriptor)
    }

    func deleteData(where predicate: Predicate<T>) async throws {
        try modelContext.delete(model: T.self, where: predicate)
        try modelContext.save()
    }
}

ModelActor 매크로에는 ModelContext와 Executor가 존재해 따로 Context를 선언을 하지 않아도 된다.

그냥 Container만 잘 생성해서 넘겨주면 된다! (아래는 ModelActor 매크로의 본문 중 일부)

@available(swift 5.9)
@available(macOS 14, iOS 17, tvOS 17, watchOS 10, *)
extension ModelActor {

    /// The optimized, unonwned reference to the model actor's executor.
    nonisolated public var unownedExecutor: UnownedSerialExecutor { get }

    /// The context that serializes any code running on the model actor.
    public var modelContext: ModelContext { get }
}

여기까지가 비동기 작업을 구현할 수 있는 초석이다.
그럼 이제 Container를 주입해주고 초기화하여 사용하면 의도한대로 MainThread가 아닌 다른 Thread에서 동작을 할까?

NOPE

미자막으로 하나만 해주면 완성이다.

바로 ModelActor를 초기화 할 때, Background Thread에서 초기화 해준다면 이 후 CRUD 함수를 호출해도 Background Thread에서 동작하는 걸 확인 할 수 있다.

Task.detached(priority: .background) { [weak self] in
    self?.userStorageUsecase = UserStorageUsecaseImpl(storage: AnotherStorageRepositoryImpl<UserDTO>())
//Container는 Generic을 정의할 때 자동으로 초기화 후 주입되게 했습니다. (ModelActor 매크로 사용하기 부분 코드 참조)
}

그렇다면 마지막으로 Background Thread 동작이 보장되는 이유도 알아보자.

ModelActor를 초기화 할 때는 ModelContext라는 변수를 먼저 초기화 해 준다. 여기서 이 Context가 초기화 시점에 부모 Context를 상속받아 사용하기 때문에, 비동기 컨텍스트 내에서 생성하면 비동기로 동작하는게 보장되는 ModelActor가 생성된다.

Ref

UnownedSerialExecutor Apple dev docs

ModelActor Apple dev docs

Concurrency of SwiftData, by Donny Wals

Power of ModelActor in SwiftData

이렇게 자세히 공부하게 된 이유는..

이 프로젝트에서는 비동기로 초기화 후 주입하지 않아도 Background Thread에 할당되기에 너무 이상해서 다른 팀원과 함께 열심히 알아보았다.. (도움을 받은 ㅎㅎ)
결국 샘플 프로젝트를 만들어 실행해보니, Background Thread에서 초기화를 해줘야만 되는것이 맞았다.

그래서 여전히 미스테리다.. 왜 이 프로젝트는 시뮬, 실 기기 모두 백그라운드에서 잘 돌았는가..

다른 친구의 기기로 실행해보니 Background Thread에서 초기화 하지 않으면 Main Thread에 할당되는 정상적인 모습 확인. (내 기기가 이상한 거 같다)
참고로 SwiftData는 auto save가 된다고 했지만, Background Thread에서는 안된다. 그래서 꼭 context.save() 명시 해줘야함

iOS - Multi-Threading

JustHm — Tue, 29 Jul 2025 18:50:15 +0900

Multi-Threading?

짧은 시간에 복잡하고 많은 작업을 실행하여 사용자에게 좋은 경험을 제공하기 위해,
작업을 여러 프로세스에서 동시에 실행시키는 병렬 처리 방법!

iOS에서도 역시 Multi-Threading을 지원한다.

iOS에서 사용하는 Multi-Threading

대표적인 3 가지!

GCD (Grand Central Dispatch)
Operation, OperationQueue (NSOperation)
Swift Concurrency

먼저 하나씩 알아보자!

GCD (Grand Central Dispatch)

https://developer.apple.com/documentation/dispatch
GCD는...

iOS 8.0+
저수준 큐 기반
멀티코어 환경과 멀티스레드 환경에서 최적화된 프로그래밍을 할 수 있도록 애플이 개발한 기술
어떻게 사용할지 (일의 순서, 동기/비동기 처리) 정해주면 스레드를 관리해준다.
GCD 사용은 Dispatch라는 프레임 워크를 사용하고 DispatchQueue라는 클래스를 주로 사용한다.

사용법

// 동기, sync 
DispatchQueue.main.sync { ... } 
DispatchQueue.global().sync { ... } 
// 비동기, async 
DispatchQueue.main.async { ... } 
DispatchQueue.global().async { ... }

자세한 내용은 이전에 정리했던 노션 글 참조! (야곰 강의 정리본)
https://galvanized-jeep-eb7.notion.site/Concurrency-Programming-cc51f4320fd149acab2e44e20d3ba647

Operation, OperationQueue (NSOperation)

https://developer.apple.com/documentation/foundation/operation
Operation은...

iOS 2.0+
GCD를 객체지향적으로 재탄생 시킨것
동시성 프로그래밍에 관련한 작업을 Operation이라는 객체로 만들어 놓고 사용할 수 있다.
Operation을 상속받아 커스텀 클래스로 직접 만들거나 BlockOperation이라는 하위 클래스를 사용해 사용가능
GCD에도 작업을 객체로 만드는 DispatchWorkItem이 있다... 다른점은?
- 일단 Operation은 DispatchWorkItem 보다 먼저 나옴
- Operation은 객체지향적으로 설계되어 더 세부적인 스케쥴링 가능
- 세부적인것 중 대표적인 부분은 Operation 상태추적을 위한 다양한 프로퍼티가 존재함

사용법

let operation = BlockOperation { ... } // 생성
operation.addExecutionBlock { ... } // 첫번째로 초기화 한 위 작업이 끝나면 실행됨.
operation.completionBlock = { ... } // ExecutionBlock이 모두 실행된 뒤 호출되는 Property

operation.start() // 직접 실행하는 방식

let operationQueue = OperationQueue() //OperationQueue에 넣어 실행하는 방식
operationQueue.addOperation(operation)

자세한 내용은 이전에 정리했던 노션 글 참조! (야곰 강의 정리본)
https://galvanized-jeep-eb7.notion.site/Operation-3df4b450f95a4db985b5c193838c6b30

Swift Concurrency

https://developer.apple.com/documentation/swift/concurrency
Concurrency는...

iOS 13.0+
구조적 동시성(Structured Concurrency)을 지향
GCD의 복잡함을(콜백) 줄이고 가독성, 안전성을 보장한 비동기 코드를 작성할 수 있도록 만듦.
스레드, 큐를 직접 다루지 않아도 비동기 작업을 간단하고 명확하게 구현가능.
직관적인 문법제공 - async, await, Task, actor 등의 키워드

이것도 이전 스터디 노션 정리내용으로!
강의영상 저작권 때문에 링크는 X

잘 몰랐지만 직접 쓰레드를 생성하는 방법도 있었다!

let current = Thread.current
print("current thread", current, current.stackSize)

let newTread1 = Thread()
newTread1.name = "secondThread"
print("secondary thread with default size", newThread1, newThread1.stackSize)

let newTread2 = Thread()
newThread2.name = "thirdThread"
newThread2.stackSize = 4096 * 512
print("secondary thread with default size", newThread2, newThread2.stackSize)


/* Thread class also has...*/
Thread.isMainThread //Bool

DispatchQueue, OperationQueue의 차이

	DispatchQueue	OperationQueue
작업 간 의존성 설정	불가능	addDependency 메서드 사용해 가능
작업 취소 기능	수동구현	cancel로 명시적 취소 가능
우선순위 설정	qos로 제한적 가능	queuePriority qualityOfService 설정으로 상세하게 가능
재사용/재시작/중단	불가능	Operation으로 가능
결론	간단한 작업에 적합	복잡한 작업에 적합

Race Condition

Race Condition은 두 개이상 스레드가 하나의 자원에 동시에 접근 및 수정하려 할 때 발생하는 문제

그럼 각 Multi-Threading 방식에서는 어떻게 방지할 수 있는지 알아보자

GCD

Serial Queue 사용
Serial Queue를 사용하면 같은 큐에 실행되는 작업은 순차적으로 실행되기 때문에 동시접근이 발생 안함

let serialQueue = DispatchQueue(label: "com.example.myQueue")

serialQueue.async {
    // 공유 자원에 안전하게 접근
}

Dispatch Semaphore 사용

운영체제 과목을 공부하다보면 나오는 Semaphore와 같은 개념
특정 자원에 접근 가능한 스레드 수를 제한하는 방식

하나의 스레드가 접근하여 작업을 하는동안 다른 스레드는 대기하다가 들어갈 수 있게 되면 작업을 시작함.

let semaphore = DispatchSemaphore(value: 1) //접근 가능한 수 설정으로 이해하면 됌
func updateSharedResource() { 
    semaphore.wait() // 접근 시작 
    sharedResource += 1 
    semaphore.signal() // 접근 종료 
}

Operation

Operation 의존성 사용

그냥 동시에 실행되지 않게 실행순서를 보장하는 방법

let op1 = BlockOperation { /* 공유 자원 수정 */ }
let op2 = BlockOperation { /* 이후 작업 */ }

op2.addDependency(op1)
queue.addOperations([op1, op2], waitUntilFinished: false)

NSLock 사용

Lock을 사용해 명시적으로 접근을 제어가능

let lock = NSLock()
let operation = BlockOperation {
    lock.lock()
    // 공유 자원 접근
    lock.unlock()
}

Swift Concurrency

Actor 사용
actor는 내부 상태를 단일 태스크만 접근 가능하도록함.

actor Counter {
    private var count = 0

    func increment() {
        count += 1
    }

    func value() -> Int {
        return count
    }
}

// 사용
let counter = Counter()
await counter.increment()
let current = await counter.value()

메인 스레드에서 UI 업데이트를 해야 하는 이유는 무엇일까?

일단 iOS에서 메인 스레드는 UI, event 처리를 모두 담당하고 있다.

좋은 사용자 경험 및 일관성을 위해,
프레임워크 자체가 메인스레드에서 안전하게 작동되도록 설계되었기 때문이다.

UI업데이트를 병렬로 처리한다면 Race Condition이 발생 할 수 있다.
물론 방지하는 방법을 쓰면 괜찮겠지만, 어쩔 수 없이 지연이 생기게 될 것이다.
그렇게되면 일관성 및 사용자 경험이 저해되는 상황이 발생하게 된다.

번외로 메인스레드에서 오래걸리고 복잡한 로직을 (UI아님) 실행하게 된다면
메인 스레드 블락 현상이 발생한다. 그럼 화면 터치도 안되고 앱 자체가 작업이 끝날때 까지 멈추게 된다.
이를 방지하기 위해 메인스레드에서 UI 또는 이벤트 작업 외에는 동시성을 사용하는게 좋다.

의존성 관리 도구 알아보기 (SPM, CocoaPod, Carthage)

JustHm — Tue, 15 Jul 2025 16:26:53 +0900

의존성 관리도구가 하는 일

프로젝트에 외부 라이브러리를 쉽게 관리할 수 있게 도와주는 도구!

라이브러리 설치, 버전관리, 업데이트 관리, 빌드 통합 등을 도와주는 도구다.

iOS에서는 대표적으로 3가지 의존성 관리 도구가 있다.

SPM(Swift Package Manager) - First party, git기반, 요즘에는 대부분 라이브러리가 SPM도 지원함
CocoaPod - third party, obj-c 시절부터 인기있었음, Ruby 기반
Carthage - third party

각각의 장단점을 알아보자

SPM (Swift Package Manager)

장점

Xcode 내장(first party도구)이 되어있어 프로젝트에 쉽게 라이브러리를 추가하고 관리할 수 있다.

처음 나왔을때는 지원하는 라이브러리가 적었지만 지금은 신경안써도 될 정도로 많이 지원하고 있음.

Git 기반으로 외부 스크립트에 의존이 없음

단점

obj-c 시절 레거시 라이브러리는 지원이 미비함..

CocoaPod

장점

obj-c 시절부터 유명한 도구기 때문에 거의 모든 라이브러리가 지원하고있음

프로젝트에 라이브러리를 가져오고 빌드 설정을 자동으로 해주기때문에 편리하다.

단점

업데이트나 프로젝트에 install시 속도가 느리다.

다른 pod file간 충돌 또는 workspace가 꼬일 수 있다.

xcworkspace로 프로젝트 파일이 자동으로 생겨 바로 쓰면 되긴하지만, 추가적인 부분이 필요하면 나머지 설정도 CocoaPod에 맞게 설정해둬야한다.

Carthage

장점

CocoaPod과 다르게 Xcode 프로젝트를 건드리지 않고 프레임워크만 만들어준다.

빌드 링킹 방식을 내가 직접 관리할 수 있다.

가볍고 빠르다!

단점

자동으로 빌드는 해주지만 통합은 내가해야한다.. (수동) 프레임워크 링킹을 추가해줘야하는것.

지원하는 라이브러리가 적음

현재는 SPM에 많이 힘을 쏟고있으니 레거시가 아니라면 SPM을 사용하는편이 관리하기 편하다 생각이든다.

Swift 고차함수 정리 - map, flatMap, compactMap / filter, reduce, forEach

JustHm — Tue, 8 Jul 2025 00:43:45 +0900

고차함수 (High order function)

다른 함수를 매개변수로 받거나 반환하는 함수를 의미한다.
클로저와는 다르다 (클로저는 이름이 없는 익명함수)

고차함수가 매개변수로 받는 함수가 클로저일때가 많아서 헷갈릴수는 있지만, 고차함수 안에서 클로저를 자주 사용하는 것 뿐 같은 개념은 아니다.

특징

가독성
함수형 프로그래밍 스타일
재사용성 높음

map

let numbers = [1, 2, 3, 4, 5]
let twoTimesNumbers = numbers.map{ $0*2 }
//[2, 4, 6, 8, 10]

각 요소에 동일한 연산을 적용해 새로운 배열을 반환한다.
for-in문과 비교했을 때 차이는 없지만, 속도면에서 차이가 있다. (요소가 많을수록 차이 남)

flatMap

let numbers = [[1, nil], [nil, nil, 2], [3]]
let flatArray = numbers.flatMap{ $0 }
//[Optional(1), nil, nil, nil, Optional(2), Optional(3)]

다차원 배열을 1차원 배열로 flat하게 만들어 반환한다.
Optional을 따로 처리하진 않기 때문에 만약 Optional을 없애고 싶다면 CompactMap을 같이 쓰면 된다!

사용하다보면 1차원 배열에 flatMap을 써도 옵셔널이 제거되는걸 볼 수 있는데, deprecated 된 것이니까 compactMap을 쓰자.

자세한건 compactMap에 설명

compactMap

let numbers = [1, nil, 3, nil, 5]
let numbersWithOutNil = numbers.compactMap{ $0 }
//[1, 3, 5]

요소 중 nil을 제거한 나머지 요소들을 반환한다.

Nil이 있는 1차원 배열에 FlatMap을 사용해도 compactMap과 동일한 기능을 하는데,
이는 Swift4.1 이전 flatMap이 두 기능(평탄화, 옵셔널제거)을 모두 같이 했었다가
이후에 평탄화만 되는 flatMap, 옵셔널 제거를 위한 compactMap 두 가지로 나눴다.

filter

let numbers = [1, 2, 3, 4, 5]
let temp = numbers.filter{ $0 % 2 == 0 }
//[2, 4]

요소 중 주어진 조건을 만족하는 요소들만 포함하는 새로운 배열을 반환한다.

reduce

let numbers = [1, 2, 3, 4, 5]
let sum = numbers.reduce(0, +)
//15

모든 요소를 하나로 합쳐 단일값을 반환한다.
초기값과 결합하는 방법을 파라미터로 넘기면 된다.

결합하는 방법은 간단하게 사칙연산자를 사용해도 되고, numbers.reduce(0) {$0 + $1} 처럼 클로저를 사용하는것도 가능하다.

ForEach

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

numbers.forEach { number in
    print(number)
}

각 요소에 대해 주어진 작업을 수행한다. 반환값은 없고, 반복문 대용으로 사용하는 편.

for-in문과 비슷해보이지만 break, continue와 같은 반복문에 들어가는 키워드를 사용할 수 없다.

ARC (자동 참조 카운트) 자세히 알아보기 + 참조 키워드(weak, strong, unowned)

JustHm — Tue, 1 Jul 2025 14:39:59 +0900

정의

ARC(Automatic Reference Counting)는 메모리 구조에서 힙 영역을 관리한다.
Swift에서 힙에 메모리를 할때는 참조타입을 생성할 때 자동으로 할당하게 된다.
ARC는 할당된 메모리가 더 이상 필요하지 않을 때 자동으로 해제한다.

C++에서는 new, delete 키워드를 통해 클래스 인스턴스를 생성할 때 메모리를 할당, 해제 한다.

특징

컴파일 시점에 언제 참조되고 해제되는지 결정되어 런타임때 그대로 실행된다.

장단점

장점
- 개발자가 참조 해제 시점을 파악할 수 있음
- RunTime 시점에 추가 리소스가 발생하지 않음
단점
- 순환 참조 발생 시 영구적으로 메모리가 해제되지 않을 수 있음

MRC? ARC?

둘 다 Reference Counting을 하지만, Manual, Automatic의 차이가 있다.
MRC는 2011년 이전 Objective-C에서 사용했던 방법이다.
C++와 비슷하게 retain, release 를 사용해 할당, 해제를 한다.
Obj-C 코드를 건드릴 일이 있다면... 참고

동작 방식

메모리의 참조 횟수를 계산해 참조 횟수가 0이 되면 더 이상 사용하지 않는 메모리라 생각해 해제한다.
참조 횟수를 계산하는 방법을 알아보자

참조 횟수가 증가할 때

인스턴스를 새로 생성할 때
기존 인스턴스를 다른 변수에 대입할 때

참조 횟수가 감소할 때

인스턴스가 가리키던 변수가 메모리에서 해제되었을 때
nil이 지정되었을 때
변수에 다른 값을 대입한 경우
프로퍼티의 경우 속해있는 클래스 인스턴스가 메모리에서 해제될 때
- A클래스 안에 B 클래스 인스턴스가 프로퍼티로 존재할때 각각 인스턴스의 RC가 증가함
- A 인스턴스를 생성 후 제거 했을 때 A의 프로퍼티인 B 인스턴스도 A 해제 후 해제.

순환 참조(retain cycle) & keywords

ARC 단점 중 순환참조 발생 시 영구적으로 메모리가 해제되지 않을 수 있다. 라는게 있었다.
순환 참조는

두 개의 객체가 서로를 참조하고 있는 형태다.

먼저 코드로 이해해보자

class A { var b: B?}
class B { var a: A?}
// 여기서 A, B의 RC 각각 + 1
var a: A = A()
var b: B = B()
// 여기서 A, B의 RC 각각 + 1
a.b = b
b.a = a
// 최종 A,B의 RC는 각각 2

이렇게 되면 a, b변수를 nil로 만들어 해제하든 뭘하든 RC는 1 남게된다.
그렇게 memory leak이 발생하게 된다.

이런 문제를 해결하기 위해서는 키워드 중 weak, unowned를 사용하면 된다.

strong (강한 참조)

Swift를 사용하면서 인스턴스의 주소값이 변수에 할당될 때 강한참조를 사용한것이다.
인스턴스 생성시 default로 strong 키워드가 있어 RC를 +1 하게 된다.

하지만 강한 참조를 사용하다보면

순환참조

가 발생해 문제를 일으킬 수 있다.

weak (약한 참조)

단어 그대로 strong의 반대인 약한 참조다
strong은 default라 사용안했지만 weak의 경우 명시해줘야 한다.
특징을 먼저 알아보고 간단하게 코드를 확인해보자

특징

인스턴스 참조시 RC를 증가시키지 않음
참조하던 인스턴스가 메모리에서 해제된 경우, 자동으로 nil이 할당돼 메모리가 해제된다.
위와 같은 이유로 무조건 Optional 타입의 변수다.

해제되는 과정

class A { weak var b: B?}
class B { var a: A?}
// 여기서 A, B의 RC 각각 + 1
var a: A = A()
var b: B = B()
// A의 RC = 2, B의 RC = 1
a.b = b
b.a = a
// 순환이 끊어져

생성시 A, B 각각 +1
각 인스턴스에 프로퍼티를 할당할 때도 +1 이지만 weak이 붙은 프로퍼티인 B는 증가하지 않음
메모리 해제시 각 RC를 -1하게 됨
B의 RC는 해제 직전 1이 였기에 0이되고 메모리에서 제거됨
A는 B가 메모리에서 제거됐기 때문에 B가 가지고 있던 A인스턴스가 해제되고 A의 최종 RC도 0이 된다.
생각보다 간단하다.

weak을 어디다 선언해도 문제 없을까?
둘 중 수명이 더 짧은 인스턴스를 가리키는 애를 약한 참조로 선언하면 된다.
아니면 그냥 둘 다 weak으로 하고 예외처리 하거나..

unowned (미소유 참조)

weak과 동일한 특징을 갖는다. (마지막 특징 빼고..) 특별한 점은

옵셔널이 아니다

인스턴스를 참조하는 도중에 해당 인스턴스가 메모리에서 사라질 일이 없다고 확신하는것이다.

만약에 인스턴스가 메모리에서 해제된 경우에도 unowned는 nil을 할당받지 못하고 계속 해제된 메모리의 주소를 갖고있게 된다.

그래서 위와 같은 경우에서는 런타임 에러가 생긴다.

웬만해서 weak을 사용하는걸 권장한다

Swift 5.0 부터 Optional Type으로도 선언 가능하다.

추가

Grabage Collection과의 차이

“ARC는 객체의 참조 카운트를 기반으로 메모리를 관리하는 방식이고, GC는 주기적으로 불필요한 객체를 탐색해 제거하는 방식

GC는 런타임에서 ARC는 컴파일 타임에서!

GC는 런타임에서 동작하다보니 추가 리소스가 필요해 성능 저하가 발생할 수 있다.

Pinit 셀 재사용 이슈

JustHm — Wed, 25 Jun 2025 16:17:50 +0900

발생했던 문제

Pinit 에서는 이미지가 있을때는 그대로 보여주고, 이미지가 없다면 기록한 위치의 지도를 스냅샷으로 보여준다.

여기서 문제가 발생했다.

이미지는 저장된걸 바로 보여주지만, 스냅샷은 주소만 보내주고 셀에서 스냅샷 이미지를 로드하기에 몇 초 더 지연시간이 생긴다.

이때 셀이 엄청 많을때 스크롤을 하면, 재사용 때문에 이전에 사용된 이미지 또는 스냅샷이 먼저 보이고 나중에 제대로 된 스냅샷으로 갈아끼워지는 문제가 있었다.

문제점 파악

문제점은 역시 셀 재사용 매커니즘을 제대로 이해못하고 지연시간을 고려하지 않았기 때문이다.

셀이 재사용 될 때 이전 데이터를 그대로 들고 있다는 것 역시 인지하지 못했기 때문에 일어난 문제였다.

셀이 화면에서 사라지면 셀 자체가 지워지지 않고 이전 데이터 그대로 Reusable Queue에 할당된다. (해제되지 않음)

문제 해결

셀 코드

func configure(model: PinEntity) {
    pinDateLabel.text = model.date.formatted()
    pinTitleLabel.text = model.title

    if let image = model.mediaPath {
        thumbnailImageView.image = image
    }
    else {
        captureMapSnapshotWithPin(
            center: CLLocationCoordinate2D(
                latitude: model.latitude,
                longitude: model.longitude
            ),
            imageSize: CGSize(
                width: contentView.frame.height,
                height: contentView.frame.width
            )) { image in
                self.thumbnailImageView.image = image ?? UIImage(systemName: "house")
            }
    }

    setupLayout()
}

이 부분에서 else로 들어가면 딜레이가 생기는 것, 썸네일이 제대로 뜨기 전 까진 기본 이미지가 뜨게 만들어뒀다.

앞에서 봤던것처럼 셀 자체의 데이터가 지워진채로 재사용 되는것이 아니기 때문에, 설정시 데이터를 다시 초기화해주면 쉽게 해결이 가능했다.

func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
    guard let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "cell", for: indexPath) as? PinRecordCell
    else { return UICollectionViewCell() }

    cell.thumbnailImageView.image = nil
    cell.configure(model: data[indexPath.row])
    cell.layoutIfNeeded()

    return cell
}

cell.configure 내에서 초기화해주는게 좋겠지만, 급하게 제출하느라 cellForItemAt 에서 데이터를 지워줬다.

☝️커스텀 바텀시트 구현 + PanGesture 로 바텀시트 같은 인터렉션 만들기

JustHm — Thu, 12 Jun 2025 16:57:17 +0900

GitHub - EST-iOS-TEAM2/Pinit: ESTSoft 2차 팀프로젝트

ESTSoft 2차 팀프로젝트. Contribute to EST-iOS-TEAM2/Pinit development by creating an account on GitHub.

github.com

바텀시트 만들어보기

탭바를 가리지 않으면서 바텀시트를 홈화면에서 상시운용을 하려는데, 간단한 방법들로는 불가능한거 같아 직접 바텀시트를 만들게 됐다!

물론 검색해보면 엄청난 방법으로 만드는분도 있었지만, 이 프로젝트엔 간단하게만 사용되기에 만드는 방법만 좀 알아보고 적용해봤다.

바텀시트로 사용될 View

final class CustomBottomSheet: UIView {
    var collectionView = UICollectionView(frame: .zero, collectionViewLayout: .init())

    let grabber: UIView = {
        let grabber = UIView()
        grabber.layer.cornerRadius = 4
        grabber.backgroundColor = DesignSystemColor.Lavender.value
        grabber.layer.borderColor = UIColor.white.cgColor
        grabber.layer.borderWidth = 1
        grabber.clipsToBounds = true
        grabber.isUserInteractionEnabled = false //Grabber는 Guide용으로만 사용
        return grabber
    }()

    init() {
        super.init(frame: .zero)
        setupLayout()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func setupLayout() {
        let cornerRadius = 20.0
        self.backgroundColor = .secondarySystemBackground
        self.layer.cornerRadius = cornerRadius
        // cornerRadius 상단 좌,우측만 적용하기
        self.layer.maskedCorners = .init(arrayLiteral: [.layerMaxXMinYCorner, .layerMinXMinYCorner])

        addSubviews(collectionView, grabber)

        grabber.snp.makeConstraints {
            $0.centerX.equalToSuperview()
            $0.top.equalToSuperview().offset(8)
            $0.width.equalTo(100)
            $0.height.equalTo(grabber.layer.cornerRadius * 2)
        }

        collectionView.snp.makeConstraints {
            $0.top.equalToSuperview().offset(cornerRadius*1.8)
            $0.leading.trailing.bottom.equalToSuperview()
        }

        collectionView.isUserInteractionEnabled = false
    }
}

먼저 바텀시트로 사용될 뷰를 생성했다.

Grabber를 만들어두긴 했지만, 가이드용으로만 사용하고 실제 인터렉션은 바텀시트 자체에서 처리할것이다.

그래서 isUserInteractionEnabled를 false로 두어 인터렉션 이벤트에서 아예 제외해버렸다.

물론 CollectionView는 완전 제외한것이 아니다! 가장 높이가 낮을때는 CollectionView는 보이지 않은 상태이니 false인 것,
나중에 높이가 높아지면 인터렉션이 가능하게 변경한다.

ViewController에 바텀시트 등록하기

class HomeViewController: UIViewController {
    // MARK: Variables
    // BottomSheet 동적 높이를 저장하기위한 변수
    private lazy var bottomSheetHeight: CGFloat = view.frame.height / 14
    ...

    // MARK: UI Components
    private var adapter: PinCollectionViewAdapter?
    private let mapView = MKMapView(frame: .zero)
    private let bottomSheet = CustomBottomSheet()

    ...

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

    private func setupProperties() {
        view.backgroundColor = .gray
        // 바텀시트 패닝 제스처 추가
        let panGesture = UIPanGestureRecognizer(target: self, action: #selector(panGestureHandler(_:)))
        bottomSheet.addGestureRecognizer(panGesture)
        // 버튼 액션 추가
        addPinButton.addTarget(self, action: #selector(moveToAddPin), for: .touchUpInside)
        currentLocationButton.addTarget(self, action: #selector(moveToUserLocation), for: .touchUpInside)
    }

    private func setupLayout() {
        view.addSubviews(mapView, addPinButton, currentLocationButton, bottomSheet)
        bottomSheet.snp.makeConstraints {
            $0.leading.trailing.equalToSuperview()
            $0.bottom.equalTo(view.safeAreaLayoutGuide)
            $0.height.equalTo(bottomSheetHeight)
        }
        ...
    }
    ...
}

먼저 bottomSheet를 선언하고, 높이를 동적으로 관리해주기 위해 bottomSheetHeight를 선언한다.

bottomSheet에 PanGesture를 등록해 드래그 했을때 위-아래로 자유롭게 움직일 수 있게 한다.
setupLayout() 함수를 보면 bottomSheetHeight변수를 사용해 동적으로 constraint를 잡아주는 걸 볼 수 있다.

여기까지는 간단하지만, 조금 어려웠던 PanGesture로 등록한 함수 내용을 보자
여기에서 동적으로 높이를 변경하고 업데이트 해주었다.

BottomSheet에 사용될 PanGesture 등록하기

@objc private func panGestureHandler(_ gesture: UIPanGestureRecognizer) {
    // Pretend 크기 설정
    let small = view.frame.height / 14
    let medium = view.frame.height * 0.4
    let large = view.frame.height * 0.8
    // 제스처 시작
    let translation = gesture.translation(in: view)
    let newHeight = bottomSheetHeight - translation.y
    // 제스처 (드래그) 위치에 따라 업데이트
    if newHeight >= small && newHeight <= large {
        bottomSheetHeight = newHeight
        gesture.setTranslation(.zero, in: view)
    }
    // 제스터 (드래그 끝났을때) 위치에 따라 최종 높이 업데이트
    if gesture.state == .ended {
        // 높이 조정 pretend?
        if newHeight > (view.frame.height * 0.6) {
            bottomSheetHeight = large
            bottomSheet.collectionView.isUserInteractionEnabled = true
        }
        else if newHeight > (view.frame.height * 0.25) {
            bottomSheetHeight = medium
            bottomSheet.collectionView.isUserInteractionEnabled = true
        }
        else {
            bottomSheetHeight = small
            bottomSheet.collectionView.isUserInteractionEnabled = false
        }
    }
    bottomSheet.snp.updateConstraints {
        $0.height.equalTo(self.bottomSheetHeight)
    }
    // Constraint 업데이트 + Animation
    UIView.animate(withDuration: 0.07) {
        self.view.layoutIfNeeded()
    }
}

총 3개의 위치를 만들어두고 그 범위에 들어온다면 자동으로 높이를 조정되게 하고싶어 small, medium, large로 고정 높이를 만들어뒀다.

드래그를 시작할때 호출되는 함수기때문에 함수 시작부 부터 gesture.translation.y로 현재 제스처의 y위치를 가져온다.

그 값을 가지고 bottomSheet의 높이가 실시간으로 정해지지만, 초반에 정해둔 small, large를 벗어나면 y값을 갱신하지 않게 만들어뒀다.

제스처가 끝났을때(손가락을 땠을때)는 현재 bottomSheet Height가 어디에 가까운지에 따라서 small, medium, large가 정해지게 로직을 작성했다.

마지막으로 중요한 Constraint 업데이트!

SnapKit을 사용하고 있어서 간편하게 업데이트를 해줬지만, 이것만 하면 제대로 반영되지 않는다.

꼭 layoutIfNeeded()를 호출해 다시 그리게 해야하고, 부드러운 효과를 위해 애니메이션에 duration을 달아 처리를 해준다.
이렇게 하지 않으면 제스처에 따라서 확확 따라오기 때문에 일반적으로 사용하던 바텀시트와 사용감이 달랐다.