라이믹스/매뉴얼/라이믹스 업데이트

상위 문서: 라이믹스/매뉴얼

1. 개요#

라이믹스의 코어를 새 버전으로 갱신하는 방법이다. 공식 매뉴얼은 압축 파일을 기존 설치 경로에 덮어쓰는 방법과 Git으로 변경 사항을 받아오는 방법을 안내한다. XE에서 처음 전환하는 경우에는 라이믹스/XE에서 넘어오기를 참고한다.

2. 업데이트 전 준비#

1. 적용할 버전의 릴리즈 노트와 설치 환경을 확인한다. PHP·DB 요구사항과 사용 중인 서드파티 자료의 호환성을 함께 점검한다.
2. 설치 폴더 전체와 DB를 각각 백업한다. 코어 수정분, 추가 자료, 설정 및 첨부파일도 포함하고 복원 방법을 확인한다. 파일만 되돌려서는 DB 변경을 취소할 수 없다.
3. 가능하면 별도 테스트 환경에서 먼저 갱신한다. 운영 사이트에 적용할 때는 작업 중 글쓰기 등 데이터 변경을 제한한다.
4. Git 설치라면 설치 폴더에서 git status, git branch --show-current, git remote -v로 변경분·브랜치·원격 저장소를 확인한다. 아래 예제는 origin이 공식 저장소인 경우이다.

3. 압축 파일로 덮어쓰기#

1. 공식 릴리즈 공지에서 적용할 버전의 공지를 열고 전체 배포 파일을 내려받는다. 공지의 Download 링크와 Changed Files Only 링크를 구분한다. GitHub Releases에 배포 파일이 등록되어 있다고 가정하지 않는다.
2. 기존 사이트 밖의 별도 작업 폴더에 압축을 푼다. 압축 파일에 따라 최상위 폴더 이름이 다를 수 있다.
3. 압축을 푼 폴더 안의 index.php, common, modules 등이 기존 설치 폴더의 같은 위치에 덮어써지도록 업로드한다. .htaccess 등 숨김 파일도 포함한다.
4. 아래 업데이트 후 확인 절차를 수행한다.

기존 설치 폴더에 unzip ... -d 설치경로만 실행하면 그 아래에 배포 폴더가 하나 더 생겨 실제 코어가 갱신되지 않을 수 있다. 업로드 후에는 새 파일이 기존 index.php와 같은 경로에 있는지 확인한다.

배포 파일에는 files 폴더가 포함되지 않으며, 사용자 설정·첨부파일은 files와 DB에 저장된다. 추가한 서드파티 자료도 보통 유지된다. 다만 배포 파일과 같은 경로를 직접 수정했다면 수정분이 덮어써질 수 있다. 백업 없이 안전하다는 의미는 아니다.

4. Git으로 업데이트#

Git으로 설치하여 .git 디렉터리가 남아 있는 사이트에서 사용한다. 압축 파일로 설치한 사이트에서는 이 절차를 그대로 실행할 수 없다.

4.1. 코어 수정이 없는 경우#

현재 브랜치와 추적 대상이 의도한 버전인지 확인한 뒤 실행한다.

git status
git pull --ff-only

--ff-only는 이력이 갈라진 경우 임의로 병합하지 않고 중단한다. 실패하면 현재 상태를 확인하고 아래의 수정분 관리 절차를 검토한다. 새 브랜치로 전환한 경우에도 그 브랜치의 추적 대상을 확인한다.

추가한 모듈·스킨은 Untracked files로 표시될 수 있다. 이를 코어 변경으로 취급할 필요는 없지만, 새 코어 파일과 경로가 겹치면 업데이트가 중단될 수 있으므로 메시지를 확인한다. 강제 초기화나 일괄 삭제로 해결하지 않는다.

4.2. 코어 수정이 적은 경우#

수정분을 임시 보관한 뒤 업데이트하고 다시 적용한다.

git stash push -m "라이믹스 업데이트 전 코어 수정분"
git stash list

방금 저장한 항목이 생겼는지 확인한다. 기본 stash는 미추적 파일과 무시된 파일을 포함하지 않으므로 추가 자료는 따로 백업한다. 저장된 항목을 확인한 뒤 다음을 실행한다.

git pull --ff-only
git stash apply 'stash@{0}'

위의 stash@{0}은 방금 만든 항목이 최신 항목인 경우의 예이다. 기존 stash를 잘못 적용하지 않도록 git stash list로 구분한다. 충돌이 발생하면 해당 파일을 열어 <<<<<<<, =======, >>>>>>> 표시를 해결하고 동작을 검증한다. apply는 보관본을 자동 삭제하지 않는다.

업데이트 후 점검까지 끝난 다음, 더 이상 필요 없는 해당 항목 하나만 삭제한다.

git stash drop 'stash@{0}'

git stash clear는 기존 보관본까지 모두 지우므로 이 절차의 정리 명령으로 사용하지 않는다.

4.3. 코어 수정이 많은 경우#

별도 브랜치에서 수정분을 커밋하고 공식 브랜치의 변경을 병합한다. 다음은 master의 변경을 가져오는 예이다.

git checkout -b mysite
git add -u .
git commit -m "사이트 코어 수정분 보관"
git fetch origin
git merge origin/master

git add -u는 이미 추적 중인 파일의 수정·삭제만 포함한다. 새로 만든 코어 파일이 있다면 필요한 파일을 개별적으로 추가하고, 설정 파일이나 첨부파일을 실수로 커밋하지 않도록 확인한다. 이미 수정분 관리 브랜치가 있으면 새로 만들지 않고 그 브랜치에서 진행한다.

충돌이 발생하면 수정 후 해결한 파일만 git add하고 병합 커밋을 완료한다. 개발 브랜치 이름은 시기마다 달라질 수 있으므로 과거 문서의 develop을 그대로 지정하지 말고 실제 공식 저장소와 적용 대상 릴리즈를 확인한다.

5. 여러 버전을 건너뛸 때#

현재 버전과 대상 버전 사이의 공지에서 PHP 요구 사항, 삭제·변경된 API와 권한 제한을 함께 확인한다. 변경 파일만 적용할 때는 해당 파일 묶음이 전제로 하는 이전 버전을 확인한다. 오래된 버전에서 바로 최신 변경 파일만 덮어쓰면 중간 변경이 누락될 수 있다.

예를 들어 2.1.37은 보안 수정과 array_escape()의 자료형 처리 변경을 포함하고, 2.1.38은 HTMLFilter 옵션 제거와 게시판 관리자의 스크립트 수정 권한 제한을 포함한다. 라이믹스/릴리즈 노트/2.1.37·라이믹스/릴리즈 노트/2.1.38과 라이믹스/매뉴얼/서드파티 자료 호환성 체크리스트를 함께 확인한다.

6. 업데이트 후 확인#

1. 관리자 화면(/admin)에 접속하여 안내되는 모듈 업데이트·DB 변경 작업을 완료한다.
2. 관리자 화면에서 캐시 재생성을 실행한다. PHP OPcache 등 별도 캐시가 남는 환경은 해당 서버의 운영 절차에 따라 갱신한다.
3. 관리자 화면의 버전을 확인하고 메인 화면, 로그인, 글·댓글 작성, 파일 업로드, 짧은주소, 사용 중인 메일·알림 기능을 점검한다.
4. PHP·웹서버 오류 로그와 서드파티 자료의 동작을 확인한 뒤 사이트를 다시 연다.

문제가 생겼다면 오류 메시지와 적용 버전을 기록하여 원인을 확인한다. 복원이 필요하면 같은 시점에 백업한 파일과 DB를 함께 복원한다. 업데이트 후 새로 작성된 데이터가 있다면 복원으로 사라질 수 있으므로 쓰기 제한을 유지한 상태에서 판단한다.

7. 운영 보충 안내#

• 라이믹스/매뉴얼/백업과 복원 — 파일·DB 시점을 맞추고 복원을 연습하는 방법
• 라이믹스/매뉴얼/캐시와 성능 점검 — 라이믹스 캐시 재생성과 PHP OPcache·CDN 캐시의 차이
• 라이믹스/매뉴얼/업로드 오류와 서버 진단 — 갱신 후 업로드·서버 오류의 진단

8. 같이 보기#

• 라이믹스/설치
• 라이믹스/매뉴얼/설치 환경
• 라이믹스/매뉴얼/서드파티 자료 호환성 체크리스트
• 라이믹스/릴리즈 노트

9. 출처#

이 문서는 라이믹스 공식 매뉴얼을 바탕으로 경로 확인, 백업 및 점검 절차를 보완하였다. 공식 매뉴얼은 CC BY-SA 4.0으로 배포된다.