Notion에서 Snowflake MCP 설정하기

이 참조 문서에 있는 내용

Snowflake를 커스텀 에이전트 또는 Notion 에이전트에 연결하여 Notion에서 회사 데이터에 관해 질문하는 방법을 알아보세요.

자주 묻는 질문(FAQ)으로 이동

일부 기능은 알파 단계입니다.

워크스페이스에서 구성한 MCP 연결과 커스텀 에이전트의 사용자별 사용 권한 관리를 포함하여 이 문서에서 다루는 일부 기능은 현재 알파 단계이며, 워크스페이스에서 아직 제공되지 않을 수 있습니다.

사용 권한을 요청하려면 Notion 고객사 담당팀에 문의하거나 데이터 에이전트 얼리 액세스 프로그램에 신청하세요→

커스텀 에이전트와 Notion 에이전트는 Snowflake가 운영하는 MCP(Model Context Protocol) 서버를 통해 Snowflake에 연결할 수 있습니다. 설정을 마치면 에이전트에게 Snowflake 웨어하우스 데이터에 관해 질문하고 Notion에서 바로 답변을 받을 수 있습니다.

설정은 단계별로 진행되며 단계마다 담당자가 다릅니다.

  • Snowflake 관리자는 역할, 웨어하우스, Snowflake 관리 대상 MCP 서버를 설정합니다.

  • Notion 워크스페이스 소유자 또는 관리자는 워크스페이스의 Snowflake MCP 연결을 구성합니다.

  • 이후 워크스페이스 멤버는 자신의 Snowflake 인증 정보를 사용하여 커스텀 에이전트에서 Snowflake MCP에 연결하거나, Snowflake를 자신의 Notion 에이전트에 직접 연결할 수 있습니다. 두 연결 방식 모두 이 문서의 1~10단계까지는 동일하며, 11단계부터는 연결하려는 에이전트에 따라 진행 방법이 달라집니다.

  • 사용 가능한 도구는 Snowflake 클라우드 리전에 따라 다를 수 있습니다.

  • Snowflake의 관리 대상 MCP 서버는 중국 본토 또는 정부 리전에서 사용할 수 없습니다.

  • Notion 워크스페이스가 비즈니스 또는 엔터프라이즈 요금제를 이용 중이어야 합니다.

  • 웹 또는 데스크톱에서 Notion을 사용하세요. 이 기능은 모바일에서 사용할 수 없습니다.

  • 회사에 Snowflake 계정이 있어야 합니다.

  • 커스텀 에이전트를 만들려면 워크스페이스에서 에이전트를 생성할 권한이 필요합니다.

공유 설정을 사용하더라도 모든 사용자가 같은 데이터를 볼 수 있는 것은 아닙니다.

워크스페이스에는 OAuth 클라이언트 ID와 시크릿을 비롯한 연결 정보가 저장됩니다. 이 정보는 연결을 설정하기 위한 것으로, 공유 로그인 정보가 아닙니다. 각 사용자는 자신의 Snowflake 계정으로 로그인합니다. 커스텀 에이전트를 사용하든 자신의 Notion 에이전트를 사용하든, 에이전트는 해당 계정에 사용 권한이 있는 데이터에만 접근할 수 있습니다.

팀에서 Snowflake를 Notion에 연결하려면 먼저 Snowflake 관리자가 사용 권한을 설정해야 합니다. 이 단계는 설정 과정에서 가장 복잡하지만 한 번만 진행하면 됩니다. Notion 워크스페이스 관리자와 협력하여 진행하세요. Notion은 리디렉션 URI를 제공하고, Snowflake는 OAuth 클라이언트 ID와 시크릿을 제공합니다.

역할과 웨어하우스를 설정하고, Snowflake 관리 대상 MCP 서버를 생성한 다음, 필요한 리소스에 대한 사용 권한을 부여하고, OAuth 범위와 보안 통합을 구성하고, 조직에서 요구하는 경우 네트워크 정책을 추가합니다.

시작하기 전에 Notion 워크스페이스 관리자와 함께 이 워크시트를 작성하세요. 멤버는 이 단계를 건너뛰고, 설정이 완료되면 자신의 Snowflake 계정으로 로그인할 수 있습니다.

OAuth 클라이언트 시크릿을 비공개로 유지하세요.

Slack, 티켓, 소스 코드 관리 시스템 또는 터미널 기록에 시크릿을 추가하지 마세요. 승인된 보안 채널을 통해서만 공유하세요.

필드

값

담당자

Snowflake 계정 식별자

<organization-account>

Snowflake 관리자

MCP 데이터베이스

<database_name>

Snowflake 관리자

MCP 스키마

<schema_name>

Snowflake 관리자

MCP 서버

<mcp_server_name>

Snowflake 관리자

웨어하우스

<warehouse_name>

Snowflake 관리자

사용 권한 역할

<mcp_access_role>

Snowflake 관리자

서버 URL

https://<account_host>/api/v2/databases/<database_name>/schemas/<schema_name>/mcp-servers/<mcp_server_name>

Snowflake 관리자

기본 역할 범위

session:role:<mcp_access_role>

Snowflake 관리자

리디렉션 URI

Notion에서 생성한 URI 복사

Notion 워크스페이스 관리자

OAuth 클라이언트 ID

Snowflake에서 가져오기

Snowflake 관리자

OAuth 클라이언트 시크릿

승인된 보안 채널을 통해 전송

Snowflake 관리자

계정 호스트 이름에는 언더바가 아닌 하이픈을 사용합니다. 서버 URL의 각 객체 이름이 Snowflake의 해당 객체 이름과 일치하는지 확인하세요.

가능한 한 필요한 최소한의 권한만 부여한 전용 역할과 승인된 웨어하우스 하나를 사용하세요.

부차적 역할이 없는 제한된 역할(권장) 이 모델은 이해하고 감사하기가 더 쉽습니다. OAUTH_USE_SECONDARY_ROLES = NONE으로 설정하고 ALLOWED_ROLES_LIST를 지정한 다음, Notion 범위 session:role:<mcp_access_role>을 사용하세요.

사용자의 기본 부차적 역할(선택 항목) 서버에 각 사용자의 Snowflake DEFAULT_SECONDARY_ROLES에서 상속된 권한이 필요할 때만 이 모델을 사용하세요. OAUTH_USE_SECONDARY_ROLES = IMPLICIT으로 설정하고 ALLOWED_ROLES_LIST는 생략한 다음, 명시적인 기본 역할 범위를 사용하세요. Snowflake에서는 IMPLICIT 부차적 역할과 ALLOWED_ROLES_LIST를 함께 사용할 수 없으므로, 이 모델을 사용할 때는 허용 항목 목록을 생략하세요.

가능하면 MCP 서버에 필요한 최소한의 권한만 부여한 전용 역할을 사용하세요.

일반적인 ID 관리 프로세스에 따라 이 역할을 부여하세요. Okta 또는 SCIM으로 Snowflake 역할의 멤버십을 관리한다면, 해당 프로세스를 거치지 않고 사용자를 수동으로 추가하지 마세요.

서버를 운영할 팀이 소유한 데이터베이스와 스키마를 생성하거나 선택하세요.

거버넌스가 적용되는 비즈니스 관련 질문을 처리하려면 멤버가 사용할 도구로 Cortex Agent를 제공할 수 있습니다. Cortex Agent를 사용하면 시맨틱 뷰, 검증된 쿼리, 검색과 오케스트레이션을 한곳에서 관리할 수 있습니다. Cortex Agent 사용은 선택 사항입니다. 생성한다면 아래 사양을 따르세요. 기존 에이전트를 교체한다면 새 에이전트가 승인된 사양에 맞는지 확인하세요.

execution_environment는 반드시 Analyst 도구 리소스 아래에 중첩되어 있어야 합니다.

warehouse를 최상위 수준에 배치하면 에이전트 정의는 생성될 수 있지만, 실행 시 도구에 실행용 웨어하우스가 지정되지 않습니다.

지원되는 다른 Snowflake MCP 도구 유형으로는 CORTEX_ANALYST_MESSAGE, CORTEX_SEARCH_SERVICE_QUERY, GENERIC과 SYSTEM_EXECUTE_SQL이 있습니다.

SQL에 직접 접근해야 하는 경우, 필요한 최소한의 권한만 부여한 전용 역할을 사용하는 MCP 서버를 따로 설정하고 해당 역할이 읽기 전용인지 확인하세요.

거버넌스가 적용되는 에이전트의 서버에 SYSTEM_EXECUTE_SQL을 추가하면 클라이언트가 시맨틱 뷰와 검증된 쿼리를 우회할 수 있게 됩니다.

각 도구에 명확한 이름과 설명을 지정하세요. 어떤 데이터를 다루는지, 결과가 얼마나 상세한지, 언제 사용해야 하는지 설명하세요. 에이전트가 적절한 도구를 선택하는 데 도움이 됩니다.

MCP 서버에 대한 USAGE 권한이 있으면 해당 역할로 서버에 연결하고 서버의 도구를 확인할 수 있습니다. 그렇다고 해당 역할에 웨어하우스, 에이전트, 시맨틱 뷰, 검색 서비스, 저장 프로시저 또는 기반 데이터에 대한 사용 권한이 부여되는 것은 아닙니다. 서버 도구에 필요한 각 리소스의 사용 권한을 역할에 부여하세요.

각 도구에 필요한 추가 리소스에 대해서만 사용 권한을 부여하세요. 예를 들어 승인된 시맨틱 뷰에는 SELECT 권한을, Cortex 검색 서비스에는 USAGE 권한을, 특정 함수나 프로시저에는 USAGE 권한을 부여하세요. 이 역할을 PUBLIC에 부여하거나 현재 또는 향후 생성될 객체에 광범위한 권한을 추가하지 마세요.

OAuth를 설정하기 전에 MCP 서버와 부여된 권한을 확인하세요.

멤버가 요청할 역할을 정확히 알 수 있도록 MCP 스키마를 설정하세요.

명시적인 역할 범위를 사용하세요. session:role:all은 사용하지 마세요. Snowflake는 이 값을 모든 역할에 대한 사용 권한이 아니라 사용자의 기본 주 역할로 해석하며, 권한이 높은 역할에 적용되는 정책에 따라 차단될 수 있습니다. 역할을 명시적으로 지정하면 어떤 사용 권한을 요청하는지 명확해지고 확인하기도 쉬워집니다.

이 SQL을 실행하기 전에 Notion 워크스페이스 관리자와 상의하세요. 관리자에게 워크스페이스 MCP 설정 폼에 Snowflake 서버 URL을 입력하고 인증 수동 구성과 워크스페이스 공유 OAuth 클라이언트 사용을 활성화하도록 요청하세요. 그러면 Notion에서 리디렉션 URI가 생성됩니다. 이를 복사해 Snowflake 관리자에게 보내세요. Snowflake에서 클라이언트 ID와 시크릿을 생성한 후에는 워크스페이스 관리자가 나머지 연결 설정을 완료할 수 있습니다.

Notion에서 제공한 리디렉션 URI를 그대로 사용하세요. 끝에 슬래시 또는 쿼리 매개변수를 추가하거나 호스트를 변경하지 마세요.

IS_AGENTIC = TRUE로 설정하면 이 통합을 통해 생성된 세션이 에이전트 세션으로 표시됩니다. 그러면 Snowflake의 IS_AGENT_ACTIVATED() 함수가 TRUE를 반환해 Snowflake가 에이전트별 감사와 거버넌스를 적용할 수 있습니다. 선택 사항인 부차적 역할 모델을 사용하는 경우 OAUTH_USE_SECONDARY_ROLES = IMPLICIT로 설정하고 ALLOWED_ROLES_LIST는 생략하세요.

갱신 토큰의 유효 기간으로 설정된 값인 7776000초는 90일에 해당합니다. 이 값을 사용하기 전에 조직의 재인증과 토큰 교체 정책에 맞는지 확인하세요. 일반적인 변경에는 CREATE OR REPLACE SECURITY INTEGRATION을 사용하지 마세요. 해당 통합을 교체하면 기존 연결이 중단될 수 있습니다.

시크릿을 표시하지 않고 통합을 확인하려면 다음을 실행하세요.

통합이 활성화되어 있고 리디렉션 URI가 정확히 일치하는지 확인하세요. 또한 해당 역할이 허용되어 있고 차단되지 않았는지, 갱신 토큰과 PKCE가 활성화되어 있는지, 승인 엔드포인트와 토큰 엔드포인트가 모두 Snowflake의 공용 계정 호스트를 사용하는지도 확인하세요.

이 단계는 조직에서 네트워크 정책을 요구하는 경우에만 필요합니다. 보안 또는 네트워크 담당자에게 Notion의 현재 송신 범위를 승인해 달라고 요청하세요.

OAuth 통합에서는 다음 두 Notion 경로를 모두 허용해야 합니다.

  1. OAuth 콜백을 처리하고 인증 코드를 교환하는 API 경로

  2. 연결을 검증하고 도구를 실행하며 토큰을 갱신하는 워크스페이스 런타임 경로

이 경로들은 서로 다른 Notion 송신 주소를 사용할 수 있습니다. 최초 토큰 교환에 사용된 주소만 허용하면 로그인은 성공해도 검증이나 토큰 갱신에 실패할 수 있습니다. Notion의 현재 승인된 송신 범위를 사용하세요. 브라우저나 로그에서 확인한 일회성 IP 주소를 프로덕션 허용 항목 목록에 추가하지 마세요.

이 네트워크 정책은 개별 사용자가 아닌 OAuth 통합에 연결하세요. 브라우저 로그인, VPN 접속 또는 사용자 네트워크 접근에 적용되는 계정 전체 정책은 변경하지 마세요. 네트워크 정책이 토큰 요청을 차단하면 Snowflake에서 invalid_client를 반환할 수 있습니다. 이 오류가 반드시 클라이언트 ID나 시크릿이 잘못되었다는 의미는 아닙니다.

보안이 유지되는 Snowflake 워크시트에서 이를 실행하세요. 통합 이름은 대소문자를 구분하며 일반적으로 대문자로 표기됩니다.

승인된 보안 채널을 통해 클라이언트 ID와 해당 시크릿을 Notion 워크스페이스 관리자와 공유하세요. Snowflake에서는 유효한 시크릿 두 개를 제공하므로 서비스 중단 없이 시크릿을 교체할 수 있습니다. 두 시크릿 중 어느 것도 문서, 채팅, 티켓 또는 소스 코드 관리 시스템에 붙여넣지 마세요.

워크스페이스에서 구성한 MCP 연결은 현재 알파 단계의 기능입니다.

워크스페이스에 아직 해당 기능의 사용 권한이 없다면 고객사 담당팀에 문의하거나 데이터 에이전트 얼리 액세스 프로그램에 신청하세요.

Snowflake 설정이 완료되면 워크스페이스 소유자나 관리자가 워크스페이스에 서버를 한 번만 추가하면 됩니다. 그러면 멤버들은 Snowflake MCP를 커스텀 에이전트에 연결하든 자신의 Notion 에이전트에 연결하든 OAuth 클라이언트 시크릿을 확인하지 않고도 서버를 찾을 수 있습니다.

  1. 워크스페이스의 설정으로 이동하세요.

  2. 연결 → 워크스페이스 공유 MCP를 선택하세요.

  3. 새 워크스페이스 MCP를 선택하세요.

다음 필드를 입력한 후 MCP 서버 추가를 선택하세요.

필드

입력할 내용

이름

멤버에게 표시될 명확한 이름(예: 회사 Snowflake 데이터 에이전트)

설명

데이터와 데이터의 사용 목적에 대한 간단한 설명.

서버 URL

워크시트에 표시된 정확한 Snowflake 공개 MCP URL.

인증 수동 설정

활성화하세요. Notion에서 Snowflake의 OAuth 설정 정보를 자동으로 찾습니다.

워크스페이스 공유 OAuth 클라이언트 사용

활성화하세요.

리디렉션 URI

Notion에서 생성한 값입니다. Snowflake 관리자에게 전달한 URI와 일치하는지 확인하세요.

클라이언트 ID

Snowflake OAuth 통합에서 가져온 클라이언트 ID입니다.

클라이언트 시크릿

승인된 보안 채널을 통해 전달받은 해당 시크릿입니다.

OAuth 범위

정확한 session:role:<mcp_access_role> 범위를 선택하세요. Snowflake에서 승인된 해당 범위 하나만 제공하고 더 넓은 범위는 제공하지 않는 경우에만 모든 범위를 선택해도 됩니다.

저장한 후 이 워크스페이스와 공유됨 아래에 새 행이 나타나고 워크스페이스 OAuth 클라이언트가 구성됨으로 표시되는지 확인하세요.

이 설정의 기능:

  • 멤버가 승인된 서버를 찾을 수 있도록 지원합니다.

  • OAuth 클라이언트 시크릿을 Notion의 암호화된 연결 저장소에 한 번만 저장합니다.

  • 멤버들이 승인된 서버 URL, 클라이언트, 범위를 사용하여 로그인하도록 합니다.

  • 공유 Snowflake 세션을 생성하거나 Snowflake의 사용 권한 제어를 우회하지 않습니다.

  • 모든 멤버를 자동으로 연결하지 않습니다. 각 멤버는 개별적으로 로그인해야 합니다.

이 설정을 제거하면 새 멤버는 더 이상 서버를 찾을 수 없습니다. 기존 연결이 계속 표시될 수 있으므로 이 변경 사항은 Snowflake 권한을 회수하고 기존 연결을 제거하는 작업과 함께 진행하세요.

관리자가 Snowflake MCP 연결 설정을 완료하면 두 가지 방법으로 사용할 수 있습니다. 팀을 위해 설정하는 경우 11A부터 시작하세요. 개인적으로 질문하는 데 사용하려면 11B로 건너뛰세요. 두 가지 방법을 모두 사용할 수도 있으며, 각각 별도의 연결입니다.

커스텀 에이전트를 사용하면 팀원들이 한곳에서 Snowflake 데이터에 대해 질문할 수 있습니다. Snowflake를 한 번 연결한 후 지표와 표에 대한 에이전트 지침을 추가한 다음, 에이전트를 팀과 공유하세요. 에이전트를 사용하는 모든 사람은 각자의 인증 정보로 Snowflake에 로그인해야 합니다. 따라서 각자 사용 권한이 있는 데이터에 기반한 답변만 받을 수 있습니다.

커스텀 에이전트의 사용자별 인증 기능은 현재 알파 단계입니다.

워크스페이스에 아직 해당 기능의 사용 권한이 없다면 고객사 담당팀에 문의하거나 데이터 에이전트 얼리 액세스 프로그램에 신청하세요.

커스텀 에이전트에 Snowflake 연결하기

  1. 커스텀 에이전트를 열거나 새 에이전트를 만드세요.

  2. 설정 → 도구 및 사용 권한으로 이동하세요.

  3. 연결 추가를 선택한 다음 워크스페이스 관리 대상이라고 표시된 Snowflake 서버를 선택하세요. 사용자 지정 MCP 서버를 선택하거나 서버 URL을 직접 입력하지 마세요.

  4. 브라우저에서 Snowflake에 로그인하세요. 조직에서 평소 사용하는 Okta 또는 SSO(통합 로그인) 로그인 화면이 나타날 수 있습니다.

  5. 요청된 Snowflake 역할을 검토하고 승인하세요.

  6. 에이전트가 사용할 도구를 선택하세요. 쓰기 기능이 있는 도구와 CORTEX_AGENT_RUN은 테스트를 마칠 때까지 승인 요청으로 설정해 두세요.

  7. 연결을 선택하고 연결 상태가 연결됨으로 표시되는지 확인하세요.

에이전트에 컨텍스트 제공하기

이 연결을 통해 에이전트는 Snowflake 사용 권한을 얻습니다. 에이전트 지침은 회사에서 해당 데이터를 어떻게 사용하는지 에이전트에 알려주는 역할을 합니다. 에이전트 지침에 어떤 유형의 질문에 어떤 도구를 사용할지, 팀에서 핵심 지표를 어떻게 정의하는지, 어떤 표나 시맨틱 뷰를 먼저 참조해야 하는지를 설명하세요. 검증된 질문 예시 몇 개만 추가해도 큰 도움이 됩니다. 바로 시작하려면 Data Scout 툴킷 가이드를 참고하세요.

에이전트 공유

다른 커스텀 에이전트를 공유할 때와 같은 방법으로 에이전트를 팀과 공유하세요. 팀원이 처음으로 Snowflake가 필요한 질문을 하면 자신의 Snowflake 계정으로 로그인하라는 메시지가 표시됩니다. 클라이언트 ID나 시크릿을 입력할 필요는 없습니다.

사용자별 인증은 사용자가 에이전트와 직접 채팅하는 경우에 적용됩니다.

예약 실행과 트리거 실행에는 로그인한 사용자가 없으므로, 아직 어떤 사용자의 Snowflake 사용 권한도 사용할 수 없습니다. 일정에 따라 Snowflake 데이터를 사용해야 한다면 설정하기 전에 Snowflake 관리자와 상의하세요.

내 채팅에서 직접 질문하고 싶다면 Notion Agent에 Snowflake를 연결하세요. 내 Snowflake 계정으로 로그인하므로 에이전트는 본인이 볼 수 있는 데이터에만 접근할 수 있습니다.

  1. 설정 → Notion AI로 이동하세요.

  2. MCP 서버에서 MCP 서버 추가를 선택하세요.

  3. 워크스페이스 관리 대상이라고 표시된 Snowflake 서버를 선택하세요. 사용자 지정 MCP 서버를 선택하거나 서버 URL을 직접 입력하지 마세요.

  4. 연결을 선택하세요.

  5. 브라우저에서 Snowflake에 로그인하세요. 조직에서 평소 사용하는 Okta 또는 SSO(통합 로그인) 로그인 화면이 나타날 수 있습니다.

  6. 요청된 Snowflake 역할을 검토하고 승인하세요.

  7. 브라우저에서 Notion을 열 것인지 묻는 메시지가 표시되면 Notion 열기를 선택하세요.

  8. 서버 상태가 인증 필요가 아닌 연결됨으로 표시되는지 확인하세요.

연결을 완료하면 채팅의 모든 소스 → MCP 서버에 Snowflake가 표시됩니다.

어느 방법을 택해도 OAuth 클라이언트 ID나 시크릿을 입력하라는 요청이 표시되지 않아야 합니다.

Notion에서 둘 중 하나를 입력하라는 요청이 표시된다면 워크스페이스 관리 대상 서버 대신 사용자 지정 MCP 옵션을 선택했거나, 관리자가 워크스페이스 공유 OAuth 클라이언트 사용을 활성화하지 않았을 수 있습니다. 이전 단계로 돌아가 워크스페이스 관리 대상 서버를 선택하세요.

  1. Snowflake를 사용해 답할 수 있고 정답을 이미 알고 있는 안전한 질문을 해 보세요.

  2. 에이전트가 Snowflake를 사용하여 결과를 반환하는지 확인하세요.

  3. 부여받은 역할의 권한 범위를 벗어나는 데이터에 접근할 수 없는지 확인하세요.

커스텀 에이전트를 설정했다면 Snowflake 역할의 사용 권한이 더 제한적인 팀원에게도 사용해 보도록 요청하세요. 해당 팀원은 여러분이 아닌 자신의 사용 권한으로 접근할 수 있는 데이터만 볼 수 있어야 합니다. 이는 에이전트가 빌더가 아닌 각 사용자의 사용 권한을 적용하는지 확인하는 가장 빠른 방법입니다.

더 자세히 확인하려면 Snowflake 관리자에게 사용자 계정과 역할, 웨어하우스, 쿼리 기록을 확인해 달라고 요청하세요. 로그인에 성공하면 사용자의 신원은 확인되지만, 부여된 모든 권한이 올바르다는 뜻은 아닙니다.

에이전트에 Snowflake 데이터에 관한 구체적인 질문을 해 보세요. 예를 들어 이렇게 물어보세요.

  • “Snowflake에서 지난달 총 가입자 수는 얼마였어?”

  • “Snowflake에서 이번 분기 매출이 가장 높은 고객 계정 10개는 뭐야?"

커스텀 에이전트의 지침에 Snowflake를 언제 사용해야 하는지 명확히 설명되어 있다면 질문할 때 'Snowflake에서'라는 표현을 대부분 생략해도 됩니다. 반면 Notion 에이전트에서는 Snowflake를 언급하면 에이전트가 올바른 소스를 선택하는 데 도움이 됩니다.

요청 범위가 넓으면 처리 시간이 길어지거나 시간 초과가 발생할 수 있습니다. 이런 경우 질문 범위를 좁히거나 요청을 여러 개의 작은 질문으로 나눠 보세요.

대부분의 경우 별도의 조치를 취하지 않아도 연결이 유지됩니다. Snowflake는 유효 기간이 짧은 액세스 토큰을 사용하고, Notion은 백그라운드에서 토큰을 갱신합니다. 따라서 액세스 토큰의 만료만으로는 연결이 끊어지지 않습니다.

다음과 같은 경우에는 다시 로그인해야 합니다.

  • 갱신 토큰이 만료되거나 관리자가 갱신 토큰을 취소한 경우

  • 관리자가 OAuth 통합 또는 클라이언트 시크릿을 교체한 경우

  • Snowflake 역할이 제거된 경우

  • 관리자가 워크스페이스 설정 또는 사용자의 연결을 제거한 경우

  • 네트워크 정책으로 인해 토큰 갱신이 차단된 경우

커스텀 에이전트에서는 각 사용자가 개별적으로 로그인합니다. 한 사용자에게 다시 로그인하라는 안내가 표시되더라도 다른 사용자에게는 영향을 미치지 않으며, 에이전트를 만든 사람도 별도의 조치를 취할 필요가 없습니다.

클라이언트 시크릿을 교체할 때 통합을 교체하는 대신 Snowflake의 두 시크릿을 이용한 교체 방식을 사용하세요. 기존 시크릿을 폐기하기 전에 워크스페이스 설정을 업데이트하고 테스트할 수 있도록 두 시크릿을 충분한 기간 동안 모두 유효하게 유지하세요.

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

  • Snowflake MCP 연결이 리스트에 표시되지 않습니다. 워크스페이스 관리자가 아직 연결을 추가하지 않았거나 워크스페이스에서 사용자 지정 서버 사용을 제한했을 수 있습니다. 관리자에게 도움을 요청하세요.

  • 클라이언트 ID나 시크릿을 입력하라는 안내가 표시됩니다. 사용자 지정 MCP 옵션을 선택했을 가능성이 높습니다. 이전 단계로 돌아가 워크스페이스 관리 대상으로 표시된 Snowflake 서버를 선택하세요.

  • 다시 로그인하라는 안내가 표시됩니다. Snowflake 세션이 만료되었거나 관리자가 연결을 업데이트했을 수 있습니다. Snowflake에 다시 로그인하세요.

  • 커스텀 에이전트를 열었더니 Snowflake에 로그인하라는 안내가 표시됩니다. 처음 사용할 때는 해당 안내가 표시되는 것이 정상입니다. 관리 대상 커스텀 에이전트를 사용하는 각 사용자는 자신의 Snowflake 인증 정보로 로그인해야 합니다.

  • 팀원이 동일한 커스텀 에이전트에서 다른 결과를 받습니다. 이는 정상입니다. 에이전트는 각 사용자의 Snowflake 사용 권한을 적용하므로 역할이 다르면 보이는 데이터도 다릅니다.

  • 커스텀 에이전트가 채팅에서는 작동하지만 예약 실행에서는 작동하지 않습니다. 예약 실행과 트리거 실행에는 로그인한 사용자가 없으므로, 아직 사용자별 로그인을 통해 Snowflake를 사용할 수 없습니다.

  • 로그인했지만 연결되지 않거나 도구가 작동하지 않습니다. 로그인하면 사용자의 신원은 확인되지만, 실제 사용 권한은 여전히 Snowflake에서 부여받은 권한에 따라 결정됩니다. Snowflake 관리자에게 내 역할로 서버, 웨어하우스, 에이전트, 데이터에 접근할 수 있는지 확인해 달라고 요청하세요.

  • 에이전트가 표를 찾지 못합니다. 사용자의 Snowflake 계정으로 접근할 수 있는 데이터에만 접근할 수 있습니다. Snowflake 사용 권한을 확인하고 질문에 표 이름을 포함하세요.

  • 요청 시간이 초과됩니다. 더 구체적으로 질문하거나 요청을 여러 개의 작은 질문으로 나누세요.

이러한 오류는 일반적으로 Notion이 아닌 Snowflake 설정에서 발생합니다. Snowflake 관리자에게 오류 내용을 공유하세요.

  • 서버 URL이 https://https%3A...와 같이 중복되어 표시됩니다. 주소를 붙여넣을 때 앞에 https://가 한 번 더 추가되었습니다. URL 시작 부분에 https://가 하나만 있도록 수정하세요.

  • ‘이 서버는 OAuth 인증을 지원하지 않습니다.’라는 메시지가 표시됩니다. 보안 통합이 OAuth용으로 설정되지 않았거나 서버 URL이 잘못되었습니다. Snowflake 관리자에게 OAuth 보안 통합과 서버 URL을 확인해 달라고 요청하세요.

  • 로그인하거나 갱신하는 중에 invalid_client 메시지가 표시됩니다. 클라이언트 ID나 시크릿이 잘못되었거나 시크릿이 변경되었습니다. 관리자에게 현재 사용 중인 클라이언트 ID와 시크릿을 요청하세요.

  • 로그인에 성공했지만 곧바로 연결이 끊어집니다. 내 역할로 서버에 접근할 수 없거나 역할 또는 네트워크 규칙이 세션을 차단하고 있을 수 있습니다. 관리자에게 부여된 권한과 정책을 확인해 달라고 요청하세요.

  • '요청한 역할 ALL이 명시적으로 차단되었습니다.'라는 메시지가 표시됩니다. 연결 시 모든 역할을 한꺼번에 요청(session:role:all)했지만 이 요청이 차단되었습니다. 대신 session:role:analyst처럼 실제 역할 이름을 지정해 특정 역할 하나만 사용하세요.

  • 리디렉션 오류(오류 390307)가 표시됩니다. Snowflake에 저장된 리디렉션 URL이 Notion에서 사용하는 URL과 일치하지 않습니다. 관리자에게 보안 통합의 리디렉션 URL을 Notion에서 사용하는 값과 정확히 일치하도록 설정해 달라고 요청하세요.

  • 유효하지 않은 코드 챌린지와 관련된 오류 390311이 표시됩니다. PKCE가 일치하지 않아 발생하는 오류입니다. 관리자에게 보안 통합에서 OAUTH_ENFORCE_PKCE가 올바르게 설정되었는지 확인해 달라고 요청하세요.

  • 연결되었지만 도구가 표시되지 않습니다. 내 역할에 MCP 서버의 USAGE 권한이 없을 수 있습니다. 관리자에게 권한 부여를 확인해 달라고 요청한 다음, DESCRIBE MCP SERVER를 실행해 설정을 확인하세요.

  • 예상보다 접근할 수 있는 데이터가 많거나 적습니다. 부차적 역할에 따라 세션에서 볼 수 있는 데이터가 달라집니다. 관리자에게 문의해 세션에서 활성화된 역할을 확인하세요.

  • 이전에는 정상적으로 작동했지만 시크릿이 변경된 후에는 모든 사용자가 연결할 수 없습니다. 클라이언트 시크릿이 교체되어 저장된 연결 정보가 최신 상태가 아닙니다. 관리자에게 새 시크릿을 요청한 다음 다시 연결하세요.

  • 이전에는 작동했지만 이제 나만 연결이 되지 않습니다. 역할이나 부여된 권한, 정책이 변경되었거나 세션이 만료되었을 수 있습니다. 다시 로그인한 다음 관리자에게 내 사용 권한이 변경되지 않았는지 확인해 달라고 요청하세요.

  • 계정 식별자가 거부되었습니다.myorg-myaccount처럼 점 대신 하이픈을 사용하는 organization-account 형식으로 입력하세요.

  • PrivateLink 계정이 연결되지 않습니다. PrivateLink 계정에는 추가 네트워크 설정이 필요합니다. 관리자에게 PrivateLink에서 Notion 연결을 허용하는지 확인해 달라고 요청하세요.

  • 예약 실행이나 트리거 실행에서는 Snowflake를 사용할 수 없습니다. 이러한 실행에는 로그인한 사용자가 없으므로, 아직 사용자별 로그인을 사용할 수 없습니다. 대신 채팅에서 요청을 실행하세요.

  • 브라우저에서 로그인한 후 oauth_security_error 오류가 표시됩니다. 계정 수준의 네트워크 정책이 요청을 차단하고 있을 수 있습니다. 관리자는 다음을 실행하여 이를 확인할 수 있습니다.

  • 로그인은 되는 것 같지만 올바른 범위를 사용해도 역할 오류가 발생합니다. 기본 역할이 차단되었을 수 있습니다. 예를 들어 ACCOUNTADMIN이나 BLOCKED_ROLES_LIST에 포함된 역할이 차단되었을 수 있습니다. 관리자는 다음 방법으로 문제를 확인하고 해결할 수 있습니다.

다음 읽기 전용 명령어를 사용하면 관리자가 설정을 변경하지 않고도 설정 상태를 확인할 수 있습니다. Snowflake에서 실행하세요.

ACCOUNT_USAGE 뷰는 데이터 반영이 늦어질 수 있으므로, 해당 행이 보이지 않는다고 해서 요청이 없었다고 단정할 수는 없습니다.

어떤 계층에서 오류가 발생하는지 확인하기 전까지는 시크릿을 교체하거나 정책을 완화하거나 권한 범위를 넓히지 마세요.

다음 Snowflake 가이드를 참고하여 설정을 완료하세요.


자주 묻는 질문(FAQ)

커스텀 에이전트를 설정해야 하나요, 아니면 Snowflake를 Notion 에이전트에 연결해야 하나요?

팀을 위해 Snowflake MCP 연결을 설정한다면 커스텀 에이전트를 만드세요. 그러면 모든 팀원이 같은 에이전트 지침과 지표 정의를 공유하고 한곳에서 질문할 수 있습니다. 동시에 각 사용자는 자신의 Snowflake 인증 정보로 로그인합니다. 개인적으로 질문하는 용도로만 사용하려면 Snowflake MCP를 자신의 Notion 에이전트에 연결하세요. 두 가지 방법을 모두 사용할 수도 있습니다.

Snowflake를 Notion 에이전트에 연결하면 팀의 커스텀 에이전트에도 연결되나요?

아니요. 각각 별도의 연결이며, 커스텀 에이전트마다 개별적으로 연결해야 합니다. 1~10단계의 Snowflake 설정은 공유되지만, 로그인은 각자 해야 합니다.

팀원 모두가 같은 데이터를 볼 수 있나요?

아니요. 각 사용자는 자신의 Snowflake 인증 정보로 로그인하며, 에이전트는 해당 계정에 사용 권한이 있는 데이터에만 접근할 수 있습니다. 커스텀 에이전트도 마찬가지입니다.

팀과 Snowflake 비밀번호를 공유해야 하나요?

아니요. 누구도 인증 정보를 공유하지 않습니다. OAuth 클라이언트 정보는 워크스페이스에 한 번 저장되며, 각 사용자는 Snowflake에 개별적으로 로그인합니다.


피드백 보내기

이 내용이 도움이 되었나요?