2026. 6. 6. 17:11ㆍCloud/GCP
Cloud Run은 컨테이너를 배포 단위로 사용하는 서버리스 플랫폼이고, Cloud Functions는 함수 단위의 이벤트 기반 서버리스(FaaS)입니다. 2024년 8월 이후 Google은 Cloud Functions를 "Cloud Run functions"로 리브랜딩하며 Cloud Run 플랫폼 위에서 실행하도록 통합했지만, 두 서비스의 설계 철학과 적합한 워크로드는 여전히 다릅니다.
핵심 요약
- Cloud Run은 컨테이너 이미지를 배포 단위로 사용합니다. HTTP 서버를 직접 구현하며, 런타임 환경을 완전히 제어할 수 있습니다.
- Cloud Functions(Cloud Run functions)는 소스 코드(함수) 를 배포 단위로 사용합니다. 빌드와 컨테이너화를 플랫폼이 처리합니다.
- Cloud Run은 최대 8 vCPU, 32 GiB 메모리, 요청 타임아웃 60분까지 지원합니다. Cloud Functions는 최대 4 vCPU, 16 GiB, 60분(HTTP) / 9분(이벤트)입니다.
- Cloud Run은 인스턴스당 최대 1,000 동시 요청을 처리할 수 있어 비용 효율이 높습니다. Cloud Functions도 2세대(Cloud Run functions)부터 동일하게 1,000 동시성을 지원합니다.
- 단일 목적의 이벤트 핸들러라면 Cloud Functions, HTTP 기반 서비스나 컨테이너 제어가 필요하면 Cloud Run을 우선 검토합니다.
1. 왜 이 비교가 필요한가
GCP에서 서버리스로 API를 하나 배포하려고 합니다. Cloud Run도 되고 Cloud Functions도 됩니다. 둘 다 서버 관리 없이 코드를 배포하고, 트래픽에 따라 자동 스케일링되며, 사용한 만큼만 과금됩니다.
그런데 막상 선택하려면 혼란이 생깁니다.
- "컨테이너 안 만들어도 되면 Cloud Functions가 더 간편한 거 아닌가?"
- "Cloud Functions가 Cloud Run 위에서 돌아간다면, 그냥 Cloud Run 쓰면 되는 거 아닌가?"
- "비용은 어느 쪽이 더 싼가?"
이 글에서는 두 서비스의 구조적 차이를 정리하고, 어떤 워크로드에 어떤 서비스를 선택하는 것이 적합한지 판단 기준을 제시합니다.
2. 서비스 개요
2.1 Cloud Run
Cloud Run은 컨테이너 이미지를 실행하는 서버리스 플랫폼입니다. 사용자가 Dockerfile로 이미지를 빌드하고, Cloud Run에 배포하면 플랫폼이 인스턴스를 관리합니다.
핵심 특성:
| 항목 | 설명 |
|---|---|
| 배포 단위 | 컨테이너 이미지 (Dockerfile 또는 Buildpack) |
| 실행 모델 | HTTP 요청을 수신하는 서버 프로세스 |
| 스케일링 | 0에서 N까지 자동 스케일링 (요청 기반) |
| 런타임 | 임의 언어, 임의 바이너리, 커스텀 의존성 가능 |
| 상태 | Stateless (인스턴스 간 상태 공유 없음) |
Cloud Run의 핵심은 "포트를 리스닝하는 컨테이너를 주면, 나머지는 플랫폼이 처리한다" 는 것입니다. 어떤 웹 프레임워크든, 어떤 언어든, 심지어 컴파일된 바이너리도 컨테이너에 넣으면 실행됩니다.
2.2 Cloud Functions (Cloud Run functions)
Cloud Functions는 함수 단위의 이벤트 드리븐 서버리스 플랫폼입니다. 소스 코드를 배포하면, 플랫폼이 컨테이너 빌드부터 HTTP 엔드포인트 생성까지 처리합니다.
핵심 특성:
| 항목 | 설명 |
|---|---|
| 배포 단위 | 소스 코드 (함수 + 의존성 파일) |
| 실행 모델 | 이벤트 트리거 시 함수 실행 |
| 스케일링 | 0에서 N까지 자동 스케일링 (이벤트 기반) |
| 런타임 | Node.js, Python, Go, Java, .NET, Ruby, PHP (지원 목록 제한) |
| 상태 | Stateless |
Cloud Functions의 핵심은 "함수 하나만 작성하면, 인프라는 플랫폼이 알아서 한다" 는 것입니다. Dockerfile을 만들 필요가 없고, HTTP 서버를 띄울 필요도 없습니다.
2024년 8월, Google은 Cloud Functions를 "Cloud Run functions"로 리브랜딩했습니다. 2세대(2nd gen) Cloud Functions는 내부적으로 Cloud Run 인프라 위에서 실행됩니다. 다만 배포 경험, 이벤트 트리거, 과금 모델에서 차이가 있으므로 이 글에서는 기능적 차이를 기준으로 비교합니다.
3. 아키텍처 비교
두 서비스의 요청 처리 구조를 비교하면 다음과 같습니다.
Cloud Run: 1. 사용자가 컨테이너 이미지를 빌드합니다 (Dockerfile 작성 → Cloud Build 또는 로컬 빌드). 2. Artifact Registry에 이미지를 푸시합니다. 3. Cloud Run 서비스로 배포합니다. 4. 요청이 들어오면 Cloud Run이 컨테이너 인스턴스를 시작하고, 포트로 요청을 전달합니다. 5. 하나의 인스턴스가 여러 동시 요청을 처리할 수 있습니다.
Cloud Functions: 1. 사용자가 함수 소스 코드를 작성합니다. 2. gcloud functions deploy로 배포하면, 플랫폼이 자동으로 빌드하고 컨테이너화합니다. 3. 트리거(HTTP, Pub/Sub, Cloud Storage 등)가 발생하면 함수가 실행됩니다. 4. 2세대에서는 하나의 인스턴스가 여러 동시 요청을 처리할 수 있습니다 (1세대는 1 요청/인스턴스).
4. 주요 차이점 비교
4.1 배포와 런타임
| 기준 | Cloud Run | Cloud Functions |
|---|---|---|
| 배포 형태 | 컨테이너 이미지 | 소스 코드 (ZIP 또는 저장소 연결) |
| Dockerfile 필요 | 필요 (또는 Buildpack 사용) | 불필요 (플랫폼이 빌드) |
| 런타임 선택 | 제한 없음 (임의 언어/바이너리) | Node.js, Python, Go, Java, .NET, Ruby, PHP |
| 서버 구현 | 직접 HTTP 서버 구현 | 함수 시그니처만 작성 |
| 포트 리스닝 | 명시적 (PORT 환경변수) | 플랫폼이 처리 |
| 로컬 테스트 | 컨테이너로 동일 환경 재현 가능 | Functions Framework 필요 |
실무 시나리오:
기존 Express.js 애플리케이션을 GCP로 마이그레이션한다면, Cloud Run이 적합합니다. 기존 코드를 거의 수정 없이 컨테이너로 감싸서 배포할 수 있습니다.
반면 "S3 버킷에 파일이 업로드되면 썸네일을 생성한다"처럼 단일 이벤트에 단일 작업을 수행하는 경우, Cloud Functions가 더 간편합니다. 서버 코드 없이 함수 하나만 작성하면 됩니다.
4.2 스케일링과 동시성
| 기준 | Cloud Run | Cloud Functions (2nd gen) | Cloud Functions (1st gen) |
|---|---|---|---|
| 최대 인스턴스 | 리전/할당량 기반 (기본 1,000+) | 리전/할당량 기반 | 3,000 |
| 최소 인스턴스 | 설정 가능 (Cold Start 방지) | 설정 가능 | 미지원 |
| 인스턴스당 동시성 | 최대 1,000 요청 | 최대 1,000 요청 | 1 요청 (고정) |
| Scale to Zero | 지원 | 지원 | 지원 |
| CPU 할당 방식 | 요청 처리 중만 / 항상 할당 선택 가능 | 요청 처리 중만 / 항상 할당 선택 가능 | 요청 처리 중만 |
동시성은 비용에 직접 영향을 줍니다. 인스턴스당 동시 요청을 250으로 설정하면, 초당 1,000 요청을 4개 인스턴스로 처리할 수 있습니다. 동시성이 1이면 같은 트래픽에 1,000개 인스턴스가 필요합니다.
두 서비스 모두 최소 인스턴스(min instances)를 설정해 Cold Start를 줄일 수 있습니다. 다만 최소 인스턴스는 유휴 상태에서도 비용이 발생하므로, 응답 지연에 민감한 워크로드에서만 사용을 검토합니다. Cloud Run의 "CPU always allocated" 모드에서는 유휴 시에도 백그라운드 작업을 실행할 수 있어 리소스를 더 효율적으로 활용할 수 있습니다.
4.3 리소스 제한
| 기준 | Cloud Run | Cloud Functions (2nd gen) | Cloud Functions (1st gen) |
|---|---|---|---|
| 최대 vCPU | 8 | 4 | 미지정 (메모리 기반) |
| 최대 메모리 | 32 GiB | 16 GiB | 8 GB |
| 요청 타임아웃 | 최대 60분 (서비스) | 최대 60분 (HTTP) / 9분 (이벤트) | 9분 |
| 태스크 타임아웃 | 최대 7일 (Cloud Run Jobs) | 미지원 | 미지원 |
| 최대 요청 크기 | 32 MB | 10 MB (1st gen) / 32 MB (2nd gen) | 10 MB |
Cloud Functions 1st gen은 메모리 설정에 따라 CPU가 자동 할당되며, 별도로 vCPU를 지정할 수 없습니다.
Cloud Run이 리소스 상한이 더 높습니다. 무거운 연산이나 긴 처리 시간이 필요한 워크로드에서는 Cloud Run이 유일한 선택지가 될 수 있습니다.
4.4 이벤트 트리거
| 트리거 유형 | Cloud Run | Cloud Functions |
|---|---|---|
| HTTP 요청 | ✅ 기본 지원 | ✅ 기본 지원 |
| Pub/Sub | ✅ (Push subscription 연동) | ✅ 네이티브 트리거 |
| Cloud Storage | ✅ (Eventarc 통한 연동) | ✅ 네이티브 트리거 |
| Firestore | ✅ (Eventarc) | ✅ 네이티브 트리거 |
| Cloud Scheduler | ✅ (HTTP 호출) | ✅ (HTTP 또는 Pub/Sub) |
| Eventarc | ✅ 직접 수신 | ✅ 지원 |
| 커스텀 이벤트 소스 | ✅ (Eventarc + CloudEvents) | ✅ (2nd gen에서 Eventarc) |
Cloud Functions의 강점은 이벤트 트리거 설정이 배포 명령에 포함된다는 점입니다. gcloud functions deploy --trigger-bucket=my-bucket 한 줄로 Cloud Storage 이벤트 연동이 끝납니다.
Cloud Run에서 같은 작업을 하려면, Eventarc 트리거를 별도로 생성하거나 Pub/Sub Push 구독을 설정해야 합니다. 동작 자체는 동일하지만, 설정 단계가 하나 더 들어갑니다.
4.5 비용 구조
두 서비스 모두 사용량 기반 과금이며, 무료 티어를 제공합니다.
| 과금 항목 | Cloud Run | Cloud Functions |
|---|---|---|
| vCPU 시간 | $0.00002400 / vCPU-초 | Cloud Run 가격 동일 (2nd gen) |
| 메모리 시간 | $0.00000250 / GiB-초 | Cloud Run 가격 동일 (2nd gen) |
| 요청 수 | $0.40 / 100만 요청 | $0.40 / 100만 호출 |
| 네트워크 | 외부 전송 $0.12/GB | 외부 전송 $0.12/GB |
| 무료 티어 (월) | vCPU 180,000초 + 메모리 360,000 GiB-초 + 200만 요청 | 200만 호출 + 400,000 GB-초 + 200,000 GHz-초 |
위 가격은 Tier 1 리전(us-central1 등) 기준입니다. Tier 2 리전은 약 40% 높은 요금이 적용됩니다. 정확한 최신 가격은 Cloud Run 가격 페이지에서 확인할 수 있습니다.
비용 관점에서의 핵심 차이:
- 2세대 Cloud Functions는 내부적으로 Cloud Run 인프라를 사용하므로, 과금 모델이 거의 동일합니다.
- Cloud Run은 "CPU always allocated" 모드를 선택하면 인스턴스 수명 전체에 과금됩니다. 이 모드는 유휴 시에도 백그라운드 작업을 실행할 수 있어 일부 워크로드에서 비용 효율적입니다.
- 높은 동시성 설정은 인스턴스 수를 줄여 비용을 절감합니다. 1세대 Cloud Functions처럼 동시성 1이면 요청마다 인스턴스가 필요해 비용이 급증할 수 있습니다.
실무 시나리오:
하루 100만 API 호출을 처리하는 서비스를 운영한다면, Cloud Run에서 동시성을 높게 설정하고 최소 인스턴스를 유지하는 것이 Cold Start도 줄이고 비용도 예측 가능합니다. 반면 하루 1,000건 미만의 간헐적 이벤트를 처리하는 경우, Cloud Functions의 무료 티어 안에서 운영비가 0에 가까울 수 있습니다.
5. 선택 기준 의사결정
Cloud Run을 선택하는 경우
- 기존 컨테이너화된 애플리케이션을 서버리스로 마이그레이션할 때
- 여러 엔드포인트를 하나의 서비스로 묶어야 할 때 (REST API, gRPC 등)
- 지원 런타임 외의 언어나 바이너리를 사용해야 할 때 (Rust, C++, 커스텀 라이브러리)
- 긴 처리 시간(10분 이상)이 필요한 워크로드
- 높은 리소스(8 vCPU, 32 GiB)가 필요한 연산
- Cloud Run Jobs로 배치 작업을 실행할 때
- WebSocket, gRPC 스트리밍 등 HTTP/2 기능이 필요할 때
Cloud Functions를 선택하는 경우
- 단일 이벤트에 단일 작업을 수행하는 간단한 핸들러
- 빠른 프로토타이핑: Dockerfile 없이 코드만 배포해서 즉시 테스트
- 이벤트 소스 연동이 핵심인 워크로드 (Cloud Storage 파일 업로드, Pub/Sub 메시지, Firestore 변경)
- 팀에 컨테이너 경험이 없는 경우
- 간헐적으로 실행되는 가벼운 작업 (월 수천 건 이하)
- 인프라 설정을 최소화하고 함수 로직에만 집중하고 싶을 때
판단이 어려운 경우
두 서비스의 경계가 모호해지는 상황도 있습니다.
- 2세대 Cloud Functions는 Cloud Run 위에서 실행되므로, 성능이나 스케일링 특성이 거의 동일합니다.
- Cloud Run도 소스 기반 배포(Source Deploy)를 지원하므로 Dockerfile 없이도 배포할 수 있습니다.
이런 경우에는 "앞으로의 확장 방향" 을 기준으로 판단합니다.
- 서비스가 커질 가능성이 있다면 → Cloud Run (나중에 엔드포인트 추가, 미들웨어 추가가 자유로움)
- 독립적인 이벤트 핸들러로 유지될 가능성이 높다면 → Cloud Functions (단순성 유지)
6. 실무 아키텍처 예시
시나리오: 이커머스 플랫폼의 서버리스 설계
온라인 쇼핑몰 백엔드를 GCP 서버리스로 설계한다고 가정합니다.
| 컴포넌트 | 선택 | 이유 |
|---|---|---|
| 상품 API (CRUD) | Cloud Run | 여러 엔드포인트, REST 라우팅, 미들웨어 필요 |
| 주문 처리 서비스 | Cloud Run | 복잡한 비즈니스 로직, 외부 결제 API 연동, 긴 처리 시간 가능 |
| 이미지 리사이징 | Cloud Functions | Cloud Storage 업로드 이벤트 → 썸네일 생성, 단일 작업 |
| 알림 발송 | Cloud Functions | Pub/Sub 메시지 수신 → 이메일/SMS 발송, 단일 작업 |
| 일일 리포트 생성 | Cloud Run Jobs | 스케줄 기반 배치, 대량 데이터 처리, 긴 실행 시간 |
| 실시간 재고 동기화 | Cloud Functions | Firestore 변경 트리거 → 재고 캐시 갱신 |
이 구조에서 핵심 원칙은 다음과 같습니다:
- HTTP 기반 서비스: Cloud Run (라우팅, 미들웨어, 여러 엔드포인트)
- 이벤트 기반 단일 작업: Cloud Functions (트리거 연동의 간편함)
- 배치 작업: Cloud Run Jobs (긴 실행 시간, 재시도 제어)
7. 운영 고려사항
모니터링과 로깅
두 서비스 모두 Cloud Logging과 Cloud Monitoring에 자동 통합됩니다. 다만 운영 관점에서 차이가 있습니다.
| 항목 | Cloud Run | Cloud Functions |
|---|---|---|
| 구조화 로깅 | 직접 구현 (JSON stdout) | 직접 구현 (JSON stdout) |
| 커스텀 메트릭 | Cloud Monitoring API 직접 연동 | 동일 |
| 에러 리포팅 | Error Reporting 자동 연동 | 자동 연동 |
| 트레이싱 | Cloud Trace 수동 계측 또는 자동 | 자동 계측 지원 |
| 리비전 관리 | 트래픽 분할(Canary) 가능 | 미지원 (배포 = 전체 교체) |
Cloud Run은 트래픽 분할(Traffic Splitting) 을 지원합니다. 새 버전을 배포할 때 10%만 새 리비전으로 보내고 점진적으로 늘리는 Canary 배포가 가능합니다. Cloud Functions에는 이 기능이 없으므로, 배포하면 즉시 모든 트래픽이 새 버전으로 전환됩니다.
보안
| 항목 | Cloud Run | Cloud Functions |
|---|---|---|
| IAM 인증 | 서비스 단위 IAM 정책 | 함수 단위 IAM 정책 |
| VPC 연결 | Serverless VPC Access / Direct VPC Egress | Serverless VPC Access / Direct VPC Egress |
| Secret 관리 | Secret Manager 연동 (환경변수/볼륨) | Secret Manager 연동 (환경변수) |
| Ingress 제어 | Internal / Internal + Load Balancing / All | Internal / Internal + Load Balancing / All |
| 서비스 계정 | 서비스별 커스텀 SA 지정 | 함수별 커스텀 SA 지정 |
보안 기능은 거의 동일합니다. 두 서비스 모두 최소 권한 원칙에 따라 전용 서비스 계정을 생성하고, 필요한 역할만 부여하는 것이 기본입니다.
8. 마이그레이션 경로
Cloud Functions에서 Cloud Run으로 마이그레이션하는 경우가 일반적입니다. 서비스가 성장하면서 다음 요구가 생기면 전환을 검토합니다.
- 여러 엔드포인트를 하나의 서비스로 통합해야 할 때
- 지원 런타임 외 언어가 필요할 때
- 더 높은 리소스 제한이 필요할 때
- Canary 배포가 필요할 때
마이그레이션 단계:
- 기존 Cloud Functions 코드를 웹 프레임워크(Express, Flask 등)로 래핑합니다.
- Dockerfile을 작성하거나 Buildpack을 사용해 컨테이너 이미지를 빌드합니다.
- Cloud Run 서비스로 배포하고, 기존 트리거를 Eventarc 또는 Pub/Sub Push로 전환합니다.
- 트래픽을 점진적으로 이동시킵니다.
반대 방향(Cloud Run → Cloud Functions)은 드뭅니다. 일반적으로 서비스 복잡도는 증가하는 방향으로 진화하기 때문입니다.
9. 요약 비교 테이블
| 기준 | Cloud Run | Cloud Functions (2nd gen) |
|---|---|---|
| 배포 단위 | 컨테이너 이미지 | 소스 코드 (함수) |
| 런타임 자유도 | 제한 없음 | 지원 런타임만 |
| HTTP 서버 | 직접 구현 | 플랫폼이 처리 |
| 이벤트 트리거 | Eventarc / Pub/Sub 연동 | 네이티브 트리거 내장 |
| 최대 리소스 | 8 vCPU, 32 GiB | 4 vCPU, 16 GiB |
| 최대 타임아웃 | 60분 (서비스), 7일 (Job) | 60분 (HTTP), 9분 (이벤트) |
| 동시성 | 최대 1,000/인스턴스 | 최대 1,000/인스턴스 |
| 트래픽 분할 | 지원 (Canary 배포) | 미지원 |
| Dockerfile 필요 | 필요 (또는 Source Deploy) | 불필요 |
| 적합한 워크로드 | HTTP 서비스, 마이크로서비스, 배치 | 이벤트 핸들러, 글루 코드, 프로토타입 |
10. 결론
Cloud Run과 Cloud Functions는 경쟁 관계가 아니라 보완 관계입니다. Google이 Cloud Functions를 Cloud Run 플랫폼 위로 통합한 것 자체가, 두 서비스의 기반 인프라는 같되 사용 경험을 분리한다는 설계 의도를 보여줍니다.
선택 기준을 한 줄로 요약하면:
- 컨테이너를 직접 제어하고 싶거나, 여러 엔드포인트가 있는 서비스 → Cloud Run
- 이벤트에 반응하는 단일 함수로 충분하고, 인프라 설정을 최소화하고 싶다 → Cloud Functions
실무에서는 하나의 프로젝트 안에서 두 서비스를 함께 사용하는 것이 일반적입니다. API 서비스는 Cloud Run으로, 이벤트 핸들러는 Cloud Functions로 구성하면 각 서비스의 강점을 활용할 수 있습니다.
참고 자료
'Cloud > GCP' 카테고리의 다른 글
| GCP GKE 기본 구조: Autopilot vs Standard, Node Pool, Networking (0) | 2026.06.08 |
|---|---|
| GCP Cloud Storage 종류와 선택 기준: Standard, Nearline, Coldline, Archive (0) | 2026.06.07 |
| GCP Cloud Load Balancing 기본 구조 정리: 종류, 구성 요소, 동작 원리 (0) | 2026.05.30 |
| GCP IAM 기본 개념: Role, Principal, Policy 이해하기 (0) | 2026.05.30 |
| GCP VPC란 무엇인가: Subnet, Firewall Rule, Route 개념 정리 (0) | 2026.05.30 |