있음은 곧 완료야

"파일은 검증되고 원자적으로 rename된 뒤에만 캐시 항목이 돼. 그전까진 거기 없는 거야."

반쯤 쓰인 파일

캐시를 조용히 망치는 실패가 있어. 오디오를 합성하고, 캐시 경로에 쓰기 시작하는데, 뭔가 끊어 — 크래시, 꽉 찬 디스크, 죽은 프로세스. 이제 잘린 파일이 다음 읽는 쪽이 확인하는 바로 그 경로에 앉아 있어. 캐시 히트처럼 보여. 잡음 폭발이나 십 초 문장의 삼 초로 재생돼. 캐시가 그냥 miss한 게 아니라 — 거짓말했어.

바이트와 캐시 항목 사이의 두 단계

Bellows는 읽는 쪽이 진행 중 파일을 절대 못 보게 해. 갓 나온 오디오는 먼저 임시 파일에 쓰여 — 진짜 미디어 확장자로, validator가 실제로 디코드할 수 있게. 그다음 검증돼: 디코드하고, 예상한 모양의 진짜 오디오인지 확인하고, 잘렸거나 무음인 건 거부해. 통과한 뒤에만 원자적 rename으로 제자리에 옮겨져. 단일 파일시스템에서 rename은 원자적이야: 읽는 쪽은 옛 상태나 완전히 완성된 새 파일을 보지, 중간은 절대 안 봐.

왜 이 순서가 보증 전부인가

발행이 마지막 단계고 원자적이라, 캐시 항목의 존재 자체가 그게 완전하고 유효하다는 증거야. 읽는 쪽이 재확인할 필요 없고; 요청이 "이 파일 다 됐나?" 플래그가 필요 없어. "거기 있다"랑 "좋다"가 같은 사실이 돼. 그게 validate-then-rename의 보상이야: 정확성이라는 질문 전체를, 파일이 아예 보이기 전으로 옮기는 거야.

Code

임시 파일, 검증, 원자적 rename·python

import os, tempfile

def publish_cache_entry(identity: str, audio_bytes: bytes) -> str:
    final = cache_path(identity)                     # where readers will look

    # 1. Write to a temp file WITH a real media suffix (the validator needs it).
    fd, tmp = tempfile.mkstemp(dir=os.path.dirname(final), suffix=".mp3")
    with os.fdopen(fd, "wb") as f:
        f.write(audio_bytes)

    # 2. VALIDATE: decode it. A truncated or silent file fails HERE, not on play.
    if not is_valid_audio(tmp):
        os.unlink(tmp)
        raise SynthesisInvalid(identity)

    # 3. ATOMIC RENAME: from here on, 'present' means 'complete and valid'.
    os.replace(tmp, final)                           # atomic on the same filesystem
    return final

Exercise

네가 아는 시스템에서 읽는 쪽이 반쯤 쓰인 파일이나 레코드를 볼 수 있는 곳을 찾아 — append되는 로그, 업로드 중인 이미지, 제자리에서 재작성되는 config. 읽는 쪽이 쓰기 중간에 도착하면 뭘 보는지 묘사해. 그다음 흐름을 write-temp, validate, atomic-rename으로 다시 쓰고, '파일이 존재한다'가 이제 뭘 보증하는지 말해.

Hint

단서는 읽는 쪽이 쓰는 경로에 직접 쓰는 코드 아무거나야. 쓰기랑 가시성이 같은 단계면 창이 있어; 고침은 가시성을 별개의, 원자적인, 마지막 단계로 만드는 거야.