5. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
RAID 0/1/5/6/10의 동작 원리부터 대용량 디스크에서 RAID 5가 위험한 이유, 벤더별 독자 RAID 구현, 이레이저 코딩까지. 데이터를 지키는 기술의 본질을 현장 관점에서 정리한다.
디스크는 반드시 죽는다. 언제 죽느냐의 문제일 뿐이다.
HDD든 SSD든, 수명이 있다. HDD는 기계 부품이니 모터가 멈추거나 헤드가 긁힐 수 있고, SSD는 NAND 셀의 쓰기 횟수에 한계가 있다. 디스크 수십 대, 수백 대를 운영하면 매달 한두 개는 장애가 나는 게 자연스러운 일이다. 문제는 디스크가 죽었을 때 데이터를 잃지 않는 것이다. 그게 RAID의 존재 이유다.
RAID 기본 — 다시 한번 짚고 넘어가자
RAID(Redundant Array of Independent Disks) 레벨별 동작을 시각적으로 정리하면 이렇다.
RAID 0: 스트라이핑 (보호 없음)
┌──────┐ ┌──────┐ ┌──────┐
│ A D │ │ B E │ │ C F │ 데이터를 쪼개서 분산
│ │ │ │ │ │ → 빠르지만 하나 죽으면 전체 손실
└──────┘ └──────┘ └──────┘ → 프로덕션에서 절대 쓰지 않는다
RAID 1: 미러링
┌──────┐ ┌──────┐
│ A B │ │ A B │ 똑같이 두 벌 저장
│ C D │ │ C D │ → 1개 죽어도 OK, 용량 50% 손실
└──────┘ └──────┘
RAID 5: 패리티 1개 분산
┌──────┐ ┌──────┐ ┌──────┐
│ A B │ │ C P1│ │ P2 D │ 패리티를 분산 저장
│ E P3│ │ F G │ │ H P4│ → 1개 죽어도 복구 가능
└──────┘ └──────┘ └──────┘ → 2개 동시 사망 시 데이터 손실
RAID 6: 패리티 2개 분산
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ A B │ │ C P1a│ │P1b P2a│ │P2b D│ 이중 패리티
└──────┘ └──────┘ └──────┘ └──────┘ → 2개까지 동시 사망 OK
RAID 10: 미러 + 스트라이프
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ A │ │ A │ │ B │ │ B │ 미러 쌍을 스트라이핑
│ C │ │ C │ │ D │ │ D │ → 성능 + 보호 둘 다
└──────┘ └──────┘ └──────┘ └──────┘ → 용량 50% 손실
[미러 쌍 1] [미러 쌍 2]성능, 용량, 안정성의 트레이드오프를 정리하면 이렇다.
┌─────────────────────────────────────────────────────────┐
│ RAID 레벨 비교 (디스크 6개 기준) │
├──────────┬────────┬────────┬────────┬──────┬────────────┤
│ │ RAID 0 │ RAID 1 │ RAID 5 │RAID 6│ RAID 10 │
├──────────┼────────┼────────┼────────┼──────┼────────────┤
│ 실효 용량│ 6 디스크│ 3 디스크│ 5 디스크│4디스크│ 3 디스크 │
│ (6개중) │ (100%) │ (50%) │ (83%) │(67%) │ (50%) │
├──────────┼────────┼────────┼────────┼──────┼────────────┤
│ 허용 장애│ 0 │ 1 │ 1 │ 2 │ 미러당 1 │
├──────────┼────────┼────────┼────────┼──────┼────────────┤
│ 읽기 성능│ 최고 │ 좋음 │ 좋음 │ 좋음 │ 최고 │
├──────────┼────────┼────────┼────────┼──────┼────────────┤
│ 쓰기 성능│ 최고 │ 좋음 │ 보통 │ 낮음 │ 좋음 │
│ │ │ │(패리티)│ │ │
├──────────┼────────┼────────┼────────┼──────┼────────────┤
│ 주 사용처│ 임시 │ OS │ (비권장│ 범용 │ DB, 고성능 │
│ │ 데이터│ 부트 │ 대용량│ │ │
│ │ │ 디스크 │ 환경) │ │ │
└──────────┴────────┴────────┴────────┴──────┴────────────┘RAID 5가 위험해진 이유
RAID 5는 오랫동안 "가성비 최고"로 인기를 끌었다. 디스크 1개 분량의 패리티만으로 1개 디스크 장애를 견딜 수 있으니까. 하지만 대용량 디스크 시대에 RAID 5의 리스크가 급격히 올라갔다.
핵심은 리빌드 시간과 URE(Unrecoverable Read Error) 확률이다.
디스크 장애 발생 → RAID 리빌드 시작
리빌드: 나머지 디스크들의 데이터 + 패리티를
읽어서 새 디스크에 기록하는 과정
┌────────────────────────────────────────────────┐
│ RAID 리빌드 시간 추정 │
├──────────────┬───────────────┬──────────────────┤
│ 디스크 용량 │ 리빌드 시간 │ 위험도 │
│ │ (RAID 5 기준) │ │
├──────────────┼───────────────┼──────────────────┤
│ 1TB HDD │ 4~8시간 │ 보통 │
│ 4TB HDD │ 12~24시간 │ 주의 │
│ 8TB HDD │ 24~48시간 │ 위험 │
│ 16TB HDD │ 48~96시간 │ 매우 위험 │
│ │ │ │
│ SSD (올플래시)│ 수분~수시간 │ 상대적으로 안전 │
└──────────────┴───────────────┴──────────────────┘
리빌드 중에 두 번째 디스크가 죽으면?
RAID 5에서는 데이터 전체가 날아간다.
8TB HDD RAID 5, 리빌드 중 URE 발생 확률:
URE 발생 확률 = 디스크 수 × 디스크 용량 / URE 비율
SATA HDD URE: 10^14 비트당 1개 (약 12.5TB당 1개)
8TB × 5개 = 40TB 읽기 → URE 발생 확률 상당히 높음
→ 대용량 HDD 환경에서 RAID 5는 사실상 권장하지 않는다
→ RAID 6 또는 RAID 10을 써야 한다올플래시 환경에서는 상황이 다르다. SSD의 리빌드 시간이 HDD보다 훨씬 짧고, URE 비율도 낮다. 그래서 올플래시 스토리지에서는 RAID 5 유사 구현이 여전히 쓰이기도 한다. 환경에 따라 판단이 달라지는 거다.
벤더별 독자 RAID 구현
엔터프라이즈 스토리지 벤더들은 표준 RAID 대신 독자적인 데이터 보호 방식을 쓴다.
┌──────────────────────────────────────────────────────────┐
│ 벤더별 RAID / 데이터 보호 구현 │
├──────────────┬───────────────────────────────────────────┤
│ NetApp │ RAID-DP: 더블 패리티 (RAID 6 유사) │
│ │ RAID-TEC: 트리플 패리티 (3개 동시 장애 OK) │
│ │ → 대용량 디스크에서 RAID-TEC 권장 │
├──────────────┼───────────────────────────────────────────┤
│ Dell EMC │ ADAPT: 분산 RAID │
│ (PowerStore) │ → 리빌드가 전체 디스크에 분산 │
│ │ → 리빌드 시간 대폭 단축 │
├──────────────┼───────────────────────────────────────────┤
│ HPE │ ADM (Adaptive Data Mirror) │
│ (Alletra) │ → 적응형 미러링 │
├──────────────┼───────────────────────────────────────────┤
│ Pure Storage │ 전통 RAID 없음 │
│ │ 독자적 가변 스트라이프 + 이중 패리티 │
│ │ → 디스크 장애 시 전체 드라이브에 분산 복구 │
│ │ → "RAID를 생각하지 않아도 된다" │
└──────────────┴───────────────────────────────────────────┘벤더 독자 구현의 공통 트렌드는 "리빌드를 전체 디스크에 분산"하는 거다.
- 전통 RAID에서는 Hot Spare 1개에 집중적으로 쓰기가 발생해서 리빌드도 오래걸리고 부하로 인해 성능저하도 많이 체감되었었다.
- 분산 RAID에서는 평소 모든 디스크에 공간을 10%~15% 정도 비워두고, 장애 발생 시 비어있던 공간에 데이터를 복구한다(리빌드). 그 뒤에 새롭게 교체된 디스크에 데이터를 리벨런싱하는 식이다. 이렇게하면 모든 디스크가 조금씩 리빌드에 참여하니 시간과 부하가 줄어든다.
전통 RAID 리빌드:
[디스크1] [디스크2] [디스크3] [죽은4] [HotSpare]
│ │ │ ▲
└─────────┴─────────┴─── 전부 여기로 ─┘
(병목!)
분산 RAID 리빌드 (Dell ADAPT, Pure 등):
[디스크1] [디스크2] [디스크3] [디스크5] [디스크6]
▲ ▲ ▲ ▲ ▲
└─────────┴─────────┴─────────┴─────────┘
모든 디스크가 리빌드에 참여 → 시간 대폭 단축이레이저 코딩 — 분산 환경의 데이터 보호
분산 스토리지(Ceph, HDFS, MinIO)에서는 전통 RAID 대신 이레이저 코딩(Erasure Coding)을 쓴다. RAID가 "디스크 레벨"의 보호라면, 이레이저 코딩은 "노드 레벨"의 보호다.
HDFS 3-replica vs Erasure Coding (EC):
[3-replica] [Erasure Coding 6+3]
원본 데이터 1MB 원본 데이터 1MB
노드A: 1MB (복제1) 노드A: 166KB (조각1)
노드B: 1MB (복제2) 노드B: 166KB (조각2)
노드C: 1MB (복제3) 노드C: 166KB (조각3)
노드D: 166KB (조각4)
총 저장: 3MB (3배) 노드E: 166KB (조각5)
노드F: 166KB (조각6)
노드G: 166KB (패리티1)
노드H: 166KB (패리티2)
노드I: 166KB (패리티3)
총 저장: 1.5MB (1.5배)
9개 중 3개까지 유실 OK
→ EC가 용량 효율이 훨씬 좋다
→ 대신 읽기/쓰기 시 계산 오버헤드 있음RAID vs Erasure Coding 비교
┌──────────────────────────────────────────────────────┐
│ RAID vs Erasure Coding 비교 │
├──────────────────┬──────────────┬────────────────────┤
│ │ RAID │ Erasure Coding │
├──────────────────┼──────────────┼────────────────────┤
│ 적용 범위 │ 단일 장비 내 │ 클러스터/노드 간 │
│ 보호 단위 │ 디스크 │ 노드 / 서버 │
│ 용량 효율 │ 50~83% │ 60~80% │
│ 연산 오버헤드 │ 낮음 │ 있음 (인코딩/ │
│ │ │ 디코딩 필요) │
│ 리빌드/복구 │ 디스크 교체 │ 네트워크 통해 복구 │
│ 주 사용 환경 │ SAN 스토리지│ Ceph, HDFS, MinIO │
│ │ 엔터프라이즈│ 분산 스토리지 │
└──────────────────┴──────────────┴────────────────────┘RAID를 넘어선 데이터 보호
RAID(또는 EC)는 "디스크/노드 장애"에 대한 보호다. 하지만 데이터를 위협하는 건 디스크 장애만이 아니다. 실수로 삭제, 랜섬웨어 감염, 사이트 전체 재해. 이런 것들은 RAID로 못 막는다.
데이터 보호의 계층:
┌──────────────────────────────────────────────┐
│ 사이트 재해 (화재, 지진) │
│ └─► 원격 복제 (DR 사이트) │
│ │
│ 랜섬웨어 / 논리적 오류 / 실수 삭제 │
│ └─► 스냅샷 + 백업 (Immutable 스냅샷) │
│ │
│ 디스크/노드 장애 (물리적) │
│ └─► RAID / Erasure Coding │
│ │
│ 비트 레벨 오류 (Silent Data Corruption) │
│ └─► 체크섬 (ONTAP WAFL, ZFS 등) │
└──────────────────────────────────────────────┘
RAID는 이 계층에서 한 층만 담당한다.
전체 보호 전략은 시리즈 후반(백업, 보안 편)에서 다룬다.3-2-1 백업 원칙이라는 게 있다. 데이터 복사본 3개, 서로 다른 매체 2종류, 오프사이트 1곳. 이 원칙과 RAID/스냅샷/복제가 어떻게 맞물리는지는 나중에 백업 편에서 자세히 다룬다.
다음 편부터는 라이프사이클의 첫 단계 — 도입 검토로 들어간다. 실제로 스토리지를 사야 할 때, 워크로드를 어떻게 분석하고, 벤더를 어떻게 비교하고, RFP를 어떻게 쓰는지. "사는 것"부터가 스토리지 엔지니어링의 시작이다.
이 글이 어떠셨나요?
관련 포스트
2. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
DAS, NAS, SAN, Object Storage의 구조와 차이를 아스키 도표와 함께 정리한다. 어떤 워크로드에 어떤 방식을 선택하는가의 판단 기준과 벤더별 제품 포지셔닝까지.
2026. 04. 06. 오후 10:00Infrastructure1. 스토리지, 왜 어렵고 왜 중요한가
서버는 죽어도 살리면 되지만 스토리지는 잃으면 끝이다. 10년차 시스템 엔지니어가 스토리지가 어렵고 중요한 이유, 스토리지 담당자의 실제 업무, 기술의 진화 흐름을 현장 경험 기반으로 풀어본다.
2026. 03. 30. 오후 10:00Infrastructure4. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
FC Zoning과 ALUA, iSCSI 네트워크 설계, NFS 마운트 옵션, SMB 멀티채널, S3 API까지. 스토리지 프로토콜의 동작 원리와 실무 설정 포인트를 아스키 도표와 함께 정리한다.
2026. 04. 20. 오후 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.