LLM WikiAccess-protected knowledge portal

WIKI

Databricks OpenSharing SecureConnect GA: 방화벽 뒤 스토리지를 리시피언트마다 열지 않고 공유하는 방법

요약 Delta Sharing이 처음 나올 때 남긴 숙제 하나가 있었다. 프로토콜은 열렸지만 네트워크는 열리지 않았다 는 점이다. 프로바이더가 데이터를 프라이빗 VPC나 방화벽 뒤 오브젝트 스토리지 예 S3 bucket with aws SourceIp 조건, ADLS with private endpoint, GCS with VPC Service Controls 에 두면, 리시피언트가 하나 늘어날 때마다 프로바이더의 스토리지 방

경로human/study/content/database-frontier/126-databricks-opensharing-secureconnect-ga-managed-proxy-firewall.md
카테고리Study
태그#firewall #infra #managed #mysql #opensharing #proxy #secureconnect #study

요약

Delta Sharing이 처음 나올 때 남긴 숙제 하나가 있었다. 프로토콜은 열렸지만 네트워크는 열리지 않았다는 점이다. 프로바이더가 데이터를 프라이빗 VPC나 방화벽 뒤 오브젝트 스토리지(예: S3 bucket with aws:SourceIp 조건, ADLS with private endpoint, GCS with VPC Service Controls)에 두면, 리시피언트가 하나 늘어날 때마다 프로바이더의 스토리지 방화벽에 IP를 추가해야 했다. 실무에서는 이 과정에 몇 주가 걸렸다. 보안팀 승인, 리시피언트 IP 확정, 변경 승인, 감사 로그—모든 단계가 서로 다른 조직 경계에 걸쳐 있었다.

2026년 8월, Databricks는 이 문제를 정면으로 다룬 OpenSharing SecureConnect를 일반 사용 가능(GA)으로 전환했다. 6월 10일 Data + AI Summit 2026에서 발표된 OpenSharing(Delta Sharing의 후속, Linux Foundation 호스팅)의 첫 번째 대형 확장 기능이다. Databricks가 관리하는 프록시가 리시피언트를 대신해 프로바이더 스토리지에 접근하고, 프로바이더는 Databricks의 안정된 IP 목록만 한 번 허용하면 이후 리시피언트가 몇 명 늘어나든 방화벽을 다시 만지지 않는다.

이 글은 왜 이 문제가 몇 주 걸리던 것이 몇 시간으로 줄었는지, SecureConnect의 아키텍처가 정확히 무엇을 매개하는지, 프로바이더·리시피언트·서버리스/클래식 컴퓨트마다 설정이 어떻게 다른지, 그리고 이 기능을 운영에 도입할 때 결정해야 할 지점들을 다룬다.

배경: Delta Sharing이 열지 못한 것

Delta Sharing 프로토콜은 원리 자체가 우아하다. 프로바이더 서버는 리시피언트의 요청을 받아 메타데이터를 리턴하고, 실제 Parquet 파일에 대한 단기 pre-signed URL을 발행한다. 리시피언트는 이 URL로 오브젝트 스토리지에서 직접 데이터를 읽는다. 서버는 컨트롤 플레인만 담당하고, 대역폭은 스토리지에서 곧바로 흐른다.

이 설계는 두 가지 전제를 깔고 있다.

  1. 스토리지가 리시피언트로부터 도달 가능해야 한다. 즉 pre-signed URL이 열리는 순간, 리시피언트의 네트워크가 스토리지 엔드포인트에 접속할 수 있어야 한다.
  2. 프로바이더가 리시피언트를 신뢰할 수 있어야 한다. 최소한 스토리지 방화벽에 리시피언트의 IP를 추가할 만큼은.

문제는 대부분의 엔터프라이즈 프로바이더가 두 조건 중 첫 번째를 만족시키지 못한다는 데 있다. 데이터가 있는 S3 bucket에는 aws:SourceIp 또는 aws:SourceVpc 제한이 걸려 있고, ADLS는 private endpoint 뒤에 있으며, GCS는 VPC Service Controls로 감싸져 있다. 이 상태에서 새 리시피언트가 등장하면 필요한 절차는 대략 다음과 같다.

이 흐름이 리시피언트마다 반복된다. 파트너 30곳에 데이터를 열려면 30번 같은 절차를 밟는다. 이 실무 부담이 오랫동안 Delta Sharing의 확산을 제한한 조용한 원인이었다.

왜 지금 바뀌었나

이 문제가 2026년 상반기부터 특히 압박을 받은 세 가지 트렌드가 있다.

OpenSharing은 이 세 요구를 반영하고, SecureConnect는 그중 첫 번째와 세 번째를 실질적으로 실행 가능하게 만드는 네트워크 계층이다.

SecureConnect 아키텍처

SecureConnect의 핵심은 한 문장으로 요약된다. Databricks가 리시피언트 대신 프로바이더 스토리지에 접근한다.

리시피언트
(서버리스/클래식)
→
Databricks
관리형 프록시
Stable IPs
→
프로바이더 클라우드
필터링 컴퓨트
(materialize)
↓
방화벽 뒤 스토리지
S3 / ADLS / GCS
SecureConnect 데이터 경로: Databricks 관리형 프록시가 스토리지 접근을 대리한다

세 지점을 하나씩 뜯어본다.

1) 프로바이더 스토리지 앞의 필터링 컴퓨트

SecureConnect가 켜지면, 공유되는 자산은 항상 프로바이더 쪽에서 materialize + filter된다. 리시피언트가 SELECT를 던질 때 프로바이더의 서버리스 컴퓨트가 필요한 필터·프로젝션을 적용해 결과를 임시 스토리지에 물리적으로 저장한 다음, 그 파일에 대한 pre-signed URL을 리시피언트에게 넘긴다.

이 설계는 두 가지를 함의한다.

2) Databricks 관리형 프록시

프록시는 리시피언트의 pre-signed URL 요청을 받아 프로바이더 스토리지에 접근한다. 모든 이 접근은 Databricks의 안정된 공개 IP 대역에서 나간다. 프로바이더 입장에서 이 IP 대역은 발표되어 있고 자주 바뀌지 않는다.

이 한 번의 허용이 모든 리시피언트의 접근을 커버한다. 새 리시피언트가 붙는다고 목록이 늘지 않는다.

3) 리시피언트 아웃바운드

리시피언트는 두 부류로 나뉜다.

프록시는 일방향이다. Databricks 프록시가 리시피언트 네트워크로 인바운드 연결을 열지 않는다. 즉 리시피언트의 네트워크 관리자가 인바운드 IP를 허용할 필요가 없다.

무엇이 바뀌었는가: "몇 주 → 몇 시간"

이 아키텍처가 실무에서 무엇을 바꾸는지 세 가지 각도로 정리한다.

프로바이더 관점

이전에는 새 리시피언트 등록 프로세스가 대략 이랬다.

  1. 리시피언트가 자사 아웃바운드 IP 문서를 제공.
  2. 프로바이더 보안팀이 스토리지 방화벽 변경안 검토.
  3. 변경 승인·감사 트레일 작성.
  4. 롤아웃 후 실제 접근 테스트.
  5. 종단 실패 시 IP 재확인, NAT gateway 변경, 반복.

SecureConnect 이후에는 이 프로세스가 최초 한 번으로 압축된다. Databricks의 IP 대역을 최초에 허용하고, 이후 새 리시피언트는 OpenSharing 리시피언트 오브젝트 생성만으로 끝난다. 감사 관점에서는 프로바이더가 관리하는 항목이 "IP 목록" 하나에서 "리시피언트 목록"으로 바뀐다. 훨씬 명확한 경계다.

리시피언트 관점

Delta Sharing 클라이언트(Spark, pandas, Trino, PowerBI 등)가 그대로 동작한다. 프로토콜 자체가 바뀌지 않기 때문이다. SecureConnect는 컨트롤 플레인의 pre-signed URL 발행 경로 뒤에서 라우팅만 바꾸는 인프라 수준의 변화다.

서버리스 워크스페이스에서는 문자 그대로 아무 것도 하지 않는다. 클래식 컴퓨트에서는 Databricks 아웃바운드 IP 허용 한 번이면 이후의 어떤 SecureConnect 프로바이더에 대해서도 접근이 성립한다.

데이터 관점

원본 데이터는 프로바이더 스토리지에 계속 남아 있다. 사본이 만들어지지 않는다. 접근 정책, 감사 로그, 삭제 요청 처리는 모두 프로바이더 쪽 원본에서 유지된다. 이는 GDPR·CCPA 같은 데이터 삭제 권리 대응에서 결정적으로 중요한 특성이다.

OpenSharing이 열어놓은 큰 그림

SecureConnect는 OpenSharing이 6월에 발표한 큰 확장 중 네트워크 축을 담당한다. 나머지 축을 함께 놓고 봐야 전체 그림이 보인다.

발표 시 파트너로 OpenAI, SAP, Stripe, Atlassian, LSEG, Amadeus가 이름을 올렸다. 이 조합이 시사하는 방향은 명확하다. AI 에이전트가 조직 경계를 넘어 데이터를 소비하는 사용례를 위한 인프라 계층으로 OpenSharing을 위치시키려는 것이다.

롤아웃과 운영 시점

GA 시점의 세부 사항 몇 가지가 도입 계획에 영향을 준다.

Open question: 롤링 활성화 순서가 문서상 세밀하게 공개되지 않았다. 프로바이더는 자사 계정의 활성화 시점 확인이 필요.

비용 모델

현재 시점의 청구 구조는 이렇다.

이 청구 구조는 프로바이더에게 두 가지 운영 결정을 요구한다.

  1. 데이터 이동 예산 산정. 파트너가 늘거나 특정 파트너가 대량으로 스캔하는 경우, egress 비용이 예상 밖으로 커질 수 있다. 필터링 컴퓨트의 캐시 정책과 materialize 재사용 정책을 함께 모니터링해야 한다.
  2. 리시피언트별 사용량 가시성. 어떤 리시피언트가 얼마나 쓰는지 감사 로그에서 추적 가능해야 한다. 현재 OpenSharing이 제공하는 감사 이벤트로 대부분 확보되지만, 팀별 비용 어트리뷰션은 조직 내부에서 다시 구성해야 한다.

도입 체크리스트

프로바이더 관점에서 도입 검토 시 확인해야 할 항목.

남은 문제와 한계

정리: 네트워크가 프로토콜을 따라잡았다

Delta Sharing이 5년 전 프로토콜 문제를 풀었다면, OpenSharing SecureConnect는 네트워크 문제를 풀었다. 그 결과는 이전에는 "몇 주짜리 협의 프로젝트"였던 리시피언트 등록이 몇 시간짜리 오퍼레이션 태스크로 바뀐 것이다.

운영자 관점에서 세 가지 요약:

  1. 프로바이더는 IP를 한 번만 허용한다. 이후 리시피언트가 몇 명이든 방화벽을 다시 만지지 않는다.
  2. 원본 데이터는 리시피언트 네트워크에서 절대 직접 접근되지 않는다. 프로바이더 쪽에서 materialize + filter 후 pre-signed URL로만 흐른다. 접근 정책의 물리적 강제가 명확해진다.
  3. 서버리스 리시피언트는 아무 것도 안 한다. 클래식 리시피언트는 아웃바운드 허용 한 번이면 끝. 대부분의 리시피언트-측 운영 부담이 사라진다.

이 변화는 OpenSharing이 지향하는 더 큰 그림—AI 자산과 온프렘 데이터까지 벤더 중립 프로토콜로 흐르는 데이터 공유 인프라—의 첫 번째 실질적 지원이다. 아직 롤아웃 시점, 캐시 정책, 향후 청구 구조 같은 실무 변수가 남아 있지만, 그 결정을 기다리는 동안에도 자사 스토리지 정책과 리시피언트 안내 준비를 미리 해두는 것이 다음 라운드의 확장 속도를 결정한다.

References