데이터 가상화(Data Virtualization)

1. 개요

가. 정의

데이터 가상화(Data Virtualization)는 물리적으로 흩어져 있는 이기종 데이터 원천을 복제·이동하지 않고, 실시간 연결·질의를 통해 하나의 논리적 가상 데이터 계층(virtual data layer)으로 통합해 소비자에게 단일 뷰로 제공하는 데이터 통합 기술이자 아키텍처 패턴이다.

데이터 가상화의 핵심은 "데이터를 옮겨 와서 합치는 것"이 아니라 "데이터를 있는 자리에 둔 채 질의 시점에 가상으로 합치는 것"이다. 전통적 통합이 ETL(Extract-Transform-Load)로 원천 데이터를 추출·변환해 데이터 웨어하우스(DW)에 물리 사본으로 적재했다면, 데이터 가상화는 메타데이터 기반의 가상 뷰(view)만 정의해 두고 실제 데이터는 소비자가 질의하는 순간에 원천에서 끌어와 결합·가공해 돌려준다. 따라서 데이터 가상화는 저장 공간을 늘리는 기술이 아니라 접근(access)과 통합(integration)의 추상화 계층을 제공하는 기술이며, 소비자는 원천이 Oracle인지, 클라우드 객체 스토리지인지, SaaS API인지 알 필요 없이 표준 SQL이나 REST/GraphQL로 하나의 데이터처럼 다룬다.

이 때문에 데이터 가상화는 흔히 논리적 데이터 웨어하우스(Logical Data Warehouse)를 구현하는 핵심 수단으로 이해되며, 물리적 통합(DW·데이터 레이크)과 상호 배타적 기술이 아니라 이들을 함께 묶어 추상화하는 상위 계층으로 자리한다.

나. 등장 배경과 필요성

첫째, 데이터의 폭발적 분산과 멀티클라우드화이다. 기업 데이터는 온프레미스 DW, 복수의 퍼블릭 클라우드, SaaS(예: Salesforce·SAP), 데이터 레이크, 운영 DB로 흩어졌고, 이를 모두 하나의 물리 저장소로 모으는 전략은 복제 비용과 적재 지연, 데이터 중복으로 인한 정합성 훼손을 초래했다. 데이터를 옮기지 않고도 통합 뷰를 제공하는 접근이 필요해졌다.

둘째, 실시간성·신선도(freshness) 요구의 증가이다. 배치 ETL은 수 시간~하루 주기로 적재되므로 적재 지연만큼 데이터가 낡는다. 실시간 리스크 모니터링, 360도 고객 뷰처럼 지금 이 순간의 원천 상태가 필요한 업무에서는 질의 시점에 원천을 직접 조회하는 가상화가 더 적합하다.

셋째, 데이터 복제의 비용·거버넌스 부담이다. 동일 데이터가 여러 사본으로 흩어지면 저장 비용뿐 아니라 "어느 사본이 정본인가", "개인정보 사본이 어디까지 퍼졌는가"라는 거버넌스 문제가 커진다. 가상화는 사본을 최소화해 단일 접근 지점에서 정책을 일관되게 집행할 수 있게 한다.

넷째, 셀프서비스 분석과 가치 실현 속도(time-to-value)이다. 새 분석 요구가 생길 때마다 ETL 파이프라인을 신규 개발하면 수주가 걸리지만, 가상 뷰는 메타데이터 정의만으로 수일 내에 제공할 수 있어 비즈니스 민첩성을 높인다.

2. 아키텍처와 핵심 구성요소

데이터 가상화 플랫폼은 다양한 물리 원천 위에 연결 → 추상화(가상 뷰) → 질의 최적화 → 전달의 논리 계층을 쌓아 올린 구조로 이해할 수 있다. 아래 개념도는 원천부터 소비까지의 전체 구조를 보여준다.

graph TD
    subgraph SRC["데이터 원천(이기종·분산)"]
        S1["관계형 DB<br/>(Oracle·MySQL)"]
        S2["클라우드 DW<br/>(Snowflake·BigQuery)"]
        S3["데이터 레이크<br/>(S3·HDFS)"]
        S4["SaaS/API<br/>(Salesforce·REST)"]
    end
    subgraph DV["데이터 가상화 계층"]
        C["연결/어댑터(Connector)"]
        B["기본 뷰(Base View) 추상화"]
        D["파생 뷰(Derived View)/시맨틱 모델"]
        O["질의 최적화 엔진"]
        G["보안·거버넌스·캐시"]
    end
    subgraph CON["데이터 소비자"]
        U1["BI/리포팅"]
        U2["데이터 분석/AI"]
        U3["애플리케이션(API)"]
    end
    S1 --> C
    S2 --> C
    S3 --> C
    S4 --> C
    C --> B --> D --> O --> G
    G --> U1
    G --> U2
    G --> U3

가. 연결/어댑터 계층은 이기종 원천에 접속하는 커넥터 집합이다. 각 원천의 드라이버(JDBC/ODBC), API, 파일 포맷을 흡수해 플랫폼 내부의 공통 표현으로 바꾼다. 이 계층 덕분에 상위 계층은 원천의 물리적 차이를 알 필요가 없고, 새 원천이 추가돼도 상위 뷰를 바꾸지 않아도 된다. 실무에서는 수십 종의 원천을 사전 제공 커넥터로 흡수하며, 커넥터가 없는 경우 범용 REST/SQL 어댑터로 확장한다.

나. 추상화(가상 뷰) 계층은 데이터 가상화의 심장이다. 원천 테이블을 1:1로 비추는 기본 뷰(base view) 위에, 조인·필터·변환·집계를 적용한 파생 뷰(derived view)를 쌓고, 최종적으로 업무 용어로 정리한 시맨틱 모델(비즈니스 뷰)을 만든다. 예컨대 Oracle의 CUST 테이블과 Snowflake의 ORDERS를 조인한 "고객_주문통합" 뷰를 정의해 두면, 소비자는 물리 위치를 모른 채 이 뷰 하나만 질의한다. 뷰는 물리 적재가 없으므로 정의 변경이 즉시 반영되고, 원천 스키마가 바뀌어도 뷰 매핑만 고치면 소비자 영향이 격리된다.

다. 질의 최적화 엔진은 성능을 좌우하는 핵심이다. 가상 뷰 질의는 여러 원천에 분산 실행되므로, 네트워크로 대량 데이터를 끌어오면 성능이 급락한다. 이를 막기 위해 푸시다운(pushdown) 최적화로 필터·집계·조인을 가능한 한 원천 측에서 수행시키고, 원천 간 조인은 비용 기반으로 실행 순서를 정한다. 뒤의 비교 절에서 푸시다운의 효과를 수치로 다룬다.

라. 보안·거버넌스·캐시 계층은 단일 접근 지점의 장점을 극대화한다. 행·열 수준 접근제어, 데이터 마스킹, 계보(lineage) 추적을 가상 계층에서 일괄 적용하고, 반복 질의는 캐시로 가속한다.

3. 질의 처리 흐름과 최적화

가상 뷰에 대한 질의가 어떻게 분해·최적화되어 실행되는지는 성능 이해의 핵심이다. 아래 시퀀스 다이어그램은 소비자 질의가 가상화 엔진에서 처리되는 과정을 보여준다.

sequenceDiagram
    participant U as 소비자·BI
    participant E as 가상화 엔진
    participant O as 최적화기
    participant A as 원천 A·DB
    participant B as 원천 B·DW
    U->>E: 가상 뷰 질의 SQL
    E->>O: 논리 질의 분해
    O->>O: 푸시다운·조인순서 결정
    O->>A: 필터/집계 위임 질의
    O->>B: 필터/집계 위임 질의
    A-->>O: 축소된 결과셋
    B-->>O: 축소된 결과셋
    O->>E: 원천 간 조인·후처리
    E-->>U: 통합 결과 반환

질의 처리는 먼저 소비자가 던진 SQL을 논리 질의 트리로 분해하는 것에서 시작한다. 최적화기는 이 트리를 분석해 어떤 연산을 어느 원천으로 밀어낼지(pushdown), 원천 간 조인을 어떤 순서로 할지, 중간 결과를 메모리에서 어떻게 결합할지 결정한다. 핵심 원리는 데이터 이동량 최소화이다. 원천에서 필터와 집계를 먼저 수행해 네트워크로 넘어오는 행 수를 줄여야 한다.

예를 들어 1억 건의 거래 테이블(원천 B)과 10만 건의 고객 테이블(원천 A)을 조인해 특정 지역 고객의 월 합계를 구하는 질의를 생각해 보자. 푸시다운이 없으면 1억 건을 모두 엔진으로 가져와 조인·집계해야 하지만, 지역 필터와 월별 집계를 원천 B에 위임하면 수천 건 수준으로 축소된 결과만 전송되어 네트워크 전송량과 응답 시간이 수십 배 개선될 수 있다. 이처럼 가상화의 성능은 "얼마나 많은 일을 원천으로 밀어내는가"에 달려 있으며, 원천이 집계를 지원하지 않거나 조인 키 통계가 부정확하면 최적화 효과가 제한된다.

캐시 전략도 함께 고려해야 한다. 자주 조회되지만 원천 부하가 큰 뷰는 쿼리 캐시나 구체화 캐시(materialized cache)로 결과를 저장해 재사용하고, 신선도가 중요한 뷰는 캐시를 끄거나 TTL을 짧게 둔다. 즉 가상화는 "완전 무복제"가 아니라 성능과 신선도의 트레이드오프를 뷰 단위로 조절하는 기술이다.

4. 전통적 통합(ETL/DW)과의 비교

데이터 가상화와 물리적 통합의 차이는 단순한 기술 선택이 아니라 데이터를 언제·어디서 결합하는가라는 설계 철학의 차이에서 비롯된다. ETL/DW는 데이터를 미리(적재 시점) 결합해 사본을 만들어 두므로 복잡한 대규모 집계·과거 이력 분석에 강하지만, 적재 지연과 복제 비용을 수반한다. 반대로 가상화는 질의 시점에 결합하므로 신선도와 민첩성에 강하지만, 원천 성능·가용성에 종속되고 초대규모 반복 집계에는 불리할 수 있다.

구분	데이터 가상화	ETL/데이터 웨어하우스
데이터 결합 시점	질의 시점(on-demand)	적재 시점(사전)
물리 사본	최소(캐시만)	전체 복제
데이터 신선도	높음(실시간)	배치 주기만큼 지연
구축 속도	빠름(뷰 정의)	느림(파이프라인 개발)
대규모 반복 집계	상대적으로 불리	유리
원천 부하	질의마다 발생	적재 시 1회

실무에서는 둘을 대립이 아닌 보완 관계로 설계한다. 예컨대 과거 3년치 정형 데이터는 DW에 물리 적재하고, 최신 운영 데이터와 SaaS 데이터는 가상화로 실시간 연결한 뒤, 가상 계층에서 둘을 조인해 "과거 추세 + 실시간 현황"을 하나의 뷰로 제공하는 하이브리드 구성이 널리 쓰인다. 즉 가상화는 DW를 대체하기보다 DW가 미처 담지 못한 신선도와 범위를 메우는 역할을 한다.

5. 활용 사례와 산업 적용

데이터 가상화는 통합이 반복적으로 필요하면서 복제가 부담되는 산업에서 실질적 가치를 낸다.

가. 금융권의 360도 고객 뷰와 규제 보고. 은행은 계좌·카드·대출·투자 시스템이 각기 다른 DB에 분산돼 있다. 이를 물리 통합하려면 막대한 ETL과 중복 저장이 필요하지만, 가상화로 고객 식별자를 축으로 각 시스템을 가상 조인하면 실시간 통합 고객 뷰를 제공할 수 있다. 실제로 Denodo 등 상용 플랫폼은 금융권의 리스크·컴플라이언스 보고에서 여러 원천을 가상 결합해 보고 주기를 단축한 사례를 다수 보유한다.

나. 제조·공급망의 실시간 가시성. 제조업은 ERP(SAP), MES, IoT 센서 데이터가 이기종으로 존재한다. 센서 시계열은 데이터 레이크에, 자재·발주는 ERP에 있을 때, 가상화 계층에서 이를 묶어 "현재 재고 + 생산 현황 + 센서 이상"을 단일 대시보드로 제공하면 수 시간 걸리던 통합 리포트를 분 단위로 당길 수 있다.

다. 공공·헬스케어의 데이터 이동 제약 대응. 개인정보·의료정보는 법적으로 원천 밖 복제가 제한되는 경우가 많다. 데이터를 옮기지 않고 원천 자리에서 접근제어·마스킹을 적용한 채 가상 조회만 허용하면, 규제를 준수하면서도 분석 활용을 가능하게 한다.

이 세 사례의 공통점은 "데이터를 모으는 비용·위험이 통합의 가치보다 클 때" 가상화가 선택된다는 점이며, 반대로 안정적 대규모 배치 분석이 주목적이면 여전히 DW 적재가 유리하다.

6. 심화: 최신 동향과 데이터 아키텍처 속 위치

데이터 가상화는 최근 데이터 패브릭·데이터 메시 같은 상위 아키텍처 담론 안에서 재조명되고 있다. 데이터 패브릭은 능동 메타데이터와 AI 자동화로 통합을 지능화하는 개념인데, 가상화는 그 패브릭이 "데이터를 옮기지 않고 접근을 통합"하는 집행 수단으로 쓰인다. 데이터 메시에서도 도메인별 데이터 제품을 소비자가 연결해 쓰는 연합(federation) 접근과 결합돼, 가상화는 도메인 경계를 넘는 질의 계층을 제공한다.

기술적으로는 오픈소스 분산 SQL 엔진의 부상이 두드러진다. Trino(구 PrestoSQL)와 이를 상용화한 Starburst, 레이크하우스 질의에 특화된 Dremio 등은 데이터 레이크·DW·DB를 넘나드는 연합 질의(federated query)를 제공하며, 넓게 보면 데이터 가상화의 질의 엔진 계보에 속한다. 또한 레이크하우스 테이블 포맷(Apache Iceberg·Delta Lake)과 결합해, 객체 스토리지의 원시 데이터에도 가상 계층으로 트랜잭션·스키마 진화를 입히는 방향으로 진화하고 있다.

예상 출제 방향으로는 ① 데이터 가상화와 ETL/DW의 비교 및 하이브리드 설계, ② 논리적 데이터 웨어하우스 구현 수단으로서의 역할, ③ 데이터 패브릭·메시와의 관계, ④ 푸시다운·캐시 등 성능 최적화 원리와 트레이드오프가 자주 다뤄질 수 있다. 답안 구성 시에는 "복제 없는 실시간 통합"이라는 본질을 먼저 제시하고, 아키텍처 계층도와 ETL 비교표로 뼈대를 세운 뒤, 성능 한계와 그 보완책(캐시·푸시다운)을 함께 논하는 균형 잡힌 서술이 효과적이다.

7. 고려사항 및 시사점

데이터 가상화는 도입 그 자체가 목적이 아니라, 통합 전략 전반에서 물리 통합과 역할을 나누는 설계 의사결정의 문제이다.

첫째, 적용 전략(Fit-for-purpose)이다. 신선도·민첩성이 중요하고 데이터양이 중간 규모인 통합에는 가상화가 적합하나, 수 TB 이상을 반복 집계하는 분석 워크로드는 DW 적재가 유리하다. 업무 특성별로 가상화와 물리 통합을 혼합하는 하이브리드 기준을 먼저 정의해야 한다.

둘째, 성능·가용성 트레이드오프이다. 가상 질의는 원천 성능과 네트워크에 종속되고, 질의마다 원천에 부하를 준다. 따라서 운영 DB에 직접 가상 질의를 거는 것은 운영계 성능을 해칠 수 있으므로, 복제본·캐시·동시성 제한을 함께 설계하고 푸시다운 가능 여부를 원천별로 검증해야 한다.

셋째, 거버넌스·보안의 집중화 기회와 책임이다. 가상 계층은 접근제어·마스킹·계보를 한곳에서 집행할 수 있는 단일 통제점이 되지만, 동시에 이 계층이 뚫리면 전 원천이 노출되는 단일 장애·위험 지점이 된다. 최소권한·감사로그·암호화와 가용성 이중화를 반드시 수반해야 한다.

넷째, 조직·운영 성숙도와 연계 기술이다. 가상화는 메타데이터 카탈로그, 데이터 품질, 마스터데이터관리(MDM)와 함께 작동할 때 가치가 극대화된다. 또한 뷰 난립을 막는 명명·버전 관리 체계와, 원천 스키마 변경을 흡수하는 운영 프로세스가 없으면 "가상 스파게티"로 전락할 수 있으므로, 데이터 거버넌스 체계와 함께 단계적으로 도입해야 한다.

다섯째, 전망이다. 멀티클라우드·레이크하우스가 보편화될수록 데이터를 한곳에 모으는 비용은 커지고, 메타데이터 기반의 가상 접근 수요는 늘어난다. 가상화는 데이터 패브릭·메시의 집행 엔진이자 AI 학습 데이터의 실시간 공급 계층으로서 그 전략적 중요성이 커질 전망이다.

참고자료

Gartner, "Data Virtualization" (Information Technology Glossary), https://www.gartner.com/en/information-technology/glossary/data-virtualization
Denodo, "What is Data Virtualization?", https://www.denodo.com/en/data-virtualization/overview
Trino Project Documentation, https://trino.io/docs/current/
AWS, "What is Data Virtualization?", https://aws.amazon.com/what-is/data-virtualization/

한 줄 요약: 데이터 가상화는 흩어진 이기종 데이터를 복제·이동 없이 질의 시점에 가상 계층으로 실시간 통합해 단일 뷰로 제공하는 기술로, 신선도·민첩성과 거버넌스 집중화를 얻는 대신 원천 성능 종속과 대규모 반복 집계의 한계를 캐시·푸시다운·하이브리드 설계로 보완해야 한다.