"원본의 정신에서 다시 만들어. 옛 데이터를 새 모양으로 리마스터하지 마."
선대가 있었어
Recall 이 첫 시도는 아냐. 그 전에, 레거시 메타데이터 DB 가 더 옛날 음성 model 로 같은 아카이브를 색인했어. Recall 은 그 구현을 대체해 — 근데 옛 프로젝트를 어떻게 다루느냐가 레슨 전체고, 대부분의 엔지니어가 그대로 걸어 들어가는 함정이야.
본능은 마이그레이션이야: 옛 DB 를 가져다, 제자리에서 변형하고, 새 스키마로 바꾸고, 끝. 효율적으로 느껴져. 함정이야. 옛 데이터는 더 약한 파이프라인이 만든 거라 그 파이프라인의 결함 — 침묵 hallucination, 상투구, 한국어/영어 혼동 — 을 품고 있어. 제자리에서 마이그레이션하면 깨끗한 새 시스템이 안 나와. 새 옷 입은 옛 rot 이 나오고, 이제 어느 행이 믿을 만한지도 못 가려.
리마스터 vs 리메이크
게임 업계의 구분을 빌리면:
- 리마스터 — 옛 콘텐츠를 유지하고 텍스처만 개선. 같은 에셋을 업스케일. 이게 마이그레이션 사고방식이야: 옛 데이터는 남고, 광만 내.
- 리메이크 — 현재 ground truth 로, 원본의 정신에서 다시 지어. 새 엔진, 새 증거, 더 나은 스키마, 한 번에.
Recall 은 리메이크야. 현재 ground truth 는 더 나은 ASR model, two-host 아키텍처, 그리고 evidence-first 데이터 모델이야. 그래서 transcript 를 옛것에서 업스케일하는 게 아니라 그 ground truth 에서 다시 파생해. 오염된 corpus 를 깨끗한 걸로 리마스터할 순 없어 — 오염이 광내기를 살아남거든.
레거시는 두 가지가 되고, 둘 다 '진실'은 아냐
그럼 옛 프로젝트는 어떻게 돼? 조심스럽게 경계 지어진 두 가지가 돼:
- parity oracle. 레거시 repo 는 얼려서, 손 안 대고, 딱 한 질문에만 써: "새 시스템이 옛것의 모든 기능을 유지했나?" 완결성의 기준점이지 데이터 소스가 아냐. 돌지 않아 — 정답지야.
- 일회성, 읽기 전용 import. 옛 Markdown transcript 는 명확히 라벨된 레거시 증거로 딱 한 번 import 해 — 자기만의 종류로, 격리해서 — 아무것도 안 잃게. 근데 검색은 그 Markdown 이 아니라 새로 구조화된 타임스탬프 segment 위에서 돌아. Markdown 은 사람이 읽는 export 지, live 데이터 모델이 아냐.
그게 규율이야: 옛것은 참조이자 격리된 import 지만, 현재 ground truth 가 새 시스템의 소스야. 옛 데이터를 진실로 만드는 순간, rot 을 리마스터한 거야. 대신 리메이크해.