프로세스 하나가 전부 소유

"프로세스 하나가 앱을 서빙하고, 스케줄을 돌리고, 쓰기를 소유하고, 백업을 rotate 해. 소유자가 하나면, 누가 뭘 했는지 물을 일이 없어."

한 지붕 아래 전부

Keep 은 단일 launchd agent 로 돌아. 그 프로세스 하나가 전부 해: API 서빙, 빌드된 PWA 서빙(같은 프로세스가 웹 앱을 나눠주고 그 호출에 답해), 06:31 일일 loop 돌리기, SQLite writer 소유, 백업 rotate. 별개 웹 서버도, 별개 스케줄러도, 별개 백업 daemon 도 없어. 프로세스 하나, 모든 움직이는 부품의 소유자 하나. 가족 하나 local-first 앱엔 이게 제한이 아냐 — 시스템 전체를 추론 가능하게 만드는 의도적 단순함이야.

왜 프로세스 하나가 딱 맞는 양인가

클라우드 아키텍처가 훈련시킨 본능은 쪼개기야: 웹 tier, worker tier, cron 서비스, 백업 job, 각자 독립 스케일. 규모에선 맞고 Mac 하나의 가족 하나엔 엄청난 over-build 야. 더하는 모든 split 이 새 조율 문제야: 스케줄러와 웹 서버가 상태를 어떻게 합의해, DB 를 하나만 쓰게 어떻게 확보해, 백업 daemon 과 일일 loop 가 동시에 돌면 뭐가 돼. Keep 은 그 질문을 애초에 안 만들어 전부 녹여. 프로세스 하나는 writer 를 누가 소유하는지 자기랑 의견 갈릴 수 없어, 그게 바로 writer 니까.

더하는 모든 프로세스 경계가 이제 네가 소유하는 조율 문제야. 서비스로 쪼개는 건 독립 스케일을 사고 분산 시스템 복잡성 — consensus, ordering, 부분 실패 — 을 지불해. 스케일이 필요한 규모 아래에선 아무것도 아닌 걸 위해 비용을 내는 거야. 프로세스 수를 실제 운영 필요에 맞춰, 그럼 소유자 하나가 종종 정확히 옳아.

프로세스 하나가 실체화하는 single writer

snapshot 트랙의 single-writer DB 보장 기억나? 여기가 그게 물리적으로 참이 되는 곳이야. SQLite writer 가 정확히 하나인 이유는 프로세스가 정확히 하나고, 그 프로세스가 writer 니까. lock 과 서비스 간 조율로 single-writer 를 강제할 필요가 없어, 아키텍처가 여러 writer 를 불가능하게 만드니까 — 쓸 수 있는 프로세스가 하나뿐이야. 깔끔한 데이터 레이어 invariant 과 깔끔한 프로세스 모델은 두 각도에서 본 같은 사실이야.

launchd 가 살려두기를 소유해. 프로세스 밖의 유일한 건 supervisor 야: launchd 가 agent 를 돌리고, 죽으면 재시작하고, 부팅 때 시작해. 그게 옳은 분업 — OS 레벨 supervisor 가 프로세스 존재를 보장하고, 프로세스가 그 안 전부를 보장해. 자기 babysitter 를 안 지어; 플랫폼의 supervisor 가 그게 만들어진 그 한 일을 하게 둬.

Code

프로세스 하나, 모든 책임 (예시)·text

com.cwk.keep-serve  (launchd agent 하나)
  ├─ API 서빙                (HTTP endpoint)
  ├─ 빌드된 PWA 서빙          (웹 앱 자체)
  ├─ 06:31 일일 loop 돌림     (in-process 스케줄러)
  ├─ SQLite writer 소유        (유일한 writer)
  └─ 백업 rotate               (crash-safe 스냅샷)

# 두 번째 웹 서버 없음. 두 번째 스케줄러 없음. 백업 daemon 없음.
# '누가 writer 를 소유해?' 는 프로세스가 하나라 답이 하나.
# launchd 의 유일한 일: 이 단일 프로세스를 살려두고 재시작.

Exercise

네가 지었거나 상상한 작은 앱을 잡고 프로세스를 세어: 웹 서버, worker, 스케줄러, 백업 job. 각 split 에 대해 물어 '이게 진짜 독립 스케일이 필요해, 아니면 습관으로 쪼갰어?' 그다음 단일 프로세스 버전을 설계하고 그냥 사라지는 조율 문제를 나열해. 마지막으로 진짜로 프로세스 밖에 속하는 하나를 짚어(힌트: 살려두기).

Hint

대부분 작은 앱의 프로세스 split 은 클라우드 다이어그램에서 cargo-cult 된 거야. 접으면 진짜 복잡성이 사라져: 프로세스 간 상태 sync 없음, '누가 DB 써' 질문 없음, cron 과 앱의 race 없음. 밖에 남아야 할 하나는 supervisor 야 — OS 가 네 프로세스를 재시작하길 원하지, 네 프로세스가 자기를 재시작하는 게 아니라.

프로세스 하나가 전부 소유

한 지붕 아래 전부

왜 프로세스 하나가 딱 맞는 양인가

프로세스 하나가 실체화하는 single writer

Code

External links

Exercise

Progress

댓글 0