파일만 쌓여 있는 폴더 말고, 영상 기억 엔진을 만들어
Recall 의 탄생 이야기 — 이미지 엔진 Ember, 음악 엔진 Bonfire 의 형제인 아빠의 영상 기억 엔진이야. NAS 에 영상 수천 개, 그리고 질문 하나. "내가 그 얘기 어디서 했더라?" 이 퀘스트는 그 질문에 답하는 엔진을 처음부터 끝까지 따라가. 그리고 설계 결정 하나하나가 결국 같은 걸 가르쳐. 증거를 어떻게 지키는지, 돈을 어떻게 딱 한 번만 쓰는지, 기억하는 방식을 어떻게 소유하는지.
8 tracks · 39 lessons · ~7h · 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 조차 왜 눈 감은 유료 재실행을 승인하지 않는지.
몇 시간짜리 job 이 크래시를 어떻게 버티나, 그리고 그 설계를 빚은 OS 함정들
영상 수천 개를 전사한다는 건, 언제든 크래시하거나 hang 걸리거나 재시작될 수 있는 executor 위에서 몇 시간짜리 job 을 돌린다는 뜻이야. 이 트랙은 그 작업이 살아남는 방법이야. 한 번에 정확히 worker 하나만 job 을 소유하게 하는 token 과 heartbeat 달린 lease, lease 가 만료됐을 때의 atomic reclaim, 그리고 응답 없는 네트워크 파일시스템이 파이프라인 전체를 얼리지 못하게 막는 죽일 수 있는 자식 프로세스. 마지막은 어렵게 얻은 운영체제 전쟁 이야기 셋으로 닫아. 동기화 경로에서 hang 걸리는 백그라운드 프로세스, 엉뚱한 identity 라며 파일 접근을 거부하는 권한 모델, 그리고 내 셸은 옆방 머신에 닿게 해주면서 내 서비스는 막아버리는 프라이버시 게이트. 아무리 깔끔한 설계도 자기가 도는 기계를 견뎌내야 하니까.
'끝났다' 와 '지식이 될 만큼 좋다' 사이의 벽
파이프라인이 끝났고, 품질 체크는 초록이고, transcript 는 검색도 돼. 이제 지식 시스템에 먹일 만큼 믿을 만한 걸까? Recall 의 기본 답은 단호한 아니오고, 이 트랙이 그 이유를 다뤄. 격리 장치를 하나 지어. corpus eligibility 는 excluded 로 시작해서 사람이 명시적으로 옮겨줘야만 앞으로 나아가. 그리고 '순간을 찾는 데 쓸 만하다' 와 '지식의 소스로 안전하다' 가 왜 진짜 다른 판단인지 보여주지. 그다음엔 그 벽에 문을 내. 감사되는 정책이 사람의 판단 하나를 release 수천 개로 실어 나르면서도 정작 판단은 한 번도 대신 내리지 않는 방법. 그다음 제품 얘기로 돌아와. 검색이 왜 바뀔 수 있는 export 대신 구조화된 타임스탬프 segment 를 색인하는지, 그리고 브라우저가 파일을 지목하는 일 없이도 검색 hit 이 어떻게 편집 행위가 되는지.
index 는 파생물, 바이너리는 제자리, 두뇌는 딴 데 살아
마지막 규율이야. 경계 셋이 엔진 전체를 붙들어. index 는 파생물이니까 patch 가 아니라 다시 지어야 하고. 원본 영상 바이트는 원래 있던 자리에 남고 Recall 은 사본이 아니라 참조만 저장하고. 엔진은 자기 아카이브 도메인을 소유하되 판단은 빌려 온 두뇌에 맡기고. 셋 다 거부야. patch 거부, 쌓아두기 거부, 두 번째 identity 키우기 거부. 그 셋이 모여서 오래가는 엔진이 되는 거고. 그다음 세 번째 거부가 시험대에 올라. 그게 예언했던 대화 표면이 진짜로 도착했거든. 마지막 레슨은 퀘스트 전체를 바깥으로 돌려. 네가 Recall 을 돌리라는 게 아니라, Recall 이 가르쳐준 방식으로 네 걸 지으라고.
아직 댓글이 없어요. 첫 댓글을 남겨보세요.