실습용 VM에서 상시 실행 에이전트로: Google Cloud 배포 판단 가이드

결론부터

Google Cloud에서 AI 에이전트를 실행하는 것은 가능하다. 다만 Google Cloud Skills Boost의 GSP001 실습에서 제공되는 25분짜리 VM은 영구 호스트가 아니다. 이 VM은 Compute Engine의 기본 흐름을 익히는 학습 환경이지, 에이전트 프로세스를 계속 켜 두는 운영 환경이 아니다.

따라서 실습을 마친 뒤에도 에이전트를 실행하려면 별도의 Google Cloud 프로젝트에서 운영 자원과 접근 정책을 다시 설계해야 한다. 핵심은 “실습 VM을 어떻게 계속 살려 둘까?”가 아니라 “내가 유지할 수 있는 환경에서 에이전트의 실행 방식을 어떻게 선택할까?”라는 질문이다.

GSP001에서 실제로 배운 것

GSP001은 가상 머신을 처음 다루는 사람에게 필요한 흐름을 짧게 보여준다. Google Cloud Console에서 VM을 만들고, gcloud에서도 VM 생성 흐름을 확인한다. 운영 환경을 완성하는 튜토리얼은 아니지만, 다음 작업의 연결을 직접 확인할 수 있다는 점이 중요하다.

• Debian 이미지를 선택해 VM을 생성한다.
• 콘솔이나 gcloud를 사용해 VM에 SSH로 접속한다.
• VM 안에서 NGINX를 설치하고 웹 서버를 실행한다.
• 외부에서 웹 페이지에 접근할 수 있도록 포트 80을 허용하는 방화벽 노출을 확인한다.

이 과정은 “클라우드에 있는 컴퓨터”라는 개념을 구체화한다. 프로젝트 안에 VM이 생기고, 운영체제에 로그인하며, 프로세스를 실행하고, 네트워크 규칙에 따라 외부 요청이 들어온다. 에이전트도 결국 이 실행 환경 위에서 동작한다. 다만 실습에서 확인한 생성·접속·노출의 흐름과, 실제 서비스를 계속 운영하는 일은 같은 문제가 아니다.

실습 VM을 계속 쓸 수 없는 이유

첫째, 실습에는 제한된 타이머가 있다. GSP001의 25분은 VM을 영구적으로 임대하는 시간이 아니라 학습을 수행하는 시간이다. 타이머가 끝나면 실습 환경에 대한 접근이 종료되거나 리소스가 정리될 수 있으므로, 그 안에서 실행한 프로세스와 로컬 파일을 상시 운영 자원으로 가정할 수 없다.

둘째, 로그인에 사용하는 자격 증명은 학습자를 위한 임시 자격 증명이다. 이 계정과 권한은 실습 범위에 맞춰 제공되며, 개인 프로젝트의 운영 계정처럼 계속 보관하고 사용할 수 있는 전제가 아니다. API 키나 서비스 계정 키를 실습 VM에 남겨 두는 것도 피해야 한다.

셋째, VM과 방화벽 규칙 같은 리소스는 실습이 만든 범위 안에 있다. 리소스 이름이나 IP 주소를 기억해 두었다고 해서 내 Google Cloud 프로젝트의 자산이 되는 것은 아니다. 실습이 알려 주는 것은 VM을 만들고 접근하는 기본 원리이며, 지속적인 저장·재시작·보안·비용 관리는 별도로 준비해야 한다.

상시 운영으로 바꾸면 무엇이 달라지는가

상시 운영의 첫 경계는 계정과 결제다. 개인 또는 조직의 Google Cloud 프로젝트를 만들고, 어떤 사용자가 비용과 리소스를 책임지는지 정해야 한다. Skills Boost 학습자 계정과 내 프로젝트의 계정·권한·리소스를 섞어 생각하면 안 된다. 구체적인 가격을 미리 단정하기보다, 사용할 컴퓨트·디스크·네트워크 리소스와 모델 API 사용량이 예산에 반영된다는 사실을 먼저 확인해야 한다.

그 다음에는 프로세스가 터미널 세션에 묶이지 않도록 해야 한다. SSH 창을 닫았을 때 에이전트가 끝나는 구조는 운영이 아니다. VM에서는 systemd 같은 프로세스 감독 도구를 사용해 재부팅과 장애 뒤의 동작을 정의할 수 있고, 컨테이너를 선택한다면 컨테이너 재시작 정책을 운영 규칙으로 둘 수 있다. 에이전트 종류가 정해지지 않은 단계에서는 특정 런타임 설치 명령보다 이런 실행 계약을 먼저 정하는 편이 안전하다.

상태를 어디에 둘지도 정해야 한다. 에이전트의 작업 기록, 큐, 업로드 파일, 설정이 재시작 뒤에도 필요하다면 영구 디스크나 데이터베이스를 사용하고 백업 방법을 마련해야 한다. 컨테이너나 임시 파일 시스템에만 상태를 두면 인스턴스 교체나 재배포 때 잃을 수 있다.

비밀값은 코드와 이미지에 넣지 않는다. 모델 API 키와 기타 자격 증명은 Secret Manager 같은 비밀 관리 경로에 보관하고, 에이전트가 실제로 필요한 범위만 읽도록 최소 권한의 서비스 계정을 사용한다. SSH 접근, 방화벽, 서비스 계정은 각각 별도의 경계로 검토해야 한다.

마지막으로 포트 80을 열어 웹 페이지가 보였다는 사실은 운영 완료를 뜻하지 않는다. 실제 요청을 받을 엔드포인트에는 HTTPS와 인증을 적용하고, 누가 어떤 작업을 호출할 수 있는지 정한다. 공개 네트워크에 노출된 에이전트는 모델 API 호출이나 파일 처리 권한까지 함께 노출할 수 있으므로, 로그와 실패 경로도 운영 범위에 포함해야 한다.

Compute Engine과 Cloud Run 비교

두 서비스 중 하나가 항상 정답인 것은 아니다. 에이전트의 프로세스 수명과 상태 관리 방식, 브라우저 사용 여부, 운영팀이 감당할 작업을 기준으로 고른다.

기준	Compute Engine	Cloud Run
프로세스 수명	VM 안에서 오래 실행되는 프로세스와 재시작 정책을 직접 설계한다.	요청을 처리하는 컨테이너를 중심으로 설계하며, 상시 프로세스를 VM처럼 유지하는 모델은 아니다.
로컬 상태	영구 디스크를 붙여 파일을 보존하고, 백업·복구 절차를 함께 정한다.	컨테이너 로컬 파일을 영구 상태로 가정하지 않고 외부 저장소에 상태를 둔다.
브라우저 자동화	긴 작업이나 지속적인 브라우저 프로세스가 필요할 때 선택하기 쉽다.	요청 안에서 끝나는 짧은 자동화에 맞추고 세션 상태를 외부화하는 설계가 필요하다.
운영 작업	운영체제 패치, 방화벽, 프로세스 감독, 디스크와 로그를 직접 관리한다.	컨테이너 이미지와 서비스 설정, 인증과 로그에 집중하되 요청 단위 제약을 반영한다.
적합한 시작점	장시간 실행 작업, 브라우저 자동화, 내구성 있는 로컬 파일이 필요한 에이전트	무상태 요청 기반 API 에이전트와 호출이 있을 때 처리하면 되는 작업

24시간 실행과 언제든 호출 가능은 다르다

“언제든 호출할 수 있다”는 말이 “VM에서 프로세스를 24시간 실행한다”는 뜻은 아니다. 사용자가 HTTPS 요청을 보낼 때만 에이전트가 일을 시작하고, 결과를 외부 저장소에 기록하는 무상태 서비스라면 요청 기반 배포가 더 자연스러울 수 있다. 이 경우 서비스는 요청을 처리하는 동안 컨테이너를 사용하도록 설계할 수 있고, 아무 요청도 없는 시간까지 별도의 VM 프로세스를 계속 유지할 필요는 없다.

반대로 긴 작업이 중간에 끊기면 안 되거나, 브라우저 세션·로컬 파일·특정 프로세스를 계속 유지해야 한다면 “요청이 올 때 시작”만으로는 부족하다. 이때는 Compute Engine 같은 VM의 수명과 저장소를 직접 관리하는 편이 맞을 수 있다. 중요한 것은 24시간이라는 표현을 가용성, 프로세스 지속성, 요청 응답성 중 무엇을 의미하는지 나눠 적는 것이다.

API 모델과 로컬 모델

모델을 직접 호스팅하지 않고 외부 모델 API를 호출하는 에이전트라면, 일반적인 CPU VM에서 애플리케이션을 시작하고 네트워크로 모델 API를 호출하는 구성을 먼저 검토할 수 있다. 이때 VM의 역할은 모델 추론기가 아니라 에이전트 프로세스와 도구 호출을 실행하는 호스트다. API 자격 증명은 코드에 하드코딩하지 않고 비밀 관리 체계로 전달해야 한다.

반대로 모델을 VM 안에서 직접 실행하려면 필요한 메모리와 연산 자원을 따져야 한다. 모델 규모와 사용 방식에 따라 GPU가 필요할 수 있으며, 일반 CPU VM에서 시작하는 API 호출형 구성보다 비용과 운영 복잡도가 크게 높아질 수 있다. 특정 가격이나 성능 수치를 정해 두기보다, 실행하려는 모델과 트래픽을 확정한 뒤 자원과 예산을 검증해야 한다.

최소 아키텍처

아래 구조는 어떤 에이전트 프레임워크를 선택하든 먼저 점검할 수 있는 최소 경계다.

사용자
  ↓ HTTPS + 인증
NGINX 또는 API 엔드포인트
  ↓
에이전트 프로세스
  ├─ 모델 API
  ├─ 영구 디스크 또는 데이터베이스
  └─ 필요한 Google Cloud 서비스

여기서 NGINX는 선택 가능한 진입점일 뿐이다. Cloud Run의 서비스 엔드포인트를 사용하든 VM 앞에 프록시를 두든, HTTPS·인증·권한 검사는 에이전트의 실제 작업 범위에 맞게 적용해야 한다.

운영 체크리스트

배포 전에 다음 질문에 답할 수 있어야 한다.

• 에이전트의 런타임과 호출 인터페이스를 정했는가?
• 이 작업은 VM과 Cloud Run 중 어느 실행 모델에 더 잘 맞는가?
• 재시작 뒤에도 필요한 영구 데이터를 디스크나 데이터베이스에 두었는가?
• systemd 또는 컨테이너 재시작 정책을 정의했는가?
• 모델 API 키와 비밀값을 Secret Manager로 관리하는가?
• 서비스 계정에 최소 권한만 부여했는가?
• HTTPS와 인증을 적용했는가?
• 에이전트·프록시·클라우드 작업의 로그를 확인할 수 있는가?
• 중요한 데이터와 설정의 백업·복구 절차가 있는가?
• 프로젝트에 예산과 예산 알림을 설정했는가?

다음 단계

처음 배포하는 무상태 요청 기반 에이전트라면 Cloud Run에서 시작하는 구성이 간단하다. 긴 작업, 브라우저 자동화, 내구성 있는 로컬 파일이 필요한 에이전트라면 Compute Engine을 선택하고 프로세스·디스크·보안·로그를 직접 운영한다.

어느 쪽이든 다음 단계는 실행할 에이전트의 런타임과 외부 인터페이스를 구체화하는 일이다. 그 정보가 정해지면 필요한 이미지, 재시작 정책, 저장소, 인증 방식을 좁혀 갈 수 있다. GSP001에서 배운 VM 생성과 SSH는 좋은 출발점이지만, 상시 운영은 내 프로젝트의 계정·예산·상태·보안 경계까지 설계했을 때 시작된다.