---
title: Delta Lake가 뭐길래 Fabric 테이블은 전부 Delta인가요
description: Fabric 레이크하우스 테이블 속성을 보면 죄다 Delta라고 써 있어요. 파케이 파일 더미에 트랜잭션 로그를 얹었을 뿐인데 왜 ACID·시간 여행이 가능해지는지, SQL 사용자 눈높이로 정리했어요.
date: 2026-09-20
  tags: [Delta Lake, Parquet, Lakehouse, 타임 트래블, Fabric]
cards:
  - /cards/fabric-delta-lake-basics-for-sql-users/card-01.png
  - /cards/fabric-delta-lake-basics-for-sql-users/card-02.png
  - /cards/fabric-delta-lake-basics-for-sql-users/card-03.png
  - /cards/fabric-delta-lake-basics-for-sql-users/card-04.png
  - /cards/fabric-delta-lake-basics-for-sql-users/card-05.png
  - /cards/fabric-delta-lake-basics-for-sql-users/card-06.png
  - /cards/fabric-delta-lake-basics-for-sql-users/card-07.png
author: Lissa
source: https://interlinear.work/notes/fabric-delta-lake-basics-for-sql-users/
---

> **원문:** [Delta Lake overview](https://learn.microsoft.com/en-us/fabric/fundamentals/delta-lake-overview)
> **게시일:** 2026-05-08 · **저자:** Sneha Gunda

Fabric 레이크하우스에 테이블을 하나 만들어보면 이상한 점을 눈치채게 돼요. 형식을 CSV로 올렸든 JSON으로 올렸든, Tables 목록에 뜨는 순간 전부 "Delta"라고 표시돼 있거든요. 웨어하우스도, 레이크하우스도, KQL 데이터베이스도 결국 같은 형식을 씁니다. 왜 Fabric은 이걸 하나로 통일했을까요.

## Delta Lake는 뭔가요 — 파케이 파일 더미 + 트랜잭션 로그

Delta Lake<sup>1</sup>는 새로운 파일 포맷이 아니에요. 이미 쓰던 **파케이(Parquet)**<sup>2</sup> 열 지향 압축 파일에, 모든 변경 내역을 기록하는 **트랜잭션 로그**를 얹은 오픈소스 저장 계층이에요. 파케이 파일만 있으면 "지금 이 폴더에 있는 파일들이 최신 상태인지, 쓰다 만 파일은 아닌지"를 파일 시스템만 보고는 알 수 없어요. 로그가 "몇 번 버전에서 이 파일들이 유효하다"는 걸 별도로 기록해두기 때문에, 여러 프로세스가 동시에 읽고 쓰는 상황에서도 무결성이 깨지지 않는 거예요.

이 조합에서 SQL 사용자에게 익숙한 개념들이 그대로 따라와요.

- **ACID 트랜잭션**: 원자성·일관성·격리성·지속성을 보장해요. 관계형 DB에서 당연하게 여기던 것들이, 파일 기반 저장소에서도 성립해요.
- **시간 여행(time travel)**: 특정 시점·버전의 테이블을 그대로 조회할 수 있어요.
- **스키마 진화(schema evolution)**: 기존 데이터를 다시 쓰지 않고도 열을 추가·삭제·변경할 수 있어요.
- **배치와 스트리밍을 같은 형식으로**: 실시간 데이터와 배치 데이터를 같은 테이블 포맷으로 다룰 수 있어요.

## 시간 여행, 실제로는 이렇게 써요

말로만 들으면 막연한데, Spark 노트북에서는 실제로 SQL 한 줄로 씁니다.

```sql
-- 5번 버전 시점의 테이블 조회
SELECT * FROM table_name VERSION AS OF 5

-- 특정 시각 기준으로 조회
SELECT * FROM table_name TIMESTAMP AS OF '2024-01-01'

-- 어떤 버전들이 남아있는지 확인
DESCRIBE HISTORY table_name
```

이게 가능한 이유가 바로 트랜잭션 로그예요. 델타 테이블은 `_delta_log` 폴더에 커밋될 때마다 새 버전을 기록하고, 각 버전은 "그 시점에 유효했던 파일 목록"을 가리켜요. 그래서 버전을 거슬러 올라가도 테이블 전체를 매번 복사해둘 필요 없이, 그 시점에 해당하는 파일들만 다시 읽으면 돼요. 다만 이 조회는 읽기 전용이라 테이블의 현재 상태를 바꾸지는 않고, 실제로 되돌리려면 별도의 `RESTORE` 명령을 써야 해요.

## 그래서 Fabric은 왜 전부 Delta로 통일했나요

Fabric의 답은 단순해요. 웨어하우스가 쓴 데이터를 레이크하우스가 읽고, 그걸 다시 Power BI가 읽는 구조를 만들려면, 엔진마다 다른 포맷을 쓰면 안 됐던 거예요.

- **데이터 사일로가 없어요.** 레이크하우스, 웨어하우스, KQL 데이터베이스가 모두 같은 델타 테이블을 읽을 수 있어요.
- **워크로드 간 ETL이 필요 없어요.** 한 엔진이 쓴 데이터를 다른 엔진이 변환 없이 바로 읽어요.
- **데이터 사본이 하나예요.** 조직이 진실의 원천을 하나만 유지하면 되니, 저장 비용과 동기화 문제가 함께 줄어들어요.

## 몰라도 되는 부분, 알아야 유리한 부분

Delta Lake를 이해하는 정도는 하는 일에 따라 달라져도 괜찮아요.

**그냥 넘어가도 되는 경우**
- T-SQL로 SQL analytics endpoint나 웨어하우스를 조회할 때는 Delta가 배경에 완전히 숨어 있어요. 파일 포맷을 신경 쓸 필요 없이 그냥 SQL을 쓰면 돼요.
- Power BI Direct Lake로 리포트를 만들 때도 Delta 테이블을 알아서 읽어줘요.
- 파이프라인 복사 활동으로 레이크하우스 테이블에 적재할 때도 기본적으로 Delta 형식이 적용돼요.

**직접 알아야 유리한 경우**
- 쿼리 성능을 튜닝할 때: V-Order<sup>3</sup>, 파일 압축(compaction), 파티셔닝 전략을 이해해야 손댈 수 있어요.
- Databricks나 S3처럼 외부에 있는 델타 테이블과 연동할 때: 기능 호환성을 미리 확인해야 해요.
- 삭제 벡터, 컬럼 매핑처럼 고급 Spark 기능을 쓸 때: 명시적인 설정이 필요해요.
- 엔진 간 동작이 다르게 보이는 문제를 디버깅할 때: 어떤 Delta 기능을 어느 엔진이 지원하는지부터 확인해야 원인을 좁힐 수 있어요.

## Fabric이 얹은 추가 최적화

Delta Lake 자체는 Databricks든 오픈소스 Spark든 어디서나 같은 규격이지만, Fabric은 그 위에 자체 최적화를 몇 가지 더 얹었어요.

- **V-Order**: 모든 엔진에서 조회 성능을 높이기 위한 Fabric 전용 쓰기 최적화예요.
- **자동 테이블 유지 관리**: Fabric이 작은 파일을 자동으로 합치고, 오래된 데이터를 정리해줄 수 있어요.
- **Fabric 서비스와의 통합**: 같은 델타 테이블을 Power BI Direct Lake, SQL analytics endpoint, 파이프라인, 노트북이 그대로 이어받아 써요.

개방형 표준을 그대로 따르면서 그 위에 Fabric만의 성능 기능을 더한 구조라서, 어디서든 통하는 이식성과 Fabric 안에서의 속도를 동시에 챙길 수 있는 거예요.

## 외부 시스템과도 통해요

Delta Lake는 리눅스 재단이 관리하는 공개 규격이라, Fabric 밖의 시스템과도 자연스럽게 이어져요.

- **OneLake 샷컷**: Amazon S3, Azure Data Lake Storage, Databricks에 있는 델타 테이블을 복사하지 않고 그대로 참조할 수 있어요.
- **Delta Sharing**: 공개 프로토콜인 Delta Sharing으로 조직 경계를 넘어 델타 테이블을 공유할 수 있어요.
- **크로스 플랫폼 호환**: Databricks나 Azure Synapse Analytics에서 만든 테이블도 Fabric에서 읽을 수 있어요. 다만 기능 지원 여부는 플랫폼마다 조금씩 달라서, 외부 테이블을 연결할 때는 기능 호환 매트릭스를 먼저 확인하는 게 안전해요.

## 정리

Delta 테이블은 특별한 마법이 아니라, 파케이 파일에 트랜잭션 로그를 더해 "지금 유효한 파일이 무엇인지"를 기록해두는 방식이에요. 이 로그 덕분에 ACID 트랜잭션과 시간 여행이 자연스럽게 따라오고, Fabric은 이 형식 하나로 통일해서 워크로드 사이의 ETL과 데이터 중복을 없앴어요. SQL 위주로 일한다면 대부분 신경 쓸 필요 없지만, 성능 튜닝이나 외부 시스템 연동에 들어가는 순간부터는 이 구조를 아는 게 곧바로 도움이 돼요.

---

## 어휘 주석

1. **Delta Lake:** 리눅스 재단이 관리하는 오픈소스 저장 계층 규격이에요. Databricks, Synapse, Fabric, 오픈소스 Spark 환경 모두에서 같은 방식으로 동작해요.
2. **파케이(Parquet):** 분석 워크로드에 최적화된 열 지향(columnar) 압축 파일 포맷이에요. 필요한 열만 골라 읽을 수 있어서 대용량 조회에 유리해요.
3. **V-Order:** Fabric이 파케이 파일을 쓸 때 추가로 적용하는 정렬·인코딩·압축 최적화예요. 쓰기 시간은 조금 늘지만 이후 조회 성능이 좋아져요.