얼마 전 지인이 작은 웹서비스를 만들면서 서버를 어디에 올릴지 고민하더라고요. 처음에는 익숙한 호스팅을 생각했는데, 트래픽이 늘어날 가능성도 있고 데이터 분석까지 염두에 두다 보니 GCP 이야기가 자연스럽게 나왔습니다. GCP는 Google Cloud Platform의 줄임말이고, 구글이 제공하는 클라우드 서비스 묶음이라고 보면 됩니다.
처음 보면 Compute Engine, Cloud Run, Cloud Storage, BigQuery처럼 이름이 낯선 서비스가 한꺼번에 보여서 조금 복잡하게 느껴집니다. 그런데 실제로는 “서버를 빌릴 건지, 파일을 저장할 건지, 데이터를 분석할 건지”처럼 목적별로 나누면 훨씬 편하게 접근할 수 있습니다.
GCP를 시작하기 전에 목적부터 잡는 방법
GCP를 처음 쓰는 분들이 가장 많이 하는 실수는 서비스 이름부터 외우려고 하는 겁니다. 사실 먼저 정해야 할 것은 기술 이름이 아니라 사용 목적입니다. 예를 들어 개인 블로그나 간단한 API 서버를 운영하려는 사람과, 하루 수십만 건의 데이터를 분석하려는 회사가 고르는 서비스는 달라질 수밖에 없습니다.
작은 웹서비스라면 Cloud Run이나 App Engine처럼 관리 부담이 적은 서비스를 먼저 떠올릴 수 있습니다. 직접 가상머신을 다루고 싶다면 Compute Engine이 맞고요. 이미지, 첨부파일, 백업 파일을 보관해야 한다면 Cloud Storage가 기본 선택지입니다. 데이터 분석이 중심이라면 BigQuery가 자주 등장합니다.
- 웹사이트나 API 배포: Cloud Run, App Engine
- 가상 서버 직접 운영: Compute Engine
- 파일 저장: Cloud Storage
- 관계형 데이터베이스: Cloud SQL
- 대용량 데이터 분석: BigQuery
근데 처음부터 여러 서비스를 섞으면 설정도 복잡해지고 비용 구조도 헷갈립니다. 처음에는 하나의 작은 목표만 잡는 게 좋습니다. 예를 들어 “Node.js API 하나를 Cloud Run에 배포한다” 정도면 충분합니다.
계정과 프로젝트를 만들 때 챙길 것
GCP는 프로젝트 단위로 리소스를 관리합니다. 회사 업무, 개인 실험, 고객사 작업을 같은 프로젝트에 넣으면 나중에 권한과 비용을 구분하기가 꽤 피곤해집니다. 그래서 처음부터 프로젝트 이름을 구체적으로 짓는 편이 좋습니다. 예를 들면 “개인 테스트”보다 “blog-api-dev”처럼 목적이 보이는 이름이 관리하기 편합니다.
프로젝트를 만들고 나면 결제 계정을 연결하게 됩니다. 여기서 살짝 긴장되는 분들이 많은데, 비용 알림만 제대로 걸어도 큰 사고를 줄일 수 있습니다. 예산 알림을 50%, 90%, 100%처럼 단계별로 설정해두면 예상보다 사용량이 늘어났을 때 빨리 알아챌 수 있습니다.
솔직히 클라우드에서 무서운 건 “한 번 썼더니 몇백만 원이 나왔다” 같은 이야기입니다. 대부분은 리소스를 켜둔 채 잊어버리거나, 로그와 저장소가 계속 쌓이거나, 외부 요청이 예상보다 많이 들어오면서 생깁니다. 처음 쓰는 단계라면 예산 알림, 리소스 삭제 습관, 권한 최소화 이 세 가지만 챙겨도 훨씬 마음이 편합니다.
초보자가 많이 쓰는 서비스 고르는 기준
GCP에서 웹 애플리케이션을 올릴 때 가장 헷갈리는 선택지가 Compute Engine과 Cloud Run입니다. Compute Engine은 말 그대로 가상 서버를 빌리는 방식입니다. 운영체제 업데이트, 방화벽, 서버 상태 확인 같은 일을 직접 챙겨야 합니다. 대신 자유도는 높습니다.
Cloud Run은 컨테이너 기반으로 애플리케이션을 실행하는 서비스입니다. 요청이 없을 때는 인스턴스를 줄일 수 있어 작은 서비스나 실험용 프로젝트에 잘 맞습니다. 배포 단위도 비교적 깔끔해서, 서버 관리에 시간을 많이 쓰고 싶지 않은 사람에게 편합니다.
데이터베이스는 상황에 따라 다릅니다. 익숙한 MySQL이나 PostgreSQL을 쓰고 싶다면 Cloud SQL이 무난합니다. 문서 형태 데이터를 유연하게 다루려면 Firestore도 후보가 됩니다. 다만 데이터베이스는 한 번 정하면 바꾸는 비용이 생기니, 처음에는 트래픽보다 데이터 구조를 먼저 생각하는 게 좋습니다.
작게 시작하는 추천 흐름
- 간단한 백엔드 API: Cloud Run과 Cloud SQL 조합
- 정적 파일 배포: Cloud Storage 활용
- 로그 확인: Cloud Logging에서 요청 흐름 확인
- 배포 자동화: Cloud Build를 나중에 추가
처음부터 Kubernetes나 복잡한 네트워크 구성을 건드릴 필요는 거의 없습니다. 물론 규모가 커지면 Google Kubernetes Engine이 강력한 선택지가 될 수 있지만, 초보 단계에서는 관리해야 할 요소가 급격히 늘어납니다.
비용을 줄이면서 운영하는 습관
GCP 비용은 크게 컴퓨팅, 저장소, 네트워크, 데이터베이스에서 발생합니다. 예를 들어 서버를 계속 켜두면 시간 단위로 비용이 쌓이고, 저장소에 파일을 많이 넣으면 용량 기준으로 비용이 붙습니다. 외부로 데이터를 많이 내보내는 경우 네트워크 비용도 무시하기 어렵습니다.
개인 프로젝트라면 리전 선택도 생각보다 중요합니다. 사용자 대부분이 한국에 있다면 가까운 리전을 고르는 게 응답 속도에 유리할 수 있습니다. 다만 서비스별 가격은 리전마다 다를 수 있으니, 운영 전에는 GCP 가격 계산기에서 대략적인 월 비용을 잡아보는 편이 좋습니다.
그리고 테스트가 끝난 리소스는 바로 지우는 습관이 필요합니다. Compute Engine 인스턴스, 사용하지 않는 디스크, 오래된 스냅샷, 필요 없는 고정 IP 같은 것들이 대표적입니다. 특히 고정 IP는 연결된 리소스 없이 남아 있으면 비용이 생길 수 있어 자주 놓치는 항목입니다.
- 예산 알림을 프로젝트마다 설정하기
- 테스트용 리소스에는 이름에 날짜 넣기
- 사용하지 않는 디스크와 스냅샷 확인하기
- 로그 보관 기간을 목적에 맞게 조절하기
- 권한은 필요한 사람에게 필요한 만큼만 주기
구글 클라우드 안내에서도 비용 관리와 권한 관리는 별도의 관리 영역으로 다룹니다. 그만큼 기능을 잘 쓰는 것만큼이나, 누가 무엇을 만들 수 있고 어느 정도까지 비용이 늘어날 수 있는지 정해두는 일이 중요합니다.
처음 배포할 때의 현실적인 순서
처음 GCP를 만진다면 너무 큰 그림보다 손에 잡히는 순서가 낫습니다. 먼저 프로젝트를 만들고, 예산 알림을 설정하고, Cloud Run 같은 관리형 서비스에 작은 애플리케이션을 하나 배포합니다. 그다음 로그를 보고, 환경 변수를 넣고, 데이터베이스를 연결하는 식으로 넓혀가면 됩니다.
예를 들어 간단한 게시판 API를 만든다고 가정해볼게요. 처음에는 로컬에서 실행되는 코드를 준비합니다. 그다음 컨테이너 이미지로 만들고 Cloud Run에 올립니다. 데이터 저장이 필요해지면 Cloud SQL을 붙입니다. 접속량이 늘어나면 로그와 지표를 보면서 메모리, CPU, 동시 요청 수를 조절합니다.
이 흐름을 한 번만 경험해도 GCP가 덜 낯설어집니다. 메뉴 이름을 전부 외우는 것보다, 배포부터 로그 확인까지 한 바퀴 돌려보는 경험이 훨씬 오래 남습니다. 개인적으로는 처음부터 완벽한 구조를 만들려고 하기보다, 비용 제한을 걸어둔 작은 프로젝트에서 한 기능씩 붙여가는 방식이 가장 현실적이라고 생각합니다.
