개발 환경 준비와 실행 경로 선택하기

모델보다 먼저 실행 경로를 정하라

Gemma를 처음 실행할 때 가장 흔한 실수는 "어떤 모델을 받을까?"부터 고민하는 것이다. 실제로는 그보다 먼저 "어디에서, 어떤 목적으로 실행할까?"를 정해야 한다. 같은 Gemma라도 브라우저에서 프롬프트를 시험할 때, 노트북에서 튜토리얼을 따라 할 때, 로컬 PC에서 디버깅할 때, 서버에서 여러 사용자의 요청을 받을 때 필요한 준비가 모두 다르다.

실행 경로를 먼저 정하면 막히는 지점이 줄어든다. 필요한 계정, GPU, 패키지, 인증 토큰, 배포 방식이 명확해지기 때문이다. Gemma는 노트북, 로컬 워크스테이션, Google Cloud, Colab, Kaggle, Vertex AI, GKE, Hugging Face Transformers 같은 여러 환경에서 사용할 수 있다.¹ 선택지가 많다는 것은 장점이지만, 처음에는 오히려 혼란이 될 수 있다.

가장 단순한 기준은 다음과 같다.

처음이라면 빠른 실험과 재현 가능한 개발을 분리하는 것이 좋다. 예를 들어 Colab에서 작은 Gemma 모델을 먼저 실행해 보고, 같은 코드를 로컬 Python 환경으로 옮긴다. 이후 API 서비스가 필요해지면 Cloud Run이나 Vertex AI 같은 배포 환경을 검토한다.

AI 생성 이미지

노트북, 로컬, 클라우드의 역할

Google AI Studio는 프롬프트 감각을 잡는 데 유용하다. 설치 없이 모델의 응답 성향을 빠르게 볼 수 있기 때문이다. 다만 실제 애플리케이션 코드, 모델 파일 관리, 배포 구조를 그대로 검증하는 용도는 아니다.

Colab과 Kaggle Notebook은 첫 실행에 적합하다. GPU 런타임을 선택하고, 필요한 패키지를 설치한 뒤, 모델 허브에서 Gemma를 불러오는 흐름을 쉽게 재현할 수 있다. 단점은 런타임이 일시적이라는 점이다. 세션이 끊기면 설치 상태와 메모리 상태가 사라질 수 있으므로, 중요한 코드는 노트북에 명확히 남기고 데이터와 토큰은 안전하게 관리해야 한다.

Hugging Face Transformers는 PyTorch 기반 개발에 널리 쓰인다. 모델 허브와 연결이 쉽고, 토크나이저, 생성 옵션, 스트리밍, RAG, 평가 코드와 결합하기 좋다. Keras 3, JAX, PyTorch도 Gemma 생태계에서 함께 언급되는 주요 프레임워크다.¹ 이미 팀에서 사용하는 학습·추론 프레임워크가 있다면 그 기준을 우선해도 된다.

로컬 Python 환경은 재현성과 디버깅에 강하다. 가상환경을 만들고 패키지 버전을 고정하면 같은 실험을 반복하기 쉽다. 다만 GPU 드라이버, CUDA, 디스크 용량, 모델 접근 권한 문제를 직접 해결해야 한다.

운영 배포는 별도의 문제다. 사용자가 있는 서비스라면 모델을 단순히 "실행"하는 것을 넘어 인증, 요청 제한, 로그, 장애 대응, 비용, 모니터링까지 고려해야 한다. 이때 Vertex AI, Cloud Run, GKE, vLLM 같은 선택지가 중요해진다.

Vertex AI Model Garden으로 관리형 배포 준비하기

Google Cloud에서 Gemma를 관리형 엔드포인트로 배포하려면 Vertex AI Model Garden을 사용할 수 있다. 이 방식은 모델을 온라인 예측 엔드포인트에 올리고, 애플리케이션이 해당 엔드포인트로 요청을 보내는 구조다. 짧은 지연 시간의 온라인 예측이 필요하고, GPU 자원을 클라우드에서 관리하고 싶을 때 적합하다.²

실행 전 준비는 다음 순서로 점검한다.

1. Google Cloud 프로젝트를 만든다.

2. 결제를 활성화한다.

3. Vertex AI API를 활성화한다.

4. 로컬에 Google Cloud CLI를 설치하고 초기화한다.

5. gcloud auth application-default login으로 애플리케이션 기본 인증을 설정한다.

6. 사용하는 언어의 SDK를 설치한다. Python이라면 google-cloud-aiplatform>=1.64와 protobuf>=5.28 이상을 준비한다.²

그다음 배포 가능한 Gemma 모델을 확인한다.

gcloud ai model-garden models list --model-filter=gemma

모델 ID를 찾았다면 배포 설정을 확인한다.

gcloud ai model-garden models list-deployment-config --model=MODEL_ID

이 명령은 지원되는 머신 타입, GPU 종류, 컨테이너 이미지 같은 정보를 보여준다. 예를 들어 Gemma 3 1B 계열은 g2-standard-12, NVIDIA_L4, GPU 1개 같은 구성이 예시로 제시된다.² 실제 선택은 리전, 할당량, 비용, 모델 크기에 따라 달라진다.

배포는 gcloud ai model-garden models deploy 명령으로 진행한다. 배포가 시작되면 Cloud Console의 Vertex AI 온라인 예측 화면이나 gcloud ai operations describe 명령으로 상태를 확인한다. 배포된 모델은 PredictionServiceClient 같은 클라이언트로 호출할 수 있다.²

Vertex AI는 편리하지만, GPU가 붙은 리소스를 사용하므로 비용이 발생할 수 있다. 테스트가 끝난 엔드포인트는 반드시 정리해야 한다.

Cloud Run에서 Gemma 3를 실행할 때의 판단 기준

Cloud Run은 서버리스 방식으로 컨테이너를 실행하는 환경이다. Gemma 3를 Cloud Run에서 실행할 때는 Google이 제공하는 사전 빌드 컨테이너를 사용할 수 있다. 이미지 형식은 다음과 같다.³

us-docker.pkg.dev/cloudrun/container/gemma/GEMMA_PARAMETER

GEMMA_PARAMETER에는 gemma3-1b, gemma3-4b, gemma3-12b, gemma3-27b 중 하나를 넣는다. 작은 모델은 비용과 시작 시간이 유리하고, 큰 모델은 더 복잡한 요청에 유리하지만 더 많은 메모리와 GPU 여유가 필요하다.

Cloud Run의 예시 구성에는 NVIDIA L4 GPU 1개, CPU 8개, 메모리 32GiB, 동시성 4, 최대 인스턴스 1, 타임아웃 600초 같은 값이 포함된다.³ 이 숫자를 그대로 외울 필요는 없다. 중요한 것은 동시성, 메모리, GPU, 콜드스타트의 관계를 이해하는 것이다.

LLM 서비스는 일반 웹 API보다 무겁다. 요청 하나가 GPU 메모리를 오래 점유할 수 있고, 긴 출력은 응답 시간을 크게 늘린다. Cloud Run은 사용량이 없을 때 인스턴스를 줄일 수 있어 비용 관리에 유리하지만, 첫 요청에서 컨테이너와 모델을 준비하는 콜드스타트가 생길 수 있다. 사용자가 즉시 응답을 기대하는 서비스라면 최소 인스턴스, 모델 크기, 캐시 전략을 함께 검토해야 한다.

Cloud Run 문서는 OLLAMA_NUM_PARALLEL 값과 서비스 concurrency를 맞추는 방식을 권장한다. 동시성이 내부 병렬 처리 수보다 지나치게 크면 요청이 컨테이너 안에서 줄을 서고 지연 시간이 늘 수 있다.³ 처음에는 낮은 동시성으로 시작하고, 실제 부하 테스트 결과를 보며 조정하는 편이 안전하다.

또 하나 중요한 점은 인증이다. Cloud Run의 Gemma 서비스는 기본적으로 공개 API로 열기보다 서비스 간 호출을 전제로 보호하는 구성이 바람직하다. 직접 호출에는 ID 토큰 같은 인증 헤더가 필요할 수 있다.³ 모델 서버를 인터넷에 그대로 노출하지 말고, 백엔드 API 뒤에 두는 구조를 기본으로 생각하자.

하드웨어별 준비: NVIDIA, Apple Silicon, CPU-only

로컬에서 Gemma를 실행한다면 하드웨어에 따라 준비가 달라진다.

NVIDIA GPU가 있다면 CUDA와 프레임워크 호환성이 핵심이다. PyTorch나 JAX가 GPU를 제대로 인식하는지 먼저 확인해야 한다. 드라이버만 설치되어 있어도 프레임워크가 맞지 않으면 CPU로 실행될 수 있다. 첫 테스트에서는 작은 모델과 짧은 프롬프트로 GPU 메모리 사용량을 확인하자.

Apple Silicon 환경에서는 Metal 지원 여부를 살핀다. Keras 3 기반 경로, MLX 기반 도구, Ollama 같은 로컬 실행 도구가 선택지가 될 수 있다. 다만 모든 모델 형식과 모든 최적화가 동일하게 지원되는 것은 아니다. 모델 카드와 도구 문서를 확인하고, Apple Silicon에서 검증된 실행 예제를 우선 사용하는 것이 좋다.

CPU-only 환경에서는 기대치를 낮춰야 한다. 큰 모델을 원활하게 돌리기 어렵기 때문이다. 대신 소형 모델, 양자화 모델, llama.cpp, Ollama 같은 경량 실행 방식을 우선 검토한다. 양자화는 모델을 더 낮은 비트 수로 줄여 메모리 사용량을 낮추는 방법이다. 품질이 조금 떨어질 수 있지만, CPU나 노트북 환경에서는 현실적인 출발점이 된다.

도구 체인은 역할로 고른다

도구 선택은 취향보다 역할로 나눠야 한다.

Transformers는 Python 애플리케이션에서 Gemma를 직접 불러오고 제어하고 싶을 때 좋다. 토크나이저, 생성 파라미터, 모델 허브 연동이 자연스럽고, RAG나 평가 코드와 결합하기 쉽다.

Keras 3, JAX, PyTorch는 개발 프레임워크 선택지다. 연구 코드, 파인튜닝, 실험 재현성을 중시한다면 팀의 기존 스택에 맞추는 것이 좋다.

Ollama와 llama.cpp는 로컬 간편 실행에 강하다. 복잡한 Python 코드 없이 모델을 받아 실행하거나, 양자화 모델을 노트북과 데스크톱에서 시험하기 좋다. 대신 세밀한 학습 루프나 대규모 추론 서버 최적화에는 한계가 있을 수 있다.

vLLM은 GPU 기반 고성능 추론 서버에 적합하다. 여러 요청을 효율적으로 처리하고, 배치 처리와 캐시 활용을 통해 처리량을 높이고 싶을 때 검토한다. Cloud Run이나 GKE 같은 배포 환경에서 모델 서버 역할로 사용할 수 있다.

정리하면, 첫 실험은 Colab이나 Ollama, 개발은 Transformers나 Keras, 운영 추론은 Vertex AI·Cloud Run·GKE·vLLM 쪽으로 확장하는 흐름이 자연스럽다.

실행 전 체크리스트

Gemma를 내려받거나 배포하기 전에 다음 항목을 확인하자.

• 사용할 모델명이 정확한가?

• instruction-tuned 모델이 필요한 작업인가, base 모델이 필요한 작업인가?

• 모델 카드에서 입력 형식, 지원 프레임워크, 권장 사용법을 확인했는가?

• 라이선스와 사용 제한을 읽었는가?

• Hugging Face, Kaggle, Vertex AI Model Garden 등 사용 경로별 약관 동의와 접근 권한을 처리했는가?

• 인증 토큰을 코드에 직접 쓰지 않고 환경 변수나 secret으로 관리하는가?

• 체크포인트 형식이 현재 도구와 호환되는가?

• GPU 메모리, 디스크 용량, 네트워크 다운로드 제한을 확인했는가?

• 클라우드 배포라면 리전, GPU 할당량, 비용, 엔드포인트 삭제 방법을 알고 있는가?

이 체크리스트를 건너뛰면 첫 실행은 모델 문제가 아니라 환경 문제로 멈춘다. 반대로 실행 경로를 먼저 정하고 도구 체인을 맞추면 Gemma 사용은 훨씬 단순해진다. 작은 모델로 짧게 성공한 뒤, 모델 크기와 컨텍스트 길이, 배포 환경을 단계적으로 키우는 것이 가장 안전한 출발점이다.

참고

¹Gemma is now available on Google Cloud

²Vertex AI Model Garden Gemma deployment tutorial

³Run Gemma 3 on Cloud Run