Snowflake에 앱 연결하기

Snowflake OAuth를 사용해 Snowflake를 Lovable 앱에 연결합니다. Lovable의 커넥터 게이트웨이를 통해 SQL을 실행하고 SQL REST API를 사용하며 Snowflake 계정의 웨어하우스와 데이터를 다룹니다.

Snowflake는 분석, 데이터 엔지니어링, AI/ML 워크로드를 위한 클라우드 데이터 플랫폼입니다. Snowflake 앱·챗 커넥터는 Snowflake 네이티브 OAuth(커스텀 보안 통합)를 사용하므로, 프로젝트에 장기 비밀번호를 포함하지 않고도 앱이 Lovable의 커넥터 게이트웨이를 통해 Snowflake를 호출할 수 있습니다.

Snowflake를 연결하면 앱은 다음 작업을 할 수 있습니다.

• SQL 실행 및 SQL REST API 사용(예: 구문 제출 및 상태 확인)
• 사용자 role이 접근할 수 있는 warehouse, database, schema 다루기
• 데이터 팀이 Snowflake에서 관리하는 지표 정의인 semantic view 조회하기. 대시보드가 BI 도구와 같은 수치를 보고합니다
• Snowflake를 기반으로 하는 내부 도구, 대시보드, 데이터 워크플로우 구축

Snowflake는 조직이 이미 Snowflake에 데이터를 중앙화하고 있으며, Lovable 앱이 해당 데이터를 안전하게 쿼리하거나 오케스트레이션해야 할 때 적합합니다.

주요 활용 사례 및 예시 앱

Snowflake 연결 방식

• OAuth 2.0(authorization code): Snowflake에서 커스텀 OAuth 통합을 등록하고 Lovable에 Account URL, Client ID, Client Secret, Role을 입력합니다. 이후 본인(또는 관리자)이 Snowflake 로그인을 완료해 연결을 승인합니다. Lovable이 OAuth 토큰을 저장하고 자동으로 갱신하므로, 인증 정보가 앱 코드에 남지 않습니다.
• Role: 연결은 구성한 단일 Snowflake role로 실행됩니다. 관리자 role은 사용할 수 없으므로, 전용 최소 권한 role을 대신 생성합니다(아래 Step 2에서 방법을 설명합니다).
• Gateway: API 요청은 토큰을 관리하는 Lovable의 커넥터 게이트웨이를 통해 프록시됩니다. 제한은 게이트웨이 기반 커넥터를 참고합니다.

Snowflake 연결하기

Snowflake 연결을 누가 생성할 수 있는지는 플랜과 workspace 설정에 따라 다릅니다. Enterprise 플랜에서는 앱·챗 커넥터가 처음에 사실상 비활성화되어 있습니다. 연결과 클라이언트를 생성할 수 있는 사람 설정이 admin이 변경하기 전까지 No one으로 기본 설정되기 때문입니다. 서로 다른 계정이나 role로 여러 Snowflake 연결을 생성할 수 있으며, 이는 개발 데이터와 프로덕션 데이터를 분리하는 데 유용합니다.

연결을 생성하면 사용하려는 프로젝트에 연결을 링크할 수 있습니다. 프로젝트에서 개발하는 사람은 누구나 챗에서 Lovable에게 자신의 프로젝트를 연결해 달라고 요청할 수 있습니다.

아래 단계는 모든 것을 처음부터 생성할 수 있지만, 반드시 빈 상태에서 시작해야 하는 것은 아닙니다. 각 단계는 기존 구성 요소가 충족해야 하는 기준으로 시작하므로, 이미 그 기준을 통과한 부분은 확인 후 생성용 SQL을 건너뛰면 됩니다.

사전 준비

Snowflake를 연결하기 전에 다음을 갖췄는지 확인합니다.

• OAuth 보안 통합을 생성하고 그 client secret을 읽을 수 있는 ACCOUNTADMIN role(또는 전역 CREATE INTEGRATION 권한)을 가진 사용자와 Snowflake 계정
• role을 생성하고 데이터 접근 권한을 부여할 수 있는 권한. role 생성에는 USERADMIN, 권한 부여 실행에는 SECURITYADMIN이 필요합니다(SECURITYADMIN의 전역 MANAGE GRANTS 권한은 소유하지 않은 객체까지 포괄하며, Step 2의 future grant에도 필요합니다)
• 연결을 승인할 전용 비개인 Snowflake 사용자. 개인 계정 대신 전용 사용자를 사용하면, 연결을 설정한 사람이 회사를 떠나더라도 연결이 계속 활성 상태로 유지됩니다. 이 사용자는 전용 role을 보유해야 하고 브라우저 로그인을 완료할 수 있어야 하므로, TYPE = PERSON으로 유지합니다. TYPE = SERVICE 사용자는 연결을 승인할 수 없습니다. 이 사용자는 비밀번호로도 SAML SSO로도 로그인할 수 없으며, Snowflake OAuth는 대화형 로그인이 필요한 authorization code 플로우만 제공하기 때문입니다
• Lovable workspace에서 연결을 생성할 수 있는 권한(연결과 클라이언트를 생성할 수 있는 사람 참고)

Step 4를 마치면 Lovable 연결 양식이 요구하는 네 가지 값을 얻게 됩니다.

Step 1: account URL 확인

Lovable에는 https://<orgname>-<account_name>.snowflakecomputing.com 형식의 account URL이 필요하며, 끝에 슬래시나 경로가 없어야 합니다.

Step 2: 최소 권한 role 생성

Snowflake는 기본적으로 ACCOUNTADMIN, SECURITYADMIN, ORGADMIN, GLOBALORGADMIN을 OAuth 세션에서 차단하며, Lovable은 연결 양식에서 ACCOUNTADMIN과 SECURITYADMIN을 추가로 거부합니다. 이는 한계가 아니라 의도된 기능입니다. 앱에 필요한 데이터만 볼 수 있는 전용 role을 생성합니다.

아래 블록을 순서대로 실행합니다. 각 블록은 해당 구문에 Snowflake가 요구하는 role로 시작하는데, USE ROLE이 워크시트 세션의 나머지 동안 계속 적용되기 때문입니다.

USE ROLE USERADMIN;
CREATE ROLE IF NOT EXISTS LOVABLE_ROLE
  COMMENT = 'Least-privilege role for the Lovable connector';

USE ROLE SECURITYADMIN;
GRANT USAGE ON WAREHOUSE MY_WH TO ROLE LOVABLE_ROLE;

USE ROLE SYSADMIN;
CREATE WAREHOUSE IF NOT EXISTS LOVABLE_WH
  WAREHOUSE_SIZE = XSMALL
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;
GRANT USAGE ON WAREHOUSE LOVABLE_WH TO ROLE LOVABLE_ROLE;

USE ROLE SECURITYADMIN;
GRANT USAGE ON DATABASE MY_DB TO ROLE LOVABLE_ROLE;
GRANT USAGE ON SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
GRANT SELECT ON ALL TABLES IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
GRANT SELECT ON ALL VIEWS  IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
-- Cover tables and views created later:
GRANT SELECT ON FUTURE TABLES IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
GRANT SELECT ON FUTURE VIEWS  IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;

USE ROLE USERADMIN;
GRANT ROLE LOVABLE_ROLE TO USER MY_AUTHORIZING_USER;

Step 3: OAuth 보안 통합 생성

이는 Lovable이 인증에 사용하는 OAuth 클라이언트입니다. 생성하려면 ACCOUNTADMIN 또는 전역 CREATE INTEGRATION 권한이 필요합니다. Snowflake 문서의 Configure Snowflake OAuth for custom clients를 참고합니다. 이미 통합이 있다면 아래의 재사용 검사로 건너뜁니다.

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION LOVABLE_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://api.lovable.dev/workspaces/connectors/standard/oauth/callback'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_ENFORCE_PKCE = TRUE
  ALLOWED_ROLES_LIST = ('LOVABLE_ROLE')
  COMMENT = 'OAuth client for the Lovable Snowflake connector';

이 값을 사용하는 이유는 다음과 같습니다.

• OAUTH_CLIENT_TYPE = 'CONFIDENTIAL': Lovable은 client secret을 서버 측에 저장하므로 confidential 클라이언트를 사용할 수 있으며, 이는 public 클라이언트보다 더 안전합니다.
• OAUTH_REDIRECT_URI: Lovable이 사용하는 콜백과 정확히 일치해야 합니다. Lovable 연결 양식은 이 값을 Redirect URI 아래에 복사 버튼과 함께 표시하므로, 거기에서 복사할 수 있습니다.
• OAUTH_ISSUE_REFRESH_TOKENS = TRUE와 OAUTH_REFRESH_TOKEN_VALIDITY = 7776000: Snowflake access token은 수명이 짧으므로 Lovable이 백그라운드에서 갱신합니다. 두 값 모두 커스텀 클라이언트에 대한 Snowflake 기본값이므로, 새 통합에서는 이 두 줄이 아무것도 바꾸지 않습니다. 그래도 명시적으로 설정하면, 누군가 이전에 편집한 통합에서 커넥터가 더 짧은 유효 기간을 조용히 물려받는 일을 막을 수 있습니다. 7776000초(90일)는 최댓값이기도 하며, refresh token이 만료되면 Lovable에서 다시 연결하므로, 재연결은 분기당 최대 한 번으로 유지됩니다.
• OAUTH_ENFORCE_PKCE = TRUE: Lovable은 항상 PKCE code challenge를 전송하므로, 이를 강제할 수 있습니다. 이렇게 하면 authorization code 가로채기로부터 플로우를 보호합니다.
• ALLOWED_ROLES_LIST = ('LOVABLE_ROLE'): 목록에 없는 모든 role은 암묵적으로 차단되므로, 이 통합은 커넥터 role에 대해서만 세션을 발급할 수 있습니다. 유출된 client 인증 정보를 더 넓은 세션으로 확장할 수 없으며, Lovable 연결을 더 높은 권한의 role로 다시 지정하려 해도 통합을 관리하는 사람이 먼저 이 목록을 갱신하기 전까지는 승인 단계에서 실패합니다.

Step 4: client ID와 secret 조회

계속 ACCOUNTADMIN으로, 생성된 인증 정보를 읽습니다.

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('LOVABLE_OAUTH');

결과는 키가 소문자인 JSON 객체입니다(oauth_client_id, oauth_client_secret, oauth_client_secret_2). oauth_client_id와 oauth_client_secret을 복사합니다(두 secret 중 어느 것이든 작동하며, 다운타임 없이 교체할 수 있도록 두 개가 존재합니다). 이 함수는 언제든 다시 실행할 수 있으므로, secret을 잃어버려도 통합을 다시 생성할 필요가 없습니다.

Step 5: Lovable에서 Snowflake 연결

연결되면 프로젝트에서 개발하는 사람은 누구나 챗에서 Lovable에게 자신의 프로젝트를 Snowflake에 링크해 달라고 요청할 수 있습니다(구성된 연결 수준 접근 권한에 따라). 그러면 Lovable 앱은 개발 중에도, 게시 후에도 Snowflake 데이터에 대해 SQL을 실행할 수 있습니다.

연결 확인 및 사용

첫 번째 성공적인 쿼리가 role이 실제로 warehouse와 데이터에 도달할 수 있음을 증명하므로, 연결한 직후에 쿼리를 하나 실행합니다. 연결을 프로젝트에 링크하고 챗에서 Lovable에게 데이터를 쿼리해 달라고 요청합니다. 예를 들면 다음과 같습니다.

Use Snowflake and show the ten most recent rows from MY_SCHEMA.MY_TABLE.

Snowsight의 Monitoring → Query History에서 승인 사용자나 warehouse로 필터링해 쿼리를 확인합니다. 같은 화면에서 앱이 이후 실행하는 모든 것을 감사할 수 있습니다.

개발 시 알아 둘 두 가지가 있습니다.

• 컴퓨트가 필요한 쿼리는 warehouse에서 실행해야 합니다. Lovable에 어떤 warehouse를 사용할지 알려 주거나(SQL API는 구문마다 warehouse 매개변수를 받습니다), 승인 사용자에게 기본 warehouse를 설정합니다.
• 쿼리가 실패하면 연결 자체는 정상이며, role에 warehouse나 권한이 없는 것입니다. Step 2로 돌아가 SHOW GRANTS TO ROLE LOVABLE_ROLE;를 확인합니다.

Semantic view

Snowflake 계정에 데이터 팀이 관리하는 지표 정의인 semantic view가 있으면, Lovable은 연결된 프로젝트에서 dashboard, KPI, 분석을 빌드할 때 직접 작성한 SQL보다 이를 우선합니다. 지표와 차원을 자동으로 찾고 Snowflake의 SEMANTIC_VIEW() 문법으로 조회하므로 앱의 수치가 같은 정의를 사용하는 BI 도구와 일치합니다.

프롬프트에서 semantic view를 언급할 필요는 없습니다. 원하는 결과를 요청하면 Lovable이 먼저 일치하는 view를 확인합니다:

Build a revenue KPI dashboard from our Snowflake data.

요청에 맞는 semantic view가 없으면 테이블을 직접 조회합니다.

다음 사항을 확인하세요:

• 연결 role에 semantic view 접근 권한이 필요합니다. 지표 쿼리에는 role이 사용할 수 있는 warehouse도 필요하지만 SHOW SEMANTIC VIEWS 같은 탐색 명령에는 필요하지 않습니다.
• Lovable은 semantic view에서 앱 내부 view와 dashboard를 만듭니다. 지표 값을 채팅 답변으로 보고하지 않으므로 지난 분기 매출을 묻는 대신 dashboard 생성을 요청하세요.
• Lovable은 semantic view를 만들거나 변경하지 않습니다. Snowflake에서 정의하고 관리하세요.

모범 사례

• 환경마다 연결 하나. 개발 데이터와 프로덕션 데이터에 대해 별도의 통합, role, 연결을 생성합니다.
• 앱이 실제로 데이터를 쓰지 않는 한 role을 읽기 전용으로 유지하고, 권한을 전체 database가 아니라 특정 schema로 한정합니다.
• 프로덕션 앱에서는 예상치 못한 비용을 제한하도록 리소스 모니터가 있는 전용 warehouse를 사용합니다.
• 개인 로그인이 아니라 전용 사용자로 승인합니다. 승인 사용자가 비활성화되면 누군가 다시 연결하기 전까지 연결이 작동을 멈춥니다.
• 두 번째 secret 슬롯을 사용해 client secret을 주기적으로 교체한 뒤, Lovable에서 연결을 업데이트합니다.
• 나중에 연결의 role을 변경하나요? 다시 연결하기 전에 새 role을 통합의 ALLOWED_ROLES_LIST에 추가합니다.
• refresh token이 만료되면 다시 연결해야 합니다(위 설정으로는 최대 90일마다).

제한 사항

• scope와 role은 Snowflake OAuth 통합과 구성한 role에 의해 결정되며, 앱은 해당 권한을 초과할 수 없습니다.
• 이 커넥터는 사용자별 Snowflake 로그인을 제공하지 않습니다. 각 연결은 workspace 연결에 대한 공유 승인을 나타냅니다. 각 최종 사용자가 자신의 Snowflake 계정으로 로그인하고 자신의 role로 쿼리해야 한다면, Snowflake **앱 사용자 커넥터**를 사용합니다.
• 게이트웨이 기반 커넥터에서 설명한 게이트웨이 제한이 적용됩니다.

Snowflake 연결 관리

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

• Unlink projects로 특정 프로젝트에서 Snowflake 접근을 제거하되, 다른 프로젝트에서는 연결을 계속 사용할 수 있게 유지합니다. 단계는 연결에서 프로젝트 연결 해제를 참고합니다.
• Delete the connection으로 연결을 workspace에서 완전히 제거합니다. 삭제는 영구적입니다. 연결된 모든 프로젝트에서 인증 정보가 제거되며, Snowflake을 사용하는 앱 기능은 새 연결을 추가하기 전까지 작동을 멈춥니다. 단계와 삭제 권한이 있는 사람은 연결 삭제를 참고합니다.

문제 해결

관련 주제

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