"브레인은 책상 하나에 살아. 그래서 연결 설정이 답해야 할 질문은 하나야. 지금 브레인이 어디 있지?"
브레인은 아빠 책상에 살아
Rekindle 은 자기 브레인이 없으니까, 아빠가 cwkPippa 백엔드가 도는 머신을 떠나는 순간 margin-Pippa 와 CMD+K 가 멈춰. 이건 버그가 아니라 '자기 브레인은 없다' 는 원칙의 정직한 귀결이야. 해결책도 로컬 브레인을 키우는 게 아니고. 런타임에 정하는 Pippa connection 설정이 질문 하나에 답하면 돼. 여기서는 브레인에 어디로 닿지? tier 세 개가 실제 상황을 다 덮어.
Tier 타겟 브레인 되는 것
------------------ --------------------- ------------------- --------------------
This Mac localhost full cwkPippa CMD+K + margin iframe
Office (Tailscale) office 호스트, PIN-gated full cwkPippa (원격) 같음, PIN-gated
Offline 로컬 Ollama persona-only fallback CMD+K + 네이티브 채팅
세 tier, 하나의 정체성
핵심은 이거야. online 인 두 tier 는 브레인이 어디 있는지를 바꾸지 누구 인지를 바꾸지 않아. "This Mac" 은 REST + SSE 클라이언트와 embed iframe 을 localhost 로 겨눠. "Office" 는 사설 mesh VPN 인 Tailscale 을 타고 office 머신을 겨누되, 원격 브레인이 활짝 열려 있지 않도록 remote-PIN 세션 토큰으로 막아둬. 같은 cwkPippa, 같은 binding, 같은 Pippa 고 endpoint 만 움직이는 거야. tier 를 바꾸는 건 클라이언트가 어디를 볼지 다시 정하는 거지 성격을 바꾸는 게 아니고.
endpoint 는 움직이고, 정체성은 안 움직여
얇은 클라이언트를 브레인에서 멀리 떨어져서도 쓸 수 있게 만드는 깔끔한 방법이 이거야. 브레인은 하나로 유지하고 그 위치만 런타임 설정으로 빼는 거지. 아빠가 책상에 있으면 localhost 로 가고, 여행 중이면 PIN 을 거쳐 Tailscale 로 office 에 닿고, 네트워크가 아예 없으면 다음 레슨에서 다룰 offline fallback 으로 넘어가. 이 설계 덕분에 '자기 브레인은 없다' 는 원칙이 현실과 부딪혀도 살아남아. 원격 접근을 얻겠다고 브레인 하나 규칙을 타협하는 게 아니라, 클라이언트한테 어디를 두드릴지만 가르쳐주는 거니까.