FrontierStack logoFrontierStack
홈 › 블로그 › PHP는 업그레이드를 강요했고 Apple은 아무것도 보내지 않았습니다: 오래된 macOS Server를 한 번에 현대화하기

PHP는 업그레이드를 강요했고 Apple은 아무것도 보내지 않았습니다: 오래된 macOS Server를 한 번에 현대화하기

게시일 2026-10-24

2026년 10월 21일, PHP는 인증 없이 보낸 요청으로 서버에서 코드를 실행할 수 있는 치명적인 결함 두 가지를 수정했습니다. Linux 서버라면 수정은 패키지로 도착합니다. Apple의 Server.app을 아직 돌리고 있는 Mac에는 아무것도 도착하지 않습니다. Server.app의 웹사이트가 쓰는 것은 Apache에 mod_php로 들어간 Apple 기본 PHP 7.1입니다. php.net은 이 구성을 가장 위험하다고 평가하며, PHP 7.1의 수정은 2019년에 끝났고 Apple이 이를 다시 업데이트하는 일도 없습니다.

그래서 오래된 Mac 서버에서 PHP 업그레이드는 더 이상 언젠가 할 일이 아닙니다. 지금 해야 하고, 몇 년 동안 손대지 않고 돌아온 사이트를 깨뜨리지 않고 해야 합니다. 10월 23일에 출시된 FrontierStack 2.11에서는 구형 Mac 서버 현대화 패널이 이 작업을 한 번의 실행으로 해냅니다. 계획보다 한 걸음 더 나아가, 수정이 나오지 않는 Apple의 Apache를 인터넷 앞단에서 내립니다.

Apple을 기다릴 수 없는 이유

두 결함의 내용과 Homebrew·MacPorts·MAMP에서의 대처는 Mac에서 PHP 2026년 10월 긴급 보안 수정 적용하기에 정리했습니다. 이 글에서는 그 결과로 현대화 패널에서 무엇이 달라졌는지 소개합니다.

자동으로 현대화: 한 번의 실행, 단계마다 확인

이제 패널 맨 위에는 버튼이 두 개 있습니다. 도구 설치는 웹사이트를 건드리지 않고 필요한 것을 모두 갖춥니다. 자동으로 현대화…는 앱 안의 콘솔에서 다음 작업을 차례로 끝까지 진행합니다.

  1. Apple 명령줄 도구(없는 경우). MacPorts에 필요하며, FrontierStack은 서버 자체의 Apple 소프트웨어 업데이트에서 받아 옵니다. 화면도, 로그인한 사용자도 필요 없습니다. Apple은 High Sierra용으로도 아직 제공합니다.
  2. MacPorts, 이어서 PHP 8.5와 새 curl·OpenSSL·rsync. 모두 /opt/local에 들어가며, Apple의 것을 덮어쓰지 않고 옆에 둡니다.
  3. 웹사이트를 PHP-FPM 8.5로 옮깁니다. 기존 php.ini의 한도 값은 그대로 이어받습니다.
  4. Apple의 PHP 7.1을 은퇴시킵니다. Apache는 더 이상 그것을 전혀 불러오지 않습니다.
  5. MacPorts Apache를 serviceproxy 옆에서 테스트한 다음 그 자리를 넘겨받게 합니다.

단계마다 앞뒤로 모든 사이트를 불러와 확인합니다. 사이트가 깨지거나, 페이지가 PHP를 실행하지 않고 소스를 보여 주기 시작하면 그 단계는 스스로 되돌아갑니다. 실행은 거기서 멈추고, 그 앞의 단계는 완료되고 확인된 상태로 남습니다. 전환할 때마다 웹사이트가 멈추는 시간은 몇 초뿐입니다.

PHP 8.5.12 미만은 설치하지 않습니다

패널은 PHP 8.5를 설치하며, 10월 수정이 들어간 첫 8.5 릴리스인 8.5.12보다 오래된 것은 받지 않습니다. 설치·전환·이동 모두 먼저 버전을 확인합니다. PHP를 설치하고 나면 설치 버튼은 업데이트로 바뀌고, MacPorts 포트를 그 자리에서 업그레이드합니다. 다음 PHP 보안 릴리스도 서버를 다시 구성하는 대신 서버마다 클릭 한 번이면 됩니다.

예전에 PHP 8.4로 현대화한 서버도 남겨 두지 않습니다. 업데이트는 먼저 그 PHP 8.4를 수정이 들어간 8.4.27로 올리므로 곧바로 안전해집니다. 그다음 PHP 8.5(으)로 이동…이 같은 앞뒤 확인을 거쳐 사이트를 8.5로 옮기고, 깨진 사이트가 있으면 스스로 8.4로 되돌립니다.

저희 서버에서 직접 해 보면서 작은 문제도 두 가지 찾았습니다. PHP-FPM의 기본 풀은 워커를 다섯 개까지만 허용해 바쁜 서버에는 부족합니다. 그래서 이제 패널은 각 워커가 실제로 쓰는 메모리와 데이터베이스에 필요한 몫으로 풀 크기를 정합니다. 또 오래된 코드에서는 PHP 8의 오류 로그가 몇 시간 만에 수십 MB씩 커질 수 있으므로, 설치할 때 로그 순환도 설정합니다.

Apple의 Apache를 인터넷 앞단에서 내리기

첫 현대화 글에서는 Apple의 Apache를 교체할 수 없다고 썼습니다. Server.app의 웹사이트, 프로파일 관리자, Wiki, 캘린더가 모두 그것을 거치기 때문입니다. 프록시 뒤에 있는 Apache는 지금도 그렇습니다. 달라진 것은 그 앞부분입니다.

serviceproxy는 Server.app이 제공하는 모든 것에 대해 포트 80과 443에서 응답하는 Apache입니다. 같은 세 가지 문제가 거듭 일어났습니다.

교체는 버튼 세 개로, 하나씩 진행합니다.

  1. serviceproxy 교체는 MacPorts Apache를 설치할 뿐 다른 것은 바꾸지 않습니다. serviceproxy의 구성을, Server.app이 거기서 불러오는 파일까지 함께 변환합니다. 인증서·키·체인은 한 세트로 묶어 root만 읽을 수 있는 파일로 보관하고, Apple의 Apache만 이해하는 몇 가지 지시어는 뺍니다.
  2. serviceproxy 옆에서 테스트는 변환한 사본을 127.0.0.1에서 돌립니다. 모든 사이트와 Server.app의 모든 경로를 serviceproxy의 응답과 비교하며, 프로파일 관리자, Wiki, 캘린더, 연락처도 포함합니다. 응답은 모두 같아야 합니다.
  3. 새 serviceproxy로 전환…은 serviceproxy를 멈추고 launchd에서 끄고, 그 포트를 MacPorts Apache에 넘깁니다. 전환한 뒤 응답이 하나라도 다르면 serviceproxy가 곧바로 돌아옵니다.

Server.app은 그대로 돌아가며 프록시 뒤의 모든 것을 계속 관리합니다. Server.app에서 사이트를 바꾸거나 인증서가 갱신되면, 재동기화 작업이 구성을 스스로 다시 변환합니다. 재동기화에 실패하면 패널이 알려 줍니다. serviceproxy로 돌아가기…로 변경 전체를 되돌릴 수 있습니다.

주의할 점이 하나 있으며, 숨기기보다 적어 둡니다. 등록된 기기에 대해 serviceproxy는 Apple의 Apache에만 있는 인증서 검사를 썼습니다. MacPorts Apache는 기기 인증서를 표준 방식으로 검사합니다. 테스트는 iPhone인 척할 수 없으므로, 전환한 뒤에는 프로파일 관리자를 열어 등록된 기기가 여전히 체크인하는지 확인하십시오.

재부팅 반복이 아니라 복구 담당

오래된 Server.app Mac 중 상당수에는 웹사이트가 응답하지 않으면 기기를 재부팅하는 손수 만든 감시 스크립트가 있습니다. 프록시 고장은 재부팅으로 고쳐지지 않습니다. 게다가 Server.app에서 웹사이트를 꺼 두면, 감시 스크립트는 Mac을 계속해서 재부팅합니다. 이번 주에 바로 그 일이 서버 두 대에서 일어났습니다.

서비스 프록시 복구 도구(힐러)가 감시 스크립트를 대신합니다. 1분마다 포트 80과 443, 그리고 그 뒤의 Apache를 각 사이트의 실제 이름으로 확인합니다. 프록시가 멈춰 있으면 프록시만 다시 시작합니다. 15분 안에 세 번 다시 시작해도 낫지 않으면 더 시도하지 않고 찾은 내용을 보고합니다. 다시 시작해도 고칠 수 없는 TLS 키 오류를 로그에서 알아보고, 대신 인증서를 다시 가져오라고 알려 줍니다. Mac을 재부팅하는 일은 없습니다. 전환한 뒤에는 MacPorts Apache를 같은 방식으로 지켜보며, 모든 사건은 FrontierStack 알림으로 전달됩니다.

다른 서버는 응답하지 못하게

Server.app Mac에서 웹 페이지를 내보내도 되는 것은 Server.app뿐입니다. 이제 패널은 그 밖에 응답하는 것이 있는지 찾습니다. macOS에 내장된 Apache, launch 데몬이 띄운 또 다른 Apache나 nginx, 오래된 MAMP 같은 것입니다. 저희 서버 두 대에서는 내장 Apache가 몇 년 전에 켜진 채 남아 있었습니다. 한 대는 포트 80, 다른 한 대는 포트 8080에서 응답하며 PHP 파일을 그대로 텍스트로 내보내고 있었습니다. 사이트의 데이터베이스 암호가 공개되는 것이 바로 이런 경우입니다. 점검 목록은 그런 서버를 실패로 표시하고, 남는 서버를 끄도록 제안합니다. 웹사이트가 꺼져 있는데 포트 80에서 무언가 응답하면 힐러도 알림을 보냅니다.

시스템 키체인 보호

시동할 때 일어나는 키체인 초기화는 생각보다 자주 일어납니다. 이번 주에도 저희 서버 한 대에서 HTTPS가 멈췄습니다. FrontierStack 원격 에이전트는 버전 1.27부터 보호 대상 서버의 시스템 키체인을 백업하고, macOS가 그것을 바꿔치기했을 때 알아챕니다. 그런 다음 원래 키체인을 되돌릴 수 있습니다. 되돌리는 것은 시동 한 번에 최대 한 번이고, 자동으로 되돌리는 것은 허용한 경우뿐입니다. 웹사이트를 MacPorts Apache로 옮기면 그 키는 키체인에서 완전히 벗어납니다. 보호 기능은 메일을 비롯해 아직 키체인에 기대는 나머지 모든 것을 지킵니다.

플릿의 다른 서버에서도

그래도 고칠 수 없는 것

이 모든 것으로 macOS 자체의 보안 업데이트가 돌아오지는 않습니다. 현대화한 뒤 웹사이트는 지원되는 PHP와 유지 관리되는 Apache 위에서 돌아가지만, 그 아래의 커널은 여전히 High Sierra의 것입니다. 이런 서버는 트래픽을 검사하는 방화벽 안쪽에 두고, 관리 포트는 인터넷에서 감추고, 전용 네트워크를 주십시오. 그 강화 작업과 서버를 둘러싼 네트워크 방어는 이미 가진 Mac 서버로 10년 더에서, 준비가 되었을 때 Server.app에서 완전히 옮겨 가는 방법은 macOS Server를 대체한 것들(그리고 옮기는 방법)에서 다룹니다.

시작하기

FrontierStack 2.11로 업데이트하고 오래된 서버를 연결하십시오. 그런 다음 설정 및 마이그레이션 아래의 구형 Mac 서버 현대화를 열거나, macOS 10.x를 돌리는 서버의 페이지에서 이 서버 현대화를 누르십시오. 패널에는 그 서버에서 실제로 돌아가는 서비스의 항목만 나타납니다. 각 단계를 직접 보면서 진행하고 싶다면 도구 설치부터 시작하십시오. 방문자에게 보이는 것은 아무것도 바뀌지 않습니다. 패널이 하는 모든 변경은 백업을 남기며 되돌릴 수 있습니다.

Mac에서 모두 운영하십시오.

FrontierStack은 이 Mac과 연결된 서버에서 서비스를 설치, 모니터링, 보호하며 — 암호와 키는 어떤 AI에게도 보이지 않게 지킵니다.

FrontierStack 다운로드

Apple 공증 완료 · 안전 & 보안 · macOS 13 Ventura 이상