[Android] 온디바이스 AI 개발기 - 5편: 한계 실험기 (요약 / 분류 / 번역 직접 비교)
설치하고 돌려봤다. 잘 되는 것도 있고, 쓰기 어려운 것도 있다.
이 글은
1~4편에서 왜 온디바이스인지, 어떤 엔진을 쓰는지, 세팅은 어떻게 하는지를 정리했다. 이번엔 실제로 여러 태스크를 돌려보면서 1B 모델의 현실적인 한계를 정리한다.
모델: gemma3-1b-it-int4 (int4 양자화)
기기: Snapdragon 8 Elite, GPU 백엔드
실험 방식
각 태스크에 동일한 프롬프트를 5회 반복 실행해서 결과를 비교했다. 평가 기준은 단순하다.
- 쓸 만함: 결과를 그대로 혹은 약간 다듬어서 쓸 수 있는 수준
- 아쉬움: 방향은 맞지만 품질이 들쑥날쑥하거나 손봐야 할 게 많음
- 어려움: 결과를 신뢰하기 어렵거나 의도와 다른 결과가 자주 나옴
1. 짧은 텍스트 요약 ✅ 쓸 만함
프롬프트 예시
1
2
3
다음 내용을 2~3문장으로 요약해줘.
[200자 내외 텍스트]
결과
핵심을 잘 잡는다. 200자 이내 텍스트라면 5번 중 4~5번은 쓸 만한 결과가 나왔다. 문장 자체도 자연스러운 편이다.
특히 중요한 것만 추려줘 류의 단순 필터링 작업은 1B 모델도 잘 처리한다. 정보를 새로 만드는 게 아니라 줄이는 작업이기 때문인 것 같다.
한계: 300자가 넘어가면서 품질이 흔들리기 시작한다. 길수록 중요한 부분을 빠뜨리거나, 요약인데 원문을 그대로 반복하는 경우가 생긴다.
2. 이진 분류 ✅ 쓸 만함
프롬프트 예시
1
2
3
4
다음 텍스트가 업무 관련 내용인지 아닌지 판단해줘.
"업무"또는 "비업무" 중 하나만 답해줘.
[텍스트]
결과
단순 분류는 꽤 잘 된다. 특히 답변 형식을 엄격하게 지정하면(하나만 답해줘, 예/아니오로만 답해줘) 지시를 잘 따른다.
중요/스팸, 긍정/부정 같은 이진 분류 태스크에서는 꽤 신뢰할 만한 결과가 나왔다.
한계: 경계가 모호한 케이스에서는 판단이 들쑥날쑥하다. 반쯤 업무 관련인 내용은 실행마다 다른 결과가 나오기도 했다. 이런 케이스는 규칙 기반으로 보완하는 게 낫다.
3. 카테고리 분류 (다중) 🤔 아쉬움
프롬프트 예시
1
2
3
4
다음 텍스트를 아래 카테고리 중 하나로 분류해줘.
카테고리: 공지, 업무요청, 미팅, 청구서, 뉴스레터, 기타
[텍스트]
결과
카테고리가 3~4개일 때는 나쁘지 않다. 그런데 5개 이상이 되면 덜 명확한 카테고리끼리 혼동이 생긴다.
업무요청과 미팅을 섞거나, 명백한 뉴스레터를 공지로 분류하는 경우가 있었다. 정확도가 70~80% 수준이라 프로덕션에 그대로 쓰기엔 부족하다.
대안: 1B 모델로 1차 분류 후 신뢰도가 낮은 케이스는 규칙 기반으로 재처리하는 하이브리드 방식이 현실적이다.
4. 짧은 답장 초안 🤔 아쉬움
프롬프트 예시
1
2
3
다음 메시지에 대한 짧은 답장 초안을 작성해줘. 2~3문장 이내로.
[수신 메시지]
결과
형식은 맞는데 내용이 밋밋하다. 확인했습니다. 검토 후 답변 드리겠습니다. 수준의 무난한 답변이 주로 나온다.
발신자 톤에 맞추거나 맥락을 파악한 답변은 기대하기 어렵다. 1B 모델의 맥락 이해 능력에 한계가 있다.
그래도 쓸 수 있는 경우: 수신 확인 또는 일정 조율 같이 정형화된 답변이 필요한 경우는 쓸 만하다. 창의적인 답변이 필요한 상황은 어렵다.
5. 한국어 번역 ❌ 어려움
프롬프트 예시
1
2
3
다음 영어 문장을 한국어로 번역해줘.
[영어 텍스트]
결과
단어 수준 번역은 되지만 문장 자연스러움이 많이 부족하다. 직역 느낌이 강하고, 한국어 어순이나 어미 처리가 어색한 경우가 많다.
비즈니스 문서나 공식적인 텍스트는 특히 품질이 낮다. DeepL, Papago 수준은 물론이고 일반적인 서버 AI 대비도 품질 차이가 크다.
결론: 번역은 온디바이스 1B 모델로는 무리다. 번역이 핵심 기능이라면 서버 API를 쓰는 게 맞다.
6. 긴 텍스트 분석 ❌ 어려움
프롬프트 예시
1
2
3
다음 문서에서 핵심 액션 아이템을 추출해줘.
[1000자 이상 텍스트]
결과
컨텍스트가 길어질수록 품질이 급격히 떨어진다. 앞부분 내용에 집중하고 뒷부분을 놓치거나, 없는 내용을 만들어내는(환각) 경우도 나왔다.
gemma3-1b-it-int4의 최대 토큰이 제한적이기도 하고, 1B 모델 자체의 긴 컨텍스트 처리 능력에 한계가 있다.
태스크별 정리
| 태스크 | 평가 | 비고 |
|---|---|---|
| 짧은 텍스트 요약 (200자 이내) | ✅ 쓸 만함 | 핵심 필터링에 적합 |
| 이진 분류 | ✅ 쓸 만함 | 형식 지정 엄격하게 |
| 다중 카테고리 분류 | 🤔 아쉬움 | 규칙 기반 보완 필요 |
| 짧은 답장 초안 | 🤔 아쉬움 | 정형화된 답변만 |
| 번역 | ❌ 어려움 | 서버 API 권장 |
| 긴 텍스트 분석 | ❌ 어려움 | 컨텍스트 한계 명확 |
결론
1B 모델은 짧고 단순한 작업에서 빛을 발한다. 요약, 이진 분류처럼 있는 정보를 걸러내는 작업은 꽤 쓸 만하다.
반면 생성, 번역, 긴 컨텍스트 처리는 한계가 명확하다. 이런 작업을 온디바이스로 하려면 모델 크기를 키워야 하는데, 그러면 기기 제약이 다시 발목을 잡는다.
온디바이스 1B 모델을 쓸 때 현실적인 전략은:
- 단순 작업은 온디바이스로 처리 (속도, 프라이버시 이점)
- 복잡한 작업은 서버 AI로 (품질이 중요할 때)
- 규칙 기반과 혼합 (AI 결과의 신뢰도가 낮은 케이스를 보완)
다음 편에서는 모델을 앱에 어떻게 배포하는지를 다룬다. Play Asset Delivery로 1GB 모델을 런타임에 제공하는 방법이다.
6편 - Play Asset Delivery로 모델 배포하기 에서 계속