디스크가 고장 나도 파일이 살아남는 이유

숫자 세 개를 적은 쪽지를 서랍 세 칸에 나눠 두면서, 네 번째 칸에 "세 수의 합계"를 함께 적어 둔다고 해 봅시다. 서랍 하나를 잃어버려도 걱정이 없습니다. 남은 두 수와 합계로 잃어버린 수를 역산하면 되니까요.

NAS의 RAID 패리티가 정확히 이 방식입니다. 파일을 블록으로 잘라 여러 디스크에 나눠 쓰고, 같은 줄 블록들을 계산한 "합계 메모"(패리티)를 한 블록 더 적어 둡니다.

합계 대신 XOR을 쓰는 이유

컴퓨터의 합계 메모는 XOR(⊕)입니다. XOR에는 특별한 성질이 하나 있습니다. 같은 값을 두 번 XOR 하면 사라집니다 (a⊕b⊕b = a). 그래서:

저장할 때: b1 ⊕ b2 ⊕ b3 = P (패리티)
복구할 때: b1 ⊕ b3 ⊕ P = b2. 남은 값들을 다시 XOR 하면 잃어버린 블록만 정확히 남습니다.

덧셈처럼 자릿수가 넘칠 일도 없고, 어느 블록이 없어져도 같은 계산 하나로 됩니다. 추가 비용은 디스크 한 대 분량의 패리티뿐입니다.

디스크 하나가 죽으면

죽은 디스크의 블록은 그 자리에서 XOR로 즉석 복구되어 파일이 온전히 열립니다. 다만 읽을 때마다 계산이 필요해 느려집니다(degraded 모드).
새 디스크로 갈아 끼우면 같은 계산으로 블록을 처음부터 다시 채웁니다 (리빌드).

라우팅 랩에서 회선이 끊겨도 패킷이 우회하듯, 저장장치도 "고장은 반드시 난다"를 전제로 설계됩니다. 고장이 나도 멈추지 않는 것이 목표입니다. 이렇게 살아남은 파일이 내 PC까지 오는 길은 2편 파일 공유 랩에서 다룹니다.

패리티는 식 하나입니다. 식 하나로는 미지수 하나만 풀 수 있습니다. 리빌드가 끝나기 전에 디스크가 하나 더 죽으면 미지수가 두 개가 되어 복구 불가입니다. 어레이가 멈춥니다. 그리고 실수로 지운 파일, 랜섬웨어, 화재는 RAID가 전혀 막아주지 못합니다. 그래서 RAID가 있어도 백업은 따로 필요합니다. 어떻게 따로 둘지는 3편 백업 3-2-1 랩에서 다룹니다.

리빌드 중이 가장 위험한 순간입니다

앞에서 "리빌드가 끝나기 전에 하나 더 죽으면 끝"이라고 했는데, 이게 생각보다 현실적인 걱정인 이유가 있습니다.

리빌드는 남은 모든 디스크를 처음부터 끝까지 전부 읽습니다. 잃어버린 블록을 계산하려면 같은 줄의 나머지 블록이 전부 필요하니까요. 즉 디스크 한 대가 죽은 직후, 나머지 디스크들은 평소보다 훨씬 무거운 작업을 몇 시간에서 며칠씩 받게 됩니다.

디스크 용량이 클수록 리빌드 시간이 길어집니다. 위험한 시간이 그만큼 늘어납니다.
전체를 읽는 도중 복구할 수 없는 읽기 오류를 만나면 해당 블록을 재구성하지 못할 수 있습니다. 디스크 제조사는 이 확률을 데이터시트에 명시하는데, Seagate IronWolf Pro 데이터시트에는 읽은 비트 수 대비 오류율 항목이 들어 있습니다. 실제 영향은 디스크 사양뿐 아니라 컨트롤러의 오류 처리, 파일 시스템, 배열 구성에 따라 달라집니다.
남은 디스크의 상태와 백업 유무를 먼저 확인하고, 제조사 절차에 따라 교체와 리빌드를 진행해야 합니다.

가용성을 더 중시한다면 패리티를 두 개 두는 구성(RAID 6 계열)을 검토할 수 있습니다. 미지수 두 개를 풀 수 있는 식이 두 개인 셈이라, 한 디스크를 복구하는 동안 다른 한 대가 고장 나도 배열이 견딜 수 있습니다. 다만 최선의 구성은 디스크 수·용량, 성능 요구, 복구 시간, 별도 백업에 따라 달라집니다.

"몇 시간"이 아니라 계산해 볼 수 있습니다

리빌드 시간은 감으로 말할 필요가 없습니다. 최소한 디스크 한 대를 통째로 쓰는 시간은 걸리기 때문입니다. 제조사가 공개한 사양을 그대로 대입해 보겠습니다.

Seagate IronWolf Pro 12TB 데이터시트의 값입니다.

사양 항목	값
최대 지속 전송률(바깥 트랙 기준)	250 MB/s
복구 불가 읽기 오류(최대)	10¹⁵ 비트당 1회
MTBF	1,200,000시간
연간 고장률(AFR, 24×7)	0.73%

12TB를 250MB/s로 쭉 읽으면 12조 ÷ 2.5억 = 48,000초, 약 13시간 20분입니다. 그런데 이건 가장 좋은 경우의 바닥값입니다. 실제로는 이보다 오래 걸립니다.

250MB/s는 바깥 트랙(OD) 기준입니다. 안쪽 트랙으로 갈수록 느려집니다.
리빌드 중에도 NAS는 평소 요청을 받습니다. 그만큼 나눠 씁니다.
많은 제품이 리빌드 속도에 제한을 걸어 둡니다. 서비스가 멈추지 않게 하려고요.

그래서 "12TB 한 대 교체에 하루 이틀"이라는 이야기는 과장이 아니라 산수의 결과입니다. 그리고 그동안 나머지 디스크는 계속 전체 읽기를 당합니다.

읽기 오류 사양은 어떤 크기인가

같은 표의 "10¹⁵ 비트당 1회"도 크기 감각을 잡는 데 씁니다. 12TB를 한 번 완독하면 약 9.6 × 10¹³ 비트를 읽습니다. 사양 상한의 약 10분의 1 분량입니다. 4대짜리 RAID 5에서 한 대가 죽으면 남은 3대를 전부 읽으므로 2.9 × 10¹⁴비트, 상한의 약 3분의 1에 해당하는 양을 한 번의 리빌드에서 읽는 셈입니다.

여기서 멈춰야 합니다. 이 계산은 "리빌드가 실패할 확률"이 아닙니다.

데이터시트의 값은 보증 상한이지 실제로 그만큼 오류가 난다는 뜻이 아닙니다.
오류를 만났을 때 배열이 멈추는지, 해당 블록만 포기하는지는 컨트롤러와 파일 시스템의 처리 방식에 따라 다릅니다.
위 값은 특정 제품군의 사양이고 모델·세대마다 다릅니다. 같은 제조사에서도 일반 IronWolf 계열은 다른 값을 씁니다.

읽어 갈 것은 하나입니다. 용량이 커질수록 리빌드 한 번에 읽는 양도 같이 커지고, 위험에 노출되는 시간도 길어진다. 그래서 큰 디스크를 쓸수록 패리티를 두 개 두는 구성과 별도 백업의 값어치가 올라갑니다.

어떤 구성을 고를까

이름이 많아 보이지만 고르는 기준은 결국 세 가지의 균형입니다. 쓸 수 있는 용량, 견딜 수 있는 고장 수, 속도.

RAID 0 — 나눠 쓰기만 하고 패리티가 없습니다. 용량과 속도는 최대지만 한 대만 죽어도 전부 잃습니다. 사실상 백업이 확실한 임시 작업 공간용입니다.
RAID 1 — 통째로 복사본을 둡니다. 용량은 절반이지만 단순하고 복구가 빠릅니다. 디스크 두 대짜리 소형 NAS에서 흔합니다.
RAID 5 — 이 데모가 다루는 방식. 패리티 하나, 고장 한 대까지. 용량 효율이 좋아 오래 쓰였습니다.
RAID 6 — 패리티 둘, 고장 두 대까지. 가용성을 높이는 대신 RAID 5보다 쓸 수 있는 용량이 줄고 쓰기 계산이 늘어납니다.

말로 하면 헷갈리니 식으로 적어 두겠습니다. 디스크 N대, 한 대 용량 C일 때 쓸 수 있는 용량은 이렇습니다.

구성	쓸 수 있는 용량	견디는 동시 고장	4대 × 12TB라면
RAID 0	N × C	0대	48TB
RAID 1 (2대 미러)	C	1대	12TB
RAID 5	(N−1) × C	1대	36TB
RAID 6	(N−2) × C	2대	24TB
RAID 10 (2대씩 미러 후 묶기)	(N ÷ 2) × C	최소 1대	24TB

표를 세로로 읽으면 용량과 안전이 정확히 맞바꿔지고 있다는 게 보입니다. 같은 디스크 4대로 48TB를 쓰면 고장을 하나도 못 견디고, 24TB만 쓰면 두 대까지 견딥니다. RAID 5의 36TB는 그 사이의 타협입니다.

RAID 10의 "최소 1대"는 표현이 애매해 보이지만 정확한 서술입니다. 서로 다른 미러 짝에서 한 대씩 죽으면 2대가 죽어도 살지만, 같은 짝의 두 대가 죽으면 1대에서 이미 끝납니다. 운에 달린 부분이 있다는 뜻입니다.

어느 쪽을 골라도 바뀌지 않는 것이 하나 있습니다. 실수로 지운 파일과 랜섬웨어는 어떤 RAID도 막지 못합니다. 구성 선택은 "디스크 고장"이라는 한 가지 사고에 대한 답일 뿐입니다.

직접 디스크를 고장 내 보기

아래 파란 버튼만 누르세요

블록이 채워지고, 사라지고, 되살아나는 걸 보세요

대기 중

photo.jpg → 블록 9개 (스트라이프 3줄 × 3블록) + 패리티 3개

D1정상

···

D2정상

···

D3정상

···

P정상

···

XOR 계산기

블록을 쓰거나 복구할 때, 여기서 실제 바이트 값으로 XOR 계산을 보여드려요.

지나온 기록

저장을 시작하면 단계마다 기록이 쌓여요.

시나리오를 고르고 저장 시작을 누르세요. 파일이 블록으로 나뉘어 저장되고, 디스크가 고장 나는 순간부터가 진짜예요.

원리 세 가지만

패리티 하나로 고장을 견디는 이유

01나눠 쓰고, 함께 적어요.

파일을 블록으로 잘라 여러 디스크에 나눠 쓰고(스트라이핑), 같은 줄 블록들을 XOR한 패리티를 한 블록 더 적어 둬요. 추가 비용은 디스크 한 대 분량뿐이에요.

02XOR은 되돌릴 수 있어요.

같은 값을 두 번 XOR 하면 사라져요(a⊕b⊕b=a). 그래서 패리티에서 남은 블록들을 다시 XOR 하면, 잃어버린 블록만 정확히 남아요.

03딱 한 대까지만 견뎌요.

식 하나로는 미지수 하나만 풀 수 있어요. 두 대가 동시에 죽으면 복구 불가 — 그래서 RAID가 있어도 백업은 따로 필요해요.

블록 나눠 쓰기패리티 함께 적기고장 나면 XOR 복구새 디스크 리빌드

데모만 따로 보려면 전체 화면으로 열기.

디스크 1대 고장에서 저장 시작을 누르고, 스트라이프마다 패리티가 계산되는 것을 XOR 계산기에서 확인합니다.
D2가 죽은 뒤 ⚡ 남은 블록들의 XOR로 잃어버린 값이 그대로 나오는 순간을 봅니다. 실제 바이트 값이라 2진수로 검산할 수 있습니다.
디스크 2대 고장으로 바꿔, 미지수가 2개가 되어 식이 풀리지 않는 것을 확인합니다.

결국 남는 한 문장

파일은 블록으로 나뉘어 저장되고, 같은 줄 블록들의 XOR이 패리티로 함께 적힙니다. 그래서 디스크 하나가 죽어도 남은 블록들의 XOR로 잃어버린 블록이 그대로 돌아옵니다. 딱 거기까지입니다. 두 대가 동시에 죽으면 미지수가 둘이 되어 손을 쓸 수 없고, 실수로 지운 파일은 패리티까지 같이 지워집니다.

RAID는 디스크 고장에만 듣는 장치입니다. 백업은 3편에서 따로 다룹니다.

무엇이 관측이고 무엇이 계산인지

데모의 바이트 값 — 실제로 XOR 연산을 수행한 결과입니다. 2진수로 직접 검산할 수 있습니다. 다만 패리티를 마지막 디스크에 고정한 배치(RAID 4에 가까움)로 단순화했고, 실제 RAID 5는 쓰기 부하를 나누기 위해 패리티 위치를 스트라이프마다 돌려가며 둡니다.
사양 표의 값 — Seagate가 공개한 IronWolf Pro 데이터시트에서 그대로 옮긴 제조사 사양입니다. 제가 측정한 값이 아닙니다.
13시간 20분과 비트 수 — 그 사양을 나눗셈한 계산 결과입니다. 가정 (바깥 트랙 최대 속도, 다른 부하 없음)을 그대로 적어 뒀으니 조건이 다르면 값도 달라집니다. 실제 장비의 리빌드 시간을 예측한 것이 아닙니다.
용량 표 — 각 RAID 레벨의 정의에서 나오는 산수입니다.

데모가 다루지 않는 것: 패리티 회전, 쓰기 시 읽기-수정-쓰기 부담, 체크섬 기반 파일 시스템의 무결성 검사, 핫스페어, 배열 확장. RAID라는 이름은 1988년 버클리의 논문에서 나왔습니다.