부모 테마 업데이트 알림이 뜹니다. 누르기 전에 잠시 멈춥니다 — 우리 자식 테마가 부모의 무엇에 기대고 있는지 기억나지 않기 때문입니다. 그래서 코드를 뒤지기 시작하고, 그것이 매번 반나절짜리 발굴 작업이 됩니다.
이 작업이 오래 걸리는 이유는 어렵기 때문이 아니라 기록이 없기 때문입니다. 의존 지점은 만들 때는 명확하고 두 달 뒤에는 흐릿합니다. 만들 때 적어 두면 업데이트는 점검표가 됩니다.
무엇을 목록에 넣나
이 중 가장 위험한 것은 덮어쓴 템플릿입니다. 자식 테마의 오버라이드는 어느 시점의 사본이 얼어붙은 것이기 때문입니다. 부모가 그 템플릿을 고쳐도 우리 사본은 옛 마크업을 그대로 유지하고, 에러 없이 조용히 낡습니다. 새 기능이 그 템플릿에 들어왔다면 우리 화면에만 그 기능이 없습니다.
훅도 비슷하게 조용합니다. 부모가 훅 이름을 바꾸면 우리 콜백은 그냥 실행되지 않을 뿐이고, 치명적 오류가 나지 않으므로 발견이 늦습니다. 반대로 부모 함수 호출은 이름이 사라지면 즉시 오류가 나므로, 역설적으로 가장 안전한 축에 듭니다.
목록은 손으로 적지 않고 뽑습니다
기억에 의존하면 빠지는 항목이 생깁니다. 대부분은 검색으로 기계적으로 뽑을 수 있습니다.
# 덮어쓴 템플릿 — 부모에 같은 이름이 있는 파일이 대상이다
ls child-theme/*.php child-theme/template-parts/*.php
# 부모 함수에 의존하는 자리 (부모의 함수 접두사로 검색)
grep -rn "parenttheme_" child-theme/ --include="*.php"
# 부모 훅에 붙은 자리
grep -rn "add_action|add_filter|remove_action" child-theme/inc/뽑은 결과를 저장소 안의 문서 파일 하나에 정리합니다. 별도 도구가 필요 없고, 코드와 같은 저장소에 있어야 함께 갱신됩니다. 문서가 다른 곳에 있으면 반드시 낡습니다.
그리고 검증한 부모 버전을 적어 둡니다. 다음 검토는 “지금 버전과 그 버전 사이에 무엇이 바뀌었나” 로 시작할 수 있고, 이것만으로 검토 범위가 크게 줄어듭니다.
업데이트 검토 절차
순서는 스테이징 복제 → 부모 교체 → 목록 점검 → 차이 병합 → 운영 반영이고, 운영에 반영하는 것은 언제나 마지막입니다.
운영에서 바로 누르지 않습니다. 스테이징 사본에 새 부모를 올리고 목록을 한 줄씩 확인합니다. 특히 덮어쓴 템플릿은 세 개를 비교해야 합니다 — 옛 부모 파일, 새 부모 파일, 그리고 우리 사본. 부모가 바꾼 부분을 우리 사본에 옮겨 넣는 것이 이 단계의 실제 작업입니다.
자동 업데이트는 꺼 둡니다. 검증하지 않은 변경이 스스로 굴러 들어오는 상태는 테스트한 것을 배포한다는 원칙과 정면으로 충돌합니다. 업데이트는 “새 파일을 스테이징에서 검증한 뒤 교체하는 작업” 이지 알림을 누르는 일이 아닙니다.
연재를 마치며
여덟 회차에 걸쳐 템플릿 계층에서 시작해 자산 로드 순서, 조각 나누기, 빌드 구성, 출력 이스케이프, 보조 쿼리, 자산 정리, 업데이트 대응까지 왔습니다. 관통하는 원칙은 하나였습니다 — 추측하지 않고 확인한다. 어떤 파일이 그리는지, 어떤 순서로 로드되는지, 무엇이 깨졌는지, 무엇에 기대고 있는지 전부 확인할 방법이 있었습니다.
워드프레스가 오래 버텨 온 이유도 여기 있습니다. 규칙이 문서화돼 있고 확장 지점이 공개돼 있어서, 부모 테마를 건드리지 않고도 원하는 화면을 만들 수 있습니다. 문제가 생기는 곳은 도구가 아니라 기록 없이 쌓인 시간입니다.
이 작업들 — 버전 업그레이드 · 성능 최적화 · 보안 점검 · 구조 정리 — 을 한 번에 맡기고 싶다면 최적화 지원 사업에서 처리합니다. 어떤 순서로 어떻게 작업하는지는 작업 과정에 절차 그대로 공개돼 있습니다.