PII를 노출하지 않고 Claude에게 Snowflake 접근 권한을 부여하는 방법

Claude — 또는 Cursor, ChatGPT, 혹은 그 어떤 MCP 인식 에이전트(MCP-aware agent) — 가 여러분의 Snowflake 데이터에 관한 질문에 답변하기를 원할 것입니다. 동시에 여러분은 에이전트가 사회보장번호(social security numbers), 자유 형식의 고객 메모(free-text customer notes), 또는 GDPR / HIPAA / SOC 2의 적용을 받는 그 어떤 것도 읽지 않기를 원합니다. 기본 MCP 설정은 에이전트의 연결 역할(connection role)이 볼 수 있는 모든 것을 에이전트에게 넘겨줍니다. 이것이 바로 문제입니다.

이 포스트에서는 비용이 가장 적게 드는 방법부터 가장 철저한 방법까지 순서대로 정리된 5단계의 방어 계층을 살펴봅니다. 각 단계는 독립적이므로, 여러분의 위험 허용 범위(risk tolerance)에 맞는 것을 선택하십시오. 전체 스택을 기존 Snowflake 계정에 설정하는 데는 대략 1시간 정도가 소요됩니다.

기본 상태 (그리고 그것이 잘못된 이유)

공식 버전을 포함한 Snowflake를 위한 전형적인 MCP 서버는 서비스 계정(service account)으로 연결하고, query 도구를 노출하며, 모델이 해당 역할(role)이 실행할 수 있는 모든 SQL을 실행할 수 있도록 합니다. 해당 역할은 보통 웨어하우스(warehouse)와 데이터베이스(database) 범위로 제한되지만, 컬럼(column)이나 로우 세트(row set) 단위로 제한되는 경우는 드뭅니다. 모델은 여러분의 웨어하우스에 대한 유창한 SQL 인터페이스를 갖게 되며, 웨어하우스는 보이는 모든 쿼리를 신뢰합니다.

피해 범위(blast radius)는 매우 넓습니다. 2025 IBM 데이터 침해 비용 보고서(IBM Cost of a Data Breach Report)에 따르면, 데이터 침해의 평균 비용은 488만 달러에 달하며, 광범위한 클라우드 데이터 노출이 포함된 침해는 평균보다 23% 더 많은 비용이 발생합니다. AI 에이전트가 프로덕션 웨어하우스에 대해 검증되지 않은(uncurated) 쿼리를 실행하도록 허용하는 것은 정확히 이러한 비용 상승을 유발하는 클라우드 데이터 노출(cloud-data-exposure) 범주에 해당합니다.

계층 1: 전용 MCP 역할 (Dedicated MCP Role)

첫 번째 단계이자 매번 수행해야 할 작업은 에이전트만을 위해 존재하는 역할을 생성하는 것입니다. 분석용 역할(analytics role)을 재사용하지 말고, dbt 역할을 재사용하지 마십시오. 그리고 절대로 SYSADMIN을 사용해서는 안 됩니다.

에이전트가 사용하기를 원하는 웨어하우스(warehouse)에 대해 USAGE 권한을 부여하십시오. 제어되지 않는 쿼리가 발생하더라도 비용 상한선이 제한될 수 있도록 작고 전용인 웨어하우스(X-Small 또는 Small)를 사용하십시오.
에이전트가 볼 수 있어야 하는 데이터베이스(database)와 특정 스키마(schemas)에 대해 USAGE 권한을 부여하십시오.
에이전트가 쿼리해야 하는 특정 뷰(views)에 대해 SELECT 권한을 부여하십시오. 원본 테이블(raw tables)이 아닌 뷰를 사용해야 합니다. 뷰를 사용하면 기본 데이터를 수정하지 않고도 마스킹(masking), 필터(filters), 조인(joins)을 적용할 수 있는 지점을 확보할 수 있습니다.
CREATE, INSERT, UPDATE, DELETE 또는 TRUNCATE 권한은 절대로 부여하지 마십시오. 에이전트는 읽기 전용(read-only) 역할입니다.

뷰 전용 SELECT 권한만 가진 읽기 전용 역할은 대부분의 팀이 필요로 하는 기능의 약 80%를 충족합니다. 나머지 20%가 실제로 PII(개인정보) 위험이 존재하는 영역입니다.

레이어 2: 컬럼 수준 마스킹 정책 (Column-Level Masking Policies)

Snowflake는 실행하는 역할(role)에 따라 작동하는 마스킹 정책(masking policies)을 지원합니다. 동일한 SELECT 문이라도 분석가 역할(analyst role)에는 원본 값을 반환하고, 에이전트 역할(agent role)에는 마스킹된 값을 반환합니다. 이는 에이전트나 MCP 서버가 올바르게 동작하는지에 의존하지 않기 때문에 가장 중요한 단일 PII 통제 수단입니다.

ANALYTICS_HUMAN을 제외한 모든 역할에 대해 SHA2(email)를 반환하는 마스킹 정책을 적용하면, 모델이 탈옥(jailbroken)되어 SELECT * 쿼리를 생성하더라도 이메일 주소가 아닌 해시(hashes) 값을 얻게 됩니다. 이 정책은 애플리케이션 레이어(application layer)가 아닌 SQL 엔진 레이어(SQL engine layer)에서 강제됩니다.

PII로 태그된 모든 컬럼(column)에 마스킹 정책을 적용하십시오. 아직 PII 태그가 없다면, 감사 도구(또는 Data Workers 거버넌스 에이전트)가 스키마를 스캔하여 이메일, 전화번호, 사회보장번호(SSNs), 자유 형식 텍스트 컬럼(free-text columns), IP 주소, 생년월일 등 후보 컬럼을 자동으로 태깅할 수 있습니다.

레이어 3: 행 접근 정책 (Row Access Policies)

마스킹이 값을 숨긴다면, 행 접근 정책(Row access policies)은 행 전체를 숨깁니다. 멀티 테넌트(multi-tenant) 데이터, 또는 에이전트가 단 한 명의 고객, 특정 지역, 또는 특정 회계 연도의 데이터만 봐야 하는 모든 경우에 행 접근 정책이 적절한 기본 요소(primitive)입니다.

일반적인 패턴: 에이전트 역할(role)의 범위를 최근 90일간의 데이터로 제한하거나, sensitive = true로 태그된 행을 제외하거나, 특정 tenant_id로 제한하는 방식이 있습니다. 마스킹 정책(masking policies)과 마찬가지로, 이러한 정책들은 엔진 내부에서 강제되므로 애플리케이션 계층(application-layer)의 코드로도 이를 우회할 수 없습니다.

계층 4: 감사 로깅 (Audit Logging)

에이전트가 실행하는 모든 쿼리는 최소 30일 동안 감사(auditable) 가능해야 합니다. Snowflake의 QUERY_HISTORY 뷰는 신뢰할 수 있는 단일 출처(source of truth)입니다. 여기에는 SQL 텍스트, 실행 역할(role), 시작 및 종료 시간, 그리고 반환된 행(rows) 정보가 포함됩니다. 이를 SIEM(Datadog, Splunk, S3+Athena)으로 파이프라인화하면, 별도의 커스텀 코드를 작성하지 않고도 '에이전트가 지난주에 무엇을 보았는가?'라는 질문에 답할 수 있습니다.

모든 에이전트 주도 쿼리에 주석 헤더(예: /* mcp_agent=data_workers, session=abc123 */)를 태그하여 QUERY_HISTORY를 쉽게 필터링할 수 있도록 하세요.
10,000행 이상의 데이터를 반환하는 에이전트 쿼리에 대해서는 경고(alert)를 설정하세요. 이는 의도된 동작인 경우가 거의 없습니다.
에이전트의 웨어하우스(warehouse)에 엄격한 쿼리 타임아웃(query timeout)을 설정하세요(처음에는 60초로 시작해 보세요). 제어 불능 상태가 된 에이전트가 30분 동안 실행될 수 없다면 비용 손실을 최소화할 수 있습니다.

계층 5: 가드레일로서의 스키마 인식 카탈로그 (Schema-Aware Catalog)

가장 미묘한 PII 유출은 에이전트가 잘못된 테이블을 선택할 때 발생합니다. 에이전트는 customers_legacy 테이블이 2024년에 폐기되었지만 삭제되지는 않았다는 사실을 알지 못합니다. 또한 orders_raw에는 비식별화되지 않은 결제 데이터가 포함되어 있지만, orders에는 정제된 버전이 들어 있다는 사실도 알지 못합니다. 카탈로그가 없다면 에이전트는 그저 이름이 그럴듯해 보이는 테이블을 선택할 뿐입니다.

에이전트가 SQL을 작성하기 전에 읽는 데이터 카탈로그(data catalog)가 이 문제를 해결합니다. 에이전트가 카탈로그에 '주문 데이터가 어디에 있나요?'라고 물으면, 카탈로그는 거버넌스가 적용된 뷰(governed view), 소유권, 최신성(freshness), 그리고 PII 태그와 함께 응답합니다. 카탈로그가 해당 테이블을 노출하지 않기 때문에 에이전트는 레거시 테이블을 절대 볼 수 없습니다.

이것이 바로 Data Workers의 Catalog Agent가 수행하는 역할입니다. 이 에이전트는 카탈로그 탐색(catalog discovery) 기능을 MCP 도구로 노출하므로, Claude가 '주문 데이터(order data)'를 쿼리할 때 거버넌스가 적용된 답변을 받게 됩니다. 즉, 동일한 응답 형태와 동일한 마스킹 정책(masking policies)이 적용된 결과를 얻습니다. 카탈로그 자체가 에이전트가 볼 수 있는 범위를 강제합니다.

각 계층을 통해 얻는 이점

계층	방어 대상	설정 시간	운영 영향
전용 MCP 역할 (Dedicated MCP role)	권한 상승 (Privilege escalation)	10분	없음
...

자주 묻는 질문 (FAQ)

이러한 제어 방식이 Claude뿐만 아니라 ChatGPT와 Cursor에서도 작동하나요?
네. 이 모든 것은 Snowflake 측에서 이루어지는 제어입니다. Claude, Cursor, OpenClaw, ChatGPT (원격 MCP를 통해), 또는 커스텀 에이전트 등 어떤 MCP 클라이언트가 연결되더라도 동일하게 적용됩니다.

BigQuery와 Databricks는 어떤가요?
동일한 5개 계층이 적용됩니다. BigQuery에는 승인된 뷰(authorized views)와 컬럼 수준 액세스 제어(column-level access controls)가 있으며, Databricks에는 Unity Catalog 행 필터(row filters)와 컬럼 마스크(column masks)가 있습니다. 명칭은 다르지만 패턴은 동일합니다.

마스킹이 조인(join)이나 집계(aggregation)를 깨뜨리지는 않나요?
마스킹 정책은 데이터 타입(datatype)을 유지하므로, JOIN 및 GROUP BY가 여전히 작동합니다. 다만 마스킹된 값을 대상으로 연산이 수행될 뿐입니다. HASH 기반 마스크의 경우, '해시된 이메일로 그룹화(group by hashed email)'를 수행하더라도 고객별 카운트를 여전히 얻을 수 있음을 의미합니다.

현재 사용 중인 MCP 서버가 PII를 유출하고 있는지 어떻게 알 수 있나요?
에이전트 역할(agent role)로 필터링된 QUERY_HISTORY에 대해 쿼리를 실행하여 SQL 텍스트를 살펴보고, 해당 쿼리 중 마스킹되었어야 할 컬럼을 선택하는 것이 있는지 확인하십시오. 특정 컬럼이 마스킹되어야 하는지 판단할 수 없다면, 아직 PII 태깅(PII tagging)이 되어 있지 않은 상태이므로 거기서부터 시작해야 합니다.

Data Workers의 거버넌스 에이전트는 스캔, 태깅, 정책 생성을 한 번의 호출로 수행하는 pii_audit_snowflake 도구를 제공하며, 이는 오픈 소스입니다. 하지만 이 포스트의 핵심은 해당 도구가 반드시 필요하지는 않다는 점입니다. 5가지 SQL 수준의 제어와 한 시간 정도의 작업만으로도 보안 격차의 가장 큰 부분을 메울 수 있습니다. 카탈로그 가드레일(catalog guardrail)은 그 위에 더해지는 완벽한 마무리입니다.

만약 이 설정을 진행하는 과정에서 구체적인 문제에 직면한다면, 저희의 오픈 소스 리포지토리(open-source repo)인 github.com/DataWorkersProject/dataworkers-claw-community에 작동하는 방식에 대한 기록을 남겨두고 있습니다. 이슈(Issues)와 풀 리퀘스트(PRs)는 언제나 환영합니다.

원문은 https://dataworkers.io/blog/claude-snowflake-without-pii-exposure/에서 처음 게시되었습니다. Data Workers는 데이터 엔지니어링을 위한 오픈 소스 자율 에이전트 스웜(autonomous agent swarm)입니다 — 리포지토리 확인하기.