pile·
모바일·플레이키보드플레이키보드·

신입 개발자의 레거시 코드를 향한 관점 전환기

플레이키보드 iOS 주니어 개발자가 80MB 메모리 제한이 있는 키보드 익스텐션 환경에서 레거시 코드를 MVVM + Combine + DIContainer 구조로 리팩토링해 메모리를 66MB에서 26.6MB로 줄이고 안정성을 66%에서 99%로 개선한 과정을 다룬다.

핵심 포인트
  • 키보드 익스텐션 80MB 메모리 초과 시 시스템 키보드로 강제 복귀, 기능 확장 자체가 불가능한 근본 제약
  • MVVM + Combine 조합으로 아키텍처 전환, 키보드 익스텐션 제약으로 서드파티 제외 First-party 프레임워크만 사용
  • SubView별 Input/Output 스트림 분리로 Publisher 상호 의존성 제거, 비동기 상태 중첩 오류 해소
  • DIContainer로 뷰 지연 로딩 구현, 초기 로드 시 키보드 컴포넌트만 로드해 메모리 스파이크 66MB → 26.6MB 감소
  • 안정성 66% → 99% 향상, 클린 아키텍처 기반으로 향후 기능 확장 기반 마련
상세 정리
  • iOS 키보드 익스텐션은 80MB 메모리 제한이 있어 초과 시 자동으로 시스템 기본 키보드로 폴백
  • 기존 코드는 메모리 제약으로 신기능 추가가 어렵고, 레거시 유지만 반복되는 악순환
  • MVVM 선택 이유: RIBs나 Clean Architecture는 오버킬, 키보드 기능 간 뷰 구조가 유사해 MVVM이 실용적
  • Combine 선택 이유: 키보드 익스텐션에서는 서드파티 라이브러리 제약, First-party Combine으로 리액티브 구현
  • 기존 구조: SubView들이 직접 상태를 공유해 비동기 처리 중 상태 중첩 오류 발생
  • 개선 구조: 각 SubView는 독립적인 Input/Output 스트림을 가지고 MainView에서 연결, 의존성 분리
  • DIContainer의 lazy loading: 앱 시작 시 모든 뷰를 초기화하지 않고 필요 시점에 로드
  • 초기 로드를 키보드 컴포넌트만으로 제한해 pre-launch 크래시(메모리 초과) 제거
  • 메모리 66MB → 26.6MB: DIContainer lazy loading 하나로 60% 이상 감소
왜 읽나메모리나 리소스 제약이 있는 iOS 익스텐션 환경에서 레거시 아키텍처를 MVVM + Combine으로 점진적으로 전환하려는 팀에 실제 구현 전략과 메모리 최적화 성과를 제공한다.
플레이키보드
플레이키보드 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (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