모바일 환경 LLM 적용 검토와 한계 분석

사이드 프로젝트가 망했다…

• 말 그대로 처참하게 망했다.
• 현실적인 문제로 개발에 실패했고, 그 과정을 정리하며 회고해보려 한다.

만들려던 앱의 개요

누나가 임신성 당뇨를 겪고 있다. 특정 음식을 먹으면 공복 혈당과 식후 2시간 혈당을 비교했을 때, 어떤 재료(성분)가 들어간 음식에서 유독 혈당이 크게 치솟는 경우가 있었다.
그래서 그 “문제 재료”는 피하고, 혈당 관리에 도움이 되는 음식들을 기반으로 LLM이 레시피를 추천/생성해주는 혈당관리 앱을 만들려고 했다.

처음엔 단순히 LLM API를 호출하면 개발도 편하고 답변 품질도 좋을 거라 생각했다. 그리고 앱을 마켓에 올린 뒤 구글 애드(Ad)로 수익화하는 그림을 그렸다.

하지만 곧 현실적인 한계가 보였다.

• API 방식은 운영비(토큰 비용) 가 계속 발생한다.
• 단순 API 호출은 내가 하고 싶은 모델 파인튜닝 + 서비스와는 거리가 멀다.
• 내 상황에서 금전적인 부담을 감당하기 어렵다는 결론에 가까워졌다.

그래서 “서버를 직접 운영하지 않아도 되는” Firebase(BaaS) 를 기반으로 가볍게 만들고 싶었다.

진행 과정

1) 모델 후보 선정

모델 후보는 크게 두 가지였다.

1. EXAONE-3.5-2.4B: 한국어 답변 품질이 좋다.
2. Qwen2.5 계열: 경량화 옵션이 다양하다.

2) 구조적 제약을 뒤늦게 인지

문제는, 내가 서버를 운영하지 않는 구조(Firebase 중심)에서는 튜닝한 sLLM을 서버에서 직접 돌리기 어렵다는 점이었다.
(서버를 따로 두자니 다시 운영비/관리 부담이 생긴다.)

그때 요즘 광고에서 흔히 보이는 문구가 떠올랐다.

“휴대폰에서 AI를 사용하세요.”

그래서 방향을 틀었다.

• “그렇다면 모델을 더 경량화해서 'On-device LLM' 으로 돌리면 되지 않을까?”
• 목표: 모바일 기기에서 로컬 추론이 가능한지 검증해보기

치명적인 문제

1) 로컬 테스트부터 이미 느렸다

최종 모델은 “로컬 기기에서 먼저 돌려보고 결정하자”로 정했다.

• 먼저 EXAONE-3.5-2.4B 를 로컬에서 테스트했다.
  “2.4B면 그래도 금방 나오겠지”라고 생각했는데, 응답이 30분 이상 걸렸다.
  → 이 속도면 모바일에서 돌리는 건 사실상 불가능하다고 판단했다.

그래서 더 경량화된 옵션이 있는 Qwen2.5-1.5B-Instruct 를 선택했다.

• Qwen2.5-1.5B도 로컬 테스트에서 답변까지 약 10분이 걸렸다.
  → 지금 생각하면 여기서 멈췄어야 했다.

2) 모바일 실험: 앱이 그냥 죽었다

그래도 “혹시 몰라서” 실제로 '앱 + 모델 탑재 형태'로 설치해서 실행해봤다.

결과는 단순했다.

• 앱이 그냥 종료(크래시) 해버렸다.

성능/속도 문제가 아니라, '메모리/리소스/런타임' 안정성 단계에서 이미 버티지 못했다.
즉, “돌아가긴 하는데 느리다” 수준이 아니라 실행 자체가 성립하지 않는 환경이었다.

배운 점

• 아무리 경량화된 모델이라도, 현재의 모바일 기기에서 LLM을 제대로 돌리는 건 아직 무리라는 걸 몸으로 배웠다.
  관련 연구도 이미 존재했다: 논문 링크
• 개발에서 자주 하던 “일단 만들고 보자” 방식이, 이런 문제에서는 오히려 시간을 크게 낭비하게 만든다.
  다음부터는:
  • 선행 연구/사례/벤치마크를 먼저 확인하고
  • 실행 가능성을 검증한 뒤
  • 설계를 시작하는 편이 훨씬 효율적이라는 걸 느꼈다.
• On-device를 전제로 하지 않고, 비용을 통제할 수 있는 방향부터 먼저 설계할 것 (예: 레시피 생성은 서버에서, 앱은 캐싱/프롬프트 최소화/사용량 제한 등)
• 또는 LLM을 “생성”이 아니라 검색+요약(RAG) 기반의 제한된 답변으로 축소해서 리스크를 낮출 것