엔진을 다스리는 다이얼들
Monitor가 자동으로 하는 모든 것은 코드가 아니라 Settings에 사는 값들에게 다스려져: 저장소 뿌리와 그 실시간 용량, 최대 전송 속도, 일일 예산과 재설정 경계, 그 두 숫자를 끝나는 날짜로 바꾸는 계획 계산기. 아래 스크린샷이 그 표면의 모양을 보여 줘. 레슨은 그 모양이 왜 그런지에 관한 거야.
아키텍처 주장: 속도와 예산은 정책이고, 정책은 구성에 속한다. 정책은 코드가 신경 써선 안 되는 이유로 바뀌어 — 새 디스크가 NAS에 합류하고, 가정의 저녁 네트워크 현실이 바뀌고, 캠페인이 계절적 인내를 필요로 하고, 지난달 산수의 실수가 정정돼. 그 변화들이 코드 수정을 요구하면, 늦거나 절대 일어나지 않아. 메커니즘은 현실과 더 이상 맞지 않는 정책을 섬기게 돼. 구성은 엔진을 안정적으로 유지하면서 그 지배가 숨 쉬게 해.
분리가 사 주는 것
메커니즘(전송 엔진, 엔지니어링이 바뀔 때 바뀌어)과 정책(뿌리, 속도, 예산, 삶이 바뀔 때 바뀌어)의 분리는 세 실용적 보수를 가져와. 변화가 싸고 되돌릴 수 있어 — 다이얼을 조정하고, 전송 하나 지켜보고, 결정해. 실수가 보여 — 잘못된 예산은 누군가 읽을 수 있는 설정으로 나타나지, 역설계해야 하는 동작으로가 아니야. 그리고 아카이브의 운용 자세가 감사 가능해 — 다이얼들을 함께 읽으면 그게 곧 현재 정책이거든: 얼마나 빨리, 하루에 얼마나, 어느 뿌리로. 네 훈련의 스크린샷을 찍을 수 있는 거지.
이 퀘스트가 손으로 가르쳐 준 모든 것에 같은 분리가 있음을 봐: 이어받기 의례는 메커니즘이고, 네가 고른 속도 상한과 예산은 정책이야. NOTES 파일들이 네 구성을 갖고 있지. 상황이 바뀌면 노트를 고쳐 — 스크립트가 구현하는 물리 법칙이 아니라.
구성에도 규칙은 있다
이게 설정이 만능 해결책이라는 뜻은 아니야. 좋은 구성도 여전히 기록돼(누가 어느 다이얼을 언제 왜 바꿨는지 — 결정 기록은 다이얼에도 적용돼), 여전히 제약돼("링크가 가진 전부"라는 속도 상한은 중단 문제를 재현하는 정책이야), 여전히 검토돼(주기적 질문: 이 숫자들이 아직 가정의 현실과 맞아?). 다이얼은 정책을 싸게 만들어 주지, 신중함까지 대신해 주진 않아.