Cloud Run에 LLM 앱 배포하기 — 요청 없으면 0원인 서버리스 백엔드

앱이나 웹에서 Claude 같은 LLM API를 쓰려면 API 키를 클라이언트에 심을 수 없으니 중간에 서버가 하나 필요하다. 문제는 이 프록시 서버 하나 때문에 상시 가동 VM을 돌리자니 비용이 아깝다는 것이다. Cloud Run은 이 상황에 거의 정확히 맞는 답이다. 컨테이너를 올려 두면 요청이 올 때만 인스턴스가 기동되고, 요청이 없으면 0개로 줄어 비용도 0원이 된다. LLM 백엔드를 Cloud Run에 배포하면서 밟은 순서 그대로 정리한다.

왜 Cloud Run인가 — 요청 없을 때 0원

Cloud Run 과금 방식

Cloud Run의 기본 과금 방식은 요청을 처리하는 동안의 CPU·메모리 사용 시간과 요청 수 기준이다. 트래픽이 없으면 인스턴스가 0개까지 줄어들기 때문에(scale to zero) 개인 프로젝트나 초기 서비스처럼 트래픽이 들쭉날쭉한 워크로드에서 유리하다. 여기에 HTTPS 엔드포인트가 기본으로 제공되고, Dockerfile만 있으면 어떤 언어·프레임워크든 그대로 올릴 수 있다. LLM 프록시 서버는 대부분의 시간을 모델 응답 대기(I/O)에 쓰는 가벼운 워크로드라 서버리스와 궁합이 좋다.

컨테이너 준비 — FastAPI 프록시와 Dockerfile

예제는 Claude API를 대신 호출해 주는 최소한의 FastAPI 앱이다. main.py부터 만든다.

import anthropic
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()
client = anthropic.Anthropic()  # ANTHROPIC_API_KEY 환경변수를 자동 사용

class ChatRequest(BaseModel):
    message: str

@app.post("/chat")
def chat(req: ChatRequest):
    response = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=512,
        messages=[{"role": "user", "content": req.message}],
    )
    return {"reply": response.content[0].text}

requirements.txt에는 fastapi, uvicorn, anthropic 세 줄을 넣는다. Dockerfile은 다음과 같다.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]

포트가 핵심이다. Cloud Run은 컨테이너가 PORT 환경변수(기본값 8080)로 들어오는 HTTP 요청을 받길 기대한다. 8080을 리슨하지 않으면 배포가 실패하거나 헬스체크에서 걸린다.

배포 명령과 환경변수·시크릿

Cloud Run에 LLM 백엔드 배포 3단계

배포는 명령 한 줄이다. --source .를 쓰면 로컬 소스를 올려 Cloud Build가 컨테이너 빌드까지 대신해 준다.

gcloud run deploy llm-backend \
  --source . \
  --region asia-northeast3 \
  --allow-unauthenticated

리전은 사용자와 가까운 곳을 고른다. 국내 사용자 대상이라면 서울 리전(asia-northeast3)이 무난하다. 처음 배포하면 Cloud Build·Artifact Registry 등 필요한 API를 활성화하겠냐는 확인이 나오는데 그대로 진행하면 된다. 빌드가 끝나기까지 몇 분 정도 걸린다.

배포가 끝나면 https://...run.app 형태의 URL이 발급된다. 이제 API 키를 넣을 차례인데, 키를 --set-env-vars로 평문 저장하는 것은 피하고 Secret Manager를 쓴다.

printf '%s' 'your-api-key' | gcloud secrets create anthropic-key --data-file=-

gcloud run services update llm-backend \
  --region asia-northeast3 \
  --set-secrets=ANTHROPIC_API_KEY=anthropic-key:latest

서비스가 쓰는 서비스 계정에 Secret Manager 보안 비밀 접근자(roles/secretmanager.secretAccessor) 역할이 있어야 시크릿을 읽을 수 있다. 권한 오류가 나면 이것부터 확인한다. 그리고 --allow-unauthenticated는 말 그대로 전 세계에 열리는 옵션이므로, 실서비스라면 자체 토큰 검증이나 IAM 인증을 붙여 아무나 내 API 키로 LLM을 쓰지 못하게 막아야 한다.

콜드스타트와 동시성 설정

인스턴스가 0개인 상태에서 첫 요청이 오면 컨테이너가 새로 뜨는 시간, 즉 콜드스타트가 생긴다. 가벼운 Python 앱이면 수 초 안쪽이지만 첫 사용자 경험에는 영향을 준다. LLM 백엔드에서 실제로 만지게 되는 설정은 세 가지다.

  • 동시성(concurrency): 인스턴스 하나가 동시에 받는 요청 수로 기본값은 80이다. LLM 프록시는 응답 대기가 대부분이라 동시성을 높게 유지해도 CPU가 놀기 때문에 기본값 언저리로 두는 것이 비용에 유리하다.
  • 타임아웃: 긴 프롬프트는 응답에 수십 초가 걸릴 수 있다. 기본 타임아웃이 짧다고 느껴지면 --timeout=300처럼 늘린다. 스트리밍 응답을 구현하면 체감 대기도 줄어든다.
  • 최소 인스턴스: --min-instances=1로 두면 콜드스타트가 사실상 사라지지만, 유휴 시간에도 인스턴스 유지 비용이 발생해 "요청 없으면 0원"이라는 장점과 맞바꾸게 된다.
gcloud run services update llm-backend \
  --region asia-northeast3 \
  --concurrency 80 --timeout 300 --memory 512Mi

앱에서 붙일 때는 발급된 URL의 /chat 엔드포인트로 JSON을 보내면 끝이다. 클라이언트 입장에서는 그냥 HTTP API 하나가 생긴 것이라 Flutter든 웹이든 연동 방식이 다르지 않다. 응답이 느리게 느껴진다면 서버 쪽에서 모델을 더 빠른 등급으로 바꾸거나 스트리밍으로 전환하는 식으로 백엔드에서만 손보면 되고, 앱을 다시 배포할 필요가 없다는 점도 프록시 구조의 장점이다.

비용 관리와 무료 한도

Cloud Run 월 무료 한도 3종

공식 문서 기준 Cloud Run 무료 한도는 매월 요청 200만 건, CPU 18만 vCPU초, 메모리 36만 GiB초다. 초과분 단가는 Tier 1 리전 기준 요청 100만 건당 0.40달러, vCPU초당 0.000024달러, GiB초당 0.0000025달러 수준이다. 개인 프로젝트의 프록시 서버 트래픽이라면 대부분 무료 한도 안에서 끝난다.

주의할 비용 포인트는 두 가지다. 첫째, 최소 인스턴스를 1 이상으로 두면 유휴 시간에도 과금이 이어지므로 정말 필요할 때만 켠다. 둘째, Cloud Run 요금이 0원이어도 앱이 호출하는 LLM API의 토큰 비용은 별개로 나간다. 전체 비용을 볼 때는 Cloud Run 요금과 모델 사용료를 함께 봐야 한다.

운영 중 상태 확인은 콘솔의 Cloud Run 서비스 화면에서 한다. 요청 수, 지연 시간, 인스턴스 수, 로그를 한 화면에서 볼 수 있어 콜드스타트가 실제로 얼마나 자주 생기는지도 여기서 확인된다. 트래픽이 늘어 인스턴스가 예상보다 많이 뜨면 최대 인스턴스 수(--max-instances)로 상한을 걸어 비용 폭주를 막는 것도 잊지 말자.

정리하면, Dockerfile 하나와 명령 몇 줄로 HTTPS 백엔드가 생기고 트래픽이 없을 땐 비용이 0원에 수렴한다. LLM 앱의 첫 배포처라 치면 Cloud Run보다 부담 없는 선택지를 찾기 어렵다.

함께 보면 좋은 글: 구글 클라우드 API 사용량 실시간 모니터링 방법

※ 이 글의 무료 한도·단가·명령 옵션은 2026년 기준이며 변경될 수 있습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[AI입문]AI 용어 사전 — 토큰, 컨텍스트, 환각... 뜻만 알면 절반은 끝난다

이미지
이 글은 새로 시작하는 AI 입문 연재의 첫 번째 글이다. 이 연재는 AI를 한 번도 써 본 적 없는 사람을 위해 쓴다. 그런데 첫 관문은 기술이 아니라 말이다. 토큰, 컨텍스트, 환각 같은 단어가 설명 없이 튀어나오는 순간부터 글이 읽히지 않는다. 그래서 첫 글에서는 앞으로 계속 나올 용어를 하나씩 짚는다. 용어마다 일상 비유 하나와, 그 말을 알면 무엇이 달라지는지를 붙였다. 외울 필요는 없다. 읽고 나서 "아, 그게 그 말이었구나" 정도만 남아도 충분하다. 대화를 이루는 기본 용어 LLM과 생성형 AI LLM 은 '거대 언어 모델'의 줄임말이다. 어마어마한 양의 글을 읽고 말의 패턴을 익힌 프로그램이라고 보면 된다. 생성형 AI 는 그보다 넓은 말로, 없던 결과물을 새로 만들어 내는 AI 전체를 가리킨다. 글을 만들면 언어 모델, 그림을 만들면 이미지 생성 AI다. 왜 중요한가. 흔히 말하는 'AI 챗봇'은 대부분 LLM, 즉 글을 다루는 데 특화된 도구다. 계산기나 검색 엔진과는 잘하는 일이 애초에 다르다는 뜻이다. 토큰 AI는 글을 글자 단위로 세지 않는다. 토큰 이라는 조각 단위로 센다. 한글은 한 글자가 대략 한 토큰 정도라고 생각하면 크게 어긋나지 않는다. 택배 요금을 무게로 매기듯, AI는 처리량을 토큰으로 잰다. 왜 중요한가. 무료 사용 한도, 유료 요금, 한 번에 넣을 수 있는 문서 분량이 모두 토큰으로 계산된다. "길게 쓰면 비싸진다"는 말의 근거가 여기에 있다. 컨텍스트 윈도우 AI가 한 번에 펼쳐 놓고 볼 수 있는 분량이다. 책상 넓이에 비유할 수 있다. 책상이 넓으면 자료를 여러 개 올려놓고 볼 수 있지만, 좁으면 새 자료를 놓을 때 먼저 있던 것을 치워야 한다. 대화가 길어지면 앞부분이 이 책상에서 밀려난다. 왜 중요한가. 오래 이어 간 대화에서 AI가 갑자기 앞 내용을 잊는 것은 고장이 아니다. 구조상 당연한 일이다. 주제가 바뀌면 새 대화를 여...
자세한 내용 보기

메일 주소 하나 만들려다 브랜드를 세웠다 — 1인 스튜디오 브랜딩 실전기

이미지
메일 주소 하나 만들려다, 브랜드를 통째로 세웠다 1인 스튜디오 브랜딩 실전기 — 도메인 · 메일 · 로고 · 상표 출원까지 직접 해본 기록 시작은 단순했다. " 내이름@내스튜디오.com 같은 전문적인 메일 주소 하나 갖고 싶다." 딱 그거였다. 그런데 그 한 가지 바람이 도메인 선정, 브랜드 네이밍, 상표 검색, 로고 제작, 메일 서버 인증, 상표 출원까지 줄줄이 이어졌다. 결국 1인 개발/콘텐츠 스튜디오 ‘에이븐스튜디오(Aeven Studio)’ 의 기반을 통째로 세우게 됐다. 같은 길을 걸을 다른 1인 창작자들을 위해, 부딪힌 함정과 배운 것을 정리한다. 1. 자체 메일 서버? 결론은 ‘관리형’ 처음엔 멋있어 보여서 메일 서버를 직접 굴려볼까 했다. 알아보니 개인이 자체 발송 서버를 운영하는 건 생각보다 가시밭길이다. 가정용 IP는 대부분 스팸 차단 목록에 기본 등록돼 있어 받는 쪽이 거부한다. 발송 포트(25번)가 막혀 있고, 역방향 DNS(PTR)를 내 맘대로 못 건다. AWS EC2조차 25번 포트가 기본 차단이고 IP 평판이 좋지 않다. 결론: 비즈니스 메일이라면 Google Workspace · Zoho · 네이버웍스 같은 관리형 서비스 가 정답이다. 서버·보안·스팸·도달률이라는 골치 아픈 문제를 통째로 넘길 수 있다. 나는 익숙함과 생태계 통합 때문에 Google Workspace로 정했다. 2. 이름 짓기 — 가장 오래 헤맨 구간 여기서 제일 많이 배웠다. 좋은 이름을 정하는 건 ‘감각’의 문제가 아니라 세 개의 관문을 동시에 통과 시키는 문제였다. 이름 하나가 통과해야 할 세 관문 후보 이름 "이거 어때?" 관문 ① 상표 KIPRIS 검색 내 사업류에 살아있는 유사 상표 없어야 'AI' 등 설명적 단어는 식별력 없음 관문 ② 도메인 진짜 병목 구간 어감 좋은 단어는 .com이 이미 선점됨 해법: .kr/.app 수용 또는 조어(coined word) 관...
자세한 내용 보기

클로드 Fable 5와 Opus 4.8 비교 - 차이점, 가격, 무료 기간 종료 후 변화까지 총정리 (7월 최신)

이미지
2026년 6월 9일, Anthropic이 5세대 모델 가족의 첫 주자인 Claude Fable 5 를 공개했다. 기존 최상위 모델이던 Opus 4.8과 무엇이 다른지, 구독 플랜에서는 어떻게 제공되는지, 그리고 출시 직후 벌어진 접근 중단 사태까지, 실제 사용 과정에서 확인한 내용을 정리한다. 새 모델을 써볼지 고민 중이거나 갑자기 모델 접근 오류를 만난 사람에게 도움이 될 것이다. Fable 5란 어떤 모델인가 Fable 5는 Anthropic의 모델 계층에서 가장 위에 있는 Mythos급(Mythos-class) 모델이다. 기존 계층이 Haiku → Sonnet → Opus 순서였다면, 이제 그 위에 Mythos 등급이 추가된 셈이다. 배경을 보면 Anthropic은 같은 해 4월에 Mythos를 먼저 공개했지만, 고급 사이버보안 능력 때문에 일부 승인된 고객에게만 제한적으로 배포했다. Fable 5는 그 Mythos 기술에 안전장치를 더해 일반 사용자도 쓸 수 있게 만든 버전이다. 함께 발표된 Claude Mythos 5는 여전히 일반 출시되지 않았으며, 두 모델은 본질적으로 같은 기반 모델이다. Fable 5 vs Opus 4.8 - 핵심은 용도의 차이 두 모델의 가장 중요한 차이는 성능 수치가 아니라 용도 다. Fable 5는 모델이 스스로 작업을 분해하고 조사하고 만들고 검증하는 장기 비동기 프로젝트 에 적합하고, Opus 4.8은 복잡한 작업을 사람과 주고받으며 처리하는 빠른 동기적(실시간) 협업 에 적합하다. Fable 5의 강점으로 알려진 내용은 다음과 같다. Claude Code 같은 에이전트 환경에서 며칠 동안 작업을 지속 하며, 단계별로 계획하고 하위 에이전트에 위임하고 자기 작업을 검증한다. 5천만 줄 규모의 Ruby 코드베이스에서, 팀이 수작업으로 2개월 넘게 걸릴 전체 마이그레이션을 하루 만에 수행한 사례가 소개됐다. 파일과 PDF 안에 중첩된 다이어그램·차트·표를 이해하는 비전 능력이 강화되어 금융·법률...
자세한 내용 보기