1년간 진행한 iOS 모듈화 여정

2024년 한 해 동안 iOS 모듈화를 본격적으로 진행하면서, 단순히 코드를 쪼개는 것보다 의존성을 먼저 정리하고 영향 범위를 줄이는 일 이 더 중요하다는 점을 체감했다. 처음에는 단일 프로젝트에서 피처 모듈로 옮기기 위해 빈 모듈을 만들고 파일을 이동했지만, 생각보다 코드 결합도가 높아 완전한 분리가 쉽지 않았다.

초기 목표 구조는 Core / UI / Features 3개 레이어였다. Core에는 공통 로직과 모델, 레포지토리를 두고, UI에는 재사용 가능한 컴포넌트와 리소스를, Features에는 기능 단위의 독립 모듈을 배치하려 했다. 그런데 실제로는 피처 모듈을 독립적으로 분리하려면 먼저 모델과 레포지토리의 의존 관계를 정리해야 했고, 그 결과 이들을 ZCore 로 먼저 옮기는 전략을 택했다.

대규모 이동은 안정성 측면에서 부담이 컸다. 특히 모델을 한꺼번에 ZCore 로 옮기면서 변경 파일 수가 급증했고, 각 사용처에 import ZCore 를 추가해야 했으며, 예상하지 못한 의존성 문제도 드러났다. 대신 이런 과정을 통해 구조가 정리됐고, 이후 다른 파일을 분리하는 작업은 한결 수월해졌다.

다음에는 더 작은 단위로 나눠 진행하는 방식이 더 적절하다고 정리했다.

• 하나의 피처나 특정 화면에서만 쓰는 모델부터 순차적으로 이동
• 공용 모델은 먼저 ZCore와 앱 모듈에 중복 선언해 기존 코드 영향 최소화
• 다음 업데이트에서 중복 모델을 정리하며 점진적으로 완전 분리

아쉬웠던 점도 분명했다. 모듈 네이밍 규칙을 초반에 정하지 않아 ZigZagCore, ZigZagUI, MarketingLogger, Utils처럼 이름이 제각각이 됐고, 나중에 Z prefix로 통일하는 과정에서 런타임 크래시 가 발생했다. 원인은 ZUI 모듈에 남아 있던 레거시 xib 파일의 Inspector 설정이 이전 모듈명을 그대로 참조하고 있었기 때문이었고, 코드 검색만으로는 이 설정이 바뀌지 않았다.

또 다른 고민은 앱 실행 시간(App Launch Time) 이었다. 초기 모듈들은 대부분 Core Layer에 속해 Dynamic Framework 로 구성될 수밖에 없었고, 그 수가 늘면서 실행 시간이 길어지는 문제가 보였다. 현재는 일부 모듈을 static으로 바꾸거나, Dynamic framework로 쓰던 CocoaPod 을 SPM 으로 바꾸는 방식으로 개선을 실험하고 있다.

모듈을 나누다 보니 역할 경계가 애매한 코드도 드러났다. 예를 들어 UserAccountInitType 같은 모델은 ZCore에 두는 것이 자연스럽지만, localizedName 처럼 문자열 리소스를 참조하는 확장 로직은 ZResource에 속한다고도 볼 수 있어, 모듈 경계가 흔들리는 문제가 생겼다. 이런 경우를 처리하기 위해 extension 전용 모듈 을 두는 방안까지 고민 중이다.

결국 얻은 교훈은 세 가지로 정리된다.

• 작게 시작하고 점진적으로 확장할 것
• 모듈의 역할과 의존성을 명확히 정의할 것
• 항상 영향 범위를 최소화하며 안정성을 우선할 것

2024년의 모듈화는 쉽지 않았지만, 구조를 정리하는 방법과 피해야 할 실수를 함께 배운 시간이었다. 앞으로는 코드 결합도를 더 세밀하게 풀어가며, 모듈화를 한 단계씩 확장해 나갈 계획이다.