데이터를 옮기지 않고 통합하는 법 — 데이터 가상화의 구조와 한계

여러 시스템에 흩어진 고객 데이터를 하나의 대시보드에서 보려면 보통 ETL 파이프라인을 짜고 웨어하우스에 복제본을 쌓는다. 데이터 가상화는 이 복제 단계를 생략한다. 소스에 있는 데이터는 그대로 두고, 그 위에 논리적 통합 계층 하나를 얹어 실시간으로 조회한다.

물리 이동 없이 통합한다는 것의 의미

데이터 가상화는 RDBMS, NoSQL, 데이터 레이크, SaaS, 스트리밍처럼 이질적인 소스를 스키마 추상화와 쿼리 최적화·푸시다운으로 묶어 단일 뷰나 API로 내보내는 기술이다. 보안·정책도 이 계층에서 중앙집중적으로 적용된다. ETL 중심의 데이터 웨어하우스가 배치 복제와 정규화로 최신성을 희생하는 대신 낮은 지연을 얻는 방식이라면, 가상화는 그 반대로 움직인다 — 복제 비용을 없애는 대신 최신성과 민첩성을 우선하는 것이다. 흔히 비교되는 데이터 페더레이션과는 개념적으로 겹치지만, 가상화는 거버넌스·캐싱·가속·API 제공까지 플랫폼화된 기능 범위로 확장된 형태에 가깝다.

이 계층을 구성하는 것은 결국 세 가지다. 비즈니스 용어 중심으로 뷰를 정의해 원천 스키마 변경에 느슨하게 결합되도록 하는 시맨틱 레이어, 필터·프로젝션·집계·조인을 소스 엔진으로 재배치하는 쿼리 옵티마이저, 그리고 RDBMS부터 스트리밍까지 스키마 매핑과 타임존·정렬 규칙을 통일하는 커넥터·페더레이션 계층이다. 여기에 단기 캐시와 머티리얼라이즈드 뷰가 TTL과 무효화 규칙으로 지연을 줄이고, ABAC/RBAC 기반 인증·인가와 열·행 수준 마스킹이 보안을 담당한다.

요청 하나가 지나가는 경로

클라이언트가 SQL이나 GraphQL로 요청을 보내면 파싱 → 정책 적용 → 플랜 최적화 → 푸시다운 → 캐시 히트 체크 순으로 처리되고, 소스별 결과가 스트리밍으로 통합돼 후처리 후 응답된다. 소스 장애가 나면 재시도 정책을 거쳐 대체 소스나 캐시로 폴백하고, 필요하면 부분 결과를 허용한다. 분산 트랜잭션은 원칙적으로 회피하되 소스별 원자성이 필요하면 보상 트랜잭션을 쓰고, 읽기 시점을 스냅샷으로 고정하고 카탈로그를 버저닝해 일관성을 유지한다.

⤢✕

ETL·복제와 비교하면 어디가 다른가

항목	데이터 가상화	ETL/데이터 웨어하우스	데이터 복제/CDC
성능(지연)	소스·네트워크 의존, 캐시로 단축 가능	배치 사전 집계로 낮은 지연	소스 근접 쿼리로 낮은 지연
확장성	수평 확장형 쿼리 엔진·커넥터 확장	스토리지·컴퓨트 분리로 확장	대상 수 증가 시 운영 복잡성 증가
일관성	읽기 시점·정책 기반, 소스별 다양	웨어하우스 내 강한 일관성	소스와 근실시간 동기, 랙 존재
안정성	소스 장애 영향, 폴백·서킷브레이커 필요	파이프라인 실패 격리 용이	네트워크/지연에 취약
운영 편의	스키마 추상화·정책 일원화	파이프라인 관리 부담 큼	증분 관리·충돌 처리 필요

실무에서는 이렇게 쓰인다

온프레미스 RDBMS와 클라우드 데이터 레이크를 조인해야 하는 하이브리드 분석에서는 규제 데이터에 행 수준 마스킹을, 민감정보에는 컬럼 마스킹을 건다. 고객·제품 마스터 데이터를 가상 뷰로 통합하는 MDM 골든 레코드 시나리오에서는 정합성 규칙을 시맨틱 레이어에 구현하고 변경 이력은 소스에 그대로 두되 조회는 스냅샷 타임스탬프 기준으로 제공한다. 분석가가 카탈로그에서 데이터셋을 검색해 가상 뷰를 골라 BI 도구에 연결하는 셀프서비스 BI에서는 반복 쿼리를 결과 캐시·머티리얼라이즈드 뷰로 최적화한다. 클라우드 마이그레이션 기간에는 신구 소스를 동시에 서비스하다 뷰 리바인딩만으로 전환을 무중단화하고, 도메인 팀이 계약 기반 스키마·SLO로 데이터 제품을 노출하는 데도 쓰인다.

숫자로 보는 효과와 트레이드오프

스키마 추상화로 무이관 전제가 성립하면 데이터 온보딩 리드타임이 5070% 단축되고, 캐시·푸시다운·조인 재배치가 맞물리면 쿼리 지연이 3060% 개선된다. 중복 저장을 줄이는 만큼 복제·스토리지 비용도 30~50% 절감된다. 다만 이 수치는 최신성과 성능(캐시), 단순성과 일관성(분산 트랜잭션 회피), 유연성과 비용(커넥터 확장) 사이의 균형을 어떻게 잡느냐에 따라 갈린다. 도메인 중심 시맨틱 레이어와 명시적 계약·버전 관리를 갖추고, 캐시·머티리얼라이즈드 뷰의 대상과 TTL을 SLA 기준으로 정의하는 것이 출발점이다.

성능 쪽에서는 푸시다운 비율(필터/집계/조인)을 계속 모니터링하고 소스에 인덱스·파티셔닝을 걸어야 하며, 크로스소스 대규모 조인은 피하고 필요하면 사전 집계나 부분 물리화로 대체한다. 보안·거버넌스는 중앙 인증(OIDC/SAML)에 카탈로그 권한, 열·행 보안·마스킹을 통합하고 감사로그·계보·데이터 품질 신호를 연계해 규제 라벨링을 적용한다. 안정성 측면에서는 서킷브레이커·재시도·폴백 정책과 소스 레이트리밋을 설정하고, P95 지연·캐시 히트율·푸시다운율·소스 부하·실패율을 관측 지표로 추적한다.

Trino로 크로스소스 뷰 만들기

Trino 425 이상을 설치하고 mysql.sales, hive.datalake 카탈로그를 구성했다는 전제로, 두 소스를 조인하는 가상 뷰는 다음처럼 만든다.

-- 가상 통합 뷰
CREATE OR REPLACE VIEW analytics.customer_orders AS
SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.amount,
  o.order_date
FROM mysql.sales.customers AS c
JOIN hive.datalake.orders AS o
  ON c.customer_id = o.customer_id
WHERE o.order_date >= DATE '2025-01-01';

-- 실행 계획 확인(푸시다운 검증)
EXPLAIN (TYPE DISTRIBUTED)
SELECT * FROM analytics.customer_orders WHERE amount > 1000;

-- 세션 튜닝 예시
SET SESSION join_reordering_strategy = 'AUTOMATIC';
SET SESSION join_distribution_type = 'AUTOMATIC';

WHERE 절에서 프루닝 가능한 컬럼에는 파티셔닝·인덱스를 부여하고, 빈번한 쿼리는 결과 캐시나 사전 집계 뷰로 옮기되 TTL은 SLA 기준으로 정한다.

운영에서 챙길 것

핵심 KPI는 P95/P99 지연, 캐시 히트율, 푸시다운율, 소스당 QPS·CPU·스캔 바이트, 실패율이다. 소스별 쿼터와 동시성 제한, 서킷브레이커 임계치, 재시도·타임아웃 정책을 경계값으로 잡아둬야 하고, 스키마 변경이 감지되면 계약 검사와 스테이지 환경 검증을 거쳐 점진적으로 릴리스하는 변경 관리 절차가 필요하다. 이질적 소스가 많고 신선도 요구가 높은 분석·서비스, 그리고 마이그레이션 공존 단계처럼 물리적 복제가 부담스러운 상황에서 데이터 가상화가 제 몫을 한다.