Tuist 학습 Q&A 정리

1. pbxproj 파일

Q: pbxproj는 XML 파일인가?

아니요. OpenStep plist 형식 (NeXTSTEP 시대 유산)

Q: pbxproj가 Git 충돌이 잦은 이유?

1. 객체 ID가 랜덤 해시값

2. 파일 하나 추가 시 여러 섹션 변경

3. Xcode 버전마다 정렬 순서 다름

Q: pbxproj는 언제 생겼나?

P = Project, B = Builder, X = Xcode (또는 NeXTSTEP의 X)

2. Workspace, Project, Target 관계

Q: project.pbxproj가 "핵심 설정 파일"이란 무슨 의미?

Q: .xcodeproj vs .xcworkspace 차이?

Q: 여러 프로젝트 = 여러 타겟?

아니요, 다른 개념.

Q: 타겟의 "빌드 결과물이 하나"란?

Q: 프로젝트 빌드하면 모든 타겟이 빌드되나?

아니요. 프로젝트가 아니라 Scheme을 빌드하는 것.

3. Scheme (스킴)

Q: Scheme이 뭐야?

"어떤 타겟을, 어떤 설정으로, 어떻게 실행할지" 정의한 것

Q: 왜 Scheme이 여러 개 필요한가?

같은 타겟, 다른 설정으로 실행하기 위해:

Q: Scheme vs Target 차이?

4. Configuration (빌드 설정)

Q: Configuration이 뭐야?

"어떤 옵션으로 컴파일할지" 미리 정의한 설정 묶음

Q: 커스텀 Configuration 예시?

코드에서 분기:

Q: 전체 구조 정리?

5. dSYM과 빌드 스크립트

Q: dSYM이 뭐야?

Debug Symbol 파일 = 메모리 주소 ↔ 코드 위치 매핑

dSYM 없이:

dSYM 있으면:

Q: dSYM 업로드는 런타임에 하나?

아니요. 빌드 타임에 함.

모든 게 빌드 타임 안에서 일어남 (런타임 아님)

Q: dSYM 업로드 흐름?

Q: 빌드 스크립트 종류?

6. dyld와 Dynamic Framework 로딩

Q: 앱 실행 시 dyld가 미리 코드를 읽어오는가?

Static Framework (정적):

Dynamic Framework (동적):

Q: 실제로 코드를 "읽어오는" 시점은?

7. Symbol Table vs .swiftmodule

Q: Symbol Table이 뭐야?

함수 이름 ↔ 주소 매핑 (링커/디버거용)

용도:

• 링커: 다른 모듈에서 호출 시 주소 연결
• 디버거: 크래시 주소 → 함수 이름 변환 (dSYM)

Q: .swiftmodule이 뭐야?

모듈의 공개 인터페이스 (컴파일러용)

용도:

• 컴파일러: import 시 타입 체크, 자동완성
• 함수 시그니처, 제네릭 정보, 프로토콜 준수 등

Q: Symbol Table vs .swiftmodule 비교?

Q: 전체 흐름은?

8. dyld의 정확한 역할

Q: dyld가 런타임에 함수이름과 주소를 매핑하는 건가?

아니요. dyld는 이미 있는 Symbol Table을 보고 실제 메모리 주소로 연결해주는 것.

Static Framework (dyld 관여 안 함)

Dynamic Framework (dyld가 처리)

그림으로 정리

핵심 비교

9. Tuist의 SPM 통합 & 캐싱 (2026-06-20)

SPM 통합 — "패키지가 아니라 sub project/framework로"

Xcode 기본은 SPM 패키지를 native package로 통합(Xcode 내부 블랙박스). Tuist는 다르게, 각 SPM 패키지를 별도 Xcode 프로젝트/framework 타겟으로 생성해 의존하게 만든다.

왜? Tuist가 빌드를 통제해야 ① 바이너리 캐싱을 외부 의존성에도 적용하고 ② 내 모듈도 외부도 framework로 일관 관리할 수 있기 때문.

SPM도 타겟으로 관리한다 (Tuist만의 개념 아님)

SPM도 Package.swift에 target이 있다 (Package > Product > Target). 차이는 SPM=라이브러리 빌드 모델(표현력 제한) vs Tuist=Xcode 프로젝트 생성 모델(풀 표현력: 앱·확장·스킴·설정). 둘 다 타겟 단위.

⭐ 증분 빌드 vs 바이너리 캐시 — 다른 층위

SPM/Xcode도 증분 빌드는 한다(바뀐 모듈만 재컴파일, DerivedData 재사용). 그런데 그건 Tuist 바이너리 캐시와 다르다.

→ 일상 개발(DerivedData 유지)에선 SPM 증분 빌드로 충분. Tuist 바이너리 캐시가 빛나는 건 클린 빌드·CI·새 머신·팀 공유처럼 증분 캐시가 무력화되는 상황이다.

⚠️ 용어: DerivedData 재사용을 "바이너리 캐싱"이라 부르면 어폐. 그건 증분 빌드 캐시이고, "바이너리 캐시"는 해시 기반·영속·공유형(Tuist/Bazel)을 지칭. SPM은 binaryTarget(XCFramework 의존)은 지원하지만 자동 바이너리 캐시 시스템은 없다.

로컬 vs 원격 캐시 — 서버 필요 여부

공유는 git이 아니라 별도 캐시 스토리지로(바이너리를 git에 커밋 X). CI는 Jenkins 같은 도구로 매번 클린 빌드 → 느린데, 원격 캐시를 붙이면 미리 빌드된 framework를 받아 가속. (CI = 자주 통합+자동 빌드·테스트 관행 / Jenkins = 그걸 실행하는 도구)

⚠️ 흔한 오해: "Tuist + SPM = 항상 xcframework?"

아니다. tuist cache를 실행해야만 xcframework로 저장된다.

즉, Tuist를 쓴다고 자동으로 바이너리 캐시가 생기는 게 아니라, tuist cache 명령을 명시적으로 실행해야 SPM 의존성이 xcframework로 미리 빌드되어 저장된다.

관련 문서

컴파일·링킹·심볼·static/dynamic·중복 Q&A · Tuist 완벽 가이드

10. 빌드 결과물 · 캐시 · Framework 위치 Q&A (2026-06-29)

Q. 컴파일 결과물은 어디에 저장?

DerivedData에 저장됨:

~/Library/Developer/Xcode/DerivedData/
└── MyApp-xxxxx/
    └── Build/Products/
        ├── Debug-iphonesimulator/
        │   ├── Alamofire.framework   ← 의존성 빌드 결과
        │   └── MyApp.app             ← 앱 빌드 결과
        └── Release-iphoneos/

타겟 단위로 관리 — 각 타겟이 각자의 빌드 결과물 생성.

Q. DerivedData 삭제해도 컴파일 결과물 유지?

❌ 아니다. DerivedData 삭제 → 컴파일 결과물 전부 삭제 → 처음부터 다시 빌드.

Q. SourcePackages/artifacts vs checkouts 차이?

Q. Tuist/Dependencies/에 Package.swift만 있는데?

실제 소스 코드는 여기 없음!

• Tuist/Dependencies/SwiftPackageManager/ — 의존성 목록 정의
• Tuist/Dependencies/Lockfiles/ — 버전 고정 (Package.resolved)
• tuist install 시 소스는 별도 위치에 다운로드 (.build/ 또는 시스템 캐시)

Q. tuist cache는 항상 xcframework로 복원?

✅ 맞다. tuist cache는 의존성을 xcframework로 미리 빌드해서 저장. 복원 시 xcframework 그대로 연결 (재컴파일 X).

Q. Debug-iphoneos/ 폴더에 Static/Dynamic 둘 다 있나?

✅ 맞다. 빌드 결과 폴더에는 타입 상관없이 모든 .framework가 존재.

구분 방법:

file SomeLib.framework/SomeLib
# Static:  "current ar archive"
# Dynamic: "Mach-O 64-bit dynamically linked shared library"

Q. .app/Frameworks/에 있는 것 = Dynamic만?

✅ 맞다.

Debug-iphoneos/
├── StaticA.framework      ← Static
├── DynamicB.framework     ← Dynamic
└── MyApp.app/
    ├── MyApp              ← 실행파일 (StaticA 코드 포함)
    └── Frameworks/
        └── DynamicB.framework  ← Dynamic만 여기로

Q. Static Framework는 앱 실행 파일에 포함?

✅ 맞다. Static은 링킹 시 앱 실행 파일에 코드가 복사됨. Dynamic은 .app/Frameworks/에 별도 파일로 존재.

11. 심화 Q&A — DerivedData · checkouts · artifacts · tuist cache (2026-06-29)

Q. DerivedData 폴더명이 MStove-abcdef123 이상한 이유?

해시값 = 프로젝트 경로 기반. 같은 이름 프로젝트 충돌 방지용.

~/Projects/AppA/MStove.xcodeproj → MStove-abc123/
~/Projects/AppB/MStove.xcodeproj → MStove-def456/

Q. checkouts은 항상 SPM 소스코드만?

✅ 맞다. SPM 의존성의 git에서 클론한 소스 코드만 저장.

Q. artifacts는 Xcode가 빌드한 결과물?

❌ 아니다. artifacts는 이미 빌드된 상태로 배포되는 바이너리 (binaryTarget).

Q. tuist install은 소스를 어디에 저장?

SourcePackages/checkouts 아님. Tuist는 자체 경로 사용:

~/.tuist/Dependencies/  또는
프로젝트/.build/checkouts/

Q. tuist cache 기준, 저장 위치, static/dynamic은?

기준: 프로젝트 의존성 그래프에서 캐시 가능한 모든 타겟.

저장 위치:

~/.tuist/Cache/
└── [hash]/
    ├── Alamofire.xcframework
    └── RxSwift.xcframework

static/dynamic: xcframework는 "컨테이너"일 뿐 — 안에 static 또는 dynamic 담을 수 있음. Tuist 설정에서 선택 가능.

Q. .framework가 Static/Dynamic 둘 다 될 수 있나?

✅ 맞다.

file MyLib.framework/MyLib
# Static:  "current ar archive random library"
# Dynamic: "Mach-O 64-bit dynamically linked shared library"

Q. Library vs Framework 차이?

Library (.a):
  libMyLib.a  ← .o 파일들 묶은 아카이브

Framework (.framework):
  MyLib.framework/
  ├── MyLib         ← 바이너리 (static/dynamic)
  ├── Headers/      ← 헤더 파일
  ├── Modules/      ← Swift module
  ├── Resources/    ← 이미지, xib 등
  └── Info.plist    ← 메타데이터

요약: Framework = Library + 헤더 + 리소스 + 메타데이터 (구조화된 번들)

12. Package.swift 심화 Q&A — Target · Product · binaryTarget (2026-06-29)

Q. 1 Product = 1 Target = 1 Module?

기본적으로 맞다. 단, 1 Product가 여러 Target을 묶을 수도 있다:

.library(
    name: "MyProduct",
    targets: ["TargetA", "TargetB"]  // ← 2개 타겟 묶음
)

이 경우 import MyProduct하면 TargetA, TargetB 코드 둘 다 사용 가능.

Q. binaryTarget을 왜 만드나? 패키지 내 타겟끼리 의존 가능?

소스 코드 없이 xcframework만 있을 때 binaryTarget을 쓴다:

.binaryTarget(
    name: "SGSAuthGoogle",
    path: "SGSSDK/SGSAuthGoogle.xcframework"  // 로컬 xcframework
)

같은 패키지 내 타겟끼리 의존 가능:

targets: [
    .target(
        name: "MStoveSDKWrapper",
        dependencies: ["SGSAuthGoogle"]  // ← 같은 패키지의 binaryTarget
    ),
    .binaryTarget(name: "SGSAuthGoogle", path: "..."),
]

Q. .zip 하나에 xcframework 여러 개?

1 zip = 1 xcframework. 하지만 전이 의존성이 풀리면서 여러 개 생긴다:

artifacts/에 생기는 것들:
├── SGSAuthGoogle.xcframework        ← 직접 선언
├── GoogleSignIn.xcframework         ← SGSAuthGoogle이 의존
├── GTMSessionFetcher.xcframework    ← GoogleSignIn이 의존
└── AppAuth.xcframework              ← 전이 의존성

Q. xcframework를 패키지로 감싸서 배포하는 이유?

직접 binaryTarget도 가능하지만, 버전 관리를 위해 패키지로 감싼다:

Q. dependencies에서 문자열 vs .product() 차이?

dependencies: [
    "MStoveSDKWrapperInterface",              // 같은 패키지 내 타겟
    .product(name: "SGSBase", package: "base"), // 다른 패키지, 이름 다름
    "SGSAuthGoogle",                          // 같은 패키지 내 binaryTarget
]

Q. 외부 패키지도 이름 같으면 문자열만 가능?

조건부로 가능. SPM이 추론할 수 있을 때만:

// 패키지명 = 프로덕트명 같으면
.package(url: ".../Alamofire", from: "5.0.0")
dependencies: ["Alamofire"]  // ✅ 가능

// 패키지명 ≠ 프로덕트명 다르면
.package(url: ".../auth-line", exact: "2.9.0")  // 패키지명: auth-line
// 프로덕트명: SGSAuthLine (다름!)
dependencies: [
    "SGSAuthLine"  // ❌ 안 됨
    .product(name: "SGSAuthLine", package: "auth-line")  // ✅ 필요
]

Q. binaryTarget은 Package.dependencies에 없어도 사용 가능?

✅ 가능하다. 두 가지 dependencies를 구분:

let package = Package(
    dependencies: [
        // 패키지 레벨: 외부 패키지 가져오기
        .package(url: ".../auth-line", exact: "2.9.0"),
    ],
    targets: [
        .target(
            name: "MStoveSDKWrapper",
            dependencies: [
                // 타겟 레벨: 이 타겟이 의존하는 것
                "SGSAuthGoogle",  // ← 같은 패키지 내 binaryTarget (외부 아님)
            ]
        ),
        .binaryTarget(
            name: "SGSAuthGoogle",  // ← targets 배열에서 정의
            path: "SGSSDK/SGSAuthGoogle.xcframework"
        ),
    ]
)

binaryTarget은 targets 배열에서 정의하면, 같은 패키지 내 다른 타겟이 의존 가능.

Q. auth-google 주석인데 binaryTarget은 어떻게 사용?

// 주석 처리됨 (원격 패키지 안 씀)
// .package(url: "https://.../auth-google", exact: "2.8.2"),

// 대신 로컬 xcframework 직접 사용
.binaryTarget(
    name: "SGSAuthGoogle",
    path: "SGSSDK/SGSAuthGoogle.xcframework"
)

원격 패키지 대신 로컬 xcframework를 직접 사용. 이유: 버전 충돌, 커스텀 빌드, 빌드 속도 등.

Q. 원격 패키지 binaryTarget vs 로컬 binaryTarget 차이?

SGSPush (원격 패키지 경유):
┌─────────────────────────────────────────────┐
│ MStoveSDKWrapper/Package.swift              │
│   dependencies: [.package(url: ".../push")] │
│                      ↓                      │
│   push 패키지의 Package.swift               │
│     targets: [.binaryTarget(url: "...zip")] │
│                      ↓                      │
│   원격에서 SGSPush.xcframework.zip 다운로드  │
└─────────────────────────────────────────────┘

SGSAuthGoogle (로컬 직접 참조):
┌─────────────────────────────────────────────┐
│ MStoveSDKWrapper/Package.swift              │
│   targets: [.binaryTarget(path: "SGSSDK/")] │
│                      ↓                      │
│   로컬 SGSAuthGoogle.xcframework 직접 사용  │
└─────────────────────────────────────────────┘

Q. 앱에 포함되는 건 xcframework? framework?

xcframework 안에 있는 framework. xcframework는 컨테이너일 뿐:

SGSPush.xcframework/              ← 컨테이너 (빌드 후 사라짐)
├── ios-arm64/
│   └── SGSPush.framework/        ← 실제로 사용되는 것
│       └── SGSPush (바이너리)
├── ios-arm64_x86_64-simulator/
│   └── SGSPush.framework/
└── Info.plist

Static인 경우

빌드:
1. xcframework에서 현재 플랫폼 framework 선택
2. framework 코드 → 앱 실행파일에 복사 (링킹)

결과:
MyApp.app/
└── MyApp  ← SGSPush 코드가 여기 포함됨

(xcframework, framework 파일 자체는 앱에 없음)

Dynamic인 경우

빌드:
1. xcframework에서 현재 플랫폼 framework 선택
2. framework → .app/Frameworks/에 복사

결과:
MyApp.app/
├── MyApp  ← "SGSPush 필요해" 참조만
└── Frameworks/
    └── SGSPush.framework/  ← framework가 복사됨 (xcframework 아님!)

런타임:
dyld가 SGSPush.framework 로드

Q. 버전 충돌 시 왜 하나만 포함돼?

framework 파일 이름이 같아서. 타겟 이름 때문이 아님:

.app/Frameworks/
└── base.framework/    ← 폴더 이름

base 2.8.0 → base.framework
base 2.9.0 → base.framework
→ 이름 같아서 하나만 존재 가능

같은 이름 framework는 하나만 존재 → 버전 불일치 시 심볼 못 찾아 크래시.

Q. xcodeproj 변환 = 컴파일/링킹?

❌ 아니다. 완전히 다른 단계.

1. tuist install     → 의존성 다운로드
2. tuist generate    → .xcodeproj 생성 (컴파일 X)
3. xcodebuild / ⌘B   → 컴파일 + 링킹 (여기서 빌드)

Q. tuist generate하면 자동으로 tuist cache 실행?

❌ 아니다. 별도 명령어.

cache 없이 generate:
  Alamofire → 소스 타겟 → 빌드 시 컴파일

cache 사용:
  tuist cache → ~/.tuist/Cache/에 Alamofire.xcframework
  tuist generate → xcframework 연결 → 컴파일 스킵

Q. tuist cache의 xcframework, 빌드하면 Static/Dynamic 어디로?

xcframework도 빌드(링킹) 시 Static/Dynamic 규칙 그대로 적용:

tuist cache 저장:
~/.tuist/Cache/
├── Alamofire.xcframework/     ← 안에 static 바이너리
└── RxSwift.xcframework/       ← 안에 dynamic 바이너리

빌드 (⌘B) 후:
MyApp.app/
├── MyApp                      ← 실행 파일 (Alamofire 코드 포함됨)
└── Frameworks/
    └── RxSwift.framework/     ← Dynamic만 여기로 복사

xcframework는 "컨테이너"일 뿐 — 안에 static이면 실행 파일에, dynamic이면 Frameworks/에. tuist cache든 소스 컴파일이든 이 규칙은 동일.

13. tuist generate 흐름 심화 Q&A (2026-06-29)

Q. cache 있으면 tuist install 안 해도 돼?

❌ 아니다. install과 cache는 다른 단계:

캐시는 "다운로드"가 아니라 "컴파일"을 스킵하는 것.

Q. "소스 타겟으로 프로젝트 생성"이 무슨 말?

tuist generate가 의존성을 어떻게 참조하느냐의 차이:

캐시 없이 generate:
MyApp.xcworkspace
├── MyApp.xcodeproj
│   └── Targets: MyApp
├── Alamofire.xcodeproj         ← 별도 프로젝트
│   └── Targets: Alamofire      ← Xcode Target (소스 컴파일 필요)
└── RxSwift.xcodeproj
    └── Targets: RxSwift        ← Xcode Target (소스 컴파일 필요)

캐시 있으면 generate:
MyApp.xcodeproj                 ← 프로젝트 하나
└── Targets: MyApp
    └── Link Binary: Alamofire.xcframework, RxSwift.xcframework

"소스 타겟" = 의존성마다 Xcode Target이 생성되어 빌드 시 소스 컴파일 필요

Q. tuist generate가 컴파일도 해?

❌ 안 한다. generate는 프로젝트 파일만 생성:

Q. "Link Binary With Libraries"가 뭐야?

Xcode Build Phases의 한 단계. 링커에게 "이 라이브러리들과 연결해라"고 지정하는 곳:

Build Phases (타겟 → Build Phases 탭):
├── Dependencies
├── Compile Sources           ← .swift → .o 컴파일
├── Link Binary With Libraries ← 여기! 링크할 라이브러리 지정
├── Copy Bundle Resources     ← 리소스 복사
└── Embed Frameworks          ← Dynamic Framework 앱에 포함

빌드 흐름에서의 역할:

1. Compile Sources
   .swift → .o (오브젝트 파일)

2. Link Binary With Libraries  ← 여기
   .o + 라이브러리들 → 실행 파일
   "Alamofire의 함수 주소 연결해줘"

3. Embed Frameworks (Dynamic만)
   Dynamic Framework를 .app/Frameworks/에 복사

Q. Xcode 프로젝트의 Frameworks는 Dynamic만?

❌ 아니다. 두 가지 "Frameworks"를 구분해야 함:

Xcode 프로젝트 (빌드 설정):
└── Link Binary With Libraries:
    ├── Alamofire.xcframework  ← Static도 여기 참조
    └── RxSwift.xcframework    ← Dynamic도 여기 참조

빌드 후 .app:
MyApp.app/
├── MyApp                      ← Static은 여기에 포함
└── Frameworks/                ← Dynamic만 여기에 복사
    └── RxSwift.framework

Q. 의존성 있으면 xcworkspace가 무조건 생겨?

❌ 항상은 아니다.

여러 프로젝트가 필요하면 workspace, 하나면 project만.

14. Tuist Project.swift vs SPM Package.swift (2026-06-29)

Q. Project.swift와 Package.swift 차이?

Q. packages:에 로컬/원격 패키지 둘 다 가능?

✅ 둘 다 가능.

// Tuist Project.swift
packages: [
    .local(path: "../Packages/MStoveBaseUtil"),        // 로컬 SPM 패키지
    .remote(url: "https://github.com/Alamofire", ...), // 원격 SPM 패키지
]

// SPM Package.swift
dependencies: [
    .package(path: "../MStoveBaseUtil"),               // 로컬
    .package(url: "https://github.com/Alamofire", ...), // 원격
]

Q. .package(product:)는 패키지? 프로덕트?

프로덕트를 사용하겠다는 것. 패키지 ≠ 프로덕트:

packages: [
    .local(path: "../MStoveBaseUtil"),  // ← 패키지 선언
]

targets: [
    Target(
        dependencies: [
            .package(product: "MStoveBaseUtil"),  // ← 패키지의 "프로덕트" 사용
        ]
    )
]

• 패키지 = 컨테이너 (Package.swift 가진 폴더)
• 프로덕트 = 패키지가 외부에 노출하는 것 (library, executable)

Q. .package(product:)는 "외부 패키지" 전용?

❌ "외부"가 아니라 "packages:에 선언된 패키지" 전용. 로컬이든 원격이든:

packages: [
    .local(path: "../MStoveBaseUtil"),     // 로컬 패키지
    .remote(url: "https://...", ...),      // 원격 패키지
]

// 둘 다 .package(product:)로 사용
dependencies: [
    .package(product: "MStoveBaseUtil"),   // 로컬이든
    .package(product: "Alamofire"),        // 원격이든
]

Q. Tuist 의존성 종류 정리

Q. import는 Product? Module?

Module을 import한다. Product가 아니라:

Package
└── Product (외부 노출용)
    └── Target (빌드 단위)
        └── Module (import 대상)

// 의존성 선언 (Product 이름)
.package(product: "SGSAuth")

// 코드에서 사용 (Module 이름 = Target 이름)
import SGSAuth

보통 Product 이름 = Target 이름 = Module 이름이라 헷갈리지만, 실제 import하는 건 Module.

Q. 의존성 그래프가 뭐야?

누가 누구를 의존하는지 관계를 파악하는 것:

MStoveSDKWrapper
├── MStoveBaseUtil
├── SGSAuth
│   ├── SGSBase        ← SGSAuth가 의존
│   └── SGSLog
└── SGSPush
    └── SGSBase        ← 중복 (한 번만 빌드)

용도: 빌드 순서 결정, 중복 제거, 버전 충돌 감지

Q. Tuist/Package.swift vs Project.swift packages 차이?

// Tuist/Package.swift — 외부 의존성
dependencies: [
    .package(url: "https://github.com/Alamofire/Alamofire", ...),
]

// Project.swift packages: — 내부 모듈
packages: [
    .local(path: "App/MStoveBaseUI"),
    .local(path: "Feature/MStoveV3Home"),
]

// Target dependencies에서
dependencies: [
    .external(name: "Alamofire"),           // ← Tuist/Package.swift
    .package(product: "MStoveBaseUI"),      // ← 로컬 패키지
]

Q. productTypes가 뭐야?

외부 의존성의 Static/Dynamic을 결정:

// Tuist/Package.swift
let packageSettings = PackageSettings(
    productTypes: [
        "Alamofire": .staticFramework,      // Static으로 빌드
        "LineSDK": .framework,              // Dynamic으로 빌드
        "FirebaseAnalytics": .staticFramework,
    ]
)

이 설정 없으면 Tuist가 기본값으로 결정.

Q. "소스 타겟" vs "xcframework 연결" 차이?

캐시 없을 때 (소스 타겟):
MyApp.xcworkspace/
├── MyApp.xcodeproj
├── Alamofire.xcodeproj    ← 소스 타겟 (컴파일 필요)
│   └── Sources/*.swift
└── RxSwift.xcodeproj      ← 소스 타겟 (컴파일 필요)
    └── Sources/*.swift
→ ⌘B 하면 Alamofire, RxSwift 소스 전부 컴파일

캐시 있을 때 (xcframework 연결):
MyApp.xcodeproj/
└── Link:
    ├── Alamofire.xcframework   ← 미리 빌드됨
    └── RxSwift.xcframework     ← 미리 빌드됨
→ ⌘B 하면 링킹만 (컴파일 스킵)

"소스 타겟" = 소스 코드(.swift)를 포함하는 Xcode Target. 빌드 시 컴파일 필요.

Q. 내부 모듈은 캐싱 안 해?

✅ 맞다. 내부 모듈은 항상 소스 타겟:

tuist generate 결과:

MyApp.xcworkspace/
├── Alamofire.xcframework        ← 외부 (캐시됨, 컴파일 X)
├── RxSwift.xcframework          ← 외부 (캐시됨, 컴파일 X)
│
├── MStoveV3Home.xcodeproj       ← 내부 (소스 타겟, 매번 컴파일)
│   └── Sources/*.swift
└── MStoveNetwork.xcodeproj      ← 내부 (소스 타겟, 매번 컴파일)
    └── Sources/*.swift

Q. 전체 흐름 정리

1. Tuist/Package.swift
   → 외부 의존성 URL + 버전 선언
   → productTypes로 Static/Dynamic 지정

2. tuist install
   → 외부 의존성 소스 다운로드

3. tuist cache (선택)
   → 외부 의존성을 xcframework로 빌드
   → ~/.tuist/Cache/에 저장

4. tuist generate
   → .xcodeproj 생성
   → 외부: 캐시 있으면 xcframework, 없으면 소스 타겟
   → 내부: 항상 소스 타겟

5. Target dependencies에서
   → .external(name:) = Tuist/Package.swift
   → .package(product:) = 로컬 패키지

Q. 왜 ".external()"이라고 부르나?

Project.swift 기준으로 "외부"라는 뜻:

프로젝트 구조:
├── Tuist/
│   └── Package.swift      ← Project.swift "외부"에 정의
│
└── Projects/
    └── ABCApp/
        └── Project.swift   ← 여기 기준
            └── packages:   ← Project.swift "내부"에 정의

• .external() = "Project.swift 밖 (Tuist/ 폴더)에서 정의된 것"
• .package() = "Project.swift 안 packages:에서 정의된 것"

Q. tuist install은 Project.swift packages:도 다운로드하나?

❌ 안 합니다:

// Project.swift에 원격 패키지가 있다면
packages: [
    .remote(url: "https://github.com/SomeLib/SomeLib", ...),
]

tuist install   // ← SomeLib 다운로드 안 됨
tuist generate  // ← 이때 SPM이 resolve해서 다운로드

Q. resolve가 뭐야? 언제 하나?

버전 호환성 계산 + 의존성 그래프 확정:

tuist install (Tuist/Package.swift 대상)
├── 1. Package.swift 읽기
├── 2. 버전 resolve (의존성 그래프 계산)
├── 3. 소스 다운로드 → Tuist/.build/checkouts/
└── 4. Package.resolved 생성 (버전 잠금)

tuist generate
└── Tuist/Package.swift 것들은 이미 resolve 끝남
    → 그냥 연결만

Q. 왜 Tuist/Package.swift를 권장하나?

resolve가 "느림 × 반복"이라서:

tuist generate 할 때마다 (Project.swift packages: 원격):

1. 원격 서버에 연결 (네트워크)
2. 패키지 manifest 확인 (Package.swift 읽기)
3. 버전 호환성 계산 (의존성 그래프)
4. 소스 다운로드 (없거나 변경 시)
5. .xcodeproj 생성

→ 매번 1~4 체크해야 함

결론: 한 번 resolve/build 해두고 재사용 → Tuist/Package.swift + cache 권장

15. Scheme · Configuration · dSYM (2026-06-30)

Q. Scheme 구조가 뭐야?

Scheme.scheme(
    name: "QA_ABCApp",                        // 1. 스킴 이름
    buildAction: .buildAction(targets: [...]), // 2. 빌드할 타겟
    runAction: .runAction(configuration: "Debug_Qa"),    // 3. 실행(⌘R) 시 Configuration
    archiveAction: .archiveAction(configuration: "Release_Qa") // 4. 아카이브 시 Configuration
)

┌─────────────────────────────────────────────────────────┐
│ Scheme: QA_ABCApp  ← name                               │
├─────────────────────────────────────────────────────────┤
│ Build                                                   │
│   └── Target: QA_ABCApp  ← targets                      │
├─────────────────────────────────────────────────────────┤
│ Run (⌘R)                                                │
│   └── Configuration: Debug_Qa  ← runAction              │
├─────────────────────────────────────────────────────────┤
│ Archive (배포용 빌드)                                    │
│   └── Configuration: Release_Qa ← archiveAction         │
└─────────────────────────────────────────────────────────┘

Q. Debug vs Release Configuration 차이?

// Assertions 예시
assert(user != nil, "유저 없음")
// Debug: 크래시 (버그 발견)
// Release: 이 줄 자체가 사라짐

// Optimization 예시
// Debug: 코드 그대로 실행 → 브레이크포인트 정확히 멈춤
// Release: 컴파일러가 코드 재배치 → 브레이크포인트 이상하게 멈춤

Q. 환경별 Configuration은 왜 나누나?

// Debug_Qa vs Release_Qa 공통
API_BASE_URL = "https://qa-api.example.com"

// Debug_Qa만
ENABLE_LOGGING = true
SHOW_DEBUG_MENU = true

// Release_Qa만
ENABLE_LOGGING = false
SHOW_DEBUG_MENU = false

Q. dSYM이 뭐야? Firebase Crashlytics랑 무슨 관계?

dSYM = 주소 ↔ 함수명 매핑 테이블. 크래시 로그를 읽을 수 있게 해줌:

크래시 발생 시 실제 기록:
0x1000a4f2c  ← 메모리 주소만 있음
0x1000a3b18
0x1000a2104

         ↓ dSYM으로 symbolicate

Firebase Crashlytics 표시:
UserService.swift:42  fetchUser()
LoginViewController.swift:128  loginButtonTapped()
AppDelegate.swift:31  application(_:didFinishLaunching:)

Q. dSYM 없으면 어떻게 되나?

Crashed: com.app.main
0x1000a4f2c
0x1000a3b18
→ 뭐가 문제인지 모름

Crashed: com.app.main
UserService.fetchUser():42
LoginViewController.loginButtonTapped():128
→ 어디서 터졌는지 바로 앎

Q. dSYM 흐름 정리

1. Release 빌드 시
   ├── 앱 바이너리 (주소만, 심볼 제거됨)
   └── dSYM 파일 (주소 ↔ 함수명 매핑)

2. 앱스토어 배포
   └── 앱 바이너리만 올라감

3. Firebase에 dSYM 업로드
   └── 나중에 크래시 해석용

4. 유저 크래시 발생
   └── 주소만 Firebase로 전송: "0x1000a4f2c에서 죽음"

5. Firebase가 dSYM으로 변환 (symbolicate)
   └── "UserService.swift:42 fetchUser()에서 죽음"

핵심: Release 빌드는 심볼 제거 → dSYM 별도 보관 → 크래시 시 symbolicate

16. Framework · Library · 링킹 흐름 (2026-06-30)

Q. Static/Dynamic Framework 결과물 확장자?

둘 다 .framework:

# .framework 안의 바이너리로 구분
file MyFramework.framework/MyFramework

# Static이면:
current ar archive random library

# Dynamic이면:
Mach-O 64-bit dynamically linked shared library

핵심: .framework는 껍데기(컨테이너), 안의 바이너리가 static/dynamic 결정

Q. Static vs Dynamic 앱 번들 구조?

Static:
MyApp.app/
└── MyApp  ← 실행파일 (Alamofire 코드 포함됨)

Dynamic:
MyApp.app/
├── MyApp  ← 실행파일 (참조만: "@rpath/Alamofire")
└── Frameworks/
    └── Alamofire.framework  ← 별도 파일로 존재

Q. Dynamic Framework 링킹 흐름?

1. 컴파일 타임
   └── .swiftmodule 읽음
       → 타입 체킹 ✅
       → 주소? ❌ 없음

2. 링크 타임
   └── 실행파일에 기록:
       "Alamofire.request 심볼 필요"
       "@rpath/Alamofire.framework에서 찾아라"
       → 주소? ❌ 아직 모름 (placeholder)

3. 런타임 (앱 실행)
   └── dyld가:
       1) .app/Frameworks/Alamofire.framework 로드
       2) 메모리에 올림
       3) 심볼 테이블 읽음
       4) "request" → 0x1000a4f2c 바인딩
       → 주소? ✅ 이제 알음

차이: Static은 링크 타임에 주소 확정, Dynamic은 런타임에 dyld가 바인딩

Q. ProjectDescriptionHelpers는 사용자 정의 폴더명?

❌ Tuist 공식 기능 (이름 고정):

Tuist/
├── Config.swift
├── Package.swift
└── ProjectDescriptionHelpers/   ← Tuist가 이 이름을 인식
    └── *.swift                  ← 자동으로 모듈로 만들어줌

// Tuist/ProjectDescriptionHelpers/MyHelpers.swift
public func makeAppTarget() -> Target { ... }

// Projects/MyApp/Project.swift
import ProjectDescriptionHelpers  // ← Tuist가 자동으로 import 가능하게 해줌

let project = Project(
    targets: [makeAppTarget()]
)

폴더 이름 바꾸면 Tuist가 인식 못함. 이름 고정, 내용만 사용자 정의.

Q. Tuist 의존성 문법 — .target() vs .package()?

"어디서 가져오느냐" 기준:

// Project.swift
let project = Project(
    packages: [
        .local(path: "../MyLibrary"),  // SPM 패키지
    ],
    targets: [
        Target(
            name: "MyApp",
            dependencies: [
                .target(name: "MyFramework"),     // 같은 Project.swift의 타겟
                .package(product: "MyLibrary"),  // packages:의 SPM 프로덕트
            ]
        ),
        Target(name: "MyFramework", ...),
    ]
)

핵심: SPM 패키지의 "타겟"을 직접 가져오는 건 없음. 항상 프로덕트를 통해 가져옴.

핵심 요약