[모듈화 3편] 우리의 최종 모듈화 (feat. Multiple Project)
반갑습니다 ! Memorial House의 집주인 효준 & 영현 입니다.
지난 편에서 Library와 Framework의 차이와 Dynamic Library vs Static Library에 대해 알아보았고,
본 편에서는 어떻게 저희 팀이 모듈화를 진행했는지 작성해보겠습니다 !!
총 3편의 시리즈로 구성되어 있습니다..!
그럼 레쯔고 〰️
- 우리 프로젝트에 클린 아키텍처를 도입했음
- 4명의 팀원이 협업하는 과정에서 모듈화를 도입하여 클린 아키텍처의 각 계층을 잘 관리할 수 있게끔 하고자 함
- Clean Architecture를 도입하여 Layer 간의 분리가 필요했다.
- 디렉토리로 구분하지 않고, 모듈로 각 Layer를 분리하여 접근 제어자를 활용한 강한 제약을 하고자 했다.
- 모듈화를 함으모써 특정 모듈만 빌드시켜 빠른 빌드 속도의 장점을 얻고자 했다.
우리가 생각해본 모듈화의 4가지 방법이다.
- Single Project에 Multi Target
- Multi Project에 Multi & Single Target
- XCFrameworks
- Swift Package
우선 우리 팀원 4명 중 2명은 모듈화 경험이 있고, 2명은 경험이 없다.
3번과 4번의 경우 우리의 프로젝트가 오픈소스 혹은 다른 곳에서도 재활용될 필요성이 있다면 고려했겠지만, 그렇지 않으므로 우리 프로젝트에는 적절하지 않은 방법이라고 판단했다.
1번의 경우 우리 팀의 모듈화 결정 이유 중 특정 모듈만 빌드함으로써 얻을 수 있는 빠른 빌드 속도라는 장점을 얻을 수 없었다.
따라서 프로젝트 단위로 모듈을 분리하고 각각의 모듈들을 WorkSpace로 묶어주었다.
필요에 따라서 각 모듈에서 Interface, Test가 필요한 경우 타겟을 따로 두어 멀티 프로젝트에서 타겟을 유동적으로 관리하고자 했다.
Multi Project를 활용하여 모듈화를 진행하면 merge를 하는 과정에서 모든 모듈의 pbxproj 파일이 감지되기 때문에 conflict가 매우 많이 발생한다는 단점이 있다.
이때 Tuist라는 서드파티 라이브러리를 활용하면 더욱 편하게 Multi Project 단위의 모듈화를 팀 프로젝트에 활용할 수 있었다.
하지만 Tuist를 경험해본 팀원은 1명 뿐이었으며 2명은 모듈화의 경험이 전무했기 때문에 처음부터 Tuist를 사용하면 프로젝트 단위로 모듈화를 했을 때 여러 설정들 (앞서 알아본 Dynamic Library나 Embed 설정 등)을 직접 경험해보지 못할 것이라 판단하였다.
conflict는 많이 발생하겠지만 이를 해결하는 과정에서 더 깊이있는 학습이 가능할 것이라는 의견이 있었다.
추가로 우리 팀은 Third-Party 라이브러리는 최대한 지양하자는 룰이 있었기 때문에 Tuist는 도입하지 않는 방향으로 결정이 났다.
결론적으로 우리 팀은 Tuist를 사용하지 않고 Project 단위의 모듈화 방법을 채택하게 되었다.
우리 프로젝트는 각각의 모듈을 다음과 같이 분리했다.
MH는 Memorial House의 약어이다 ^0^
- 앱의 첫 시작점(AppDelegate와 SceneDelegate 등)을 담당하는 MHApplication 모듈
- Executable File
- 앱의 전반적인 Core(DIContainer)를 담당하는 MHCore 모듈
- Dynamic Library
- 애플의 Foundation 모듈을 상속하여 우리 프로젝트 전반적인 Foundation의 extension을 정의하는 MHFoundation 모듈
- Dynamic Library
- 앱의 UI를 담당하는 MHPresentation 모듈
- Static Library
- 네트워킹 혹은 Local DB에서 데이터를 불러올 수 있는 MHData 모듈
- Static Library
- 앱의 비즈니스 로직을 담당하는 MHDomain 모듈
- Dynamic Library
https://medium.com/@showcove/library-framework-%EA%B7%B8%EB%A6%AC%EA%B3%A0-xcframework-15387031964b