실전 프로젝트로 완성하는 Gemma 활용법

지금까지는 Gemma를 실행하고, 프롬프트를 다듬고, RAG를 만들고, 파인튜닝과 배포·평가를 각각 살펴보았다. 마지막 장의 목표는 이 조각들을 하나의 프로젝트로 연결하는 것이다. 좋은 LLM 프로젝트는 "모델을 붙였다"에서 끝나지 않는다. 입력 데이터가 어디서 오고, 어떤 근거로 답하며, 누가 최종 판단하고, 실패했을 때 어떻게 되돌릴지까지 정해야 실무에서 쓸 수 있다.

이 장에서는 사내 문서 Q&A 챗봇을 기준 프로젝트로 삼는다. 같은 구조는 고객 상담 초안 생성기, 회의록 요약기, 사내 지식 검색 도우미에도 거의 그대로 적용할 수 있다.

AI 생성 이미지

요구사항을 먼저 고정한다

프로젝트의 첫 단계는 기술 선택이 아니라 요구사항 정리다. 예를 들어 사내 문서 Q&A 챗봇이라면 다음 질문에 답해야 한다.

이 표가 없으면 모델 크기 논쟁으로 빠지기 쉽다. 그러나 실무에서는 모델보다 업무 경계가 먼저다. 챗봇이 인사 규정을 답할 수 있다면 최신 규정 문서만 근거로 삼아야 한다. 고객 계약서나 인사 평가 자료처럼 민감한 문서는 권한이 있는 사용자에게만 검색되어야 한다.

사내 문서 Q&A의 전체 데이터 흐름

RAG 기반 Q&A의 흐름은 다음처럼 잡을 수 있다.

1. 원천 문서를 수집한다.

2. PDF, 웹페이지, 위키 문서를 텍스트로 정리한다.

3. 제목, 부서, 작성일, 수정일, 권한, 원문 URL 같은 메타데이터를 붙인다.

4. 문서를 검색하기 좋은 청크로 나눈다.

5. 청크를 임베딩으로 바꾸고 벡터 DB에 저장한다.

6. 사용자가 질문하면 먼저 사용자 권한을 확인한다.

7. 접근 가능한 문서 안에서 관련 청크를 검색한다.

8. 검색 결과를 Gemma 프롬프트에 넣는다.

9. Gemma가 근거 기반 답변을 생성한다.

10. 출력 형식, 금칙어, 개인정보 노출 여부를 검사한 뒤 사용자에게 보낸다.

여기서 중요한 점은 Gemma가 모든 것을 직접 하지 않는다는 것이다. 권한 확인, 검색, 로그 저장, 개인정보 마스킹, 출력 검사는 애플리케이션 코드가 맡는다. Gemma는 "검색된 근거를 읽고 답변 문장을 만드는 역할"에 집중하는 편이 안전하다.

프롬프트 템플릿은 단순해야 한다.

당신은 사내 문서 Q&A 도우미입니다.
아래 <근거>에 포함된 내용만 사용해 답하세요.
근거가 부족하면 "문서에서 확인할 수 없습니다"라고 답하세요.
답변 끝에는 사용한 문서 제목과 링크를 표시하세요.

<사용자 질문>
{question}

<근거>
{retrieved_chunks}

<출력 형식>
- 답변:
- 근거:
- 추가 확인이 필요한 사항:

처음부터 복잡한 에이전트 구조를 만들 필요는 없다. 로컬에서 Ollama로 Gemma를 띄우고, 작은 문서 20~50개로 RAG 흐름을 검증한다. 이 단계의 목표는 "답이 멋진가"가 아니라 "근거 없는 답을 하지 않는가", "권한 밖 문서를 검색하지 않는가", "출처를 빠뜨리지 않는가"를 확인하는 것이다.

반복 업무 자동화로 확장하기

같은 구조는 다른 업무에도 적용된다. 다만 작업마다 입력, 출력, 검토 흐름이 다르다.

고객 상담 초안 생성기는 고객 문의, 주문 정보, 정책 문서를 입력으로 받는다. 출력은 상담사가 수정할 수 있는 초안이어야 하며, 환불 가능 여부나 보상 금액처럼 중요한 판단은 사람이 승인해야 한다. 모델이 바로 고객에게 답을 보내게 하면 위험하다.

회의록 요약기는 녹취록이나 회의 메모를 입력으로 받는다. 출력은 결정 사항, 담당자, 마감일, 보류 안건으로 나누는 것이 좋다. 개인정보나 민감한 발언은 저장 전에 마스킹해야 한다.

사내 지식 검색 도우미는 질문에 맞는 문서를 찾아 요약한다. 이 경우 답변 품질보다 검색 정확도가 더 중요할 수 있다. 틀린 문서를 근거로 넣으면 Gemma가 아무리 자연스럽게 답해도 결과는 틀린 답이 된다.

자동화 파이프라인을 만들 때는 항상 다음 네 가지를 함께 정의한다.

• 입력 데이터 형식: 텍스트, 표, 첨부 파일, 메타데이터를 어떻게 받을지

• 출력 품질 기준: 반드시 포함할 필드, 금지할 표현, 근거 표시 방식

• 안전 처리: 개인정보, 금칙어, 권한 밖 정보, 위험한 조언 차단

• 승인 흐름: 자동 발송인지, 담당자 검토 후 발송인지, 관리자 승인이 필요한지

LLM 자동화의 핵심은 사람을 없애는 것이 아니다. 반복 작성과 검색 시간을 줄이고, 중요한 판단은 사람이 더 잘할 수 있게 만드는 것이다.

로컬 프로토타입에서 팀 API로 이동하기

로컬 검증이 끝나면 다음 단계는 팀이 함께 쓸 수 있는 API다. 이때 프런트엔드가 직접 Ollama나 vLLM을 호출하게 만들지 않는다. 백엔드 API를 하나 두고, 그 안에서 인증, 권한 확인, RAG 검색, Gemma 호출, 출력 검사를 처리한다.

초기 구조는 다음 정도면 충분하다.

웹/업무 도구
  → Backend API
    → 권한 확인
    → 문서 검색 / 벡터 DB
    → Gemma 추론 서버
    → 출력 검증
  → 사용자 응답

작은 팀 내부 사용이라면 Cloud Run GPU와 Ollama 조합으로 시작할 수 있다. 준비 순서는 명확하다. Google Cloud 프로젝트를 만들고 결제를 연결한 뒤 Artifact Registry, Cloud Build, Cloud Run, Cloud Storage API를 활성화한다. gcloud CLI를 초기화하고 프로젝트와 리전을 설정한다. GPU를 쓰려면 Cloud Run에서 NVIDIA L4 GPU 할당량을 요청해야 하며, 배포 계정에는 Artifact Registry, Cloud Build, Cloud Run, IAM, Storage 관련 권한이 필요하다.¹

컨테이너는 Ollama 이미지를 기반으로 만들 수 있다. 예를 들어 OLLAMA_HOST를 0.0.0.0:8080으로 열고, 모델 저장 경로를 지정한 뒤, 빌드 과정에서 gemma3:4b 같은 모델을 미리 내려받는다. 이렇게 하면 서비스 시작 시 매번 모델을 다운로드하는 시간을 줄일 수 있다. 배포할 때는 GPU 1개, L4 타입, 충분한 메모리, 동시성 값을 정하고, OLLAMA_NUM_PARALLEL과 Cloud Run 동시성 설정을 맞춘다. 내부 서비스라면 인증 없는 공개 접근은 막아야 한다.¹

Cloud Run은 운영 부담이 낮다. 다만 GPU 인스턴스 수, 콜드 스타트, 최대 동시 요청, 모델 크기에는 한계가 있다. 그래서 "팀 공유용 API"나 "트래픽이 예측 가능한 내부 도구"에 잘 맞는다.

트래픽이 커지면 GKE와 vLLM으로 확장한다

요청량이 늘고 운영 제어가 더 필요해지면 GKE에서 vLLM API 서버를 운영하는 구조를 검토한다. vLLM은 여러 요청을 효율적으로 처리하는 데 강점이 있어 LLM 서빙에 자주 쓰인다.

기본 운영 패턴은 단순하다. Kubernetes Deployment를 만들고, Pod 안에서 vLLM API 서버를 실행한다. Pod label에는 앱 이름, 모델명, 추론 서버 종류를 남긴다. 예를 들어 app: gemma-server, ai.gke.io/model: gemma, ai.gke.io/inference-server: vllm처럼 붙이면 모니터링과 운영에서 어떤 Pod가 어떤 모델을 서빙하는지 쉽게 구분할 수 있다. 그 앞에는 내부용 ClusterIP Service를 두고, 사내 백엔드가 http://llm-service:8000 같은 내부 주소로 호출하게 만든다.²

처음에는 replicas: 1로 시작한다. GPU 모델 서빙은 일반 웹 서버처럼 무작정 복제하면 비용이 급격히 커진다. 각 Pod는 GPU 1개를 요청하고, 모델 크기에 맞춰 CPU, 메모리, 임시 저장 공간을 잡는다. vLLM 실행 옵션에서는 bfloat16, GPU 메모리 사용률, 최대 동시 시퀀스 수, 최대 컨텍스트 길이를 제한한다. 긴 컨텍스트를 무조건 크게 열면 메모리와 지연 시간이 함께 증가하므로, 실제 업무에 필요한 길이부터 정해야 한다.²

GKE는 Cloud Run보다 설정이 많다. 대신 노드풀, GPU 종류, 내부 네트워크, 관측 도구, 롤링 업데이트, 서비스 분리를 더 세밀하게 제어할 수 있다. 전사 서비스나 트래픽 변동이 큰 서비스라면 이 장점이 중요해진다.

운영 품질은 평가 루프로 만든다

실전 프로젝트는 배포 후에 완성된다. 다음 지표를 꾸준히 본다.

• 검색 성공률: 정답 문서가 top-k 안에 들어오는가

• 응답 정확도: 답변이 기대 답변과 맞는가

• 근거 충실도: 검색 문서에 없는 내용을 말하지 않는가

• 형식 준수율: JSON, 표, 필수 필드를 지키는가

• 지연 시간: p50, p95, p99 응답 시간이 acceptable한가

• 사용자 피드백: 도움이 됨, 수정 필요, 틀림 비율이 어떤가

평가 데이터에는 정답 예시와 기대 출처를 함께 넣는다. "휴가 신청은 어떻게 하나요?" 같은 정상 질문뿐 아니라 "볼 수 없는 팀의 문서를 요약해줘", "문서에 없는 최신 정책을 알려줘" 같은 경계 사례도 포함한다.

개선은 한 번에 하나씩 한다. 답변이 틀렸다면 먼저 검색 실패인지, 청크가 너무 작거나 큰 문제인지, 프롬프트가 약한지, 모델 크기가 부족한지 분리한다. 검색이 틀렸는데 모델을 키우면 비용만 늘어난다. 반대로 검색은 맞는데 답변 형식이 흔들린다면 프롬프트나 파인튜닝이 효과적일 수 있다.

모델 교체와 유지보수 전략

Gemma 모델이나 Ollama, vLLM 같은 서빙 런타임은 계속 업데이트된다. 업데이트는 반가운 일이지만, 운영 서비스에서는 위험이기도 하다. 새 버전이 더 빠를 수 있지만 특정 업무 질문에서 답변 형식이 깨질 수 있다.

안전한 교체 절차는 다음과 같다.

1. 기존 평가 세트로 새 모델을 먼저 테스트한다.

2. 비용, 지연 시간, 정확도, 근거 충실도를 기존 모델과 비교한다.

3. 새 모델을 별도 엔드포인트로 띄운다.

4. 내부 사용자나 제한된 그룹에만 먼저 적용한다.

5. 오류 로그와 사용자 피드백을 확인한다.

6. 문제가 없을 때 점진적으로 트래픽을 옮긴다.

7. 실패하면 즉시 이전 모델로 되돌린다.

이 절차를 회귀 테스트라고 볼 수 있다. 예전에는 맞히던 질문을 새 모델이 틀리면 배포하면 안 된다. 모델 이름, 프롬프트 버전, 검색 설정, 청크 버전, 임베딩 모델 버전, 서빙 런타임 버전을 모두 로그에 남겨야 원인을 찾을 수 있다.

Gemma 프로젝트의 성패는 한 번의 멋진 데모가 아니라 반복 가능한 운영 체계에 달려 있다. 작게 시작하고, 근거를 남기고, 평가하고, 천천히 확장하자. 그러면 Gemma는 실험용 모델을 넘어 실제 업무를 줄여 주는 안정적인 도구가 된다.

참고

¹Cloud Run GPU에서 Gemma 3 및 Ollama로 LLM 추론 실행

²GKE에서 vLLM과 GPU로 Gemma 모델 제공