🧪 1️⃣ 실습 환경 접속 및 운영 방식 설명

(ESI LearnOnDemand 실습 환경)

🔹 주요 내용

• 실습은 esi.learnondemand.net 기반
• Entra ID(회사 계정) → 실패 시 개인 Microsoft Account로 로그인 가능
• Training Key 입력 후 실습 환경 활성화
• 실습 환경 유효 기간은 약 6개월
• 각 실습은 실행 횟수 제한(보통 10회) 있음

🔹 중요 운영 팁

• 실습 VM 화면은 반응이 느릴 수 있음
• ✅ 권장 방식
  👉 실습 VM은 계정 정보 확인용
  👉 실제 실습은 로컬 브라우저(InPrivate / 시크릿 모드) 에서 Fabric 포털 직접 접속

📌 교육 의도

• “실습이 안 돼서 수업을 못 따라오는 상황”을 미리 차단
• 현업에서도 바로 써먹을 수 있는 현실적인 실습 운영 방식 전달

🌐 2️⃣ 데이터 분석의 전체 흐름(Big Picture)

“Fabric을 이해하려면 먼저 데이터가 어떻게 흘러가는지 알아야 한다”

🔹 데이터 유형 3가지

• 📊 정형 데이터 (Structured)
  → 관계형 DB, 테이블 기반
• 📄 반정형 데이터 (Semi-Structured)
  → CSV, JSON, XML
• 🎥 비정형 데이터 (Unstructured)
  → 문서, 이미지, 영상, 음성

🔁 데이터 수집 방식

① Ad-hoc 방식

• 필요할 때마다 데이터 수집
• 주 대상: 정형 / 비정형 데이터

② Streaming 방식

• 지속적으로 데이터 유입 (IoT, 로그 등)
• Event Hub, Kafka, IoT Hub 사용
• Hot Path / Cold Path 개념 등장 🔥❄️

🏗️ 데이터 처리 파이프라인

• ETL / ELT
• 변환, 정제, 필터링
• PySpark, Spark SQL, SQL 등 다양한 언어 사용

📌 핵심 메시지

“데이터는 항상
수집 → 저장 → 처리 → 분석 → 시각화
이 흐름을 따른다”

🧵 3️⃣ Microsoft Fabric은 왜 등장했는가?

🎯 “흩어져 있던 모든 데이터 분석 서비스를 하나로”

🔹 기존 문제

• Data Factory
• Synapse (DW / Spark / Real-time)
• Power BI
• ML, Streaming, Security
  👉 각각 따로 관리해야 했음

🧩 Fabric의 핵심 가치

✅ 단일 SaaS 기반 통합 플랫폼
✅ UI 중심 + Low-Code / No-Code
✅ 하나의 저장소: OneLake

📌 강조 포인트

• Synapse는 유지되지만 신규 기능은 Fabric 중심
• Copilot / AI 기능은 Fabric에만 적극 탑재

🏞️ 4️⃣ OneLake & Lakehouse 개념

“Data Lake + Data Warehouse = Lakehouse”

🔹 Lakehouse 구조

• 📂 Files 영역 → Data Lake 역할
• 📊 Tables 영역 → Data Warehouse 역할
• 둘 다 하나의 Lakehouse 안에 공존

📌 중요 개념

• 데이터는 복사하지 않고 직접 참조
• 여러 분석 엔진이 같은 데이터를 사용

📦 5️⃣ 파일 포맷의 진화 (중요 ⭐)

왜 CSV/JSON이 아닌 Parquet인가?

🔹 전통 포맷의 한계

• 사람이 읽기 쉬움 ✅
• 분석 성능 ❌
• 저장 공간 비효율 ❌

🚀 분석용 파일 포맷

포맷특징

✅ Fabric / Synapse / Databricks 표준 포맷 = Parquet

📌 핵심 메시지

“사람이 읽는 파일이 아니라
분석 엔진이 읽기 좋은 파일이 중요하다”

🗄️ 6️⃣ NoSQL까지 확장되는 데이터 저장

• JSON을 DB에 저장하고 싶을 때?
  • Key-Value
  • Document DB (Cosmos DB)
  • Column Family
  • Graph DB

📌 의도

• “데이터 형식에 따라 저장 방식이 달라진다”
• Fabric을 이해하려면 저장 개념을 먼저 이해해야 함

🍱 7️⃣ 점심 전 마무리 메시지

✅ Fabric은 단순 도구가 아니라
👉 데이터 분석 전체 생태계를 통합한 플랫폼

✅ 오후에는

• Lakehouse 실제 생성
• 데이터 적재
• 테이블 변환
• Fabric UI 실습으로 이어질 예정

🧱 2️⃣ Lakehouse 개념 복습 (실습 관점)

✅ 핵심 다시 정리

• Lakehouse = Data Lake + Data Warehouse
• Fabric Lakehouse 생성 시 자동 생성 요소:
  • 📂 Files → Data Lake 영역 (CSV / JSON / Parquet 등)
  • 📊 Tables → Data Warehouse 영역 (Delta / Parquet 기반)
  • 🧠 SQL Analytics Endpoint → SQL로 바로 분석 가능

💡 중요 포인트

• 파일을 “복사”하지 않고
• 같은 데이터를 여러 엔진(Spark / SQL / BI)이 직접 사용

🧪 3️⃣ 실습 ① : Lakehouse 생성

🛠️ 실습 흐름

1. Workspace 생성
   • 이름: WS-xxxxxxxx (계정 고유 ID 포함)
   • Fabric 용량 선택 (실습 환경 기본값)
2. Lakehouse 생성
   • 이름: LHLab
   • ✅ Lakehouse Schema 옵션 활성화
     • → dbo 스키마 사용 가능 (RDB 감각 유지)
3. 자동 생성 확인
   • Tables / Files 구조
   • SQL Analytics Endpoint 생성됨

✅ 교육 포인트

• “Lakehouse 만들면 분석 준비의 70%는 끝났다”

📂 4️⃣ 실습 ② : CSV 파일 → Lakehouse Files 업로드

📥 데이터 준비

• 외부 CSV 파일 다운로드
  👉 sales.csv (매출 데이터)

📤 Lakehouse에 업로드

• 경로:
  Files → data/
• CSV 업로드 후 미리보기로 데이터 확인

⚠️ 이 상태는 아직 분석 불가→ 파일일 뿐, 테이블 아님

🔁 5️⃣ 실습 ③ : CSV → Table 변환 (핵심!)

🧠 수행 작업

• sales.csv → Load to Table
  • Schema: dbo
  • Table Name: sales
  • Header 사용, 구분자 ,

✅ 결과

• Tables → dbo.sales 생성
• 컬럼 타입 자동 인식 (string / int / date 등)
• Delta Lake Table로 생성됨

🧬 6️⃣ Parquet & Delta 확인 (중요 ⭐)

🔍 내부 구조 확인

• sales 테이블 → 파일 보기
  • .parquet 파일
  • _delta_log 폴더

📉 용량 비교

• 원본 CSV: 약 3MB
• Parquet: 약 500KB

💡 강조 메시지

• Fabric의 모든 분석 테이블 = Parquet 기반
• 사람이 읽기 위한 파일 ❌
• 분석 엔진이 읽기 좋은 파일 ✅

🧮 7️⃣ 실습 ④ : SQL Analytics Endpoint 분석

✍️ SQL 쿼리 실행

SELECT Item, SUM(Quantity * UnitPrice) AS Revenue

FROM sales

GROUP BY Item

ORDER BY Revenue DESC;

✅ 결과

• 제품별 매출 집계
• CSV → SQL 분석까지 단일 플랫폼에서 완료

🎯 의미

• Spark 몰라도 SQL만으로 분석 가능
• Lakehouse의 강력한 장점

🎨 8️⃣ 실습 ⑤ : Visual Query (No SQL!)

🖱️ Visual Query 기능

• 테이블 드래그 앤 드롭
• 컬럼 선택
• Group By / Count / Aggregate UI로 수행

예시

• 주문번호별(Line Item 개수)
  • Group by: SalesOrderNumber
  • Count: SalesOrderLineNumber (Distinct)

➡️ 자동으로 SQL 생성됨

✅ 핵심 가치

• SQL 몰라도 분석 가능
• Low-code / No-code 분석 경험

🧠 9️⃣ 실습 ⑥ : Semantic Model 생성

🧩 Semantic Model

• 보고서용 의미 계층(Semantic Layer)
• 테이블 선택 → SemanticLab 생성

이후 가능 작업:

• 관계 설정
• Measure 정의
• Power BI 보고서 기반

📊 1️⃣0️⃣ 실습 ⑦ : 보고서 생성 (데모 중심)

⚠️ 실습 계정은 Power BI 라이선스 제한
→ 강사가 데모로 진행

데모 내용

• Semantic Model → 새 보고서
• 제품별 판매 수량 시각화
• Bar Chart / Top N 필터
• 보고서 저장 & 공유

💡 중요

• Fabric 안에서 BI까지 끊김 없이 연결

🤖 1️⃣1️⃣ AI 기반 기능 소개 (미래 방향)

✨ Auto Report / Insight

• Semantic Model 기반
• AI가 자동으로 보고서 생성
• 요약 카드 / 시각화 자동 추천

🧠 Ontology 언급

• 테이블 의미 구조 이해
• Copilot / AI 분석의 기반 기술

🚀 메시지“앞으로는 데이터를 잘 준비하는 사람이 가장 중요해진다”

✅ 1️⃣2️⃣ 오후 핵심 요약 한 줄

CSV 하나로 시작해서
Lakehouse → Table → SQL → Visual Query → Semantic → Report
👉 이 모든 과정을 Fabric 하나로 끝냈다 ✨

🔄 1️⃣ 오후 세션 재개 & 방향 전환

“이제부터는 진짜 Fabric을 써본다”

• 점심 이후 참석자 재확인(손들기) ✅
• 오전의 개념 중심 설명 → 오후는 실습 중심으로 전환
• 핵심 메시지 🎯

“Fabric은 설명보다 직접 만져보는 게 훨씬 빠르게 이해된다”

🧱 2️⃣ Lakehouse 구조 다시 짚기 (실습 관점)

왜 Lakehouse가 핵심인가?

📌 Lakehouse를 만들면 자동으로 생성되는 것들

• 📂 Files
  • CSV / JSON / Parquet 저장
  • 👉 Data Lake 역할
• 📊 Tables
  • Delta / Parquet 기반 테이블
  • 👉 Data Warehouse 역할
• 🧠 SQL Analytics Endpoint
  • Spark 없이 즉시 SQL 분석 가능

💡 핵심 포인트

같은 데이터를
Spark / SQL / Power BI가 복사 없이 직접 사용

🧪 3️⃣ 실습 ① Lakehouse + CSV → Table 변환

“파일을 분석 가능한 테이블로 바꾸는 순간”

✅ 실습 흐름

1. Workspace 생성
   • WS-xxxxxxxx (계정 고유 ID 포함)
2. Lakehouse 생성
   • 이름: LHLab
   • ✅ Lakehouse Schema 옵션 활성화
3. CSV 파일 업로드
   • Files/data/ 경로
4. Load to Table
   • CSV → dbo.sales 테이블 생성

📌 결과

• 단순 CSV ❌
• 👉 Delta Lake Table (Parquet 기반) ✅

📦 4️⃣ Parquet & Delta 구조 직접 확인 ⭐

“왜 CSV가 아니라 Parquet인가?”

🔍 확인 내용

• sales 테이블 → 파일 보기
  • .parquet
  • _delta_log

📉 용량 비교

• CSV: 약 3MB
• Parquet: 약 500KB

💡 핵심 메시지

사람에게 읽기 쉬운 파일 ❌
분석 엔진이 읽기 쉬운 파일 ✅

🧮 5️⃣ SQL Analytics Endpoint 실습

Spark 없이 SQL로 바로 분석

SELECT Item, SUM(Quantity * UnitPrice) AS Revenue

FROM sales

GROUP BY Item

ORDER BY Revenue DESC;

✅ 의미

• CSV → Table → SQL 분석
• 단일 플랫폼(Fabric) 에서 end-to-end 분석 완료

🎨 6️⃣ Visual Query (No SQL 분석!)

SQL을 몰라도 되는 이유

• 테이블 Drag & Drop
• Column 선택
• Group By / Count / Sum → UI로 수행

🧠 내부적으로는?

• 자동으로 SQL 생성

💡 포인트

Low-code / No-code 분석이 Fabric의 핵심 UX

🧠 7️⃣ Semantic Model 생성

“보고서를 위한 의미 계층”

• SemanticLab 생성
• 역할
  • 📐 테이블 관계 정의
  • 📊 Measure 기준
  • 📈 Power BI 보고서 기반

⚠️ 실습 계정 제한

• Power BI 라이선스 없음 → 강사 데모로 진행

📊 8️⃣ Power BI 보고서 데모

Semantic → Report까지 한 번에

데모 내용:

• 제품별 판매 수량 시각화
• Bar Chart
• Top N 필터
• 보고서 저장 & 공유

💡 핵심

Fabric 안에서 BI까지 끊김 없음

🤖 9️⃣ AI 기반 자동 보고서 & Ontology

“이제는 AI가 보고서를 만든다”

• Auto Report
  • Semantic Model 기반
  • AI가 자동 시각화 생성
• Ontology
  • 데이터 의미 구조 정의
  • Copilot / AI 분석의 기반

🔮 메시지

*“앞으로는 분석보다
*데이터를 잘 준비하는 사람이 더 중요해진다”

🔁 🔟 Dataflow Gen2 소개 (ETL의 핵심)

UI 기반 ETL 도구

📌 Dataflow Gen2란?

• Power Query 기반
• ✅ UI 기반 ETL
• Extract / Transform / Load를 코드 없이 수행

🔧 특징

• CSV / DB / SaaS (Salesforce, GA 등) 연결
• 변환 단계 시각화 (Diagram)
• Copilot으로 수식 자동 생성

🧪 1️⃣1️⃣ 실습 ② Dataflow Gen2 → Lakehouse

“ETL을 진짜로 돌려본다”

실습 흐름

1. Dataflow Gen2 생성
   • 이름: ImportCSV
2. 외부 CSV (GitHub) 연결
3. 변환 작업
   • 📅 OrderDate → Year / Month 컬럼 생성
   • ✅ Copilot으로 수식 생성
4. Lakehouse → Table로 Load
   • Append 모드 (누적)

📌 결과

• Orders 테이블 생성
• 변환 컬럼 포함

🔄 1️⃣2️⃣ Pipeline으로 반복 실행

“한 번이 아니라 매일 실행”

• Pipeline 생성
• Activity로 Dataflow 추가
• 실행 결과:
  • 기존 500여 건 → 1000+ 건으로 증가

⏱️ 가능 트리거

• 시간 기반 (Daily)
• 이벤트 기반 (파일 업로드 등)

스토리지 중복 옵션

GRS 동작 개념도

GRS 동작 방식

기본 지역 (예: Korea Central)     보조 지역 (예: Korea South)
┌─────────────────────────┐       ┌─────────────────────────┐
│  데이터센터              │  →→→  │  자동 복제               │
│  LRS 3중 복사           │       │  LRS 3중 복사            │
└─────────────────────────┘       └─────────────────────────┘
                                          ↑
                              다른 지역에서 백업 복원 가능 ✅

DBCC CHECKDB 옵션

DBCC CHECKDB는 DB의 물리적/논리적 손상을 식별하고 복구하는 명령어

DBCC CHECKDB ('database_name', 복구옵션)
WITH 검사옵션;

-- 복구옵션: REPAIR_FAST / REPAIR_REBUILD / REPAIR_ALLOW_DATA_LOSS / NOINDEX
-- 검사옵션: PHYSICAL_ONLY / EXTENDED_LOGICAL_CHECKS / TABLOCK / NO_INFOMSGS

- 복구 옵션

IP flow verify

IP flow verify 기능을 사용하면 출발지 및 목적지 IPv4 주소, 포트, 프로토콜(TCP/UDP), 트래픽 방향(인바운드 또는 아웃바운드) 을 지정할 수 있습니다.
IP flow verify는 지정된 통신을 테스트하여 연결이 성공하는지 또는 실패하는지 알려줍니다.
만약 연결이 실패하면, 어떤 보안 규칙(NSG Rule) 이 해당 통신을 허용하거나 차단했는지 알려 주어 문제를 해결할 수 있도록 도와줍니다.

연결 문제 해결(Connection troubleshoot)

Connection troubleshoot 기능을 사용하면 VM과 다음 대상 간의 연결을 테스트할 수 있습니다:

• 다른 VM
• FQDN
• URI
• IPv4 주소

이 테스트는 Connection Monitor 기능과 유사한 정보를 제공하지만, 차이점은 특정 시점의 연결을 테스트한다는 점입니다.
Connection Monitor가 시간이 지남에 따라 지속적으로 모니터링하는 것과는 다릅니다.

Azure Container Registry(ACR)의 Private Link(프라이빗 엔드포인트) 지원 여부는 요금제(Tier) 에 따라 달라집니다.

🔍 ACR Private Link 지원 계층

문제에서 ACR은 Standard tier 라고 했으므로,
Private Link 기능을 사용하려면 반드시 Premium tier로 업그레이드 해야 함.

따라서 먼저 해야 할 일은:

👉 ACR을 Premium tier로 업그레이드하는 것

• .NET Core 3.0: Windows 및 Linux에서 지원
• ASP .NET V4.7: Windows에서만 지원
• PHP 7.3: Windows 및 Linux에서 지원
• Python 3.11: Linux에서만 지원

또한, Windows 앱과 Linux 앱은 같은 App Service Plan(ASP)에서 사용할 수 없습니다.
새로운 App Service Plan을 만들 때 운영 체제(OS) 유형을 반드시 선택해야 하기 때문입니다.
즉, 하나의 App Service Plan에 Windows 앱과 Linux 앱을 혼합하여 실행할 수 없습니다.

Virtual Network Gateway 필요성

시나리오 핵심:

• WebApp1 = Azure App Service(웹앱)
• Share1 = 온프레미스 SMB 파일 공유
• 목표 = WebApp1이 온프레미스 네트워크의 SMB 공유에 연결해야 함

Azure App Service는 일반적으로 온프레미스 네트워크에 직접 접근할 수 없습니다.

온프레미스를 연결하려면 반드시 다음 중 하나가 필요합니다:

• Site-to-Site VPN
• ExpressRoute

이 연결을 만들기 위해 필수 요소가 바로:

👉 Azure Virtual Network Gateway

App Service(VNet Integration) → VNet1 → VPN Gateway → 온프레미스 Share1
이 구조로 SMB 접근이 가능합니다.

Azure Data Lake Storage를 지원하는 Azure Storage 계정을 만들려면 계층적 네임스페이스(hierarchical namespace) 옵션을 활성화해야 합니다.
이 옵션을 사용하면 데이터 레이크에서 파일과 폴더를 효율적으로 구성하고 조작할 수 있습니다.
또한, 빅데이터 분석에서 널리 사용되는 Hadoop Distributed File System(HDFS) API와의 호환성도 제공합니다.
자세한 내용은 Azure Data Lake Storage Gen2 소개를 참고하세요.

비용을 최소화하려면, 특히 자주 액세스되지 않는 데이터에 대해 스토리지 계정의 Cool 액세스 계층을 선택할 수 있습니다.
이 계층은 Hot 액세스 계층보다 저장 비용이 낮지만, 액세스 및 트랜잭션 비용은 더 높습니다.

Cool 액세스 계층은 짧은 기간의 백업, 재해 복구용 데이터, 아카이브 데이터처럼 자주 액세스되거나 수정되지 않는 데이터에 적합합니다.
Cool 계층에 저장된 데이터는 최소 30일 이상 보관되어야 합니다.
자세한 내용은 Blob 데이터 액세스 계층을 참고하세요.

데이터를 자동으로 보조 Azure 지역으로 복제하려면 스토리지 계정에서 GRS(geo-redundant storage, 지역 중복 스토리지) 옵션을 선택할 수 있습니다.
이 옵션은 데이터를 기본 지역에서 동기적으로 세 번 복제한 후, 보조 지역으로 비동기적으로 복제합니다.
GRS는 데이터에 대해 가장 높은 수준의 내구성과 가용성을 제공하며, 지역 전체 장애나 재해로부터 데이터를 보호합니다.

어떤 구독에서 GA(Global Administrator, 전역 관리자)라고 해서, 모든 구독에서 리소스를 만들 수 있다는 의미는 아닙니다.

Azure Active Directory(Azure AD)의 전역 관리자(Global Administrator)라 하더라도, 디렉터리 내의 모든 구독과 관리 그룹에 자동으로 접근 권한이 부여되는 것은 아닙니다.
Azure AD와 Azure 리소스는 서로 독립적으로 보안이 적용됩니다.
즉, Azure AD 역할 할당은 Azure 리소스에 대한 접근 권한을 부여하지 않으며, Azure 역할 할당 역시 Azure AD에 대한 권한을 부여하지 않습니다.

그러나 Azure AD의 전역 관리자(Global Administrator)라면, 디렉터리 내의 모든 Azure 구독 및 관리 그룹에 대해 스스로 접근 권한을 부여할 수 있습니다.

“컨테이너 크기를 자동으로 조정(Auto-scale)할 수 있는 Azure 서비스”

여기서 "자동 크기 조정"은

• 인스턴스 수 자동 증가/감소
• CPU/메모리 기반 autoscale
• KEDA 기반 이벤트 드리븐 autoscale
  등을 의미하는 것으로 해석됩니다.

🔍 서비스별 Autoscale 지원 여부

📌 도메인의 Standard ?

요구사항 분석:

1) app.contoso.com 사용자 지정 도메인 사용 가능해야 함

• Custom domain 지원 요금제:
  Shared, Basic, Standard 이상
• Free 요금제는 ❌ 사용자 지정 도메인 불가

2) 최대 8개 인스턴스까지 자동 확장(Autoscale)

• Autoscale(자동 확장)은 Standard 이상에서만 가능
  (Free, Shared, Basic은 autoscale 지원 ❌)

따라서 자동 확장이 필수 → Standard가 최소 조건

➡ Standard 요금제 선택해야 함

📌 도메인 인증 레코드 유형: TXT

Azure App Service에서 custom domain을 추가할 때:

• 도메인 소유권 확인(verification) → TXT 레코드 사용
• A 레코드 / CNAME 레코드는 실제 도메인 연결용이지만
  "도메인 인증" 요구사항에서는 TXT가 정답

따라서 맞는 레코드: TXT

Azure Firewall 배포 규칙 (핵심 포인트)

• Azure Firewall은 가상 네트워크와 같은 Azure Region에만 배치 가능
• 리소스 그룹은 중요하지 않음
  • 방화벽이 있는 RG와 VNet이 있는 RG가 달라도 상관없음
  • 지역만 맞으면 된다

게스트 사용자를 Microsoft Entra ID(Azure AD)에 대량으로 초대하려면 New-MgInvitation cmdlet을 사용합니다.

• New-MgInvitation = 외부 사용자(게스트)를 초대하는 PowerShell 명령
• 초대 이메일을 보내고, 게스트 사용자 계정을 엔트라 테넌트(contoso.com)에 생성함
• CSV 파일을 읽어서 반복 호출하면 500명의 게스트 사용자 계정 생성 가능

따라서 "각 외부 사용자에 대해 New-MgInvitation을 실행하는 스크립트를 만든다" → 정확한 해결 방법입니다.

📌 참고 설명

문제의 요구 사항은 “게스트 사용자 생성” → 반드시 New-MgInvitation 사용해야 합니다.

✅ 1. BlobStorage (Blob 전용 스토리지 계정)

✔ 특징

• Blob 서비스만 지원
  (Blob Containers, Block Blob, Append Blob)
• 다른 서비스(Queue, Table, File)는 지원 X
• Hot / Cool 액세스 계층 지원
• 요금 모델이 액세스 계층 중심

✔ 언제 사용?

• 저렴한 비용으로
  “저장만 하면 되는 Blob 데이터” 보관이 목적일 때
• 예: 이미지, 문서, 백업 파일

✅ 2. BlockBlobStorage (프리미엄 Block Blob 특화 계정)

✔ 특징

• Block Blob만 사용 가능
• Premium SSD 기반 → 초고속 처리
• 지연 시간 Low, 높은 IOPS
• Hot, Cool 계층 없음 (Premium만 존재)

✔ 언제 사용?

• 매우 높은 처리량이 필요한 대규모 Blob 데이터 업로드 시
• 예:
  • 대규모 미디어 처리
  • 고속 로그 수집
  • 빅데이터 실시간 분석 입력 데이터 저장

✅ 3. Storage (General Purpose V1, GPv1) — 구형 계정

✔ 특징

• Blob + File + Queue + Table 모두 지원
• 다양한 서비스 제공하지만 성능/요금 모델이 구식
• Access Tier(Hot/Cool/Archive) 기능 일부 제한
• 신규 기능 업데이트 적음

✔언제 사용?

• 레거시 시스템에서 GPv1을 계속 사용하는 경우
• 특별한 이유가 없다면 새로 만들 필요 없음

✅ 4. StorageV2 (General Purpose V2, GPv2) — 최신 표준, 추천

✔ 특징

• Blob / File / Queue / Table / Disk 모두 지원
• Hot / Cool / Archive 모든 계층 지원
• 가장 많은 기능 제공
• 대부분의 신규 기능이 GPv2에서만 활성화
  • Data Lake Storage Gen2
  • Lifecycle management
  • Static website hosting
  • Soft delete / Versioning / MFA delete 등

✔ 언제 사용?

• 새로 만드는 모든 Storage 계정 → GPv2 권장
• 거의 모든 워크로드에 적합

📌 한 표로 전체 비교

📌 결론적으로…

• BlobStorage → Blob만 필요하고 비용 절감하고 싶을 때
• BlockBlobStorage → Premium SSD 속도 필요할 때
• GPv1(Storage) → 레거시 외 신규 사용 비추천
• GPv2(StorageV2) → 모든 신규 스토리지 계정의 기본 선택