1년간의 iOS 모듈화 여정 - 2. Component 모듈

피처 모듈 분리를 끝내려면 먼저 여러 지면에서 공통으로 쓰이는 UI 컴포넌트를 독립시켜야 했다. 캐러셀, 헤더 뷰, 배너처럼 얽혀 있는 컴포넌트가 많아 이 레이어를 정리하지 않으면 피처 단위 분리가 계속 막혔다.

서버 드리븐 구조에서는 앱에 어떤 컴포넌트가 있는지 한눈에 보이지 않았고, 비슷한 UI가 있는지 확인하려면 사람에게 묻거나 서버 스펙과 코드를 함께 뒤져야 했다. 그 결과 유사한 컴포넌트가 중복 생성되거나, 재사용 가능 여부를 확인하는 데도 커뮤니케이션 비용이 크게 들었다.

QA 범위도 불명확했다. 하나의 컴포넌트를 수정하면 공통 View나 헤더, 캐러셀을 공유하는 다른 컴포넌트까지 영향이 번지는 경우가 많았지만, 어떤 지면까지 확인해야 하는지 빠르게 파악하기 어려웠다.

분리는 UICollectionViewCell + CellViewModel 구조를 기준으로 진행했다. 이미 ZCore로 모델, Repository, LogService 같은 공용 의존성을 먼저 분리해 둔 덕분에, Component 모듈 작업은 관련 파일을 ZComponent로 옮기고 필요한 타입에 public을 붙인 뒤 사용처에 import ZComponent를 추가하는 흐름으로 정리할 수 있었다.

리뷰 효율을 위해 커밋도 쪼갰다.

• 의존성 정리 커밋
• 파일 이동 커밋
• public과 import 정리 커밋
• 실제 로직 변경 커밋

이렇게 나누면 Git이 rename을 잘 인식하고, 리뷰어도 이동과 진짜 로직 변경을 분리해서 볼 수 있었다.

서버 드리븐 환경의 가시성을 높이기 위해 ZComponent 데모 타겟도 만들었다. 데모앱은 서버와 독립적으로 컴포넌트만 렌더링하며, 각 컴포넌트의 모델 데이터를 JSON 케이스로 저장해 상태와 옵션 조합을 빠르게 확인하게 했다. 그 결과 iOS 개발자, 서버 개발자, 디자이너 모두가 컴포넌트 카탈로그처럼 활용할 수 있게 됐다.

마지막으로 스냅샷 테스트를 도입해 영향 범위를 시각화했다. uber/ios-snapshot-test-case와 CI/CD를 연결해 PR에서 어떤 컴포넌트가 실제로 바뀌었는지 이미지로 확인할 수 있게 만들었고, QA도 그 결과를 바로 받아볼 수 있었다.

정리하면, 이번 작업은 세 가지 문제를 풀었다. Feature 모듈 분리의 기반을 만들었고, 서버 드리븐 환경의 컴포넌트 가시성을 높였으며, QA 영향 범위를 이미지로 명확하게 공유할 수 있게 했다.