서버 관리를 하면서 가급적 최신 버전의 OS와 PHP 버전 사용을 추구하다 보니 해결하기 어려운 문제가 생겼다.
그누보드 php 7.3 설치한 계정을 php 8.3 계정으로 옮기려고 보니 smartedit 웹에디터에서 오류가 발생하고 1시간 넘게 해결하다 보니 무한 루프가 돌아서 서버가 다운되어 재 부팅하는 일까지 어제 있었다. 할 수없이 2가지 버전을 사용하는 방법으로 해결했다. 록키리눅스에서 php 8.3 버전은 안되기에 8.4로 하고 아파치 세팅도 php-fpm 위치만 지정하면 되기에 추천하는 방법이다. 소스를 새 버전에 맞춰 수정하려다 보면 이것 끝이 없다.
한 서버에서 버전을 나누는 이유가 생길 때
운영 중인 서버를 오래 바라보다 보면, 언젠가 버전의 균열이 생기는 시점이 오는 듯합니다. 신규 서비스는 PHP 8.x의 문법과 성능을 자연스럽게 따라가지만, 오래된 서비스는 특정 라이브러리나 코드 습관 때문에 7.x에 머물러야 하는 순간이 있습니다. 이때 서버 전체를 내리는 방식은 바닥을 통째로 바꾸는 일에 가깝고, 영향 범위가 넓어 보입니다. 반대로 도메인 단위로 실행 엔진을 분리하는 방식은, 바닥은 유지한 채 방 하나만 리모델링하는 쪽에 가까운 선택으로 해석됩니다.
Rocky Linux 9.7 환경에서는 특히 이 구분이 더 또렷해지는 경향이 있습니다. PHP 7.3 같은 더 오래된 버전은 패키지 제공 자체가 어려운 편이라, 7.4를 현실적인 하한선으로 두는 구성이 자연스럽게 자리잡는 듯합니다. 그 결과 “PHP 8.3은 유지하고, 레거시 도메인만 PHP 7.4로 보낸다”는 흐름이 가장 안정적으로 보입니다.
먼저 확인되는 전제들
이 방식은 Apache가 PHP를 직접 처리하는 구조(mod_php)가 아니라, PHP-FPM으로 요청을 넘기는 구조일 때 가장 깔끔하게 성립되는 듯합니다. Apache 입장에서는 “이 도메인의 .php 요청을 어느 소켓으로 전달할지”만 알면 되고, 실제 실행은 각 PHP-FPM이 담당합니다. 결국 관건은 두 가지로 정리됩니다. 하나는 PHP 7.4용 PHP-FPM을 별도로 띄우는 일이고, 다른 하나는 도메인별 VirtualHost 안에서 소켓을 정확히 지정하는 일입니다.
특히 멀티 버전 운영에서는 “기본으로 되겠지”라는 기대가 종종 흔들리는 편입니다. 전역 설정에 기본 PHP-FPM 핸들러가 없거나 비활성화되어 있으면, 어떤 도메인은 PHP 처리가 되지 않는 상태로 보일 수 있습니다. 그래서 도메인별로 의도한 핸들러를 명시해두는 방식이 결과적으로 더 정돈된 운영 형태로 보입니다.
Remi 저장소와 7.4 선택의 맥락
Rocky Linux 9.7에서는 AppStream 기본 모듈로 8.1~8.3 계열이 제공되지만, 레거시 운영을 위해서는 Remi 저장소를 사용하는 경우가 흔합니다. 다만 Remi 모듈 목록에서 7.3이 보이지 않는 환경이 많고, 이때 7.4가 “현실적으로 함께 운영 가능한 7.x”로 선택되는 듯합니다. 호환성 관점에서도 7.3에서 7.4로의 이동은 상대적으로 충격이 적은 편으로 해석됩니다.
PHP 7.4 FPM 설치와 기동 흐름
Remi 패키지를 설치할 때는 서버의 기본 PHP(8.3)를 건드리지 않고, php74 전용 패키지를 추가로 올리는 방향이 안정적으로 보입니다. 설치는 remi-safe를 명시하는 쪽이 가장 덜 흔들리는 편입니다.
dnf install -y https://rpms.remirepo.net/enterprise/remi-release-9.rpm
dnf install -y php74
dnf install -y php74-php-fpm
dnf install -y php74-php-mysqlnd
dnf install -y php74-php-gd
dnf install -y php74-php-mbstring
dnf install -y php74-php-opcache
dnf install -y php74-php-xml
dnf install -y php74-php-json
dnf install -y --enablerepo=remi-safe
패키지 설치가 끝난 뒤에는 php74-php-fpm 서비스를 활성화하고, 소켓이 실제로 생성되는 경로를 확인하는 흐름으로 이어집니다.
systemctl enable php74-php-fpm
systemctl start php74-php-fpm
systemctl status php74-php-fpm
Remi 계열 PHP는 일반적으로 /run/php 아래가 아니라 /var/opt/remi/php74 쪽에 런타임 파일이 생성되는 경우가 많습니다. 실제 환경에서 소켓을 확인할 때는 다음 흐름이 유용해 보입니다.
ls /var/opt/remi/php74/run/php-fpm/
정상이라면 www.sock 같은 파일이 보이는 편입니다. 이 소켓 경로가 곧 Apache에서 연결해야 할 목적지가 됩니다.
Apache VirtualHost에서 도메인별로 소켓을 고정하는 방식
도메인 분리는 Apache 설정에서 VirtualHost 단위로 이루어지는 편입니다. 레거시로 분리할 도메인(all2k.kr 같은)에만 PHP 7.4 소켓을 지정하면, 나머지는 기존 8.3 흐름을 유지할 수 있습니다. 다만 앞서 언급한 것처럼 전역 핸들러가 없는 환경에서는 8.3 도메인에도 “어느 소켓으로 보낼지”를 명시해야 안정적으로 보입니다.
레거시 도메인(예: all2k.kr)을 PHP 7.4로 연결
vi /etc/httpd/conf.d/all2k.kr.conf
vi /etc/httpd/conf.d/all2k.kr-ssl.conf
VirtualHost 블록 내부에 아래와 같은 형태로 추가합니다. 핵심은 소켓 경로가 실제 서버에 존재하는지 여부로 보입니다.
SetHandler "proxy:unix:/var/opt/remi/php74/run/php-fpm/www.sock|fcgi://localhost/"
메인 도메인(예: goz.kr)을 PHP 8.3으로 연결
서버 기본 PHP-FPM(8.3)이 생성하는 소켓 경로는 환경마다 조금씩 다릅니다. 흔히 /var/run/php-fpm/www.sock 같은 형태로 보이는 경우가 많습니다. 실제 경로는 서버에서 확인한 뒤 VirtualHost에 넣는 흐름이 안정적입니다.
ls /var/run/php-fpm/
vi /etc/httpd/conf.d/goz.kr-ssl.conf
VirtualHost 내부 예시는 다음 형태로 정리됩니다.
SetHandler "proxy:unix:/var/run/php-fpm/www.sock|fcgi://localhost/"
적용과 확인이 이어지는 지점
설정 적용은 언제나 문법 점검이 먼저인 듯합니다. 문법이 맞아 보이면 reload로 반영하는 편이 흔합니다.
apachectl -t
systemctl reload httpd
도메인별 PHP 버전 확인은 phpinfo 페이지를 잠시 만들고 확인한 뒤 바로 삭제하는 방식이 안전해 보입니다.
echo /home/all2k/public_html/phpinfo.php
rm -f /home/all2k/public_html/phpinfo.php
운영 중에 다시 떠올리기 쉬운 주의점들
멀티 PHP 구성에서 흔히 보이는 실수는, 소켓 경로를 쉘에서 실행하려 하거나(SetHandler를 명령처럼 입력하는 경우), 한 도메인에만 핸들러를 넣고 다른 도메인에는 기본 핸들러가 존재할 것이라 예상하는 경우로 보입니다. 특히 Remi PHP는 런타임 경로가 /var/opt/remi 아래로 분리되는 편이어서, /run/php를 습관적으로 확인하면 “없다”로 보이는 순간이 생길 수 있습니다. 이때는 서비스 상태에 표시되는 설정 경로(/etc/opt/remi/php74/php-fpm.conf 같은)를 따라가면 빠르게 정리되는 듯합니다.
결국 이 구성은 ‘버전 충돌을 서버 전체 문제로 만들지 않는 방식’에 가깝게 보입니다. 하나의 서버 안에서 서로 다른 시대의 코드를 같은 무대에 올려두되, 무대 뒤의 엔진을 분리해서 안정성을 확보하는 형태로 해석됩니다. 시간이 지나 레거시가 정리되면, 해당 VirtualHost에서 PHP 7.4 소켓 지정만 제거하는 방식으로 자연스럽게 정리될 여지도 남아 있는 편입니다.
어제 늦게 까지 삽질한 걸 생각하면 슬프지만 늘 쉬운 방법이 있다는 걸 생각하고 진행하는 게 좋다.
