서버를 “하나만” 띄우면 끝날 것 같죠.\
그런데 막상 시작하면 선택지가 폭발합니다. VM? 컨테이너? 스토리지? 방화벽? 고정 IP? 과금? 그리고 마지막에 꼭 한 번은… “왜 접속이 안 되지?”를 외치게 됩니다.

이 글은 **GCP(Google Cloud Platform)**를 처음 쓰는 분도 **서버를 안정적으로 만들고, 외부에서 접속 가능하게 설정하고, 비용 폭탄을 피하는 방법**까지 한 번에 정리한 실전 가이드입니다.\
읽고 나면, 오늘 안에 **내 서버를 직접 띄워서 SSH로 접속**할 수 있게 됩니다.

![Generated image](https://images.tilnote.io/pages/660f3dc5-d7c6-4a13-8c66-95462677c682.webp)

---

## GCP란? “서버를 빌리는 게 아니라, ‘사용한 만큼’ 쓰는 것”

Google Cloud(=GCP)는 구글의 초대형 데이터센터 자원을 빌려 **앱/서비스를 개발·배포·운영**하는 클라우드 플랫폼입니다. 핵심은 이거예요.

* 월 임대가 아니라 **초/분 단위로 과금**(서비스에 따라 다름)

* CPU, 스토리지, 네트워크 같은 **리소스를 쓴 만큼 결제**

* VM(가상머신)뿐 아니라 **Kubernetes 기반 컨테이너 운영(GKE)**에 강점

Cloud Ace 자료에서도 “서버를 한 달 단위로 임대하는 전통 방식이 아니라, 처리/저장/쿼리/네트워크 사용량 기반으로 과금한다”는 점을 강조합니다. (Compute Engine 초 단위 과금 언급 포함)

---

## GCP에서 서버를 띄우는 2가지 길: VM vs 컨테이너(정답은 ‘목적’)

### 1) 빠르게 서버 1대가 필요하면: Compute Engine(VM)

**Compute Engine(GCE)**는 우리가 흔히 말하는 “EC2 같은 VM”입니다. 운영체제를 올리고(리눅스/윈도우), 그 위에 Nginx든 Node.js든 마음대로 설치합니다.

* 장점: 익숙함, 자유도 높음, 마이그레이션 쉬움

* 단점: 패치/보안/운영 책임이 사용자에게 있음

> VM 리소스 묶음을 **인스턴스(instance)**라고 부릅니다.

### 2) 배포 자동화/확장성이 중요하면: Google Kubernetes Engine(GKE)

구글이 만든 Kubernetes를 구글이 운영해주는 서비스가 **GKE**입니다. 앱을 “컨테이너” 단위로 올리면 자동 배치/확장/롤링업데이트가 쉬워집니다.

* 장점: 마이크로서비스, 오토스케일, 배포 자동화에 최적

* 단점: 러닝커브 있음(초보에게는 과함)

**오늘 목표가 “서버 설정 방법”이라면, 일단은 GCE로 시작**하는 게 가장 빠릅니다. (필요해지면 GKE로 확장)

---

## (실전) GCP 서버 설정 방법: Compute Engine으로 리눅스 서버 만들기

아래대로 하면 “접속 안 됨” 사고를 대부분 피합니다.

### 0단계: 결제 계정/프로젝트부터 정리(의외로 여기서 막힘)

1. GCP 콘솔 접속

2. **프로젝트 생성**(예: `my-first-server`)

3. **결제 계정 연결**

4. 예산 알림 설정(강력 추천):

 * Billing → Budgets & alerts → 예산 1만원/5만원 등 설정

---

### 1단계: VM 인스턴스 생성(Compute Engine)

경로: **Compute Engine → VM instances → Create instance**

추천 설정(초보 기준):

* 이름: `web-1`

* 리전/존: 사용자와 가까운 곳(예: `asia-northeast3(서울)`)

* 머신: e2-micro(테스트/학습에 가벼움) 또는 e2-small(조금 여유)

* 부팅 디스크: **Ubuntu 22.04 LTS**

* 디스크 크기: 20~30GB부터 시작

* 방화벽 체크:

 * “Allow HTTP traffic”

 * “Allow HTTPS traffic”

여기서 포인트:

* “서울 리전”은 지연이 적고 국내 서비스 테스트에 편합니다.

* HTTP/HTTPS 허용 체크는 **GCP 방화벽 규칙을 자동 생성**해 줍니다(하지만 80/443만 열립니다).

---

### 2단계: 외부 IP(고정 IP) 설정 — 서버 주소가 바뀌면 다 무너집니다

기본 설정은 VM 재시작/중지 시 **외부 IP가 바뀔 수** 있습니다.

고정 IP 설정:

1. VPC network → **IP addresses**

2. “Reserve external static address”

3. 만든 주소를 VM에 연결

고정 IP가 필요한 경우:

* 도메인을 붙일 예정

* 방화벽/허용 IP 기반 연동

* 고객에게 고정 주소 제공

---

### 3단계: SSH 접속(가장 빠른 방법 2개)

#### 방법 A) 콘솔에서 바로 접속

VM 목록에서 **SSH 버튼** 클릭 → 브라우저 터미널 열림

#### 방법 B) 로컬에서 접속(개발자 추천)

1. SSH 키 준비

2. VM 메타데이터/OS Login 설정(조직 정책에 따라 다름)

3. 접속:

```bash
ssh username@<외부IP>
```

---

### 4단계: 초기 서버 세팅(필수 패키지/보안 기본)

접속 후 바로:

```bash
sudo apt update && sudo apt -y upgrade
sudo apt -y install nginx ufw fail2ban
```

* **nginx**: 웹서버

* **ufw**: 리눅스 방화벽(추가 안전장치)

* **fail2ban**: SSH 무차별 대입 공격 방어

UFW 기본 정책(예시):

```bash
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status
```

---

### 5단계: 방화벽(진짜 중요) — GCP 방화벽 + OS 방화벽 “둘 다” 봐야 합니다

외부 접속이 안 될 때 90%는 방화벽입니다.

체크리스트:

* GCP VPC 방화벽 규칙에 80/443 허용되어 있나?

* VM에 “network tag”가 붙어 있고, 방화벽 규칙이 그 태그를 대상으로 하나?

* 리눅스(UFW)에서 80/443 허용했나?

GCP에서 특정 포트(예: 8080) 열기:

1. VPC network → Firewall → Create firewall rule

2. Ingress 허용

3. Targets: `Specified target tags`

4. tag 예: `web`

5. Ports: `tcp:8080`

6. VM에 네트워크 태그 `web` 추가

---

### 6단계: 도메인 연결 + HTTPS(Let’s Encrypt)까지 하면 ‘실서비스 느낌’ 완성

1. 도메인 A 레코드를 고정 IP로 연결

2. Nginx 서버 블록 설정

3. Certbot으로 HTTPS 발급:

```bash
sudo apt -y install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
```

자동 갱신 확인:

```bash
sudo certbot renew --dry-run
```

---

## 스토리지는 어떻게? Cloud Storage(GCS) + Nearline을 이렇게 쓰면 됩니다

### Cloud Storage(GCS): 파일 보관함을 “인터넷 급”으로 쓰는 방식

GCS는 오브젝트 스토리지입니다. 이미지/동영상/백업/로그 같은 파일을 서버 디스크에 두지 말고 **버킷(bucket)**에 넣어두면 운영이 편해집니다.

추천 패턴:

* 웹서버(VM): 앱 실행

* 정적 파일(이미지/다운로드): **GCS 버킷**

* 백업/아카이브: **Nearline(콜드 스토리지)**

### Nearline: “거의 안 꺼내볼 파일”은 저렴하게

Nearline은 월 1회 이하 접근 같은 **저사용량 백업/아카이브**에 맞춘 스토리지 클래스입니다.\
운영하면서 쌓이는 DB 덤프/로그 스냅샷을 Nearline으로 보내두면 비용이 줄어듭니다.

---

## GCP 비용 폭탄 피하는 설정 7가지(경험상 이게 제일 중요)

서버를 “하나만” 띄우면 끝날 것 같죠. 그런데 막상 시작하면 선택지가 폭발합니다. VM? 컨테이너? 스토리지? 방화벽? 고정 IP? 과금? 그리고 마지막에 꼭 한 번은… “왜 접속이 안 되지?”를 외치게 됩니다. 이 글은 GCP(Google Cloud Platform)를 처음 쓰는 분도 서버를 안정적으로 만들고, 외부에서 접속 가능하게 설정하고, 비용 폭탄을 피하는 방법까지 한 번에 정리한 실전 가이드입니다. 읽고 나면, 오늘 안에 내 서버를 직접 띄워서 SSH로 접속할 수 있게 됩니다. GCP란? “서버를 빌리는 게 아니라, ‘사용한 만큼’ 쓰는 것” Google Cloud(=GCP)는 구글의 초대형 데이터센터 자원을 빌려 앱/서비스를 개발·배포·운영하는 클라우드 플랫폼입니다. 핵심은 이거예요. 월 임대가 아니라 초/분 단위로 과금(서비스에 따라 다름) CPU, 스토리지, 네트워크 같은 리소스를 쓴 만큼 결제 VM(가상머신)뿐 아니라 Kubernetes 기반 컨테이너 운영(GKE)에 강점 Cloud Ace 자료에서도 “서버를 한 달 단위로 임대하는 전통 방식이 아니라, 처리/저장/쿼리/네트워크 사용량 기반으로 과금한다”는 점을 강조합니다. (Compute Engine 초 단위 과금 언급 포함) GCP에서 서버를 띄우는 2가지 길: VM vs 컨테이너(정답은 ‘목적’) 1) 빠르게 서버 1대가 필요하면: Compute Engine(VM) Compute Engine(GCE)는 우리가 흔히 말하는 “EC2 같은 VM”입니다. 운영체제를 올리고(리눅스/윈도우), 그 위에 Nginx든 Node.js든 마음대로 설치합니다. 장점: 익숙함, 자유도 높음, 마이그레이션 쉬움 단점: 패치/보안/운영 책임이 사용자에게 있음 VM 리소스 묶음을 인스턴스(instance)라고 부릅니다. 2) 배포 자동화/확장성이 중요하면: Google Kubernetes Engine(GKE) 구글이 만든 Kubernetes를 구글이 운영해주는 서비스가 GKE입니다. 앱을 “컨테이너” 단위로 올리면 자동 배치/확장/롤링업데이트가 쉬워집니다. 장점: 마이크로서비스, 오토스케일, 배포 자동화에 최적 단점: 러닝커브 있음(초보에게는 과함) 오늘 목표가 “서버 설정 방법”이라면, 일단은 GCE로 시작하는 게 가장 빠릅니다. (필요해지면 GKE로 확장) (실전) GCP 서버 설정 방법: Compute Engine으로 리눅스 서버 만들기 아래대로 하면 “접속 안 됨” 사고를 대부분 피합니다. 0단계: 결제 계정/프로젝트부터 정리(의외로 여기서 막힘) GCP 콘솔 접속 프로젝트 생성(예: my-first-server) 결제 계정 연결 예산 알림 설정(강력 추천): Billing → Budgets & alerts → 예산 1만원/5만원 등 설정 1단계: VM 인스턴스 생성(Compute Engine) 경로: Compute Engine → VM instances → Create instance 추천 설정(초보 기준): 이름: web-1 리전/존: 사용자와 가까운 곳(예: asia-northeast3(서울)) 머신: e2-micro(테스트/학습에 가벼움) 또는 e2-small(조금 여유) 부팅 디스크: Ubuntu 22.04 LTS 디스크 크기: 20~30GB부터 시작 방화벽 체크: “Allow HTTP traffic” “Allow HTTPS traffic” 여기서 포인트: “서울 리전”은 지연이 적고 국내 서비스 테스트에 편합니다. HTTP/HTTPS 허용 체크는 GCP 방화벽 규칙을 자동 생성해 줍니다(하지만 80/443만 열립니다). 2단계: 외부 IP(고정 IP) 설정 — 서버 주소가 바뀌면 다 무너집니다 기본 설정은 VM 재시작/중지 시 외부 IP가 바뀔 수 있습니다. 고정 IP 설정: VPC network → IP addresses “Reserve external static address” 만든 주소를 VM에 연결 고정 IP가 필요한 경우: 도메인을 붙일 예정 방화벽/허용 IP 기반 연동 고객에게 고정 주소 제공 3단계: SSH 접속(가장 빠른 방법 2개) 방법 A) 콘솔에서 바로 접속 VM 목록에서 SSH 버튼 클릭 → 브라우저 터미널 열림 방법 B) 로컬에서 접속(개발자 추천) SSH 키 준비 VM 메타데이터/OS Login 설정(조직 정책에 따라 다름) 접속: 4단계: 초기 서버 세팅(필수 패키지/보안 기본) 접속 후 바로: nginx: 웹서버 ufw: 리눅스 방화벽(추가 안전장치) fail2ban: SSH 무차별 대입 공격 방어 UFW 기본 정책(예시): 5단계: 방화벽(진짜 중요) — GCP 방화벽 + OS 방화벽 “둘 다” 봐야 합니다 외부 접속이 안 될 때 90%는 방화벽입니다. 체크리스트: GCP VPC 방화벽 규칙에 80/443 허용되어 있나? VM에 “network tag”가 붙어 있고, 방화벽 규칙이 그 태그를 대상으로 하나? 리눅스(UFW)에서 80/443 허용했나? GCP에서 특정 포트(예: 8080) 열기: VPC network → Firewall → Create firewall rule Ingress 허용 Targets: Specified target tags tag 예: web Ports: tcp:8080 VM에 네트워크 태그 web 추가 6단계: 도메인 연결 + HTTPS(Let’s Encrypt)까지 하면 ‘실서비스 느낌’ 완성 도메인 A 레코드를 고정 IP로 연결 Nginx 서버 블록 설정 Certbot으로 HTTPS 발급: 자동 갱신 확인: 스토리지는 어떻게? Cloud Storage(GCS) + Nearline을 이렇게 쓰면 됩니다 Cloud Storage(GCS): 파일 보관함을 “인터넷 급”으로 쓰는 방식 GCS는 오브젝트 스토리지입니다. 이미지/동영상/백업/로그 같은 파일을 서버 디스크에 두지 말고 버킷(bucket)에 넣어두면 운영이 편해집니다. 추천 패턴: 웹서버(VM): 앱 실행 정적 파일(이미지/다운로드): GCS 버킷 백업/아카이브: Nearline(콜드 스토리지) Nearline: “거의 안 꺼내볼 파일”은 저렴하게 Nearline은 월 1회 이하 접근 같은 저사용량 백업/아카이브에 맞춘 스토리지 클래스입니다. 운영하면서 쌓이는 DB 덤프/로그 스냅샷을 Nearline으로 보내두면 비용이 줄어듭니다. GCP 비용 폭탄 피하는 설정 7가지(경험상 이게 제일 중요)

서버를 “하나만” 띄우면 끝날 것 같죠. 그런데 막상 시작하면 선택지가 폭발합니다. VM? 컨테이너? 스토리지? 방화벽? 고정 IP? 과금? 그리고 마지막에 꼭 한 번은… “왜 접속이 안 되지?”를 외치게 됩니다.이 글은 GCP(Google Cloud Platform)를 처음 쓰는 분도 서버를 안정적으로 만들고, 외부에서 접속 가능하게 설정하고, 비용 폭탄을 피하는 방법까지 한 번에 정리한 실전 가이드입니다. 읽고 나면, 오늘 안에 내 서버를 직접 띄워서 SSH로 접속할 수 있게 됩니다.<img src="https://images.tilnote.io/pages/660f3dc5-d7c6-4a13-8c66-95462677c682.webp" alt="Generated image" loading="eager" decoding="async" fetchpriority="high"><hr><h2 id="GCP란-서버를-빌리는-게-아니라-사용한-만큼-쓰는-것">GCP란? “서버를 빌리는 게 아니라, ‘사용한 만큼’ 쓰는 것”</h2>Google Cloud(=GCP)는 구글의 초대형 데이터센터 자원을 빌려 앱/서비스를 개발·배포·운영하는 클라우드 플랫폼입니다. 핵심은 이거예요.<ul><li>월 임대가 아니라 초/분 단위로 과금(서비스에 따라 다름)</li><li>CPU, 스토리지, 네트워크 같은 리소스를 쓴 만큼 결제</li><li>VM(가상머신)뿐 아니라 Kubernetes 기반 컨테이너 운영(GKE)에 강점</li></ul>Cloud Ace 자료에서도 “서버를 한 달 단위로 임대하는 전통 방식이 아니라, 처리/저장/쿼리/네트워크 사용량 기반으로 과금한다”는 점을 강조합니다. (Compute Engine 초 단위 과금 언급 포함)<hr><h2 id="GCP에서-서버를-띄우는-2가지-길-VM-vs-컨테이너정답은-목적">GCP에서 서버를 띄우는 2가지 길: VM vs 컨테이너(정답은 ‘목적’)</h2><h3 id="1-빠르게-서버-1대가-필요하면-Compute-EngineVM">1) 빠르게 서버 1대가 필요하면: Compute Engine(VM)</h3>Compute Engine(GCE)는 우리가 흔히 말하는 “EC2 같은 VM”입니다. 운영체제를 올리고(리눅스/윈도우), 그 위에 Nginx든 Node.js든 마음대로 설치합니다.<ul><li>장점: 익숙함, 자유도 높음, 마이그레이션 쉬움</li><li>단점: 패치/보안/운영 책임이 사용자에게 있음</li></ul><blockquote>VM 리소스 묶음을 인스턴스(instance)라고 부릅니다.</blockquote><h3 id="2-배포-자동화확장성이-중요하면-Google-Kubernetes-EngineGKE">2) 배포 자동화/확장성이 중요하면: Google Kubernetes Engine(GKE)</h3>구글이 만든 Kubernetes를 구글이 운영해주는 서비스가 GKE입니다. 앱을 “컨테이너” 단위로 올리면 자동 배치/확장/롤링업데이트가 쉬워집니다.<ul><li>장점: 마이크로서비스, 오토스케일, 배포 자동화에 최적</li><li>단점: 러닝커브 있음(초보에게는 과함)</li></ul>오늘 목표가 “서버 설정 방법”이라면, 일단은 GCE로 시작하는 게 가장 빠릅니다. (필요해지면 GKE로 확장)<hr><h2 id="실전-GCP-서버-설정-방법-Compute-Engine으로-리눅스-서버-만들기">(실전) GCP 서버 설정 방법: Compute Engine으로 리눅스 서버 만들기</h2>아래대로 하면 “접속 안 됨” 사고를 대부분 피합니다.<h3 id="0단계-결제-계정프로젝트부터-정리의외로-여기서-막힘">0단계: 결제 계정/프로젝트부터 정리(의외로 여기서 막힘)</h3><ol><li>GCP 콘솔 접속</li><li>프로젝트 생성(예: <code class="language-javascript">my-first-server</code>)</li><li>결제 계정 연결</li><li>예산 알림 설정(강력 추천):<ul><li>Billing → Budgets &amp; alerts → 예산 1만원/5만원 등 설정</li></ul></li></ol><hr><h3 id="1단계-VM-인스턴스-생성Compute-Engine">1단계: VM 인스턴스 생성(Compute Engine)</h3>경로: Compute Engine → VM instances → Create instance추천 설정(초보 기준):<ul><li>이름: <code class="language-javascript">web-1</code></li><li>리전/존: 사용자와 가까운 곳(예: <code class="language-javascript">asia-northeast3(서울)</code>)</li><li>머신: e2-micro(테스트/학습에 가벼움) 또는 e2-small(조금 여유)</li><li>부팅 디스크: Ubuntu 22.04 LTS</li><li>디스크 크기: 20~30GB부터 시작</li><li>방화벽 체크:<ul><li>“Allow HTTP traffic”</li><li>“Allow HTTPS traffic”</li></ul></li></ul>여기서 포인트:<ul><li>“서울 리전”은 지연이 적고 국내 서비스 테스트에 편합니다.</li><li>HTTP/HTTPS 허용 체크는 GCP 방화벽 규칙을 자동 생성해 줍니다(하지만 80/443만 열립니다).</li></ul><hr><h3 id="2단계-외부-IP고정-IP-설정-서버-주소가-바뀌면-다-무너집니다">2단계: 외부 IP(고정 IP) 설정 — 서버 주소가 바뀌면 다 무너집니다</h3>기본 설정은 VM 재시작/중지 시 외부 IP가 바뀔 수 있습니다.고정 IP 설정:<ol><li>VPC network → IP addresses</li><li>“Reserve external static address”</li><li>만든 주소를 VM에 연결</li></ol>고정 IP가 필요한 경우:<ul><li>도메인을 붙일 예정</li><li>방화벽/허용 IP 기반 연동</li><li>고객에게 고정 주소 제공</li></ul><hr><h3 id="3단계-SSH-접속가장-빠른-방법-2개">3단계: SSH 접속(가장 빠른 방법 2개)</h3><h4 id="방법-A-콘솔에서-바로-접속">방법 A) 콘솔에서 바로 접속</h4>VM 목록에서 SSH 버튼 클릭 → 브라우저 터미널 열림<h4 id="방법-B-로컬에서-접속개발자-추천">방법 B) 로컬에서 접속(개발자 추천)</h4><ol><li>SSH 키 준비</li><li>VM 메타데이터/OS Login 설정(조직 정책에 따라 다름)</li><li>접속:</li></ol><pre><code class="language-bash">ssh username@&lt;외부IP&gt;</code></pre><hr><h3 id="4단계-초기-서버-세팅필수-패키지보안-기본">4단계: 초기 서버 세팅(필수 패키지/보안 기본)</h3>접속 후 바로:<pre><code class="language-bash">sudo apt update &amp;&amp; sudo apt -y upgrade
sudo apt -y install nginx ufw fail2ban</code></pre><ul><li>nginx: 웹서버</li><li>ufw: 리눅스 방화벽(추가 안전장치)</li><li>fail2ban: SSH 무차별 대입 공격 방어</li></ul>UFW 기본 정책(예시):<pre><code class="language-bash">sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status</code></pre><hr><h3 id="5단계-방화벽진짜-중요-GCP-방화벽-OS-방화벽-둘-다-봐야-합니다">5단계: 방화벽(진짜 중요) — GCP 방화벽 + OS 방화벽 “둘 다” 봐야 합니다</h3>외부 접속이 안 될 때 90%는 방화벽입니다.체크리스트:<ul><li>GCP VPC 방화벽 규칙에 80/443 허용되어 있나?</li><li>VM에 “network tag”가 붙어 있고, 방화벽 규칙이 그 태그를 대상으로 하나?</li><li>리눅스(UFW)에서 80/443 허용했나?</li></ul>GCP에서 특정 포트(예: 8080) 열기:<ol><li>VPC network → Firewall → Create firewall rule</li><li>Ingress 허용</li><li>Targets: <code class="language-javascript">Specified target tags</code></li><li>tag 예: <code class="language-javascript">web</code></li><li>Ports: <code class="language-javascript">tcp:8080</code></li><li>VM에 네트워크 태그 <code class="language-javascript">web</code> 추가</li></ol><hr><h3 id="6단계-도메인-연결-HTTPSLets-Encrypt까지-하면-실서비스-느낌-완성">6단계: 도메인 연결 + HTTPS(Let’s Encrypt)까지 하면 ‘실서비스 느낌’ 완성</h3><ol><li>도메인 A 레코드를 고정 IP로 연결</li><li>Nginx 서버 블록 설정</li><li>Certbot으로 HTTPS 발급:</li></ol><pre><code class="language-bash">sudo apt -y install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com</code></pre>자동 갱신 확인:<pre><code class="language-bash">sudo certbot renew --dry-run</code></pre><hr><h2 id="스토리지는-어떻게-Cloud-StorageGCS-Nearline을-이렇게-쓰면-됩니다">스토리지는 어떻게? Cloud Storage(GCS) + Nearline을 이렇게 쓰면 됩니다</h2><h3 id="Cloud-StorageGCS-파일-보관함을-인터넷-급으로-쓰는-방식">Cloud Storage(GCS): 파일 보관함을 “인터넷 급”으로 쓰는 방식</h3>GCS는 오브젝트 스토리지입니다. 이미지/동영상/백업/로그 같은 파일을 서버 디스크에 두지 말고 버킷(bucket)에 넣어두면 운영이 편해집니다.추천 패턴:<ul><li>웹서버(VM): 앱 실행</li><li>정적 파일(이미지/다운로드): GCS 버킷</li><li>백업/아카이브: Nearline(콜드 스토리지)</li></ul><h3 id="Nearline-거의-안-꺼내볼-파일은-저렴하게">Nearline: “거의 안 꺼내볼 파일”은 저렴하게</h3>Nearline은 월 1회 이하 접근 같은 저사용량 백업/아카이브에 맞춘 스토리지 클래스입니다. 운영하면서 쌓이는 DB 덤프/로그 스냅샷을 Nearline으로 보내두면 비용이 줄어듭니다.<hr><h2 id="GCP-비용-폭탄-피하는-설정-7가지경험상-이게-제일-중요">GCP 비용 폭탄 피하는 설정 7가지(경험상 이게 제일 중요)</h2>

GCP(Google Cloud)로 서버 1시간 안에 띄우는 법: 초보도 실패 없는 설정 체크리스트 12