Azure SQL Database vs. Fabric SQL Database: 비용과 컴퓨팅 차이 살펴보기

By Mirko Peters · 2026-10-21

Azure SQL Database와 Fabric SQL Database의 컴퓨팅 비용, 서버리스 확장, 용량 단위, 스토리지 경제성, 기능상 절충점을 비교합니다.

Automatically translated with AI from the original post. Read the English original

Azure SQL Database와 Fabric SQL Database 중 무엇을 선택할지는 컴퓨팅 할당, 확장 동작, 용량 단위가 어떻게 다른지 이해하는 데 달려 있습니다. 두 서비스 모두 동일한 강력한 SQL 엔진을 기반으로 하지만, Fabric의 OneLake 통합과 공유 용량 모델은 데이터 중심 조직에 뚜렷이 다른 아키텍처 및 비용 고려 사항을 가져옵니다.

핵심 요약

• Fabric SQL Database는 독립형 Azure vCore 계층이 아니라 공유 Fabric 용량 단위(CU)에서 리소스를 사용합니다.
• 컴퓨팅 리소스는 15분간 활동이 없으면 0까지 축소되며 자동으로 해제되어 비용을 절감합니다.
• 스토리지는 매시간 지속적으로 과금되는 반면, 백업 스토리지는 기본 데이터베이스 크기까지 무료입니다.
• 내장된 자동 미러링은 OneLake에 Delta Parquet 파일을 실시간으로 채워 수동 ETL 파이프라인을 없앱니다.
• 기존 Azure SQL Database는 전용 탄력적 풀과 SQL Server Agent 작업을 제공하며, Fabric 환경은 이를 다르게 처리합니다.

컴퓨팅 이해하기: vCore 대 용량 단위

워크로드를 마이그레이션하거나 새로운 클라우드 아키텍처를 계획할 때, 기존 Azure SQL과 Fabric SQL의 근본적인 차이는 컴퓨팅 관리 방식에 있습니다. 독립형 Azure SQL Database에서는 개별 데이터베이스 인스턴스에 직접 대응되는 전용 vCore 또는 서버리스 컴퓨팅을 프로비저닝합니다. 확장 한도, 유지 관리 기간, 성능 계층을 데이터베이스 단위로 관리합니다.

반면 Fabric SQL Database는 조직 전체의 Fabric 용량 풀에서 컴퓨팅 성능을 가져옵니다. 이 공유 리소스 모델은 데이터베이스가 Power BI 보고서, Data Factory 파이프라인, Lakehouse와 예산을 나눠 쓴다는 뜻입니다. Fabric 용량 단위(CU)와 데이터베이스 성능 간의 환산은 내부적으로 동적으로 처리됩니다. 예를 들어 64개의 용량 단위는 데이터베이스 워크로드에 대략 24.5개의 vCore에 해당합니다. 이 통합 풀 방식은 다중 데이터베이스 환경에서 흔한 리소스 분산을 막고, 분석 작업 영역 전체에서 동적으로 자원을 공유할 수 있게 합니다.

서버리스 확장과 유휴 과금 규칙

두 데이터베이스 제품 모두 피크 쿼리 실행 시 확장되고 트래픽이 줄면 다시 축소되는 서버리스 아키텍처를 사용합니다. 다만 예산 예측에서는 유휴 시간의 과금 방식이 특히 중요합니다. Fabric SQL Database는 활동을 지속적으로 모니터링합니다. 들어오는 쿼리 없이 15분 동안 완전히 유휴 상태가 되면 모든 컴퓨팅 리소스를 해제하여 컴퓨팅 비용을 0으로 낮춥니다.

다음 사용자의 콜드 스타트 지연을 막기 위해 Microsoft는 의도적인 유지 버퍼를 둡니다. 데이터베이스가 2분 동안 작업하다가 조용해지면, 활성 2분에 더해 웜 대기 컴퓨팅 15분이 추가되어 총 17분에 대해 과금됩니다. 반면 스토리지는 데이터베이스가 트랜잭션을 처리하든 대기 중이든 상관없이 변하지 않고 매시간 과금됩니다.

스토리지 비용과 백업 경제성

Fabric SQL Database의 스토리지 관리는 기존 환경과 비교했을 때 상당한 비용 절감 효과를 제공합니다. 데이터베이스가 OneLake로의 지속적인 미러링을 자동으로 시작하기 때문에 운영 레코드가 개방형 Delta Parquet 파일로 복제됩니다. 이 개방형 형식 덕분에 데이터가 독점 사일로에 묶이지 않으며, Delta 형식을 읽을 수 있는 도구라면 어떤 도구로든 미러링된 복사본을 직접 쿼리할 수 있습니다.

아울러 Fabric 생태계에서는 백업 비용도 크게 최적화되어 있습니다. 특정 시점 복원 기능을 이용하면 관리자는 최대 7일 전으로 되돌려 실수로 인한 데이터 손상이나 치명적인 사용자 오류로부터 복구할 수 있습니다. 백업 스토리지는 기본 데이터베이스의 총 크기까지 완전히 무료입니다. 백업 스토리지 사용량이 활성 데이터베이스 자체보다 커질 때만 추가 요금이 발생하므로, 장기 데이터 보존을 위한 예측 가능한 재무적 안전망을 제공합니다.

운영상의 트레이드오프: 얻는 것과 잃는 것

핵심 SQL 엔진은 두 플랫폼에서 동일하지만, Azure SQL Database 대신 Fabric SQL Database를 선택하려면 특정 기능 간의 트레이드오프를 따져 봐야 합니다. Fabric 구현에서 빠진 기능이 무엇인지 알고 있으면 개발 중 예상치 못한 아키텍처상의 장애물을 피할 수 있습니다.

기존 Azure SQL 고유의 기능

독립 실행형 Azure SQL Database는 이름으로 탄력적 풀을 기본 지원하여, 데이터베이스 관리자가 데이터베이스 그룹을 세밀하게 제어할 수 있습니다. 또한 많은 기존 애플리케이션이 저장 프로시저와 유지 관리 작업을 내부적으로 예약하는 데 사용하는 클래식 SQL Server Agent도 포함되어 있습니다.

Fabric SQL의 기본 장점

Fabric SQL을 사용하면 외부 복제 파이프라인을 구성하는 관리 부담이 사라집니다. 데이터베이스를 생성하는 즉시 지원되는 모든 테이블에 대해 미러링이 자동으로 활성화되며, 수동 ETL 구성은 필요하지 않습니다. 또한 Git과 기본적으로 통합되어 소스 제어를 지원하고, 세 부분으로 구성된 이름 규칙을 지원하므로 단일 쿼리에서 운영 테이블을 Lakehouse 및 Warehouse와 손쉽게 조인할 수 있습니다. 이러한 요소들이 어떻게 맞물리는지에 대한 포괄적인 개요는 전체 에피소드 듣기에서 최신 데이터 아키텍트를 위한 전문가 분석과 실용적인 전략을 확인해 보시기 바랍니다.

자주 묻는 질문

유휴 상태인 Fabric SQL Database의 요금은 어떻게 청구되나요?

컴퓨팅 요금은 마지막 쿼리 실행이 끝난 후 15분 동안 데이터베이스를 활성 상태로 유지하기 위해 계속 청구되며, 이후에는 컴퓨팅 비용이 0으로 떨어집니다. 스토리지는 활동 여부와 관계없이 매시간 계속 청구됩니다.

OneLake에 데이터를 가져오려면 미러링을 수동으로 구성해야 하나요?

아니요. Fabric SQL Database가 생성되는 순간 미러링이 자동으로 시작되며, 사용자 지정 ETL 코드 없이 관계형 테이블을 개방형 Delta Parquet 파일로 OneLake에 지속적으로 동기화합니다.

Fabric SQL Database에서 작업 예약에 SQL Server Agent를 사용할 수 있나요?

Fabric SQL Database에서는 SQL Server Agent를 사용할 수 없습니다. 대신 Microsoft는 예약 및 자동화를 위해 Data Factory 파이프라인이나 Apache Airflow 작업을 사용하는 것을 권장합니다.

Fabric SQL의 백업 요금은 어떻게 청구되나요?

특정 시점 복원 백업은 활성 데이터베이스의 총 스토리지 크기까지 완전히 무료입니다. 백업 사용량이 기본 데이터베이스의 크기를 초과할 때만 백업 스토리지 요금을 지불하면 됩니다.