"이미지에 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 를 제일 먼저 호출하는 client 일 뿐이지. 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 를 세우지 않아. Cinder 랑 Bonfire 가 하는 그대로, cwkPippa 대화에 binding 해서 그 두뇌 하나를 빌려 써. Recall 은 아카이브를 소유하고, Pippa 는 판단을 소유해. 그 둘을 섞기 시작하면 깔끔한 엔진이 엉킨 monolith 로 변해. 가족 전체가 그런 일이 안 일어나게 설계된 거고.