얼마 전 작은 웹 서비스를 하나 올릴 일이 있었는데, 로컬에서는 잘 돌아가던 프로젝트가 막상 배포 단계로 가니 선택지가 너무 많아 잠깐 멈칫했습니다. GCP는 이름만 보면 거대한 회사 서버를 다루는 느낌이지만, 실제로는 개인 프로젝트나 작은 팀 서비스도 꽤 가볍게 시작할 수 있는 클라우드입니다.
GCP는 Google Cloud Platform의 줄임말로, 서버, 데이터베이스, 저장공간, AI 도구, 로그 분석 같은 기능을 인터넷에서 빌려 쓰는 서비스라고 생각하면 편합니다. 노트북에 직접 서버를 켜두지 않아도 되고, 사용량이 늘면 자원을 키울 수 있다는 점이 가장 큰 장점입니다. 다만 처음부터 모든 기능을 쓰려고 하면 금방 복잡해집니다. 처음에는 계정, 프로젝트, 권한, 비용 알림, 배포 방식 정도만 잡아도 충분합니다.
GCP 시작은 프로젝트 하나로 나누면 편합니다
GCP에서 가장 먼저 만나는 단위는 프로젝트입니다. 프로젝트는 작업 폴더 같은 개념입니다. 예를 들어 블로그 백엔드, 쇼핑몰 테스트, 회사 내부 도구를 각각 다른 프로젝트로 만들면 비용과 권한을 따로 볼 수 있어 관리가 쉬워집니다.
초보 단계에서는 프로젝트 이름을 너무 멋있게 짓는 것보다 용도를 바로 알 수 있게 만드는 쪽이 낫습니다. 예를 들어 personal-blog-prod, personal-blog-test처럼 운영용과 실험용을 나누면 나중에 헷갈릴 일이 줄어듭니다. 운영용 서버를 만진다고 생각했는데 테스트 서버였거나, 반대로 테스트 중인 코드를 운영 환경에 올리는 실수도 꽤 흔합니다.
- 개인 실습용 프로젝트 1개
- 실제 서비스용 프로젝트 1개
- 테스트와 운영을 구분할 필요가 있으면 2개 이상
처음부터 회사급 구조를 만들 필요는 없습니다. 다만 프로젝트를 하나로 몰아넣으면 비용이 어디서 나가는지 보기 어려워집니다. 한 달 뒤 청구서를 보고 “이게 왜 이렇게 나왔지?” 하는 상황을 피하려면 시작 단계에서 용도별 구분만 해도 훨씬 편합니다.
초보자가 먼저 보면 좋은 GCP 서비스
GCP에는 서비스가 정말 많습니다. 그런데 처음부터 전부 외울 필요는 없습니다. 웹사이트나 API를 올릴 목적이라면 Compute Engine, Cloud Run, Cloud Storage, Cloud SQL 정도만 먼저 익혀도 기본 흐름은 잡힙니다.
Compute Engine
Compute Engine은 가상 서버를 빌리는 방식입니다. 리눅스 서버 한 대를 직접 관리하는 느낌이라 자유도가 높습니다. 대신 보안 업데이트, 방화벽, 서버 설정을 스스로 챙겨야 합니다. 기존에 AWS EC2나 일반 VPS를 써본 사람이라면 이해가 빠릅니다.
Cloud Run
Cloud Run은 컨테이너 기반으로 앱을 올리는 서비스입니다. 사용자가 없을 때는 자원을 줄이고, 요청이 들어오면 자동으로 실행되는 식이라 작은 서비스에 잘 맞습니다. 예를 들어 하루 방문자가 100명 안팎인 개인 API라면 서버를 하루 종일 켜두는 방식보다 부담이 적을 수 있습니다.
Cloud Storage와 Cloud SQL
Cloud Storage는 이미지, 백업 파일, 첨부파일 같은 정적 파일을 넣어두는 공간입니다. Cloud SQL은 MySQL, PostgreSQL 같은 관계형 데이터베이스를 관리형으로 쓰는 서비스입니다. 직접 데이터베이스 서버를 설치할 수도 있지만, 백업과 장애 대응까지 생각하면 관리형 서비스를 쓰는 쪽이 편한 순간이 많습니다.
간단히 비교하면, 웹 앱 실행은 Cloud Run, 파일 저장은 Cloud Storage, 회원 정보나 주문 정보처럼 구조가 있는 데이터는 Cloud SQL로 시작하는 구성이 무난합니다. 처음 배포하는 작은 서비스라면 이 조합만으로도 꽤 많은 일을 처리할 수 있습니다.
비용 폭탄을 피하려면 알림부터 켜야 합니다
클라우드에서 가장 무서운 건 기술보다 비용입니다. 사실 서버 하나 잘못 켜두는 정도는 큰 문제가 아닐 수 있지만, 고사양 인스턴스나 대용량 로그, 외부 트래픽이 겹치면 예상보다 빠르게 금액이 커질 수 있습니다.
처음에는 월 예산을 작게 잡는 편이 좋습니다. 예를 들어 개인 실습이면 1만 원, 작은 테스트 서비스면 3만 원, 외부 사용자가 있는 서비스면 5만 원처럼 본인이 놀라지 않을 선을 정해두는 겁니다. 그리고 예산의 50%, 80%, 100%에 도달했을 때 알림을 받도록 설정하면 갑자기 큰 금액을 마주할 가능성이 줄어듭니다.
- 새 프로젝트를 만들면 예산 알림부터 설정
- 쓰지 않는 VM, 디스크, 고정 IP는 주기적으로 확인
- 로그 보관 기간은 필요한 만큼만 유지
- 테스트 리소스에는 이름에 test나 dev를 넣어 구분
특히 VM을 삭제했는데 디스크가 남아 있는 경우가 있습니다. 서버는 껐다고 생각했는데 저장공간 비용이 계속 나가는 식입니다. 고정 IP도 연결된 리소스가 없으면 과금될 수 있으니, 실습 후에는 리소스 목록을 한 번 훑는 습관이 꽤 중요합니다.
작은 서비스 배포 흐름은 이렇게 잡으면 됩니다
처음 GCP를 쓰는 목적이 웹 서비스 배포라면 흐름을 단순하게 잡는 게 좋습니다. 코드를 컨테이너로 만들고, Cloud Run에 올리고, 환경변수를 넣고, 로그를 확인하는 방식입니다. 처음에는 자동화보다 수동 배포로 구조를 이해하는 편이 빠를 때가 많습니다.
예를 들어 Node.js나 Python으로 만든 API가 있다면 Dockerfile을 하나 만들고, 이미지로 빌드한 뒤 Cloud Run에 배포할 수 있습니다. 데이터가 필요하면 Cloud SQL을 연결하고, 이미지 업로드가 필요하면 Cloud Storage 버킷을 붙입니다. 여기까지 하면 “내 컴퓨터에서만 돌아가는 앱”이 아니라 외부에서 접속 가능한 서비스가 됩니다.
운영 환경에서는 환경변수를 코드에 직접 넣지 않는 것이 좋습니다. 데이터베이스 비밀번호, API 키, 토큰 같은 값은 별도로 관리해야 합니다. 개인 프로젝트에서는 대충 넘어가기 쉬운데, 깃 저장소에 비밀값이 올라가면 나중에 지우는 일이 더 번거롭습니다.
- 1단계: 로컬에서 앱 실행 확인
- 2단계: 컨테이너 이미지 만들기
- 3단계: Cloud Run에 배포
- 4단계: 로그로 오류 확인
- 5단계: 예산과 권한 점검
이 순서로 가면 중간에 문제가 생겨도 원인을 좁히기 쉽습니다. 로컬에서 안 되는 문제인지, 컨테이너 설정 문제인지, GCP 권한 문제인지 따로 볼 수 있기 때문입니다.
처음 한 달은 작게 굴리는 게 좋습니다
GCP는 잘 쓰면 든든한 도구지만, 처음부터 완벽한 클라우드 아키텍처를 만들려고 하면 금방 지칩니다. 개인 블로그나 작은 API라면 Cloud Run 하나로 시작하고, 파일 저장이 필요할 때 Cloud Storage를 붙이고, 데이터가 쌓이기 시작하면 Cloud SQL을 고민하는 식으로 넓혀가는 편이 자연스럽습니다.
솔직히 클라우드는 책으로만 익히면 감이 잘 안 옵니다. 작은 서버 하나를 실제로 올리고, 로그를 보고, 비용 알림을 받아보고, 필요 없는 리소스를 지워보는 과정에서 훨씬 빨리 익숙해집니다. GCP는 기능이 많은 만큼 겁먹기 쉬운데, 첫 목표를 “대단한 인프라 만들기”가 아니라 “작은 앱 하나 안전하게 올리기”로 잡으면 생각보다 부담이 줄어듭니다.
개인적으로는 비용 알림과 프로젝트 구분만 제대로 해도 출발선은 꽤 괜찮다고 봅니다. 기술은 조금씩 붙이면 되지만, 돈이 새는 구조와 권한이 뒤섞인 구조는 나중에 고치기 더 귀찮아지니까요. 작게 시작해서 직접 굴려보는 쪽이 결국 가장 현실적인 GCP 입문 방법입니다.
