폴더 가득한 파일 말고, 영상 기억 엔진을 만들어
Recall 의 탄생 이야기 — 이미지 엔진 Ember, 음악 엔진 Bonfire 의 형제인 아빠의 영상 기억 엔진이야. NAS 에 영상 수천 개, 그리고 질문 하나. "내가 그 얘기 어디서 했더라?" 이 퀘스트는 그 질문에 답하는 엔진을 걸어. 그리고 모든 설계 결정이 같은 걸 가르쳐 — 증거를 어떻게 지키고, 돈을 어떻게 딱 한 번만 쓰고, 기억하는 방식을 어떻게 소유하는지.
8 tracks · 35 lessons · ~6h · difficulty: intermediate-to-advanced
Recall 이 뭔지, 가족 안에서 어디 앉는지, 왜 존재하는지
아키텍처 이전에 방향부터. Recall 은 영상 기억 엔진이야 — 전사 도구도 아니고, 폴더에 붙인 검색창도 아니고, 인생을 통째로 올리는 클라우드도 아냐. 이 트랙은 Recall 이 푸는 기억 문제를 잡고, cwkPippa 엔진 가족 안에 아카이브 형제로 앉히고, 자기가 만든 도구한테 다들 처음 던지는 질문 — 그냥 빌리면 되잖아? — 에 답하고, 옛 프로젝트를 '다시 만든다'는 것과 '리마스터한다'는 것 사이의 날카로운 선을 그어.
control plane, stateless executor, 그리고 둘을 묶는 규칙
Recall 은 항상 켜진 기계 두 대랑 개발 노트북 하나에 걸쳐 돌고, 그 분리는 의도적이야. 한 호스트는 control plane 이자 단일 진실의 원천이고, 다른 하나는 무겁고 느리고 비싼 일을 하면서 아무것도 소유 안 하는 stateless executor 야. 이 트랙은 분산 시스템의 척추를 가르쳐 — 왜 결정하는 plane 과 실행하는 plane 을 분리하는지, 둘을 정직하게 유지하는 한 규칙 — control plane 이 durably 받아들이기 전엔 계산이 안 끝난다 — 왜 웹 요청이 절대 몇 시간짜리 일을 소유하면 안 되는지, 그리고 왜 코드랑 상태가 다른 레일로 다니는지.
raw 출력은 영구 기록; 진실은 그 위에 얹힌 버전
Recall 데이터 모델의 심장이자, 가장 옮겨 쓰기 좋은 아이디어: 기계가 돌려준 걸 진실과 절대 혼동하지 마. raw 음성-텍스트 출력은 불변 증거야 — 특정 model 이 특정 바이트에 대해 정확히 뭐라고 했는지의 영구 기록. 유저가 보는 transcript 는 그 증거에서 파생된 버전 있는 release 고, 원본을 절대 변형하지 않고 교정할 수 있어. 이 트랙은 run 과 release 를 분리하고, 왜 교정이 덮어쓰지 않고 분기하는지, content hash 가 어떻게 모든 하류 산물의 staleness 를 감지 가능하게 하는지, 그리고 왜 자동 품질 점수가 증명이 아니라 조언인지 보여줘.
쓰기 전에 예약하고, identity 당 한 번 쓰고, 청구됐을지 모르는 호출은 절대 자동 재시도 안 함
전사 호출은 다 진짜 돈이 들고, 불안정한 네트워크 위 순진한 재시도 loop 은 같은 오디오를 조용히 다섯 번 결제할 수 있어. 이 트랙은 그걸 막는 돈 규율이야: 어떤 유료 호출 전에도 요청이 건너야 하는 예약 ledger, 같은 오디오를 최대 한 번만 사는 content-addressed identity, provider 가 청구했을지 모르는데 결과가 없는 무서운 경우를 위한 명시적 'ambiguous' 상태, 그리고 이미 청구됐을지 모르는 호출을 자동 재시도하지 않겠다는 의도적 거부. 마지막은 outbox — executor 가 이미 쥔 유료 응답을 어떻게 보호하는지.
단일 플래그 없음, identity 사다리, 그리고 --force 가 진짜 뭘 뜻하는지
단일 'done' boolean 은 데이터 파이프라인에서 가장 흔한 거짓말이야: 뭐 기준으로 done? 같은 source? 같은 설정? 같은 출력? Recall 은 플래그 하나를 절대 안 믿어. identity 를 계층화해서 바뀐 source, 바뀐 오디오 설정, 바뀐 provider 설정, 바뀐 release 가 각각 구별되게 해 — 모든 단이 특정 혼동 하나를 막는 hash 사다리. 이 트랙은 그 사다리를 바닥부터 지어: 왜 한 플래그가 실패하는지, video identity 가 관찰된-바이트 fingerprint 와 어떻게 다른지, 전체 10계층 방식, 그리고 왜 --force 조차 blind 유료 재실행을 승인 안 하는지.
몇 시간짜리 job 이 크래시를 어떻게 살아남나, 그리고 그 설계를 빚은 OS 함정들
영상 수천 개를 전사한다는 건, 언제든 크래시하거나 hang 걸리거나 재시작될 수 있는 executor 에서 몇 시간 도는 job 을 뜻해. 이 트랙은 그 작업이 생존 가능하게 남는 법이야: 한 번에 정확히 한 worker 가 job 을 소유하게 하는 token 과 heartbeat 있는 lease, lease 만료 시 atomic reclaim, 그리고 응답 없는 네트워크 파일시스템이 파이프라인 전체를 얼릴 수 없게 하는 죽일 수 있는 자식 프로세스. 어렵게 얻은 운영체제 전쟁 이야기 둘로 닫아 — 동기화 경로에서 hang 걸리는 백그라운드 프로세스, 그리고 잘못된 identity 에 파일 접근을 거부하는 권한 모델 — 가장 깔끔한 설계도 자기가 도는 기계를 살아남아야 하니까.
'끝났다' 와 '지식이 될 만큼 좋다' 사이의 벽
파이프라인이 끝났고, 품질 체크가 초록이고, transcript 가 검색 가능해. 이제 지식 시스템에 먹일 만큼 믿을 만해? Recall 의 답은 기본값 단호한 아니오고, 이 트랙이 그 이유야. 격리를 지어 — excluded 로 시작해 명시적 사람 전이로만 나아갈 수 있는 corpus eligibility — 그리고 '순간을 찾는 데 쓸 만함' 과 '지식의 소스로 안전함' 이 왜 진짜 다른 두 판단인지 보여줘. 그다음 제품으로 돌아: 왜 검색이 mutable export 가 아니라 구조화된 타임스탬프 segment 를 색인하는지, 그리고 검색 hit 이 브라우저가 파일을 지목하게 하는 일 없이 어떻게 편집 행위가 되는지.
index 는 파생물, 바이너리는 제자리, 두뇌는 딴 데 살아
마지막 규율. 경계 셋이 엔진 전체를 붙들어: index 는 파생물이라 patch 가 아니라 재구축돼야 하고; 원본 영상 바이트는 사는 데 남고 Recall 은 사본이 아니라 참조를 저장하고; 엔진은 자기 아카이브 도메인을 소유하되 판단은 빌린 두뇌에 남아. 각각이 거부야 — patch 거부, 쌓아두기 거부, 두 번째 identity 키우기 거부 — 그리고 함께 그게 오래가는 엔진을 만들어. 마지막 레슨은 퀘스트 전체를 바깥으로 돌려: 네가 Recall 을 돌리라고가 아니라, Recall 이 짓는 법을 가르쳐준 걸 짓게.
아직 댓글이 없어요. 첫 댓글을 남겨보세요.