엔터프라이즈 데이터는 멀티 클라우드, 애플리케이션, 플랫폼 전반에 분산되어 있어 경계 방화벽만으로는 관리할 수 없는 중대한 사각지대가 발생합니다. 따라서 네트워크 경계 보안만으로는 충분하지 않습니다. 거버넌스와 통제는 데이터가 존재하는 바로 그 위치에 내재되어야 합니다. 일반적인 대기업이라면 핵심 재무 데이터는 Oracle 데이터베이스에서 운영하고, 실시간 이벤트는 프라이빗 VPC 내 Kafka 브로커를 통해 스트리밍하며, 이와 동시에 여러 퍼블릭 클라우드에 분산된 데이터베이스를 함께 운영하는 경우가 많습니다. 하이브리드 환경에서 이러한 프라이빗 소스에 접근하는 일은 그동안 불가능했거나, 토폴로지마다 별도의 네트워크 솔루션을 마련해야 했습니다. 이렇게 VPN, PrivateLink, 일회성 에이전트를 이어 붙인 구성은 시간이 지나면 그 자체로 또 하나의 인프라 문제가 됩니다.
Snowflake는 이러한 프라이빗 데이터 액세스 문제를 해결하기 위해 Snowflake Openflow용 Data Connectivity Proxy(DCP)를 새롭게 제공합니다. Snowflake Openflow는 별도의 ETL 인프라를 구축하지 않고도 데이터를 연결할 수 있는 Snowflake의 완전 관리형 데이터 통합 서비스이며, DCP는 이전에는 접근할 수 없었던 프라이빗 소스까지 Openflow가 연결할 수 있도록 지원합니다. 이는 Snowflake가 제공하는 일관된 에이전트 모델을 통해 구현되며, 이에 따라 토폴로지별로 VPN, PrivateLink, 서드 파티 에이전트를 따로 마련해야 하는 부담이 줄어듭니다.
네트워크 프로젝트가 되어 버린 프라이빗 데이터 연결
지금까지는 프라이빗 데이터를 관리형 파이프라인에 연결하려면 둘 중 하나를 선택해야 했습니다. 네트워크 경계마다 별도의 ETL 인프라를 두고 그 운영 비용을 감당하거나, 인바운드 포트 개방이 원칙적으로 허용되지 않는 환경에서 승인을 받기 위해 몇 달이 걸리는 프로젝트를 진행해야 했습니다.
금융 서비스, 헬스케어, 제조 기업에서는 모든 인바운드 트래픽을 차단하는 정책이 규정 요건인 경우가 많습니다. 관리형 파이프라인 공급업체가 “프라이빗 네트워크 연결을 구성하라”고 안내하면, 네트워크 엔지니어링 조직을 참여시키고, 방화벽 규칙을 열고, 변경 심의 위원회의 승인을 받아야 합니다. 하지만 DCP는 모든 인바운드를 차단하는 네트워크를 전제로 설계되었습니다. 에이전트는 포트 443에서 아웃바운드 TLS 연결만 생성합니다. 다만 한 가지 제약이 따릅니다. 에이전트를 실행하는 호스트는 해당 포트에서 Snowflake로 직접 아웃바운드 연결을 할 수 있어야 합니다. 현재는 엔터프라이즈 관리형 포워드 프록시(HTTPS_PROXY 또는 CONNECT 기반 포워딩)를 통해 에이전트 자체의 아웃바운드 트래픽을 라우팅하는 방식은 지원되지 않습니다.
그럼에도 데이터가 이동하기 전까지 이 모든 설정에는 몇 주가 걸리며, 기존 선택지는 문제의 일부만 해결할 뿐입니다.
- CSP 네이티브 프라이빗 연결(AWS PrivateLink, Azure Private Endpoint 및 Google Private Service Connect)은 동일 클라우드 내에서 프라이빗 인클라우드 경로가 필요할 때 적합합니다. 따라서 온프레미스 소스를 대상으로 한 방식은 아닙니다. DCP는 고객 네트워크에 설치되는 아웃바운드 에이전트를 통해 이러한 경우까지 지원합니다.
- VPN, ExpressRoute, VPC 피어링도 사용할 수는 있지만, 각각 인프라 팀과의 조율, 승인, 지속적인 유지 관리가 필요한 몇 주짜리 네트워크 엔지니어링 프로젝트입니다.
- 레거시 파이프라인 도구는 대체로 이 문제를 해결하지 못합니다. 일부 도구는 퍼스트 파티 에이전트조차 제공하지 않기 때문에, 파이프라인을 사용하기 전에 고객이 직접 VPN과 전용 네트워크 연결을 구축해야 합니다.
- 서드 파티 연결 에이전트는 기술적 문제는 해결할 수 있지만, 또 다른 공급업체, 관리해야 할 공급업체와 계약, 운영·지원 대상 시스템이 하나씩 늘어납니다.
Data Connectivity Proxy 작동 방식
DCP는 데이터가 이미 자리 잡고 있는 환경 안에서 실행되는 경량 에이전트로 제공되어, 데이터 통합 경로에서 이러한 네트워크 의존성을 없앱니다. 온프레미스 데이터센터, 프라이빗 클라우드 환경, VPC, 다른 클라우드가 모두 해당됩니다.
에이전트는 443 포트로 Snowflake에 아웃바운드 연결을 생성하고 암호화된 터널을 구성합니다. 그런 다음 Snowflake는 이 터널을 통해 Openflow 트래픽을 전달해 프라이빗 소스에 접근합니다.
이 구조는 기존 방식을 뒤집습니다. Snowflake가 고객 네트워크 안으로 들어오는 것이 아니라, 고객 네트워크가 Snowflake로 연결을 내보내는 방식입니다. 방화벽을 지나는 트래픽은 내부에서 시작된 아웃바운드 TLS 연결뿐입니다. 인바운드 방화벽 규칙을 새로 열거나, 변경 또는 승인받을 일이 없습니다.
에이전트와 Snowflake 간 트래픽은 상호 TLS(mTLS)로 보호되며, 양쪽 모두 인증서로 서로의 신원을 확인합니다. 초기 설정은 일회성 부트스트랩 토큰으로 시작됩니다. 이후에는 에이전트가 인증서 쌍으로 자동 인증하며, Snowflake는 이를 백그라운드에서 교체합니다. 에이전트는 TCP 계층에서 작동합니다. 터널을 통과하는 데이터를 검사하거나 파싱하거나 저장하지 않고 그대로 전달합니다.
프라이빗 데이터 소스 연결에 Openflow와 DCP를 선택해야 하는 이유
보안: DCP는 모든 인바운드를 차단하는 네트워크를 전제로 설계되었습니다. 에이전트는 인바운드 연결을 절대 수락하지 않으므로 방화벽 예외를 요청할 필요도, 새로운 인바운드 리스너를 추가할 필요도 없습니다. 방화벽을 지나는 트래픽은 443 포트의 아웃바운드 TLS 한 가지뿐입니다.
인증 주체가 명시적이고 감사 가능합니다. Snowflake에서 부트스트랩 JSON 웹 토큰(JWT)을 발급해 에이전트 호스트에 배치합니다. 에이전트는 해당 토큰을 DCP 컨트롤 플레인에 한 번 제출하고, 해당 DCP 클라이언트에 연결된 mTLS 인증서를 받습니다. 그 이후 터널, 하트비트, 라우팅 업데이트에는 mTLS가 사용됩니다. 양쪽 모두 모든 연결에서 인증서를 확인합니다. 부트스트랩 토큰은 다음 인증서 교체 시점까지 다시 사용되지 않습니다.
에이전트는 TCP 패스스루 방식으로 작동합니다. 터널을 지나는 바이트를 검사하거나 파싱하거나 저장하지 않습니다. 소스 자격 증명은 Snowflake에 보관되며, 에이전트에는 전달되지 않습니다. 접속 대상은 Snowflake에서 허용 목록으로 관리됩니다. 네트워크 규칙에 프라이빗 호스트와 포트를 지정하고, 외부 액세스 통합에서 해당 규칙을 허용한 뒤, 이 통합을 DCP 오브젝트에 바인딩합니다. 필요하면 오브젝트에 네트워크 정책을 적용해 DCP 컨트롤 플레인에 접속할 수 있는 소스 IP를 제한할 수 있습니다. 오브젝트를 비활성화하거나 삭제하면 인증서 유효 기간이 남아 있어도 에이전트 인증서가 더 이상 동작하지 않습니다.
연결 범위: DCP는 같은 클라우드 내 프라이빗 엔드포인트나 퍼블릭 SaaS 커넥터로는 다룰 수 없는 영역을 지원합니다.
- Oracle, SQL Server, PostgreSQL, MySQL을 포함해 기업 방화벽 뒤에 있는 온프레미스 데이터베이스
- VPC 또는 데이터 센터 내 프라이빗 Kafka 브로커
- Snowflake 계정은 Azure에 있고 데이터는 AWS에 있는 경우와 같은 크로스 클라우드 소스
- 이러한 토폴로지가 동시에 존재하는 하이브리드 환경
에이전트에는 아웃바운드 포트 443만 필요하므로 데이터와 Snowflake 계정이 AWS, Azure, Google Cloud 또는 온프레미스 어디에 있든 동일한 패턴을 적용할 수 있습니다. 그동안은 이러한 공백을 메우기 위해 서드 파티 도구를 이어 붙여 왔다면, DCP는 그 복잡한 조합을 Openflow에 기본으로 통합된 퍼스트 파티 경로로 대체합니다.
단순한 구성: 에이전트는 Docker 이미지로 제공되며 Docker 또는 다른 OCI 호환 런타임이 설치된 모든 Linux 호스트에서 실행됩니다. Kubernetes는 필요하지 않습니다. 터널이 끊기면 에이전트가 다시 연결되며, Snowflake는 활성 연결을 중단하지 않고 백그라운드에서 에이전트 인증서를 교체합니다.
DCP 시작 방법
DCP는 현재 AWS, Azure, GCP에서 Standard, Enterprise, Business-Critical 에디션을 사용하는 Snowflake 고객에게 정식 제공됩니다. 온프레미스 Oracle을 운영하는 중견 제조기업부터 방화벽 뒤에서 PostgreSQL을 운영하는 지역 은행까지, 프라이빗 소스 연결이 필요한 조직은 Snowflake 상위 에디션으로 이전하지 않고도 퍼스트 파티 Openflow 기능을 통해 바로 시작할 수 있습니다.
지금까지 Snowflake Openflow에 연결할 수 없었던 온프레미스 데이터베이스, 프라이빗 Kafka 브로커 또는 크로스 클라우드 소스가 있다면, 지금 Openflow에서 DCP를 사용해 보세요. 인바운드 방화벽 액세스를 열거나 네트워크를 재설계하지 않고도 연결할 수 있습니다.
Quick start
-- Step 1: Create the DCP object
CREATE DATA CONNECTIVITY PROXY my_dcp_client;
-- Step 2: Generate a bootstrap token (valid for 7 days)
SELECT SYSTEM$GENERATE_DATA_CONNECTIVITY_PROXY_BOOTSTRAP_TOKEN('my_dcp_client', 7);# Step 3: Deploy the agent
docker run -d \
--name dcp-agent \
--restart unless-stopped \
-v /etc/dcp/credentials:/credentials:ro \
snowflake/dcp-agent:latest \
--dcp-client-name my_dcp_client \
--credentials-file /credentials \
--snowflake-account <your-account>-- Step 4: Verify
DESCRIBE DATA CONNECTIVITY PROXY my_dcp_client;Snowflake 설명서
- Data Connectivity Proxy 개요: 아키텍처, DCP 사용 시점, PrivateLink 및 안정적 송신 IP와의 비교
- Data Connectivity Proxy 설정: 단계별 배포 가이드
- 보안 모델: mTLS, 인증서 관리 및 액세스 해지
- Data Connectivity Proxy 모니터링:
DESCRIBE DATA CONNECTIVITY PROXY, 이벤트 기록, Prometheus 지표 - Data Connectivity Proxy와 함께 Snowflake Openflow 사용하기
