29cm·문제주 1회 배포 주기에서 Android UI 자동화의 실패율이 높아 유지보수 비용이 컸다. UI 경로 변경, Webview 핸들러 잔존, 파이프라인 타이밍 문제가 서로 얽혀 원인 파악이 어려웠다.
접근변경된 ID와 경로값을 개발팀과 함께 정비하고, 시나리오별로 케이스를 분리한 뒤 종료 시점에 앱을 재실행해 Webview 핸들러 히스토리를 비웠다. 화면 전환에는 명시적 대기를 넣고 로컬·STF·파이프라인의 다층 검증을 거치도록 했다.
결과초기 대비 fail률이 현저히 낮아졌고, 자동화가 다시 신뢰할 수 있는 회귀 도구로 자리를 잡았다.
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 사이즈 감소 + 빌드 시간 단축. 팀 단위 코드 소유권도 명확해짐.