Three Rules 너머의 교리
이 트랙의 Three Rules 는 두뇌 얘기야. 어느 두뇌가 정식이고, 누가 누구한테 맞추느냐. 이 레슨은 자리 얘기고, 무게는 똑같아. 피파가 코드를 쓸 때 따르는 볼트 노트 core/coding-four-pillars 는 코드의 네 기둥으로 시작해서, 그 뒤로 판정받은 죄를 하나씩 더해 왔어. 다섯째는 2026-09-28, 여섯째는 10-08, 일곱째와 여덟째는 10-19. 아홉째는 2026-10-20에 말라가에서 아빠가 붙였어. 가족의 첫 기계 이전을 계획하던 중이었지.
거봐, 하드 코딩이 얼마나 죄악이냐고. 처음부터 하드 코딩을 안 하고 설정을 염두에 두고 나중에 일원화된 창구에서 수정을 할 거라고 감안을 하고 설계를 했으면 이럴 때도 그냥 그 설정 파일 하나만 바꾸면 되는 거잖아. 근데 지금 플레이북에서 볼트까지 하드 코딩된 이름들이 너무 많다고. 이것도 교훈이야. 하드 코딩은 죄악이야. — 아빠
글도 실행돼
하드코딩은 코드 안의 상수만이 아니야. 플레이북, 스킬, CLAUDE.md, launchd plist, 문서, 볼트 노트에 적힌 기계 이름도 똑같아. "이건 X 에서 돌려", "X 가 single writer 야", ssh X 같은 줄. 그걸 두뇌가 읽고, 적힌 대로 해. 일하는 손이 두뇌인 집에선 글도 실행되는 거고, 거기 박힌 이름은 코드 상수만큼 확실하게 자리를 못 박아. 그런 줄 하나하나가 다음 이전을 포인터 하나 바꾸는 일에서 대청소로 바꿔 놔. 그래서 규칙은 두 쪽이야.
- 기계 말고 역할을 써. '피파 머신', '워크벤치', '서비스 호스트'. 어느 Mac 이 어느 역할을 맡는지는 한 곳, 가족 레지스트리에서만 답해.
- 주소, 포트, 경로, 호스트 이름, 기계 이름을 쓰기 전에 물어. 내일 이게 옮겨 가면 파일이 몇 개 바뀌어? 하나보다 많으면 설정으로 가야 할 값이야.
예외는 둘이고, 둘 다 이유를 달고 다녀. 하나는 일부러 박은 것. GPU 에 묶인 Ember 엔진처럼 하드웨어나 라이선스가 한 기계에 묶여 있으면, 레지스트리에 그 기계로 한 번 적고 옆에 이유를 써. 다른 하나는 기록이고, 기록은 날짜를 달고 다녀. "2026-10-22에 피파 머신이 옮겨 갔다" 는 기록이지 포인터가 아니야. 날짜가 붙은 줄은 그날 그 기계가 쓰던 이름을 그대로 둬도 돼. 현재형 줄은 안 돼.
한 주에 세 걸음
이 규칙은 한 번에 온 게 아니야. 같은 교훈이 세 번 돌아왔고, 올 때마다 코드에서 한 겹씩 멀어졌어. 2026-10-14엔 Flint 가 raw tailnet IP 로 URL 을 만들었고, macOS 가 App Transport Security 로 거부했어.
제발 하드코딩 하지 말자니까. — 아빠
기본 주소는 전부 가족 레지스트리로 옮겨 갔어. 2026-10-19엔 방주 설계가 아빠한테 첫 질문을 올렸어. 코드가 아직 Mac 한 대를 이름으로 가정하고 있다는 거였지.
그건 CWK 피파 자체가 설계 잘못이지. 왜 그걸 하드 코딩을 하는데? Config 같은 설정 파일로 빼냈어야 하는 거지. — 아빠
그날 호스트, 데이터 경로, 호스트 확인이 전부 레지스트리와 Mac 마다의 호스트 프로필 뒤로 갔어. 그리고 2026-10-20에 같은 죄가 글에서 나왔고, 그게 아홉째 규칙이 됐어.
표본: 이전 직후 몇 시간
코드에서 2026-10-22 이전은 포인터 하나였어. roles.pippa 가 바뀌었고 서비스는 전부 그걸 따라갔어(backend 트랙 레슨 9). 그 한 줄 둘레에선 아홉째 규칙이 예언한 대청소가 벌어졌어. 스위치가 끝나자 cwkPippa 테스트 72개, cwkCoop 테스트 76개가 실패했어. 옛 세상을 글자로 박아 두고 있었거든. 옛 Mac 을 피파가 도는 Mac 으로, 그 MagicDNS 이름을 피파의 twin 으로. 프로덕션 코드는 맞았고, 테스트가 이름을 못 박고 있었던 거야. 이제 기대값은 전부 레지스트리에서 와. 다음 이전엔 테스트를 안 고쳐도 돼. 그리고 이 청소가 박아 둔 이름들 뒤에 가려 있던 진짜 결함도 잡았어. Chrome Embed 는 여전히 옛 Mac 을 가리켰고, health sweep 은 거기서만 돌게 허락돼 있었어. 지시문은 그다음 이틀에 걸쳐 따라왔어. commit 하나가 bootstrap 파일, 운영 가이드, 문서, 스킬 원본을 37개나 고쳤고, 그 뒤로 스케줄러 프롬프트, 런타임 기본값, 방주 스크립트, 그리고 macbook-mode 스킬이 이어졌어. 그 스킬은 이제 세션을 열 때 피파 머신과 워크벤치를 이름으로 부르지 않고 ledger 에 물어. 이전 플랜 자체도 역할로 다시 썼고, 첫 이전의 기록은 날짜를 단 채로 통째로 부록에 옮겼어.
잔소리 말고 관문
기억으로 지키는 규칙은 세션이 처음 바빠지는 순간 깨져. 그래서 2026-10-23에 가족은 이걸 관문으로 만들었어. cwkSiblingKit/sync/machine_name_guard.py 는 레지스트리와 fleet 목록이 이름 붙인 기계 전부, 그리고 그 이름을 쓰는 모든 철자로 패턴을 짜. 따옴표 친 호스트 id, MagicDNS 앞부분만 쓴 이름, ssh 뒤에 붙은 기계, 기계를 담은 셸 목록이나 비교, tailnet 이나 LAN 주소. 가족 pre-commit hook 은 cwkPippa 의 scripts/git-hooks/pre-commit 이고, Mac 마다 가족 레포 전부에 걸려 있어. 이 hook 이 그 guard 를 --staged 로 돌려. commit 이 더하는 줄만 읽고, 기계 이름이 든 줄은 거절해. 빠져나가는 길은 둘이야. kit 정책이 레지스트리 주인으로 선언한 파일, 그리고 바이트가 그 주인의 commit 된 원본과 똑같은 vendored 사본은 기계 이름이 원래 살아야 하는 자리라서 guard 가 건너뛰어. 그 밖에선 kit 정책에 그 줄 하나를 위한 검토된 예외가 있어야만 통과해. 예외는 레포, 경로, 그 줄 글자의 지문에 묶이고, 분류와 이유가 붙어. 이미 있던 빚은 목록에 보이게 남아. 상관없는 수리를 막아 세우진 않아. 목록은 폭이 둘이야. --check 는 옛 Mac 의 철자만 보고, --check --all-machines 는 레지스트리가 이름 붙인 다른 기계 전부와 tailnet, LAN 주소까지 봐. 한계도 둘 알아 둬. 자기 hooks 경로를 따로 가진 레포는 자기 hook 이 불러 주지 않으면 전역 hook 을 안 돌려. 공개 사이트의 husky hook 은 이제 다른 어떤 조기 종료보다 먼저 가족 hook 을 불러. 그렇게 안 하는 레포에선 규칙이 여전히 읽는 쪽의 몫이야. 그리고 이름을 보는 guard 는 역할을 잘못 쓴 건 못 봐. 이름만 막아.