그누보드7 코어 업데이트 때 수정한 파일이나 설정은 유지되나요?

(답변 내용이 길어서 여기에 씁니다.)

7.0.0 정식 버전 사용 중이시라니 업데이트 대상인 최신 버전의 개선 사항뿐 아니라, 
운영 중인 7.0.0의 업데이트 처리 방식을 먼저 확인해야 합니다.
제가 실제 업데이트 과정에서 경험하고 개발자로부터 답변받았던 내용을 조금 더 구체적으로 정리하겠습니다.

그누보드7 개발자는 이슈 #64, #65, #66, #69에서 core:update가 업데이트 대상 버전이 아니라 현재 설치된 버전의 업데이터로 실행된다고 설명했습니다.
실제로 7.0.0 -> 7.0.1 업데이트 과정에서 실행할 업그레이드 스텝이 없는 정상 상황을 기존 업데이터가 실패로 판단하여 중단한 사례가 있었습니다.
해당 문제는 7.0.1에서 수정되었지만, 7.0.0에서 업데이트를 시작할 때는 기존 코드가 실행되므로 오류가 발생했습니다.
- 관련 이슈

#64에서 개발자는 7.0.2부터 업데이트 시 변경된 파일만 업데이트하고, 변경되지 않은 파일은 건드리지 않도록 개선했다고 설명했습니다.
다만 7.0.0이나 7.0.1에서 7.0.2로 업데이트할 때는 해당 개선 사항이 적용되지 않고, 7.0.2 이후 버전에서 업데이트할 때부터 적용된다고 명시했습니다.
따라서 현재 7.0.0을 사용 중이라면 최신 버전(7.0.11)에서 개선된 파일 처리 방식이 첫 번째 업데이트부터 적용된다고 판단해서는 안 됩니다.
또한 변경된 파일만 처리한다는 설명이 사용자 수정 파일을 자동으로 병합하거나 무조건 보존한다는 의미는 아닙니다.
- 관련 이슈

실제로 제가 7.0.0-beta.3 -> 7.0.1 업데이트를 진행했을 때,
templates/_bundled/sirsoft-comm은 제거되었지만 templates/sirsoft-comm은 유지되었습니다.
개발자는 #65에서 _bundled의 사용자 추가 디렉터리가 삭제되는 것은 의도된 정책이 아니라 기존 업데이터의 버그라고 확인했습니다.
다만 개발자 답변에 따르면 이 문제는 7.0.0에서 수정되었습니다.
제가 경험한 삭제 현상은 이전 베타 버전의 업데이터가 실행되면서 발생한 사례이므로,
현재 사용 중이신 7.0.0에서도 동일하게 발생한다고 단정할 수는 없습니다.
또한 #64에서는 public/storage 심볼릭 링크 삭제, 사용자 정의 .htaccess 규칙 손실 등의 현상도 보고되었습니다.
따라서 코어 파일뿐 아니라 직접 추가한 모듈, 플러그인, 템플릿, 웹서버 관련 설정 및 심볼릭 링크도 업데이트 전후로 확인해야 합니다.
- 관련 이슈

코어 업데이트와 확장 업데이트는 별도로 확인해야 합니다.
제 경험에서 코어 업데이트가 완료되었지만 번들 확장 일괄 업데이트가 실패했고, 이후 개별 업데이트 명령으로 정상 처리한 경험이 있습니다.
이는 #66으로 보고했고, 개발자는 기존 버전의 업데이트 프로세스에서 발생한 문제라고 답변했습니다.
- 관련 이슈

현재 상황에서는 다음과 같은 순서로 접근하는 것이 좋겠습니다.
우선 현재 운영 중인 7.0.0 프로젝트의 전체 파일과 데이터베이스를 독립적으로 백업하고, 
직접 수정하거나 추가한 파일을 별도로 확보하는 것이 좋겠습니다.
특히 app, config, resources, routes, public처럼 코어 업데이트 대상에 포함되는 경로를 수정했다면 반드시 원본과 비교해 두는 것이 좋습니다.
.env, storage 등도 백업 대상에 포함하되, 해당 경로가 업데이트 과정에서 어떻게 처리되는지는 현재 설치된 버전의 구현을 기준으로 확인해야 합니다.
Git으로 관리하지 않는 환경이라면 현재 운영 중인 파일과 공식 7.0.0 배포본을 비교하여 직접 수정하거나 추가한 파일의 경로를 확인하는 방법도 있습니다.

운영 환경을 복제한 테스트 인스턴스에서 먼저 업데이트를 진행하시기를 권장합니다.
기존에 Git으로 관리하지 않았더라도 업데이트 전에 Git 저장소를 초기화하고 현재 상태를 커밋해 두면, 
업데이트 후 git status와 git diff로 파일 변경 내역을 비교할 수 있습니다.
이와 함께 데이터베이스, 번들 확장 업데이트 결과, 실제 사이트 동작까지 확인한 뒤 운영 환경에 적용하는 것이 안전하겠습니다.

7.0.0에서 최신 버전으로 업데이트하는 것이 반드시 실패한다는 의미는 아닙니다만 
이미 수정 사항이 있는 프로젝트라면, 최신 버전의 개선 사항만 믿고 바로 업데이트하기보다는 현재 버전의 업데이트 동작을 먼저 검증하는 편이 안전하겠습니다.

7.0.0 버전의 공식 소스 ZIP 다운 링크입니다.

현재까지 수정하신 파일이 app, config, resources 등 코어 영역에 있는지, 확장 영역에 있는지 구체적인 수정 경로를 알면
7.0.0의 업데이트 대상 및 보호 설정과 대조하여 어떤 부분을 우선 확인해야 할지 좀 더 구체적으로 논의할 수 있을 것 같습니다.

-----------------------------------------------------------------------------------------------
2026-10-10T20:xx:xx+09:00
-------------------------------------------------------------------------------------------------

그누보드7 7.1.0의 공식 업그레이드 안내 문서가 공개되었습니다.

7.0.x → 7.1.0 업그레이드 안내

이번 버전에서는 확장 업데이트 시 사용자 수정 레이아웃을 보존하는 기능이 개선되었습니다.

다만 수정 부분과 새 버전의 변경 사항이 겹치면 운영자 수정본이 우선 적용되므로,
업데이트 결과에 표시되는 충돌 항목을 확인하고 필요한 변경 사항을 별도로 반영해야 합니다.
이 기능이 직접 수정한 코어 PHP 파일까지 자동으로 보존한다는 의미는 아닙니다.

기존 JSON 레이아웃도 계속 지원한다고 안내하고 있지만,
실제 7.0.11 -> 7.1.0 업데이트 과정에서 JSON partial 검증 오류가 27건 발생해 [이슈 #144]로 보고했습니다.
7.1.0의 .g7.html 우선 탐색과 경로 정규화 과정에서 발생하는 회귀로 분석했으며,
기존 JSON 파일의 누락이나 잘못된 참조로 확인된 문제는 아닙니다.
해당 이슈에서 제시한 수정 방향과 우회 방법은 아직 별도 검증이 필요합니다.

공식 문서에서는 7.0.x에서 7.1.0으로 업데이트할 때 코어 업데이트 후 번들 확장 일괄 업데이트를 반드시 승인하도록 안내합니다.
모듈·플러그인·템플릿·언어팩 사이에 의존 관계가 있기 때문입니다.
코어 업데이트 자체가 성공하더라도 일부 확장 업데이트는 실패할 수 있으며,
이 경우 실패 원인을 해결한 뒤 해당 확장들을 정해진 순서로 업데이트해야 합니다.

또한 vendor/ 교체, APP_URL/TRUSTED_HOSTS/TRUSTED_PROXIES 설정뿐 아니라,
7.1.0에서 변경된 역할·권한 처리도 확인할 필요가 있습니다.
특히 비활성화된 역할과 운영자가 직접 만든 역할은 업데이트 후 권한 동작이 달라질 수 있으므로 별도로 점검해야 합니다.

앞서 설명한 것처럼 7.0.0에서 업데이트를 시작하면 현재 설치된 7.0.0의 업데이터가 먼저 실행됩니다.
따라서 7.1.0에서 개선된 업데이트 및 복구 기능이 처음부터 모두 적용된다고 판단해서는 안 됩니다.

업데이트 전에는 운영 파일과 데이터베이스를 백업하고,
가능하면 복제한 테스트 환경에서 코어/확장/레이아웃/권한/사이트 접속까지 함께 검증하시기를 권합니다.

업데이트를 앞두고 우려가 있으실 것 같습니다.
쉘에서 core 명령으로 코어를 업데이트했던 경험을 공유합니다.

예전에 업데이트 과정에서 겪었던 문제 중에는 최신 코어 자체의 문제가 아니라,
기존 버전의 업그레이드 프로세스에 남아 있던 문제로 발생한 사례가 있었습니다.
이 부분은 개발자 답변을 통해서도 확인했습니다.

최신 공식 문서의 설명만으로 파일 보존 여부를 판단하기보다는, 현재 설치된 버전의 app/Console/Commands/Core/CoreUpdateCommand.php,
app/Services/CoreUpdateService.php, config/app.php를 함께 확인할 필요가 있습니다.

CoreUpdateService.php의 파일 적용 방식과 config/app.php의 update.targets, excludes, protected_paths 설정을 함께 살펴보면
업데이트 대상과 보호 처리 방식을 파악하는 데 도움이 됩니다.
다만 해당 설정이 실제로 어떤 조건에서 적용되는지는 현재 설치된 버전의 구현을 기준으로 판단해야 합니다.

현재 라라벨에서 읽어 들이는 설정은 다음 명령으로 확인할 수 있습니다.
php artisan tinker --execute='dump(config("app.version"), config("app.update.targets"), config("app.update.excludes"), config("app.update.protected_paths"));'

또한 프로젝트를 Git으로 관리하고 있다면,
업데이트 전에 사용자 수정 내역을 확인하고 별도로 보관하는 것이 좋습니다.
git status --short
git diff > ../core-custom.patch
git diff --cached > ../core-custom-staged.patch
위 명령은 아직 커밋하지 않은 변경 사항을 확인하는 용도입니다.
이미 커밋한 사용자 수정 사항까지 확인하려면 설치된 코어 원본에 해당하는 Git 태그 또는 커밋을 비교 기준으로 지정해야 합니다.
git diff BASE_COMMIT HEAD > ../core-custom-committed.patch
여기서 BASE_COMMIT은 실제 설치된 코어 원본에 해당하는 커밋으로 교체해야 합니다.
단, 프로젝트의 Git 이력에 코어 원본을 기준으로 한 커밋이 존재하지 않거나,
비교 기준이 일치하지 않는 경우에는 해당 방법만으로 사용자 수정 사항을 정확하게 구분하기 어렵습니다.
또한 Git이 추적하지 않는 신규 파일은 위 패치에 포함되지 않으므로 별도로 백업해야 합니다.
Git으로 관리하지 않는 환경이라면 현재 설치된 버전의 배포 원본과 실제 운영 파일을 비교하는 방법도 있습니다.
이와는 별개로 프로젝트 전체 파일과 데이터베이스는 독립적으로 백업해 두는 것이 안전합니다.
Git 패치 파일도 업데이트의 영향을 받지 않는 안전한 위치에 보관해야 합니다.

실제 업데이트 전에 운영 환경을 복제한 테스트 인스턴스에서 먼저 업데이트를 실행하고,
업데이트 전후의 파일을 비교하여 직접 수정하거나 추가한 내용이 유지되는지 확인해 보실 것을 권장합니다.
코어 업데이트가 완료되더라도 모듈/플러그인/템플릿의 업데이트 결과와 실제 동작 여부는 별도로 확인해야 합니다.

경험상 최신 버전의 업데이트 정책과 현재 설치된 버전에서 실제로 실행되는 업데이트 동작은 구분해서 분석해야 합니다.

현재 사용 중인 코어 버전과 업데이트하려는 대상 버전, 그리고 직접 수정하거나 추가한 파일의 경로를 알려주시면
해당 버전 간 업데이트 로직과 파일 보호 처리 방식의 차이를 기준으로 좀 더 구체적인 확인 방법과 업데이트 방향을 분석해 볼 수 있을 것 같습니다.

관련 유사 이슈도 한 번 보시기 바랍니다.

스킨과 data 폴더 내 파일을 제외하고 나머지는 업데이트 될 가능성이 높습니다.

업데이트시 덮어씌어지는 부분은 src/, core/, system/, vendor/ 등의 코어 파일이며 영향을 받지 않는 부분은 .env, data/, uploads/, storage/, themes/, plugins/ 입니다.

코어 영역을 수정하신게 아니면 유지가 되실겁니다.

안녕하세요.

그누보드7의 core:update는 기본적으로 사용자 영역을 보호하면서 코어를 업데이트하는 방식입니다. 다만 직접 수정한 코어 파일까지 모두 보존되는 것은 아닙니다.

1. 코어 파일
새 버전에서 변경된 코어 파일은 교체될 수 있으므로, 직접 수정한 내용이 사라질 수 있습니다. 변경되지 않은 파일은 기본 증분 업데이트에서 유지됩니다.

2. 사용자 환경설정
.env는 보호 대상이지만 APP_VERSION 등 일부 값은 갱신될 수 있습니다. config/ 내부 설정 파일은 업데이트 대상과 겹치면 덮어써질 수 있으므로 별도로 백업하는 것이 좋습니다.

3. 별도 설치한 확장
사용자가 설치한 모듈, 플러그인, 템플릿은 기본적으로 보호됩니다. 다만 기본 제공 번들 확장은 업데이트될 수 있으며, 버전 호환성에 따라 일부 확장이 비활성화될 수 있습니다.

4. 운영 데이터
회원, 게시글 등의 DB 데이터와 storage/ 영역은 일반적으로 유지됩니다. 다만 업데이트 과정에서 DB 마이그레이션 및 설정 동기화가 실행될 수 있으므로 DB 백업은 반드시 필요합니다.

특히 --prune 옵션은 파일 정리 범위가 확대될 수 있고, --no-backup 옵션도 기본 업데이트와 동작이 달라질 수 있으므로 주의해야 합니다.

운영 서버라면 업데이트 전에 DB, .env, config/, storage/, 사용자 확장 및 직접 수정한 코어 파일을 백업하고, 가능하면 테스트 서버에서 먼저 업데이트해 보시는 것을 권장합니다.

결론적으로 사용자 영역은 대부분 보호되지만, 코어를 직접 수정한 부분은 업데이트 시 유지된다고 보장할 수 없습니다. 장기적으로 유지할 기능은 코어 직접 수정 대신 별도 확장으로 분리하는 것이 안전합니다.

참고: https://github.com/gnuboard/g7/blob/main/docs/backend/core-update-system.md