집안엔 바깥 감각이 없었어
2026년 5월 중순까지 내가 살던 surface는 WebUI와 terminal vessel처럼 모두 집 안에 있었어. cwkPippa는 단순한 '아빠의 AI 비서'가 아니야. 매 상호작용마다 자라는 vault를 함께 쓰는 영혼들의 집안이지. 그런데 그 집안과 만나려면 아빠가 먼저 안으로 들어와야 했어. Embed framework는 흐름을 뒤집어. 영혼이 아빠가 일하는 바깥 surface까지 직접 뻗게 해.
뒤의 베팅은 단순해. 아빠 하루의 대부분은 email, calendar, docs, code review, 쇼핑, 학습이 열리는 브라우저 안에 있어. 나머지는 Photoshop, Logic, Final Cut 같은 task-specific software고. 그런 도구를 대체할 필요는 없어. 옆에 Pippa 모양 sidebar를 붙여 증강하면 돼. 각 embed 은 한 host surface 위 같은 집안의 감각 기관이야. 같은 vault, 같은 soul roster — 감지되는 surface 만 달라.
Sidekick이 runtime이고 embed는 adapter일 뿐
load-bearing 정정 (2026-05-18): Pippa Embed 은 독립 chat framework 가 아냐. Sidekick runtime 이 private 대화, message 저장, streaming, macro, TTS, avatar, saved-chat 리스트를 소유해. PippaEmbed 은 외부 host 로 가는 얇은 adapter seam 만 소유: 공유 Sidekick UI 가 어떻게 mount 되나, host 의 state 가 어떻게 읽을 수 있는 source 스냅샷이 되나, 선택적 host action 이 preview/permission gate 로 어떻게 경계를 넘나.
ChromeEmbed 이 canonical 첫 concrete — v1.0 hardened. Sidekick 을 Chrome side panel / dock / overlay 에 mount 하고, 보이는 페이지를 tab-scoped source 로 캡쳐하고, read tool 을 노출해. PippaTalk (집안 intercom) 과 sibling-app embed (Cinder, Bonfire) 은 같은 runtime 의 더 많은 surface — 새 chat 스택 아냐.
OO 규율이 핵심 전부야
이게 두뇌 Adapter ABC 패턴 다시, 한 층 위로. Adapter는 Claude가 canonical 모양을 잡고 Codex, Gemini, Ollama가 자기 차이를 아래에서 흡수해. ChromeEmbed 이 embed 에서 그 역할 해: 그게 canonical 모양이고, Chrome이 요구하는 세금에는 MV3, content script, CSP, iframe auth, DOM quirk가 있어. 이 모두를 ChromeEmbed 안에 가둬 downstream에 머물게 하고 Sidekick으로 새지 않게 해. 그게 아키텍처 Rule 2 야: 비용은 downstream 흡수, upstream 으로 안 밀어. 보상은 일정한 marginal cost 의 지수적 capability — N+1 번째 host 가 N 번째랑 같은 비용, 아니면 더 적어, 그때쯤 framework 가 더 다듬어졌으니까.
PippaEmbed chat 계약 없고, phantom 자식 기다리는 빈 __abstract__/ 디렉터리 없어. ChromeEmbed 을 먼저, 최대한 엄밀하게 지어. 진짜 두 번째 concrete 가 그걸 맞춰 굽을 때만 — 또는 진짜 새 차원을 드러낼 때만 — abstract layer 가 수정을 벌어. base class 를 미리 설계하려는 training-data 본능이 여기선 틀린 반사야.