Google Cloud API에 앱을 연결해 리소스를 목록화하고, 모니터링·로깅 데이터를 읽고, IAM을 점검하고, Google Cloud 프로젝트를 관리합니다.
Google Cloud API에 앱 연결하기
Google Cloud API에 앱을 연결해 Lovable 앱에서 리소스를 목록화하고, 모니터링·로깅 데이터를 읽고, IAM을 점검하고, Google Cloud 프로젝트를 관리하세요.
Google Cloud는 Google의 클라우드 플랫폼입니다. Google Cloud API 커넥터를 사용하면 Lovable 앱이 Google Cloud 조직의 service account로서 Resource Manager, Cloud Asset Inventory, Cloud Monitoring, Cloud Logging, Compute Engine, Cloud Run 같은 모든 Google Cloud REST API를 호출할 수 있습니다. 직접 통제하는 Google Cloud 프로젝트를 읽거나 관리하는 내부 도구와 대시보드를 염두에 두고 설계되었습니다.
Google Cloud API는 앱 + 채팅 커넥터로 제공됩니다. 하나의 공유 연결이 Chats, 빌드 중 프로젝트 채팅, 게시된 앱 모두에서 작동합니다.
Google Cloud API를 연결하면 앱에서 다음 작업을 할 수 있습니다.
- 프로젝트, 폴더, 조직 목록 조회 및 Cloud Asset Inventory로 그 안의 리소스 검색
- 대시보드와 리포트에 쓸 Cloud Monitoring 지표와 Cloud Logging 항목 읽기
- Compute Engine 인스턴스, Cloud Run 서비스, Cloud Storage 버킷 목록 조회
- Cloud Billing에서 결제 계정, 프로젝트 결제 설정, 서비스 요금 읽기
- 프로젝트의 Identity and Access Management(IAM) 정책 점검
- 요청할 경우 service account에 부여된 역할 범위 안에서 리소스 생성·변경·삭제
이 커넥터는 Lovable로 만드는 앱을 위한 것입니다. 앱을 Google Cloud 프로젝트와 통합해 줍니다. Lovable 앱 자체를 Google Cloud에 배포하거나 호스팅하지는 않습니다. Lovable 앱을 게시하려면 Lovable의 게시 흐름을 사용하세요.
Cloud Billing 내보내기 데이터로 비용과 지출을 분석하는 등 BigQuery 데이터에 SQL 분석이 필요하다면 BigQuery 커넥터를 사용하세요. 같은 Workload Identity Federation 설정을 지원합니다. Google Cloud API는 결제 계정과 요금을 읽을 뿐 지출액은 읽지 않습니다.
주요 활용 사례 및 예시 앱
다음 예시는 Google Cloud API로 만들 수 있는 기능을 보여주며, 각 항목에는 시작점으로 쓸 프롬프트가 함께 있습니다.
| 예시 앱 | 예시 프롬프트 | 설명 |
|---|---|---|
| 프로젝트 인벤토리 | Google Cloud API를 사용해 우리 조직의 모든 Google Cloud 프로젝트를 ID, 상태, 라벨과 함께 나열하는 페이지를 만들어줘. | 모든 프로젝트를 한곳에서 봅니다. 앱이 Resource Manager로 프로젝트를 나열하고 검색 가능한 표로 렌더링합니다. |
| 리소스 인벤토리 | Google Cloud API를 사용해 선택한 프로젝트의 리소스 인벤토리를 서비스별로 묶어 위치와 라벨과 함께 만들어줘. | 프로젝트에서 무엇이 돌아가는지 한눈에 파악합니다. 앱이 Cloud Asset Inventory로 프로젝트를 검색하고 결과를 서비스별로 묶습니다. |
| 모니터링 대시보드 | Google Cloud API를 사용해 선택한 프로젝트의 Compute Engine 인스턴스 CPU 사용률을 지난 24시간 동안 차트로 보여주는 대시보드를 만들어줘. | Cloud Monitoring 지표를 팀이 검토하는 차트로 바꿉니다. 앱이 Cloud Monitoring에서 시계열을 읽어 인스턴스별로 그립니다. |
| 로그 뷰어 | Google Cloud API를 사용해 선택한 프로젝트의 최신 error 레벨 로그 항목을 텍스트 필터와 함께 보여주는 내부 페이지를 만들어줘. | 콘솔을 열지 않고 로그를 읽습니다. 앱이 Cloud Logging에서 심각도 필터로 항목을 나열하고 최신 항목부터 보여줍니다. |
| Cloud Run 개요 | Google Cloud API를 사용해 선택한 리전의 Cloud Run 서비스를 최신 revision과 URL과 함께 나열하는 페이지를 만들어줘. | 리전에 걸친 서비스를 추적합니다. 앱이 선택한 위치의 Cloud Run 서비스를 나열하고 각 서비스의 현재 revision을 보여줍니다. |
| 접근 권한 검토 | Google Cloud API를 사용해 우리 운영 프로젝트마다 Owner 또는 Editor 역할을 가진 사용자를 정리한 리포트를 만들어줘. | 광범위한 접근 권한이 문제가 되기 전에 감사합니다. 앱이 Resource Manager로 각 프로젝트의 IAM 정책을 읽어 광범위한 역할을 가진 principal을 표시합니다. |
Google Cloud API 연결 방식
이 커넥터는 Workload Identity Federation으로 인증합니다. 외부 시스템이 키 없이 service account로 동작하게 해 주는 Google의 방식입니다. Google Cloud가 워크스페이스별 audience의 identity token을 신뢰하도록 구성하되 Lovable 커넥터 게이트웨이의 service account로 제한하면, Lovable이 지정한 service account를 impersonate 합니다. 각 연결은 workload identity provider 하나와 service account 하나를 사용하며, 워크스페이스의 여러 프로젝트가 이를 공유할 수 있습니다. service account 키는 만들어지지 않고 Lovable은 Google 시크릿을 저장하지 않습니다. 연결은 provider의 리소스 이름과 service account의 이메일 주소로만 구성됩니다.
Lovable 커넥터 게이트웨이는 Google의 Security Token Service를 통해 자신의 identity token을 해당 service account의 짧은 수명 액세스 토큰으로 교환하고, 백그라운드에서 갱신하며, 앱이 지정한 Google Cloud API로 각 요청을 전달합니다. 토큰은 서버에 머물고 게시된 앱에 노출되지 않습니다.
커넥터는 연결이 어떤 Google Cloud 서비스나 작업에 접근할 수 있는지 제한하지 않으며 읽기와 쓰기를 구분하지도 않습니다. 통제 수단은 service account에 부여된 IAM 역할입니다. service account가 할 수 있는 일은 그 연결로 만든 앱도 모두 할 수 있습니다. 앱에 필요한 범위를 덮는 가장 좁은 역할을 가장 좁은 범위(프로젝트, 폴더, 조직)에 부여하고, 가능하면 읽기 전용으로 두세요.
한 가지 예외가 있습니다. 다섯 개의 Google Cloud 서비스는 자격 증명이나 시크릿 값을 반환하며, 앱이 이 서비스에 아예 접근할 수 있는지는 연결의 Scopes 설정이 결정합니다.
| 서비스 | 반환하는 것 |
|---|---|
IAM Credentials (iamcredentials) | service account용 짧은 수명 액세스 토큰과 서명 |
IAM (iam) | service account, 역할, 다운로드 가능한 service account 키 |
Secret Manager (secretmanager) | 저장된 시크릿 값 |
Cloud KMS (cloudkms) | 사용자 키로 복호화한 데이터와 생성한 서명 |
Parameter Manager (parametermanager) | Secret Manager 값이 치환된 매개변수 |
연결을 만들 때 다섯 개 모두 선택됩니다. 특정 서비스를 차단하려면 선택을 해제하세요. 그러면 게이트웨이가 리전 엔드포인트를 포함해 해당 서비스에 대한 모든 요청을 거부하고, 오류 유형이 sensitive_service_not_enabled인 403을 반환합니다. Lovable은 재시도하는 대신 어느 서비스를 활성화해야 하는지 알려 줍니다. 선택한 상태로 둔 서비스에도 IAM은 그대로 적용되므로, 서비스를 선택했다는 사실만으로는 어떤 권한도 부여되지 않습니다.
연결은 federation을 검증하지만 접근 권한은 검증하지 않습니다. Lovable은 Google이 자신의 identity를 해당 service account의 토큰으로 교환해 주는지만 확인합니다. 따라서 역할이 부여되고 API가 활성화되기 전까지는 연결이 검증을 통과하고도 403 응답을 받을 수 있습니다. 문제 해결을 참고하세요.
프로젝트 채팅에서 이 연결로 빌드할 때 Lovable은 다음과 같이 동작합니다.
- Lovable은 기본적으로 읽기 전용 기능을 만들고, 리소스나 IAM 바인딩을 생성·변경·삭제하는 호출은 이름을 들어 명시적으로 요청할 때만 추가합니다.
- 프로젝트를 변경하는 호출의 코드를 생성하기 전에, Lovable은 정확한 프로젝트와 리소스, 변경 내용을 알려 주고 확인을 요청합니다. 삭제, 역할 변경, 비용이 발생하는 호출, 자격 증명을 만들거나 반환하는 호출이라면 Lovable은 그 변경이 무엇에 영향을 주는지와 되돌릴 수 있는지까지 설명하고 한 번 더 확인을 요청합니다.
- Lovable은 리소스 생성을 반복 루프나 스케줄, 사용자별 트리거가 아니라 사용자가 확인하는 단일 동작으로 만듭니다.
- Lovable은 모든 호출을 서버 측에 두며, Google 액세스 토큰이나 커넥터의 자격 증명을 프런트엔드 코드나 채팅에 넣지 않습니다. 호출이 반환하는 시크릿 값, 키, 토큰도 서버에 머뭅니다.
- Lovable은 다운로드 가능한 service account 키 생성을 거부하고 대신 Workload Identity Federation을 권합니다.
- Google이 호출을 거부하면 Lovable은 재시도하는 대신 빠진 역할이나 활성화해야 하는 API를 알려 줍니다.
이 규칙은 Lovable이 앱을 위해 작성하는 코드에 적용됩니다. Lovable이 프로젝트 채팅에서 연결을 직접 사용해 변경을 수행할 때는 먼저 승인 카드에서 멈춥니다. Agent approval for this connection 설정은 본인과 해당 연결에만 적용되며 Lovable이 계속 확인을 요청할지 결정합니다. 프로젝트 채팅에서 커넥터 동작 승인하기를 참고하세요.
Google Cloud API 연결 방법
Google Cloud API 연결을 만들 수 있는 사용자는 플랜과 워크스페이스 설정에 따라 달라집니다. 앱 + 채팅 커넥터는 Free, Pro, Business 플랜에서 기본적으로 사용할 수 있습니다. Enterprise 플랜에서는 처음에 사실상 비활성화되어 있습니다. admin이 Connectors → Admin settings → App + chat connectors에서 변경하기 전까지 연결 및 클라이언트를 만들 수 있는 사용자가 No one으로 설정됩니다.
서로 다른 service account로 여러 Google Cloud API 연결을 만들 수 있습니다. 조직, 프로젝트, 환경(예: development와 production)을 분리할 때 유용합니다.
연결을 만든 후 사용할 프로젝트에 연결을 연결할 수 있습니다. 프로젝트에서 빌드하는 사용자는 누구나 프로젝트 채팅에서 Lovable에 프로젝트를 연결해 달라고 요청할 수 있습니다.
사전 준비
Google Cloud API를 연결하기 전에 다음을 준비하세요.
-
workload identity pool과 service account를 담을 Google Cloud 프로젝트. 이후 service account에 이 프로젝트나 다른 프로젝트, 또는 폴더와 조직에 대한 역할을 부여할 수 있습니다.
-
연결 양식의 Configure connection에 표시되는 Lovable 워크스페이스 ID
-
Lovable 워크스페이스에서 연결 만들기 권한(연결 및 클라이언트를 만들 수 있는 사용자 참고)
-
Google Cloud 프로젝트에 대한 다음 역할들.
roles/owner가 이 모두를 포함합니다.역할 필요한 이유 roles/serviceusage.serviceUsageAdminIAM, Security Token Service, IAM Credentials, Cloud Resource Manager API 활성화 roles/iam.workloadIdentityPoolAdminWorkload identity pool과 OpenID Connect provider 생성 roles/iam.serviceAccountAdminservice account 생성 및 impersonation 권한 부여 roles/resourcemanager.projectIamAdmin프로젝트에서 service account에 역할 부여
API 동작은 클라우드 리소스를 만들거나 변경할 수 있고 비용을 발생시킬 수 있으며, 그 책임은 전적으로 사용자에게 있습니다. 앱이 사용하거나 생성하는 모든 것에 대해 Lovable이 아니라 Google이 Cloud Billing 계정에 직접 청구합니다. 연결하기 전에 알림이 설정된 Cloud Billing 예산을 만들고, Lovable이 만든 결과를 확인하며, 정리와 해체가 제대로 끝났는지 확인하세요.
1단계: Google Cloud에서 Workload Identity Federation 구성하기
해당 워크스페이스에 대해 Lovable 커넥터 게이트웨이가 보내는 Google 발급 ID 토큰을 신뢰하는 workload identity pool과 OpenID Connect(OIDC) provider, Lovable이 impersonate 할 service account, 그리고 앱이 무엇을 할 수 있는지 결정하는 IAM 역할이 필요합니다.
이 설정은 Google Cloud Shell Editor에서 설정 스크립트를 직접 실행하거나, Google Cloud 콘솔에서 수동 단계로 완료할 수 있습니다(Google Cloud 콘솔에서 수동으로 설정하기 참고).
기반이 되는 Google Cloud 기능의 배경지식은 Workload Identity Federation과 Workload Identity Federation 사용 모범 사례를 참고하세요.
Google Cloud 콘솔을 열고 Cloud Shell Editor 검색하기
Google Cloud 콘솔에서 Cloud Shell Editor를 검색해 엽니다.
Cloud Shell이 자격 증명을 사용하도록 승인하기
메시지가 표시되면 Cloud Shell이 Google 자격 증명을 사용하도록 승인합니다.
올바른 프로젝트 선택하기
Cloud Shell 세션에서 올바른 Google Cloud 프로젝트가 선택되어 있는지 확인합니다.
새 파일 만들고 스크립트 복사한 뒤 변수 설정하기
새 파일(예: setup.sh)을 만들고 아래 스크립트를 붙여넣은 뒤 맨 위 값을 채웁니다. 워크스페이스 ID는 Lovable 연결 양식의 Configure connection에 표시됩니다.
#!/usr/bin/env bash
set -euo pipefail
# ---- FILL THESE IN ----
GCP_PROJECT="YOUR_GCP_PROJECT_ID"
WORKSPACE_ID="YOUR_WORKSPACE_ID"
# Roles granted to the service account on GCP_PROJECT. roles/viewer covers
# read-only inventory, monitoring, and logging. Add service-specific roles
# only for the changes your app makes. Leave the list empty to grant roles
# yourself in the console, for example on a folder or organization.
ROLES=("roles/viewer")
# ---- Defaults ----
POOL_ID="lovable"
PROVIDER_ID="lovable-gateway"
SA_NAME="lovable-gcp"
LOCATION="global"
GATEWAY_SA_EMAIL="connector-gateway@lovable-core-prod.iam.gserviceaccount.com"
# ---- Validate placeholders ----
for VAR in GCP_PROJECT WORKSPACE_ID; do
if [[ -z "${!VAR}" || "${!VAR}" == YOUR_* ]]; then
echo "ERROR: set ${VAR} at the top of this script" >&2
exit 1
fi
done
# ---- Derived ----
SA_EMAIL="${SA_NAME}@${GCP_PROJECT}.iam.gserviceaccount.com"
SUBJECT_TOKEN_AUDIENCE="https://connector-gateway.lovable.dev/workspaces/${WORKSPACE_ID}"
# Enable APIs first. Cloud Resource Manager is not enabled by default on
# a new project, and the gcloud projects commands below depend on it.
gcloud services enable \
iam.googleapis.com sts.googleapis.com \
iamcredentials.googleapis.com cloudresourcemanager.googleapis.com \
--project="${GCP_PROJECT}"
PROJECT_NUMBER=$(gcloud projects describe "${GCP_PROJECT}" --format="value(projectNumber)")
POOL_RESOURCE="projects/${PROJECT_NUMBER}/locations/${LOCATION}/workloadIdentityPools/${POOL_ID}"
# Create the workload identity pool
if ! gcloud iam workload-identity-pools describe "${POOL_ID}" \
--location="${LOCATION}" --project="${GCP_PROJECT}" &>/dev/null; then
gcloud iam workload-identity-pools create "${POOL_ID}" \
--location="${LOCATION}" \
--project="${GCP_PROJECT}" \
--display-name="Lovable WIF Pool"
fi
# Create the OIDC provider, restricted to Lovable's connector gateway.
# An existing provider that already matches is left alone. One with
# different settings is only overwritten after you confirm, because the
# binding below trusts every identity this pool admits.
EXPECTED_CONDITION="assertion.email == '${GATEWAY_SA_EMAIL}'"
if gcloud iam workload-identity-pools providers describe "${PROVIDER_ID}" \
--location="${LOCATION}" \
--workload-identity-pool="${POOL_ID}" \
--project="${GCP_PROJECT}" &>/dev/null; then
CURRENT_CONDITION=$(gcloud iam workload-identity-pools providers describe "${PROVIDER_ID}" \
--location="${LOCATION}" \
--workload-identity-pool="${POOL_ID}" \
--project="${GCP_PROJECT}" \
--format="value(attributeCondition)")
CURRENT_AUDIENCE=$(gcloud iam workload-identity-pools providers describe "${PROVIDER_ID}" \
--location="${LOCATION}" \
--workload-identity-pool="${POOL_ID}" \
--project="${GCP_PROJECT}" \
--format="value(oidc.allowedAudiences)")
# The impersonation binding below matches on attribute.email, so the
# provider has to map it.
CURRENT_EMAIL_MAPPING=$(gcloud iam workload-identity-pools providers describe "${PROVIDER_ID}" \
--location="${LOCATION}" \
--workload-identity-pool="${POOL_ID}" \
--project="${GCP_PROJECT}" \
--format="value(attributeMapping['attribute.email'])")
if [[ "${CURRENT_CONDITION}" == "${EXPECTED_CONDITION}" \
&& "${CURRENT_AUDIENCE}" == "${SUBJECT_TOKEN_AUDIENCE}" \
&& "${CURRENT_EMAIL_MAPPING}" == "assertion.email" ]]; then
echo "Provider '${PROVIDER_ID}' already matches this workspace."
else
echo ""
echo "Provider '${PROVIDER_ID}' already exists with different settings:"
echo " audience now: ${CURRENT_AUDIENCE:-(none)}"
echo " new: ${SUBJECT_TOKEN_AUDIENCE}"
echo " condition now: ${CURRENT_CONDITION:-(none)}"
echo " new: ${EXPECTED_CONDITION}"
echo " attribute.email now: ${CURRENT_EMAIL_MAPPING:-(unmapped)}"
echo " new: assertion.email"
echo ""
echo "Overwriting replaces these values. Any other audience on this provider is dropped."
CONFIRM=""
read -r -p "Overwrite it? (y/N) " CONFIRM < /dev/tty || CONFIRM="n"
case "${CONFIRM}" in
[Yy]|[Yy][Ee][Ss]) ;;
*) echo "Aborted."; exit 1 ;;
esac
gcloud iam workload-identity-pools providers update-oidc "${PROVIDER_ID}" \
--location="${LOCATION}" \
--workload-identity-pool="${POOL_ID}" \
--project="${GCP_PROJECT}" \
--issuer-uri="https://accounts.google.com" \
--allowed-audiences="${SUBJECT_TOKEN_AUDIENCE}" \
--attribute-mapping="google.subject=assertion.sub,attribute.email=assertion.email" \
--attribute-condition="${EXPECTED_CONDITION}"
fi
else
gcloud iam workload-identity-pools providers create-oidc "${PROVIDER_ID}" \
--location="${LOCATION}" \
--workload-identity-pool="${POOL_ID}" \
--project="${GCP_PROJECT}" \
--issuer-uri="https://accounts.google.com" \
--allowed-audiences="${SUBJECT_TOKEN_AUDIENCE}" \
--attribute-mapping="google.subject=assertion.sub,attribute.email=assertion.email" \
--attribute-condition="assertion.email == '${GATEWAY_SA_EMAIL}'"
fi
# Create the service account Lovable impersonates
if ! gcloud iam service-accounts describe "${SA_EMAIL}" \
--project="${GCP_PROJECT}" &>/dev/null; then
gcloud iam service-accounts create "${SA_NAME}" \
--project="${GCP_PROJECT}" \
--display-name="Lovable Google Cloud API"
fi
# Wait for the service account to become visible to IAM. Reads are
# eventually consistent, so a new service account can take 60s or more
# to appear.
PROPAGATION_TIMEOUT=120
echo "Waiting up to ${PROPAGATION_TIMEOUT}s for service account to propagate..."
PROPAGATION_DEADLINE=$((SECONDS + PROPAGATION_TIMEOUT))
until gcloud iam service-accounts describe "${SA_EMAIL}" \
--project="${GCP_PROJECT}" &>/dev/null; do
if (( SECONDS >= PROPAGATION_DEADLINE )); then
echo "ERROR: ${SA_EMAIL} did not become available after ${PROPAGATION_TIMEOUT}s" >&2
exit 1
fi
sleep 2
done
# ---- Confirm before granting roles ----
if (( ${#ROLES[@]} > 0 )); then
echo ""
echo "Service account ${SA_EMAIL} will be granted on project ${GCP_PROJECT}:"
for ROLE in "${ROLES[@]}"; do
echo " ${ROLE}"
done
echo ""
REPLY=""
read -r -p "Continue? (Y/n) " REPLY < /dev/tty || REPLY="n"
case "${REPLY}" in
""|[Yy]|[Yy][Ee][Ss]) ;;
*) echo "Aborted."; exit 1 ;;
esac
for ROLE in "${ROLES[@]}"; do
gcloud projects add-iam-policy-binding "${GCP_PROJECT}" \
--member="serviceAccount:${SA_EMAIL}" \
--role="${ROLE}" --condition=None --quiet
done
fi
# Allow the pool to impersonate the service account
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
--project="${GCP_PROJECT}" \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/${POOL_RESOURCE}/attribute.email/${GATEWAY_SA_EMAIL}" \
--condition=None --quiet
AUDIENCE="//iam.googleapis.com/${POOL_RESOURCE}/providers/${PROVIDER_ID}"
echo ""
echo "=== Paste these into the Google Cloud API connector in Lovable ==="
echo ""
echo " WIF Audience: ${AUDIENCE}"
echo " Service Account Email: ${SA_EMAIL}"
echo ""
echo "NOTE: IAM bindings can take up to 5 minutes to propagate."
echo "NOTE: Enable the APIs your app calls under APIs & Services in the console."터미널을 열고 스크립트 실행하기
Cloud Shell 터미널에서 bash setup.sh를 실행합니다.
스크립트는 2단계에서 필요한 WIF audience와 Service account email을 출력합니다.
스크립트는 선택한 프로젝트에 ROLES의 역할을 부여하며 기본값은 Viewer(roles/viewer)입니다. 다른 프로젝트나 폴더, 조직에 역할을 부여하려면, 또는 결제 계정에 Billing Account Viewer(roles/billing.viewer)를 부여하려면 콘솔에서 해당 리소스를 선택한 상태로 IAM & Admin → IAM을 사용하세요. Owner와 Editor는 피하고 IAM을 관리하는 역할도 피하세요. 역할을 부여할 수 있는 service account는 스스로에게 더 많은 권한을 부여할 수 있기 때문입니다.
또한 앱이 호출하는 API를 각각 활성화하세요. 예를 들어 Cloud Asset, Cloud Monitoring, Cloud Logging API를 service account가 속한 프로젝트의 APIs & Services → Enabled APIs & services에서 활성화합니다. 앱이 다른 프로젝트를 읽거나 관리할 때는 Google이 그 프로젝트에서도 API 활성화를 요구할 수 있습니다. 활성화되지 않은 API로 보낸 요청은 service account가 어떤 역할을 갖고 있든 403과 SERVICE_DISABLED 사유로 실패하며, 오류 메시지가 수정해야 할 프로젝트를 알려 줍니다.
2단계: Lovable에서 Google Cloud API 연결하기
federation을 설정하고 역할을 부여했다면 Lovable에서 연결을 만듭니다.
Connectors에서 Google Cloud API 열기
Connectors를 열고 Google Cloud API를 선택합니다. 카탈로그를 열 수 있는 다른 위치는 커넥터를 찾을 수 있는 곳을 참고하세요. 커넥터 페이지에는 API 동작의 비용과 리소스 영향에 관한 Use responsibly 안내가 표시됩니다.
연결 추가하기
Add connection을 클릭하고 App + chat connector를 선택합니다. 양식은 Details, Configure connection, Sharing 세 개의 접을 수 있는 섹션으로 나뉩니다.
연결 이름 지정하기
Details에서 Lovable이 연결 이름을 채워 주며 직접 바꿀 수 있습니다. 이 이름은 Lovable 안에서 연결을 식별할 때만 사용됩니다.
연결 구성하기
Configure connection에는 1단계에서 사용하는 값이 담긴 Workspace ID 복사 필드가 표시됩니다. 그 아래에 다음을 입력합니다.
- WIF audience: Google Cloud의 Workload Identity Provider 리소스 이름을 붙여넣습니다(
//iam.googleapis.com/projects/.../providers/...형태의 전체 문자열). 이 문자열에는 프로젝트 ID가 아니라 프로젝트 번호가 들어가며, Lovable은 다른 형식을 거부합니다. - Service account email: Google Cloud 접근을 위해 impersonate 할 service account를 입력합니다(예:
lovable-gcp@your-project.iam.gserviceaccount.com). - Scopes: Google Cloud API 연결 방식에서 설명한, 자격 증명과 시크릿을 반환하는 다섯 개 서비스이며 모두 기본으로 선택되어 있습니다. 이 연결로 만든 앱이 접근해서는 안 되는 서비스는 선택을 해제하세요. 선택은 나중에 변경할 수 있습니다.
이 연결을 사용할 사용자 선택하기
Sharing에서 연결은 기본적으로 본인만 사용할 수 있으며 Private 라벨이 표시됩니다. 공유하려면 Share with others를 클릭합니다. 그다음 이메일로 워크스페이스 멤버를 추가하거나, Invite entire workspace를 클릭해 Lovable 워크스페이스의 모든 사용자가 연결을 사용할 수 있게 합니다.
연결을 공유받은 사용자는 누구나 service account의 모든 접근 권한을 사용하는 기능을 만들 수 있습니다.
자세한 내용은 연결 및 클라이언트를 사용할 수 있는 사용자를 참고하세요.
연결하기
Connect를 클릭합니다. Lovable은 연결을 저장하기 전에 게이트웨이를 통해 federation 설정을 검증합니다. Google에 Lovable의 identity를 해당 service account의 짧은 수명 토큰으로 교환해 달라고 요청하는 방식입니다. 이 검사는 provider가 해당 워크스페이스에 대해 Lovable을 신뢰하는지와 service account가 impersonation을 허용하는지만 확인하며, 역할이나 API 활성화 여부는 확인하지 않습니다. 검증이 실패하면 문제 해결을 참고하세요.
연결되면 프로젝트에서 빌드하는 사용자는 누구나 구성된 연결 수준 접근 권한에 따라 프로젝트 채팅에서 Lovable에 프로젝트를 Google Cloud API에 연결해 달라고 요청할 수 있습니다. 이후 Lovable 앱은 service account에 부여된 역할 범위 안에서 커넥터 게이트웨이를 통해 Google Cloud API를 호출할 수 있습니다.
제한 사항
Google Cloud API 커넥터는 다음을 하지 못합니다.
- Scopes에서 자격 증명과 시크릿을 반환하는 다섯 개 서비스를 차단하는 것 말고는, Lovable 내부에서 연결을 읽기 전용 작업이나 특정 Google Cloud 서비스로 제한하지 못합니다. 연결로 만든 앱이 무엇을 할 수 있는지에 대한 다른 통제 수단은 IAM 역할뿐입니다.
- service account 키 파일, 사용자의 Google 로그인, API 키로는 인증하지 못합니다. 이 연결에는 Workload Identity Federation이 필요합니다.
- Gmail, Drive, Sheets 같은 Google Workspace API를 호출하지 못합니다. 토큰에는 Google Cloud 스코프만 담깁니다. 이런 데이터에는 Google Workspace 커넥터를 사용하세요.
- 직접 운영하는 Cloud Run 서비스, Cloud Functions, App Engine 앱을 각자의 URL로 호출하지 못합니다. 이 연결은 Google Cloud의
googleapis.comAPI에만 접근하므로, Cloud Run 서비스를 관리할 수는 있지만 그 서비스에 요청을 보낼 수는 없습니다. - Pub/Sub push 전달이나 Eventarc 이벤트처럼 Google Cloud가 보내는 이벤트를 수신하지 못합니다. 이 연결은 바깥으로 나가는 호출만 수행합니다.
- 최종 사용자별 Google 로그인을 지원하지 못합니다. 각 연결은 연결된 모든 프로젝트가 공유하는 하나의 service account를 나타냅니다.
service account를 삭제하거나 Workload Identity User 바인딩을 제거하거나 풀 또는 provider를 삭제하면, 복원하기 전까지 요청이 실패합니다. 연결을 다른 provider나 service account로 바꾸려면 연결을 열어 Configure connection의 값을 변경한 뒤 Update를 클릭하세요. Lovable이 저장하기 전에 federation을 다시 검증합니다.
문제 해결
연결이 실패하거나 Google Cloud 요청이 예상치 못한 상태 코드를 반환할 때 다음을 확인하세요.
Google Cloud API 연결 관리
연결은 Connectors에서 관리합니다. **Google Cloud API**를 선택한 다음 연결을 여세요.
- Unlink projects를 사용하면 다른 프로젝트에서 연결을 계속 사용할 수 있도록 유지하면서 특정 프로젝트의 Google Cloud API 접근 권한만 제거할 수 있습니다. 단계별 절차는 연결에서 프로젝트 연결 해제를 참고하세요.
- Delete the connection을 사용하면 워크스페이스에서 연결을 완전히 제거할 수 있습니다. 삭제는 영구적이며 연결된 모든 프로젝트에서 자격 증명이 제거되고, Google Cloud API을 사용하는 앱 기능은 새 연결을 추가할 때까지 작동하지 않습니다. 단계와 삭제 권한은 연결 삭제를 참고하세요.