무결성(Fixity) 관리 - 비트 하나가 바뀌면 생기는 일

#Fixity란

Fixity(고정성) 는 "이 파일이 보관을 시작했을 때와 똑같은 상태인가"를 확인하는 것입니다. 장기 보관에서는 파일을 열 일이 거의 없으므로, 열어 보기 전까지 손상을 모릅니다. 그때는 이미 복구할 수 있는 다른 복본도 함께 손상되었을 수 있습니다. 그래서 주기적으로 확인하는 체계가 필요합니다.

#실험: 1비트가 바뀌면

10초짜리 MXF 파일(약 62MB)을 두 개로 복사한 뒤, 하나의 한가운데 1바이트에서 1비트만 반전시켰습니다.

import hashlib, os, shutil

def sha(p):
    h = hashlib.sha256()
    with open(p, 'rb') as f:
        for b in iter(lambda: f.read(1 << 20), b''):
            h.update(b)
    return h.hexdigest()

shutil.copy('src.mxf', 'copy1.mxf')
shutil.copy('src.mxf', 'copy2.mxf')
base = sha('src.mxf')

with open('copy2.mxf', 'r+b') as f:                 # 한가운데 1비트 반전
    f.seek(os.path.getsize('copy2.mxf') // 2)
    b = f.read(1)
    f.seek(-1, 1)
    f.write(bytes([b[0] ^ 0x01]))

print(sha('copy1.mxf') == base)   # True  : 정상 복사본
print(sha('copy2.mxf') == base)   # False : 1비트 반전

결과는 다음과 같았습니다.

검사	정상 복사본	1비트 반전 복사본
SHA-256 일치	일치	불일치(해시값이 완전히 다름)
파일 크기	동일	동일
`ffmpeg -i copy2.mxf -f null -` (디코딩)	오류 없음	오류 없음(종료 코드 0)

1비트 손상은 디코딩에서 아무 오류도 나타나지 않았습니다. 영상 한 프레임의 일부 픽셀이 미세하게 달라졌을 뿐이라 디코더는 정상으로 처리합니다. 눈에 띄지 않는 손상은 체크섬만 확실하게 잡아냅니다.

#매니페스트 기반 검증

체크섬 검증은 기준값(보관 시점의 체크섬) 이 있어야 의미가 있습니다. 파일 옆이나 DB에 매니페스트(파일 목록과 체크섬)를 보관합니다.

# manifest-sha256.txt  (BagIt 등에서 쓰는 형식과 유사)
e5702873c6a1949756c45e0a7e3c8a14...  data/a1.mxf
3b4c7b9d1f0a8e2c6d5e4f3a2b1c0d9e...  data/a1_proxy.mp4

검증 절차는 다음과 같습니다.

보관 직후 체크섬을 계산해 DB와 매니페스트 양쪽에 저장한다.
전송·복사·복원 때마다 대상 파일의 체크섬을 다시 계산해 비교한다.
정기 점검(scrubbing) 때 같은 방식으로 비교한다.
불일치하면 다른 복본의 체크섬과 비교해 어느 쪽이 손상되었는지 판단하고, 정상 복본에서 복구한다.

기준 체크섬이 손상되지 않았다는 보장도 필요합니다. 체크섬 목록 자체를 별도 복본으로 보관하세요.

#정기 점검(Scrubbing)

매체	점검 방법	주기(예시)
디스크(니어라인)	파일 체크섬 재계산, 스토리지의 자체 scrub 기능	분기~반기
LTO 테이프	일부 샘플 또는 전체를 로드해 읽고 체크섬 확인	연 1회 샘플 + 세대 이관 시 전수
클라우드 객체	저장된 체크섬과 비교, 서비스 무결성 기능 활용	정책에 따라

점검 주기는 데이터의 중요도, 복본 수, 매체의 오류율, 점검 비용을 고려해 정합니다. 점검 자체가 읽기 부하(테이프 마모, 대역폭, 클라우드 조회료)를 만든다는 점도 반영해야 합니다.

#복본 비교와 복구

복본이 2개 이상일 때 불일치 상황별 판단은 다음과 같습니다.

상황	판단	조치
복본 A = 기준값, B ≠ 기준값	B 손상	A로 B를 복구하고 B 매체 점검
A ≠ 기준값, B ≠ 기준값 (서로 다름)	모두 손상 가능성	다른 복본·원본·프록시 확인. 부분 복구 검토
A = B ≠ 기준값	기준값이 틀렸을 가능성	기준 체크섬 기록 오류 확인
모두 기준값과 일치	정상	점검 이력 기록

복본이 하나뿐이면 손상을 발견해도 복구할 방법이 없습니다. 그래서 무결성 관리는 복본 정책과 반드시 함께 설계됩니다.

#체크섬 외의 방어

전송 중 검증: 복사하면서 해시 계산, 도착 후 비교(인제스트 편의 설계)
미디어 자체의 오류 정정: ECC, RAID, 파일 시스템 체크섬(ZFS 등) 같은 하위 계층 방어를 사용하되, 이를 체크섬 검증의 대체로 보지 않습니다.
오류가 있는 영상의 수리: 일부 프레임만 손상된 영상은 다른 복본의 해당 구간으로 교체할 수 있도록 구간 단위 체크섬(예: GOP 단위)을 보관하는 방법도 있습니다.
감사 기록: 언제 누가 어떤 검증을 했고 결과가 무엇인지를 기록합니다(법적 증빙, 감사 대비).

현업 경험 · 처리 결과는 정상인데 손상이 발견된 경험

파일을 FTP로 받거나, 파일 시스템으로 복사하거나, NLE에서 렌더링한 파일을 쓰려고 할 때, 그리고 아카이브한 뒤 정합성을 점검할 때 손상이 발견된 적이 있습니다. 문제는 프로그램의 처리 결과에는 이상이 없다고 기록되어 있었다는 점입니다. 원인을 알 수 없는 경우가 많았고, 복구할 수 있는 부분만 복구한 뒤 다시 아카이브해야 했습니다. 그러려면 전체 작업을 다시 돌려야 해서, 자동화 작업에 시스템을 할당하고 수일에서 수개월이 걸리는 시간 지연이 생겼습니다. (앞의 1비트 반전 실험처럼, 처리 성공 기록만으로는 손상을 알 수 없습니다.)

#정리

1비트 손상은 재생·디코딩으로 발견되지 않으며 체크섬만이 확실하게 잡아냅니다.
기준 체크섬을 보관 시점에 DB와 매니페스트에 저장하고, 전송·복원·정기 점검 때 비교합니다.
복구는 정상 복본이 있어야 가능하므로 무결성 관리와 복본 정책은 함께 설계합니다.