Lovable한국어 문서

Databricks 웨어하우스 데이터에 SQL을 실행해 라이브 대시보드와 데이터 기반 앱을 구축합니다.

Databricks에 앱 연결하기

Databricks에 앱을 연결하면 웨어하우스 데이터를 쿼리하고, 라이브 대시보드를 만들며, 기존 테이블과 뷰를 기반으로 데이터 기반 도구를 구동할 수 있습니다. service principal로 연결하거나 본인의 Databricks 계정으로 로그인하세요.

Databricks는 Lovable 앱이 웨어하우스 데이터, SQL 쿼리, 클러스터 리소스를 다룰 수 있게 해주는 데이터 인텔리전스 플랫폼입니다. Databricks 커넥터를 사용하면 CSV를 내보내거나 엔지니어링 티켓을 기다리지 않고 기존 Databricks 데이터 위에 앱과 대시보드를 구축할 수 있습니다.

커넥터이럴 때 사용
App + chat connector (이 페이지)채팅과 게시된 앱에서 공유 Databricks 연결을 사용하려는 경우
App user connector게시된 앱의 각 사용자가 자신의 Databricks 계정을 연결해 자신의 데이터를 다루도록 하려는 경우

Databricks를 연결하면 앱은 다음 작업이 가능합니다.

  • 웨어하우스 데이터에 대해 SQL 쿼리 실행
  • SQL warehouse 조회 및 관리
  • Databricks 워크스페이스의 cluster 목록 조회
  • 실시간으로 데이터를 쿼리하는 라이브 대시보드 구축

인증은 Databricks service principal 또는 본인의 Databricks 계정(User OAuth)을 사용합니다. 어느 방식이든 자격 증명과 토큰은 Lovable의 게이트웨이에 저장되며 브라우저나 앱의 프론트엔드 코드에 도달하지 않습니다.

주요 활용 사례 및 예시 앱

예시 앱프롬프트 예시설명
라이브 KPI 대시보드Databricks 웨어하우스를 쿼리해 MRR, DAU, 이탈률을 보여주는 대시보드를 만들어줘. 5분마다 자동 새로고침 해줘.정적인 슬라이드를 웨어하우스 데이터 기반 라이브 대시보드로 대체합니다. 앱이 Databricks를 직접 쿼리하여 수동 내보내기 없이 핵심 지표를 최신 상태로 보여줍니다.
매출 파이프라인 추적기Databricks 테이블에서 매출과 딜 데이터를 가져와 지역과 분기별 필터가 있는 퍼널 뷰를 보여주는 파이프라인 추적기를 만들어줘.RevOps 팀에 웨어하우스에 있는 파이프라인 데이터에 대한 셀프 서비스 뷰를 제공합니다. 앱이 CRM 데이터가 도달하는 Databricks 테이블을 쿼리하여 구조화된 필터링 가능한 뷰로 표시합니다.
팀 지표 탐색기사용자가 팀과 날짜 범위를 선택하면 Databricks에서 가져온 핵심 지표 차트를 볼 수 있는 지표 탐색기를 만들어줘.팀이 데이터 요청을 넣지 않고도 자체 지표를 탐색할 수 있게 합니다. 앱이 매개변수화 SQL 쿼리를 실행하고 각 팀의 데이터로 스코프된 차트로 결과를 렌더링합니다.
데이터 품질 모니터웨어하우스 테이블에 대해 데이터 품질 검사를 실행하고 이상을 표시하는 내부 도구를 만들어줘.데이터 문제가 다운스트림 소비자에게 도달하기 전에 잡아냅니다. 앱이 스케줄에 따라 검증 쿼리를 실행하고 실패를 깔끔한 내부 뷰로 보여줍니다.
경영진 요약 봇자연어 데이터 질문에 Databricks 웨어하우스를 쿼리해 답하는 Slack 봇을 만들어줘.웨어하우스를 경영진을 위한 대화형 인터페이스로 바꿉니다. 앱이 질문을 SQL로 변환하고, Databricks에 쿼리한 뒤, 포맷된 답을 Slack에 게시합니다.

Databricks 연결 방식

Databricks 연결은 두 가지 방식 중 하나로 인증합니다. 연결을 만들 때 방식을 선택합니다.

방식연결 양식의 옵션쿼리 실행 주체적합한 경우
Service principal (machine-to-machine OAuth, 기본값)Use your own credentialsDatabricks admin이 만든 service principal팀이 공유하는 연결과 프로덕션 앱. 접근 권한이 특정 개인에게 의존하지 않아야 하는 경우
User OAuth (user-to-machine OAuth)User OAuth연결을 승인하며 로그인한 Databricks 사용자개인과 프로토타입. 그리고 Unity Catalog가 개인의 권한을 그대로 적용하고 Databricks 감사 로그에 각 쿼리를 실행한 사람이 남기를 원하는 팀

데이터 접근에 미치는 영향

Lovable은 개별 Lovable 사용자의 Databricks 권한을 기준으로 결과를 필터링하지 않습니다. 연결이 인증하는 identity가 그 연결을 사용하는 모든 사람에게 제공되는 데이터를 결정합니다.

  • service principal로 연결하면 그 service principal의 Unity Catalog 권한이 적용됩니다. HR 테이블에 접근 권한이 있는 service principal을 만들면 Lovable에서 해당 연결에 접근할 수 있는 모든 사람이 HR 데이터를 쿼리할 수 있습니다.
  • User OAuth로 연결하면 본인의 Unity Catalog 권한이 적용되고, Databricks 감사 로그는 모든 쿼리를 본인에게 귀속시킵니다. 이 연결을 공유하면 공유받은 모든 사람이 본인 자격으로 쿼리하며 본인이 볼 수 있는 모든 것을 봅니다.

공유 연결 권장 방식: 접근 역할당 하나의 service principal. 서로 다른 데이터로 스코프된 별도의 service principal을 만드세요.

  • databricks-engineering: 전체 웨어하우스 접근, 엔지니어만 이 연결을 Lovable에서 사용
  • databricks-sales: 파이프라인과 매출 테이블만, 세일즈 팀이 이 연결을 사용
  • databricks-company: 전사에 안전한 지표, 모든 사람이 이 연결을 사용

Lovable은 각 연결을 누가 사용할 수 있는지 통제합니다. Databricks는 각 identity가 무엇을 쿼리할 수 있는지 통제합니다. 두 가지가 결합해 사용자별 OAuth 없이 역할 기반 데이터 접근을 제공합니다.

워크스페이스에 Databricks 연결을 여러 개 만들 수 있으며, 각각 다른 service principal이나 사용자와 다른 접근 설정을 가질 수 있습니다.

이 커넥터는 읽기 전용 접근을 강제하지 않습니다. 메서드나 경로 allowlist를 적용하지 않으므로 모든 Databricks REST 경로와 verb가 그대로 전달되며, 연결은 자신의 identity, 즉 service principal이나 연결을 승인한 사용자에게 허용된 SQL이라면 무엇이든 실행합니다. 접근을 통제하는 방법은 Unity Catalog 권한 부여입니다. 연결을 읽기 전용으로 제한하기를 참고하세요.

Databricks는 안전한 OAuth 처리와 자동 토큰 갱신을 위해 Lovable의 게이트웨이 아키텍처를 사용합니다. service principal 연결은 client ID와 secret을 수명이 짧은 액세스 토큰으로 교환합니다. User OAuth 연결은 all-apis와 offline_access 스코프를 요청하므로, 게이트웨이가 리프레시 토큰을 보관하고 한 시간짜리 액세스 토큰을 백그라운드에서 갱신해 다시 로그인하라고 요청하지 않습니다. 인증 및 사용량 제한에 대한 자세한 내용은 게이트웨이 기반 커넥터를 참고하세요.

Databricks 컴퓨트 및 스토리지 비용은 Lovable이 아니라 Databricks가 청구합니다.

Databricks 연결하기

누가 Databricks 연결을 만들 수 있는지는 플랜과 워크스페이스 설정에 따라 다릅니다. App + chat 커넥터는 Free, Pro, Business 플랜에서 기본으로 사용할 수 있습니다. Enterprise 플랜에서는 처음에 사실상 비활성화되어 있습니다. 연결과 클라이언트를 만들 수 있는 사람 설정이 admin이 변경하기 전까지 No one으로 기본 설정되기 때문입니다.

네트워크 접근

어느 방식을 쓰든 Lovable의 게이트웨이가 Databricks 워크스페이스에 네트워크로 접근할 수 있어야 합니다. 워크스페이스가 인바운드 트래픽을 제한한다면 시작하기 전에 이 문제를 해결하세요.

Databricks IP access list는 웹 UI뿐 아니라 워크스페이스 REST API에도 적용됩니다. 따라서 목록에 없는 소스 IP는 인증 전에 거부되고 연결이 끝내 검증되지 않습니다. IP allowlisting을 참고해 Lovable의 게이트웨이 이그레스 범위를 ALLOW 목록에 추가하세요. 워크스페이스 IP access list는 admin UI가 아니라 Databricks REST API를 통해 구성하며, 계정 수준 컨텍스트 기반 인그레스 제어가 함께 적용되므로 요청은 두 가지를 모두 통과해야 합니다.

워크스페이스가 공개 네트워크 접근이 비활성화된 상태로 프런트엔드 Private Link를 사용하면 커넥터는 워크스페이스에 전혀 접근할 수 없으며, allowlisting도 우회책이 되지 않습니다. Databricks는 공개 접근이 비활성화된 워크스페이스에서 IP access list를 지원하지 않기 때문입니다. AWS에서는 private access settings 객체의 public_access_enabled가 기본값 False이므로, 시작하기 전에 이 값을 확인하세요.

연결 방식 선택

두 방식 모두 같은 종류의 연결을 만듭니다. 차이는 연결이 누구의 identity를 지니는지입니다. 그에 따라 연결이 어떤 데이터에 닿을 수 있는지, 그리고 연결을 계속 동작하게 할 책임이 누구에게 있는지가 정해집니다.

  • Use your own credentials는 Databricks admin이 만든 공유 identity인 service principal로 연결합니다. 기본으로 선택되어 있습니다. 연결을 사용하는 모든 사람이 service principal 자격으로 쿼리하므로, 팀을 떠난 사람이 생겨도 연결이 계속 동작하며, 접근 역할마다 자체 service principal을 주어 데이터 범위를 나눕니다. 공유 연결과 프로덕션 앱에는 이 방식을 선택하세요.
  • User OAuth는 본인의 Databricks 계정으로 로그인합니다. 쿼리가 본인을 대신해 실행되고, Unity Catalog가 본인의 권한을 적용하며, Databricks 감사 로그에 공유 service principal이 아니라 본인이 남습니다. Databricks account console에 커스텀 OAuth 애플리케이션이 필요하고, 연결은 본인 계정이 활성 상태로 유지되는 데 의존합니다(제한 사항 참고). admin에게 service principal을 요청하지 않고 본인 접근 권한 위에서 빌드하려는 경우, 또는 개인별 귀속이 중요한 경우에 선택하세요.

선택한 방식에 맞는 아래 설정 단계를 따르세요.

Databricks admin이 만든 service principal로 연결합니다. 연결 양식에서 이 옵션의 이름은 Use your own credentials이며 기본으로 선택되어 있습니다.

사전 준비

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

  • SQL warehouse가 하나 이상 있는 Databricks 워크스페이스
  • OAuth secret이 구성된 Databricks service principal (Databricks M2M OAuth 설정 참고)
  • service principal의 client ID와 client secret
  • Databricks 워크스페이스 URL (예: https://dbc-abc123.cloud.databricks.com)
  • Lovable 워크스페이스에서 연결 생성 권한 (연결과 클라이언트를 만들 수 있는 사람 참고)

1단계: Databricks에서 service principal 구성

OAuth secret이 있는 service principal을 아직 설정하지 않았다면, Databricks에서 다음 단계를 따르세요. 전체 레퍼런스는 Databricks M2M OAuth 설정을 참고하세요.

service principal을 만들고 OAuth secret을 생성하려면 Databricks account admin 또는 워크스페이스 admin이어야 합니다. 이 역할이 없다면 Databricks 관리자에게 이 단계를 완료해 달라고 요청하세요.

service principal 만들기

Databricks account console에서 User management → Service principals로 이동해 새 service principal을 만듭니다. account console 호스트는 워크스페이스를 어느 클라우드가 호스팅하는지에 따라 다릅니다.

Azure는 방식이 다릅니다. Azure의 account console은 사용자, 그룹, Unity Catalog metastore를 다루지만, 워크스페이스는 Azure portal에서 만들며, 조직이 첫 account admin을 지정하기 전까지는 아무도 account console을 열 수 없습니다. 또한 Azure는 두 종류의 service principal을 제공합니다. Azure Databricks managed와 Microsoft Entra ID managed입니다. Databricks는 이 커넥터 같은 자동화에는 Azure Databricks managed 종류를 권장합니다. Azure Databricks 문서는 docs.databricks.com이 아니라 Microsoft Learn에 있으므로, Azure를 사용할 때는 이 페이지의 링크를 그에 맞게 바꿔서 참고하세요.

워크스페이스에 할당

account console에서 그대로 Workspaces로 이동해 대상 워크스페이스를 선택하고, Permissions 탭을 연 뒤 Add permissions를 클릭합니다. service principal을 선택하고 Workspace access와 Databricks SQL access 엔타이틀먼트(entitlement)를 부여합니다. 엔타이틀먼트는 나중에 service principal의 Configuration 탭에서 검토하고 변경할 수 있습니다.

service principal 자체의 Permissions 탭은 다른 일을 합니다. 이 탭은 Service principal: Manager와 Service principal: User 역할을 다른 사람에게 할당해 누가 service principal을 관리할 수 있는지 정합니다. 데이터 접근 권한은 전혀 부여하지 않습니다. 데이터 접근은 다음 두 단계에서 나옵니다.

SQL warehouse 접근 권한 부여

Databricks 워크스페이스에서 사이드바의 SQL Warehouses를 클릭하고, 앱이 쿼리할 warehouse 행의 케밥 메뉴를 연 뒤 Permissions를 클릭하고, Can use 권한으로 service principal을 추가합니다. Can use 권한이 있으면 service principal이 warehouse를 시작하고 쿼리를 실행할 수 있습니다.

OAuth secret 생성

  • Databricks 워크스페이스에서 오른쪽 위 모서리의 사용자 이름을 선택하고 Settings를 선택합니다.
  • Identity and access로 이동한 뒤 Service principals를 찾아 Manage를 클릭합니다.
  • service principal을 선택하고 Secrets 탭을 엽니다.
  • Generate secret을 클릭하고, 만료 기간(최대 730일)을 선택한 뒤 Generate를 클릭합니다.
  • Client ID와 Client secret을 즉시 모두 복사하세요. secret은 한 번만 표시됩니다. 이 대화 상자를 닫은 뒤에는 다시 가져올 수 없습니다.

계속하기 전에 client ID와 client secret을 안전한 곳(예: 비밀번호 관리자)에 저장하세요. 2단계에서 두 값이 모두 필요하며, client secret은 Databricks에서 다시 가져올 수 없습니다.

데이터 접근 권한 부여

앱이 읽는 데이터에 Unity Catalog 권한을 부여합니다. principal을 지정할 때는 표시 이름이 아니라 Application ID(이전 단계의 OAuth client ID와 같은 값)를 백틱으로 감싸 사용합니다.

GRANT USE CATALOG ON CATALOG main TO `<application-id>`;
GRANT USE SCHEMA ON SCHEMA main.analytics TO `<application-id>`;
GRANT SELECT ON TABLE main.analytics.orders TO `<application-id>`;

세 가지 권한 부여가 모두 필요합니다. 테이블에 대한 SELECT는 해당 catalog에 대한 USE CATALOG와 schema에 대한 USE SCHEMA 없이는 아무 효과가 없습니다. USE CATALOG는 catalog owner이거나 catalog에 대한 MANAGE 권한이 있는 사람만 부여할 수 있으므로, 그들에게 요청해야 할 수 있습니다. 전체 최소 권한 설정은 연결을 읽기 전용으로 제한하기를 참고하세요.

Workspace URL 확인

Workspace URL은 Databricks에 로그인했을 때 브라우저 주소 표시줄에 나타납니다. Databricks는 이 호스트를 인스턴스 이름이라고 부르며, 형식은 클라우드에 따라 다릅니다.

  • AWS: https://dbc-a1b2345c-d6e7.cloud.databricks.com
  • Azure: https://adb-5555555555555555.19.azuredatabricks.net. Azure portal에서 워크스페이스 리소스를 선택해 URL 필드를 확인할 수도 있습니다.
  • GCP: https://8757561887652360.0.gcp.databricks.com

워크스페이스 객체 식별자 가져오기를 참고하세요.

2단계: Databricks 연결 설정

Lovable에서 Databricks 연결을 설정합니다.

Databricks 커넥터로 이동

Connectors를 열고 Databricks를 선택합니다.

새 연결 추가

Add connection을 클릭하고 App + chat connector를 선택합니다.

연결 이름 지정

Display name에 연결 이름을 입력합니다 (예: Databricks Engineering 또는 Databricks Sales). service principal의 접근 수준을 반영하는 이름을 사용하세요.

Use your own credentials를 선택한 상태로 두기

Configure connection에서 Use your own credentials를 선택된 상태로 둡니다. 기본값입니다.

자격 증명 입력

1단계: Databricks에서 service principal 구성에서 얻은 값을 사용합니다.

  • Workspace URL: Databricks 워크스페이스 URL (예: https://dbc-abc123.cloud.databricks.com)
  • Client ID: service principal의 OAuth client ID
  • Client secret: service principal의 OAuth client secret

이 연결을 사용할 수 있는 사람 선택

Sharing에서 연결은 기본적으로 본인만 사용할 수 있으며 Private 라벨이 표시됩니다. 공유하려면 Share with others를 클릭합니다. 그런 다음 이메일로 워크스페이스 멤버를 추가하거나, Invite entire workspace를 클릭해 Lovable 워크스페이스의 모든 사람이 연결을 사용할 수 있게 합니다.

이 설정은 대부분의 커넥터보다 Databricks에서 더 중요합니다. service principal의 권한 부여가 어떤 데이터가 보일지 결정하기 때문입니다. 여기에 추가한 사람은 누구나 service principal이 접근할 수 있는 모든 것을 쿼리할 수 있습니다. 자세한 내용은 연결과 클라이언트를 사용할 수 있는 사람을 참고하세요.

연결

Connect를 클릭합니다. Lovable이 Databricks 워크스페이스에 대해 자격 증명을 검증합니다.

본인의 Databricks 계정으로 로그인합니다. 쿼리가 본인 자격으로 실행되므로 연결이 읽을 수 있는 범위는 본인이 읽을 수 있는 범위와 정확히 같습니다. 연결 양식에서 이 옵션의 이름은 User OAuth입니다.

사전 준비

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

  • SQL warehouse가 하나 이상 있는 Databricks 워크스페이스, 그리고 앱이 쿼리할 warehouse에 대한 Can use 권한
  • 앱이 읽는 데이터에 대한 Unity Catalog 접근 권한. 연결은 본인 계정과 동일한 접근 권한을 가집니다
  • Lovable의 리다이렉트 URI가 등록된 커스텀 OAuth 애플리케이션과 그 client ID, client secret. Databricks account console에서 등록합니다(커스텀 OAuth 애플리케이션 활성화 참고). 아래 1단계에서 다룹니다
  • Databricks 워크스페이스 URL (예: https://dbc-abc123.cloud.databricks.com)
  • Lovable 워크스페이스에서 연결 생성 권한 (연결과 클라이언트를 만들 수 있는 사람 참고)

1단계: Databricks에 커스텀 OAuth 애플리케이션 등록

Lovable은 본인의 Databricks 계정에 있는 OAuth 애플리케이션을 통해 로그인시키므로, 로그인이 완료되려면 Databricks가 먼저 Lovable의 리다이렉트 URI를 알고 있어야 합니다. 애플리케이션을 만들려면 Databricks account admin이어야 하므로, 이 역할이 없다면 관리자에게 요청하세요. 애플리케이션 하나로 Lovable 워크스페이스의 모든 User OAuth 연결을 처리할 수 있습니다.

account console에서 App connections 열기

account admin으로 Databricks account console에 로그인해 사이드바의 Settings를 클릭하고, App connections 탭을 연 뒤 Add connection을 클릭합니다. account console 호스트는 워크스페이스를 어느 클라우드가 호스팅하는지에 따라 다릅니다.

애플리케이션 이름 지정 및 Lovable 리다이렉트 URI 추가

Application name에 Lovable을 식별할 수 있는 이름(예: Lovable)을 입력합니다. Redirect URLs에 다음을 추가합니다.

https://api.lovable.dev/workspaces/connectors/standard/oauth/callback

User OAuth를 선택하면 Lovable 연결 양식이 같은 값을 Redirect URI로 보여주고 복사 버튼도 제공하므로 거기서 복사할 수 있습니다. 값이 정확히 일치해야 합니다.

All APIs 스코프 선택

Access scopes에서 SQL이 아니라 All APIs를 선택합니다. 커넥터는 SQL 실행뿐 아니라 warehouse와 cluster 목록도 조회하므로 Lovable은 로그인 시 all-apis 스코프를 요청합니다. Lovable은 offline_access도 요청하며, 이 스코프가 백그라운드 토큰 갱신을 가능하게 합니다.

토큰 수명 검토

Access token TTL의 기본값은 60분, Refresh token TTL의 기본값은 10080분(7일)입니다. Lovable은 리프레시 토큰이 유효한 동안 액세스 토큰을 자동으로 갱신합니다. 리프레시 토큰이 만료되면 Lovable에서 연결을 다시 연결할 때까지 연결이 동작을 멈추므로, 보안 정책이 허용하고 재연결 횟수를 줄이고 싶다면 리프레시 토큰 TTL을 늘리세요.

client secret 생성 및 값 저장

Generate a client secret을 체크하고 연결을 만듭니다. Databricks가 Connection created 대화 상자에 Client ID와 Client secret을 표시합니다. 두 값을 즉시 복사하세요. secret은 한 번만 표시되며 나중에 다시 가져올 수 없습니다.

체크박스를 해제한 채로 secret 없는 애플리케이션을 만들 수도 있습니다(Databricks는 이를 public client라고 부릅니다). 그러면 Lovable에서도 Client Secret을 비워 둡니다. secret이 있는 애플리케이션이 더 안전한 구성이므로, 특별한 이유가 없다면 secret을 사용하세요.

본인의 Databricks 접근 권한 확인

본인 계정이 앱이 쿼리할 SQL warehouse에 대한 Can use 권한(SQL Warehouses → (해당 warehouse) → 케밥 메뉴 → Permissions)과 데이터에 대한 Unity Catalog 권한, 즉 catalog에 대한 USE CATALOG, schema에 대한 USE SCHEMA, 테이블이나 schema에 대한 SELECT를 갖고 있는지 확인하세요. 세 가지 모두 필수이며, 연결은 정확히 이 권한을 그대로 물려받습니다.

Workspace URL 확인

Workspace URL은 Databricks에 로그인했을 때 브라우저 주소 표시줄에 나타납니다. 예를 들어 AWS에서는 https://dbc-a1b2345c-d6e7.cloud.databricks.com, Azure에서는 https://adb-5555555555555555.19.azuredatabricks.net, GCP에서는 https://8757561887652360.0.gcp.databricks.com 형식입니다. 워크스페이스 객체 식별자 가져오기를 참고하세요.

2단계: Databricks 연결 설정

Databricks 커넥터로 이동

Connectors를 열고 Databricks를 선택합니다.

새 연결 추가

Add connection을 클릭하고 App + chat connector를 선택합니다.

연결 이름 지정

Display name에 연결 이름을 입력합니다. 연결이 본인 자격으로 동작하므로, 본인 이름을 넣은 이름(예: Databricks (Jane))을 쓰면 누구의 접근 권한을 지닌 연결인지 팀원에게 분명해집니다.

User OAuth 선택

Configure connection에서 User OAuth를 선택합니다. 양식이 Databricks OAuth 앱에 추가할 Redirect URI를 보여줍니다. 1단계에서 이 작업을 건너뛰었다면 지금 복사해 앱에 추가하세요.

OAuth 앱 정보 입력

1단계: Databricks에 커스텀 OAuth 애플리케이션 등록에서 얻은 값을 사용합니다.

  • Workspace URL: Databricks 워크스페이스 URL (예: https://dbc-abc123.cloud.databricks.com)
  • Client ID: 커스텀 OAuth 애플리케이션의 OAuth client ID
  • Client Secret: 애플리케이션의 client secret. secret 없는 public client로 만든 경우에만 비워 둡니다

이 연결을 사용할 수 있는 사람 선택

Sharing에서 연결은 기본적으로 본인만 사용할 수 있으며 Private 라벨이 표시됩니다. 공유하려면 Share with others를 클릭합니다. 그런 다음 이메일로 워크스페이스 멤버를 추가하거나, Invite entire workspace를 클릭해 Lovable 워크스페이스의 모든 사람이 연결을 사용할 수 있게 합니다.

User OAuth 연결을 공유받은 사람은 누구나 본인 자격으로, 본인의 Unity Catalog 권한으로 Databricks를 쿼리하며, Databricks 감사 로그는 그들의 쿼리를 본인에게 귀속시킵니다. 연결을 비공개로 두거나, 본인이 볼 수 있는 모든 것을 봐도 되는 사람에게만 공유하세요. 팀 전체가 사용하는 연결이라면 대신 service principal 연결을 만드세요.

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

연결 및 로그인

Connect를 클릭합니다. Databricks 로그인을 위한 새 창이 열립니다. 브라우저가 창을 차단하면 Lovable이 대신 리다이렉트합니다. Databricks 계정으로 로그인하고 요청된 접근을 승인하세요.

이 승인은 Databricks가 OAuth 애플리케이션에 토큰을 발급했다는 뜻일 뿐입니다. Lovable은 이 시점에 연결을 테스트하지 않습니다. 본인 계정에 warehouse에 대한 Can use 권한이나 Unity Catalog 권한이 없어도 연결은 성공으로 보고됩니다. 프로젝트에 연결을 링크한 뒤 실제 쿼리로 연결을 확인하세요.

연결되면 사용하려는 프로젝트에 연결을 링크하고, Databricks 데이터를 쿼리하는 앱을 만들기 시작할 수 있습니다.

연결을 읽기 전용으로 제한하기

커넥터는 앱이 보내는 것은 무엇이든 그대로 전달합니다. 메서드나 경로 allowlist를 적용하지 않으므로 모든 Databricks REST 경로와 모든 HTTP verb가 워크스페이스에 도달하며, 여기에는 DROP TABLE을 담아 /api/2.0/sql/statements로 보내는 POST도 포함됩니다. 실제로 작동하는 통제 수단은 Unity Catalog 권한입니다. 연결의 identity에 SELECT만 부여하고 그 이상은 부여하지 마세요.

이 단계는 service principal 연결을 기준으로 작성했습니다. User OAuth 연결은 본인의 권한으로 실행되므로 따로 잠글 것이 없습니다. 연결의 권한이 정확히 본인의 권한입니다. 그 위에 빌드한 앱을 읽기 전용으로 유지하려면 본인의 권한을 좁히거나, 아래 권한을 가진 service principal 연결을 앱에 주는 편이 더 낫습니다.

Unity Catalog에서 읽기 전용 권한 부여

이 명령은 catalog owner이거나 catalog에 대한 MANAGE 권한이 있는 사람으로 실행합니다. principal을 지정할 때는 표시 이름이 아니라 Application ID를 백틱으로 감싸 사용합니다.

GRANT USE CATALOG ON CATALOG main TO `<application-id>`;
GRANT USE SCHEMA ON SCHEMA main.analytics TO `<application-id>`;
GRANT SELECT ON SCHEMA main.analytics TO `<application-id>`;

GRANT SELECT ON SCHEMA는 schema에 있는 현재와 미래의 모든 테이블과 뷰를 포함합니다. 개별 테이블을 지정하려면 대신 SELECT ON TABLE main.analytics.orders를 부여합니다. 앱이 읽는 각 schema에 대해 이 명령을 반복하세요.

읽기 전용으로 유지하려는 service principal에는 MODIFY, CREATE TABLE, ALL PRIVILEGES를 절대 부여하지 마세요. 그리고 SHOW GRANTS `<application-id>` ON CATALOG main;으로 그룹이나 상위 catalog에서 이미 상속받은 권한을 확인하세요. 상위에서 부여한 권한은 아래로 전파되므로, catalog에 대한 MODIFY 하나가 세심하게 설정한 테이블 권한들을 무력화합니다.

전용 warehouse 부여

공유 분석 warehouse 대신 이 연결 전용으로 예약한 warehouse 하나에 Can use 권한을 부여합니다. 쿼리량은 앱의 최종 사용자에게서 발생하므로 예측할 수 없고 통제 밖에 있습니다. 전용 warehouse는 그 부하를 격리하고, 앱의 지출을 별도 항목으로 분리하며, 크기와 시간 제한을 독립적으로 설정할 수 있게 합니다. Cluster Size는 작게, Auto stop은 짧게 설정하세요.

Can manage는 끄세요. Can use만으로 warehouse를 시작하고 쿼리를 실행하기에 충분하며, warehouse 크기 변경이나 삭제는 허용하지 않습니다.

접근 역할당 하나의 service principal 유지

권한 부여는 service principal에 붙으므로, 연결은 그 principal만큼만 좁을 수 있습니다. 한 팀에 쓰기 접근이 필요하다면, 읽기 전용 연결을 넓히는 대신 그 팀에 두 번째 service principal과 두 번째 Lovable 연결을 제공하세요.

시맨틱 레이어 구축

모든 Databricks 사용 사례는 시맨틱 레이어의 이점을 얻습니다. 시맨틱 레이어는 핵심 지표의 의미, 사용할 테이블, 그리고 그 안에 담긴 가정에 대한 공유 정의입니다. '일간 활성 사용자'는 무엇을 의미하는지, MRR은 어떻게 계산되는지, 이탈에는 어떤 뷰를 사용해야 하며 trial은 제외되는지 같은 것들 말이죠.

이런 공유 컨텍스트가 없으면 각 앱이나 대시보드가 같은 지표를 서로 다르게 계산할 위험이 있습니다.

이미 시맨틱 레이어가 있는 경우

Databricks 워크스페이스에 이미 시맨틱 레이어가 있다면 (예: dbt metrics, Unity Catalog 태그, YAML 정의 파일) Lovable이 이를 참조하도록 지정하세요.

Use our semantic layer at catalog.schema.metrics_definitions when computing any KPIs. MRR is defined there as monthly_recurring_revenue.

아직 없는 경우

Lovable에서 전용 프로젝트를 사용해 시맨틱 레이어를 빠르게 구축할 수 있습니다. 새 프로젝트를 만들고 Databricks에 연결한 뒤, 에이전트에게 웨어하우스를 탐색하고 정의를 초안으로 작성해달라고 요청하세요.

Let's build a full semantic layer for our Databricks warehouse. Please start by exploring the tables and forming your own understanding of the data. Create a sample dashboard that showcases your analysis of the key metrics, the tables they use, and the assumptions behind each query. We will walk through them together and correct anything that is wrong. Use these tables as the main starting point: [table names]

가지고 있는 컨텍스트(이전 대시보드, 데이터 사전, dbt 스키마 파일 등)가 있으면 함께 투입하세요. Lovable이 이를 반영합니다. 에이전트에게 결과를 프로젝트 디렉터리에 Markdown 또는 YAML 파일로 저장하도록 요청하세요.

Save the finalized metric definitions as YAML files in this project. Other projects will reference them.

저장되면 같은 Lovable 워크스페이스의 다른 Lovable 프로젝트들이 해당 프로젝트의 지식을 참조해 일관된 지표 정의를 기본으로 얻을 수 있습니다.

제한 사항

  • 연결 안에서 사용자별 데이터 스코핑이 없습니다. service principal 연결을 사용하는 모든 사람이 동일한 데이터, 즉 service principal의 데이터를 보며, User OAuth 연결로 빌드하는 모든 사람은 연결을 승인한 사람 자격으로 쿼리합니다. 접근 역할별로 별도의 service principal을 만들거나, Databricks **app user connector**를 사용해 각 최종 사용자가 자신의 Databricks 로그인과 권한으로 쿼리하도록 하세요.
  • 강제되는 읽기 전용 접근이 없습니다. 커넥터는 메서드나 경로 allowlist를 적용하지 않으므로, 연결은 자신의 service principal이나 연결을 승인한 사용자에게 허용된 SQL이라면 무엇이든 실행합니다. Unity Catalog 권한 부여로 범위를 제한하세요. 연결을 읽기 전용으로 제한하기를 참고하세요.
  • 자동 캐싱이 없습니다. 쿼리 결과는 기본적으로 캐시되지 않습니다. 원하는 간격으로 앱에 캐싱 로직을 추가하도록 Lovable에 요청할 수 있습니다.
  • 게시 후에는 연결 접근이 강제되지 않습니다. 연결 수준 접근은 누가 연결로 빌드할 수 있는지를 정할 뿐, 누가 게시된 앱을 방문할 수 있는지는 정하지 않습니다. 누가 방문할 수 있는지는 별도의 게시 시점 통제입니다. 사이트 공개 범위를 Invite only(Free 및 Pro 플랜) 또는 Workspace나 Custom(Business 및 Enterprise 플랜)으로 설정해 방문자가 로그인하도록 하세요. Business와 Enterprise 플랜에서는 admin이 Workspace settings → Privacy & security → Default website access에서 워크스페이스 전체 기본값도 설정할 수 있습니다. 웹사이트 접근 제어를 참고하세요.
  • 고객 관리형 비용 제어. Lovable은 쿼리 비용 상한을 부과하지 않으며, Databricks budget도 마찬가지입니다. budget은 계정, 워크스페이스, 리소스 태그 단위로 적용되고 이메일 알림만 보내며, 최대 24시간까지 지연될 수 있습니다. warehouse를 실제로 제한하는 통제 수단은 Auto stop, 작은 Cluster Size, 그리고 STATEMENT_TIMEOUT입니다. 시스템 기본값이 172800초(2일)이므로, Settings → Compute → SQL warehouses → SQL Configuration Parameters에서 워크스페이스 전체에 대한 타임아웃을 설정하세요. warehouse별 타임아웃도 있지만 Beta이며 SQL warehouses API를 통해서만 설정할 수 있습니다.

Databricks 연결 관리

연결은 Connectors에서 관리합니다. **Databricks**를 선택한 뒤 연결을 엽니다.

  • Unlink projects로 특정 프로젝트에서 Databricks 접근을 제거하면서 다른 프로젝트에서는 연결을 계속 사용할 수 있게 합니다. 방법은 연결에서 프로젝트 연결 해제하기를 참고하세요.
  • Delete the connection으로 워크스페이스에서 연결을 완전히 제거합니다. 삭제는 영구적입니다. 연결된 모든 프로젝트에서 자격 증명이 제거되며, Databricks를 사용하는 앱 기능은 새 연결을 추가하기 전까지 동작을 멈춥니다. 방법과 삭제 권한이 있는 사람은 연결 삭제하기를 참고하세요.

FAQ

문제 해결

관련 주제

On this page