오래된 서버 환경과 최신 기술 스택 간의 버전 차이 때문에 작업은 예상보다 훨씬 험난했고, 끊임없이 발생하는 문제들로 인해 진행이 더뎠습니다. 특히 가장 큰 난관은 아주 오래된 버전의 미디어위키(MediaWiki)였습니다.
포기할까도 생각했지만, 이왕 시작한 것 끝을 보고 싶다는 아쉬움이 컸습니다. 예전에도 ChatGPT의 도움을 받았지만 종종 문제 해결에 실패하곤 했습니다. 이번에는 구글의 Gemini 2.5 Pro와 함께 이 험난한 여정을 시작했고, 수많은 대화 끝에 마침내 성공적으로 이전을 마칠 수 있었습니다. 그 과정에서 겪었던 수많은 이슈와 해결 과정을 정리해 보았습니다.
1단계. 작업 계획 세우기
처음의 계획은 단순했습니다. 새로운 호스팅 환경과의 호환성을 고려하여, 낡은 미디어위키를 한 번에 옮기는 대신 단계적으로 업그레이드한 후 이전하는 것이었죠. Gemini의 도움을 받아 다음과 같이 계획을 세웠습니다.
1차 목표: PHP 호환성 문제 해결을 위해 미디어위키 1.31 → 1.35 (LTS)로 업그레이드.
2차 목표: 미디어위키 1.35 → 1.39 (LTS)로 업그레이드.
최종 목표: 모든 업그레이드가 끝난 후, 새로운 호스팅으로 이전하기.
2단계. OS와 PHP, 모든 것과의 싸움
시작은 오래된 Ubuntu 18.04 환경의 미디어위키 1.31을 1.35로 올리기 위한 PHP 버전 업그레이드였습니다. 하지만 apt 시스템은 GPG 키 만료, 저장소(PPA) 지원 중단 등 온갖 오류를 뿜어내며 저희의 앞을 가로막았습니다. 서버가 오랫동안 관리되지 않았다는 명백한 신호였죠.
결국 PPA를 통한 PHP 업그레이드가 불가능하다는 것을 확인하고, 더 큰 결심을 합니다. 바로 서버 운영체제(OS) 자체를 Ubuntu 18.04에서 20.04로 업그레이드하는 것이었습니다.
하지만 OS 업그레이드는 더 큰 드라마의 서막에 불과했습니다. 디스크 공간 부족 문제를 해결하기 위해 오래된 커널, 로그, 스냅 패키지를 정리하는 과정을 거쳤고, 마침내 시작한 do-release-upgrade는 중간에 멈춰버리는 최악의 상황을 맞이했습니다. dpkg 잠금을 수동으로 해제하고, 깨진 패키지 설정을 강제로 복구하는 아슬아슬한 외줄타기 끝에 간신히 OS 업그레이드를 마칠 수 있었습니다.
우여곡절 끝에 PHP 7.3은 건너뛰고 7.4 버전을 설치했고, 다행히 미디어위키는 새로운 OS 위에서 잘 동작했습니다.
3단계. Ubuntu 20.04와 미디어위키 1.35
아슬아슬한 OS 업그레이드 끝에 Ubuntu 20.04와 PHP 7.4 환경에 안착했습니다. 이제 본래 목표였던 미디어위키 1.35 업그레이드를 위해 php maintenance/update.php 스크립트를 실행했습니다.
하지만 스크립트는 PHP Fatal error: require_once(...) 오류를 내며 멈췄습니다. 원인은 1.31 시절부터 사용하던 LocalSettings.php 파일이 Interwiki와 같은 확장 기능을 낡은 require_once 구문으로 불러오고 있었기 때문입니다.
다행히 이 문제는 네트워크나 다른 복잡한 설정과는 관계가 없었습니다. LocalSettings.php를 열어 문제가 되는 require_once 구문을 모두 미디어위키 1.35의 표준 방식인 wfLoadExtension() 구문으로 변경해주자, update.php 스크립트는 성공적으로 완료되었습니다. 이로써 미디어위키 1.35로의 업그레이드를 마칠 수 있었습니다.
하지만 이 모든 것을 해결했음에도, apt는 또다시 PHP 8.1 패키지를 찾지 못하는 미스터리한 증상을 보였습니다. sources.list.d 디렉토리에 OS 업그레이드 후 남겨진 낡은 설정 파일이 중복으로 존재하여 apt 시스템 전체에 혼란을 주고 있다는 것을 밝혀냈지만, 그것을 정리한 후에도 문제는 해결되지 않았습니다. 마침내 최종 결론에 도달했습니다. 이 서버의 apt 시스템은 회복 불가능할 정도로 손상되었다는 것을요.
4단계. 보이지 않는 벽, 그리고 마이그레이션이라는 결단
1.35 버전에 잠시 안주했지만, 최종 목표인 새 호스팅(PHP 8.1)으로 이전하기 위해서는 현재 서버의 PHP 버전을 먼저 8.1로 올려보는 과정이 필요했습니다.
바로 이 지점에서 우리는 해결할 수 없는 벽에 부딪혔습니다. PPA 저장소를 올바르게 추가하고, 설정 파일을 수동으로 수정하고, apt 캐시를 초기화하는 등 모든 방법을 동원했음에도, 서버는 php8.1 패키지를 찾지 못하는 오류를 반복했습니다.
수많은 진단 끝에, 우리는 이 서버의 apt 패키지 관리 시스템이 OS 업그레이드의 후유증으로 회복 불가능할 정도로 손상되었다는 최종 결론에 도달했습니다. 이 서버를 고치려는 시도는 더 이상 무의미했습니다.
5단계. 새로운 희망 - 마이그레이션
수리가 아닌 새로운 시작을 하기로 결정했습니다. 목표는 다음과 같았습니다.
기존 서버: Ubuntu 20.04, Apache, PHP 7.4, MySQL 5.7
새로운 서버: Ubuntu 22.04, Nginx, PHP 8.1, MySQL 8.0
이전 과정은 그 자체로 또 하나의 도전이었습니다.
웹 서버 변경 (Apache → Nginx): .htaccess가 없는 Nginx 환경에 맞춰 URL 재작성 규칙 등을 포함한 새로운 설정 파일을 작성해야 했습니다.
데이터 이전: mysqldump와 tar로 백업한 데이터베이스와 이미지 파일들을 새 서버로 안전하게 이전하고 복원했습니다.
최종 설정: 미디어위키 웹 설치 마법사를 통해 새로운 환경에 맞는 LocalSettings.php를 생성하고, Common.js를 수정하여 애드센스 광고를 넣는 현대적인 방식으로 교체했습니다. 관리자 계정 분실, 인터페이스 편집 권한(editsitejs) 문제 등 자잘하지만 중요한 문제들도 해결했습니다.
에필로그: 여정의 끝에서 배운 것들
단순한 버전 업데이트로 시작했던 작업은 OS 업그레이드, 서버 복구, 그리고 최종적으로는 새로운 서버로의 마이그레이션이라는 대장정으로 마무리되었습니다. 이 과정을 통해 몇 가지 중요한 교훈을 얻을 수 있었습니다.
백업은 생명선이다: 어떤 작업을 하든, 시작 전 백업은 모든 것을 되돌릴 수 있는 유일한 타임머신입니다.
오래된 시스템은 시한폭탄이다: 당장 문제가 없어 보여도, 오래된 OS와 소프트웨어는 언젠가 반드시 예상치 못한 문제를 일으킵니다.
문제는 복합적이다: 하나의 오류 메시지 뒤에는 여러 원인이 얽혀있을 수 있습니다. 네트워크, 권한, 설정, 캐시 등 다각도로 접근해야 합니다.
때로는 수리보다 새로운 시작이 빠르다: 복구 불가능한 상태에 이르렀을 때, 미련을 버리고 깨끗한 환경에서 새로 시작하는 것이 더 현명한 선택일 수 있습니다.
