Model Garden 선택과 Gemini 앱 최적화

로우코드 섹션의 마지막 조각은 「이미 학습된 생성 모델을 골라 제품에 붙이는 길」입니다. 03편이 SQL로 모델을 만들었고 04편이 AutoML과 기성 API를 봤다면, 여기서는 고르는 기준과 고른 뒤의 운영을 봅니다. 시험이 이 자리에서 묻는 것은 「어느 모델이 더 똑똑한가」가 아니라 「이 요구사항에 비용·지연·경계를 어떻게 맞출 것인가」입니다.

Model Garden

모델 카드

Model Garden은 Google Cloud에서 바로 쓸 수 있는 모델을 모아 둔 카탈로그입니다. 항목마다 모델 카드가 붙어 있고, 거기에 그 모델이 다루는 모달리티·권장 용도·컨텍스트 창 크기·라이선스·튜닝 가능 여부가 적혀 있습니다. 카드를 읽지 않고 이름만 보고 고르면 라이선스나 배포 방식에서 막히는 일이 생깁니다.

카드에서 바로 이어지는 행동이 셋입니다 — 그대로 호출하기, 튜닝하기, 엔드포인트에 배포하기. 어느 것이 가능한지는 모델마다 다르고, 그 차이가 곧 다음 절의 갈림입니다.

모델의 세 출처

「데이터가 우리 VPC 밖으로 나가면 안 된다」·「가중치를 우리가 쥐어야 한다」는 조건이 붙으면 첫 줄은 지워지고 둘째 줄이 남습니다. 반대로 「빨리 붙이고 운영 부담을 지지 않겠다」면 첫 줄입니다.

선택의 네 축

시험 문항은 보기 넷을 전부 「가능한 모델」로 채워 두고 조건 문장 한둘로 답을 가릅니다. 그 조건이 늘 이 넷 중 하나에 걸립니다.

1. 모달리티. 입력과 출력이 무엇인가. 영상을 만들어야 하면 아무리 좋은 텍스트 모델도 후보가 아닙니다.
2. 품질. 같은 계열 안에서 큰 모델과 작은 모델 중 어느 쪽이 요구 품질을 넘기는가.
3. 비용과 지연. 토큰 단가와 응답 시간. 대개 큰 모델이 비싸고 느립니다.
4. 제약. 라이선스, 데이터 경계, 튜닝 필요 여부, 리전.

생성 모델 세 갈래

Gemini

Gemini는 텍스트·이미지·오디오·영상을 입력으로 받아 텍스트를 내는 다중 모달 모델입니다. 이 시험에서 「생성형 AI」라고 하면 기본값이 여기이고, 요약·분류·추출·대화·코드 생성이 전부 이 모델의 자리입니다. 입력이 이미지나 영상이어도 출력이 글이면 Gemini입니다.

Imagen

Imagen은 이미지를 만들고 고치는 모델입니다. 글로 설명한 장면을 그리는 생성, 지운 자리를 채우는 인페인팅, 배경을 바꾸는 편집, 해상도를 올리는 업스케일이 이쪽입니다. 「사진 속에 무엇이 있는지 알아내라」는 Imagen이 아니라 Vision API나 Gemini입니다 — 만드는 쪽과 읽는 쪽이 다릅니다.

Veo

Veo는 글이나 이미지를 받아 영상을 만드는 모델입니다. 셋을 가르는 질문은 하나로 줄어듭니다 — 무엇이 나오는가. 글이 나오면 Gemini, 그림이 나오면 Imagen, 영상이 나오면 Veo입니다.

서비스형 모델

관리형 API

서비스형 모델(models as a service)은 모델을 호출하는 API만 쓰고 그 모델이 도는 기계를 내가 갖지 않는 방식입니다. 엔드포인트를 만들 것도, GPU를 고를 것도, 오토스케일링을 설정할 것도 없고 요금은 처리한 토큰 수로 매겨집니다.

from google import genai

client = genai.Client(vertexai=True, project="my-proj", location="us-central1")

resp = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="다음 리뷰의 감정을 긍정/부정/중립 중 하나로만 답하세요:\n배송이 하루 만에 왔습니다.",
)
print(resp.text)

위 코드에 서버도 엔드포인트도 없다는 것이 이 방식의 정의입니다. 요청이 없는 시간에는 요금도 0입니다.

자체 배포

반대쪽은 Model Garden에서 고른 오픈 웨이트 모델을 엔드포인트에 배포해 내 자원 위에서 돌리는 방식입니다. 머신 타입과 가속기를 고르고 복제본 수를 정하며, 요금은 토큰이 아니라 뜬 시간으로 매겨집니다.

트래픽이 하루 몇 건인 사내 도구에 GPU 엔드포인트를 띄우는 보기는 이 표의 둘째 줄 때문에 오답이 됩니다.

컨텍스트 캐싱과 배치 예측

컨텍스트 캐싱

같은 앞부분을 매 요청에 다시 실어 보내는 패턴이 있습니다 — 수백 쪽짜리 매뉴얼을 붙이고 질문만 바꾸는 챗봇이 그렇습니다. 컨텍스트 캐싱은 그 변하지 않는 앞부분을 한 번 올려 두고 이후 요청은 캐시를 가리키게 하는 기능입니다.

from google.genai import types

cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(contents=[manual_text], ttl="3600s"),
)

resp = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="환불 기한은 며칠인가요?",
    config=types.GenerateContentConfig(cached_content=cache.name),
)

캐시된 부분의 입력 토큰은 매번 새로 보내는 것보다 싼 단가로 매겨지고, 대신 캐시를 유지하는 동안 저장 요금이 따로 붙습니다. 그래서 같은 맥락을 여러 번 재사용할 때만 이득입니다. 요청마다 맥락이 통째로 다른 워크로드에 캐싱을 붙이는 보기는 저장 요금만 더하는 셈입니다. ttl은 그 캐시가 살아 있는 시간입니다.

배치 예측

기다리는 사용자가 없는 작업은 배치 예측으로 돌립니다. 입력을 Cloud Storage나 BigQuery에 통째로 두고 작업을 제출하면, 플랫폼이 여유 있는 시간에 처리해 결과를 같은 방식으로 내놓습니다.

job = client.batches.create(
    model="gemini-2.5-flash",
    src="bq://my-proj.reviews.to_score",
    config=types.CreateBatchJobConfig(dest="bq://my-proj.reviews.scored"),
)

배치는 온라인 호출보다 단가가 낮은 대신 즉시 응답하지 않습니다. 「어젯밤 들어온 리뷰 50만 건을 아침까지 분류해 두라」는 요구에 온라인 호출을 50만 번 도는 보기가 오답인 이유가 여기 있습니다. 반대로 사용자가 화면에서 기다리는 요구에 배치를 붙이는 것도 같은 잘못입니다.

지연 시간과 가용성

동적 공유 할당량

종량제로 서비스형 모델을 부르면 그 용량은 여러 고객이 함께 쓰는 몫에서 나옵니다. 이것을 동적 공유 할당량이라 부르고, 프로젝트마다 분당 요청 수가 고정으로 잡혀 있는 것이 아니라 그때그때 나눠 씁니다. 평소에는 넉넉하지만 몰리는 시간에는 용량 부족 오류를 받을 수 있고, 그래서 재시도와 백오프가 애플리케이션 쪽의 기본 준비물이 됩니다.

프로비저닝된 처리량

용량 부족을 「재시도로 넘기는 것」이 아니라 「일어나지 않게 하는 것」이 요구라면 프로비저닝된 처리량을 삽니다. 일정 기간 동안 처리량을 예약하고 고정 요금을 내는 방식이라, 그만큼의 트래픽은 공유 몫과 무관하게 보장됩니다.

예약분을 넘긴 트래픽을 종량제로 흘려보낼지 거절할지도 고를 수 있습니다. 「급증에도 응답을 보장해야 한다」와 「비용을 최소로」는 같은 문항에 함께 못 오는 요구이고, 어느 쪽이 조건 문장으로 적혀 있는지가 답을 정합니다.

리전

모델을 부르는 리전은 지연 시간과 규정을 함께 건드립니다. 사용자와 가까운 리전이 왕복 시간을 줄이지만, 「데이터가 특정 국가를 벗어나면 안 된다」는 조건이 있으면 그 조건이 먼저입니다. 리전마다 쓸 수 있는 모델이 다르다는 것도 함께 봐야 합니다 — 고른 모델이 그 리전에 없으면 선택 자체가 성립하지 않습니다.

연습 문제

1. 제품 설명 문구에 어울리는 배경 이미지를 생성해야 합니다. 알맞은 모델은?
   ① Gemini
   ② Imagen
   ③ Veo
   ④ Document AI

   ②. 출력이 이미지입니다. ①은 글을 내고 ③은 영상을 냅니다.
2. 업로드된 사진에 어떤 사물이 있는지 설명하는 문장을 받아야 합니다. 알맞은 것은?
   ① Imagen
   ② Veo
   ③ Gemini
   ④ Vizier

   ③. 입력이 이미지여도 출력이 글이면 Gemini입니다. ①은 이미지를 만드는 쪽이라 읽는 과제와 방향이 반대입니다.
3. 다음 코드가 하는 일로 옳은 것은?

   cache = client.caches.create(
       model="gemini-2.5-flash",
       config=types.CreateCachedContentConfig(contents=[manual_text], ttl="3600s"),
   )

   ① 모델을 파인튜닝한다
   ② 반복해 쓰는 맥락을 올려 두고 한 시간 동안 재사용할 수 있게 한다
   ③ 응답을 캐시해 같은 질문에 같은 답을 돌려준다
   ④ 배치 예측 작업을 제출한다

   ②. 캐시되는 것은 응답이 아니라 입력 맥락이고 ttl이 그 캐시의 수명입니다. ③처럼 응답을 저장하는 기능이 아닙니다.
4. 사내 문서 3만 건을 주제별로 분류해 BigQuery에 적재하려 합니다. 오늘 밤에 시작해 내일 아침까지 끝나면 되고 비용을 최소로 하고 싶습니다. 알맞은 것은?
   ① 온라인 호출을 3만 번 돈다
   ② 배치 예측 작업을 제출한다
   ③ 프로비저닝된 처리량을 한 달 예약한다
   ④ 오픈 웨이트 모델을 GPU 엔드포인트에 배포한다

   ②. 기다리는 사용자가 없고 입력이 통째로 있습니다. ③은 한 번 쓰는 일에 기간 요금을 내고, ④는 뜬 시간만큼 요금이 나갑니다.
5. 하루 평균 20건, 사용자가 화면에서 기다리는 사내 요약 도구를 만듭니다. 비용을 최소로 하려면?
   ① 오픈 웨이트 모델을 GPU 엔드포인트에 상시 배포한다
   ② 서비스형 모델을 종량제로 호출한다
   ③ 프로비저닝된 처리량을 예약한다
   ④ 배치 예측으로 돌린다

   ②. 트래픽이 없는 시간에 요금이 0인 유일한 보기입니다. ①과 ③은 쓰지 않는 시간에도 요금이 나가고, ④는 기다리는 사용자가 있어 성립하지 않습니다.
6. 상담 챗봇이 요청마다 같은 200쪽 매뉴얼을 프롬프트 앞에 붙입니다. 토큰 비용을 줄이는 방법은?
   ① 배치 예측으로 바꾼다
   ② 매뉴얼을 컨텍스트 캐싱으로 올려 두고 요청은 캐시를 가리킨다
   ③ 프로비저닝된 처리량을 예약한다
   ④ 리전을 사용자와 가까운 곳으로 옮긴다

   ②. 변하지 않는 앞부분이 매 요청마다 되풀이되는 전형적인 캐싱 자리입니다. ③은 용량을 보장할 뿐 보내는 토큰 수를 줄이지 않고, ④는 지연 시간 이야기입니다.
7. 블랙프라이데이에 평소의 열 배 트래픽이 예상되고, 그 시간에 용량 부족으로 실패하면 안 됩니다. 알맞은 준비는?
   ① 동적 공유 할당량을 그대로 쓰고 재시도만 넣는다
   ② 프로비저닝된 처리량을 예약한다
   ③ 컨텍스트 캐싱을 켠다
   ④ 배치 예측으로 전환한다

   ②. 공유 몫은 이름 그대로 보장되지 않습니다. ③은 비용을 줄이는 기능이고 ④는 실시간 요구를 버리는 선택입니다.
8. 모델을 고를 때 조건 문장이 「가중치를 우리 환경 안에 두고 VPC 밖으로 데이터가 나가면 안 된다」입니다. 지워지는 보기는?
   ① Gemma를 엔드포인트에 배포한다
   ② Llama를 엔드포인트에 배포한다
   ③ Gemini를 서비스형 모델로 호출한다
   ④ 오픈 웨이트 모델을 파인튜닝해 배포한다

   ③. 서비스형 모델은 가중치에 접근할 수 없고 호출이 관리형 API를 지납니다. 나머지 셋은 모두 가중치를 쥐는 쪽입니다.