서론

「메모 앱에 AI를 도입하고 싶다」고 생각했을 때, 가장 먼저 떠오른 것은 클라우드 API였습니다. 하지만 곧바로 걸림돌이 생겼습니다.

• 메모 내용은 개인적인 정보가 많다
• 오프라인 환경에서도 동작했으면 좋겠다
• API 비용을 사용자에게 부담시키고 싶지 않다

이 세 가지를 해결할 수 있는 것이 바로 **온디바이스 LLM (On-device LLM)**입니다. 단말기 내부에서 모델이 동작하기 때문에 데이터가 서버로 전송되지 않고, 네트워크가 필요 없으며, 추가 비용도 들지 않습니다.

그래서 flutter_gemma 패키지를 사용하여, Gemma 3 1B를 온디바이스로 동작시키는 AI 메모 앱을 Claude Code로 개발했습니다. 기능 중 하나로 메모 내용에서 자동으로 태그를 생성하는 기능을 구현했는데——여기서 벽에 부딪혔습니다.

이 기사는 「성공한 이야기」가 아닙니다. 태그 생성의 정밀도가 생각보다 낮았고, 그 원인을 기술적으로 고찰한 기록입니다. 같은 과제에 부딪힌 분들에게 참고가 된다면 좋겠습니다.

앱 개요

프레임워크: Flutter -
사용 패키지: flutter_gemma

모델: Gemma 3 1B (int4 양자화) -
동작: 완전 오프라인·온디바이스 -
대상 OS: Android (iOS 대응 예정)

메모를 작성한 후 AI 버튼을 탭하면, 본문을 읽고 태그를 자동으로 생성하는 심플한 설계입니다.

태그 생성 구현

프롬프트는 대략 다음과 같은 형태입니다.

final prompt = '''
다음 메모의 내용을 읽고, 적절한 태그를 3~5개 생성해 주세요.
태그는 쉼표(comma)로 구분하여 출력해 주세요. 불필요한 설명은 필요 없습니다.
...

심플한 지시 추종 (Instruction Following) 태스크입니다. 「읽고 → 태그를 → 쉼표로 구분하여 출력한다」뿐이기에, 처음에는 「이것만으로 충분히 동작하겠지」라고 생각했습니다.

실제 동작: 기대와 현실

기대했던 동작

예를 들어 다음과 같은 메모가 있다고 가정해 봅시다.

다음 주 월요일에 상사와의 1on1이 있다.
아젠다는 ①최근 업무 보고 ②부업 신청 상담 ③다음 기수 목표 설정.
사전에 자료를 준비해 둘 것.

기대하는 태그: 업무, 1on1, 미팅, 준비, 목표 설정

……그리 정확한 태그는 나오지 않았습니다.

그 외에도:

• 태그가 1개밖에 나오지 않음
• 영어와 일본어가 혼재됨 (work, 仕事, meeting이 동시에 나옴)
• 쉼표 구분이어야 하는데 줄바꿈 구분으로 나옴
• 관계없는 부분이 태그가 됨
• 태그가 아니라 「이 메모는 〇〇에 관한 기록입니다」라는 요약문이 나옴

한마디로 말하면, 출력 포맷과 내용 모두 불안정했습니다.

고찰: 왜 정밀도가 낮은가?

여기서부터가 본론입니다. 몇 가지 가설을 세워 정리해 보겠습니다.

가설 1: 모델 사이즈의 근본적인 한계

Gemma 3 1B는 파라미터 수가 약 10억 개입니다. 스마트폰에서 구동하기 위한 모델로서는 타당한 사이즈지만, 지시 추종 (Instruction Following)의 안정성 관점에서는 7B 이상의 모델과 비교했을 때 명확히 취약한 부분이 있습니다.

「태그를 생성한다」는 태스크는 언뜻 심플해 보이지만, 사실 복합적인 능력을 요구합니다.

• 텍스트의 의미를 이해함
• 적절한 입도(Granularity)로 키워드를 추출함
• 지정된 포맷으로 출력함
• 불필요한 것을 쓰지 않음 (=네거티브 지시를 준수함)

특히 마지막인 「불필요한 것을 쓰지 않음」은 소형 모델이 가장 어려워하는 부분입니다. 대규모 모델은 방대한 RLHF (인간 피드백을 통한 강화학습)를 통해 이 능력을 연마하지만, 1B 클래스의 모델에서는 한계가 있습니다.

가설 2: 양자화에 의한 품질 저하

flutter_gemma에서 사용하는 모델은 **int4 양자화 (int4 quantization)**되어 있습니다. 양자화란 모델의 가중치를 32bit 부동 소수점에서 4bit 정수로 압축하는 기술로, 파일 크기와 계산 비용을 대폭 낮출 수 있습니다.

하지만 품질과의 트레이드오프(Trade-off)가 있습니다. 특히 세밀한 지시 해석이나 출력의 일관성에 영향을 주기 쉽다고 알려져 있습니다.

「쉼표로 구분하여 출력해 주세요」라는 단순한 형식 지정이 지켜지지 않는 것은 양자화에 의한 정밀도 저하의 영향도 생각할 수 있습니다.

가설 3: 프롬프트 설계의 문제

이것은 제 책임이기도 합니다. 현재의 프롬프트는 너무 단순할 가능성이 있습니다.

대규모 모델이라면 제로샷 (Zero-shot)으로도 작동하겠지만, 소형 모델에서는 few-shot (출력 예시 제시) 이 효과적이라고 알려져 있습니다.

# 나쁜 예 (현상)
태그를 3~5개, 쉼표로 구분하여 출력해 주세요.
# 개선 후보
...

few-shot을 추가함으로써, "태그란 이런 입도(Granularity)와 형식의 것이다"라는 것을 모델에게 전달할 수 있습니다. 이것은 아직 시도해 보지 않았으므로, 다음 단계로서 시도해 보겠습니다.

가설 4: 태스크와 모델의 상성

애초에 "태그 생성"은 생성 태스크 (Generative Task)입니다. 모델이 자유롭게 문자를 출력할 수 있기 때문에, 지정되지 않은 문자열이 섞여 들어오기 쉽습니다.

반면, 분류 태스크 (Classification Task) ("이 메모는 업무, 개인, 학습 중 무엇인가?")라면 선택지를 한정할 수 있기 때문에 소형 모델에서도 안정적으로 작동하기 쉽습니다.

태그를 미리 정의해 두고, "다음 태그 중에서 해당하는 것을 골라주세요"라는 설계로 바꾸면 정밀도가 대폭 개선될 가능성이 있습니다. 다만, 사용자가 자유롭게 태그를 만들 수 있다는 메모 앱 특유의 유연성은 상실됩니다.

정리: 가설과 대책 요약

다음 단계

우선순위에 따라 시도해 보려고 합니다.

1. 프롬프트 개선 (비용: 낮음)

few-shot 추가와 출력 포맷의 엄격화. 모델을 바꾸지 않고 개선할 수 있는 가능성이 있으므로 가장 먼저 시도한다.

2. 모델 업그레이드 (비용: 중간~높음 · 현실적으로는 어려움)

더 고성능인 모델 (3B, 7B)을 시도하면 정밀도가 개선될 가능성이 높다. 하지만 스마트폰에서 구동한다는 전제가 있는 이상, 모델 사이즈에는 물리적인 상한선이 있다. Gemma 3의 3B 모델도 양자화 (Quantization) 후 파일 크기가 2GB 전후가 되며, 추론 시 RAM 사용량도 그에 상응하여 늘어난다. 하이엔드 단말기라면 동작할지도 모르지만, 일반적인 사용자의 단말기에서 쾌적하게 동작할 수 있을지는 별개의 문제다. "고성능 모델을 쓰고 싶다"는 욕구와 "온디바이스 (On-device)에서 구동한다"는 제약은 근본적으로 트레이드오프 (Trade-off) 관계에 있다.

3. 하이브리드 구성 (비용: 높음)

오프라인 시에는 온디바이스 LLM으로 간이 처리하고, 온라인 시에는 Gemini API로 폴백 (Fallback) 하는 구성. 이전에 Gemini API를 사용해 본 경험이 있으므로 구현 자체는 어렵지 않다. 다만 개인정보 보호 정책과 UX ("지금 네트워크로 전송했습니다"라는 고지) 설계가 필요하다.

마치며

"온디바이스 LLM으로 완결되는 AI 메모 앱"이라는 컨셉 자체는 지금도 옳다고 생각합니다. 다만 1B라는 작은 모델로 어디까지 할 수 있는가라는, 그 현실의 벽에 부딪혔습니다.

정밀도가 낮다는 것을 글로 쓰는 데는 약간의 용기가 필요했지만, 같은 벽에 부딪힌 사람이 "아, 나뿐만이 아니구나"라고 느낄 수 있다면 그것으로 충분하다고 생각하며 썼습니다.

온디바이스 LLM은 "프라이버시 · 오프라인 · 비용" 문제를 단번에 해결해 주는 매력적인 선택지입니다. 다만 그 혜택을 받기 위해 모델을 단말기에 가두는 순간, 성능의 천장도 함께 가져오게 됩니다. 이 제약과 어떻게 타협할 것인가, 그것이 온디바이스 AI 개발의 리얼한 과제임을 실감하고 있습니다.

피드백이나 조언이 있다면 댓글로 알려주시면 감사하겠습니다.

Discussion