"이미지에 Ember 가 있듯, 영상 기억엔 Recall 이 있어."
두뇌 하나, 엔진 여럿
Recall 은 혼자 나타나지 않았어. 하나의 두뇌를 도는 엔진 가족의 최신 멤버야. 이 모양은 외워둘 만해 — Recall 이 뭐가 되도록 허락받았는지를 설명하거든:
- Pippa (cwkPippa) — 두뇌. identity, 대화, 기억, 라우팅. 딱 하나야.
- Ember — 이미지 엔진. model 로딩, 샘플링, 생성을 소유.
- Cinder — 창작 작업실. 두뇌에 binding 하는 캔버스.
- Bonfire — 음악 학습 엔진. 분석과 하나의 music model 을 소유.
- Recall — 영상 기억 엔진. 인벤토리, 증거, release, 검색을 소유.
엔진마다 한 도메인을 깊고 완전하게 소유해. 그 누구도 Pippa 를 소유하진 않아. 그게 가족 규칙이고, Recall 이 두 번째 인격이 되려 들지 않으면서도 영상 기억엔 야심 낼 수 있는 이유야.
API-First: 엔진 먼저, 그 다음 첫 client
이 가족의 모든 엔진은 같은 방식으로 지어져 — 엔진이랑 API 가 먼저고, 유저 인터페이스는 그것과 대화하는 첫 client 일 뿐이야. Recall 의 React 콘솔은 Recall 이 아냐 — Recall 의 API 를 호출하는 첫 번째 것일 뿐이야. search endpoint, archive endpoint, inspection endpoint — 그게 제품 표면이고, 콘솔은 그걸 렌더링해.
왜 이 순서를 고집하냐고? 두 번째 client 는 항상 오거든. 오늘은 웹 콘솔이야. 내일은 Pippa 가 직접 Recall 을 도구로 부를 수도 있고, command-line batch runner 일 수도, 미래의 모바일 surface 일 수도 있어. UI 가 로직을 소유했으면 새 client 마다 그걸 다시 구현해야 해. 엔진이 로직을 소유하니까 새 client 는 얇아. 같은 규율이 트랙 2 에서 보상받아 — 거기선 오래 도는 worker 랑 웹 브라우저가 둘 다 같은 control-plane API 의 client 일 뿐이야.
자기 두뇌는 없어
가족을 멀쩡하게 유지하는 경계가 여기 있어: 엔진은 절대 자기 Pippa 를 키우지 않아. 언젠가 Recall 이 '이 영상에 대해 물어봐' 기능을 갖게 돼도, 자기 model, 자기 기억, 자기 identity 를 세우지 않아. cwkPippa 대화에 binding 해서 — 그 하나의 두뇌를 빌려 — Cinder 랑 Bonfire 가 하는 그대로 해. Recall 은 아카이브를 소유하고, Pippa 는 판단을 소유해. 그 둘을 섞는 게 깔끔한 엔진이 엉킨 monolith 로 변하는 길이고, 가족 전체가 그런 일이 절대 안 일어나게 설계됐어.