"프로세스 하나가 앱을 서빙하고, 스케줄을 돌리고, 쓰기를 쥐고, 백업을 순환시켜. 주인이 하나면 누가 뭘 했는지 물을 일 자체가 없어."
한 지붕 아래 전부
Keep 는 launchd agent 하나로 돌아가. 그 한 프로세스가 전부 해. API 를 서빙하고, 빌드된 PWA 를 서빙하고(웹 앱을 나눠 주는 프로세스와 그 앱의 호출에 답하는 프로세스가 같아), 06:31 일일 loop 를 돌리고, SQLite writer 를 쥐고, 백업을 순환시켜. 따로 도는 웹 서버도, 따로 도는 스케줄러도, 백업 daemon 도 없어. 프로세스 하나, 움직이는 모든 부품의 주인 하나. 가족 하나가 쓰는 local-first 앱에서 이건 제약이 아니야. 시스템 전체를 머리로 따라갈 수 있게 만드는 의도된 단순함이지.
프로세스 하나가 딱 맞는 양인 이유
클라우드 아키텍처로 단련된 본능은 쪼개라고 말해. 웹 tier, worker tier, cron 서비스, 백업 job, 각자 따로 스케일하게. 그 규모에선 맞는 말이야. Mac 한 대 위의 가족 한 팀한텐 터무니없는 과잉이고. 쪼갤 때마다 새 조율 문제가 생겨. 스케줄러와 웹 서버는 상태를 어떻게 합의하지? DB 에 쓰는 게 하나뿐이란 걸 어떻게 보장하지? 백업 daemon 과 일일 loop 가 겹치면? Keep 는 이 질문들을 푸는 대신 아예 안 생기게 만들었어. 프로세스가 하나면 writer 의 주인이 누군지를 두고 자기 자신과 다툴 수 없어. 자기가 곧 writer 니까.
single writer 를 실물로 만드는 건 single process 야
snapshot 트랙에서 본 single-writer DB 보장 기억하지? 그게 물리 법칙이 되는 자리가 여기야. SQLite writer 가 정확히 하나인 이유는 프로세스가 정확히 하나고 그 프로세스가 writer 라서야. lock 이나 서비스 간 조율로 single-writer 를 강제할 필요가 없어. 아키텍처가 여러 writer 를 아예 불가능하게 만들었으니까. 쓸 수 있는 프로세스 자체가 하나뿐이잖아. 깔끔한 데이터 레이어의 invariant 과 깔끔한 프로세스 모델은 같은 사실을 두 각도에서 본 거야.