Static Framework
스태틱 프레임워크는 정적 라이브러리(.a) 와 리소스를 묶은 형태에요.
컴파일 타임 시점에 실행 파일 안에 코드 자체가 복사되어 포함돼요.
링크 방식
- 컴파일 시점에 라이브러리 코드가 앱 바이너리에 합쳐져요. (Static Linking)
장점은 뭐에요?
- 앱 실행속도가 빨라요
앱이 뜰때 별도의 로딩 과정이 없다보니 다이나믹 방식보다 실행이 약간 더 빨라요. - 최적화되어 있어요.
컴파일러가 앱 전체 코드를 보고 사용하지 않는 코드를 제거(Dead code stripping) 하기 유리해요.
단점은 뭐에요?
- 코드 중복이 있어요.
여러 타겟(앱, Extension 등)에서 동일한 스태틱 프레임워크를 쓰면 각 타겟마다 코드가 복사되어 앱 전체 용량이 커져요. - 빌드시간이 느려요.
코드가 수정될 때마다 전체 앱을 다시 링크해야 하므로 빌드 시간이 늘어날 수 있어요.
Dynamic Framework
다이나믹 프레임워크는 실행 파일에 포함되지 않고, 앱이 실행될 때(Runtime) 메모리에 로드돼요. Swift로 만든 프레임워크는 기본적으로 이 방식을 많이 사용해요.
링크 방식
실행 파일에는 라이브러리의 위치 정보(Reference) 만 담고, 필요할 때 로드해요.
장점은 뭐에요?
- 공유 메모리를 사용해요.
여러 타겟이 하나의 다이나믹 프레임워크를 공유해서 사용하므로, 전체 앱 번들 용량을 줄일 수 있어요. - 모듈화하기 유리해요.
기능별로 분리하기 좋으며, 코드 수정 시 해당 프레임워크만 다시 빌드하면 되는 경우가 많아 대규모 프로젝트에 유리해요.
단점은 뭐에요?
- 실행속도(Cold Start)가 느려요
앱이 처음 켜질 때 프레임워크를 찾고 연결하는 과정(dyld)이 필요해서, 너무 많아지면 앱 런칭 속도가 느려져요. (Apple은 6개 이하를 권장했으나, 최신 하드웨어에서는 더 늘어나도 무방해요.)
한눈에 비교하기
| 구분 | Static Framework | Dynamic Framework |
|---|---|---|
| 연결 시점 | 컴파일 타임 (Static Link) | 런타임 (Dynamic Link) |
| 파일 포함 | 앱 실행 파일 내부에 포함 | 앱 번들 내 별도 폴더에 존재 |
| 런칭 속도 | 빠름 | 상대적으로 느림 (오버헤드 발생) |
| 메모리/용량 | 중복 포함 가능성 있음 | 효율적인 공유 가능 |
| Swift 호환성 | Swift 3.0 이전엔 제약이 있었으나 현재는 완벽 지원 | Swift의 기본 표준 방식 |
Swift에서는 무엇을 써야 할까?
과거 Swift 초기에는 ABI(Application Binary Interface) 안정화 문제로 다이나믹 프레임워크가 필수적이었지만, 지금은 상황에 따라 선택해요.
- 작은 규모의 라이브러리
앱 실행 속도를 위해 Static을 권장해요. - 여러 타겟(App + WatchApp + Extension)이 공유하는 모듈
용량 최적화를 위해 Dynamic이 유리해요. - SPM
기본적으로.automatic설정을 사용하면 Xcode가 상황에 맞게 최적의 방식을 결정해줘요.
팁
프로젝트가 커지면서 앱 런칭 속도가 느려진다면 DYLD_PRINT_STATICS 환경 변수를 켜서 프레임워크 로딩에 시간이 얼마나 걸리는지 체크할 수 있어요.
iOS 정복중인 Tabber 입니다.