C.W.K.
Stream
Lesson 02 of 04 · published

NAS 가 바이너리를 소유해

~11 min · references, storage-ownership, tombstone, no-hoarding

Level 0Empty Shelf
0 XP0/35 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"재생성할 수 있는 건 전부 소유해. 못 하는 그 하나는 참조해."

쌓아두기 본능

엔진을 지을 때 자기 완결적으로 만들고 싶은 강한 끌림이 있어: 엔진은 필요한 전부를 소유해야지. 영상을 자기 저장소로 복사하면, 이제 완결이고, 이식 가능하고, 아무것에도 안 의존해. Recall 은 거부하고, 그 거부가 가장 깔끔한 선 중 하나야: 스토리지가 원본 미디어를 소유해. Recall 은 경로, 메타데이터, hash, 그리고 자기가 파생하는 증거를 저장해 — 아카이브를 자기 DB 로 절대 복사 안 해.

쌓아두기 비용이 즉시 쌓여. 방금 몇 기가짜리 파일 수천 개를 중복했으니, 이제 저장하고, 백업하고, 동기화할 두 번째 아카이브가 있어. 그리고 마지막 게 치명적이야: 사본이 둘이면 어느 사본이 진짜인지의 상시 질문 — 트랙 2 가 동기화 폴더에서 받아들이길 거부한 바로 그 모호함. 자족감 하나와 맞바꿔 그 버그 부류 전체를 import 한 거야.

훔칠 만한 뒤집기

Recall 이 실제로 뭘 쥐고 뭘 가리키는지 봐, 그 분리가 본능의 반대니까:

  • 증거, release, segment, index 를 소유해 — 전부 잃어도 재생성할 수 있는 것들(다시 전사, 다시 투영, 다시 색인).
  • 원본 footage 를 참조해누구도, 영원히, 재생성 못 하는 유일한 산물. 그 파일이 사라지면, 어떤 연산도 못 되돌려.

그게 뒤집기야: 엔진은 재구축할 수 있는 전부를 소유하고 못 하는 하나는 그냥 참조해. 거꾸로 들리다가 논리를 보면 알아 — 대체 불가능한 건 job 을 돌리고, 스키마를 바꾸고, 쓰기 중에 서비스 매니저한테 재시작당하기도 하는 애플리케이션이 아니라, 바이트를 안전히 지키는 게 일 전부인 소유자를 받을 자격이 있어. 스토리지는 저장을 잘해. 엔진은 의미를 잘해야 하고. 엔진을 자기가 재창조 못 하는 그 하나의 관리인으로 만들지 마.

tombstone: 기억이 파일보다 오래 살아

이 분리가 조용히 뭉클한 결과를 낳아. 스캔이 영상이 살던 데 더는 없다는 걸 찾으면, Recall 은 record 를 안 지워 — 사라진 날짜와 함께 missing 으로 표시해. 나중 스캔이 다시 찾으면 표시가 지워져. 그리고 그동안, tombstone 된 그 영상은 검색 가능하고 export 가능하게 남아. 그냥 작업 큐에 못 넣고 live 소스 미디어로 못 열 뿐이야, 바이트가 없으니까.

기억 엔진한테 그게 뭘 뜻하는지 앉아서 생각해봐. 파일을 잃어도, 기억은 지켜: transcript, 타임스탬프, 요약, 뭐라고 했고 언제였는지 — 전부 살아남아, 증거는 파생돼서 소유됐고 바이너리는 참조만 됐으니까. 더는 안 가진 영상을 여전히 검색하고 거기서 뭐라고 했는지 정확히 읽을 수 있어. 그냥 못 볼 뿐이야. 그게 위로상이 아니라; 아키텍처가 두 종류의 상실에 대해 정직하고, 기록과 footage 가 같은 거라고 척하길 거부하는 거야.

Code

바이트는 참조; 의미는 소유·sql
CREATE TABLE videos (
  video_id       TEXT PRIMARY KEY,   -- 안정된 논리적 identity
  source_id      TEXT NOT NULL,      -- 어느 아카이브 root
  relative_path  TEXT NOT NULL,      -- 어디 사나 (참조)
  size_bytes     INTEGER,
  modified_ns    INTEGER,
  source_sha256  TEXT,               -- 바이트의 identity
  missing_since  TEXT,               -- tombstone: 언제부터 사라짐
  title          TEXT
  -- 여기 없는 걸 봐: 영상 바이트.
);

-- 소유 (재생성 가능): run, release, segment, fts, 요약
-- 참조 (대체 불가): 스토리지의 원본 footage

-- tombstone 된 영상은 검색 가능하고 export 가능하게 남는다.
-- 그냥 큐에 못 넣고 live 미디어로 못 열 뿐.
-- 기억이 파일보다 오래 산다.

External links

Exercise

파일이나 외부 record 를 ingest 하는, 네가 지은 시스템을 봐. 복사해 넣어, 참조해? 복사하는 각각에 대해 물어: 잃으면 재생성할 수 있어? 그렇다면 소유해도 돼. 아니라면, 네 애플리케이션이 대체 불가능한 것의 진짜 맞는 관리인인지 — 그리고 네 '어느 사본이 진짜?' 규칙이 뭔지 물어. 그다음 tombstone 을 설계해: 참조된 소스가 사라지면, 뭐가 살아남고, 뭐가 불가능해져?
Hint
질문 둘: (1) 저장하는 모든 것에 대해, 재생성 가능해? 재생성 가능한 건 마음껏 소유하고; 아닌 것의 유일한 관리인이 되는 건 아주 의심해. (2) 참조된 게 사라지면, 네 시스템이 record 를 지워, 부재로 표시해? 지우기는 파생된 기억을 파일과 함께 버려 — 근데 그건 별개의 두 상실이고, 그중 하나만 네게 강요된 거야.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.