Databricks에 앱 연결하기

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

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

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

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

인증은 Databricks service principal을 사용합니다. 자격 증명은 Lovable의 게이트웨이에 안전하게 저장되며 브라우저나 앱의 프론트엔드 코드에 노출되지 않습니다.

주요 활용 사례 및 예시 앱

Databricks 연결 방식

Databricks 커넥터는 service principal 인증 (M2M OAuth)을 사용합니다. 개별 사용자로 연결하는 대신, Databricks에서 특정 테이블과 뷰에 대한 접근 권한을 가진 service principal을 만들고 그 자격 증명을 Lovable에 제공합니다.

데이터 접근에 미치는 영향

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

예를 들어 HR 테이블에 접근 권한이 있는 service principal을 만들면 Lovable에서 해당 연결에 접근 권한이 있는 모든 사람이 HR 데이터를 쿼리할 수 있습니다.

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

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

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

Databricks는 안전한 OAuth 처리와 자동 토큰 갱신을 위해 Lovable의 게이트웨이 아키텍처를 사용합니다. 인증 및 사용량 제한에 대한 자세한 내용은 게이트웨이 기반 커넥터를 참고하세요.

Databricks 연결하기

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

사전 준비

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

• 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 워크스페이스에서 연결 생성 권한 (연결과 클라이언트를 만들 수 있는 사람 참고)
• 워크스페이스가 인바운드 트래픽을 제한하는 경우, Lovable에서 Databricks 워크스페이스로의 네트워크 접근

1단계: Databricks에서 service principal 구성

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

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>`;

2단계: Databricks 연결 설정

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

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

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

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

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>`;

시맨틱 레이어 구축

모든 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의 데이터를 봅니다. 접근 역할별로 별도의 service principal을 만들거나, Databricks **app user connector**를 사용해 각 최종 사용자가 자신의 Databricks 로그인과 권한으로 쿼리하도록 하세요.
• 강제되는 읽기 전용 접근이 없습니다. 커넥터는 메서드나 경로 allowlist를 적용하지 않으므로, 연결은 자신의 service principal에게 허용된 SQL이라면 무엇이든 실행합니다. Unity Catalog 권한 부여로 범위를 제한하세요. 연결을 읽기 전용으로 제한하기를 참고하세요.
• 자동 캐싱이 없습니다. 쿼리 결과는 기본적으로 캐시되지 않습니다. 원하는 간격으로 앱에 캐싱 로직을 추가하도록 Lovable에 요청할 수 있습니다.
• 게시 후에는 연결 접근이 강제되지 않습니다. 연결 수준 접근은 누가 연결로 빌드할 수 있는지를 정할 뿐, 누가 게시된 앱을 방문할 수 있는지는 정하지 않습니다. 누가 방문할 수 있는지는 별도의 게시 시점 통제입니다. Business와 Enterprise 플랜에서는 사이트 공개 범위를 Workspace 또는 Custom으로 설정해 방문자가 로그인하도록 하고, 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

문제 해결

관련 주제

• App user 커넥터: 사용자가 자신의 계정을 연결하게 하기
• Microsoft Fabric에 앱 연결하기
• Workday에 앱 연결하기
• Notion에 앱 연결하기
• Granola에 앱 연결하기