지난 글들에서는 Sleuth의 코어 로직을 클라이언트에서 분리하여 FastAPI로 백엔드를 구축하고, 이를 GCP Cloud Run이라는 서버리스 인프라에 안착시킨 과정을 정리했다. (Cloud Run의 Scale-to-Zero와 콜드 스타트 최적화에 대한 내용은 이전 포스팅을 참고하길 바란다.)
내부 아키텍처가 갖추어졌으니, 이제 실제 운영 환경의 쏟아지는 트래픽을 견뎌낼 수 있는지 검증할 차례다. 하지만 테스트를 시작하자마자 코드가 아닌 외부 인프라의 물리적 제약에 부딪혔고, 이 글은 그 한계를 Vertex AI의 도입을 통해 극복해나간 과정을 정리해보고자 한다.
프로토타입 제작과 실제 환경의 괴리
초기 백엔드 서버는 접근성이 좋은 일반 Gemini API(Google AI Studio 기반)를 사용하여 구축했다. 바이브코딩으로 유명하기도 하고, 개발자를 위해 만든 툴이니 별 의심없이 바로 적용하여 사용했다. 개발 단계에서 한두 번 요청을 보낼 때는 2~3초 내외로 쾌적하게 동작했기에 아무런 의심을 하지 않았다. 하지만 여러 유저가 동시에 게임을 플레이하는 상황을 가정하여 부하 테스트를 진행하자 심각한 병목 현상이 발생했다.
1분 내에 API 요청을 10번 정도 빠르게 쏘아 올린 순간, 평소 2~3초면 돌아오던 응답 레이턴시(Latency)가 무려 27초까지 치솟았다.
 |
| Problem: RPM Limit |
원인은 명확했다. 퍼블릭 API가 가진 RPM(Requests Per Minute) 제한이었다. 일반 개발자용 API는 전 세계의 수많은 사용자가 자원을 공유하는 구조다. 단기간에 특정 IP나 키에서 요청이 몰리면, API 게이트웨이 단에서 서버 보호를 위해 의도적으로 요청을 지연시키거나 429 Too Many Requests 에러를 반환한다고 한다. Gemini API 공식 문서에 따르면 이와 같은 제한 사항에 대해 명시하고 있다.
사실 Free Tier에 해당하면 문서대로 "그냥 제한에 걸렸구나" 생각하고 넘어가는데, 나름 유료 결제도 등록한 Tier 1임에도 간헐적으로 느려지는 걸 보고 문제 의식을 느꼈다.
 |
| (바이브 코딩의 흔적) |
추리 게임에서 용의자에게 질문을 던졌는데 대답이 27초 뒤에 돌아온다면?... 그 유저는 가차 없이 앱을 삭제할 것이다(내가 답답해서 못참는다). 비즈니스 관점에서 이는 치명적일 것이다.
엔터프라이즈용 GCP Vertex AI 마이그레이션
이 문제를 근본적으로 해결하기 위해, 우리는 LLM 호출 창구를 AI Studio의 일반 API에서 구글 클라우드의 엔터프라이즈 AI 플랫폼인 GCP Vertex AI로 전면 마이그레이션하기로 결정했다. Vertex AI의 가장 큰 특징은 엔터프라이즈 계층에 부여되는 높은 할당량(Quota)을 통해 대규모 트래픽 유입 시에도 Rate Limit 문제없이 안정적인 서비스 제공이 가능하다는 점이다.
이외에도 보안이나 확장성을 고려하면 프로덕션 환경을 위한 Vertex AI의 도입은 당연한 수순이었다. (구글 공식 가이드 참고)
아무튼 그 결과는 수치로 명확하게 증명되었다. gemini-3.1-flash-lite-preview 모델을 기준(추론이 들어가지 않아 비교적 평균 latency가 일정한 모델)으로 이전과 동일하게 1분 내에 다량의 트래픽을 쏟아부어 보았다. Vertex AI 환경에서는 Limit 에러나 Throttling에 전혀 걸리지 않았고, p50 레이턴시를 1957.74ms 수준으로 극적으로 방어해 냈다. (이 수치는 GCP Vertex AI 대시보드를 통해 직접 확인한 실측 데이터다.)
 |
| p50 Latency |
단순히 27초를 2초 미만으로 단축한 것 이상의 의미가 있었다. B2C 서비스에서 사용자에게 일관된 속도의 응답을 보장할 수 있는 엔터프라이즈급 인프라를 확보하게 된 것이다.
Vertex AI의 추가 장점
Vertex AI 도입은 단순히 빠르고 쾌적해졌다는 성능을 넘어, 시스템의 유지보수와 보안 측면에서도 아키텍처의 수준을 한 단계 끌어올려 주었다.
데이터 기반의 의사결정: Observability
기존 AI Studio 기반의 API는 기껏해야 비용과 사용량 정도 볼 수 있었다. 우리 서버에서 LLM으로 요청이 넘어간 이후에는 트래픽이 어떻게 처리되는지는 알지 못했다. Vertex AI로 마이그레이션한 후에는 클라우드 콘솔의 통합 대시보드에서 훨씬 더 세부적인 내용들을 확인할 수 있었다. 이게 엔터프라이즈인가...?
토큰 사용량에 따른 실시간 비용 추적
API 호출 성공률 및 에러율(Error Rate)
p50, p90, p99 등 구간별 레이턴시 분포
이러한 지표를 실시간으로 모니터링할 수 있다는 것은 곧 서비스의 병목을 데이터 기반으로 진단하고 스케일업 시점을 정확히 예측할 수 있는 기반이 될 것이다.
IAM을 통한 키리스(Keyless) 보안 아키텍처
또 중요한 기술적 수확은 보안 구조의 혁신이다. 기존 환경에서는 외부 API와 통신하기 위해 무조건 API Key를 발급받아 환경 변수(.env)나 Secret Manager에 보관해야 했다. 뭐 아직까지 그런 이슈가 없긴 했지만... 요즘 AI agent를 사용하면 자기가 알아서 파일을 읽어버리는 문제가 있어 영 찝찝함이 남는게 사실이다.
하지만 현재 우리의 백엔드는 GCP Cloud Run에서 구동되고 있다. 같은 GCP 생태계 내에 있는 Vertex AI를 호출할 때는 거추장스러운 API Key가 필요 없다. 오직 IAM(Identity and Access Management) 권한 부여만으로 상호 인증이 완료된다.
# 일반 API 방식 (취약점 존재)
# genai.configure(api_key=os.environ["GEMINI_API_KEY"])
# Vertex AI 방식 (Keyless)
import vertexai
from vertexai.generative_models import GenerativeModel
# Cloud Run의 기본 서비스 계정 권한을 자동으로 상속받음
vertexai.init(project="project-id", location="asia-northeast3")
model = GenerativeModel("gemini-3.1-flash-lite-preview")
AI agent로 바이브코딩하다가 혹시나 프로덕션 환경에서 사용되는 Key를 탈취당해버리면 굉장히 큰 이슈가 되므로... 이 점도 서비스 출시 전에 필요한 중대한 사항이라고 생각한다. 드디어 찝찝함이 사라짐..!
마치며
지금까지 프로토타입을 개발해오면서 당장 돌아가는 코드를 짜는 것은 쉬운 일이었지만, 서비스 공개를 앞두고 다수의 유저들을 수용할 수 있는 시스템을 설계하는 것은 전혀 다른 차원의 문제였다.
그런 측면에서 이번 Vertex AI 마이그레이션은 단순히 API 엔드포인트 주소를 하나 바꾼 작업이 아니었다. RPM 제한이라는 상용 서비스에서 발생하면 안되는 문제를 해결하여 Latency를 안정화시켰으며, 실시간 모니터링 체계와 IAM 보안망을 구축했다.
이렇게 구축하고 있는 백엔드 파이프라인이 앞으로 Sleuth가 안정적인 서비스를 제공하기 위해 잘 받쳐주길 바라며.
추천글
[스타트업/기술] FastAPI와 클라우드 네이티브 | 클라이언트 LLM 호출의 한계와 백엔드 전환기 (Part 1)
[스타트업/기술] FastAPI와 클라우드 네이티브 | Cloud Run 도입과 백엔드 전환기 (Part 2)
