For AI agents: a documentation index is available at /docs/llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
Snowflake 암호 인증 사용 중지 FAQ
Snowflake는 단일 요소 암호 인증을 사용하지 않도록 단계별 배포를 구현하고 있으며, 2026년 5월에 시작하여 2026년 10월까지 완료됩니다. 이 중단은 Amplitude의 모든 Snowflake 통합에 영향을 미칩니다: 소스(Snowflake에서 Amplitude로 데이터 가져오기)와 대상(Amplitude에서 Snowflake로 데이터 내보내기)입니다.
전체 공식 일정 및 시행 세부 사항은 단일 요소 암호 로그인 사용 중단에 대한 Snowflake의 계획 문서를 참조하십시오.
이 FAQ는 Amplitude 통합을 위한 키 쌍 인증으로 마이그레이션하는 것에 관한 일반적인 질문을 다룹니다.
이 변경 사항은 언제 적용됩니까?
Amplitude와 Snowflake는 조율된 일정을 따르고 있습니다:
이미 시행 중입니다.
- 2026년 2월 1일: Amplitude는 Snowflake 소스 및 대상에 대한 새로운 연결 흐름에서 암호 옵션을 제거했습니다. Snowflake 연결을 생성할 때는 새 암호 자격 증명을 입력할 수 없습니다. 기존의 비밀번호 인증 연결은 계속 작동하며, 추가 연결을 설정할 때 기존 비밀번호 자격 증명을 계속 재사용할 수 있습니다.
곧 출시 예정
- 2026년 5월: Amplitude는 기존의 암호 인증 연결을 사용하는 사용자에게 제품 내 경고를 전송하기 시작합니다.
- 2026년 5월 – 7월: Snowflake는 새로 생성된 사용자에 대해 강력한 인증 기능을 적용하기 시작합니다.
- 2026년 8월 – 10월: Snowflake는 기존 모든 사용자에게 강력한 인증을 적용합니다.
이 날짜까지 마이그레이션하지 않으면 Amplitude는 귀하의 Snowflake 연결을 끊지 않습니다. 하지만 Snowflake는 암호 기반 로그인을 차단하려고 합니다. 이로 인해 Amplitude 소스와 대상이 작동하지 않습니다.
이제 어떻게 해야 할까요?
소스와 대상 모두의 모든 Snowflake 연결을 키 쌍 인증으로 즉시 마이그레이션하여 다음을 수행할 수 있습니다.
- Snowflake가 강력한 인증을 적용할 때 서비스 중단을 방지하십시오.
- 보안 강화.
- 향후 호환성을 보장합니다.
어디에서 도움을 받을 수 있습니까?
마이그레이션 중에 문제가 발생하는 경우:
- 일반적인 채널을 통해 Amplitude 서포트에 문의하십시오.
- Snowflake의 키 쌍 인증 문서를 참조하십시오.
- 계정 이름이 해당
ORGNAME-ACCOUNTNAME형식을 따르는지 확인하십시오.
이 문제가 Snowflake 소스와 대상 모두에 영향을 미칩니까?
예. Snowflake 소스(Snowflake에서 Amplitude로 가져오기)와 Snowflake 대상(Amplitude에서 Snowflake로 내보내기)은 모두 키 쌍 인증으로 마이그레이션해야 합니다.
마이그레이션 다음 기간동안 전체 데이터가 손실됩니까?
아니요. 인증 방법을 변경해도 다음에는 영향을 주지 않습니다.
- 기존의 가져오거나 내보낸 데이터입니다.
- 구성을 가져오기 및 내보내기합니다.
- 예약된 데이터 동기화.
- 데이터 매핑.
마이그레이션할 경우 중복 데이터가 발생합니까?
아니요. 마이그레이션은 인증 방법만 변경합니다. 소스 및 목적지 구성은 동일하게 유지됩니다.
내 쿼리 또는 구성을 다시 작성해야 합니까?
아니요. 마이그레이션은 모든 구성을 유지합니다.
- SQL 쿼리.
- 테이블 선택 사항.
- 열 매핑입니다.
- 일람표를 가져오기 및 내보내기합니다.
마이그레이션 다음 기간동안 가져오기 또는 내보내기가 중단됩니까?
아니요. 데이터 동기화는 중단 없이 계속됩니다. 기존 연결을 업데이트할 때의 일반적인 흐름은 다음과 같습니다.
- 소스 또는 목적지에 대한 연결 설정을 엽니다.
- 키 쌍 인증으로 전환하고 키를 생성합니다.
- Snowflake에 공개 키를 적용합니다.
- 연결을 확인하십시오.
- 저장하십시오.
이 프로세스 내내 귀하의 가져오기 및 내보내기가 계속됩니다.
동일한 Snowflake 사용자를 사용할 수 있습니까?
예. Amplitude는 다음과 같이 권장합니다:
- 동일한 Snowflake 사용자를 유지합니다.
- 기존 소스 또는 목적지에 대한 연결 설정을 통해 키 쌍 인증을 추가합니다.
- 새 자격 증명이 작동하는지 확인한 후 암호 인증을 제거합니다.
소스와 목적지 대상 구간 자격 증명을 공유할 수 있습니까?
예. Amplitude는 조직의 모든 Snowflake 연결에서 자격 증명 재사용을 지원합니다.
- 소스는 대상의 자격 증명을 사용할 수 있으며 그 반대의 경우도 마찬가지입니다.
- 동일한 조직에 있는 여러 Amplitude 프로젝트 간의 연결은 자격 증명을 공유할 수 있습니다.
자격 증명 재사용은 키 쌍 인증으로 마이그레이션할 때 도움이 됩니다. 각 연결에 대해 새 키 쌍을 생성하는 대신, 하나의 키 쌍을 생성하여 Snowflake 소스 및 목적지 전반에서 재사용할 수 있습니다.
Snowflake 소스 및 목적지에는 서로 다른 Snowflake 사용자 권한 관리가 필요합니다. 즉, 소스 읽기 권한이 필요하고 목적지는 쓰기 권한이 필요합니다. 소스와 목적지 대상 구간 자격 증명을 공유하는 경우, Snowflake 사용자가 두 가지 모두에 필요한 권한 관리를 갖고 있는지 확인하십시오.
여러 연결에서 공유되는 자격 증명을 업데이트하면 어떻게 됩니까?
여러 개의 Snowflake 연결이 동일한 자격 증명을 공유하는 경우 한 연결에 대한 자격 증명을 업데이트하면 모든 연결이 업데이트됩니다. Amplitude는 연결 설정을 볼 때 자격 증명을 공유하는 연결의 수를 보여주므로 저장하기 전에 업데이트의 범위를 확인할 수 있습니다.
한 번에 하나씩 연결을 마이그레이션할 수 있습니까?
예. 다음과 같은 작업을 수행할 수 있습니다.
- 소스와 대상을 개별적으로 마이그레이션합니다.
- 다음 마이그레이션을 진행하기 전에 각 마이그레이션을 테스트하십시오.
- 암호와 키 쌍 인증을 일시적으로 혼합하여 유지하십시오.
소스와 대상 대상 구간 사용 권한 차이는 무엇입니까?
Snowflake 소스(가져오기)에는 Snowflake 데이터를 쿼리하려면 읽기 권한 관리가 필요합니다. Snowflake 대상(내보내기)에는 데이터를 웨어하우스에 로드하기 위한 쓰기 권한 관리가 필요합니다. 소스 목적지 대상 구간 자격 증명을 공유하는 경우, Snowflake 사용자에게 읽기 및 쓰기 작업 모두에 필요한 모든 권한 관리가 있는지 확인하십시오.
서비스 계정 대신 개인 Snowflake 계정은 어떻습니까?
Amplitude는 Snowflake 연결에 대한 MFA를 지원하지 않습니다. 연결에 사람의 Snowflake 사용자 계정을 사용하는 경우 다음 중 하나를 수행해야 합니다.
- Snowflake 서비스 계정으로 전환하고 키 쌍 인증을 구성합니다.
- 기존 인간 계정에 키 쌍 인증을 추가하십시오(Snowflake는 단일 사용자에 대해 MFA와 키 쌍을 모두 허용합니다).
대부분의 Amplitude 고객은 Snowflake 연결을 위해 전용 서비스 계정을 사용합니다.
키 페어 인증을 위해 새 Snowflake 사용자를 생성해야 합니까?
그럴 필요는 없습니다. 기존 Snowflake 사용자를 사용하고 키 쌍 인증을 추가하십시오.
- 기존 Snowflake 사용자를 사용하십시오.
- 단일 키 쌍을 생성하여 모든 Snowflake 소스와 대상에서 이를 재사용하세요.
- 모든 연결이 새 키 쌍으로 작동하는지 확인한 후에만 암호 인증을 제거하십시오.
기존 연결에 대한 키 쌍 인증을 설정하려면 어떻게 해야 합니까?
이 프로세스는 소스와 대상 모두에 대해 동일합니다.
기존 Snowflake 소스 또는 목적지에 대한 연결 설정을 엽니다.
- 소스의 경우: _데이터 > 소스_로 이동하여 소스를 선택한 다음 해당 설정을 엽니다.
- 목적지의 경우: _데이터 > 목적지_로 이동하여 목적지를 선택한 다음 해당 설정을 엽니다.
키 쌍 인증을 선택합니다.
키 생성을 클릭하여 새 키 쌍을 생성합니다.
생성된 공개 키를 복사합니다.
Snowflake에서 다음 SQL을 실행하여 사용자에게 공개 키를 추가하십시오.
sqlALTER USER "your_username" SET rsa_public_key='your_public_key_here';조직 및 계정 이름을 형식으로 입력하십시오
ORGNAME-ACCOUNTNAME.연결을 테스트하여 작동하는지 확인하십시오.
확인이 완료되면 변경 사항을 저장하십시오.
다른 연결이 동일한 자격 증명을 공유하는 경우 이 업데이트는 모든 연결에 적용됩니다.
새 연결을 위해 기존 자격 증명을 어떻게 재사용합니까?
새 Snowflake 소스 또는 목적지를 만들 때 조직의 전체 연결에서 이전에 불러오기 자격 증명을 선택할 수 있습니다.
- 새 소스 또는 목적지를 생성할 때 자격 증명 단계에서 기존 자격 증명을 사용할 수 있는 옵션을 찾습니다.
- 다른 프로젝트의 연결을 포함하여 조직의 기존 연결(소스 또는 목적지)에서 자격 증명을 선택합니다.
- Snowflake 사용자에게 새 연결 유형에 필요한 권한 관리가 있는지 확인하십시오.
- 연결 설정을 완료합니다.
계정 이름에는 어떤 형식을 사용해야 합니까?
형식을 사용하십시오ORGNAME-ACCOUNTNAME. 올바른 형식을 얻으려면 Snowflake 인스턴스에서 다음 쿼리를 실행하십시오.
SELECT CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME();
"JWT 토큰이 유효하지 않습니다."라는 오류가 발생하면 어떻게 됩니까?
이 오류는 일반적으로 다음과 같은 경우에 발생합니다.
- 공개 키가 Snowflake 사용자에게 제대로 설정되어 있지 않습니다.
- 계정 이름 형식이 잘못되었습니다(형식은
ORGNAME-ACCOUNTNAME이어야 함). - 공개 키와 개인 키 대상 구간 불일치가 있습니다.
해결 방법:
공개 키가 Snowflake 사용자에게 올바르게 설정되어 있는지 확인하십시오. 다음을 실행하여 확인하십시오.
sqlDESC USER "your_username";올바른 계정 이름 형식을 사용하고 있는지 확인하십시오.
공개 키를 설정할 때 사용 중인 Snowflake 역할에
ALTER USER권한이 있는지 확인하십시오.필요한 경우 키 쌍을 다시 생성하고 Snowflake에서 공개 키를 업데이트하십시오.
이 내용이 도움이 되었나요?