그누보드 PHP 보안 취약점, 업그레이드를 미루면 안 되는 이유

“사이트 잘 돌아가는데 PHP를 왜 올려요?” 그누보드로 홈페이지를 운영하는 분들한테 제일 많이 듣는 말이에요. 화면이 멀쩡하게 열리고 게시판도 잘 쓰이니까 문제가 없다고 느끼는 거죠. 그런데 그누보드 PHP 보안은 화면이 아니라 서버 안쪽에서 결정돼요. 페이지가 열린다는 사실과 그 서버의 PHP가 안전한 버전인지는 완전히 별개 문제입니다.

마침 2026년 10월에 PHP 보안 취약점이 또 올라왔어요. 이런 공지는 사실 몇 달에 한 번씩 꾸준히 나와요. 그때마다 “또 올려야 하나” 싶지만, 미루다 보면 어느새 지원이 끝난 버전 위에서 사이트를 굴리고 있게 됩니다. 이걸 계기로 그누보드 PHP 보안 업데이트가 왜 필요한지, 버전을 올릴 때 실제로 뭐가 깨지고 어떻게 해결하는지를 제가 직접 겪은 경험으로 정리해볼게요. 저는 웹 에이전시에서 그누보드 사이트를 PHP 5에서 7.4로 수차례 올려본 사람이라, 교과서 얘기가 아니라 현장에서 터지는 것들 위주로 풀겠습니다.

2026년 10월에 또 터진 PHP 보안 취약점

2026년 10월 21일, The PHP Group이 보안 릴리스를 냈어요. 로그인하지 않은 요청만으로 코드가 실행될 수 있는 취약점 두 건(CVE-2026-109618, CVE-2026-109619)을 수정했다고 밝혔습니다. 같은 날 KISA도 대응 공지를 올렸고, 등급은 CVSS v4.0 기준 9.2예요. 10점 만점에 9.2면 사실상 거의 최상위 등급입니다. KISA 보안공지와 PHP 공식 릴리스에 그대로 나와 있어요.

“로그인 안 해도 코드가 실행된다”는 게 핵심이에요. 공격자가 계정이 없어도, 특정 요청만 보내면 서버에서 코드가 돌 수 있다는 뜻이거든요. 그누보드처럼 게시판으로 외부 입력을 상시 받는 사이트는 이런 종류의 취약점에 특히 노출돼 있어요. 화면이 멀쩡해도 서버 PHP가 수정 버전이 아니면 그대로 위험한 상태인 겁니다.

이번 공지의 수정 버전은 계열별로 달라요. 8.2는 8.2.35 이상, 8.3은 8.3.36 이상, 8.4는 8.4.27 이상, 8.5는 8.5.12 이상이 안전 버전입니다. 각 계열의 공식 보안 지원 종료일도 정리해두면 이렇습니다.

PHP 계열	이번 공지 수정 버전	공식 보안 지원 종료
8.2	8.2.35 이상	2026년 12월 31일
8.3	8.3.36 이상	2027년 12월 31일
8.4	8.4.27 이상	2028년 12월 31일
8.1 이하	공식 보안 지원 종료	지원 중인 계열로 이전

PHP 8.1 이하는 패치 자체가 안 나와요

이번 공지에서 진짜 심각한 건 8.1 이하 사용자예요. PHP 공식 지원 버전 페이지를 보면 PHP 8.1은 2025년 12월 31일에 보안 지원이 끝났어요(EOL). 그 이후로는 아무리 치명적인 취약점이 나와도 커뮤니티 패치가 아예 안 나옵니다. 이번 10월 취약점 두 건도 8.2 이상만 수정 버전이 나왔고, 8.1 이하는 “지원 중인 버전으로 올려라”가 유일한 답이에요.

문제는 현실의 사이트 상당수가 이 EOL 버전 위에서 돌아간다는 거예요. 한 조사에 따르면 상위 100만 개 PHP 사이트의 약 55%가 이미 지원 종료된 PHP 버전을 쓰고 있고, 워드프레스만 봐도 42.91%가 2022년에 EOL된 PHP 7.4를 그대로 쓰고 있다고 합니다(365i 조사). 그누보드5 사이트는 사정이 더 안 좋아요. 한번 납품받으면 “잘 돌아가니까” 손 안 대고 몇 년을 쓰는 경우가 대부분이거든요. 소상공인 쇼핑몰, 동호회, 지역 단체, 작은 학원 홈페이지… 관리자가 자기 사이트 PHP 버전이 몇인지도 모르는 경우가 태반이에요.

EOL 버전이 왜 위험하냐면, 알려진 취약점이 “영구 공격 경로”가 되기 때문이에요. 패치가 나오는 버전은 취약점이 발견돼도 금방 막히지만, EOL 버전은 발견된 취약점이 그대로 방치돼요. 공격자 입장에선 “이미 공개된 약점 + 아무도 안 고치는 서버”라서 제일 손쉬운 먹잇감이 되는 거죠. 보안 스캐너 대부분은 “알려진 CVE가 있냐”만 체크하는데, EOL 버전의 진짜 위험은 그 뒤로 계속 쌓이는 미패치 취약점들이에요. 스캐너에는 안 잡히지만 시간이 갈수록 구멍이 늘어나는 상태인 거죠. 그누보드처럼 외부 입력을 상시 받는 사이트일수록 이 방치 시간이 길어지면 위험이 복리로 커집니다. 한 가지 주의할 건, 운영체제 패키지에 백포트된 패치는 버전 숫자만으로 판단할 수 없다는 거예요. 예를 들어 우분투 22.04는 PHP 8.1을 저장소에 포함하고 있고 우분투 쪽에서 보안 패치를 백포트해 내려주기도 하거든요. 그래서 “8.1이니까 무조건 위험”도, “숫자가 최신이니까 무조건 안전”도 아니고, 실제 서버 환경을 봐야 정확히 판단이 됩니다.

그누보드 PHP 보안 말고도 업그레이드가 이득인 이유

업데이트를 보안 때문에만 하는 건 아니에요. 사실 보안은 “안 하면 큰일 나는” 쪽이고, 성능과 호환성은 “하면 좋아지는” 쪽인데 이쪽 이득도 꽤 큽니다.

가장 체감되는 건 속도예요. PHP 7은 5 대비 성능이 크게 뛰었고, 8에서 JIT까지 들어오면서 또 빨라졌어요. 같은 서버에서 PHP만 올려도 페이지 응답이 눈에 띄게 빨라지는 경우가 많아요. 트래픽이 몰리는 쇼핑몰이라면 이 차이가 이탈률로 이어지고요. 두 번째는 호환성이에요. 요즘 나오는 결제 모듈, 외부 API 라이브러리, 각종 플러그인은 최신 PHP를 기준으로 만들어져요. 구버전에 묶여 있으면 새 기능을 붙이고 싶어도 “PHP 버전 때문에 안 된다”는 벽에 자꾸 부딪혀요. 세 번째는 호스팅이에요. 호스팅 업체들이 EOL 버전을 하나둘 내리고 있어서, 버티다 보면 어느 날 호스팅 쪽에서 강제로 버전을 올려버리는 상황이 와요. 그때 급하게 하는 것보다 미리 준비하고 올리는 게 사고가 적습니다.

정리하면 그누보드 PHP 보안은 업그레이드를 해야 하는 가장 급한 이유일 뿐, 속도·호환성·호스팅 정책까지 따지면 미룰 이유가 별로 없어요.

그래서 PHP 버전은 어떻게 확인하나요

업그레이드를 고민하기 전에 지금 버전부터 알아야겠죠. 그누보드라면 관리자로 로그인한 뒤 주소 끝에 /adm/phpinfo.php를 붙이면 맨 위에 쓰는 PHP 버전이 나와요. 이게 공개 화면에는 안 보이고 관리자만 볼 수 있어요. 카페24 웹호스팅은 “나의 서비스 관리 → 서버 환경”에서도 확인할 수 있고요.

여기서 카페24 쓰시는 분들은 반드시 주의하세요. 서버 환경 화면에 현재 버전이 보인다고 “변경신청”을 누르면 안 돼요. 카페24 공식 안내에 나와 있듯이, 그 변경신청은 단순히 버전만 바꾸는 게 아니라 데이터와 DB를 지우고 서버를 새로 깝니다. 버전 올리려다 사이트를 통째로 날리는 사고가 여기서 제일 많이 나요. 눈으로 확인만 하고 신청 버튼은 건드리지 마세요.

아예 모르겠으면 계정 루트에 아래 파일을 올려서 확인하는 방법도 있어요.

<?php echo PHP_VERSION; ?>

이 파일은 버전 확인 후 반드시 지워야 해요. 안 지우면 서버 정보가 외부에 노출되니까요. VPS는 터미널의 php -v와 웹에서 실제로 쓰는 PHP가 다를 수 있다는 것도 알아두면 좋아요.

5에서 7.4로 올리면서 실제로 깨진 것들

여기가 이 글의 핵심이에요. “업그레이드하면 사이트 망가지는 거 아니냐”는 걱정, 맞는 말이에요. 계열을 건너뛰면 실제로 깨집니다. 저는 에이전시 시절에 그누보드 사이트를 PHP 5에서 7.4로 여러 번 올려봤는데, 그때마다 터진 패턴이 꽤 정해져 있었어요.

가장 흔한 게 PHP 7.0에서 제거된 함수들이에요. split()은 7.0에서 완전히 사라져서 preg_split()으로 바꿔야 하고, each()도 7.2에서 deprecated 됐어요. create_function()도 7.2부터 안 쓰는 방향으로 바뀌었고요(PHP 호환성 이슈 정리). 구버전 그누보드 스킨이나 오래된 플러그인에 이런 함수가 박혀 있으면, PHP를 올리는 순간 그 페이지가 흰 화면으로 죽어버려요.

더 골치 아픈 건 에러 처리 방식의 변화예요. PHP 7.4까지는 경고(Warning) 수준이던 코드가 8.x에서는 치명적 오류(Fatal Error)로 바뀌는 경우가 많아요. 그래서 7.4까지는 경고 메시지를 뿜으면서도 어찌어찌 돌아가던 사이트가, 8로 올리면 그 자리에서 멈춰버립니다. 그누보드 구버전의 eval() 사용부도 PHP 7부터 파싱 에러를 예외로 던지게 바뀌어서, 예전처럼 조용히 false 반환하고 넘어가던 코드가 전부 예외로 터져요.

제가 제일 신경 썼던 건 결제모듈이었어요. 쇼핑몰이 붙어 있는 그누보드 사이트는 PG사 연동 모듈이 구버전 PHP 문법에 맞춰져 있는 경우가 많았거든요. 버전을 올리면 결제가 아예 안 되는 사태가 나는데, 이건 사이트 깨지는 것보다 훨씬 심각해요. 돈이 안 들어오니까요. 그래서 결제모듈은 PG사가 제공하는 최신 버전 모듈로 교체하거나, 안 되면 해당 부분 코드를 직접 신버전 문법에 맞게 고쳐서 연동을 다시 살렸어요. 특히 예전 이니시스·KCP 구버전 연동 모듈은 PHP 7에서 사라진 함수를 쓰는 경우가 있어서, 모듈만 최신으로 갈아끼우면 끝나는 게 아니라 연동 코드 흐름을 다시 맞춰줘야 했어요.

스킨 깨지는 것도 한참 손봤어요. 그누보드 스킨은 PHP와 HTML이 한 파일에 섞여 있는 구조라, 스킨 안에 박힌 오래된 PHP 코드가 신버전에서 그대로 터지거든요. 게시판 목록이 안 뜨거나, 상세 페이지만 흰 화면이 되거나, 로그인은 되는데 글쓰기에서 죽거나 하는 식으로 증상이 제각각이에요. 그래서 버전 올린 뒤에 화면, 로그인, 게시판 글쓰기·수정·삭제, 결제까지 주요 동작을 하나씩 다 눌러보면서 확인하는 과정이 꼭 필요해요. “올렸더니 메인은 뜨네” 하고 넘어가면 꼭 어딘가에서 사고가 납니다. 이런 건 한두 번 해봐야 “어디가 터지는지” 감이 생기는 작업이라, 처음 하는 사람한테는 꽤 지뢰밭이에요. 반대로 패턴을 알면 체크리스트처럼 훑어낼 수 있고요.

같은 계열 패치와 메이저 업그레이드는 난이도가 달라요

많은 분들이 “PHP 업데이트”를 하나로 뭉뚱그려서 생각하는데, 실제로는 두 가지가 완전히 달라요. 이걸 구분 못 하면 견적도 일정도 다 틀어집니다.

같은 계열 보안 패치는 예를 들어 8.2.30을 8.2.35로 올리는 거예요. 큰 틀은 그대로고 보안 구멍만 메우는 거라, 코드 수정이 거의 없고 위험도 낮아요. 이번 10월 취약점 대응도 8.2 쓰는 사이트라면 이 범위에 들어갑니다. 반면 메이저 업그레이드는 7.4를 8.3으로 올리는 것처럼 계열 자체를 바꾸는 일이에요. 위에서 말한 문법 변화, 제거된 함수, 확장 모듈, 결제모듈이 전부 영향을 받아서 코드를 같이 봐야 합니다.

그래서 작업 전 백업은 타협 대상이 아니에요. 메이저 업그레이드는 깨질 가능성이 보이면 견적 전에 미리 말하고, 되돌리는 게 안전하면 백업으로 복구할 수 있게 준비해둬야 해요. “아무 변화도 없다”고 장담하는 사람이 있으면 오히려 의심해야 합니다. 계열을 건너뛰는 작업에서 100% 무사고를 장담하는 건 경험이 없거나 솔직하지 않은 거예요.

참고로 저는 에이전시에서 퇴사할 즈음엔 아예 신규 사이트를 처음부터 8.2로만 만들기 시작했어요. 나중에 올릴 거 미리 올려두는 게 결국 품이 덜 들거든요. 몇 년 뒤에 또 마이그레이션하느라 고생하느니, 만들 때부터 최신 계열로 잡아두는 게 장기적으로 훨씬 편하다는 걸 여러 번 겪으면서 알게 됐어요. 지금 5나 7.x로 돌아가는 사이트라면, 이번 보안 이슈를 계기로 한 번에 지원되는 계열로 넘어가는 걸 권합니다.

그래서 랜딩페이지를 하나 만들었어요

이번 10월 공지를 보면서, 그누보드 PHP 보안 업데이트가 필요한데 어디에 맡겨야 할지 모르는 사람이 많겠다는 생각이 들었어요. 그래서 제가 운영하는 디웹시 이름으로 그누보드 PHP 보안 업데이트 서비스 페이지를 만들었습니다. 지금까지 설명한 내용, 그러니까 보안 이슈가 뭔지, 버전 확인법, 같은 계열 패치와 메이저 업그레이드의 차이를 한 페이지에 정리해뒀어요.

페이지를 만들면서 제일 신경 쓴 건 공포 마케팅처럼 안 보이게 하는 거였어요. 그래서 맨 위에 디웹시는 KISA나 The PHP Group과 제휴하거나 인증받은 기관이 아니라고, 공지를 보고 서버 작업을 대행하는 거라고 명시했어요. “모르는 업체가 약점 캐서 겁주는” 느낌이 나면 안 되니까요. 신청 폼에는 서버 비밀번호나 SSH 키를 넣지 말라는 경고도 달았어요. 견적이 확정된 뒤에 접근 방법을 따로 받는 구조로요. 보안 작업을 파는 사람이 정작 보안 의식이 없으면 안 되잖아요.

PHP 버전 업데이트는 결국 “지금은 괜찮아 보이는데”의 함정이에요. 괜찮아 보일 때 미리 해두는 게, 터지고 나서 복구하는 것보다 훨씬 싸게 먹혀요. 사이트가 뚫려서 데이터가 새거나 악성코드가 심어진 뒤에 수습하는 비용은, 미리 버전 올리는 비용과 비교가 안 됩니다. 특히 개인정보를 다루는 사이트라면 사고 한 번에 법적 책임까지 따라와요.

그누보드로 사이트를 운영하는 분이라면 이번 기회에 /adm/phpinfo.php로 버전부터 한 번 확인해보세요. 8.1 이하면 지금이 올릴 때입니다. 버전만 확인하고 카페24 변경신청은 누르지 않기, 작업 전 백업은 필수, 올린 뒤엔 결제까지 전 기능 점검. 이 세 가지만 기억해도 사고는 크게 줄어요. 그누보드 PHP 보안 작업을 직접 하기 어렵다면 디웹시 랜딩도 참고하시고요. 저는 랜딩을 막 올려둔 참이라, 실제로 어떤 문의가 들어오고 어떤 환경이 많은지는 데이터가 쌓이는 대로 다시 정리해볼게요.