온디바이스와 엣지 환경에서 활용하기

서버 밖에서 Gemma를 실행한다는 의미

Gemma를 꼭 서버에서만 실행해야 하는 것은 아니다. 모바일 앱, 데스크톱 프로그램, 브라우저, 산업용 단말, 라즈베리파이 같은 엣지 장비에서도 경량 Gemma 모델을 실행할 수 있다. 사용자의 입력을 서버로 보내지 않고 기기 안에서 처리하면 개인정보 보호, 오프라인 사용, 빠른 반응이라는 뚜렷한 장점이 생긴다.

Google이 공개한 Gemma 3n은 모바일·엣지 실행을 염두에 둔 모델로 소개된다. Google DeepMind는 Gemma 3n을 온디바이스 애플리케이션을 위해 설계했으며, 개인정보를 존중하고 오프라인에서도 동작하는 기능, 줄어든 메모리 사용량, 텍스트·이미지·오디오·비디오 이해 같은 멀티모달 방향성을 강조한다.¹ 이런 흐름은 Gemma를 단순한 서버용 LLM이 아니라 제품 안에 내장할 수 있는 작은 AI 엔진으로 보게 만든다.

하지만 온디바이스 실행은 "서버 비용이 사라진다" 정도로 단순하지 않다. 서버 GPU 대신 사용자의 CPU, GPU, NPU, RAM, 저장 공간, 배터리를 사용한다. 모델 파일을 내려받아야 하고, 업데이트해야 하며, 문제가 생기면 회수하거나 비활성화할 방법도 있어야 한다. 따라서 온디바이스 Gemma 설계의 핵심은 가장 똑똑한 모델을 넣는 것이 아니라, 목표 기기에서 안정적으로 동작하는 가장 작은 기능 단위를 찾는 것이다.

AI 생성 이미지

서버 추론과 온디바이스 추론 비교하기

서버 추론은 모델을 중앙 서버에서 실행하고 앱은 API로 결과를 받는 구조다. 큰 모델을 쓰기 쉽고, 업데이트와 모니터링이 단순하며, RAG나 도구 호출 같은 복잡한 흐름을 붙이기 좋다. 대신 네트워크가 필요하고, 사용자의 입력이 서버로 전송되며, 요청이 많아질수록 GPU 비용이 증가한다.

온디바이스 추론은 모델이 사용자 기기 안에서 직접 실행된다. 민감한 문장, 개인 메모, 메시지 초안, 건강 기록, 현장 센서 데이터처럼 외부 전송이 부담스러운 입력을 다루기 좋다. 네트워크가 불안정한 환경에서도 쓸 수 있고, 짧은 작업은 서버 왕복보다 빠르게 느껴질 수 있다.

제품 관점에서는 둘 중 하나만 고를 필요가 없다. 민감하고 짧은 작업은 로컬 Gemma가 처리하고, 긴 문서 분석이나 복잡한 추론은 사용자 동의를 받아 서버 모델로 넘길 수 있다. 이 하이브리드 구조가 실제 서비스에서 가장 현실적인 선택인 경우가 많다.

목표 기기군을 먼저 정한다

온디바이스 배포에서 "내 컴퓨터에서 실행됐다"는 충분한 검증이 아니다. 같은 Gemma 모델도 안드로이드 플래그십, 보급형 스마트폰, iPhone, Mac, Windows 노트북, 브라우저 WebGPU 환경, 산업용 ARM 보드에서 전혀 다르게 동작한다. CPU 명령어, GPU 메모리, NPU 지원, 운영체제 제한, 런타임 성숙도, 백그라운드 실행 정책이 모두 다르기 때문이다.

먼저 목표 기기군을 정해야 한다.

• 최소 지원 RAM은 얼마인가?

• 모델 파일을 몇 MB 또는 몇 GB까지 포함할 수 있는가?

• 첫 실행 때 모델을 앱에 포함할 것인가, 나중에 다운로드할 것인가?

• 한 번의 요청에서 입력과 출력은 몇 토큰까지 허용할 것인가?

• 동시에 몇 개의 로컬 AI 작업이 실행될 수 있는가?

• 배터리와 발열이 UX에 어느 정도 영향을 주는가?

• CPU, GPU, NPU 중 어떤 백엔드를 우선 사용할 것인가?

Google AI Edge의 Gemma 3 모바일·웹 소개에서는 Gemma 3 1B 모델을 모바일과 웹에 배포하는 예를 들며, 작은 모델 크기, 빠른 다운로드, 사용자가 기다릴 수 있는 응답 속도, 다양한 사용자 기기 지원이 중요하다고 설명한다. 또한 Android 예제에서 CPU 또는 GPU 실행을 선택할 수 있고, INT4 양자화 모델을 사용하는 흐름을 보여준다.² 여기서 배울 점은 명확하다. 온디바이스 모델 선택은 벤치마크 표의 최고 성능이 아니라, 실제 사용자가 가진 기기 분포에서 출발해야 한다.

경량화는 선택이 아니라 전제다

엣지 LLM 연구에서는 기기 제약을 계산 성능, 메모리, 저장 공간, 하드웨어·소프트웨어 다양성의 문제로 본다. 이를 해결하기 위해 배포 전 압축과 배포 후 런타임 최적화를 함께 사용한다. 대표적인 압축 방법은 양자화, 가지치기, 지식 증류, 저랭크 근사다.³

가장 먼저 검토할 방법은 양자화다. 양자화는 모델 가중치나 일부 연산을 더 낮은 비트 수로 표현해 모델 크기와 메모리 사용량을 줄이는 방식이다. 예를 들어 16비트 모델을 8비트나 4비트로 줄이면 저장 공간과 메모리 부담이 크게 낮아진다. 대신 품질이 조금 떨어질 수 있으므로, 실제 제품 입력으로 반드시 비교해야 한다.

가지치기는 모델 안의 덜 중요한 연결이나 구조를 제거해 계산량을 줄이는 방식이다. 지식 증류는 큰 모델의 동작을 작은 모델이 따라 배우게 하는 방법이다. 저랭크 근사는 큰 행렬을 더 작은 구조로 근사해 계산과 저장을 줄인다. 이 기법들은 강력하지만, 애플리케이션 개발자가 매번 직접 적용하기에는 부담이 크다. 실무에서는 먼저 공식 또는 커뮤니티에서 제공하는 양자화된 Gemma 변형을 검토하고, 품질이 부족할 때 파인튜닝·증류·전용 데이터셋을 고려하는 순서가 좋다.

경량화 후에도 끝이 아니다. 런타임에서 KV 캐시 메모리, 컨텍스트 길이, 배치 방식, 텐서 연산 최적화, GPU/NPU 가속 여부가 실제 속도를 좌우한다. 같은 모델이라도 컨텍스트를 512토큰으로 제한할 때와 4096토큰까지 허용할 때의 발열, 메모리, 지연 시간은 크게 달라진다.

작은 모델에는 작은 일을 맡긴다

온디바이스 Gemma를 실패하게 만드는 흔한 원인은 작은 모델에게 서버급 범용 비서 역할을 맡기는 것이다. 사용자가 어떤 질문을 하든 깊게 추론하고, 최신 정보를 알고, 긴 문서를 읽고, 복잡한 도구를 호출하길 기대하면 품질이 흔들린다.

작은 모델은 범위를 좁힐수록 강해진다. 다음과 같은 기능이 적합하다.

• 개인 메모를 세 줄로 요약하기

• 메시지 답장 후보 만들기

• 문장을 더 공손하게 바꾸기

• 오타와 문체를 교정하기

• 사용자가 작성한 내용을 정해진 양식으로 변환하기

• 앱 내부 데이터를 자연어 설명으로 바꾸기

• 짧은 로그나 오류 메시지를 쉬운 말로 설명하기

• 민감한 문서에서 항목을 추출하되 서버로 보내지 않기

이런 작업은 입력 범위가 작고, 출력 형식을 제한하기 쉽다. 프롬프트도 자유 대화형보다 템플릿형이 좋다.

역할: 문장 교정 도우미
작업: 사용자가 입력한 문장을 의미는 유지한 채 자연스러운 한국어로 고친다.
제약:
- 새 정보를 추가하지 않는다.
- 문장을 2개 이상으로 늘리지 않는다.
- 결과 문장만 출력한다.
입력: {user_text}

출력이 JSON이어야 한다면 모델에게만 맡기지 말고 앱에서 파싱 검증을 한다. 길이 제한, 금지어 검사, 필수 필드 확인, 실패 시 재시도 또는 기본 UI 표시 같은 후처리가 필요하다. 온디바이스 환경에서는 모델 품질을 키우기보다 제품 흐름으로 실패 가능성을 줄이는 설계가 더 효과적일 때가 많다.

개인정보 보호는 로컬 실행만으로 끝나지 않는다

로컬에서 실행하면 사용자의 원문 입력을 서버로 보내지 않을 수 있다. 이는 강력한 장점이다. 그러나 "온디바이스"라는 말만으로 개인정보 보호가 완성되지는 않는다.

앱이 입력과 출력을 로컬 로그에 저장하는지, 분석 SDK가 화면 내용을 수집하는지, 오류 리포트에 프롬프트가 포함되는지, 동기화 기능이 결과물을 클라우드에 올리는지 확인해야 한다. 서버 fallback이 있다면 사용자가 어떤 순간에 데이터가 전송되는지 알아야 하고, 민감한 항목은 전송 전에 마스킹하거나 로컬 처리만 허용해야 한다.

특히 RAG나 문서 Q&A를 로컬에서 제공할 때는 문서 인덱스도 보호 대상이다. 원문 문서뿐 아니라 임베딩, 검색 캐시, 요약본, 대화 기록도 민감할 수 있다. 기기 분실, 백업, 앱 삭제, 회사 단말 반납 같은 상황에서 데이터 삭제 정책을 함께 설계해야 한다.

하이브리드 구조로 한계를 보완한다

온디바이스 Gemma의 한계는 분명하다. 작은 모델은 복잡한 추론, 긴 문맥 처리, 최신 지식 반영, 높은 정확도가 필요한 업무에서 서버 모델보다 불리할 수 있다. 이 한계를 숨기면 사용자는 모델을 신뢰하지 못한다. 대신 처음부터 하이브리드 구조를 설계하는 편이 낫다.

예를 들어 앱은 요청을 세 단계로 나눌 수 있다.

1. 로컬 처리: 문장 교정, 요약, 분류, 민감 입력 처리처럼 작고 빠른 작업.

2. 사용자 확인 후 서버 처리: 긴 문서 분석, 고난도 질의응답, 최신 정보 검색처럼 로컬 한계를 넘는 작업.

3. 거절 또는 축소 처리: 정책상 전송할 수 없거나 근거가 부족한 작업.

이때 중요한 것은 데이터 경계다. 어떤 데이터가 로컬에만 남는지, 어떤 데이터가 서버로 전송되는지, 서버 전송 전에 어떤 필드가 제거되는지, 사용자가 설정에서 이를 끌 수 있는지 명확해야 한다. 모델 라우팅은 단순한 성능 최적화가 아니라 개인정보와 신뢰의 문제다.

배포 전 체크리스트

온디바이스 Gemma 기능을 배포하기 전에는 다음 항목을 확인한다.

• 최소 사양 기기에서 첫 실행, 두 번째 실행, 장시간 실행을 모두 테스트했는가?

• 모델 다운로드 실패, 저장 공간 부족, 네트워크 끊김을 처리하는가?

• CPU/GPU/NPU 백엔드별 속도와 발열을 측정했는가?

• 컨텍스트 길이와 출력 길이에 상한을 두었는가?

• 배터리 절약 모드나 백그라운드 상태에서 동작 정책을 정했는가?

• 모델 파일의 버전, 라이선스, 출처, 해시를 기록했는가?

• 문제가 있는 모델을 회수하거나 비활성화할 수 있는가?

• 로컬 로그, 캐시, 임베딩, 대화 기록 삭제 정책이 있는가?

• 서버 fallback 시 사용자 동의와 데이터 마스킹이 적용되는가?

• 작은 모델이 모를 때 억지로 답하지 않도록 UX가 설계되어 있는가?

온디바이스 Gemma의 가치는 모든 질문에 답하는 만능 챗봇이 되는 데 있지 않다. 사용자의 기기 안에서, 빠르게, 조용히, 민감한 데이터를 지키며, 정해진 일을 안정적으로 처리하는 데 있다. 기능 범위를 좁히고, 모델을 가볍게 만들고, 실패를 제품 로직으로 감싸면 Gemma는 서버 밖에서도 충분히 강력한 개발 도구가 된다.

참고

¹Gemma 3n — Google DeepMind

²Gemma 3 on mobile and web with Google AI Edge

³A Review on Edge Large Language Models: Design, Execution, and Applications