GCP에서 '서버리스'를 검색하면 세 가지 서비스가 동시에 나옵니다. App Engine, Cloud Run, Cloud Functions. 세 서비스 모두 인프라를 직접 관리하지 않는다는 공통점이 있지만, 동작 방식과 적합한 워크로드가 뚜렷이 다릅니다. 이 글은 53개의 실제 GCP-ACE 시험 문제에서 추출한 패턴을 기반으로 각 서비스의 결정적 차이와 배포 실무를 정리합니다.
---
서버리스라는 단어가 가리키는 세 가지 서비스
| 서비스 | 추상화 수준 | 주요 대상 | 과금 기준 | |--------|------------|----------|----------| | App Engine | 플랫폼 (PaaS) | 풀스택 웹 앱 | 인스턴스 시간 | | Cloud Run | 컨테이너 서버리스 | HTTP 마이크로서비스 | CPU·메모리·요청 수 | | Cloud Functions | 함수 서버리스 | 이벤트 기반 단기 함수 | 호출 횟수·실행 시간 |
App Engine은 코드와 런타임 설정만 올리면 로드 밸런서·HTTPS·오토스케일링까지 Google이 관리합니다. Cloud Run은 Docker 컨테이너를 그대로 배포하는 서버리스로 언어와 프레임워크 제약이 없습니다. Cloud Functions는 함수 단위 코드를 이벤트에 연결하는 가장 가벼운 서버리스입니다. 세 서비스의 차이는 '무엇을 배포하느냐'입니다.
---
App Engine Standard vs Flexible
App Engine은 두 가지 환경을 제공합니다. 이 두 환경의 차이를 이해하는 것이 App Engine 문제를 푸는 핵심입니다.
| 항목 | Standard 환경 | Flexible 환경 | |------|-------------|-------------| | 런타임 | Python, Java, Go, Node.js, Ruby, PHP (특정 버전) | 모든 언어 (커스텀 Dockerfile) | | 인스턴스 시작 | 수 초 (밀리초 수준도 가능) | 수 분 | | 스케일 투 제로 | 가능 (트래픽 없을 때 인스턴스 0) | 불가 (최소 1개 유지) | | VPC 직접 연결 | 불가 (Serverless VPC Access Connector 필요) | 가능 | | 비용 모델 | 인스턴스 초 단위 과금, 유휴 시 0 | 최소 1인스턴스 상시 과금 | | 파일 시스템 | 읽기 전용 (로컬 /tmp 쓰기 가능) | 읽기·쓰기 가능 |
Standard 환경의 장점은 빠른 콜드 스타트와 스케일 투 제로입니다. 트래픽 변동이 심한 앱에 비용 효율적이지만 런타임 버전이 고정되어 있어 특정 라이브러리 의존성에 제약이 생길 수 있습니다.
Flexible 환경은 커스텀 Docker 이미지와 VPC 직접 연결이 가능하지만 최소 1개 인스턴스를 항상 유지하므로 유휴 비용이 발생합니다. 시험에서는 'VPC 직접 연결'이 나오면 Flexible, '트래픽 없을 때 비용 0'이 나오면 Standard를 선택하세요. 중요한 제약: App Engine 앱은 프로젝트당 하나만 생성할 수 있고 최초 배포 시 설정한 리전을 변경할 수 없습니다. 리전을 바꾸려면 새 프로젝트를 생성해야 합니다.
---
Cloud Run: 컨테이너 기반 서버리스의 표준
Cloud Run은 GCP 서버리스 중 가장 범용적입니다. 언어·프레임워크 제약 없이 Docker 컨테이너를 그대로 배포할 수 있습니다.
Cloud Run의 핵심은 요청 기반 스케일링입니다. 요청이 없으면 인스턴스가 0개로 줄고, 트래픽 급증 시 기본 최대 1,000개까지 자동 확장됩니다.
| Cloud Run 주요 설정 | 기본값 | 설명 | |--------------------|-------|------| | 동시성 (concurrency) | 80 | 인스턴스 하나가 동시에 처리하는 최대 요청 수 | | 최소 인스턴스 | 0 | 항상 유지할 최소 인스턴스 수 | | 최대 인스턴스 | 1,000 | 스케일 아웃 상한선 | | 요청 타임아웃 | 최대 3,600초 | 단일 요청 처리 최대 시간 | | CPU 할당 | 요청 처리 중만 | --cpu-always-on으로 상시 할당 가능 |
Cloud Run은 두 가지 형태로 사용합니다. 서비스(Service)는 HTTP 요청을 지속적으로 받는 웹 API·웹 앱에 해당하고, 작업(Job)은 HTTP 엔드포인트 없이 배치 처리를 완료하면 종료됩니다.
비동기 처리에서는 Pub/Sub Push 구독이 Cloud Run을 호출하는 구조가 일반적이며, OIDC 토큰 인증이 Google 권장 방식입니다. API 키 방식은 시험에서 오답입니다.
---
Cloud Functions와 이벤트 트리거 모델
Cloud Functions는 함수 단위로 코드를 배포하고 이벤트에 연결하는 서비스입니다. Cloud Run이 컨테이너 단위라면, Cloud Functions는 함수 단위입니다.
| 트리거 종류 | 예시 이벤트 | 1세대 지원 | 2세대 지원 | |------------|------------|-----------|----------| | HTTP | HTTP 요청 수신 | 지원 | 지원 | | Cloud Storage | 객체 업로드(finalize), 삭제, 메타데이터 변경 | 지원 | 지원 | | Cloud Pub/Sub | 토픽에 메시지 게시 | 지원 | 지원 | | Firestore | 문서 생성·수정·삭제 | 지원 | 지원 | | Eventarc (기타) | BigQuery, Cloud Audit Logs 등 90개 이상 | 미지원 | 지원 |
1세대와 2세대의 핵심 차이는 실행 시간 한도와 동시성입니다. 2세대는 내부적으로 Cloud Run 위에서 동작하여 HTTP 트리거 최대 60분 실행, Cloud Run과 동일한 동시성 설정이 가능합니다.
| 항목 | Cloud Functions 1세대 | Cloud Functions 2세대 | |------|-------------------|-------------------| | 최대 실행 시간 | 9분 | HTTP 60분, 이벤트 9분 | | 기반 인프라 | 자체 인프라 | Cloud Run | | 동시성 | 인스턴스당 1 요청 | Cloud Run과 동일 (설정 가능) | | Eventarc 통합 | 미지원 | 지원 | | 트래픽 분할 | 미지원 | 지원 |
Cloud Functions의 전형적인 사례는 Cloud Storage 이벤트 처리입니다. 이미지를 버킷에 업로드하면 이벤트가 발생하고, 연결된 Cloud Functions가 자동 실행되어 리사이징이나 메타데이터 추출을 처리합니다. 이벤트가 없을 때는 비용이 0입니다. 과금 기준은 호출 횟수와 실행 시간(100ms 단위)이며, 월 200만 호출·360,000 GB-초가 무료 티어로 제공됩니다.
---
트래픽 분할과 무중단 배포 패턴
App Engine의 트래픽 분할(Traffic Splitting)은 동일 서비스 내 여러 버전에 트래픽 비율을 나누어 카나리 배포, A/B 테스트, 블루-그린 전환을 네이티브로 구현하는 기능입니다.
| 분할 방식 | 특성 | 사용 시나리오 | |----------|------|-------------| | IP 기반 | 동일 사용자가 항상 같은 버전으로 라우팅 | 사용자 경험 일관성 필요 시 | | 쿠키 기반 | HTTP 쿠키로 사용자 고정 (IP보다 안정적) | 로그인 세션이 있는 앱 | | 랜덤 분할 | 요청마다 독립적으로 버전 선택 | 순수 비율 테스트 |
트래픽 분할 설정과 롤백은 gcloud 명령어 하나로 처리합니다.
카나리 배포 (신버전 10%): 즉시 롤백:
새 버전을 배포하면서 트래픽은 유지하려면 플래그를 사용합니다. 새 버전이 배포되어도 트래픽이 자동 전환되지 않으며, 준비가 완료된 시점에 수동으로 비율을 조정합니다.
Cloud Run도 리비전 단위로 버전을 관리하며 여러 리비전 간 트래픽 분할을 지원합니다.
| 서비스 | 버전 단위 | 트래픽 분할 | 즉시 롤백 | |--------|----------|------------|----------| | App Engine | 버전(Version) | 지원 (IP/쿠키/랜덤) | 지원 | | Cloud Run | 리비전(Revision) | 지원 | 지원 | | Cloud Functions 1세대 | 미지원 | 미지원 | 재배포 필요 | | Cloud Functions 2세대 | 지원 | 지원 | 지원 |
시험에서 '재배포 없이 즉시 롤백'이 나오면 App Engine 트래픽 분할이 정답입니다. 배포된 버전은 명시적으로 삭제하기 전까지 유지되므로 이전 버전으로 트래픽을 100% 전환하면 바로 롤백이 완료됩니다.
---
동시성·최소 인스턴스·콜드 스타트의 트레이드오프
서버리스에서 비용과 응답 속도는 서로 반대 방향으로 움직입니다. 이 트레이드오프를 이해하는 것이 실무 설계와 시험 모두에 중요합니다.
콜드 스타트(Cold Start)는 인스턴스가 0인 상태에서 첫 요청이 들어올 때 기동 지연이 발생하는 현상입니다. App Engine Standard와 Cloud Run 모두 최소 인스턴스 설정으로 제어합니다.
| 설정 | 효과 | 비용 영향 | |------|------|----------| | 최소 인스턴스 = 0 | 콜드 스타트 발생 가능 | 유휴 비용 없음 | | 최소 인스턴스 >= 1 | 콜드 스타트 제거 | 유휴 인스턴스 비용 발생 | | 동시성 증가 | 인스턴스 수 감소 | 인스턴스당 처리량 증가 | | 동시성 = 1 | 요청마다 별도 인스턴스 필요 | 인스턴스 수 증가 가능 |
App Engine Standard의 (또는 )를 1 이상으로 설정하면 항상 워밍업 인스턴스가 대기합니다. 비용은 발생하지만 첫 요청도 즉시 처리됩니다.
Cloud Run의 기본 동시성은 80으로, 인스턴스 하나가 최대 80개 요청을 동시 처리합니다. I/O 바운드 서비스는 동시성을 높게, CPU 바운드 서비스는 낮게 설정하는 것이 기본 원칙입니다. Cloud Functions 1세대는 동시성이 강제 1이어서 이벤트 100개가 동시에 오면 인스턴스 100개가 생성됩니다. 2세대는 Cloud Run과 동일한 동시성 설정을 지원합니다.
비용 최적화 전략: 개발·스테이징은 최소 인스턴스 0, SLA가 있는 프로덕션은 최소 인스턴스 1~2가 현실적 균형입니다.
---
시험에서 자주 헷갈리는 서버리스 시나리오
GCP-ACE 시험에서 서버리스 함정 문제는 몇 가지 패턴으로 반복됩니다.
Cloud Run vs Cloud Functions 구분
| 시나리오 키워드 | 정답 | |---------------|------| | 컨테이너 이미지 배포, Docker, HTTP API | Cloud Run | | 이벤트 즉시 실행, 단순 함수, Cloud Storage 업로드 반응 | Cloud Functions | | 장시간 처리 (9분 초과), 배치 작업 컨테이너 | Cloud Run (Job) | | cron 기반 주기적 실행, 서버 없이 자동화 | Cloud Scheduler + Cloud Functions |
!Cloud Run vs Cloud Functions
동시성 80과 단일 요청 처리의 차이
'Cloud Run의 동시성 80'은 인스턴스 하나가 동시에 80개 요청을 처리할 수 있다는 뜻입니다. Cloud Functions 1세대만 인스턴스당 1 요청으로 고정됩니다.
Serverless VPC Access Connector
App Engine Standard, Cloud Run, Cloud Functions에서 VPC 내부 사설 IP 리소스(Cloud SQL Private IP, Memorystore 등)에 접근하려면 Serverless VPC Access Connector가 필요합니다. App Engine Flexible은 VPC 직접 연결이 가능해 Connector가 불필요합니다. 시험에서 '사설 IP 접근'이 나오면 Connector 설정이 답에 포함됩니다.