Firebase Extensions 서비스는 지원 중단되었으며 2027년 3월 31일에 종료됩니다. 이미 설치된 확장 프로그램은 무기한으로 실행되지만 이 날짜 이후에는 주요 관리 기능을 더 이상 사용할 수 없습니다. 추가 마이그레이션 안내 및 도구는 2026년 9월에 출시될 예정입니다.
지원 중단 개요
Firebase Extensions이 지원 중단되는 이유는 무엇인가요?
기본 Google Cloud 인프라의 예정된 변경사항과 지원 중단으로 인해 관리형 Firebase Extensions 서비스가 종료됩니다.
2027년 3월 31일 이후 기존에 배포된 확장 프로그램이 작동하지 않게 되나요?
아니요. 이미 배포된 확장 프로그램은 표준 Google Cloud 인프라 (예: Cloud Functions, Eventarc, Cloud Run, Cloud Tasks)에서 직접 실행되며 무기한으로 계속 실행됩니다.
하지만 2027년 3월 31일 이후에는 Firebase 콘솔 또는 CLI를 통해 이러한 확장 프로그램을 업데이트, 재구성, 제거할 수 없게 됩니다. 함수 키트로 이전하는 데 도움이 되는 기존 확장 프로그램 구성을 다운로드하는 기능도 사용할 수 없게 됩니다. 2027년 3월 31일까지 확장 프로그램 구성을 이전하거나 내보내는 것이 좋습니다.
사용자가 아무 조치도 취하지 않으면 어떻게 되나요?
사용자가 아무 조치도 취하지 않으면 기존에 배포된 함수가 표준 애셋으로 계속 실행됩니다. 하지만 2027년 3월 31일 이후에는 다음 사항이 적용됩니다.
- 구성 매개변수를 변경하거나 환경 변수를 업데이트할 수 없습니다.
- 버그 수정, 보안 패치 또는 종속 항목 업그레이드를 적용할 수 없습니다.
- 교체 기능 키트를 동일하게 구성하는 데 도움이 되는 확장 프로그램 구성을 다운로드할 수 없습니다.
- 현재 대부분의 확장 프로그램은 이전 Node.js 런타임에 연결된 기존 Cloud Functions v1 SDK를 기반으로 빌드됩니다. 이러한 기존 런타임이 Google Cloud에 의해 완전히 서비스 중지되면 함수가 실행을 중지하거나 사용 중지될 수 있습니다. 런타임 지원을 참고하세요.
Firebase Extensions를 대체하는 것이 있나요?
Cloud Functions에 확장 프로그램을 대체할 수 있는 다양한 기능이 추가되었습니다. 가장 주목할 만한 것은 npm을 사용하여 배포할 수 있고 단일 프로젝트에서 확장 프로그램을 여러 번 설치할 수 있는 것과 유사하게 함수의 여러 인스턴스를 배포할 수 있는 함수 키트입니다.
하지만 npm에 공식 함수 키트 대체 항목을 게시할지 여부는 각 확장 프로그램 게시자가 결정합니다. 확장 프로그램은 오픈소스이므로 게시자가 공식 대체 항목을 만들고 싶지 않다면 개발자가 포크하여 Node SDK에서 2세대 API를 사용하여 Cloud Functions로 비공식 대체 항목을 만들 수 있습니다.
교체를 원하는 게시자는 게시자 이전 가이드의 안내를 따라야 합니다.
공식 대체 패키지를 활용하거나 자체 대체 패키지를 만들려는 사용자는 사용자용 이전 가이드의 안내를 따르세요.
확장 프로그램 사용자는 어떻게 해야 하나요?
확장 프로그램 사용자이고 더 이상 설치된 확장 프로그램을 사용하지 않는 경우 2027년 3월 31일 전에 확장 프로그램을 제거하세요.
서비스 해지 후 Firebase 콘솔의 '제거' 버튼과 해당 CLI 명령어가 삭제됩니다. Google Cloud 콘솔을 사용하여 개별 Cloud Functions, Secret Manager 보안 비밀, Cloud Tasks 대기열, 맞춤 IAM 서비스 계정을 비롯한 연결된 모든 Google Cloud 리소스를 수동으로 삭제해야 합니다.
하지만 설치된 확장 프로그램을 적극적으로 사용하는 경우 함수 키트로 마이그레이션하는 것이 좋습니다. 함수 키트로 이동하려면 사용자 마이그레이션 가이드의 안내를 따르세요.
함수 키트로 이전하지 않을 수도 있습니다. 이 경우 나중에 이전할 수 있도록 모든 확장 프로그램을 최신 버전으로 업데이트하고, 최신 상태로 유지하고, 기존 확장 프로그램 구성을 내보내는 것이 좋습니다.
확장 프로그램 게시자로서 무엇을 해야 하나요?
게시된 확장 프로그램을 npm에 게시된 함수 키트로 마이그레이션하는 것이 좋습니다. 함수 키트를 만드는 데 필요한 전제 조건인 2세대 함수로 확장 프로그램을 마이그레이션하는 것부터 시작할 수 있습니다. 여기에는 Cloud Functions v2 SDK를 사용하여 확장 프로그램 로직을 패키징하는 작업이 포함됩니다. 선언적 보안 및 수명 주기 이벤트와 같은 기능을 지원하도록 Cloud Functions v2 SDK가 업데이트되었습니다. 이제 핵심 비즈니스 로직을 최소한으로 변경하여 기존 확장 프로그램 코드를 2세대 함수로 이전할 수 있습니다. 이러한 함수는 npm 패키지를 사용하여 게시할 수 있습니다. 자세한 내용은 게시자용 이전 가이드를 참고하세요.
다른 궁금한 점이 있으면 어떻게 해야 하나요?
궁금한 점이 있는 사용자는 사용자 이전 가이드를 참고하세요. 가이드를 사용한 후에도 궁금한 점이 있으면 Firebase 지원팀에 문의하세요.
Firebase Extensions을 마이그레이션하는 방법에 대해 궁금한 점이 있는 게시자는 게시자용 마이그레이션 가이드를 참고하세요. 이 가이드에는 업데이트에 대한 정보를 확인하고 게시된 확장 프로그램의 대안을 제공하는 데 도움을 받는 방법에 관한 안내가 포함되어 있습니다.
이전 옵션 및 기술 실행
사용 가능한 기본 이전 경로는 무엇인가요?
2026년 9월부터 Firebase에서는 다음 두 가지 기본 이전 경로를 공식적으로 지원합니다.
- NPM 공유 함수 ('함수 키트')로 이전: Firestore를 BigQuery로 스트리밍하는 경우와 npm에서 사용할 수 있게 되는 기타 함수 키트에 권장됩니다. 핵심 로직은 Cloud Functions v2 SDK를 사용하여 표준 NPM 라이브러리로 패키징됩니다. 사용자는 표준 Cloud Functions 코드베이스를 초기화하고, 패키지를 설치하고, 함수를 다시 내보내고, CLI를 사용하여 독립적으로 배포합니다.
- 포크 및 자체 관리: npm에서 사용할 수 있는 함수 키트가 없는 모든 확장 프로그램에 권장됩니다. 사용자는 오픈소스 확장 프로그램 소스 코드를 복사하거나 포크하고, 최선을 다하는 AI 이전 기술이나 수동 가이드를 사용하여 트리거를 표준 Firebase v2 함수로 리팩터링하고, 코드베이스와 지속적인 유지관리의 전체 소유권을 가져갑니다.
어떤 확장 프로그램이 함수 키트로 이전되나요?
Firestore를 BigQuery로 스트리밍 확장 프로그램이 npm 패키지 @firebase-function-kits/firestore-bigquery-export로 제공되는 함수 키트로 이전되었습니다.
이전하려면 Cloud Functions v1에서 v2로 업그레이드해야 하는 이유는 무엇인가요?
Cloud Functions v1 표준 지원은 Node.js 22 런타임으로 종료됩니다. 개발자가 Firebase Extensions에서 이전한 후 기존 런타임이 지원 중단될 때 두 번째 수동 리팩터링을 강제하는 '이중 이전'을 방지하기 위해 Firebase에서는 이 전환 중에 이전된 모든 함수를 v2 SDK로 즉시 업그레이드할 것을 적극 권장하며, 이는 함수 키트의 경우 필수입니다.
확장 프로그램 사용자는 사용자 이전 가이드를 사용하여 자체 함수 키트를 만들 수도 있습니다.
결제 및 가격 책정
자체 관리 Cloud Functions로 이전하면 고객의 결제가 변경되나요?
일반적으로는 아닙니다. 배포된 확장 프로그램은 이미 Cloud Functions 호출, Cloud Storage 또는 BigQuery 스토리지 및 쿼리와 같이 소비하는 기본 Google Cloud 리소스에 대해 고객에게 요금을 청구합니다. 하지만 마이그레이션 기간에 고객이 안전한 전환을 위해 기존 Firebase Extensions와 새로 배포된 대체 기능을 동시에 실행하는 경우 일시적으로 소액의 추가 비용이 발생할 수 있습니다.
Mandiant 또는 기타 전문 엔터프라이즈 계정의 청구는 어떻게 처리되나요?
이 지원 중단은 모든 Firebase 및 Google Cloud 프로젝트에 영향을 미치는 플랫폼 전체 변경사항입니다. 표준 결제 및 구독 계약은 영향을 받지 않습니다. 고객이 지원 중단 다운타임으로 인해 SLA 크레딧을 요청하거나 복잡한 결제 예외가 발생하는 경우 일반 결제 지원 채널을 통해 케이스를 직접 에스컬레이션합니다.
문제 해결 및 위험 완화
마이그레이션 중에 데이터 손실이나 서비스 다운타임이 발생할 위험은 무엇인가요?
관리 리소스를 자체 관리 코드베이스로 전환하면 서비스 중단이나 이벤트 손실이 발생할 위험이 약간 있습니다.
- 트리거 중단: 새 트리거가 활성화되기 전에 이전 트리거가 삭제되면 이벤트 (예: Cloud Firestore 문서 쓰기)가 누락되어 영구적으로 손실되는 간격이 발생합니다. 데이터 손실을 방지하려면 확장 프로그램을 삭제하기 전에 교체 키트를 배포하고 유효성을 검사하는 것이 좋습니다.
- 권한 격차: 새로 배포된 코드베이스에 필요한 IAM 권한이 없으면 BigQuery에 쓰기와 같은 작업이 자동으로 실패하거나 런타임에 비정상 종료됩니다. 함수에 선언적 보안이 추가되었으므로 역할을 쿼리하고 설정하며 서비스 계정을 생성할 수 있는 계정에서 실행하는 첫 번째 키트 배포로 이 문제가 완화됩니다.
중요한 Cloud Firestore~BigQuery 내보내기 확장 프로그램의 데이터 손실을 방지하려면 어떻게 해야 하나요?
안전하고 데이터 손실이 없는 전환을 달성하려면 지원팀에서 사용자에게 갭 기반이 아닌 오버랩 기반 컷오버를 따르도록 안내해야 합니다. 키트로 마이그레이션하는 경우 기본값은 다음과 같습니다.
- 확장 프로그램이 아직 설치되어 실행 중인 동안 대체 함수 키트를 배포합니다. Eventarc가 완전히 프로비저닝될 때까지 몇 분 정도 기다립니다.
- 감시되는 Cloud Firestore 컬렉션에 테스트 문서를 작성하고 새 자체 관리 함수가 새 이벤트 ID를 전달하여 BigQuery 변경 로그 테이블에 해당 행을 성공적으로 작성하는지 확인합니다.
- 새 배포가 작동하는지 확인한 후 즉시 기존 확장 프로그램을 제거하거나 사용 중지하여 이중 쓰기 동작을 종료합니다.
- 각 쓰기의 중복 처리 비용과 원시 BigQuery 변경 로그의 중복 행 가능성을 최소화하려면 중복 기간을 최대한 짧게 유지하세요.
- 대부분의 경우 원시 변경 로그 테이블 (
*_raw_changelog)은insertID에 의해 중복이 삭제되며 변경 로그에 중복 행이 있는 경우에도 테이블의 최신 뷰 (*_raw_latest)는 올바릅니다.
이 확장 프로그램의 이전과 데이터 손실 복구 방법에 관한 자세한 내용은 키트의 README.md를 참고하세요.
수명 주기 프로비저닝 단계가 실패하면 어떻게 해야 하나요?
관리 서비스에서는 BigQuery
데이터 세트, 테이블, 뷰 만들기 등의 설정 작업이 자동으로 처리되었습니다. 자체 관리 NPM 모델에서는 수명 주기 태스크 큐 함수를 사용하여 트리거됩니다. 예를 들어 firestore-bigquery-export에서는 initBigQuerySync라고 합니다.
이 단계가 실패하거나 자동으로 실행되지 않는 경우 다음 단계를 따르세요.
Cloud Functions 런타임 서비스 계정에 필요한 IAM 역할이 부여되었는지 확인합니다. 예를 들어
firestore-bigquery-export의 경우 다음이 포함됩니다.- 리소스를 만들고 행을 삽입하려면 다음을 실행하세요.
roles/bigquery.dataEditor - 작업을 실행하고 뷰를 빌드하려면 다음 권한이 필요합니다.
roles/bigquery.user - 프로비저닝 작업을 대기열에 추가하려면 다음을 실행하세요.
roles/cloudtasks.enqueuer
- 리소스를 만들고 행을 삽입하려면 다음을 실행하세요.
호출자에게
roles/cloudtasks.enqueuer권한이 있는지 확인합니다.CLI를 사용하여 수명 주기 초기화 명령어를 수동으로 다시 실행합니다.
firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID트리거 함수와 태스크 큐 실행 모두의 Cloud Logging 로그를 확인하여 권한 또는 구성 오류를 진단합니다.
Secret Manager 사용자 인증 정보는 어떻게 이전되나요?
관리 모델에서는 Secret Manager 리소스가 확장 프로그램 인스턴스에 자동으로 바인딩되었습니다. ext:migrate 또는 ext:export
--mode functions 명령어를 사용하여 확장 프로그램 구성을 함수 키트로 내보내면 확장 프로그램이 이러한 보안 비밀을 관리하지 않으므로 확장 프로그램을 제거한 후에도 보안 비밀이 프로젝트에 유지됩니다. 나중에 이러한 보안 비밀을 삭제하려면 Google Cloud 콘솔에서 수동으로 삭제해야 합니다.
사용자가 이전된 확장 프로그램의 여러 인스턴스를 실행하려면 어떻게 해야 하나요?
확장 프로그램의 여러 버전을 사용할 수 있는 것과 마찬가지로 함수의 여러 인스턴스를 지원하는 방법으로 함수 키트가 도입되었습니다. 각 키트에는 고유한 키트 인스턴스 ID가 부여됩니다. 이 ID는 코드베이스와 유사하며 CLI 명령어에서 코드베이스와 상호 교환적으로 사용할 수 있습니다. 배포 시 키트 인스턴스의 모든 함수에는 kit-<instance-id>-이 접두사로 붙어 모든 함수에 고유한 이름이 지정됩니다(확장의 ext-<extension-instance-id>- 접두사와 유사). 이전의 일환으로 함수 키트를 사용하는 방법을 자세히 알아보려면 사용자 이전 가이드를 참고하세요.
Kit 설치는 npm을 사용합니다. Yarn이나 다른 Node 호환 패키지 관리자를 사용하려면 어떻게 해야 하나요?
현재 Yarn 또는 기타 패키지 관리자를 지원할 계획은 없습니다. 키트 설치는 첫 번째 설치 시 키트 소스 코드를 설정할 때 npm 명령어를 직접 실행하여 작동합니다.
또는 소스 디렉터리를 만들고, 키트 npm 패키지를 직접 설치하고, 적절한 빌드 및 내보내기로 설정할 수 있습니다. TypeScript firebase-tools의 index-kit 템플릿을 참고하거나 npm으로 설치된 키트를 예로 살펴보세요. 이렇게 하면 --package이 아닌 --directory을 사용하여 로컬 키트처럼 설치할 수 있습니다. 앞으로는 디렉터리나 ID로 키트를 식별해야 하지만 키트 명령어를 사용하여 인스턴스를 추가하고 삭제할 수 있습니다.
확장 프로그램에서 Docker 저장소 또는 KMS 키 고급 시스템 매개변수를 사용합니다. 함수 키트에서 이를 구성하려면 어떻게 해야 하나요?
현재 Firebase의 경우 Cloud Functions에서 Docker 저장소 또는 KMS 키를 구성하는 것은 지원되지 않습니다. 이러한 시스템 매개변수가 구성된 확장 프로그램에서 이전하고 이 기능을 유지하려면 gcloud CLI를 사용하여 새 키트의 함수에 매개변수를 적용하면 됩니다.
기본 요건
- 마이그레이션 가이드에 따라 함수가 Google Cloud에 있도록 함수 키트를 초기 배포합니다.
터미널에서 환경 변수를 정의합니다.
export PROJECT_ID="YOUR_PROJECT_ID" export FUNCTION_REGION="YOUR_REGION" # e.g. us-east1 export KIT_NAME="YOUR_KIT_NAME" # e.g. firestore-bigquery-export export SOURCE_DIR="YOUR_KIT_SOURCE_DIR" # e.g. "./function-kits/${KIT_NAME}/source" export REPO_NAME="YOUR_DOCKER_REPO_NAME" export KEY_RING="YOUR_KMS_KEY_RING" export KEY_NAME="YOUR_KMS_KEY_NAME" # Retrieve Project Number automatically export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)")컴파일된 빌드 파일이
.gitignore에 의해 무시되지 않도록 키트의 소스 루트에.gcloudignore를 미리 만듭니다.cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore" .gcloudignore .git .gitignore node_modules #!include:.gitignore !lib/** EOF필요한 IAM 권한을 부여합니다.
KMS 키 (서비스 에이전트에 복호화 액세스 권한 부여):
for SERVICE_ACCOUNT in \ "service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \ "service-${PROJECT_NUMBER}@gcf-admin-robot.iam.gserviceaccount.com" \ "service-${PROJECT_NUMBER}@gcp-sa-artifactregistry.iam.gserviceaccount.com" do gcloud kms keys add-iam-policy-binding "$KEY_NAME" \ --keyring="$KEY_RING" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:${SERVICE_ACCOUNT}" \ --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" doneArtifact Registry (Cloud Build에 대한 쓰기 액세스 권한과 Cloud Run에 대한 읽기 액세스 권한을 부여함)의 경우:
# Grant the Cloud Build / Compute Service Account permission to write images to the repository gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --role="roles/artifactregistry.writer" # Grant Cloud Run permission to pull images from the repository gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \ --role="roles/artifactregistry.reader"
gcloud CLI을 사용하여 설정 적용하기
키트의 각 함수에 대해 gcloud functions deploy를 실행합니다.
gcloud functions deploy FUNCTION_NAME \
--project="$PROJECT_ID" \
--region="$FUNCTION_REGION" \
--source="./function-kits/${KIT_NAME}/source" \
--docker-repository="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/repositories/${REPO_NAME}" \
--kms-key="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/keyRings/${KEY_RING}/cryptoKeys/${KEY_NAME}"
이 해결 방법은 다음 조건에서 작동하지 않습니다.
- 새 키트 인스턴스:
firebase.json에 인스턴스를 추가하면 Google 관리 키와gcf-artifacts이 기본값인 새 Cloud Functions v2 리소스가 생성됩니다. 새 인스턴스마다gcloud를 실행해야 합니다. - 함수 재생성: 트리거 유형을 변경하거나 (예: HTTPS에서 Cloud Firestore 트리거로) 진입점을 변경하거나 이름을 바꾸면 Firebase CLI가 이전 함수를 삭제하고 새 함수를 만듭니다.
gcloud를 다시 실행할 때까지 새 함수는 이러한 설정을 잃게 됩니다. - 구성 드리프트: Firebase CLI는
firebase functions:list또는 차이 로그에 KMS 또는 Docker 저장소 상태를 표시하지 않으므로 인프라 감사가 어렵습니다.
성공 여부 확인
저장소와 암호화 키가 적용되었는지 확인하려면 다음 명령어를 실행합니다.
gcloud functions describe FUNCTION_NAME \
--region="$FUNCTION_REGION" \
--project="$PROJECT_ID" \
--format="yaml(state, buildConfig.dockerRepository, kmsKeyName)"