pile·
최신
  1. 모바일·LINE EngineeringLINE Engineering·

    AttributedString 구조로 풀어낸 대규모 iOS 설정 시스템

    문제대규모 iOS 설정 화면을 모든 종류의 UI 요소(텍스트 / 스위치 / 링크 / i18n) 와 함께 다루기 어렵다.

    접근Swift AttributedString 구조로 설정 항목 모델을 통합. 텍스트와 인터랙티브 요소를 한 모델로 표현해 일관된 렌더링/다국어 처리 가능하게.

    결과설정 화면이 단일 데이터 모델로 통합돼 유지보수가 쉬워졌다. 새 설정 추가 시 코드 변경 최소화.

    #ios#swift#attributedstring+2
  2. 모바일·스포카스포카·

    KMP/CMP 마이그레이션, 정말 프로덕션에서 가능할까? - 키친보드 앱 마이그레이션 도전기

    문제Kotlin Multiplatform (KMP) + Compose Multiplatform (CMP) 이 프로덕션 환경에서 정말 쓸 만한지 의문이 많다.

    접근스포카 키친보드 앱을 KMP/CMP 로 마이그레이션. iOS/Android 코드 공유율, 빌드 시간, 디버깅 경험, native 통합 시 마주친 함정까지 솔직 리뷰.

    결과부분 영역에서 KMP 가 충분히 production-ready. 단점 영역(특히 iOS 디버깅) 도 명확히 식별.

    #android#ios#cross-platform+2
  3. 모바일·당근당근·

    200MB 모듈을 팀 단위로 해결하기: 당근 숏폼팀의 On-demand Dynamic Feature Module 도입

    문제당근 숏폼팀의 모듈이 200MB 까지 커져 빌드 시간 / 메인 APK 사이즈가 문제가 됐다.

    접근Android Dynamic Feature Module (DFM) 로 숏폼 기능을 on-demand 로 분리. 사용자가 진입할 때만 다운로드.

    결과메인 APK 사이즈 감소 + 빌드 시간 단축. 팀 단위 코드 소유권도 명확해짐.

    #android#dynamic-feature-module#modularization+2
  4. 모바일·쏘카쏘카·

    쏘카프레임 - 블루투스 모듈

    문제쏘카 / 일레클 / 따릉이 앱은 차량·자전거 단말과 블루투스로 직접 통신해 잠금·해제·반납을 수행한다. Android · iOS 플랫폼이 제공하는 블루투스 API 는 파편화돼 있어 서비스 도메인 요구를 그대로 표현하기 어렵다.

    접근플랫폼 블루투스 API 위에 "쏘카프레임 블루투스 모듈" 을 만들어 하드웨어 맥락을 응집된 도메인 모델로 추상화. DeviceX 의 식별·통신 규격·수행 가능 동작을 하나의 단위로 다루고 서버 통신 fallback 까지 함께 다룬다.

    결과쏘카 / 일레클 / 따릉이 피쳐가 같은 블루투스 모듈을 공유한다. 플랫폼별 차이를 도메인 계층에서 흡수해 모바일 개발자가 비즈니스 로직에 집중할 수 있다.

    #bluetooth#iot#mobile-architecture+1
  5. 모바일·쏘카쏘카·

    쏘카프레임 - 앱 프레임워크와 개발자 경험

    문제쏘카는 2019년 앱 코드를 새로 만드는 개편을 단행했다. 변화가 잦은 모바일 환경에서 생산성을 지속적으로 끌어올리려면 개발자 경험(DX) 자체가 시스템 자산이 되어야 했다.

    접근Android / iOS 네이티브 위에 동일한 추상화를 제공하는 "쏘카프레임" 앱 프레임워크를 구축. 라이브러리·예외 처리·코딩 컨벤션을 규격화해 코드 일관성을 확보하고 선택의 인지 비용을 줄인다.

    결과잉여 시간을 생산성 재투자로 돌리는 선순환을 만든다. 프레임워크가 사고 방식을 가이드해 한 사람이 짠 듯한 일관성과 실수 방지를 동시에 달성한다.

    #developer-experience#architecture#mobile-framework+1
  6. 모바일·카카오페이카카오페이·

    기기 없이 앱을 테스트하는 법, 멀티버스가 알려드립니다

    문제모바일 앱 테스트는 OS 버전·해상도별로 실제 기기가 필요하다. 기기 관리·할당 비용이 커지고, 기획자·디자이너도 테스트 환경 구축에 시간을 쓰게 된다.

    접근가상 기기 기반 macOS 앱 "멀티버스" 를 자체 개발. 맥북 한 대로 iOS / 다양한 OS 버전 / 해상도 환경에서 페이 앱을 테스트할 수 있도록 가상 기기 풀과 테스트 편의 기능을 제공한다.

    결과기기 부족·관리 비용 문제를 해소하고 개발자·기획자·디자이너가 같은 도구를 공유. 사내 테스트 플랫폼이 "동료를 고객으로 본다" 는 관점의 성공 사례가 됐다.

    #internal-platform#mobile-testing#ios+1
  7. 모바일·HyperconnectHyperconnect·

    1:1 비디오 채팅 서비스는 E2E 회귀 테스트를 어떻게 자동화할까?

    문제아자르 1:1 비디오 채팅의 회귀 테스트는 두 사용자의 실시간 상호작용을 검증해야 한다. 일반 UI 자동화로는 두 단말 간 인터랙션을 다룰 수 없어 매 버전 수동 QA 부담이 컸다.

    접근Pytest + Appium 기반으로 테스트를 Non-interaction / Interaction 두 갈래로 나눈다. Interaction 테스트는 하나의 테스트에서 2개의 driver 를 생성·동기화해 두 단말의 행동을 함께 검증. iOS↔Android 크로스 플랫폼 조합까지 커버.

    결과1:1 인터랙션이라는 도메인 특성을 자동화 범위에 포함시켰다. 반복 회귀 테스트의 수동 작업 비중을 크게 줄였다.

    #e2e-testing#appium#test-automation+1
  8. 모바일·카카오페이카카오페이·

    MapKit을 활용한 위치 기반 서비스를 개발하며 겪은 시행착오

    문제MapKit 이 한국 서비스 대응 문서 부족으로 주소 변환과 법적 attribution 표시에 어려움.

    접근5개 지도 SDK(Naver/Kakao/MapBox/OSM/MapKit) 비교 후 비용·API 호출 제한 측면에서 MapKit 선택. CLGeocoder debugDescription 으로 한국 주소 추출 + view 디버깅으로 Apple legal attribution 위치 조정.

    결과"포춘레이더" + "내 주변 혜택" 두 LBS 출시. CLPlacemark 한계(마포구 누락 등) 해결 + MKAppleLogoLabel 위치 재배치 성공.

    #ios#mapkit#corelocation+2
  9. 모바일·29CM29CM·

    SwiftLint 캐싱을 통한 Incremental Build 최적화하기

    문제모듈화된 iOS 프로젝트에서 SwiftLint 가 증분 빌드마다 전체 코드베이스를 검사해 15~30 초 빌드 시간 소비.

    접근Xcode 의 "Based on dependency analysis" 옵션 + xcfilelist + Git diff 기반 변경사항 추적 + Build Pre-actions 활용한 로컬 캐싱. CI/CD 는 danger-swift 통합.

    결과SwiftLint 소요 시간 15~30 초 → 1~2 초로 단축. CI 에서 변경 파일만 검사해 린트 오류 누적 문제 해결.

    #ci-cd#build-optimization#incremental-build+2
  10. 모바일·29CM29CM·

    Mergeable libraries 로 29% 빠르게 앱 실행하기

    문제29CM iOS 앱의 Cold Start 시간이 p50 기준 약 1.5 초로 느려 앱 시작 성능 개선 필요.

    접근Xcode 15 Mergeable Libraries 도입. Debug 는 Dynamic library 로 빌드 시간 단축, Release 는 Static library 처럼 병합해 앱 시작 시간 개선. Tuist 80 개 모듈 프로젝트에 Manual 방식 적용.

    결과Cold Start 400~500ms, Warm Start 180~250ms 개선. 버전 6.39.0 이상에서 약 29% 성능 향상.

    #ios#mergeable-libraries#app-performance+2
  11. 모바일·카카오페이카카오페이·

    사장님플러스 앱 아키텍처 전환 이후에 대하여

    문제기존 RIBs/TCA 아키텍처가 과도한 프로토콜과 객체 분리로 코드 점핑을 일으켜 신규 개발자 진입 장벽이 높았다.

    접근자체 MVVM으로 전환하고 Domain Layer를 선택적으로 두는 구조를 채택한다. 단순 호출은 Presentation이 Data Layer를 직접 접근하고, 복잡한 비즈니스 로직에만 UseCase를 도입한다. 계층은 모듈이 아닌 폴더로 시작한다.

    결과코드 가독성이 개선되고 온보딩 비용이 줄어 소규모 iOS 팀이 유연하게 리소스를 운용할 수 있게 됐다. 불필요한 추상화를 걷어내 생산성이 올라간다.