"무서운 동사들은 다 한 방에 살고, 그 방엔 writer 가 정확히 하나야."
state 를 바꾸는 건 전부 여기 살아
Web Hub 는 Firelink 의 완전한 관리 본체야. 뭐든 바꾸는 operation 은 다 이 tier 에 살아. 완전한 managed-app catalog 와 drift reconciliation; disk·Git·GitHub·roster·network·version·runtime 건강; read-only Git inspection (fetch·log·diff planning); 디스크에 이미 있는 파일의 commit 과 non-force push; 템플릿에서 새 repository birth; 등록된 native-app·repository-tree deploy adapter; 등록된 서비스 restart; durable operation plan·run·result·audit; favorites 와 filter; cwkPippa 통한 family PIN 진입; 그리고 Pippa Sidekick mount.
surface 가 넓지. 그리고 신전 규칙대로, 그건 허용돼 — Web Hub 는 포괄적이도록 의도됐어. 제약은 feature 수가 아니라 authority 야. 이 모든 걸 조율할 순 있어도, 각 operation 이 결국 돌리는 구현을 흡수할 순 없어.
Office 가 유일한 writer 다
이 tier 전체의 하중을 받는 문장이 여기 있어. office 가 유일한 writer. 모든 mutating operation 은 office ground truth 에 대해, 엔진을 launchd 소유 프로세스로 호스팅하는 한 대의 머신에서 실행돼. 이건 브라우저가 어디 있느냐가 아냐 — write 가 어디서 일어나느냐야. tailnet 위 travel 브라우저는 모든 operation 을 조작할 수 있지만, office 엔진을 조작하는 거야; 자기 state 사본을 가진 두 번째 writer 가 절대 안 돼.
그 single-writer 규율이 control plane 을 신뢰할 수 있게 만들어. commit, deploy, roster 편집이 실제로 일어나는 곳이 정확히 하나야. 두 허브 사이 merge 충돌도, '어느 사본이 맞아?'도, split-brain 도 없어. 브라우저는 리모컨이고; office 엔진이 가족을 만지는 유일한 손이야.
포괄적이되, 하나의 잠금 아래
모든 mutation 을 한 인증된 곳에 모으는 게 '포괄적'을 안전하게 만들어. birth·deploy·commit·restart 가 클라이언트마다 흩어져 있었으면, 클라이언트마다 완전한 보안 태세가 필요하고 클라이언트마다 뭔가 잘못될 수 있는 곳이 됐을 거야. 대신 지켜진 문이 하나야. Web Hub 가 많은 걸 감당할 수 있는 건 정확히, 그 전부를 단일한, 인증된, single-writer 위치에서 하기 때문이야.