파인튜닝과 LoRA로 내 작업에 맞게 조정하기
파인튜닝이 필요한 순간
Gemma를 업무에 맞추는 첫 번째 방법은 프롬프트 개선이다. 역할을 명확히 쓰고, 출력 형식을 지정하고, 예시를 넣으면 많은 문제가 해결된다. RAG를 붙이면 최신 문서나 사내 지식도 다룰 수 있다.
그런데도 반복해서 같은 문제가 생기는 경우가 있다. 예를 들어 모델이 매번 다른 말투로 답한다. JSON 형식을 자주 깨뜨린다. 상담 답변에서 회사의 표현 기준을 지키지 못한다. 법무, 의료, 제조, 금융처럼 특정 도메인의 판단 절차를 안정적으로 따라야 한다. 이런 문제는 매번 긴 프롬프트로 고치기보다 모델의 응답 습관 자체를 조정하는 편이 낫다.
이때 사용하는 방법이 파인튜닝이다. 파인튜닝은 모델에 새로운 모든 지식을 외우게 하는 작업이 아니다. 더 정확히 말하면 특정 입력을 받았을 때 어떤 형식과 말투, 어떤 판단 순서로 답해야 하는지 추가로 학습시키는 작업이다. 바뀌는 지식은 RAG로 연결하고, 반복되는 행동 방식은 파인튜닝으로 안정화하는 것이 실무에서 가장 안전하다.
AI 생성 이미지
전체 파인튜닝보다 LoRA로 시작하기
전체 파인튜닝은 모델의 많은 가중치를 직접 업데이트한다. 품질을 크게 바꿀 수 있지만 GPU 메모리, 학습 시간, 저장 공간, 운영 위험이 커진다. 데이터가 적으면 원래 모델의 일반 능력이 손상되는 과적합도 생기기 쉽다.
대부분의 Gemma 실무 프로젝트는 PEFT, 즉 파라미터 효율 파인튜닝으로 시작하는 것이 좋다. 대표적인 방식이 LoRA다. LoRA는 기본 모델의 큰 가중치는 고정하고, 일부 선형 계층에 작은 어댑터만 붙여 학습한다. 어댑터는 모델 옆에 붙는 작은 조정 장치라고 이해하면 된다. 기본 모델 전체를 다시 저장하지 않아도 되므로 비용이 낮고, 여러 업무별 버전을 분리해 관리하기 쉽다.
Gemma 계열을 Hugging Face에서 LoRA로 조정할 때는 attention과 feed-forward 계층의 주요 선형 모듈을 대상으로 삼는 구성이 자주 쓰인다. 예를 들면 q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj 같은 모듈이다. Hugging Face의 Gemma PEFT 예제도 google/gemma-2b에 대해 이 계층들을 LoRA 대상 모듈로 지정하고, 랭크 r=8을 사용한다1.
랭크 r은 어댑터가 얼마나 많은 조정 능력을 갖는지 결정한다. 값이 커지면 표현력은 좋아질 수 있지만 메모리와 학습 비용도 늘어난다. 처음에는 8이나 16처럼 작은 값으로 기준선을 만들고, 실제 검증 세트에서 부족할 때만 키우는 편이 좋다.
QLoRA로 메모리 부담 줄이기
GPU 메모리가 부족하면 QLoRA를 검토한다. QLoRA는 기본 모델을 4비트처럼 낮은 정밀도로 올려 메모리 사용량을 줄이고, LoRA 어댑터만 학습하는 방식이다. Hugging Face 예제에서는 load_in_4bit=True, bnb_4bit_quant_type='nf4', bnb_4bit_compute_dtype=torch.bfloat16 설정으로 4비트 양자화를 적용한다1.
양자화는 모델 크기와 메모리 사용량을 줄이는 강력한 방법이다. 하지만 항상 무료는 아니다. 매우 섬세한 형식 생성, 숫자 판단, 코드 생성처럼 작은 품질 차이가 중요한 작업에서는 양자화 설정에 따라 성능이 달라질 수 있다. 따라서 기준 모델을 BF16 또는 FP16으로 먼저 평가하고, QLoRA 결과가 실제 업무 샘플에서 충분히 유지되는지 확인해야 한다.
간단한 LoRA 설정은 다음과 같은 모양이 된다.
from peft import LoraConfig
lora_config = LoraConfig(
r=8,
target_modules=[
'q_proj', 'k_proj', 'v_proj', 'o_proj',
'gate_proj', 'up_proj', 'down_proj'
],
task_type='CAUSAL_LM'
)이 코드는 완성된 학습 스크립트가 아니라 핵심 설정만 보여준다. 실제 학습에서는 모델 로드, 토크나이저, 데이터 전처리, 학습 인자, 검증 루프, 저장 경로가 함께 필요하다.
모델 접근과 라이선스 확인
Gemma 모델을 Hugging Face에서 불러오려면 먼저 모델 페이지에서 사용 조건에 동의해야 한다. 동의하지 않으면 토크나이저나 가중치 다운로드 단계에서 권한 오류가 난다. Hugging Face 예제도 Gemma artifacts에 접근하기 전에 consent form 수락이 필요하다고 설명한다1.
인증 토큰은 코드에 직접 쓰지 않는다. 환경 변수나 secret으로 관리한다.
import os
from transformers import AutoTokenizer, AutoModelForCausalLM
model_id = 'google/gemma-2b'
token = os.environ['HF_TOKEN']
tokenizer = AutoTokenizer.from_pretrained(model_id, token=token)
model = AutoModelForCausalLM.from_pretrained(model_id, token=token)학습 결과를 공유할 때도 주의가 필요하다. LoRA 어댑터만 올리는지, 베이스 모델과 병합한 모델을 올리는지에 따라 배포 방식과 책임이 달라진다. 원 모델의 라이선스, 모델 카드 조건, 사용 제한, 데이터 출처를 함께 확인해야 한다. 내부 저장소에만 배포하더라도 어떤 베이스 모델과 어떤 데이터로 학습했는지 기록해야 나중에 재현과 감사가 가능하다.
지시문 데이터셋 설계하기
파인튜닝 품질은 모델보다 데이터셋이 더 크게 좌우한다. 좋은 데이터셋은 단순한 입력-정답 쌍이 아니다. 업무 지시문, 사용자 입력, 기대 출력, 거절해야 할 요청, 금지 사례를 함께 포함해야 한다.
예를 들어 고객 상담 초안 생성기를 만든다면 데이터는 다음 정보를 담아야 한다.
상담원이 따라야 할 역할과 정책
고객 문의 원문
주문 상태나 상품 정보 같은 입력값
회사 말투에 맞춘 기대 답변
환불 불가, 개인정보 요청, 법적 책임 인정처럼 조심해야 할 사례
답할 수 없을 때의 거절 문장
형식도 운영 환경과 같아야 한다. 실제 서비스에서 JSON으로 답해야 한다면 학습 데이터도 JSON을 포함해야 한다. 실제 서비스에서 짧고 공손한 한국어를 요구한다면 검증 세트도 같은 기준을 가져야 한다. 학습 데이터는 멋진 예시만 모으면 안 된다. 애매한 요청, 정책 밖 요청, 악의적인 요청, 정보가 부족한 요청을 반드시 넣어야 한다.
데이터는 최소한 학습 세트와 검증 세트로 나눈다. 가능하면 최종 테스트 세트도 따로 둔다. 같은 문서에서 문장만 조금 바꾼 샘플이 학습과 검증에 동시에 들어가면 점수가 좋아 보이지만 실제 성능은 나쁠 수 있다. 이 데이터 누수를 막아야 한다.
학습 설정에서 봐야 할 것
LoRA 학습에서 자주 조정하는 값은 랭크 r, 학습률, 배치 크기, 에폭, 시퀀스 길이, 양자화 여부다. 각각은 품질과 비용에 영향을 준다.
학습률이 너무 크면 모델이 빠르게 망가진다. 너무 작으면 변화가 거의 없다. Hugging Face 예제는 짧은 실험 설정에서 learning_rate=2e-4, per_device_train_batch_size=1, gradient_accumulation_steps=4, optim='paged_adamw_8bit' 같은 값을 사용한다1. 이 값은 출발점일 뿐이다. 운영 데이터에서는 반드시 별도 검증 세트로 조정해야 한다.
시퀀스 길이도 중요하다. 업무 입력이 긴데 학습 시퀀스 길이를 짧게 잡으면 뒤쪽 정보가 잘려 모델이 잘못 배운다. 반대로 필요 이상으로 길게 잡으면 메모리와 시간이 낭비된다. RAG 답변을 튜닝한다면 실제 검색 컨텍스트 길이와 비슷하게 학습 예시를 구성해야 한다.
에폭은 전체 데이터를 몇 번 반복해서 학습할지 정하는 값이다. 데이터가 적을수록 많은 에폭은 위험하다. 훈련 손실이 계속 내려가도 검증 품질이 떨어지면 과적합이다. 특히 말투 튜닝이나 형식 튜닝은 몇백 개 예시만으로도 겉보기에는 좋아질 수 있지만, 새로운 입력에서 쉽게 무너질 수 있다.
평가는 자동 지표만으로 끝내지 않는다. 실제 업무 샘플을 준비해 다음을 확인한다.
출력 형식을 지키는가
모르면 모른다고 말하는가
금지된 요청을 거절하는가
도메인 용어를 일관되게 쓰는가
기존 Gemma보다 실제로 나아졌는가
프롬프트 개선만으로 얻은 효과보다 큰가
마지막 질문이 중요하다. 파인튜닝은 비용이 드는 선택이다. 프롬프트, RAG, 후처리로 충분한 문제라면 굳이 학습할 필요가 없다.
로컬 실험에서 GKE 학습으로 확장하기
처음부터 대규모 클러스터로 시작하지 않는다. 작은 데이터와 작은 Gemma 모델로 로컬 단일 GPU 또는 노트북에서 먼저 학습 루프를 검증한다. 목표는 최고 성능이 아니라 데이터 형식, 토크나이징, loss 계산, 저장, 재로드가 정상인지 확인하는 것이다.
그다음 데이터가 커지거나 학습 시간이 길어지면 클라우드 GPU로 확장한다. Google Cloud 문서는 GKE에서 Hugging Face Transformers를 사용해 Gemma 2B를 GPU 노드에서 파인튜닝하는 흐름을 제시한다. 예시 아키텍처는 Kubernetes Job으로 학습을 실행하고, 학습 후에는 vLLM 기반 Kubernetes Deployment로 서빙하는 구조다2.
GKE에서는 H100, A100, L4 같은 GPU 선택지가 있으며, 문서의 구체 예시는 L4 GPU를 사용한다2. 운영 관점에서 중요한 흐름은 단순하다.
Hugging Face 토큰을 Kubernetes secret으로 저장한다.
PyTorch와 Transformers 학습 코드를 담은 컨테이너 이미지를 만든다.
Kubernetes Job을 제출해 모델과 데이터를 내려받고 학습한다.
학습 결과를 Hugging Face Hub나 내부 저장소에 업로드한다.
서빙 Deployment의
MODEL_ID를 튜닝된 모델로 바꾼다.
이 구조의 장점은 학습과 서빙을 분리할 수 있다는 점이다. 학습은 끝나면 종료되는 Job으로 실행하고, 서빙은 별도의 Deployment가 담당한다. 실패한 학습 Job은 로그와 설정을 보고 다시 실행할 수 있고, 서빙 모델은 검증된 버전으로만 교체할 수 있다.
어댑터 저장, 병합, 배포 결정
학습이 끝나면 산출물을 어떻게 저장할지 결정해야 한다. 선택지는 크게 세 가지다.
첫째, LoRA 어댑터만 저장한다. 저장 공간이 작고 여러 업무별 어댑터를 관리하기 쉽다. 대신 추론 시 베이스 모델과 어댑터를 함께 로드해야 한다.
둘째, 베이스 모델과 어댑터를 병합해 하나의 모델로 저장한다. 서빙 구성이 단순해질 수 있지만 저장 공간이 커지고, 업무별 모델이 많아지면 관리 부담이 늘어난다.
셋째, 내부 모델 레지스트리나 Hugging Face Hub에 버전별로 게시한다. 이때 모델 카드에는 베이스 모델, 학습 데이터 요약, 사용 목적, 제한 사항, 평가 결과, 안전성 주의사항을 적는다. 공개 배포라면 원 모델 조건과 데이터 라이선스를 다시 확인해야 한다.
실무에서는 먼저 어댑터만 저장해 비교 실험을 한다. 품질과 안전성이 확인되고 운영 구성이 정해지면 병합 모델을 만들지 결정한다. 중요한 것은 학습 산출물을 코드와 같은 방식으로 버전 관리하는 것이다. 어떤 데이터와 설정이 어떤 모델을 만들었는지 모르면, 좋은 결과도 다시 만들 수 없다.
정리
Gemma 파인튜닝의 핵심은 모델을 크게 바꾸는 것이 아니라 업무에 필요한 반복 행동을 안정화하는 것이다. 최신 지식은 RAG로 연결하고, 말투·형식·판단 절차는 LoRA로 조정한다. GPU 메모리가 부족하면 QLoRA로 시작할 수 있지만, 품질 검증은 반드시 별도 데이터로 해야 한다.
작게 시작하라. 프롬프트 기준선을 만들고, LoRA 어댑터로 개선을 확인하고, 검증 세트와 실제 업무 샘플로 과적합을 걸러낸다. 이후 필요할 때만 GKE 같은 GPU 환경으로 확장한다. 파인튜닝은 한 번의 학습 이벤트가 아니라 데이터, 평가, 배포, 모니터링이 이어지는 운영 절차다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.