[Android] 온디바이스 AI 삽질기 - 1편: AI를 모르는 안드로이드 개발자가 LLM에 손댄 이유
ML도 모르고, 파이썬도 어색한데 LLM을 파인튜닝해보겠다고 나선 이야기
시작하기 전에
이 시리즈는 AI/ML 전문가가 쓰는 글이 아니다.
안드로이드 앱만 만들던 개발자가 온디바이스 AI 기능을 앱에 붙여보자는 목표 하나로 시작해서, Claude AI agent와 함께 삽질하며 배운 내용을 정리한 기록이다.
정확한 이론보다 이렇게 하면 되더라, 이건 안 되더라 에 집중한다.
왜 시작했나
앱에 AI 기능을 붙이고 싶었다. 구체적으로는 텍스트 요약 기능이었다.
처음엔 당연히 Claude API, Gemini API를 쓰려 했다. 호출 한 번으로 해결되니까. 그런데 몇 가지 문제가 있었다.
첫째, 데이터를 서버로 보내는 게 꺼려졌다. 사용자의 개인적인 텍스트를 외부 서버로 전송하는 것 자체가 민감한 문제다.
둘째, 비용. 사용자가 많아지면 토큰 비용이 선형으로 늘어난다.
셋째, 속도. 아무리 빠른 API도 네트워크 RTT가 있다. 온디바이스면 그게 없다.
그래서 찾아보다가 온디바이스 LLM이라는 게 생각보다 많이 발전해 있다는 걸 알게 됐다. 그럼 기기 안에서 직접 돌리면 되는 거 아닌가, 라는 단순한 생각으로 시작했다.
문제: AI를 모른다
시작하자마자 벽에 부딪혔다.
파인튜닝, QLoRA, LoRA 어댑터, safetensors, 양자화… 단어 자체를 몰랐다. 파이썬은 간단한 스크립트 정도는 읽을 수 있지만, ML 코드는 완전히 다른 세계였다.
그래서 선택한 방법이 Claude를 AI agent처럼 쓰는 것이었다. 개념을 물어보고, 코드를 받아서 돌려보고, 에러가 나면 에러를 그대로 붙여넣고, 다시 고쳐서 돌리는 방식으로 진행했다.
돌이켜보면 이게 맞는 방향이었다. AI를 공부해서 만드는 게 아니라, AI와 함께 만드는 방식으로.
첫 번째 결정: 어떤 모델을 쓸까
온디바이스에서 돌릴 수 있는 모델 크기는 제한적이다. 기기 RAM과 다운로드 용량을 고려하면 현실적인 선택지는 1~3B 파라미터 모델이다.
후보들을 검토했다.
KoT5 계열 — 선행 테스트에서 한국어 요약 품질이 가장 좋았다. 그런데 라이선스 문제로 상업적 사용이 불가능했다. 탈락.
Llama 3.2 1B — MediaPipe 공식 지원, 4bit 양자화 시 ~700MB. 괜찮아 보였다. 그런데 한국어 학습 데이터가 부족해서 한국어 처리 성능이 낮았다.
Gemma 3 4B — 한국어 성능은 좋은데 4bit 양자화 후에도 2GB 이상. 용량 제약에 걸렸다.
커뮤니티 한국어 파인튜닝 모델 — kenonix/gemma-3-ko-1B-full 같은 것들이 있었다. 그런데 어떤 데이터로 학습됐는지 알 수 없어서 그 위에 추가 학습을 했을 때 결과를 예측하기 어려웠다. 제외.
결론은 google/gemma-3-1b-it.
| 항목 | 내용 |
|---|---|
| 파라미터 | 1B |
| 크기 (4bit 양자화) | ~529MB |
| 라이선스 | 상업적 이용 가능 |
| 한국어 지원 | 140개 언어, Gemini 토크나이저 |
구글 공식 모델이라 안드로이드 친화적이고, 라이선스가 명확하고, 용량이 1GB 이내였다. 베이스 모델의 신뢰성도 중요했다 — 알 수 없는 커뮤니티 모델보다 공식 베이스에서 직접 학습하는 게 품질 통제에 유리하다.
두 번째 결정: 파인튜닝을 왜 하는가
베이스 모델(gemma-3-1b-it)은 이미 한국어를 안다. 그런데 우리가 원하는 방식으로 답하게 하려면 추가 학습이 필요하다.
비즈니스 텍스트를 2~3문장으로 중립 서술체로 요약해줘 — 이걸 프롬프트만으로 1B 모델에게 시키면 결과가 들쑥날쑥하다. 어떤 때는 잘 되고, 어떤 때는 엉뚱한 걸 뱉는다.
파인튜닝을 하면 이 모델은 비즈니스 문서를 이렇게 요약하는 모델이다, 라고 특화시킬 수 있다.
학습 전략은 2단계로 잡았다.
1
2
3
4
5
Phase 1: 한국어 요약 능력 강화
→ 뉴스 데이터로 한국어 텍스트를 요약하는 법 학습
Phase 2: 비즈니스 문서 도메인 적응
→ 합성 데이터로 비즈니스 말투, 구조, 맥락 학습
뉴스 데이터를 먼저 쓰는 이유는 문법이 정확하고 구조가 명확해서 요약 능력 기초를 다지기 좋기 때문이다. 요약 자체를 제대로 못 배운 상태에서 도메인 적응을 시도하면 효과가 반감된다.
여기서부터 본격 삽질
모델도 정했고 전략도 세웠다. 이제 실제로 학습을 돌려야 한다.
그런데 문제가 있었다. 학습 환경이 없었다. 파이썬 ML 라이브러리들, GPU 메모리, CUDA… 노트북으로는 무리였다.
그리고 데이터 문제도 있었다. 실제 사용자 데이터는 개인정보 문제로 쓸 수 없다. 학습 데이터를 어떻게 만들 것인가.
다음 편에서 이 두 가지를 어떻게 해결했는지 정리한다.
2편 - 학습 데이터는 어디서? Claude로 5만건 합성 데이터 만들기 에서 계속
