SPM Interface 패턴과 증분 빌드 최적화

1. SPM 기본 개념

Static vs Dynamic 링킹

Product vs Target

// Package.swift 예시
let package = Package(
    name: "MyFeatureHome",
    products: [
        // Products: 외부 노출용
        .library(name: "MyFeatureHomeFeature", targets: ["MyFeatureHomeFeature"]),
        .library(name: "MyFeatureHomeDataInterface", targets: ["MyFeatureHomeDataInterface"]),
    ],
    targets: [
        // Targets: 실제 컴파일 단위
        .target(name: "MyFeatureHomeFeature", dependencies: [...]),
        .target(name: "MyFeatureHomeDataInterface", dependencies: []),
    ]
)

2. Package 식별자 규칙

의존성 선언 시 .product(name:package:)의 package 파라미터 값은 의존 방식에 따라 결정된다:

// URL 의존
.package(url: "https://github.com/example/chat-sdk.git", exact: "1.0.44")
.product(name: "ChatSDK", package: "chat-sdk")  // URL 마지막
                                        ^^^^^^^^^^^^^^^^

// path 의존
.package(path: "../../Core/MyNetwork")
.product(name: "MyNetwork", package: "MyNetwork")  // 폴더명
                                         ^^^^^^^^^^^^^^^

단축형 사용 조건

// 단축형
"MyNetwork"

// 명시적 (동일한 의미)
.product(name: "MyNetwork", package: "MyNetwork")

패키지가 여러 product를 제공해도 상관없다. 해당 이름의 product가 존재하고 package 식별자와 같으면 단축형 사용 가능:

// RxSwift 패키지: RxSwift, RxCocoa, RxRelay 등 여러 product 제공

"RxSwift"  // ✅ 단축형 가능 (product명 == package식별자)

.product(name: "RxRelay", package: "RxSwift")  // ⚠️ 명시 필요 (RxRelay ≠ RxSwift)

Package(name:)의 용도

Package.swift 최상단의 name은 표시용이며, URL/path 의존 시 식별자로 사용되지 않는다:

3. binaryTarget (xcframework)

xcframework를 SPM에서 사용하려면 반드시 .binaryTarget으로 선언해야 한다:

targets: [
    .target(
        name: "SDKWrapper",
        dependencies: [
            "SGSAuthGoogle",  // binaryTarget 이름으로 의존
        ]
    ),
    .binaryTarget(
        name: "SGSAuthGoogle",
        path: "SGSSDK/SGSAuthGoogle.xcframework"
    ),
]

xcframework vs 소스 코드

4. Interface 모듈 패턴 (증분 빌드 최적화)

왜 Interface를 분리하나?

구현체가 바뀔 때마다 의존하는 모든 모듈이 재컴파일되는 것을 방지한다:

구조

// BlockUserInterface 모듈 (protocol만)
public protocol BlockUserService {
    var blockedUserMemberNos: Set<String> { get }
    func blockUser(memberNo: String, completion: @escaping (Result<Bool, Error>) -> Void)
    func unblockUser(memberNo: String, completion: @escaping (Result<Bool, Error>) -> Void)
}

// BlockUserManager 모듈 (구현체)
import BlockUserInterface

public final class BlockUserManager: BlockUserService {
    // 구현...
}

Interface 분리 판단 기준

5. 외부 SPM과 Interface 패턴

외부 SPM에 Interface를 둬도 증분 빌드 이득이 있을까?

단, SDK 버전 업 시에는?

Interface가 SDK 타입을 완전히 숨기면 이득이 있다:

// ❌ SDK 타입 노출 → 이득 없음
protocol ChatSDKProtocol {
    func blockUser(_ id: String) async -> Result<Void, ChatSDKError>
}                                                      ^^^^^^^^^^^^^^^^^
// SDK 버전 바뀌면 → protocol도 바뀜 → 의존자 재컴파일

// ✅ SDK 타입 숨김 → 이득 있음
protocol ChatSDKProtocol {
    func blockUser(_ id: String) async -> Result<Void, MyChatError>
}                                                      ^^^^^^^^^^^
// SDK 버전 바뀌어도 → protocol 불변 → 의존자 재컴파일 없음

6. Adapter 패턴으로 외부 SDK 감싸기

외부 SDK를 직접 사용하지 않고 Adapter로 감싸면 테스트/교체/증분빌드 이점을 얻는다:

코드 예시

// ===== ChatServiceInterface 모듈 (SDK 모름) =====
public struct MyChatError: Error {
    public let code: Int
    public let message: String
}

public protocol ChatServiceProtocol {
    func blockUser(_ id: String) async -> Result<Void, MyChatError>
}

// ===== ChatServiceAdapter 모듈 (SDK + Interface 알음) =====
import ChatServiceInterface
import ChatSDK

public class ChatServiceImpl: ChatServiceProtocol {

    public func blockUser(_ id: String) async -> Result<Void, MyChatError> {
        let sdkResult = await ChatSDK.shared.block(id)

        switch sdkResult {
        case .success:
            return .success(())
        case .failure(let sdkError):
            // SDK 타입 → 내 타입으로 변환
            let myError = MyChatError(
                code: sdkError.code,
                message: sdkError.message
            )
            return .failure(myError)
        }
    }
}

의존 방향

7. 의존성 역전 원칙 (DIP)과 빌드 이득

App에서 Adapter 주입

// App (Composition Root)
let chatService: ChatServiceProtocol = ChatServiceImpl()

let featureA = FeatureA(chatService: chatService)  // 주입
let featureB = FeatureB(chatService: chatService)  // 주입

// FeatureA - SDK 전혀 모름
class FeatureA {
    let chatService: ChatServiceProtocol  // Interface 타입

    func doSomething() {
        chatService.blockUser("123")  // Interface 메서드 호출
    }
}

SDK 버전 업 시 재컴파일 범위

8. Tuist에서 SPM 설정

productTypes 설정 위치

// Tuist/Package.swift
#if TUIST
let packageSettings = PackageSettings(
    productTypes: [
        "Alamofire": .staticFramework,
        "LineSDK": .framework,  // dynamic
        "MyNetwork": .staticFramework,
    ],
    baseSettings: .settings(...)
)
#endif

내부 vs 외부 패키지 등록

// AppPackages.swift - App이 직접 쓰는 것만
public let appPackages: [ProjectDescription.Package] = [
    .local(path: .relativeToRoot("Core/SDKWrapper")),
    // SGSBase, SGSAuth 등은 여기 없음 (SDKWrapper가 내부적으로 의존)
]

Q&A

9. Xcode Navigator: Packages vs Package Dependencies

전이적 의존성 해결

appPackages에 없어도 사용 가능?

Interface 모듈이 appPackages에 없어도 되는 이유

App은 구현체만 생성해서 넘기면 되기 때문:

// FeatureA (Interface만 앎)
class FeatureA {
    let service: BlockUserService  // Interface 타입

    init(service: BlockUserService) {
        self.service = service
    }
}

// App (구현체만 생성해서 넘김)
let impl = BlockUserManager.shared  // 구현체
let feature = FeatureA(service: impl)  // 그냥 넘기기
// → Swift가 자동으로 프로토콜로 업캐스팅

10. Adapter 패턴의 실제 용도: Unit Test

Adapter 패턴은 증분 빌드 이득이 아니라 테스트 용이성을 위한 것:

현재 구조 (테스트 어려움)

public final class BlockUserManager: BlockUserService {
    public func blockUser(...) {
        // 하드코딩 → 테스트 시 진짜 API 호출됨
        let result = await ChatSDKCompat.shared.blockUser(memberNo)
    }
}

Adapter 적용 후 (테스트 가능)

// Protocol
protocol ChatSDKServiceProtocol {
    func blockUser(_ memberNo: String) async -> Result<Void, Error>
}

// 주입받는 구조
public final class BlockUserManager: BlockUserService {
    private let chatSDK: ChatSDKServiceProtocol

    public init(chatSDK: ChatSDKServiceProtocol) {
        self.chatSDK = chatSDK
    }

    public func blockUser(...) {
        let result = await chatSDK.blockUser(memberNo)  // 주입받은 것 사용
    }
}

Mock으로 테스트하는 것

Adapter vs Interface 목적 비교

핵심 정리

• SPM 기본값은 Static - Dynamic은 명시적 지정 필요
• package 식별자 = URL 마지막 부분 또는 폴더명 (Package name 아님)
• Interface 분리 이득 = 변경 빈도 × 의존자 수 × 빌드 시간
• 외부 SPM Interface = SDK 타입 완전히 숨겨야 버전 업 시 이득
• Adapter 패턴 = 증분 빌드 X, Unit Test Mock 주입이 목적
• DIP 적용 결과 = App만 재컴파일, Feature들은 재컴파일 안 함
• Packages vs Package Dependencies = 직접 선언 vs 전이적 해결 (모두 사용 가능)