CodeIgniter 4로 블로그 만들기 #29 — CI4 버전 업그레이드

프레임워크는 계속 업데이트됩니다. 버그 수정과 보안 패치가 꾸준히 나오죠. 오래 방치하면 나중에 한꺼번에 올리기 어려워지고, 그때는 깨진 곳을 찾느라 고생합니다. 그래서 이번 회차는 작은 업그레이드를 안전하게 하는 절차를 익힙니다.

이번 변경 자체는 아주 작습니다. composer.json 한 줄이 바뀌고 composer.lock이 갱신되는 게 전부입니다. 하지만 이 회차의 진짜 내용은 코드 diff가 아니라 "outdated 점검 → 제약 상향 → update → 전체 회귀"라는 워크플로와, 그 워크플로를 받쳐 주는 테스트 안전망입니다.

준비물 / 목표

• 현재 설치된 버전과 최신 버전을 점검
• 프레임워크 제약을 검증한 최신 패치로 상향
• composer update로 잠금 파일 갱신
• 전체 테스트로 회귀 검증

1. 무엇이 뒤처졌는지 점검

먼저 지금 설치된 패키지 중 최신보다 낮은 게 있는지 봅니다.

composer outdated

CI4 프레임워크(codeigniter4/framework)가 얼마나 뒤에 있는지, 최신 안정 버전이 무엇인지 확인합니다. 점검 시점 기준으로는 4.7.3이 최신 안정 버전이었습니다.

2. 제약을 최신 패치로 상향

composer.json의 프레임워크 제약을 올립니다. 지금까지는 ^4.7이었는데, 이걸 검증한 최신 패치인 ^4.7.3으로 올립니다.

"require": {
    "php": "^8.2",
    "codeigniter4/framework": "^4.7.3",
    "codeigniter4/shield": "^1.3",
    "league/commonmark": "^2.8"
}

^4.7도 이미 4.7.3을 허용하긴 합니다. 그런데 굳이 제약의 바닥(floor)을 4.7.3으로 올리는 이유가 있습니다. 이렇게 하면 "이 프로젝트는 최소한 4.7.3에서 검증됐다"는 사실이 composer.json에 명시적으로 남습니다. 다른 사람이 클론해서 설치할 때도 그 아래 버전으로는 내려가지 않게 되고, 우리가 회귀 테스트로 확인한 최저선이 문서처럼 기록됩니다.

3. 잠금 파일 갱신

제약을 올렸으니 실제로 잠금 파일을 갱신합니다.

composer update codeigniter4/framework

composer.lock이 새 해석에 맞춰 갱신됩니다. 이번 경우 ^4.7도 이미 4.7.3을 물고 있었기 때문에 실제 설치 버전 변화는 없었고, 그래서 별도의 호환 수정 코드도 필요하지 않았습니다.

여기서 오해하면 안 되는 점 — "코드 변경이 거의 없으니 이 회차는 시시하다"가 아닙니다. 오히려 업그레이드가 조용히 지나가는 게 정상적인 좋은 상태입니다. 이 회차의 가치는 "무엇이 바뀌었나"가 아니라 "바뀌어도 괜찮은지 어떻게 확인하나"에 있습니다.

4. 전체 회귀 검증

업그레이드의 마지막이자 가장 중요한 단계입니다. 지금까지 ep04부터 쌓아 온 모든 테스트를 한 번에 돌려, 프레임워크를 만진 뒤에도 아무것도 깨지지 않았는지 확인합니다.

composer test

전체 59개 테스트가 전부 초록이면 통과입니다. 만약 어떤 테스트가 빨강으로 바뀌면, 그게 바로 "변경 로그에 따른 호환 수정이 필요한 지점"입니다. 이번엔 그런 곳이 없었지만, 있었다면 여기서 잡아냈을 겁니다.

핵심 개념 — 안전한 업그레이드는 절차와 안전망

업그레이드는 이벤트가 아니라 습관입니다. 작게 자주 올리면 매번 diff가 작아 확인하기 쉽습니다. 몇 년 묵혀 두면 메이저 버전을 여러 개 건너뛰며 깨진 곳을 한꺼번에 마주치게 됩니다.

메이저와 마이너/패치는 리스크가 다릅니다. 이번엔 프레임워크의 패치 수준만 다뤘습니다. 예컨대 phpunit 같은 개발 의존성의 메이저 업그레이드(10 → 12)는 API가 바뀔 수 있어 주제와 위험도가 전혀 다르므로, 이런 건 별도의 회차·별도의 커밋으로 분리하는 게 맞습니다. 한 커밋에 성격이 다른 변경을 섞지 않는 것이 원칙입니다.

전체 회귀가 있어야 업그레이드를 신뢰할 수 있습니다. 테스트 없이 버전을 올리면, 문제가 생겨도 배포 후 사용자가 발견합니다. 우리는 그동안 테스트를 꾸준히 쌓아 왔기 때문에, composer test 한 줄로 업그레이드의 안전을 즉시 확인할 수 있습니다. ep04부터의 투자가 여기서 배당을 돌려주는 셈입니다.

마무리 — 커밋과 태그

git add composer.json composer.lock
git commit -m "chore: CI4 버전 업그레이드"
git tag ep29

다음 회차

드디어 다음 글이 이 강좌의 마지막 회차입니다. 지금까지 개발 환경에서 만들어 온 블로그를, production(운영) 설정으로 배포하는 절차를 정리합니다. 디버그를 끄고, 설정을 .env로 주입하고, writable/ 권한을 맞추는 배포 체크리스트로 강좌를 마무리합니다.

이번 회차 요약

• 다루는 파일: composer.json(^4.7 → ^4.7.3) / composer.lock(갱신)
• 핵심: "outdated 점검 → 제약 상향 → update → 전체 회귀"가 업그레이드 절차. 제약의 바닥을 검증한 패치로 올려 최저 검증선을 기록. 전체 테스트(59)가 안전망.

다음: production 설정과 배포