PHP 7 + CodeIgniter 3 사이트를 PHP 8.4로 올리기 전에 꼭 확인할 것
오래전에 PHP와 CodeIgniter 3로 제작한 홈페이지를 운영하다 보면 어느 순간 호스팅 업체에서 이런 안내를 받게 됩니다.
현재 사용 중인 PHP 버전이 오래됐으므로 PHP 8.x 버전으로 업그레이드하는 것을 권장합니다.
서버 보안과 유지보수를 생각하면 PHP를 최신 버전으로 올리는 것이 맞습니다.
하지만 PHP 7에서 운영되던 오래된 CodeIgniter 3 사이트의 PHP 버전을 곧바로 8.4로 변경하는 것은 주의해야 합니다.
PHP 버전만 바꾸면 끝나는 문제가 아니기 때문입니다.
특히 5년 이상 운영된 홈페이지라면 PHP 자체뿐 아니라 CodeIgniter, 외부 라이브러리, 직접 작성한 소스코드까지 함께 확인해야 합니다.
결론부터 말하면
PHP 7 + CodeIgniter 3 사이트라면 다음과 같은 순서로 작업하는 것을 권장합니다.
현재 사이트 전체 백업
↓
현재 CodeIgniter 버전 확인
↓
CI3 최신 버전 검토
↓
PHP 8 호환성 문제 검사
↓
테스트 서버에서 PHP 8.4 적용
↓
오류 수정
↓
주요 기능 테스트
↓
운영 서버 적용
운영 중인 사이트에서 PHP 버전부터 바로 변경하는 방식은 피하는 것이 좋습니다.
CodeIgniter 3도 버전을 확인해야 한다
오래된 CodeIgniter 3 사이트라고 해도 모두 같은 상태는 아닙니다.
예를 들어 현재 사이트가 다음과 같다고 가정해 보겠습니다.
PHP 7.x
CodeIgniter 3.1.9
CodeIgniter 3의 현재 공식 최신 버전은 3.1.13입니다.
CodeIgniter 공식 사이트에서도 현재 CodeIgniter 3을 legacy version, 즉 이전 세대 버전으로 분류하고 있으며, 주로 보안 관련 유지보수만 이루어지는 상태입니다.
따라서 오래된 CI3 사이트라면 PHP를 올리기 전에 먼저 현재 CI3 버전을 확인하는 것이 좋습니다.
3.1.13에서는 PHP 8.0과 8.1과의 호환성을 위한 여러 수정도 이루어졌습니다.
그렇다고 해서
CI3 3.1.13이면 PHP 8.4에서도 무조건 문제가 없다.
라는 뜻은 아닙니다.
CodeIgniter 자체뿐 아니라 그 위에서 실행되는 애플리케이션 코드와 라이브러리가 있기 때문입니다.
PHP 7에서 PHP 8로 넘어가는 것은 단순한 소수점 업데이트가 아니다
PHP 7.0에서 PHP 7.1 정도로 올라가는 것과
PHP 7.x
↓
PHP 8.x
로 올라가는 것은 의미가 다릅니다.
PHP 8.0은 메이저 버전 업데이트였고, 기존 PHP 코드의 동작 방식이 변경되거나 오래된 기능이 삭제된 부분이 상당히 있습니다.
PHP 공식 마이그레이션 문서에서도 PHP 8.0으로 변경하기 전에 하위 호환성 문제를 테스트하도록 안내하고 있습니다.
예를 들어 다음과 같은 오래된 함수들은 PHP 8에서 제거됐습니다.
each()
create_function()
get_magic_quotes_gpc()
get_magic_quotes_runtime()
예전에 작성된 소스나 오래된 라이브러리에 이런 코드가 남아 있다면 PHP 8로 변경하는 순간 오류가 발생할 수 있습니다.
가장 먼저 확인할 부분 1. 오래된 PHP 함수
예전 PHP 프로젝트라면 다음과 같은 함수를 검색해 보는 것이 좋습니다.
each(
create_function(
get_magic_quotes_gpc(
get_magic_quotes_runtime(
money_format(
Linux 서버라면 프로젝트 폴더에서 간단하게 검색할 수도 있습니다.
grep -R "each(" application/
grep -R "create_function(" application/
grep -R "get_magic_quotes_gpc(" application/
Cursor나 VS Code의 전체 검색 기능을 사용해도 됩니다.
이런 코드는 PHP 8에서 그대로 사용할 수 없거나 수정이 필요할 수 있습니다.
2. PHP 8에서 더 엄격해진 타입 처리
PHP 8에서는 예전 PHP보다 함수의 인수와 타입을 더 엄격하게 검사합니다.
PHP 7에서는 경고 정도로 지나가거나 암묵적으로 처리됐던 코드가 PHP 8에서는 TypeError로 중단되는 경우가 있습니다.
예를 들어 다음처럼 값이 null일 가능성이 있는 코드는 확인할 필요가 있습니다.
strlen($value);
trim($value);
explode(',', $value);
$value가 실제 문자열이 아니라 null이라면 PHP 버전에 따라 경고나 Deprecated 메시지가 발생할 수 있습니다.
따라서 오래된 사이트에서는 다음처럼 데이터가 실제 어떤 형태로 들어오는지를 확인하는 것이 중요합니다.
$value = $value ?? '';
다만 프로젝트 전체에 이런 코드를 기계적으로 추가하는 것은 권장하지 않습니다.
원래 null이 들어오면 안 되는 데이터인지부터 확인하는 것이 좋습니다.
3. 숫자와 문자열 비교 결과도 달라질 수 있다
이 부분은 오류 메시지가 나오지 않으면서도 프로그램 동작을 바꿀 수 있기 때문에 주의해야 합니다.
PHP 7과 PHP 8에서는 숫자와 문자열을 ==로 비교할 때 일부 결과가 달라졌습니다.
예를 들어 PHP 공식 문서에서는 다음과 같은 차이를 설명하고 있습니다.
0 == "foo"
PHP 7에서는 true로 평가될 수 있었지만 PHP 8에서는 false입니다.
오래된 PHP 프로그램에는 이런 느슨한 비교가 상당히 많이 사용되어 있을 수 있습니다.
특히 다음과 같은 코드를 점검할 필요가 있습니다.
if ($value == 0) {
...
}
폼 데이터나 DB에서 가져온 값이 문자열인지 숫자인지에 따라 예상과 다른 결과가 나올 수 있습니다.
가능하면 데이터의 의미가 명확한 곳에서는
===
!==
같은 엄격한 비교를 사용하는 것이 좋습니다.
4. PHP 8.2 이후의 동적 프로퍼티 문제
PHP 8.2부터는 선언되지 않은 객체 프로퍼티를 동적으로 생성하는 방식이 Deprecated 처리됐습니다.
예를 들어 다음 코드입니다.
class User
{
public $name;
}
$user = new User();
$user->email = 'test@example.com';
email이라는 프로퍼티가 클래스에 선언되어 있지 않은 상태에서 동적으로 만들어지고 있습니다.
PHP 8.2 이전에는 흔히 사용되던 방식이지만 PHP 8.2부터는 Deprecated 경고가 발생할 수 있습니다.
오래된 CodeIgniter 프로젝트나 직접 만든 라이브러리에는 이런 패턴이 존재할 가능성이 있습니다.
따라서 PHP 8.4 테스트 환경에서
Deprecated
Warning
Notice
메시지도 무시하지 않고 확인하는 것이 좋습니다.
당장 사이트가 멈추지 않는다고 해서 그대로 운영하면 이후 PHP 버전에서 실제 오류로 바뀔 가능성이 있기 때문입니다.
5. CodeIgniter의 system 폴더를 직접 수정했는지도 확인해야 한다
CI3 버전을 업데이트할 때 특히 조심해야 하는 부분입니다.
CodeIgniter는 보통 다음처럼 구성되어 있습니다.
/application
/system
/index.php
정상적으로 개발했다면 대부분의 사용자 코드는 application 안에 있어야 합니다.
그러나 오래된 프로젝트를 유지보수하다 보면 개발자가 편의를 위해 system 내부의 CodeIgniter 코드를 직접 수정한 경우도 있습니다.
이 상태에서 system 폴더를 새로운 CI3 버전으로 그대로 교체하면 기존 수정사항이 사라질 수 있습니다.
따라서 업데이트 전에
기존 system
새 system
폴더를 비교하는 것이 안전합니다.
Git을 사용한다면 더욱 편합니다.
6. 외부 라이브러리가 더 큰 문제일 수도 있다
CodeIgniter 자체보다 오히려 오래된 외부 라이브러리에서 문제가 발생하는 경우도 많습니다.
예를 들어 오래된 사이트에는 다음과 같은 라이브러리가 들어 있을 수 있습니다.
메일 발송 라이브러리
Excel 라이브러리
이미지 처리 라이브러리
PG 결제 모듈
본인인증 모듈
SNS 로그인
문자 발송 모듈
에디터
캡차
특히 PHP 파일을 프로젝트에 직접 복사해서 사용하는 형태라면 설치된 버전조차 알기 어려운 경우가 있습니다.
따라서 PHP 8.4 업그레이드 전에
/application/libraries
/application/third_party
/vendor
등을 확인하는 것이 좋습니다.
7. MySQL도 함께 확인해야 한다
PHP 버전을 변경할 때 데이터베이스 서버가 같이 변경되는 것은 아니지만, PHP의 MySQL 드라이버와 사용 코드 때문에 문제가 발생할 수 있습니다.
오래된 프로젝트라면 특히 다음을 확인합니다.
mysql_* 함수 사용 여부
mysqli 사용 여부
PDO 사용 여부
CI Database Library 사용 여부
아주 오래된 PHP 프로그램에서 사용되던
mysql_query()
mysql_connect()
mysql_real_escape_string()
같은 mysql_* 함수는 이미 오래전에 PHP에서 제거됐습니다.
CodeIgniter의 Database Library를 정상적으로 사용하고 있다면 상대적으로 문제가 적지만, 프로젝트 곳곳에서 DB 함수나 mysqli를 직접 사용했다면 별도로 검사하는 것이 좋습니다.
8. 세션과 쿠키도 반드시 테스트한다
PHP 버전을 변경한 뒤 첫 화면은 정상적으로 나오는데 로그인에서 문제가 발생하는 경우도 있습니다.
따라서 다음 항목은 반드시 확인해야 합니다.
로그인
로그아웃
세션 유지
관리자 로그인
자동 로그인
쿠키 저장
CSRF
폼 전송
CodeIgniter 3.1.13에서도 PHP 8.0/8.1과의 호환성을 위해 세션 관련 수정이 이루어진 이력이 있습니다.
오래된 CI3 버전을 그대로 두고 PHP만 크게 올리는 것을 권장하지 않는 이유 중 하나입니다.
9. 운영 서버에서 바로 PHP 8.4로 변경하지 않는다
가장 중요한 부분입니다.
가능하면 운영 서버와 동일한 소스를 복사해 별도의 테스트 환경을 만드는 것이 좋습니다.
예를 들어
현재 운영
www.example.com
PHP 7.x
라면
테스트
dev.example.com
PHP 8.4
처럼 만드는 방법입니다.
또는 로컬 개발 환경에서 PHP 8.4를 적용해도 됩니다.
중요한 것은 실제 서비스 사용자들이 접속하는 서버에서 바로 테스트하지 않는 것입니다.
10. 테스트할 때 error_reporting을 충분히 확인한다
PHP 버전을 올렸는데 화면이 정상적으로 나온다고 끝난 것이 아닙니다.
테스트 서버에서는 PHP 오류 로그를 확인해야 합니다.
개발 환경이라면 상황에 따라 다음과 같이 오류를 확인할 수 있습니다.
error_reporting(E_ALL);
ini_set('display_errors', 1);
다만 운영 서버에서는 오류 내용을 사용자 화면에 그대로 노출하지 않는 것이 좋습니다.
운영에서는 화면 출력보다는 로그 파일로 기록하도록 설정하는 것이 안전합니다.
CodeIgniter 로그도 함께 확인합니다.
application/logs/
특히 확인해야 할 메시지는 다음과 같습니다.
Fatal error
TypeError
Deprecated
Warning
Notice
Undefined property
Undefined array key
Deprecated라고 해서 무조건 사이트가 당장 고장 나는 것은 아닙니다.
그러나 앞으로 제거될 가능성이 있는 기능이므로 PHP 8.4 전환 작업을 하는 김에 가능한 범위에서 정리하는 것이 좋습니다.
PHP 8.4에서 추가로 주의할 부분
PHP 8.4에서도 일부 기존 기능이 Deprecated 처리되거나 동작이 변경됐습니다.
예를 들어 PHP 8.4에서는 암묵적으로 nullable인 타입 선언 방식이 Deprecated 되었고, 일부 mysqli 함수도 Deprecated 대상이 됐습니다.
PHP는 8.0 이후에도
8.0
8.1
8.2
8.3
8.4
버전이 올라가면서 조금씩 호환성 변경이 누적됐습니다.
따라서 PHP 7에서 PHP 8.4로 한 번에 올라간다면 PHP 8.4 변경사항만 보는 것이 아니라 PHP 8.0부터 8.4까지의 변경사항을 함께 고려해야 합니다.
실제 점검 순서
오래된 CI3 사이트를 맡게 된다면 저는 대략 다음 순서로 진행하는 것이 좋다고 생각합니다.
1단계. 현재 환경 기록
먼저 현재 정상적으로 운영되는 환경을 기록합니다.
PHP 버전
CodeIgniter 버전
MySQL/MariaDB 버전
Apache/Nginx
사용 PHP Extension
외부 라이브러리
PHP 버전은 다음처럼 확인할 수 있습니다.
echo PHP_VERSION;
또는
phpinfo();
를 임시로 사용할 수도 있습니다.
단, phpinfo() 페이지에는 서버 정보가 많이 포함되므로 확인 후에는 반드시 삭제하는 것이 좋습니다.
2단계. 전체 백업
최소한 다음 세 가지를 확보합니다.
웹 소스 전체
DB 전체
현재 서버 설정 정보
가능하면 Git 저장소도 만들어 현재 정상 상태를 커밋해 두는 것을 권장합니다.
git init
git add .
git commit -m "backup before PHP 8.4 upgrade"
이렇게 해두면 수정 과정에서 무엇이 바뀌었는지 확인하기가 매우 쉽습니다.
3단계. CodeIgniter 버전 확인
다음 파일에서 확인할 수 있습니다.
system/core/CodeIgniter.php
CI3에서는 보통 다음과 같은 상수가 있습니다.
define('CI_VERSION', '3.1.9');
3.1.9 같은 오래된 버전이라면 PHP 8.4 테스트 전에 3.1.13으로 업데이트할 수 있는지 먼저 검토하는 것이 좋습니다.
단, 앞서 말했듯 system 폴더에 직접 수정한 내용이 없는지 반드시 확인해야 합니다.
4단계. PHP 8 비호환 코드 검색
프로젝트 전체에서 다음 키워드를 우선 검색합니다.
each(
create_function(
get_magic_quotes
mysql_
money_format(
__autoload(
그 다음 PHP 8.4 환경에서 직접 실행하면서 오류 로그를 확인합니다.
정적 검색만으로 모든 문제를 찾을 수는 없습니다.
5단계. 주요 기능 테스트
최소한 다음 항목은 직접 테스트합니다.
메인 페이지
회원가입
로그인
로그아웃
비밀번호 찾기
게시판
글쓰기
수정
삭제
파일 업로드
이미지 업로드
검색
메일 발송
문자 발송
결제
관리자 페이지
엑셀 다운로드
외부 API 연동
Cron 작업
사이트마다 기능이 다르므로 실제 서비스의 핵심 기능 목록을 따로 작성하는 것이 좋습니다.
AI를 이용하면 이런 작업이 훨씬 편해졌다
예전에는 PHP 버전을 올릴 때 프로젝트 전체를 사람이 직접 검색하면서 오래된 코드를 찾아야 했습니다.
지금은 Cursor나 Codex 같은 AI 코딩 도구를 이용하면 상당 부분을 빠르게 확인할 수 있습니다.
예를 들어 프로젝트를 열고 다음과 같이 요청할 수 있습니다.
이 프로젝트는 PHP 7과 CodeIgniter 3로 작성되어 있다.
PHP 8.4로 업그레이드하려고 한다.
전체 프로젝트에서 PHP 8.x에서 제거되었거나
Deprecated된 함수와 문법을 검색하고,
파일별로 수정이 필요한 이유를 정리해줘.
코드를 바로 수정하지 말고 먼저 점검 보고서를 만들어줘.
여기서 중요한 부분은
처음부터 AI에게 전체 소스를 수정시키지 않는 것입니다.
먼저
분석
→ 문제 목록 작성
→ 수정 우선순위 확인
→ 수정
→ 테스트
순서로 진행하는 것이 안전합니다.
오래된 운영 사이트일수록 특히 그렇습니다.
그러면 CodeIgniter 4로 바로 바꾸는 것이 좋을까?
장기적으로 보면 CI4로 이전하는 것이 더 좋은 선택일 수 있습니다.
현재 CodeIgniter 공식 사이트에서도 CI4가 최신 세대이고 CI3는 legacy 버전으로 분류되어 있습니다.
하지만
PHP 7 → PHP 8.4
CI3 → CI4
를 동시에 진행하면 작업 규모가 상당히 커집니다.
CI3와 CI4는 디렉터리 구조부터 Namespace, Routing, Model, Config 등 많은 부분이 다르기 때문에 단순 버전 업데이트로 볼 수 없습니다.
따라서 오래된 운영 사이트라면 상황에 따라
1차
CI3를 유지하면서
PHP 8 환경에서 정상 동작하도록 보수
한 뒤,
2차
필요하면 CI4로 리팩터링 또는 재구축
하는 전략도 현실적입니다.
사이트의 남은 운영기간과 기능 규모, 향후 추가 개발 계획 등을 함께 판단해야 합니다.
5년 된 사이트에서 이런 문제가 생기는 것은 이상한 일이 아니다
웹사이트는 제작 당시 정상적으로 만들어졌더라도 시간이 지나면 실행 환경이 바뀝니다.
PHP도 계속 업데이트되고,
PHP
웹서버
DB
프레임워크
브라우저
보안 정책
외부 API
가 함께 변화합니다.
Windows 10에서 잘 사용하던 프로그램이 Windows 11에서도 반드시 아무 수정 없이 동작한다고 보장할 수 없는 것과 비슷합니다.
웹사이트도 마찬가지입니다.
5년 정도 운영한 사이트라면 PHP와 프레임워크 버전 차이로 인해 호환성 점검이나 수정이 필요해지는 것은 충분히 자연스러운 일입니다.
정리
PHP 7 + CodeIgniter 3 사이트를 PHP 8.4로 변경할 때는 PHP 버전만 바꿔서는 안 됩니다.
최소한 다음 순서로 진행하는 것이 좋습니다.
1. 현재 서버 환경 확인
2. 소스와 DB 전체 백업
3. CodeIgniter 버전 확인
4. 가능하면 CI3 3.1.13 업데이트 검토
5. PHP 8에서 제거된 함수 검색
6. PHP 8.2 이후 Deprecated 코드 확인
7. 외부 라이브러리 확인
8. 테스트 서버에 PHP 8.4 적용
9. 오류 로그 확인
10. 로그인·게시판·업로드·메일 등 주요 기능 테스트
11. 문제가 없을 때 운영 서버 적용
12. 문제가 생길 경우 즉시 기존 PHP 환경으로 롤백
특히 오래된 운영 사이트라면 업데이트 자체보다 테스트와 롤백 계획이 더 중요합니다.
PHP 버전 업그레이드는 버튼 하나를 눌러 끝나는 서버 설정 변경이 아니라, 오래된 웹 애플리케이션이 새로운 실행 환경에서도 정상적으로 동작하는지 확인하는 호환성 점검 작업으로 보는 것이 정확합니다.
※ 이 글은 PHP 공식 PHP 7.4 → 8.0 마이그레이션 문서와 PHP 8.1~8.4 변경사항, CodeIgniter 공식 문서를 기준으로 작성했습니다. 프로젝트 구조와 사용하는 라이브러리에 따라 실제 수정 범위는 달라질 수 있습니다.