Notion용 Snowflake MCP 설정하기

커스텀 에이전트와 Notion 에이전트는 Snowflake가 실행하는 MCP(MCP) 서버를 통해 Snowflake에 연결할 수 있습니다. 설정이 완료되면 에이전트에게 Snowflake 웨어하우스 데이터에 대해 질문하고 Notion에서 직접 답변을 받을 수 있습니다.

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

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

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

• 워크스페이스 멤버는 자신의 Snowflake 자격 증명을 사용하여 커스텀 에이전트에서 Snowflake MCP에 연결하거나, Snowflake를 Notion 에이전트에 직접 연결할 수 있습니다. 이 문서의 1~10단계는 두 경로 모두 동일합니다. 11단계부터는 연결하려는 에이전트에 따라 경로가 나뉩니다.

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

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

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

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

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

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

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

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

시작하기 전에 Notion 워크스페이스 관리자와 함께 이 워크시트를 작성하세요. 설정이 완료되면 멤버는 이 단계를 건너뛰고 자신의 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와 함께 허용하지 않으므로, 이 모델을 사용할 때는 ALLOWED_ROLES_LIST를 생략하세요.

가능한 경우 MCP 서버에 전용의 최소 권한 역할을 사용하세요.

일반적인 ID 관리 프로세스를 통해 이 역할을 부여하세요. Okta 또는 SCIM이 Snowflake 역할 멤버십을 관리하는 경우, 해당 프로세스 외부에서 수동으로 사용자를 추가하지 마세요.

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

관리되는 비즈니스 질문의 경우, 멤버가 사용하는 도구로 Cortex 에이전트를 노출할 수 있습니다. 이를 통해 의미론적 뷰, 검증된 쿼리, 검색 및 오케스트레이션을 한곳에서 유지할 수 있습니다. Cortex 에이전트는 선택 항목입니다. 생성하는 경우 아래 사양을 사용하세요. 기존 에이전트를 교체하는 경우, 교체할 에이전트가 승인된 사양과 일치하는지 확인하세요.

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

각 도구에 명확한 이름과 설명을 지정하세요. 도구가 다루는 데이터, 결과의 상세 수준 및 사용 시기를 설명하세요. 이는 에이전트가 올바른 도구를 선택하는 데 도움이 됩니다.

MCP 서버의 USAGE 권한을 사용하면 역할이 서버에 연결하여 도구를 검색할 수 있습니다. 이 권한은 역할에 웨어하우스, 에이전트, 의미론적 뷰, 검색 서비스, 저장 프로시저 또는 기본 데이터에 대한 사용 권한을 부여하지 않습니다. 서버 도구에 필요한 각 리소스에 대해 역할에 사용 권한을 부여하십시오.

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

OAuth를 설정하기 전에 MCP 서버와 해당 권한을 확인하십시오:

멤버가 요청해야 하는 정확한 역할을 알리도록 MCP 스키마를 구성하십시오:

명시적 역할 범위를 사용하십시오. session:role:all은 사용하지 마십시오. Snowflake는 해당 값을 모든 역할에 대한 사용 권한이 아닌 사용자의 기본 역할로 취급하며, 권한 있는 역할에 대한 정책이 이를 차단할 수 있습니다. 명시적 역할을 사용하면 요청된 사용 권한이 명확해지고 확인하기가 더 쉬워집니다.

이 SQL을 실행하기 전에 Notion 워크스페이스 관리자와 협의하십시오. 워크스페이스 MCP 설정 양식에 Snowflake 서버 URL을 입력하고 Manually configure authentication 및 Use a workspace-shared OAuth client를 켜도록 요청하십시오. 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의 현재 송신(egress) 범위를 승인해 달라고 요청하십시오.

OAuth 통합은 다음 두 Notion 경로를 모두 허용해야 합니다:

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

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

이 경로들은 서로 다른 Notion 송신 주소를 사용할 수 있습니다. 초기 토큰 교환 중에 사용된 주소만 허용하면 로그인은 성공할 수 있지만 검증이나 토큰 새로 고침은 실패할 수 있습니다. Notion의 현재 승인됨 송신 범위를 사용하십시오. 브라우저나 로그에서 가져온 일회성 IP 주소를 프로덕션 허용 항목 목록에 추가하지 마십시오.

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

보안 Snowflake 워크시트에서 이를 실행하십시오. 통합 이름은 대소문자를 구분하며 일반적으로 대문자입니다:

승인된 보안 채널을 사용하여 Notion 워크스페이스 관리자와 클라이언트 ID 및 일치하는 비밀을 공유하십시오. Snowflake는 두 개의 유효한 비밀을 제공하므로 가동 중지 시간 없이 교체할 수 있습니다. 비밀을 문서, 채팅, 티켓 또는 소스 제어에 붙여넣지 마십시오.

Snowflake가 준비되면 워크스페이스 소유자나 관리자 중 한 명이 워크스페이스에 서버를 한 번 추가합니다. 그러면 멤버는 Snowflake MCP를 커스텀 에이전트에 연결하든 자신의 Notion 에이전트에 연결하든 관계없이 OAuth 클라이언트 시크릿을 보지 않고도 이를 찾을 수 있습니다.

1. 워크스페이스에 대한 Settings로 이동합니다.

2. 연결 → 워크스페이스 공유된 MCPs를 선택합니다.

3. New 워크스페이스 MCP을(를) 선택합니다.

이 필드를 채운 다음 MCP 서버 추가를 선택합니다:

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

이 설정의 기능:

• 멤버들이 승인된 서버를 찾을 수 있도록 돕습니다.

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

• 멤버들이 귀하가 승인한 서버 URL, 클라이언트 및 범위로 로그인하도록 합니다.

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

• 모든 멤버를 자동으로 연결하지 않습니다. 각 사용자가 별도로 로그인해야 합니다.

이 설정을 제거하면 새 멤버는 더 이상 서버를 찾을 수 없습니다. 기존 연결은 계속 표시될 수 있으므로, 이 변경 사항을 Snowflake 권한 취소 및 기존 연결 제거와 조정하세요.

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

커스텀 에이전트는 팀이 Snowflake 데이터에 대해 질문할 수 있는 단일 창구를 제공합니다. Snowflake를 한 번 연결하고, 지표와 표에 대한 에이전트 지침을 추가한 다음, 에이전트를 팀과 공유하면 됩니다. 에이전트를 사용하는 모두는 자신의 인증서로 Snowflake에 로그인해야 하므로, 각 사용자는 자신이 볼 수 있는 데이터에 기반한 답변만 얻게 됩니다.

Snowflake를 커스텀 에이전트에 연결

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

2. 설정 → 도구 및 사용 권한으로 이동합니다.

3. 연결 추가를 선택한 다음 Workspace Managed라고 표시된 Snowflake 서버를 선택합니다. 커스텀 MCP 서버를 선택하거나 서버 URL을 수동으로 입력하지 마세요.

4. 브라우저에서 Snowflake에 로그인합니다. 조직에서 사용하는 일반적인 Okta 또는 SSO 로그인 화면이 나타날 수 있습니다.

5. 요청된 Snowflake 역할을 검토하고 승인합니다.

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

7. 연결을 선택하고 연결 상태가 Connected로 표시되는지 확인합니다.

에이전트에 컨텍스트 제공

연결을 통해 에이전트는 Snowflake에 대한 사용 권한을 얻게 됩니다. 지침을 통해 에이전트에게 회사에서 해당 데이터를 어떻게 사용하는지 알려주세요. 에이전트 지침에 어떤 질문에 어떤 도구를 사용해야 하는지, 팀에서 주요 지표를 어떻게 정의하는지, 어떤 표나 의미론적 뷰(semantic view)부터 시작해야 하는지 설명하세요. 검증된 몇 가지 질문 예시를 제공하면 큰 도움이 됩니다. 바로 사용할 수 있는 시작 지점은 Data Scout 툴킷 가이드를 참조하세요.

에이전트 공유

다른 커스텀 에이전트를 공유하는 것과 동일한 방식으로 팀과 에이전트를 공유하세요. Snowflake가 필요한 질문을 처음 할 때, 사용자는 자신의 Snowflake 계정으로 로그인하라는 메시지를 받게 됩니다. 클라이언트 ID나 비밀/시크릿을 묻는 메시지는 표시되지 않습니다.

자신의 채팅에서 직접 질문하고 싶다면 Notion 에이전트에 Snowflake를 연결하세요. 본인의 Snowflake 계정으로 로그인하므로, 에이전트는 본인이 볼 수 있는 데이터만 조회합니다.

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

2. MCP 서버 아래에서 MCP 서버 추가를 선택합니다.

3. Workspace Managed라고 표시된 Snowflake 서버를 선택합니다. Custom MCP server를 선택하거나 서버 URL을 수동으로 입력하지 마세요.

4. 연결을 선택합니다.

5. 브라우저에서 Snowflake에 로그인합니다. 조직에서 사용하는 일반적인 Okta 또는 SSO 로그인 화면이 나타날 수 있습니다.

6. 요청된 Snowflake 역할을 검토하고 승인합니다.

7. 브라우저에서 Notion을 열지 묻는 메시지가 나타나면 Open Notion을 선택합니다.

8. 서버 상태가 연결됨이고, 인증 필요가 아닌지 확인하세요.

연결 후, 채팅의 모든 소스 → MCP 서버에 Snowflake가 나타납니다.

1. Snowflake를 사용해야 하는, 답을 알고 있는 무해한 질문을 하세요.

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

3. 귀하에게 부여된 역할 외부의 데이터에는 액세스할 수 없는지 확인하세요.

커스텀 에이전트를 설정한 경우, Snowflake 역할 범위가 더 좁은 팀원에게도 테스트를 요청하세요. 그 팀원은 귀하의 데이터가 아닌 자신의 데이터만 볼 수 있어야 합니다. 이것이 에이전트가 빌더의 사용 권한이 아닌 각 사용자의 사용 권한을 사용하고 있음을 확인하는 가장 빠른 방법입니다.

더 자세히 확인하려면 Snowflake 관리자에게 귀하의 사용자, 역할, 웨어하우스 및 쿼리 기록을 확인해 달라고 요청하세요. 성공적인 로그인은 신원을 확인해주지만, 모든 권한이 올바르게 부여되었는지까지 확인해주지는 않습니다.

에이전트에게 Snowflake 데이터에 관한 구체적인 질문을 하십시오. 예를 들면 다음과 같습니다.

• "Snowflake에서 지난달 총 가입자 수는 얼마였나요?"

• "Snowflake에서 이번 분기 수익이 가장 높은 계정 10개는 무엇인가요?"

커스텀 에이전트의 경우, 지침을 통해 언제 Snowflake를 사용해야 하는지 명확히 하면 보통 "Snowflake에서"라는 말을 생략할 수 있습니다. Notion 에이전트의 경우, Snowflake를 언급하면 에이전트가 올바른 출처를 선택하는 데 도움이 됩니다.

대규모 요청은 시간이 더 걸리거나 시간 초과가 발생할 수 있습니다. 그런 경우에는 더 좁은 범위의 질문을 하거나 요청을 더 작은 질문으로 나누세요.

대부분의 경우 별도의 조치 없이도 연결이 유지됩니다. Snowflake는 단기 액세스 토큰을 사용하며, Notion이 백그라운드에서 이를 새로 고칩니다. 액세스 토큰이 만료된다고 해서 바로 연결이 끊어지는 것은 아닙니다.

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

• 새로 고침 토큰이 만료되었거나 관리자가 이를 취소한 경우

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

• Snowflake 역할이 제거된 경우

• 관리자가 워크스페이스 설정을 제거했거나 연결이 해제되었습니다.

• 네트워크 정책이 토큰 새로 고침을 차단합니다.

커스텀 에이전트를 사용하면 각 사용자의 로그인이 별도로 처리됩니다. 한 사용자가 다시 로그인하라는 요청을 받더라도 다른 사용자에게는 영향을 미치지 않으며, 에이전트를 만든 사용자는 아무것도 할 필요가 없습니다.

클라이언트 비밀을 교체하는 경우: 통합을 교체하는 대신 Snowflake의 2개 비밀 교체 방식을 사용하세요. 이전 비밀을 폐기하기 전에 워크스페이스 설정을 업데이트하고 테스트할 수 있을 만큼 충분히 오랫동안 두 비밀을 모두 유효하게 유지하세요.

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

• Snowflake MCP 연결이 나열되지 않습니다. 워크스페이스 관리자가 아직 추가하지 않았거나 워크스페이스에서 커스텀 서버를 제한하고 있을 수 있습니다. 관리자에게 도움을 요청하세요.

• 클라이언트 ID 또는 비밀/시크릿을 묻는 메시지가 표시됩니다. 커스텀 MCP 옵션을 선택했을 가능성이 높습니다. 돌아가서 Workspace Managed라고 표시된 Snowflake 서버를 선택하세요.

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

• 커스텀 에이전트를 열었는데 Snowflake에 로그인하라는 메시지가 표시됩니다. 처음 사용할 때는 정상적인 현상입니다. 관리형 커스텀 에이전트를 사용하는 각 사용자는 자신의 Snowflake 자격 증명으로 로그인해야 합니다.

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

• 커스텀 에이전트가 채팅에서는 작동하지만 일정 잡기에서는 작동하지 않습니다. 일정 잡기 실행 및 트리거됨 실행에는 로그인한 사용자가 없으므로 아직 사용자별 로그인을 통한 Snowflake 사용이 불가능합니다.

• 로그인했지만 연결되지 않거나 도구가 실패합니다. 로그인은 본인임을 증명하지만, 사용 권한은 여전히 Snowflake 권한 부여에 따라 달라집니다. Snowflake 관리자에게 문의하여 귀하의 역할로 서버, 웨어하우스, 에이전트 및 데이터에 접근할 수 있는지 확인하십시오.

• 에이전트가 표를 찾을 수 없습니다. 에이전트는 귀하의 Snowflake 계정이 접근할 수 있는 데이터에만 접근할 수 있습니다. Snowflake 권한을 확인하고 질문에 표 이름을 포함하십시오.

• 요청 시간이 초과되었습니다. 더 구체적인 질문을 하거나 요청을 더 작은 질문으로 나누십시오.

이러한 오류는 일반적으로 Notion이 아닌 Snowflake 설정에서 발생합니다. Snowflake 관리자와 공유하십시오.

• 서버 URL이 https://https%3A...와 같이 중복되어 보입니다. 주소 앞에 https://가 추가로 붙여넣어졌습니다. URL이 https:// 하나로만 시작하도록 수정하십시오.

• "This server does not support OAuth authentication." 메시지가 표시됩니다. 보안 통합이 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를 실행하여 설정을 확인하십시오.

• 예상보다 많거나 적은 데이터에 액세스할 수 있습니다. 부차적 역할은 세션에서 볼 수 있는 내용을 변경합니다. 관리자와 함께 세션에서 활성화된 역할을 확인하십시오.

• 이전에는 작동했지만 이제 비밀 변경 후 모두 실패합니다. 클라이언트 비밀이 교체되어 저장된 연결이 최신 상태가 아닙니다. 관리자에게 새 비밀을 요청한 다음 다시 연결하십시오.

• 이전에는 작동했지만 이제 귀하에게만 실패합니다. 역할, 권한 또는 정책이 변경되었거나 세션이 만료되었을 수 있습니다. 다시 로그인한 다음 관리자에게 사용 권한이 변경되지 않았는지 확인하도록 요청하십시오.

• 계정 식별자가 거부되었습니다. 점(.) 대신 organization-account 형식과 같이 하이픈을 사용하여 myorg-myaccount와 같이 입력하십시오.

• PrivateLink 계정이 연결할 수 없습니다. PrivateLink 계정은 추가적인 네트워크 설정이 필요합니다. 관리자에게 PrivateLink가 Notion 연결을 허용하는지 문의하십시오.

• Snowflake는 예약된 실행이나 트리거됨 실행에서는 사용할 수 없습니다. 해당 실행에는 로그인한 사용자가 없으므로 아직 개인별 로그인을 사용할 수 없습니다. 대신 채팅에서 요청을 실행하십시오.

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

• 로그인은 작동하는 것 같지만 올바른 범위를 사용해도 역할 오류가 발생합니다. 기본 역할이 차단되었을 수 있습니다(예: ACCOUNTADMIN 또는 BLOCKED_ROLES_LIST에 포함된 역할). 관리자가 확인하고 수정할 수 있습니다:

이 읽기 전용 명령은 관리자가 설정을 변경하지 않고도 설정을 확인하는 데 도움이 됩니다. Snowflake에서 실행하십시오.

설정을 완료하려면 다음 Snowflake 가이드를 사용하십시오:

• Snowflake 관리형 MCP 서버

• Snowflake OAuth 보안 통합 생성

• 사용자 지정 클라이언트를 위한 Snowflake OAuth

• Snowflake OAuth 개요

• Snowflake 계정 식별자

• 커스텀 에이전트

• 커스텀 에이전트를 위한 MCP 연결

• MCP 서버를 Notion 에이전트에 연결하기

• 에이전트 연결을 위한 보안 모범 사례