banksalad·문제모바일 앱은 배포 후 되돌리기 어렵고 스토어 심사에 시간이 들며 강제 업데이트도 쉽지 않다. 뱅크샐러드는 이 제약 아래서 일관된 품질로 매주 배포해야 했다.
접근develop/release 브랜치를 분리하고 release에는 cherry-pick으로만 핫픽스를 넣는다. GitHub Actions와 자체 Mac 빌드 시스템으로 자동화 테스트를 돌리고, 사용자 5%부터 점진 출시하며 미완성 기능은 Feature Flag로 막는다.
결과개발 1주, 자동화 테스트 주말, Release QA 1주, 점진 배포 2일의 루틴이 자리잡았다. 개인 역량이 아닌 프로세스로 품질이 유지되면서 대규모 리팩토링도 안정적으로 배포할 수 있게 됐다.
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 사이즈 감소 + 빌드 시간 단축. 팀 단위 코드 소유권도 명확해짐.