엔터프라이즈 데이터 아키텍처는 단일 시스템에 존재하는 경우가 거의 없습니다. Salesforce는 고객 참여, 파이프라인, 서비스 상호 작용을 관리합니다. Snowflake와 같은 분석 플랫폼은 과거 트랜잭션, 금융 기록, 사용 데이터, 운영 메트릭을 보관합니다. 기존에는 이러한 두 세계를 연결하는 것은 소스에서 데이터를 추출하고 변환하고 Salesforce에 사본을 로드하는 예약된 작업인 ETL 파이프라인을 구축하고 유지하는 것을 의미했습니다. 이러한 파이프라인으로 인해 데이터가 지연되고, 관리 정책이 여러 시스템에 분산되며, 파이프라인에는 지속적인 운영 관리가 필요합니다.

Salesforce 데이터 가상화는 다른 모델을 제공합니다. Salesforce로 데이터를 이동하는 대신 Salesforce에서 복제 없이 런타임 시 소스에서 직접 데이터를 쿼리할 수 있습니다. 사용자는 표준 Salesforce 인터페이스를 통해 실시간 외부 데이터를 볼 수 있습니다. 데이터는 원래 출처를 벗어나지 않습니다. 이 문서에서는 패턴이 어떻게 작동하는지, 언제 사용해야 하는지, 그리고 어떻게 시작하는지에 대해 설명하며, 구체적인 예로 Snowflake를 사용합니다.

Salesforce 데이터 가상화는 Salesforce에서 데이터를 복사하거나 Salesforce 저장소에 복제하지 않고 런타임 시 외부 시스템에서 직접 데이터를 쿼리할 수 있는 통합 아키텍처 패턴입니다. 데이터를 이동하는 대신 플랫폼에서 쿼리를 보냅니다.

따라서 Salesforce 사용자는 권한이 있는 소스 시스템에 유지되는 동안 익숙한 Salesforce 인터페이스(예: 페이지 레이아웃, 관련 목록, 보고서 또는 플로)를 통해 외부 데이터와 상호 작용합니다. 거버넌스, 액세스 제어, 데이터 위치는 원래 위치에 그대로 유지됩니다.

이 패턴은 데이터가 소스에 남아 있다는 단일 아키텍처 원칙에 기반합니다. 계산이 데이터로 이동됩니다.

대부분의 엔터프라이즈 Salesforce 배포는 복제 파이프라인을 통해 외부 데이터 플랫폼(예: 데이터 웨어하우스, 운영 데이터베이스 또는 분석 스토어)과 통합됩니다. 파이프라인은 일정에 따라 데이터를 추출, 변환, Salesforce에 로드합니다. 이 접근 방식은 작동하지만 복제 시 구조적 제약이 발생합니다.

• 복제된 데이터는 항상 지연됩니다. 파이프라인은 지연을 초래하고, 오래된 데이터는 잘못된 결정을 유도합니다.
• 데이터의 사본이 늘어날수록 규정 준수 범위가 확대됩니다. 여러 시스템에서 개인 식별 정보, 재무 기록 또는 건강 데이터와 같은 중요한 데이터는 다중 거버넌스 정책을 유지해야 합니다.
• 파이프라인은 지속적인 운영 투자, 모니터링, 오류 처리, 스키마 드리프트 관리, 재처리 논리가 필요합니다.

데이터 가상화는 이러한 제약 사항을 직접 해결합니다. 읽기 작업이 많은 사용 사례에 대해 파이프라인을 완전히 제거하고, 데이터를 원래 출처에 유지하며, Salesforce 사용자에게 복제 오버헤드 없이 실시간으로 관리되는 외부 데이터 보기를 제공합니다.

외부 개체는 데이터 가상화가 Salesforce 내에서 외부 데이터를 표시하는 기본 메커니즘입니다. SOQL을 통해 쿼리 가능, 페이지 레이아웃 및 관련 목록에 표시, 표준 Salesforce API를 통해 액세스할 수 있는 표준 Salesforce 개체와 같은 방식으로 동작합니다. 중요한 차이점은 Salesforce에 데이터가 저장되지 않는다는 것입니다. 외부 개체는 스키마 프로젝션으로, 데이터 자체의 사본이 아니라 외부 데이터가 어떻게 생겼는지에 대한 정의입니다.

사용자가 페이지를 로드하거나 외부 개체를 참조하는 보고서를 실행하면 Salesforce가 외부 시스템에 대한 실시간 쿼리를 실행하고 해당 상호 작용에 대해 설정된 결과만 반환합니다.

Salesforce가 외부 개체에 대한 SOQL 쿼리를 실행하면 필터(WHERE 절), 정렬 순서(ORDER BY), 제한(LIMIT)를 등가 SQL로 번역하고 외부 시스템으로 보냅니다. 외부 시스템이 자체 계산 엔진에서 쿼리를 실행하고 필터링된 결과 집합만 반환합니다. 데이터가 있는 위치에서 작업이 수행되며, 오직 결과만이 Salesforce로 전달됩니다.

데이터 가상화는 두 개의 독립적인 보안 계층을 동시에 적용합니다. 외부 시스템은 행 수준 보안, 열 마스킹, 역할 기반 액세스를 포함하여 쿼리 실행 시간에 자체 액세스 제어를 적용합니다. Salesforce는 프로필, 권한 집합, 필드 수준 보안, 공유 규칙 등 자체 보안 모델을 추가로 적용합니다. 두 계층이 모두 모든 쿼리에서 활성화됩니다. 둘 다 다른 항목을 대체하지 않습니다.

설계자는 데이터 가상화를 “제로 카피” 패턴으로 흔히 설명합니다. 제로 카피는 Salesforce 저장소에 지속적인 복제를 하지 않음을 의미합니다. Salesforce 개체에 레코드를 작성하는 ETL 파이프라인이 없습니다. 로컬 사본 생성에 예약된 동기화가 없습니다. 외부 개체에는 행이 없습니다.

제로 카피는 데이터 전송이 전혀 없다는 뜻은 아닙니다. 사용자가 외부 개체를 쿼리할 때마다 결과 집합이 네트워크를 통해 외부 시스템에서 Salesforce로 이동합니다. 대규모 결과 집합이거나 쿼리 빈도가 높을 경우, 데이터 출력 비용과 네트워크 대기 시간은 설계자가 반드시 고려해야 할 실제 요소입니다. 이는 숨길 제한 사항이 아니라 고려해야 할 설계 제약입니다.

사용 사례에 대용량, 자주 액세스하거나 대기 시간이 낮은 경우 이러한 아키텍처적 차이점을 고려하십시오.

Snowflake는 데이터 가상화를 통해 Salesforce에 연결되는 가장 일반적인 외부 시스템 중 하나입니다. 패턴이 끝에서 끝까지 작동하는 방식을 구체적으로 보여줍니다.

이 구성에서 Salesforce는 Snowflake용 SQL 어댑터와 함께 Salesforce Connect를 사용하여 Snowflake에 연결합니다. Snowflake 테이블 및 보기는 Salesforce에서 외부 개체로 표시됩니다. 사용자가 외부 개체를 쿼리하면 Salesforce가 SOQL을 SQL로 번역하고 인증된 HTTPS 콜아웃을 통해 Snowflake 문 API에 제출합니다. Snowflake는 가상 웨어하우스에서 쿼리를 실행하고 자체 행 수준 보안 및 열 마스킹을 적용하며 결과 집합만 반환합니다. 어떠한 시점에서도 Salesforce 저장소에 데이터가 기록되지 않습니다.

Salesforce Connect 위임받은 OAuth 2.0 모델을 사용하여 Snowflake를 통해 인증합니다. 주요 구성 요소는 다음과 같습니다.

• 인증 공급자: Snowflake와의 OAuth 핸드셰이크를 관리합니다. 토큰 요청을 처리하고 반환된 토큰을 Salesforce 자격 증명에 매핑합니다.
• 외부 자격 증명: Salesforce 암호화된 자격 증명 저장소에 OAuth 액세스 및 새로 고침 토큰을 안전하게 보관하고 아웃바운드 콜아웃에 삽입합니다.
• 명명된 자격 증명: Snowflake 끝점 URL을 정의하고 외부 자격 증명을 참조합니다.
• Snowflake 보안 통합: Snowflake에서 Salesforce를 신뢰할 수 있는 OAuth 클라이언트로 등록합니다. 허용된 리디렉션 URI, OAuth 플로, 토큰 TTL을 정의합니다.

다음 구성 요소는 종속성 체인을 구성합니다. 외부 데이터 소스는 인증 공급자를 참조하는 외부 자격 증명을 참조하는 명명된 자격 증명을 참조합니다. 연결 문제 또는 액세스 실패를 해결할 때 이 체인을 이해해야 합니다.

Salesforce는 Snowflake로 인증할 때 다음 두 가지 ID 위임 모델을 지원합니다.

• 명명된 주체: 하나의 공유 서비스 계정이 모든 Salesforce 사용자를 Snowflake에 대해 인증합니다. 구성하기가 더 간단하지만 사용자별 감사 기능 또는 세분화된 Snowflake 액세스 제어가 없습니다.
• 사용자당 주체: 각 Salesforce 사용자는 자체 OAuth 토큰을 사용하여 인증합니다. 이렇게 하면 Snowflake 행 수준 보안 및 전체 사용자별 감사 추적이 활성화되며, 토큰 관리 오버헤드(사용자당 OAuth 플로우, 새로 고침, 취소)가 증가합니다.

결정 지침: 규제된 데이터 또는 개인 식별 정보(PII)에 사용자별 주체를 사용합니다. Salesforce 공유 규칙이 충분한 액세스 제어를 제공하고 단순성이 우선순위인 경우 명명된 주체를 사용합니다.

Snowflake를 사용하는 외부 개체를 사용할 때 다음 Salesforce 거버너 제한이 솔루션 설계에 직접적인 영향을 미칩니다:

• 콜아웃 제한: Apex 트랜잭션당 100개. 외부 개체 쿼리가 여러 개 있는 페이지 또는 플로는 이 제한에 빠르게 도달할 수 있습니다.
• 콜아웃 시간 초과: 최대 120초입니다. 장기 실행 Snowflake 쿼리로 인해 런타임 예외가 발생합니다.
• SOQL 행 제한: 행 50,000개 대규모 결과 집합을 페이지로 나누십시오.
• 비동기 제약: 배치 Apex 및 대부분의 비동기 컨텍스트는 콜아웃을 제한합니다. 동기식 트랜잭션 경계 내에서 외부 개체 액세스를 유지합니다. 외부 개체를 쿼리하는 비동기 사용 사례의 경우, 사용자 주도 비동기 상호 작용을 위한 연속 콜아웃을 고려하거나, 외부 데이터 접근을 동기 트랜잭션에서 수행하고 결과를 비동기적으로 전달하도록 플로우를 설계하십시오.

설계 지침: 루프 내에서 외부 개체를 쿼리하지 마십시오. WHERE 절 필터를 Snowflake로 푸시하여 결과 크기 및 콜아웃 주기를 줄입니다.

Salesforce가 Snowflake로 보내는 모든 쿼리는 대기 시간, 스캔된 행, 웨어하우스 사용, 실행 중인 ID와 같은 전체 실행 메타데이터를 사용하여 Snowflake 쿼리 내역에 기록됩니다. 이 내역은 Salesforce 사용자 작업에서 Snowflake 실행에 이르는 전체 감사 기능을 제공하며 성능 튜닝 및 액세스 검증을 위한 기본 진단 도구입니다.

데이터 가상화는 실시간 액세스, 거버넌스, 복제 오버헤드 감소의 이점이 연합 쿼리 시 액세스 모델의 제약을 능가하는 사용 사례에 적합합니다.

사용할 때:

• 읽기 중심의 분석 액세스가 주요 요구 사항입니다. 사용자가 Salesforce UI, 보고서 또는 플로우에서 외부 데이터를 쿼리하고 표시하며, 쓰기 작업은 필요하지 않은 경우, 데이터 가상화는 읽기 전용 시나리오에서 파이프라인 오버헤드를 제거합니다.
• 데이터 신선함은 매우 중요합니다. 복제되지 않는 데이터가 비즈니스 위험(예: 기한 경과 재무 잔액, 재고 수준 또는 규정 준수 상태)을 야기하는 경우 연합 모델은 모든 쿼리에 실시간 데이터가 반영되도록 보장합니다.
• 정부 및 데이터 보존 요구 사항은 엄격합니다. 규제 또는 계약상의 제약으로 인해 중요한 데이터를 Salesforce로 복사할 수 없는 경우, 가상화는 데이터를 원천 위치에 그대로 유지하면서 Salesforce 내에서 접근 가능하게 합니다. 한 시스템만 데이터를 보관합니다.
• 이중 계층 액세스 제어가 필요합니다. 외부 시스템의 기본 액세스 제어와 Salesforce 보안 모델이 동시에 적용되면 데이터 중복 없이 연합 모델이 모두 적용됩니다.
• 외부 시스템은 이미 권한 있는 기록 시스템입니다. 데이터가 이미 소스 시스템에서 정리되고 관리되며 쿼리 가능한 경우, 가상화하면 중복 변환, 저장 비용, 불일치 위험을 방지할 수 있습니다.

피해야 할 경우:

• 낮은 지연의 쓰기가 필요합니다. 외부 개체는 읽기 전용입니다. 쓰기 저장 사용 사례에는 다른 통합 패턴이 필요합니다.
• 복잡한 다중 객체 조인이 필요합니다. 다중 외부 개체 전반의 SOQL은 조인을 지원하지 않습니다. 소스 시스템에서 조인된 데이터를 하나의 뷰로 미리 물리적 구체화합니다.
• Salesforce AI 또는 Agentforce 기능에는 네이티브 데이터가 필요합니다. 현재 Einstein 및 Agentforce 기능(Einstein Copilot의 기반 기능, 예측 점수 매기기 및 Agentforce 작업 포함)은 기본 Salesforce 개체에서 작동합니다. 이러한 기능은 외부 개체를 기반 데이터 소스 또는 활성화 데이터 소스로 지원하지 않습니다. 이 데이터에 대한 AI 활성화 범위가 있는 경우 Salesforce Data 360은 보완 솔루션으로 권장됩니다.
• 고주파수, 대용량 액세스 패턴. 외부 개체는 주문형 액세스를 위해 고안되었습니다. 분당 수백 개의 쿼리를 실행하는 워크로드는 거버너 제한을 소진시키고 성능을 저하시킵니다.

다음 사용 사례는 일반적인 엔터프라이즈 시나리오에서 Salesforce 데이터 가상화가 적용되는 방식을 설명합니다. 각 예에서는 Snowflake를 외부 시스템으로 사용하지만, 기본 패턴은 Salesforce Connect 지원하는 모든 SQL 호환 데이터 소스에 적용됩니다.

도전: 지원 팀은 Snowflake에 저장된 티켓 볼륨, 해결 시간, 에스컬레이션 메트릭과 Salesforce 사례 데이터를 결합하는 통합 보고서가 필요했습니다. 이 데이터에 대한 복제 파이프라인을 구축하고 유지 관리하는 과정에서 지연이 발생하고, 읽기 전용 보고 사용 사례에 운영 오버헤드가 추가되었습니다.

솔루션: 팀은 Salesforce에서 티켓 메트릭을 외부 개체로 포함하는 Snowflake 보기를 노출했습니다. 팀은 기본 사례 개체와 외부 티켓 데이터를 조인하도록 Salesforce 보고서를 구성했습니다.

결과:

• 보고서는 항상 실시간 Snowflake 데이터를 반영합니다. 파이프라인 지연 없음.
• 중요한 지원 메트릭의 거버넌스는 Snowflake에 그대로 유지됩니다.
• 구축, 모니터링 또는 유지 관리할 ETL 파이프라인이 없습니다.

도전: 재무 팀은 Snowflake에서 권위 있는 신용 한도 및 잔액 데이터를 유지했습니다. 역 ETL을 통해 해당 값을 Salesforce에 복제하면 복제 지연이 발생하여 세일즈 담당자가 오래된 신용 정보를 기반으로 거래를 체결하게 됩니다. 규정 준수 팀은 Salesforce 저장소에 중요한 금융 데이터를 보관하는 것의 위험성을 지적했습니다.

솔루션: 팀은 Snowflake 금융 보기를 외부 개체로 가상화하고 계정 페이지 레이아웃에 표시했습니다. 이제 세일즈 담당자가 Salesforce의 표준 계정 보기의 일부로 실시간 크레딧 상태를 볼 수 있습니다.

결과:

• 모든 계정 페이지의 실시간 크레딧 데이터 지연 없음.
• 재무 데이터에 대한 역 ETL 파이프라인이 제거됩니다.
• 중요한 금융 데이터는 Salesforce 저장소에 복사되지 않습니다. 규정 준수 범위는 Snowflake에 유지됩니다.

도전: 합병 시 인수 회사는 Salesforce 사용자에게 트랜잭션, 청구, 사용량을 다루는 6개의 대용량 Snowflake 데이터 집합의 운영 데이터를 제공해야 했습니다. 테라바이트의 데이터를 Salesforce에 복제하는 것은 병합 타임라인에서 실현되지 않았으며, 각 데이터 집합에 대한 사용자 정의 ETL 파이프라인을 구축하려면 상당한 엔지니어링 투자가 필요했습니다.

솔루션: 팀은 Salesforce Connect를 사용하여 모든 6개의 Snowflake 데이터 집합에 대해 최소 권한 통합 역할로 외부 개체를 구성했습니다. 사용자 정의 코드가 필요하지 않습니다. 쿼리는 Snowflake에서 직접 실행되며 모든 활동은 규정 준수 보고를 위해 Snowflake 쿼리 내역에 기록됩니다.

결과:

• 완전히 선언적 구성입니다. 사용자 정의 코드 또는 파이프라인이 필요하지 않습니다.
• 데이터의 최신성이 보장됩니다. 모든 쿼리는 실행 시 실시간 Snowflake 데이터를 반영합니다.
• 전체 감사 추적이 Snowflake 쿼리 내역에 기록되어 규제 및 규정 준수 보고에 활용됩니다.

데이터 가상화는 고유한 운영 프로필을 도입합니다. 다음 실패 시나리오에 맞게 설계합니다.

• OAuth 토큰 만료: 토큰의 유효 기간은 TTL입니다. 만료된 토큰으로 인해 콜아웃이 실패합니다. 401 승인되지 않은 응답을 모니터링하고 새로 고침 논리를 구현합니다.
• 웨어하우스 콜드 스타트(Snowflake별): 자동 정지 웨어하우스는 첫 번째 쿼리에서 5~30초를 더합니다. 대기 시간이 필요한 사용자 대면 사용 사례의 경우 업무 시간 동안 예약된 경량 쿼리로 미리 워밍업합니다.
• 역할 불일치: 외부 시스템에서 잘못 구성된 역할은 오류가 아닌 0개의 행을 자동으로 반환할 수 있습니다. Salesforce와 독립적으로 외부 시스템에서 역할 대 개체 권한을 확인합니다.
• 결과 집합 오버플로우: 대용량 페이로드가 API 제한을 초과합니다. 항상 LIMIT 절을 적용하고 원시 테이블 대신 필터링된 보기를 노출하십시오.
• 외부 시스템 중단: 대체 또는 캐시가 없습니다. try/catch 구문으로 콜아웃을 감싸고 UI에 정보성 오류 상태를 표시합니다. 미션 크리티컬 데이터의 경우 실시간 액세스를 위해 가상화하고 소스 시스템 중단 시 가용성을 보장하기 위해 가장 중요한 필드에 대한 경량 복제 대체를 유지하는 계층화된 접근 방식을 고려하십시오.

Salesforce 데이터 가상화는 Salesforce 올바르게 설계된 프레임워크의 다음 기둥에 부합합니다.

• Trust: 위임받은 OAuth 2.0 모델 및 최소 권한 역할 지침이 Trust 일치합니다. 이중 계층 액세스 제어(소스 시스템 + Salesforce)는 심층 방어 전략을 적용합니다.
• 신뢰성(오류 허용): 오류 모드 섹션은 신뢰성을 직접 해결합니다. 토큰 만료, 콜드 스타트, 역할 잘못된 구성, 결과 집합 오버플로, 가동 중지 처리는 각각 문서화된 해결 경로가 포함된 고유한 오류 클래스를 나타냅니다.
• 신뢰성(확장성): 쿼리 푸시다운, 웨어하우스 크기 지정 지침, 콜아웃 제한 인지도는 Salesforce 총괄자 제약 내에서 실행 효율성을 최적화하며, 이는 대규모로 작동하는 솔루션의 신뢰성 우려입니다.
• 작업 우수성: Snowflake 쿼리 내역을 기본 관찰 가능성 도구로 사용하면 운영 우수성을 지원합니다. 설계자는 사용자 정의 로깅 인프라를 구축하는 대신 플랫폼 네이티브 도구를 사용하여 종단간 감사 가능성 및 성능 진단을 수행할 수 있습니다.

이 섹션은 설계자 및 디자이너에게 Sandbox 환경에서 데이터 가상화 패턴을 구축하기 위한 구조화된 시작 지점을 제공합니다. 이 가이드는 완전한 구현 가이드가 아니며, 첫 번째 개념 증명을 안내하기 위한 검증된 결정 및 구성 단계의 순서로 간주해야 합니다.

구성 작업을 시작하기 전에 다음을 확인하십시오.

• 라이센스 권한: Salesforce Connect는 모든 Salesforce Edition에 포함되어 있지 않습니다. Snowflake용 SQL 어댑터는 기본 Salesforce Connect 권한 외에 별도의 추가 기능 라이센스가 필요합니다. 진행하기 전에 조직에서 둘 다 확인하십시오.
• Sandbox 먼저: 프로덕션으로 구성을 승격하기 전에 Sandbox 환경의 모든 단계를 완료합니다.
• 스노우플레이크 액세스: Snowflake에서 보안 통합을 만들고 대상 데이터베이스, 스키마, 개체에 액세스할 수 있는 권한이 있는지 확인합니다.
• 어댑터 버전: 조직 에디션에서 Snowflake용 SQL 어댑터를 사용할 수 있는지 확인하고, Snowflake 계정 URL에 밑줄이 포함되어 있지 않은지 확인하십시오(포함되어 있다면 하이픈으로 대체하십시오). 이는 Salesforce 플랫폼의 콜아웃 호스트 이름 해결을 위한 제약 조건입니다.

Snowflake와 같은 외부 SQL 시스템으로 데이터 가상화를 설정하는 것은 선언적이고 구성 중심의 프로세스이며, 사용자 정의 코드가 필요하지 않습니다. 설정은 세 가지 연속 단계를 따릅니다: ID 및 신뢰 설정, 데이터 표면 구성, 그리고 최종 사용자에게 데이터 노출.

이 단계에서는 Salesforce와 외부 시스템 간에 안전한 위임된 OAuth 2.0 Trust 체인을 설정합니다. 데이터 표면 구성을 시작하기 전에 이 단계를 완료하십시오.

1. Salesforce에서 인증 공급자 만들기. OpenID Connect 유형을 사용합니다. 이 단계에서 자리 표시자 값을 사용합니다. 외부 시스템에서 값을 검색한 후 완료로 돌아갑니다. 저장하면 Salesforce에서 콜백 URL을 생성합니다. 이 값을 유지합니다.
2. 외부 시스템에서 Salesforce를 OAuth 클라이언트로 등록합니다. Snowflake에서 이는 보안 통합(OAuth, Confidential Client 유형) 생성을 의미합니다. Salesforce 콜백 URL을 리디렉션 URI로 제공합니다. 생성 후 통합에서 클라이언트 ID, 클라이언트 암호, 인가 URL, 토큰 URL을 검색합니다.
3. 인증 공급자 구성을 완료합니다. Salesforce 인증 공급자로 돌아가 외부 시스템에서 검색된 값으로 채웁니다. 소비자 키, 소비자 암호, 인가 URL, 토큰 URL.
4. 외부 자격 증명을 만듭니다. 프로토콜을 OAuth 2.0으로 설정하고 인증 공급자에 연결한 다음 주체(ID 모델 결정에 따라 명명됨 또는 사용자별)를 추가합니다. 이 개체는 OAuth 토큰 수명 주기를 관리합니다.
5. 명명된 자격 증명을 만듭니다. 끝점을 외부 시스템의 API URL(예: https://<account>.snowflakecomputing.com/api/v2/statements/)으로 설정하고 외부 자격 증명에 연결합니다.
6. 외부 자격 증명에 대한 프로필 액세스 권한을 부여합니다. 이 단계를 수행하지 않으면 다른 모든 구성이 올바르더라도 사용자가 연합 쿼리를 호출할 수 없습니다.
7. OAuth 플로를 시작하여 인증을 완료합니다. Salesforce에서 OAuth 핸드셰이크를 트리거합니다. 플랫폼이 외부 시스템 로그인으로 리디렉션되고 자격 증명을 확인하며 결과 토큰을 외부 자격 증명에 안전하게 저장합니다. 이 단계는 유효한 토큰에 사용자 컨텍스트를 바인딩합니다. 이 단계가 완료될 때까지 모든 연합 쿼리가 실패합니다.

이 단계에서는 Salesforce를 외부 데이터 스키마에 연결하고 사용자 및 플랫폼에서 쿼리하는 외부 개체 정의를 만듭니다.

1. 외부 데이터 소스를 만듭니다. 적절한 어댑터(예: Snowflake용 SQL 어댑터)를 선택하고 대상 데이터베이스 및 스키마를 가리킨 다음, 1단계에서 만든 명명된 자격 증명에 연결합니다.
2. 연결을 확인합니다. 외부 데이터 소스에 내장된 유효성 검사를 사용합니다. 성공적인 결과는 OAuth 신뢰 체인이 완료되었으며 외부 시스템에 접근할 수 있음을 확인합니다.
3. 메타데이터를 동기화합니다. 외부 데이터 소스에서 메타데이터 동기화를 시작합니다. Salesforce가 대상 스키마를 검사하고 외부 개체 정의를 생성하여 외부 열을 Salesforce 필드 유형에 매핑합니다.
4. 필요한 테이블 또는 보기를 선택하고 표시합니다. 외부 개체로 표시할 외부 테이블 또는 보기를 선택합니다. 가장 좋은 방법은 원시 테이블 대신 선별된 보기를 표시하는 것입니다. 보기를 사용하면 열 사전 필터링, 행 수준 제한 및 Salesforce 레이어가 액세스할 수 있는 항목을 더 엄격하게 제어할 수 있습니다.

이 단계에서는 Salesforce Lightning Experience 내의 최종 사용자가 외부 개체를 볼 수 있고 사용할 수 있게 합니다.

1. 외부 개체에 대한 탭을 만듭니다. 탭을 사용하면 Lightning 앱 내에서 외부 개체를 직접 탐색할 수 있습니다.
2. 페이지 레이아웃에 외부 개체 추가. 기본 Salesforce 레코드와 함께 관련 외부 데이터를 표시합니다(예: 계정 페이지 레이아웃에 Snowflake 금융 보기를 추가).
3. 관련 목록에 추가하기. 관련 목록에 외부 개체를 포함하여 사용자에게 컨텍스트에서 기본 및 외부 데이터의 통합 보기를 제공합니다.
4. 엔드 투엔드 쿼리 연합을 확인합니다. 페이지를 로드하거나 외부 개체를 참조하는 쿼리를 실행합니다. 그런 다음, 외부 시스템의 쿼리 내역(예: Snowflake 쿼리 내역)을 검사하여 쿼리가 소스에서 실행되었는지 확인합니다. 올바른 역할, 창고, ID가 쿼리를 실행했는지 확인합니다.

세 가지 단계 모두 완료되면 Salesforce 사용자는 데이터가 Salesforce 외부에서 생성되었음을 인식하지 않고 표준 Salesforce 인터페이스를 통해 실시간 외부 데이터와 상호 작용할 수 있습니다.

Salesforce 데이터 가상화는 복제 기반 통합을 쿼리 시간 연합으로 대체합니다. 데이터는 권한 있는 소스에 유지되며 Salesforce 사용자는 표준 플랫폼 인터페이스를 통해 상호 작용합니다. 구축할 파이프라인, 관리할 복사본, 관리할 지연이 없습니다.

이 패턴은 읽기 위주의 액세스, 실시간 데이터 신선도, 엄격한 거버넌스, 이중 계층 액세스 제어가 주요 동인인 경우에 적합한 선택입니다. 쓰기가 필요하거나 AI 또는 자동화 기능이 기본 Salesforce 개체에 의존하는 경우, 또는 액세스 패턴의 빈도가 너무 높아 거버너 제한으로 감당할 수 없는 경우에는 적절하지 않은 선택입니다.

Snowflake는 사용자 정의 코드 없이 선언적으로 설정된 쿼리 시간 연합 연결, Snowflake 쿼리 내역을 통한 종단 간 관찰, 그리고 Snowflake 기본 액세스 제어와 전체 Salesforce 보안 모델을 통한 적용 등 이 패턴을 잘 보여줍니다.

이 아키텍처를 커밋하기 전에 라이센스 권한을 확인하고, 예상 액세스 패턴에 대한 총괄자 제한 노출을 평가하고, Sandbox 환경에서 OAuth 준비 상태를 확인합니다. 이 패턴은 신중한 사전 설계의 이점을 제공합니다: ID 모델, 자격 증명 체인, 뷰 전략을 올바르게 구축하면 운영 부담이 최소화됩니다.

Yugandhar Bora는 Salesforce의 소프트웨어 엔지니어링 아키텍처로, 데이터 및 인텔리전스 애플리케이션 플랫폼 내 데이터 아키텍처를 전문으로 합니다. 그는 데이터 거버넌스 및 통합 데이터 모델에 초점을 맞춘 EARB(엔터프라이즈 아키텍처 검토 위원회) 이니셔티브를 이끌고 자동화된 플랫폼 프로비저닝 솔루션에 기여합니다.