모델 라인업과 선택 기준 이해하기
Gemma를 쓰기 시작할 때 가장 먼저 정해야 할 것은 "어떤 모델을 쓸 것인가"이다. 같은 Gemma 계열이라도 크기, 튜닝 방식, 입력 형식, 실행 환경이 다르면 성능과 비용이 크게 달라진다. 큰 모델이 항상 정답은 아니다. 작은 모델로도 충분한 작업에 큰 모델을 쓰면 응답은 느려지고 비용은 늘어난다. 반대로 복잡한 추론이나 긴 문서 분석에 너무 작은 모델을 쓰면 환각, 형식 오류, 낮은 이해도 때문에 결국 더 많은 후처리 비용이 든다.
이 장의 목표는 모델 이름을 외우는 것이 아니다. 작업 목적, 품질 요구사항, 실행 환경을 보고 합리적으로 모델을 고르는 기준을 세우는 것이다.
AI 생성 이미지
Gemma 라인업을 보는 기본 관점
Gemma는 하나의 모델이 아니라 여러 목적을 가진 공개 가중치 모델 계열이다. 기본 텍스트 모델은 문장을 입력받아 문장을 생성하는 decoder-only Transformer 구조를 사용한다. 여기에 지시문을 잘 따르도록 조정한 instruction-tuned 모델, 코드 작업에 특화된 CodeGemma, 이미지와 텍스트를 함께 다루는 PaliGemma 같은 변형이 있다.1
최근 라인업은 더 넓어졌다. Gemma 2는 이전 세대보다 효율과 품질을 개선했고, Gemma 3 계열은 더 긴 컨텍스트, 다국어, 멀티모달 방향을 강화했다. 2026년 기준으로 소개된 Gemma 4 계열은 에이전트 워크플로, 함수 호출, 오디오·비전 이해, 다국어 지원, 온디바이스와 개인 PC 실행 효율을 강조한다.2
모델을 볼 때는 다음 네 가지를 먼저 확인한다.
| 기준 | 확인할 질문 |
|---|---|
| 모델 크기 | 내 작업에 필요한 추론 능력과 언어 품질은 어느 정도인가? |
| 튜닝 방식 | 베이스 모델인가, instruction-tuned 모델인가? |
| 입력 형식 | 텍스트만 필요한가, 이미지·오디오도 필요한가? |
| 실행 위치 | 서버 GPU, 개인 PC, 노트북, 모바일·엣지 중 어디서 돌릴 것인가? |
이 네 가지를 먼저 정하면 선택지가 빠르게 줄어든다.
파라미터 수가 커지면 무엇이 좋아지고 무엇이 비싸지는가
파라미터 수는 모델 내부에 있는 학습된 숫자 값의 규모다. 2B는 약 20억 개, 7B는 약 70억 개, 27B는 약 270억 개의 파라미터를 뜻한다. 일반적으로 파라미터가 많을수록 복잡한 지시를 이해하고, 긴 문맥을 유지하고, 애매한 질문을 처리하는 능력이 좋아진다.
하지만 자원 사용량도 함께 커진다. 모델 파일이 커지고, GPU 메모리를 더 많이 쓰고, 한 번에 처리할 수 있는 사용자 수도 줄어든다. 응답 속도도 느려질 수 있다. 특히 운영 환경에서는 모델 자체 메모리만 보면 안 된다. 긴 프롬프트와 긴 답변을 처리할 때는 KV 캐시라는 추가 메모리가 필요하다. KV 캐시는 이전 토큰의 계산 결과를 저장해 다음 토큰 생성을 빠르게 만드는 공간이다. 컨텍스트 길이와 동시 사용자 수가 늘면 이 메모리가 빠르게 커진다.
따라서 모델 크기는 이렇게 고르는 것이 좋다.
먼저 작은 모델로 기준선을 만든다. 2B, 4B, E2B, E4B 같은 작은 모델로 작업이 가능한지 확인한다.
실제 데이터로 실패 유형을 본다. 한국어가 어색한지, 근거를 놓치는지, JSON 형식을 깨는지, 코드가 틀리는지 구분한다.
원인이 모델 크기인지 확인한다. 검색 품질, 프롬프트, 출력 검증으로 해결할 수 있는 문제라면 모델을 키우기 전에 시스템을 고친다.
품질 차이가 명확할 때만 큰 모델로 올린다. 큰 모델은 비용과 지연 시간이 함께 증가한다.
실무에서는 "사용자가 만족할 수 있는 가장 작은 모델"이 좋은 출발점이다.
컨텍스트 길이는 길수록 좋은가
컨텍스트 길이는 모델이 한 번에 읽을 수 있는 입력 토큰의 양이다. 긴 문서 요약, 계약서 분석, 긴 대화 기록 처리에서는 긴 컨텍스트가 유용하다. 하지만 길다고 무조건 좋은 것은 아니다.
긴 컨텍스트에는 세 가지 비용이 있다.
입력을 읽는 시간이 늘어난다.
KV 캐시 메모리가 증가한다.
관련 없는 정보가 섞이면 답변 품질이 떨어진다.
예를 들어 사내 문서 Q&A에서 관련 문서 3개만 필요할 때, 전체 매뉴얼 수백 페이지를 넣는 것은 좋은 방법이 아니다. 모델이 읽어야 할 양만 늘어나고 정작 중요한 근거는 희석된다. 이 경우에는 긴 컨텍스트 모델보다 좋은 검색과 청크 설계가 더 중요하다.
대화형 서비스에서는 특히 주의해야 한다. 아주 긴 컨텍스트를 매 요청마다 넣으면 첫 토큰이 나오기까지 시간이 길어진다. 실무 선택 가이드에서도 대화형 앱에는 전체 최대 컨텍스트를 무리하게 쓰기보다 16K~32K 범위에서 시작하고, 128K 이상의 긴 컨텍스트는 상호작용형 서비스에 신중히 적용하라고 조언한다.3
정리하면, 긴 컨텍스트는 "많이 넣기 위한 기능"이 아니라 "필요한 정보를 잃지 않기 위한 여유 공간"이다.
베이스 모델과 인스트럭션 튜닝 모델
Gemma 계열에는 베이스 모델과 instruction-tuned 모델이 있다. 베이스 모델은 다음 토큰을 예측하도록 학습된 기본 모델이다. 연구, 추가 학습, 자체 파인튜닝의 출발점으로 적합하다. 반면 instruction-tuned 모델은 사용자의 지시를 잘 따르도록 추가 조정된 모델이다. 모델 이름에 it가 붙는 경우가 많다.
대부분의 애플리케이션에서는 instruction-tuned 모델을 먼저 고르는 것이 안전하다.
| 작업 | 권장 선택 |
|---|---|
| 챗봇 | instruction-tuned 모델 |
| 문서 요약 | instruction-tuned 모델 |
| RAG 질의응답 | instruction-tuned 모델 |
| 분류·추출 | instruction-tuned 모델 또는 작은 튜닝 모델 |
| 자체 파인튜닝 연구 | 베이스 모델 또는 instruction-tuned 모델 모두 검토 |
| 말투·형식 조정 | instruction-tuned 모델 + LoRA가 현실적 |
베이스 모델을 바로 챗봇에 쓰면 사용자의 의도를 덜 안정적으로 따를 수 있다. 질문에 답하기보다 문장을 이어 쓰듯 반응할 수 있고, 출력 형식도 흔들릴 수 있다. 반대로 instruction-tuned 모델은 대화, 요약, 구조화 출력처럼 "지시를 수행하는 일"에 더 적합하다.
분류 작업도 마찬가지다. 감성 분류, 문의 유형 분류, 위험도 라벨링처럼 출력 후보가 정해진 작업은 큰 베이스 모델보다 작은 instruction-tuned 모델에 명확한 라벨과 예시를 주는 편이 더 안정적일 때가 많다.
실행 환경별 현실적인 선택
모델 선택은 하드웨어 선택과 분리할 수 없다. 같은 모델이라도 서버 GPU에서 돌릴 때와 개인 노트북에서 돌릴 때의 체감은 전혀 다르다.
GPU 서버
서버 GPU가 있다면 12B, 27B, 31B 같은 큰 모델도 검토할 수 있다. 다만 운영에서는 단일 요청 속도보다 동시 처리량이 중요하다. 여러 사용자가 동시에 접속한다면 continuous batching, KV 캐시 관리, 양자화, 추론 서버 설정까지 함께 봐야 한다.
Gemma 4 계열의 경우 고처리량 다중 사용자 서빙에는 MoE 구조인 26B A4B 같은 선택지가 언급된다. 다만 MoE는 여러 전문가 네트워크 중 일부를 사용하는 구조라서, 이를 잘 지원하는 서빙 스택이 필요하다. vLLM이나 TGI 같은 환경에서 이점을 얻을 수 있고, 단순한 실행 방식에서는 기대한 속도가 나오지 않을 수 있다.3
개인 PC와 개발용 노트북
개인 PC에서는 작은 instruction-tuned 모델부터 시작하는 것이 좋다. 4B 안팎의 모델이나 E4B급 모델은 소비자용 GPU 또는 메모리가 넉넉한 Apple Silicon 환경에서 실험하기 쉽다. 개발자는 이 크기로 프롬프트, RAG, 출력 검증, 애플리케이션 통합을 먼저 검증할 수 있다.
로컬 개발의 목적은 최고 품질이 아니라 빠른 반복이다. 모델을 바꾸고, 프롬프트를 고치고, 평가 데이터를 돌려보는 과정이 짧아야 한다. 처음부터 큰 모델을 내려받아 느린 실험을 반복하면 개발 속도가 크게 떨어진다.
CPU-only와 저사양 환경
GPU가 없다면 양자화 모델을 고려해야 한다. 양자화는 모델의 숫자 정밀도를 낮춰 메모리 사용량을 줄이는 방법이다. 8비트나 4비트 모델은 품질이 약간 떨어질 수 있지만, 로컬 실행 가능성을 크게 높인다.
다만 CPU에서 작은 모델을 실행하면 응답 속도가 제한적이다. 짧은 배치 작업, 오프라인 요약, 자동 태깅에는 쓸 수 있지만 실시간 챗봇에는 답답할 수 있다. CPU-only 환경은 "가능한지 확인하는 환경"이지, 고품질 대화 서비스를 운영하는 환경으로 보기 어렵다.
모바일·엣지 기기
모바일과 엣지에서는 모델 크기가 가장 중요한 제약이다. 메모리, 저장 공간, 배터리, 발열, NPU 지원 여부를 모두 봐야 한다. E2B나 Gemma 3n처럼 온디바이스를 염두에 둔 작은 모델이 우선 후보가 된다.
이 환경에서는 범용 비서보다 좁은 작업이 적합하다. 예를 들어 다음과 같은 기능이 현실적이다.
짧은 문장 교정
알림 내용 요약
답장 후보 생성
오프라인 메모 분류
민감한 텍스트의 로컬 추출
이미지나 화면 정보에 대한 제한된 설명
엣지 모델은 작기 때문에 "무엇이든 답하는 AI"로 설계하면 실패하기 쉽다. 작업 범위를 좁히고, 출력 형식을 제한하고, 필요할 때 서버 모델로 넘기는 하이브리드 구조가 더 안전하다.
작업 유형별 선택 체크리스트
한국어 질의응답
한국어 Q&A는 모델 크기와 지시문 이해력이 중요하다. 단순 FAQ라면 작은 instruction-tuned 모델과 RAG로 충분할 수 있다. 하지만 법률, 의료, 기술 지원처럼 표현이 미묘하고 근거가 중요한 분야라면 더 큰 모델과 엄격한 검색 품질 평가가 필요하다.
체크할 항목은 다음과 같다.
한국어 질문을 자연스럽게 이해하는가?
존댓말, 용어, 조직 내부 표현을 안정적으로 쓰는가?
모르는 경우 추측하지 않고 거절하는가?
검색된 근거와 다른 내용을 만들지 않는가?
긴 문서를 넣었을 때 핵심 근거를 놓치지 않는가?
한국어 품질이 부족하다고 바로 파인튜닝부터 할 필요는 없다. 먼저 프롬프트, 예시, 용어집, RAG 문서 품질을 개선해 본다.
코드 생성
코드가 주 업무라면 일반 텍스트 모델보다 코드 특화 모델을 먼저 검토한다. CodeGemma는 코드 완성, 코드 생성, 코드 대화 보조에 맞춰 조정된 Gemma 변형이며, 중간 빈칸 채우기 같은 코드 작업에 유리한 기능을 갖고 있다.1
단, 코드 생성 모델도 항상 정답 코드를 만들지는 않는다. 테스트, 린터, 타입 검사, 보안 검사와 함께 써야 한다. 운영 코드 자동 수정처럼 위험도가 높은 작업은 사람이 승인하는 흐름을 둔다.
문서 요약과 RAG
문서 요약은 입력 길이와 근거 충실도가 중요하다. 짧은 문서 요약은 작은 instruction-tuned 모델로도 충분하다. 긴 문서 분석은 긴 컨텍스트 모델이나 큰 모델이 도움이 되지만, 먼저 문서를 잘 나누고 필요한 부분만 넣는 RAG 구조를 설계해야 한다.
RAG에서는 모델보다 검색 품질이 더 큰 병목이 되는 경우가 많다. 관련 없는 청크가 들어오면 큰 모델도 틀린 답을 할 수 있다. 반대로 좋은 근거를 넣으면 작은 모델도 안정적인 답변을 만든다.
비전 입력과 멀티모달 작업
이미지, 스크린샷, 차트, 문서 사진을 입력으로 다뤄야 한다면 텍스트 전용 모델은 적합하지 않다. PaliGemma나 멀티모달을 지원하는 최신 Gemma 계열을 검토해야 한다. Gemma 4 소개 자료도 오디오와 시각 이해를 핵심 능력 중 하나로 강조한다.2
비전 모델을 고를 때는 이미지 종류를 직접 테스트해야 한다. 제품 사진, 영수증, 의료 이미지, UI 스크린샷, 손글씨 문서는 난이도가 다르다. "이미지를 볼 수 있다"는 말이 모든 이미지 작업에서 같은 성능을 낸다는 뜻은 아니다.
실전 선택 절차
Gemma 모델을 고를 때는 다음 순서로 결정하면 시행착오를 줄일 수 있다.
작업을 한 문장으로 정의한다.
예: "사내 정책 문서를 근거로 직원 질문에 한국어로 답한다."입력과 출력을 정한다.
텍스트만 필요한지, 이미지가 필요한지, JSON 출력이 필요한지 확인한다.실행 위치를 정한다.
클라우드 GPU인지, 사내 GPU 서버인지, 개인 PC인지, 모바일인지 결정한다.작은 instruction-tuned 모델로 시작한다.
기준 품질과 속도를 측정한다.실패 원인을 분리한다.
모델 이해력 문제인지, 검색 문제인지, 프롬프트 문제인지, 출력 검증 문제인지 나눈다.필요할 때만 모델을 키운다.
품질 개선 폭이 비용 증가를 정당화하는지 확인한다.배포 전 실제 데이터로 평가한다.
50~100개의 대표 질문만 있어도 모델 선택의 방향이 훨씬 명확해진다.
모델 선택은 한 번에 끝나는 결정이 아니다. 개발 초기에 고른 모델은 기준선이다. 이후 프롬프트, RAG, 파인튜닝, 양자화, 서빙 방식이 바뀌면 최적 모델도 달라질 수 있다. 중요한 것은 모델 이름보다 선택 기준을 갖는 것이다. 기준이 있으면 새로운 Gemma 변형이 나와도 흔들리지 않고 판단할 수 있다.
참고
1Gemma explained: An overview of Gemma model family architectures
3Intentional Model Selection — How to Actually Choose the Right Gemma 4 Variant for Your Workload
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.