AZ-305 시험에서 스토리지 솔루션 설계는 전체 출제 비중의 상당 부분을 차지합니다. 단순히 서비스를 암기하는 것을 넘어, 각 서비스의 성능 특성·복제 옵션·계층 전환 규칙을 조합하여 요구사항에 맞는 최적 아키텍처를 선택하는 능력이 핵심입니다. 이 글은 53개의 실제 시험 문제를 분석해 추출한 핵심 패턴을 중심으로 Blob Storage, Azure Files, Managed Disks, NetApp Files, 복제 옵션, 수명 주기 관리까지 한 번에 정리합니다.
---
Blob Storage 설계와 액세스 계층
Blob Storage는 이미지·동영상·로그·백업 등 비정형 데이터를 저장하는 대표적 오브젝트 스토리지입니다. HTTP/HTTPS REST API로 직접 접근 가능하며 Azure CDN·Front Door와 기본 통합됩니다.
스토리지 계정 유형은 설계의 출발점입니다. General Purpose v2(GPv2)는 Hot·Cool·Cold·Archive 4개 계층과 수명 주기 관리 정책을 모두 지원하는 범용 유형입니다. GPv2에 계층적 네임스페이스(HNS)를 활성화하면 Azure Data Lake Storage Gen2가 됩니다. Premium Block Blob은 SSD 기반으로 1ms 미만의 일관된 지연 시간을 제공하지만, Hot 계층만 지원하며 수명 주기 관리 정책이 적용되지 않습니다. FileStorage는 Azure Files Premium 전용으로 GPv2에서는 생성 불가합니다.
액세스 계층은 저장 비용과 읽기 비용의 트레이드오프입니다. Hot은 자주 접근하는 데이터, Cool은 30일 이상 보관, Cold는 90일 이상, Archive는 180일 이상에 적합합니다. 분기별 감사처럼 비정기 접근이지만 즉시 읽어야 한다면 Cool을 선택합니다. 수명 주기 관리 정책은 GPv2에서만 동작하며, Cool 최소 보관 기간 30일, Archive는 180일이고 조기 삭제 시 추가 비용이 발생합니다.
데이터 보호는 목적에 따라 구분됩니다. Blob Versioning은 덮어쓰기 시 이전 버전을 자동 보관하고, Soft Delete는 삭제 후 최대 365일 복구가 가능하지만 관리자가 복원 가능하므로 WORM 요건에는 부적합합니다. Point-in-Time Restore는 Block Blob 전용이며 Soft Delete + Versioning + Change Feed 세 가지를 모두 활성화해야 합니다. 불변성 정책(WORM)을 잠금 상태로 설정하면 구독 관리자도 보존 기간 내 데이터를 수정·삭제할 수 없으며, SEC 17a-4 등 금융·의료·법률 규정 준수에 사용합니다.
---
Azure Files와 파일 공유 설계
Azure Files는 SMB와 NFS 프로토콜을 지원하는 완전 관리형 클라우드 파일 공유 서비스입니다. Standard(GPv2 계정, HDD 기반, 수십~수백ms 지연)와 Premium(FileStorage 계정, SSD 기반, 단일 자릿수ms 미만 지연)으로 나뉩니다. Premium은 LRS와 ZRS만 지원하며 GRS·RA-GRS는 지원하지 않습니다.
GPv2 계정에서 Premium 파일 공유를 생성할 수 없습니다. 저지연 파일 공유가 필요하다면 반드시 FileStorage 계정 유형을 선택해야 합니다.
인증 방식 선택도 시험에서 자주 출제됩니다. Shared Key 사용을 금지한 환경에서 Entra ID 계정으로 SMB 인증이 필요하다면 Azure Files Entra ID 인증(Kerberos)을 활성화합니다. AD DS 인증은 온프레미스 Active Directory가 있는 하이브리드 환경용입니다.
Azure File Sync는 지사 파일 서버와 Azure Files를 자동 동기화합니다. 로컬 서버 오프라인 시에도 직원들이 Azure Files 클라우드에 직접 접근할 수 있어 장애 연속성을 보장합니다. 클라우드 티어링으로 자주 사용하는 파일만 로컬에 유지하여 로컬 스토리지를 최대 99%까지 절감할 수 있습니다. 지사 저지연 + 중앙 동기화 + 장애 내성 세 요건이 동시에 요구된다면 Azure Files + Azure File Sync 조합이 정답입니다.
---
Managed Disks와 VM 디스크 설계
Azure VM에 연결하는 블록 스토리지입니다. Standard HDD(개발·테스트), Standard SSD(일반 웹서버), Premium SSD(SQL Server·프로덕션), Premium SSD v2(고성능 OLTP, 서브밀리초 지연, IOPS·처리량 독립 조정), Ultra Disk(최고 성능, 가용성 영역 제한) 순으로 성능이 향상됩니다. Ultra Disk의 비용·운영 복잡성이 과도하다면 Premium SSD v2가 대안입니다.
Host Caching 설정은 SQL Server 시나리오에서 핵심입니다. 데이터 파일 디스크는 Read-Only 캐싱을 사용합니다. 읽기는 메모리에서 처리하여 IOPS를 낮추고, 쓰기는 디스크에 직접 기록하여 캐시 손실 시 데이터 유실 위험이 없습니다. 트랜잭션 로그 디스크는 None으로 설정합니다. 쓰기를 캐시 없이 디스크에 직접 기록하여 쓰기 내구성을 보장하며, 트랜잭션 로그의 순차 쓰기 패턴 덕분에 캐시 없이도 충분한 성능을 발휘합니다.
---
복제 옵션과 데이터 가용성 (LRS/ZRS/GRS/GZRS)
| 옵션 | 복제 위치 | 단일 DC 장애 | 리전 장애 | 내구성 | |------|-----------|-------------|-----------|--------| | LRS | 단일 데이터센터 내 3개 복사 | 취약 | 취약 | 11 nines | | ZRS | 동일 리전 3개 가용 영역 | 보호 | 취약 | 12 nines | | GRS | LRS + 보조 리전 비동기 복제 | 취약 | 보호 | 16 nines | | RA-GRS | GRS + 보조 리전 읽기 가능 | 취약 | 보호+읽기 | 16 nines | | GZRS | ZRS + 보조 리전 비동기 복제 | 보호 | 보호 | 16 nines |
선택 기준: 비용 최소화 + 재해 복구 불필요이면 LRS, 단일 DC 장애 내성 + 보조 리전 금지(데이터 주권·규정)이면 ZRS, 리전 재해 복구 + 재해 중 읽기 유지이면 RA-GRS, 영역+리전 장애 모두 대비이면 GZRS를 선택합니다.
Azure Files Premium은 LRS와 ZRS만 지원합니다. 단일 데이터센터 장애 내성이 필요하다면 ZRS가 유일한 고가용성 옵션입니다. 빈번한 접근이 예상된다면 Hot 계층을 유지해야 읽기 지연을 밀리초 수준으로 유지할 수 있습니다.
!Azure Storage 복제 옵션 비교
서비스 비교표
| 서비스 | 주요 용도 | 프로토콜 | 복제 옵션 | 계층 지원 | |--------|-----------|----------|-----------|-----------| | Blob Storage GPv2 | 비정형 오브젝트 저장 | HTTP/HTTPS | 전체(LRS~GZRS) | Hot/Cool/Cold/Archive | | Azure Files Standard | 파일 공유, 서버 대체 | SMB, NFS | LRS/ZRS/GRS/RA-GRS | - | | Azure Files Premium | 저지연 고성능 파일 공유 | SMB, NFS | LRS, ZRS만 | - | | Managed Disks | VM 블록 스토리지 | - | LRS/ZRS | - | | NetApp Files | 최고 성능 엔터프라이즈 NAS | NFS v3/v4.1, SMB | 전용 하드웨어 | Ultra/Premium/Standard | | ADLS Gen2 | 빅데이터·분석 데이터 레이크 | ABFS/HTTP | 전체(LRS~GZRS) | Hot/Cool/Archive |
NetApp Files Ultra 서비스 레벨은 TiB당 128MiB/s 처리량과 서브 밀리초 지연 시간을 제공하는 엔터프라이즈급 NAS입니다. 최고 처리량 + 최저 지연 + 성능 우선이 키워드라면 Azure NetApp Files가 정답입니다. 단, SMB 호환성이 주 요건이고 비용 효율도 고려한다면 Azure Files Premium이 더 적합합니다.
---
시험에서 자주 헷갈리는 선택 기준
WORM 규정 준수 스토리지
관리자도 삭제 불가 + SEC 17a-4 + 장기 보존이 요건이라면 Blob Storage 불변성 정책(잠금 상태)을 선택합니다. Soft Delete는 관리자가 복원할 수 있으므로 WORM이 아닙니다. Azure Backup 보관 정책은 원본 Blob을 보호하지 못합니다. Resource Lock은 스토리지 계정 삭제 방지일 뿐 Blob 수준 보호가 아닙니다.
데이터 레이크 + 폴더 ACL + Spark
계층적 폴더 구조 + POSIX ACL + Apache Spark 통합이 동시에 요구된다면 ADLS Gen2(GPv2 + HNS 활성화)를 선택합니다. HNS는 계정 생성 시에만 활성화 가능합니다. RBAC는 계정·컨테이너 수준만 제어하므로 폴더·파일 단위 세분화 권한은 POSIX ACL(HNS 필수)을 사용합니다.
고처리량 Blob + 저지연 + WORM 동시 요건
초당 수천 건 로그 쓰기 + WORM + 밀리초 미만 지연이 동시에 요구된다면 Premium Block Blob Storage를 선택합니다. Standard GPv2는 HDD 기반이라 이 요건을 충족하지 못합니다. Premium Block Blob은 SSD 기반으로 불변성 정책(WORM)도 완전히 지원하며, ZRS와 조합하면 데이터센터 장애 보호까지 추가할 수 있습니다.
단일 계정 내 부서별 독립 암호화
동일 스토리지 계정에서 컨테이너별 서로 다른 CMK가 필요하다면 Blob Encryption Scope를 선택합니다. 계정 수준 CMK는 전체 단일 키이므로 부서별 분리가 불가합니다. Encryption Scope는 컨테이너 또는 Blob 단위로 서로 다른 CMK를 적용하며, 스토리지 계정당 최대 10,000개까지 생성할 수 있습니다.
---
실무 적용 팁
SAS 토큰 방식 선택: 외부 파트너와 시간 제한 파일 공유 시 SAS를 사용합니다. Shared Key 기반 인증이 비활성화된 환경에서는 User Delegation SAS(Entra ID OAuth 서명)가 유일한 옵션입니다. Account SAS·Service SAS는 모두 Shared Key로 서명하므로 이 환경에서 사용 불가합니다.
Azure Data Share vs SAS: 조직 간 데이터 공유에서 스냅샷 제공 + 원본 직접 접근 불허 + 공유 취소 가능이 요건이라면 Azure Data Share를 선택합니다. SAS는 원본 스토리지에 임시 직접 접근 권한을 부여하므로 원본 데이터가 노출됩니다.
ADLS Gen2 초기 설계: HNS는 계정 생성 후 활성화가 불가합니다. 데이터 레이크 아키텍처가 예상된다면 초기 설계 시 GPv2 + HNS를 반드시 선택해야 합니다. 초기 비용 최소화 + 분석 통합이 요건이라면 Standard GPv2 + HNS, 극저지연 트랜잭션 집약적 워크로드라면 Premium Block Blob을 선택합니다.
복제 옵션과 데이터 주권: 데이터 주권 규정으로 보조 리전 복제가 금지된 경우 ZRS가 가용성 향상의 유일한 옵션입니다. GRS·RA-GRS·GZRS는 모두 리전 간 데이터 복제를 포함합니다.
---
정리
AZ-305 스토리지 설계는 시나리오의 핵심 요건을 빠르게 분류하는 능력이 중요합니다.
핵심 분류 흐름을 정리합니다.
파일 공유(SMB/NFS)인가, 오브젝트 스토리지인가? → Azure Files vs Blob Storage 고성능이 최우선인가? → NetApp Files > Files Premium > Premium Block Blob > GPv2 자동 계층 전환이 필요한가? → GPv2만 수명 주기 관리 지원 (Premium Block Blob 불가) 단일 DC 보호인가, 리전 재해 보호인가? → ZRS vs GRS (Files Premium은 ZRS까지만) WORM이 필요한가? → Blob 불변성 정책(잠금). Soft Delete는 WORM이 아님 폴더 수준 POSIX ACL + 빅데이터 분석인가? → ADLS Gen2(HNS 활성화, 계정 생성 시만) Premium 파일 공유인가? → FileStorage 계정 유형 필수 (GPv2 불가)
이 분류 흐름과 실제 시험 문제의 키워드를 연결하는 연습을 반복하면 스토리지 도메인의 복잡한 서비스 선택 문제를 자신 있게 풀 수 있습니다.