Lovable한국어 문서

Google 로그인(OAuth) 또는 Workload Identity Federation으로 BigQuery를 연결해 장기 GCP 키 없이 SQL과 분석 기능을 사용합니다.

BigQuery에 앱 연결하기

Google 로그인(OAuth) 또는 Workload Identity Federation을 사용해 Google BigQuery를 Lovable 앱에 연결합니다. 프로젝트에 장기 유효 GCP 키를 저장하지 않고도 SQL을 실행하고, 데이터셋과 스키마를 탐색하며, 분석 기능을 구축할 수 있습니다.

Google BigQuery는 대규모 분석을 위한 서버리스 데이터 웨어하우스입니다. BigQuery 앱 + 채팅 커넥터를 사용하면 Lovable 앱이 Lovable의 보안 게이트웨이를 통해 BigQuery API를 호출할 수 있습니다. Google 계정으로 로그인하거나 **Workload Identity Federation(WIF)**으로 연결할 수 있으므로, 장기 유효 service account 키를 Lovable에 붙여넣을 일이 없습니다.

BigQuery는 앱 + 채팅 커넥터로 제공됩니다. 하나의 공유 연결이 빌드 중 채팅과 게시된 앱 모두에서 작동합니다.

BigQuery를 연결하면 앱에서 다음 작업을 할 수 있습니다.

  • 표준 SQL을 사용해 데이터셋과 테이블 쿼리
  • 스키마 메타데이터 탐색(프로젝트, 데이터셋, 테이블, 컬럼)
  • 비용 가드레일을 염두에 둔 매개변수화 쿼리 실행
  • materialized view 읽기

데이터가 이미 GCP에 있거나, SQL로 뒷받침되는 웨어하우스 규모의 분석, 리포팅, 대시보드가 필요할 때 BigQuery가 잘 맞습니다.

주요 활용 사례 및 예시 앱

예시 앱프롬프트 예시설명
경영진 지표 대시보드BigQuery marts 테이블에서 주간 매출과 가입자 수를 보여주고 지역별 필터가 있는 대시보드를 만들어줘.웨어하우스 테이블을 앱 내 차트로 변환합니다.
앱이 BigQuery에 SQL을 실행해 이해관계자에게 KPI와 추세를 보여줍니다.
내부 리포팅 도구팀이 analytics 데이터셋에 대해 승인된 SQL 리포트를 실행하고 CSV로 내보낼 수 있는 내부 앱을 만들어줘.큐레이션된 데이터셋에 대한 셀프 서비스 리포팅.
앱이 매개변수화 쿼리를 제출하고, 사용자에게 GCP 콘솔 직접 접근 권한을 주지 않은 채 결과 집합을 반환합니다.
데이터셋 탐색기접근 가능한 데이터셋과 테이블을 나열하고 컬럼 타입과 행 수를 보여주는 도구를 만들어줘.웨어하우스 내용을 탐색합니다.
앱이 메타데이터 API와 가벼운 쿼리를 사용해 테이블과 스키마를 설명합니다.
고객 헬스 뷰BigQuery의 CRM 내보내기 데이터와 제품 사용 데이터를 조인해 계정별 헬스 스코어를 보여줘.모델링된 데이터를 결합해 운영 워크플로우에 활용합니다.
앱이 데이터 팀이 BigQuery에서 유지 관리하는 사전 조인된 큐레이션 테이블을 쿼리합니다.
스케줄 인사이트 페이지BigQuery materialized view에서 어제의 퍼널 지표를 보여주는 페이지를 만들어줘.일별 또는 시간별 집계를 표면화합니다.
앱이 파이프라인이 스케줄에 따라 갱신하는 뷰나 요약 테이블에서 데이터를 읽습니다.
데이터 검증 UI파이프라인 실행 후 주요 컬럼의 행 수와 null 검사를 수행하는 작은 앱을 만들어줘.SQL 위에 가벼운 품질 검사를 제공합니다.
앱이 적재 완료 후 기대값을 확인하기 위해 대상 쿼리를 실행합니다.

정확한 동작은 보유한 데이터셋, 연결된 identity의 IAM 권한, Lovable에 무엇을 만들어 달라고 요청하는지에 따라 달라집니다.

BigQuery 연결 방식

  • 인증: 연결은 두 가지 방식 중 하나로 인증합니다.

    • Connect with Google은 Google 계정으로 로그인합니다(OAuth).
    • Workload Identity Federation은 Google의 security token service를 통해 identity token을 짧은 수명의 service account 자격 증명으로 교환합니다.

    두 방식 모두 짧은 수명의 액세스 토큰을 Lovable의 커넥터 게이트웨이를 통해 획득하고 갱신하며, 저장소에 장기 유효 JSON 키를 저장하지 않습니다.

  • 게이트웨이: BigQuery API 요청은 게이트웨이를 통해 프록시됩니다. 토큰 처리와 프로젝트별 요청 한도게이트웨이 기반 커넥터를 참고하세요.

  • Scope: 연결은 https://www.googleapis.com/auth/bigquery scope를 사용합니다. 읽거나 실행할 수 있는 범위는 여전히 Google Cloud의 IAM 및 데이터셋 권한에 따라 달라집니다. Connect with Google은 Google 계정의 권한을, Workload Identity Federation은 service account의 권한을 따릅니다.

  • Identity: Connect with Google을 사용하면 연결은 이를 승인한 Google 계정으로 작동하며, 구성한 Google Cloud 프로젝트에서 쿼리를 실행합니다. Workload Identity Federation을 사용하면 Google Cloud가 워크스페이스별 audience의 identity token을 신뢰하도록 구성하되 Lovable 커넥터 게이트웨이 service account로 제한하며, Lovable이 지정한 service account를 impersonate 합니다.

BigQuery의 쿼리 및 스토리지 비용은 처리된 바이트, slot, 관련 사용량을 기준으로 Google Cloud가 GCP 결제 계정에 청구합니다. Lovable은 BigQuery 사용에 대해 청구하지 않습니다.

BigQuery 연결하기

BigQuery 연결을 만들 수 있는 사용자는 플랜과 워크스페이스 설정에 따라 달라집니다. 연결 및 클라이언트를 만들 수 있는 사용자를 참고하세요.

연결을 만들면 다른 앱 + 채팅 커넥터처럼 프로젝트에 연결할 수 있어, 허용된 곳에서 게시된 앱이 이를 사용할 수 있습니다.

연결 방식 선택

  • Connect with Google은 가장 빠른 연결 방법입니다. Google 계정으로 로그인하고 쿼리를 실행하고 비용을 부담할 Google Cloud 프로젝트를 선택합니다. 연결은 해당 Google 계정에 묶이므로 개인, 프로토타입, 그리고 이미 개인 Google 계정으로 작업하는 팀에 적합합니다. 해당 계정이 접근 권한을 잃으면 연결이 작동을 멈춥니다(제한 사항 참고).
  • Workload Identity Federation은 프로덕션 및 조직에서 관리하는 데이터 접근에 적합합니다. 연결이 특정 개인 계정에 묶이지 않습니다. 자체 Google Cloud IAM을 통해 service account에 접근 권한을 부여하고, 접근을 감사할 수 있으며, 장기 유효 키가 관여하지 않습니다. 팀원이 떠나도 연결이 계속 작동합니다.

BigQuery를 어떻게 연결할지에 따라 아래 설정 단계를 따르세요.

Google 계정으로 로그인하고 직접 선택한 Google Cloud 프로젝트에서 쿼리를 실행합니다. Workload Identity Federation 설정은 필요하지 않습니다.

사전 준비

BigQuery를 연결하기 전에 다음을 준비하세요.

  • 쿼리하려는 BigQuery 데이터셋에 접근할 수 있는 Google 계정
  • 쿼리를 실행할 Google Cloud 프로젝트에 대한 BigQuery Job User 역할(roles/bigquery.jobUser)
  • Lovable 워크스페이스에서 연결을 만들 수 있는 권한(연결 및 클라이언트를 만들 수 있는 사용자 참고)

Lovable에서 BigQuery 연결하기

Connectors에서 BigQuery 열기

Connectors로 이동해 BigQuery를 선택합니다.

연결 추가하기

Add connection을 클릭합니다.

연결 이름 지정하기

Display name에 명확한 이름을 입력합니다(예: BigQuery Analytics).

Connect with Google 선택하기

Connect with Google을 선택합니다. 양식이 제공하는 두 가지 옵션 중 하나이며, 다른 하나는 Use your own credentials입니다.

Google Cloud 프로젝트 ID 입력하기

Google Cloud project ID에 쿼리를 실행하고 비용을 부담할 프로젝트를 입력합니다. 연결된 Google 계정에는 이 프로젝트에 대한 BigQuery Job User 역할이 필요합니다.

쿼리를 실행하는 프로젝트는 데이터를 저장하는 프로젝트와 다를 수 있습니다. 다른 프로젝트에 저장된 데이터를 읽으려면, 이 필드에는 쿼리를 실행하는 프로젝트를 그대로 두고 쿼리에서 테이블 이름을 완전히 정규화하세요(예: data-project.dataset.table).

이 연결을 사용할 사용자 선택하기

Who can use this connection에서 워크스페이스 내 연결 사용자를 결정합니다. 처음에는 본인만 접근할 수 있습니다.

  • Only you(기본값): 접근 목록을 그대로 두면 본인만 연결과 관련 데이터를 사용할 수 있습니다.
  • Invite specific people: 이메일로 워크스페이스 멤버를 추가하면 본인과 추가한 사용자만 연결과 관련 데이터를 사용할 수 있습니다.
  • Invite entire workspace: Invite entire workspace를 클릭하면 Lovable 워크스페이스의 모든 사용자가 연결을 사용할 수 있습니다.

자세한 내용은 연결 및 클라이언트를 사용할 수 있는 사용자를 참고하세요.

연결하고 승인하기

Connect를 클릭합니다. Google 로그인 창이 열리므로 브라우저가 팝업을 차단하지 않는지 확인하세요. 로그인한 뒤 요청된 접근을 승인합니다.

이 플로우는 다음 scope를 요청합니다. View and manage your data in Google BigQuery and see the email address for your Google Account입니다. 이 scope는 부여가 아니라 상한선입니다. 연결이 실제로 할 수 있는 작업은 로그인한 계정의 IAM 역할에 따라 결정됩니다. 만들려는 것에 맞춰 역할을 부여하세요.

  • 읽기 전용 앱(대시보드, 리포팅, 데이터 탐색기): 데이터셋에 BigQuery Data Viewer를, 프로젝트에 BigQuery Job User를 부여합니다. scope가 더 많은 권한을 허용하더라도 IAM이 모든 쓰기를 차단하므로 연결은 읽기 전용으로 유지됩니다.
  • 읽기·쓰기 앱(데이터 입력, 라이트백, 테이블 관리): 앱이 변경해야 하는 데이터셋에 BigQuery Data Editor를 추가로 부여합니다.

Lovable이 Google의 읽기 전용 scope(bigquery.readonly) 대신 이 scope를 요청하는 이유는, 읽기 전용 scope가 전체 BigQuery jobs API를 지원하지 않기 때문입니다.

자체 Google Cloud IAM을 통해 service account에 접근 권한을 부여합니다. 연결이 특정 개인 계정에 묶이지 않으며 장기 유효 키를 사용하지 않습니다. 연결 양식에서 이 옵션은 Use your own credentials로 표시됩니다.

사전 준비

BigQuery를 연결하기 전에 다음을 준비하세요.

  • BigQuery API가 활성화되어 있고 쿼리하려는 데이터셋이 있는 Google Cloud 프로젝트

  • Use your own credentials를 선택하면 연결 양식에 표시되는 Lovable 워크스페이스 ID

  • Lovable 워크스페이스에서 연결을 만들 수 있는 권한(연결 및 클라이언트를 만들 수 있는 사용자 참고)

  • Google Cloud 프로젝트에 대한 다음 역할들. roles/owner가 이 모두를 포함합니다.

    역할필요한 이유
    roles/serviceusage.serviceUsageAdminIAM, STS, IAM Credentials, BigQuery API 활성화
    roles/iam.workloadIdentityPoolAdminWorkload identity pool과 OIDC provider 생성
    roles/iam.serviceAccountAdminservice account 생성 및 impersonation 권한 부여
    roles/resourcemanager.projectIamAdmin프로젝트에 BigQuery Job User 부여
    roles/bigquery.dataOwner노출하는 각 데이터셋에 읽기 권한 부여

1단계: Google Cloud에서 Workload Identity Federation 구성하기

해당 워크스페이스에 대해 Lovable 커넥터 게이트웨이가 보내는 Google 발급 ID 토큰을 신뢰하는 workload identity poolOIDC provider가 필요합니다.

이 설정은 Google Cloud Shell Editor에서 설정 스크립트를 직접 실행하거나, Google Cloud 콘솔에서 수동 단계로 완료할 수 있습니다(Google Cloud 콘솔에서 수동으로 설정하기 참고).

기반이 되는 Google Cloud 기능의 배경지식은 Workload Identity FederationWorkload Identity Federation 사용 모범 사례를 참고하세요.

Google Cloud 콘솔을 열고 Cloud Shell Editor 검색하기

Google Cloud 콘솔에서 Cloud Shell Editor를 검색해 엽니다.

Cloud Shell이 자격 증명을 사용하도록 승인하기

메시지가 표시되면 Cloud Shell이 Google 자격 증명을 사용하도록 승인합니다.

올바른 프로젝트 선택하기

Cloud Shell 세션에서 올바른 Google Cloud 프로젝트가 선택되어 있는지 확인합니다.

새 파일 만들고 스크립트 복사한 뒤 변수 설정하기

새 파일(예: setup.sh)을 만들고 아래 스크립트를 붙여넣은 뒤 맨 위 값을 채웁니다.

#!/usr/bin/env bash
set -euo pipefail

# ---- FILL THESE IN ----
GCP_PROJECT="YOUR_GCP_PROJECT_ID"
WORKSPACE_ID="YOUR_WORKSPACE_ID"
ALLOWED_DATASETS=("DATASET_1" "DATASET_2")

# ---- Defaults ----
POOL_ID="lovable"
PROVIDER_ID="lovable-gateway"
SA_NAME="lovable-bigquery"
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

if [[ ${#ALLOWED_DATASETS[@]} -eq 0 ]]; then
  echo "ERROR: set ALLOWED_DATASETS at the top of this script" >&2
  exit 1
fi

for DS in "${ALLOWED_DATASETS[@]}"; do
  if [[ -z "${DS}" || "${DS}" == DATASET_* ]]; then
    echo "ERROR: replace the placeholder entries in ALLOWED_DATASETS" >&2
    exit 1
  fi
done

if ! command -v python3 &>/dev/null; then
  echo "ERROR: python3 is required to update dataset access" >&2
  exit 1
fi

# ---- Derived ----
SA_EMAIL="${SA_NAME}@${GCP_PROJECT}.iam.gserviceaccount.com"
SUBJECT_TOKEN_AUDIENCE="https://connector-gateway.lovable.dev/workspaces/${WORKSPACE_ID}"

WORK_DIR=$(mktemp -d)
trap 'rm -rf "${WORK_DIR}"' EXIT

# 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 bigquery.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 both 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 BigQuery Reader"
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. Both messages derive from PROPAGATION_TIMEOUT so they
# cannot drift from the time the loop actually spends waiting.
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 data access ----
echo ""
echo "Service account ${SA_EMAIL} will be granted:"
echo "  roles/bigquery.jobUser     on project ${GCP_PROJECT}"
echo "  roles/bigquery.dataViewer  on datasets: ${ALLOWED_DATASETS[*]}"
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

# Allow the service account to run query jobs
gcloud projects add-iam-policy-binding "${GCP_PROJECT}" \
  --member="serviceAccount:${SA_EMAIL}" \
  --role="roles/bigquery.jobUser" --condition=None --quiet

# Grant read access on each dataset. BigQuery has no gcloud command for
# dataset-level IAM, so this updates the dataset access list directly.
for DS in "${ALLOWED_DATASETS[@]}"; do
  echo "Granting read access on ${GCP_PROJECT}:${DS}..."
  DS_JSON="${WORK_DIR}/${DS}.json"

  bq --project_id="${GCP_PROJECT}" show --format=prettyjson \
    "${GCP_PROJECT}:${DS}" > "${DS_JSON}"

  python3 -c '
import json, sys
path, service_account = sys.argv[1], sys.argv[2]
with open(path) as f:
    dataset = json.load(f)
# READER in the access list is the equivalent of roles/bigquery.dataViewer.
access = dataset.setdefault("access", [])
already_granted = any(
    entry.get("userByEmail") == service_account
    and entry.get("role") in ("READER", "roles/bigquery.dataViewer")
    for entry in access
)
if not already_granted:
    access.append({"role": "READER", "userByEmail": service_account})
with open(path, "w") as f:
    json.dump(dataset, f)
' "${DS_JSON}" "${SA_EMAIL}"

  bq --project_id="${GCP_PROJECT}" update --source "${DS_JSON}" "${GCP_PROJECT}:${DS}"
done

# 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 BigQuery 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."

bq update --source는 데이터셋의 기존 접근 제어 목록(ACL)을 병합하지 않고 완전히 대체합니다. 스크립트는 먼저 현재 ACL을 가져와 패치한 뒤 적용하므로 기존 항목이 보존됩니다. 업데이트를 수동으로 실행한다면, 적용하기 전에 원하는 모든 항목이 JSON 파일에 있는지 확인하세요.

터미널을 열고 스크립트 실행하기

Cloud Shell 터미널에서 bash setup.sh를 실행합니다.

스크립트는 2단계에서 필요한 WIF audienceService account email을 출력합니다.

2단계: Lovable에서 BigQuery 연결하기

Connectors에서 BigQuery 열기

Connectors로 이동해 BigQuery를 선택합니다.

연결 추가하기

Add connection을 클릭합니다.

연결 이름 지정하기

Display name에 명확한 이름을 입력합니다(예: BigQuery Production 또는 Analytics reporting).

자체 자격 증명 선택하기

Use your own credentials를 선택합니다. 이것이 Workload Identity Federation 옵션이며, Connect with Google과 함께 제공됩니다.

WIF audience 입력하기

WIF audience에 Google Cloud의 Workload Identity Provider 리소스 이름을 붙여넣습니다(//iam.googleapis.com/projects/.../providers/... 형태의 전체 문자열).

service account 이메일 입력하기

Service account email에 BigQuery 접근을 위해 impersonate 할 service account를 입력합니다(예: bq-reader@your-project.iam.gserviceaccount.com).

이 연결을 사용할 사용자 선택하기

Who can use this connection에서 워크스페이스 내 연결 사용자를 결정합니다. 처음에는 본인만 접근할 수 있습니다. 이메일로 특정 워크스페이스 멤버를 추가하거나, Invite entire workspace를 클릭해 Lovable 워크스페이스의 모든 사용자가 연결을 사용할 수 있도록 합니다.

자세한 내용은 연결 및 클라이언트를 사용할 수 있는 사용자를 참고하세요.

연결 만들기

플로우를 완료해 연결을 생성하거나 검증합니다. Lovable이 게이트웨이를 통해 federation 설정을 검증합니다.

연결되면 프로젝트에서 빌드하는 사용자는 구성된 연결 수준 접근 권한에 따라 채팅에서 Lovable에 프로젝트 연결을 요청할 수 있습니다. 이후 Lovable 앱은 빌드 중과 게시 후에 커넥터를 통해 데이터셋에 SQL 쿼리를 실행할 수 있습니다.

비용과 안전 관행

BigQuery는 쿼리로 스캔된 데이터(및 기타 사용량)에 대해 요금을 청구합니다. 채팅으로 기능을 구현할 때는 다음 패턴을 권장합니다.

  • 쿼리 작업에 maximumBytesBilled(또는 동등한 설정)를 사용해, 한도를 초과할 대규모 스캔이 실행 전에 실패하도록 합니다.
  • 파티션 테이블을 파티션 컬럼으로 필터링하고, 탐색 중에는 SELECT *를 피하며, 반복 작업 중에는 **LIMIT**을 사용합니다.
  • 무거운 스캔 전에 INFORMATION_SCHEMA와 메타데이터 API로 스키마와 파티션을 먼저 확인합니다.

Google 문서의 BigQuery pricing비용 관리 모범 사례를 참고하세요.

제한 사항

  • 연결당 하나의 identity: 앱의 최종 사용자는 자신의 Google 계정으로 로그인하지 않습니다. Connect with Google 연결은 이를 승인한 단일 Google 계정으로 작동하고, Workload Identity Federation 연결은 구성된 service account로 작동합니다.
  • Connect with Google 연결은 해당 Google 계정에 의존합니다: 계정이 프로젝트 접근 권한을 잃거나 Google 측에서 승인이 취소되면(예: 계정의 타사 접근 설정에서), 누군가 Lovable에서 다시 연결하기 전까지 연결이 작동을 멈춥니다.
  • 게이트웨이 한도게이트웨이 기반 커넥터에서 설명한 대로 적용됩니다.
  • IAM 및 데이터셋 접근은 전적으로 GCP 내에서 직접 제어합니다. Lovable은 연결된 계정이나 service account가 읽을 수 없는 테이블에 대한 접근 권한을 부여할 수 없습니다.

BigQuery 연결 관리하기

Connectors에서 연결을 관리합니다. **BigQuery**를 선택한 뒤 연결을 여세요.

  • 특정 프로젝트의 BigQuery 접근만 제거하고 다른 프로젝트에서는 연결을 계속 사용하려면 Unlink projects를 사용합니다. 단계는 연결에서 프로젝트 연결 해제를 참고하세요.
  • 워크스페이스에서 연결을 완전히 제거하려면 Delete the connection을 사용합니다. 삭제는 영구적입니다. 연결된 모든 프로젝트에서 인증 정보가 제거되고, 새 연결을 추가할 때까지 BigQuery을 사용하는 앱 기능이 중단됩니다. 단계와 삭제 권한은 연결 삭제를 참고하세요.

관련 주제

On this page