4 분 소요

온디바이스 AI 앱에서 모델 파일 관리 전략: 다운로드, 캐시, 업데이트, 롤백까지

온디바이스 AI 기능을 앱에 붙이기 시작하면 가장 먼저 신나는 건 데모가 돌아가는 순간이다. 그런데 그 다음부터는 갑자기 현실적인 문제가 몰려온다. 모델 파일이 너무 크고, 앱 번들에 같이 넣기에는 스토어 배포 부담이 커지고, 첫 실행 다운로드는 이탈률을 올릴 수 있다. 게다가 모델이 한 번 배포된 뒤에는 업데이트, 호환성, 롤백까지 고민해야 한다.

작은 PoC 단계에서는 “일단 모델 파일 하나 앱에 넣자”로 끝나지만, 실제 서비스로 가면 그 접근이 금방 한계에 부딪힌다. 이 글은 모바일 앱에서 LLM, 음성, 비전 모델 같은 온디바이스 AI 모델 파일을 어떻게 관리할지를 실무 관점에서 정리한 메모다. Android와 iOS 모두에 적용할 수 있는 원칙 위주로 적었다.

왜 모델 파일 관리가 중요한가

온디바이스 AI는 서버 호출이 줄고 응답성이 좋아지는 장점이 있지만, 그 대가로 모델 파일 배포를 앱이 책임져야 한다. 일반적인 이미지 asset이나 설정 JSON보다 훨씬 무겁고, 잘못 관리하면 아래 문제가 바로 생긴다.

  • 앱 설치 용량 증가
  • 첫 실행 지연
  • 네트워크 상태에 따른 기능 불안정
  • 구버전 앱과 신버전 모델의 호환성 깨짐
  • 잘못된 모델 배포 시 대규모 장애

특히 “모델만 바꾸면 되겠지”라는 감각으로 접근하면 위험하다. 앱 코드, 토크나이저, 전처리/후처리 로직, 양자화 방식, 디바이스 성능 제한이 다 얽혀 있기 때문이다.

배포 방식은 세 가지로 나뉜다

1) 앱 번들에 포함

가장 단순한 방식이다. 앱 설치와 동시에 모델이 들어가 있으니 첫 실행 시 바로 동작한다. 오프라인 친화적이고 QA 재현성도 높다.

하지만 단점도 명확하다.

  • 앱 용량이 크게 늘어난다
  • 모델 교체를 위해 앱 업데이트가 필요하다
  • 여러 모델 변형을 넣기 어렵다

데모나 완전 오프라인 기능에는 적합하지만, 서비스 운영 측면에서는 유연성이 떨어진다.

2) 첫 실행 후 다운로드

앱 본체는 가볍게 두고, 기능 진입 시점이나 온보딩 후 모델을 내려받는 방식이다. 운영 유연성은 좋아지지만, UX 설계가 중요하다.

이 방식에서 흔히 생기는 문제는 아래다.

  • 사용자가 다운로드 중간에 이탈
  • 셀룰러 환경에서 다운로드 실패/지연
  • 저장 공간 부족으로 실패
  • 앱 종료 후 부분 다운로드 상태 관리가 애매함

그래서 단순 progress bar 하나보다 재시도, 중단 복구, Wi‑Fi 정책, 저장공간 체크가 필요하다.

3) 하이브리드

핵심 경량 모델은 번들에 넣고, 고품질 모델이나 언어별 모델은 나중에 내려받는 방식이다. 개인적으로는 가장 현실적인 타협점이라고 본다. 기본 경험은 보장하면서도 확장성을 가져갈 수 있기 때문이다.

추천하는 디렉터리 전략

모델 파일은 그냥 documents 폴더에 던져 넣으면 나중에 반드시 꼬인다. 최소한 아래 단위는 분리하는 편이 좋다.

  • bundled/ : 앱에 포함된 기본 모델
  • downloaded/ : 서버에서 내려받은 모델
  • staging/ : 검증 전 임시 다운로드 파일
  • metadata/ : 버전, 해시, 호환 앱 버전, 활성 모델 정보

핵심은 활성 모델 포인터와 실제 파일을 분리하는 것이다. 파일을 직접 덮어쓰지 말고, 새 모델을 staging에 받은 뒤 검증 후 atomically 전환하는 편이 훨씬 안전하다.

예시 메타데이터는 이런 식이면 충분하다.

{
  "activeModelId": "ko-llm-q4-v3",
  "models": [
    {
      "id": "ko-llm-q4-v3",
      "version": "3.0.0",
      "sha256": "...",
      "minAppVersion": "2.4.0",
      "status": "ready"
    }
  ]
}

업데이트는 다운로드보다 검증이 중요하다

모델 파일 업데이트에서 진짜 중요한 건 “받았는가”보다 “써도 되는가”다. 최소한 아래 검증은 자동으로 거쳐야 한다.

  1. 파일 크기 확인
  2. 해시 검증
  3. 압축 해제 성공 여부
  4. 런타임 로딩 테스트
  5. 앱 버전 호환성 체크
  6. 디스크 여유 공간 재확인

이 과정을 거치지 않고 활성 모델을 바로 바꾸면, 다운로드는 성공했는데 추론 시점에만 터지는 나쁜 장애가 생긴다.

롤백 설계를 처음부터 넣어야 하는 이유

모델은 코드보다 롤백이 더 중요할 때가 있다. 코드 버그는 앱 업데이트로 잡을 수 있지만, 모델 품질 저하나 특정 디바이스 OOM 문제는 더 넓게 터질 수 있다. 그래서 활성 모델을 바꿀 때는 이전 안정 버전을 쉽게 되돌릴 수 있어야 한다.

내가 선호하는 방식은 아래다.

  • 항상 마지막 정상 모델 1개는 유지
  • 새 모델은 candidate 상태로 다운로드
  • 첫 로딩/짧은 self-test 통과 후 active 전환
  • 실패하면 자동으로 이전 모델 복귀

이렇게 하면 잘못된 모델이 와도 앱 자체가 망가지지 않는다.

모바일에서 자주 놓치는 포인트

저장 공간 부족

대형 모델은 압축본과 해제본이 동시에 필요할 수 있다. 1GB 파일 하나 받는다고 1GB만 필요한 게 아니다. 임시 공간까지 고려해야 한다.

백그라운드 다운로드 정책

iOS와 Android는 백그라운드 작업 제약이 다르다. 장시간 다운로드를 너무 낙관적으로 설계하면 앱 생명주기 때문에 끊긴다.

모델과 토크나이저 버전 불일치

특히 LLM 계열은 모델만 바꾸는 게 아니라 tokenizer, special token, prompt template까지 같이 맞아야 한다. 이게 어긋나면 성능 저하가 아니라 아예 이상 출력이 난다.

디바이스별 성능 편차

같은 모델이라도 메모리 6GB 기기와 12GB 기기 체감이 완전히 다르다. 모델 선택 정책에 디바이스 capability를 넣지 않으면 불필요한 불만이 생긴다.

추천 운영 원칙

1) 모델 파일은 버전드 artifact로 다룬다

파일 이름을 model.bin처럼 두지 말고, 식별 가능한 버전과 해시를 갖게 해야 한다. 그래야 캐시, 롤백, 장애 대응이 쉬워진다.

2) 코드와 모델의 호환성 매트릭스를 가진다

모델 배포 서버에는 최소 앱 버전, 지원 디바이스 조건, 필요한 토크나이저 버전이 같이 있어야 한다. “최신 모델 내려주기”만 하면 언젠가 사고 난다.

3) 첫 실행 경험을 너무 무겁게 만들지 않는다

온디바이스 AI를 자랑하고 싶어서 첫 화면에서 대형 모델을 바로 받게 하면 이탈률이 올라간다. 기능 진입 시점까지 미루거나, 경량 모델로 먼저 시작하고 고성능 모델은 선택 다운로드로 두는 편이 현실적이다.

4) 관측 가능성을 넣는다

최소한 아래 이벤트는 수집하는 편이 좋다.

  • 다운로드 시작/완료/실패
  • 해시 검증 실패
  • 모델 로드 실패
  • OOM 또는 추론 초기화 실패
  • 롤백 발생 여부

온디바이스라고 해서 서버 관측이 필요 없는 게 아니다. 오히려 파일 배포형 기능은 telemetry가 더 중요하다.

간단한 체크리스트

  • 번들 포함, 다운로드, 하이브리드 중 어떤 전략인지 명확하다
  • 모델 파일용 staging/active 구조가 분리되어 있다
  • 해시 검증과 런타임 로딩 테스트가 있다
  • 마지막 정상 버전으로 롤백 가능하다
  • 저장 공간 부족과 생명주기 중단을 고려했다
  • 모델-토크나이저-앱 버전 호환성 정보를 관리한다
  • 다운로드/실패/롤백 telemetry가 있다

마무리

온디바이스 AI 앱에서 어려운 건 모델을 한 번 넣는 일이 아니라, 계속 안전하게 운영하는 일이다. 초기 데모 단계에서는 배포 방식이 대수롭지 않아 보여도, 사용자 수가 붙고 모델 업데이트 주기가 빨라지면 파일 관리 전략이 곧 제품 안정성을 좌우한다. 내 경험상 가장 중요한 건 화려한 배포 기술보다도 검증 가능한 업데이트 흐름과 즉시 복귀 가능한 롤백 구조다. 모델도 결국 운영되는 artifact라는 감각을 놓치지 않는 편이 오래 간다.

댓글남기기