pile·
모바일·카카오 스타일 (지그재그)카카오 스타일 (지그재그)·

1년동안의 iOS 모듈화 진행기

지그재그 앱개발팀이 2024년 한 해 동안 진행한 iOS 모듈화를 돌아본 글이다. 모듈화의 필요성을 다루는 글이 많으니 대신 진행하면서 느낀 점과 아쉬웠던 것을 정리했다고 밝힌다. 성공적인 결과로 이어진 과정이 아니라 그 속에 어떤 어려움과 도전이 있었는지를 공유하는 데 초점이 있다.

핵심 포인트
  • 빈 껍데기 형태의 피처 모듈을 먼저 만들고 관련 파일을 옮겨보려 했지만, 코드 간 의존성이 강하게 얽혀 있어 완전히 독립적으로 분리하기 어려웠다.
  • 그래서 피처 모듈을 분리하려면 먼저 의존성을 정리하는 것이 선행되어야 한다는 결론을 내렸다.
  • 원칙적으로 피처가 쓰는 모델과 레포지토리는 그 피처 모듈 안에 있어야 하지만, 실제 진행 과정에서 별도 모듈로 분리할 필요가 생겼다.
  • 모델과 레포지토리를 Core 레이어로 먼저 옮기면 의존성을 미리 분리할 수 있고 나중에 피처 모듈로 옮길 때도 큰 문제가 없을 것으로 판단했다.
  • 이미 많은 사용자가 있는 서비스라 앱 업데이트에서 가장 중요하게 본 것은 안정성이었고, 기술 과제로 인한 버그 발생을 최소화해야 했다.
상세 정리
  • 시작 시점: 2023년 초부터 논의해 오던 모듈화를 2024년에 본격적으로 진행했고 지금도 작업을 이어가고 있다.
  • 목표 구조: 처음에는 단일 프로젝트로만 구성된 상태였고, 지금은 피처 모듈들을 원활하게 분리하기 위한 기반 모듈들이 어느 정도 구성된 상태다.
  • Core 레이어의 정의: 앱 전반적으로 사용되는 공통 로직과 모델, 레포지토리를 담는다.
  • 첫 번째 도전으로 모델과 레포지토리의 분리를 꼽으며, Core 레이어에 그 둘이 포함된 것이 원칙과 어긋나 보일 수 있다는 점을 스스로 짚는다.
  • 접근 방식의 전환: 처음의 껍데기 모듈 접근이 막힌 뒤, 의존성이 비교적 적은 코드부터 점진적으로 분리하는 방법을 고민했다.
  • 1년을 되돌아보니 생각보다 많은 작업을 진행했다는 소회를 밝힌다.
왜 읽나단일 프로젝트로 시작한 iOS 앱을 모듈화하려는 팀에게, 피처부터 떼어내려다 막히는 지점과 의존성을 먼저 정리하는 우회 경로를 실제 판단과 함께 보여준다.
카카오 스타일 (지그재그)
카카오 스타일 (지그재그) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 모바일·당근당근 테크블로그·

    웹뷰 다음의 레일을 깔다: 당근이 Lynx를 선택한 이유

    당근 프론트엔드코어팀이 WebView 기반 화면의 첫 프레임 렌더링 문제를 해결하기 위해 Lynx를 도입한 기록이다. 레퍼런스가 거의 없는 기술을 코드베이스 직접 분석으로 검증한 뒤 프로덕션에 적용했고, 1.9백만 사용자 A/B에서 Android 18%, iOS 37%의 첫 프레임 단축을 달성했다.

    요약 이어보기
    #cross-platform#webview#mobile-performance+2
  2. 모바일·토스 SLASH토스 SLASH·

    토스의 디바이스 팜 만들기

    토스가 각 팀이 각자 운영하던 작은 디바이스 팜을 하나의 중앙 플랫폼 '네뷸라(Nebula)'로 통합한 과정을 다룬다. Appium 대신 자체 드라이버를 개발해 클릭 13.5배, 텍스트 입력 10배의 성능을 달성했고, Android와 iOS 미러링도 직접 내재화해 실기기 원격 조작과 화면 실시간 공유를 동시에 가능하게 만들었다. 현재 100대를 넘어 수백 대를 향해 24시간 가동 중이다.

    요약 이어보기
    #android#ios#appium+2