업데이트를 미루는 운영자에게 이유를 물으면 대답이 거의 같습니다. “지난번에 올렸다가 화면이 깨져서.” 그래서 다음 업데이트가 두려워지고, 미루는 동안 밀린 버전이 쌓이고, 쌓인 만큼 다음 업데이트가 실제로 더 위험해집니다. 이 악순환은 대개 원인을 잘못 지목한 자리에서 시작합니다.
워드프레스 코어는 하위 호환을 대단히 보수적으로 지키는 소프트웨어입니다. 오래된 함수 하나를 없애는 데도 여러 해에 걸쳐 경고를 먼저 내보내고, 그 사이에 대체 수단을 마련해 둡니다. 그래서 코어만 올렸을 때 사이트가 통째로 죽는 일은 드뭅니다. 실제로 깨지는 것은 코어가 아니라 조합입니다.
깨지는 것은 코어가 아니라 조합입니다
운영 중인 워드프레스는 여러 층이 겹쳐 있고, 위층은 아래층의 동작을 가정합니다. 그 가정은 문서화된 약속일 수도 있고, “지금은 이렇게 동작하니까” 라는 관찰에 불과할 수도 있습니다. 후자가 문제를 만듭니다.
구체적인 예를 들면 이렇습니다. 어떤 플러그인이 코어의 내부 함수를 직접 호출하고 있었는데 그 함수가 정리되면서 오류가 납니다. 어떤 테마가 코어가 출력하던 특정 HTML 구조를 CSS 셀렉터로 붙잡고 있었는데 구조가 바뀌면서 레이아웃이 무너집니다. 두 플러그인이 같은 지점에 개입하면서 실행 순서가 바뀌어 한쪽 기능이 사라집니다.
세 경우 모두 코어는 자기 약속을 지켰습니다. 깨진 것은 약속이 아닌 것에 기대고 있던 쪽입니다. 이 구분이 중요한 이유는, 원인을 어디로 지목하느냐에 따라 다음 업데이트의 대비가 완전히 달라지기 때문입니다.
원인 지목이 바뀌면 준비 방법이 바뀝니다
왼쪽 진단은 아무것도 해결하지 않으면서 보안 패치까지 함께 미루게 만듭니다. 공개된 취약점은 공개된 순간부터 자동화된 스캔의 표적이 되므로, 미루는 것 자체가 새로운 위험을 만듭니다. 반면 오른쪽 진단은 실행 가능한 다음 행동으로 이어집니다 — 한 번에 하나씩 올리고, 사이사이에 확인하고, 무엇이 원인인지 특정할 수 있는 상태를 유지하는 것입니다.
그래서 무엇을 준비하면 되나
깨짐이 조합에서 온다면, 대비도 조합을 다루는 방식이어야 합니다. 이 연재가 다룰 것이 정확히 그것입니다. 순서를 정해 하나씩 올리고(2회차), 되돌릴 수 있는 상태를 먼저 만들고(3회차), 프로덕션이 아닌 곳에서 먼저 해 보고(4회차), 무엇을 자동에 맡길지 정하고(5회차), 확인하고 기록합니다(7 · 8회차).
덧붙이면, 위층일수록 취약하다는 사실은 위층을 적게 유지할수록 업데이트가 쉬워진다는 뜻이기도 합니다. 쓰지 않는 플러그인 하나를 지우는 것은 기능 하나를 버리는 일이 아니라 다음 업데이트의 변수 하나를 줄이는 일입니다.
플러그인과 테마가 만드는 유지보수 부채는 테마 · 플러그인 아카이브에서 더 다루고, 몇 년째 손대지 못해 한 번에 올리기 부담스러운 사이트라면 최적화 지원 사업에서 업그레이드를 작업으로 맡길 수 있습니다.
다음 회차
원인이 조합이라면 순서가 중요해집니다. 다음 회차는 코어 · 플러그인 · 테마 중 무엇부터 올리는가 — 그리고 왜 사이사이에 확인해야 하는가입니다.