LLM WikiAccess-protected knowledge portal
← 스터디 홈
126편 · 약 16분

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

요약

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로 감싸져 있다. 이 상태에서 새 리시피언트가 등장하면 필요한 절차는 대략 다음과 같다.

  • 리시피언트의 아웃바운드 NAT IP 또는 VPC ID 확정.
  • 프로바이더 클라우드 계정의 보안팀에 방화벽 변경 요청.
  • 변경 승인·감사·롤아웃.
  • 리시피언트가 실제로 pre-signed URL을 열 수 있는지 종단 테스트.

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

왜 지금 바뀌었나

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

  • 에이전트 워크로드의 확산. AI 에이전트가 다른 조직의 데이터를 짧은 시간 안에 소비하는 흐름이 늘었다. 파트너 접근을 "몇 주 후에 열어드리겠다"고 답할 수 없는 상황이 흔해졌다.
  • 오픈 테이블 포맷의 확산. Iceberg REST 카탈로그를 매개로 여러 벤더가 같은 테이블을 읽어야 하는 시나리오가 늘었다. 데이터 사본을 만들지 않고 원본에 바로 접근하는 것이 표준이 됐다.
  • 온프렘/프라이빗 클라우드 데이터의 클라우드 AI 연결. 규제 산업(금융·의료·통신)에서 원본 데이터는 온프렘에 두되, 특정 슬라이스만 클라우드 AI로 노출하는 요구가 강해졌다. Delta Sharing의 원 구조에서는 다루기 어려운 시나리오다.

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

SecureConnect 아키텍처

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

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

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

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

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

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

  • 원본 데이터는 절대 리시피언트 쪽에서 직접 접근되지 않는다. 리시피언트가 접근하는 것은 필터가 이미 적용된 파생물이다. 행 수준·컬럼 수준 액세스 제어가 실제로 작동하는 이유다.
  • 필터링 컴퓨트 비용은 프로바이더가 낸다. Materialize가 매 요청마다 일어나지는 않고 캐시가 붙지만, 근본적으로 이 비용은 프로바이더의 계정에서 발생한다.

2) Databricks 관리형 프록시

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

  • AWS 프로바이더: 프로바이더 리전의 "Default storage, OpenSharing SecureConnect, Zerobus Ingestion, Lakebase (Autoscaling Beta)" IP 목록을 스토리지 정책에 허용.
  • Azure 프로바이더: 프로바이더 리전의 "Control Plane IPs, including default storage and webapp" 목록.
  • GCP 프로바이더: 프로바이더 리전의 "Control Plane services, including default storage and webapp" 목록.

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

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

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

  • 서버리스 컴퓨트 리시피언트: 아무 것도 설정하지 않아도 된다. Databricks가 서버리스 트래픽을 내부 라우팅으로 SecureConnect에 붙인다.
  • 클래식 컴퓨트 및 오픈 리시피언트(비-Databricks): 자사 아웃바운드 방화벽에서 Databricks의 프록시 IP 대역으로 나가는 연결을 허용해야 한다. 이건 리시피언트 쪽 한 번의 작업이지, 프로바이더가 매번 관여할 부분이 아니다.

프록시는 일방향이다. 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월에 발표한 큰 확장 중 네트워크 축을 담당한다. 나머지 축을 함께 놓고 봐야 전체 그림이 보인다.

  • AI 자산 공유. Delta Sharing이 테이블만 대상으로 했다면, OpenSharing은 에이전트 스킬, 모델 아티팩트, 비정형 데이터까지 대상에 넣는다. 이 자산들도 pre-signed URL 기반 same-protocol로 흐른다.
  • Apache Iceberg REST 클라이언트 호환. Iceberg REST 카탈로그를 이해하는 어떤 클라이언트(Snowflake·Trino·Dremio·Starburst·자체 엔진 포함)든 OpenSharing 프로바이더가 노출한 테이블을 소비할 수 있다. 이는 Databricks 밖으로 리시피언트 생태계를 크게 확장한다.
  • 온프렘·프라이빗 클라우드 소스. Everpure·MinIO·Qumulo 같은 스토리지 파트너와의 연동으로, 온프렘에 있는 원본을 클라우드 AI 스택에 데이터를 옮기지 않고 노출할 수 있다. 이 시나리오는 SecureConnect의 방화벽 우회가 없으면 실질적으로 불가능하다.

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

롤아웃과 운영 시점

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

  • AWS: GA는 2026년 8월. Databricks가 프로바이더 계정에 대해 롤링으로 기본 활성화한다. 이 시점 이후 새 공유는 기본적으로 SecureConnect를 통해 라우팅된다.
  • Azure Databricks: Premium 플랜 계정은 2026년 9월 중순부터 기본 활성화, 그 외는 2027년 초까지 순차 적용.
  • GCP: 릴리스 노트 시점에는 세부 롤아웃 일정 명시 없음, 일반 GA 우산 아래 진행.

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

비용 모델

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

  • 오늘: 프로바이더가 SecureConnect 경유 접근에 대한 데이터 egress 요금을 부담. 즉 리시피언트 트래픽 볼륨에 비례해 프로바이더에게 청구된다.
  • 향후 확장 예정: 추가 charge type과 리시피언트 청구 시나리오. 세부 요율표와 청구 대상 확대 시점은 공개되지 않았다. Open question.

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

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

도입 체크리스트

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

  • [네트워크] 스토리지 방화벽(S3 bucket policy, ADLS network rules, GCS VPC-SC ingress rules)에 자사 리전의 Databricks 안정 IP 대역이 허용되어 있는가.
  • [컴퓨트] OpenSharing 서버리스 컴퓨트가 활성화된 워크스페이스에서 필터링 컴퓨트가 스케일링 예산 안에서 동작하는가. 대량 리시피언트 요청 폭주 시 예산 초과가 없는지 시뮬레이션.
  • [데이터 정책] 공유 대상 테이블·자산에 대해 행/컬럼 수준 액세스 정책과 삭제 정책이 Unity Catalog 상에 정확히 정의되어 있는가. SecureConnect는 정책의 물리적 강제만 담당하지, 정책을 만들어주진 않는다.
  • [감사] 리시피언트별·자산별 접근 감사 로그가 요구되는 규제 기준(예: SOC 2, ISO 27001, HIPAA)에 맞게 흘러가는가.
  • [리시피언트 안내] 클래식 컴퓨트 및 오픈 클라이언트 리시피언트에게 Databricks 아웃바운드 IP 허용 절차를 안내했는가.
  • [롤아웃] 자사 계정의 SecureConnect 기본 활성화 예정일을 사전 파악하고, 활성화 직후 몇몇 파트너와 종단 테스트를 계획했는가.

남은 문제와 한계

  • Materialize 캐시 정책의 세부. 필터링 결과가 얼마나 오래 캐시되는지, 언제 파기되는지, 리시피언트가 재요청할 때 재사용되는지의 정책은 공식 문서에서 세밀히 공개되지 않았다. 워크로드 특성상 이 부분이 성능과 비용을 동시에 좌우한다. Open question.
  • 동일 데이터셋의 크로스 리전/크로스 클라우드 공유. 프로바이더 스토리지가 여러 리전에 걸쳐 있을 때 프록시 라우팅이 어떻게 결정되는지, 지연 최적화가 어느 계층에서 일어나는지는 문서 표면에서 명확하지 않다.
  • 감사 로그의 표준 스키마. OpenSharing 자체가 벤더 중립 오픈 소스로 자리 잡으면서, SecureConnect가 발생시키는 이벤트가 non-Databricks 클라이언트에서도 소비 가능한 표준 형태로 노출되는지 추가 확인 필요.
  • 가격의 예측 가능성. Egress 요금 확대와 리시피언트 청구 도입이 예정되어 있다. 현 시점 비용 계산은 임시적이며, 향후 요율 확정 시 재계산 필요.

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

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

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

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

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

References

  • Databricks Blog, "Introducing OpenSharing SecureConnect". https://www.databricks.com/blog/introducing-opensharing-secureconnect
  • Databricks Blog, "Introducing OpenSharing: the Next Evolution of Delta Sharing for the Agentic Era". https://www.databricks.com/blog/introducing-opensharing-next-evolution-delta-sharing-agentic-era
  • Databricks AWS Release Notes, August 2026. https://docs.databricks.com/aws/en/release-notes/product/2026/august
  • Azure Databricks Release Notes, August 2026. https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/august
  • Databricks Docs, "What is OpenSharing?". https://docs.databricks.com/aws/en/opensharing/
  • Databricks Docs, "Share data behind a firewall with SecureConnect". https://learn.microsoft.com/en-us/azure/databricks/opensharing/secureconnect-provider
  • Databricks Docs, "OpenSharing recipient firewall configuration for SecureConnect". https://docs.databricks.com/aws/en/opensharing/secureconnect-recipient
  • Databricks Docs, "Restrict OpenSharing recipient access using IP access lists". https://docs.databricks.com/aws/en/opensharing/access-list
  • Databricks Newsroom, "Databricks Announces OpenSharing, a New Open Standard". https://www.databricks.com/company/newsroom/press-releases/databricks-announces-opensharing
  • Delta Sharing 프로토콜 논문, VLDB 2025, "Delta Sharing: An Open Protocol for Cross-Platform Data Sharing". https://www.vldb.org/pvldb/vol18/p5197-puttaswamy.pdf