banksalad·문제뱅크샐러드 iOS 앱이 커지면서 Shared 모듈이 비대해지고 불필요한 의존성 때문에 빌드와 변경 영향 범위가 넓어졌다.
접근Shared를 Constant·SwiftExtension·DIContainer 등으로 쪼개고 Data 레이어의 인터페이스를 DataInterface 모듈로 분리해 의존성 역전 원칙을 적용했다.
결과Live Activity 같은 신규 기능을 최소 의존성으로 만들 수 있게 됐고 다른 엔지니어와 충돌이 거의 없었으며 추후 gRPC·캐싱 도입 대비 구조가 마련됐다.
LINE Engineering·문제대규모 iOS 설정 화면을 모든 종류의 UI 요소(텍스트 / 스위치 / 링크 / i18n) 와 함께 다루기 어렵다.
접근Swift AttributedString 구조로 설정 항목 모델을 통합. 텍스트와 인터랙티브 요소를 한 모델로 표현해 일관된 렌더링/다국어 처리 가능하게.
결과설정 화면이 단일 데이터 모델로 통합돼 유지보수가 쉬워졌다. 새 설정 추가 시 코드 변경 최소화.
스포카·문제Kotlin Multiplatform (KMP) + Compose Multiplatform (CMP) 이 프로덕션 환경에서 정말 쓸 만한지 의문이 많다.
접근스포카 키친보드 앱을 KMP/CMP 로 마이그레이션. iOS/Android 코드 공유율, 빌드 시간, 디버깅 경험, native 통합 시 마주친 함정까지 솔직 리뷰.
결과부분 영역에서 KMP 가 충분히 production-ready. 단점 영역(특히 iOS 디버깅) 도 명확히 식별.
당근·문제당근 숏폼팀의 모듈이 200MB 까지 커져 빌드 시간 / 메인 APK 사이즈가 문제가 됐다.
접근Android Dynamic Feature Module (DFM) 로 숏폼 기능을 on-demand 로 분리. 사용자가 진입할 때만 다운로드.
결과메인 APK 사이즈 감소 + 빌드 시간 단축. 팀 단위 코드 소유권도 명확해짐.