"다 텍스트를 검색해. 그게 그것들에 대해 믿을 수 있는 가장 비싼 한 문장이야."
다 "텍스트를 검색하는" 셋
이 빌드가 끝날 무렵, 같은 가족에 별도 검색 표면 셋이 존재했고, 모든 본능이 합치라고 비명을 질렀어:
- 뇌의 자기 메모리 — 개인 vault 와 대화 기록 위의 임베딩, 비서의 system prompt 에 맞는 맥락을 싣고 과거 교환을 recall 하는 데 쓰여.
- 라이브 co-writing 경로 — 지금 이 순간 작업 중인 노트 위의 임베딩, 쓰는 동안 모델 완성을 먹여.
- 코퍼스 엔진 — 10년 치 완성된, 역사적 글 위의 결정론적이고 인용 가능한 검색.
셋 다 쿼리를 받아 관련 텍스트를 돌려줘. 분명 하나가 세 일을 다 할 수 있지 않아?
다른 크기가 아니라 다른 모양이야
인터페이스 너머를 보면 차이가 구조적이야. 메모리와 co-writing 경로는 판단 모양이야: 설계상 모델이 루프에 있고, 대화나 활성 문서에 범위가 잡히고, 목적 전체가 언어 모델을 먹이는 거야. 코퍼스 엔진은 엔진 모양이야: 경로에 모델 없고, 영구 아카이브에 범위가 잡히고, 목적은 어떤 대화보다 오래 사는 인용 가능한 결과야. 다른 수명, 다른 범위, 모델이 안에 속하냐에 정반대 입장. 합치는 건 통합이 아냐 — 하나한테 다른 것의 제약을 입히는 거야.
합치면 실제로 뭘 치르나
구체적으로 추적해. 코퍼스 엔진을 메모리 시스템에 접으면 엔진이 대화 범위와 모델 의존성을 상속해 — 뇌가 꺼져도 되는 검색과는 안녕. co-writing 경로를 코퍼스 엔진에 접으면 아직 쓰는 중인 문장을 자동완성하려고 라이브 노트가 영구히 수집되고 content-addressed 돼야 해. 각 병합이 자기 일엔 옳던 표면을 이웃의 가정에 맞추려고 부숴. 유사성은 늘 표면적이었고, 제약은 애초에 호환된 적이 없어.
경계는 의도적으로 적혀 있어
이 본능이 재발하니까 — 누군가 항상 "검색 전부 통합하면 안 돼?" 를 제안할 테니까 — 경계는 누구 머릿속이 아니라 아키텍처 문서의 표에 살아. 어느 표면이 어느 코퍼스를 소유하고, 어느 일을 하고, 어느 제약을 갖는지. 그 표는 다음에 통합 아이디어를 떠올릴 사람이 한 달 쓰기 전에 왜 거절됐는지 읽으라고 정확히 존재해. 왜 안 합쳤는지 적어두는 게, 뭘 지었는지 문서화하는 것만큼 값져.