"옛것을 지운 날 제거를 끝낸 게 아냐. 사라진 채로 있는 매일 제거를 끝내는 거야."
삭제는 폐기가 아냐
Track 1 이 옛 TextForge 기계를 은퇴시켰어. 근데 어느 하루의 삭제는 유지되는 폐기와 같지 않아. 삭제는 사건이고; 폐기는 참으로 유지해야 하는 상태야. 옛 도구엔 서버, 포트, 런치 잡, 래퍼, 환경이 있었고 — 그중 뭐든 누구도 의도 안 하고 돌아올 수 있어: 환경을 재생성하는 스크립트, 버릇으로 다시 더한 런치 잡, 무관한 변경 뒤 다시 리스닝 시작한 포트. 제거는 참으로 남는 동안만 참이야.
기계는 되기어들어
옛 인프라엔 중력이 있어. 스크립트에서 참조되고, 근육 기억에 기억되고, 예전에 됐으니까 되살리기 쉬워. 그게 정확히 '우리 지웠어' 가 약한 보증인 이유야: 돌아오는 데 아무도 되가져오기로 결정할 필요 없어 — 자동화된 프로세스나 무심한 명령이 할 수 있어. 한 번 제거했으니 레거시가 사라졌다 다루는 게 몇 달 뒤 그림자 런타임이 조용히 다시 나타나, 리메이크가 끝냈어야 할 일을 하는 법이야.
초록으로 남는 가드
그래서 폐기는 계속 통과해야 하는 확인으로 강제돼: 도는 레거시 프로세스 없음, 등록된 레거시 런치 잡 없음, 옛 포트에 리스닝 없음, 재생성된 래퍼나 환경 없음. 맨 첫 폐기 검증과 같은 아이디어지만, 상설 불변식으로 승격 — 다시 돌리고 초록을 기대하는 것, 한 번 체크한 상자가 아니라. 스케줄로 검증하는 제거가 제거된 채로 남는 제거야.
폐기 가드 (시간에 걸쳐 초록으로 남아야 함)
---------------------------------------------
레거시 프로세스 없음 pgrep -> 빔
레거시 런치 잡 없음 launchctl list -> 빔
옛 포트 리스닝 없음 lsof :옛_포트 -> 빔
래퍼 / 환경 없음 재생성? -> 아니오
한 번 초록은 삭제. 스케줄로 초록은 폐기.제거는 지속적으로 사라졌다 검증돼야만 진짜야. 뭘 지우는 건 일회성 행동이고; 지워진 채로 두는 건 불변식이야. 자동화, 버릇, 흘러든 명령으로 되살아날 수 있는 뭐든엔, '제거' 하는 정직한 방법은 돌아오면 실패하는 확인을 더하고, 그 확인을 시간에 걸쳐 도는 거야. 검증 안 하는 상태는 그냥 바라는 상태고 — 옛 기계는 바람으로 사라진 채 안 남아.
이건 '런타임 폴백 없음' 의 뒷면이야. Track 1 은 레거시가 절대 폴백이면 안 된다고 했고, 어떤 코드 경로도 못 되살리게 심링크 없이 아카이브했어. 이 레슨은 운영 절반이야: 코드가 실행 불가여도, 프로세스, 포트, 잡이 다른 경로로 되기어들지 않았는지 여전히 검증해. 벨트와 멜빵 — 코드에서 부활을 불가능하게 하고, 그래도 안 일어났는지 확인해.