5.3 인제스트 설계 - 입력 유형, 완결성, 체크섬, 정규화

#인제스트란

인제스트(Ingest) 는 외부의 미디어를 MAM으로 끌어들여 등록하는 과정입니다. 단순한 복사가 아니라 "이 파일을 믿고 쓸 수 있는 상태로 만드는" 일련의 절차입니다.

입수 → 완결성 확인 → 체크섬 계산 → 분석 → (필요 시) 표준 포맷 변환 → QC → 프록시 생성 → 메타데이터 등록 → 완료

#입력 유형별 특징

#문제: 파일이 "다 써졌는가"

감시 폴더 방식에서는 폴더에 파일이 나타나면 인제스트를 시작합니다. 하지만 파일이 폴더에 보이는 시점과 쓰기가 끝난 시점은 다릅니다. 대용량 파일을 복사하거나 FTP로 올리는 동안에도 파일은 이미 목록에 나타납니다.

쓰는 도중에 읽기 시작하면 다음 일이 생깁니다.

• 분석이 잘린 파일로 이루어져 길이와 구조 정보가 틀림(3장의 잘린 MXF)
• 변환 결과가 일부만 만들어짐
• 체크섬이 전송이 끝난 뒤의 값과 다름

#완료 판단 방법

#실험: 배타적 열기는 믿을 수 없다

6MB 파일을 1초에 1MB씩 쓰는 별도 프로세스를 만들고, 쓰는 도중에 Windows에서 파이썬으로 파일을 읽기/쓰기 모드로 열어 보았습니다.

쓰는 도중(크기 2,000,000바이트) 열기 시도 → 성공(True)

쓰기 중인 파일도 열렸습니다. 운영체제와 파일 공유 모드, 프로그램에 따라 열림 여부가 다르므로 "열리면 완료"라는 가정은 위험합니다.

#실험: 크기·수정 시각 안정성

같은 파일에 대해 크기와 수정 시각이 일정 간격으로 같은 값을 연속 N번 유지하면 완료로 보는 함수입니다.

import time
from pathlib import Path


def is_stable(path: Path, wait=2.0, checks=3):
    """크기와 수정 시각이 wait초 간격으로 checks번 연속 같으면 쓰기가 끝난 것으로 본다."""
    last, same = None, 0
    while True:
        st = path.stat()
        cur = (st.st_size, st.st_mtime_ns)
        same = same + 1 if cur == last else 1
        last = cur
        if same >= checks:
            return True
        time.sleep(wait)

위 쓰기 프로세스(6초 동안 쓰기)를 대상으로 wait=1.5, checks=3으로 실행하자 약 7.5초 뒤에 True 를 반환했고, 이때 파일 크기는 최종 크기(6,000,000바이트)와 같았습니다. 쓰는 동안에는 값이 계속 바뀌므로 안정 판정이 나지 않았고, 쓰기가 끝난 뒤 3번 연속 같은 값이 확인되자 완료로 판단했습니다.

#이 방식의 한계

• 네트워크가 일시적으로 멈추면(전송 중 정체) 쓰기가 끝나지 않았는데 완료로 오판할 수 있습니다. wait × checks 시간은 환경의 최악의 정체 시간보다 길게 잡아야 합니다.
• 반대로 값을 너무 크게 잡으면 인제스트 시작이 늦어집니다.
• 그래서 가능하면 송신 측과 약속(임시 이름으로 쓴 뒤 rename, 또는 완료 마커)하고, 안정성 검사는 안전장치로만 쓰는 것을 권장합니다.

#체크섬

체크섬(해시) 은 파일 내용에서 계산한 고정 길이의 값으로, 파일이 한 비트라도 달라지면 값이 바뀝니다. 인제스트에서 체크섬은 세 가지 용도로 씁니다.

1. 전송 검증: 송신 측이 알려준 체크섬과 수신 후 계산한 값이 같은지 비교
2. 저장 검증: 일정 기간 후(또는 아카이브 후) 다시 계산해 비트 손상(bit rot) 여부 확인
3. 중복 검출: 같은 체크섬이면 같은 파일로 판단

체크섬 알고리즘은 목적에 따라 고릅니다.

같은 PC(256MB 메모리 데이터, 단일 스레드, 파이썬 hashlib)에서 측정한 처리 속도입니다.

예상과 달리 SHA-256이 MD5보다 빨랐습니다. 최근 CPU는 SHA 계열 전용 명령을 가지고 있어 순위가 CPU에 따라 바뀝니다. "MD5가 가장 빠르다"는 옛 상식으로 알고리즘을 고르지 말고, 대상 서버에서 직접 측정하세요. 또한 이 수치는 메모리 속도이므로, 실제 인제스트의 병목은 대개 디스크와 네트워크의 읽기 속도입니다. 수 GB/s의 해시 속도보다 스토리지가 훨씬 느리다면, 어떤 알고리즘을 쓰든 총 시간은 거의 같습니다.

방송 소재는 한 파일이 수십~수백 GB이므로 계산 시간과 I/O 비용이 큽니다. 인제스트에서는 파일을 복사하면서 동시에 해시를 계산해 읽기를 한 번으로 줄이는 방식이 일반적입니다.

#표준 포맷 정규화

다양한 포맷으로 들어오는 소재를 시스템의 표준 포맷으로 통일하면 이후 처리가 단순해집니다. 표준 포맷을 정하는 기준은 다음과 같습니다.

• 원본 품질 저하가 최소인가
• 용량이 합리적인가
• 편집·송출 시스템에서 바로 쓸 수 있는가
• 구간 추출(Partial Restore)을 지원하는 포맷인가(아카이브 편)

정규화는 무조건 변환하는 것이 아닙니다. 이미 표준에 맞는 파일은 그대로 등록하고(재래핑·복사만), 맞지 않는 파일만 변환합니다. 재인코딩은 화질 손실과 시간 비용이 있으므로 판정 규칙(코덱·해상도·프레임레이트·주사 방식이 프로파일과 일치하는가)을 분석 결과(3장)로 자동 판단합니다.

#실패 처리

인제스트는 반드시 실패합니다. 실패를 어떻게 다루는지가 시스템의 품질을 좌우합니다.

• 원본은 절대 지우지 않습니다. 인제스트가 완전히 끝나 검증이 통과한 뒤에도 일정 기간 보관합니다.
• 모든 단계의 결과와 실패 이유를 작업 이력에 남겨 사용자가 확인할 수 있게 합니다.
• 실패는 사람이 이해할 수 있는 문장으로 표시합니다("FFmpeg 종료 코드 1"이 아니라 "파일이 중간에 끊겨 있습니다").

#정리

• 인제스트는 입수, 완결성 확인, 체크섬, 분석, 정규화, QC, 프록시, 등록의 연속 절차입니다.
• 감시 폴더에서는 쓰기 완료 판단이 핵심이며, 배타적 열기는 신뢰할 수 없고 크기·시각 안정성은 안전장치로 쓰는 편이 좋습니다. 송신 측과 임시 이름/마커 약속을 우선합니다.
• 체크섬, 정규화 판정 규칙, 실패 처리 방침을 설계 초기에 정해야 합니다.